Suspicious AWS IAM API Calls via Temporary Session Tokens

This brief details detection of suspicious AWS Identity and Access Management (IAM) API operations executed using temporary session credentials, characterized by access key IDs beginning with "ASIA". These temporary credentials are typically generated by services like sts:GetSessionToken, sts:AssumeRole, or AWS SSO logins and are intended for short-term, programmatic use. It is highly unusual for legitimate users or automated processes to perform privileged IAM actions, such as creating users, updating policies, or managing multi-factor authentication (MFA), directly with these short-lived tokens. Such activity may signal credential theft, session hijacking, or the abuse of temporary credentials associated with a privileged role, enabling an attacker to establish persistence, escalate privileges, or disable security protections within an AWS environment. The detection specifically excludes legitimate console login sessions, significantly reducing false positives.

Attack Chain

1. Initial Access: An attacker gains initial access to an AWS environment, often through compromised long-term credentials (e.g., IAM user access keys, compromised AWS SSO accounts) obtained via phishing, malware, or exposed secrets.
2. Credential Access: Using the compromised long-term credentials, the attacker authenticates to AWS.
3. STS Token Generation: The attacker generates temporary session credentials (access keys starting with "ASIA") via AWS Security Token Service (STS) calls like sts:GetSessionToken or sts:AssumeRole. This allows them to blend in with normal programmatic activity.
4. Privileged IAM Action: The attacker immediately utilizes these temporary session tokens to perform sensitive IAM API operations. Examples include iam:CreateAccessKey for a new backdoor user, iam:PutUserPolicy to elevate permissions, or iam:UpdateAssumeRolePolicy to modify trust relationships for privilege escalation.
5. Persistence Established: By creating new access keys, modifying existing policies, or altering role trust policies, the attacker establishes persistent access to the AWS environment.
6. Privilege Escalation: The newly created or modified IAM entities grant the attacker higher-level permissions than their initial access, allowing them to expand control.
7. Impact: The attacker proceeds to achieve their ultimate objective, which could include data exfiltration, resource manipulation, infrastructure disruption, or cryptomining, leveraging their escalated privileges.

Impact

Successful exploitation of temporary session token abuse can lead to severe consequences for an AWS environment. Attackers can establish persistent access by creating new backdoor users or modifying existing IAM policies, enabling continued unauthorized operations. They can escalate privileges to gain control over critical resources, disable security mechanisms like MFA for other accounts, and exfiltrate sensitive data or deploy malicious resources such as cryptominers. The primary impact includes unauthorized data access, resource compromise, and potential financial losses due to resource misuse or regulatory fines stemming from data breaches.

Recommendation

• Deploy the Sigma rule "AWS IAM API Calls via Temporary Session Tokens" to your SIEM and tune for your environment to detect unusual IAM API calls via temporary session tokens.
• Enable AWS CloudTrail logging for all management events and data events, ensuring iam.amazonaws.com events are captured for detection by the provided Sigma rule.
• Review aws.cloudtrail.user_identity.arn and aws.cloudtrail.user_identity.type fields for any alerts generated by the Sigma rule to identify the originating user or role.
• Examine aws.cloudtrail.user_identity.session_context.mfa_authenticated when investigating alerts, as an absence of MFA authentication may indicate token misuse.
• Inspect source.ip and user_agent.original for any detected activity to identify unexpected origins or tools.
• If unauthorized activity is confirmed, immediately revoke the temporary session by invalidating the associated IAM credentials as described in the investigation guide.
• Require MFA for all privileged actions using aws:MultiFactorAuthPresent conditions in IAM policies to prevent future abuse of compromised credentials.