AWS IAM API Calls via Temporary Session Tokens

  1[metadata]
  2creation_date = "2025/04/16"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2025/11/12"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects sensitive AWS IAM API operations executed using temporary session credentials (access key IDs beginning with
 11"ASIA"). Temporary credentials are commonly issued through sts:GetSessionToken, sts:AssumeRole, or AWS SSO logins and
 12are meant for short-term use. It is unusual for legitimate users or automated processes to perform privileged IAM
 13actions (e.g., creating users, updating policies, or enabling/disabling MFA) with session tokens. This behavior may
 14indicate credential theft, session hijacking, or the abuse of a privileged role’s temporary credentials.
 15"""
 16false_positives = [
 17    """
 18    Some CI/CD pipelines or administrative users may use session tokens. Review user context, IP, and timing to
 19    validate. Console login sessions result in temporary "ASIA" credentials and can typically be ignored for this alert.
 20    This can be verified in "event.original" as "sessionCredentialFromConsole: true"
 21    """,
 22]
 23from = "now-6m"
 24index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 25language = "kuery"
 26license = "Elastic License v2"
 27name = "AWS IAM API Calls via Temporary Session Tokens"
 28note = """## Triage and analysis
 29
 30> **Disclaimer**:
 31> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. 
 32> While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 33
 34### Investigating AWS IAM API Calls via Temporary Session Tokens
 35
 36Temporary session credentials in AWS (identified by access keys beginning with "ASIA") are typically short-lived tokens 
 37issued by the AWS Security Token Service (STS). While they are legitimate and often used by developers or automation pipelines, 
 38their use in direct IAM management or privilege modification is highly unusual and may indicate credential misuse.
 39
 40Attackers who compromise IAM users, roles, or federated identities can obtain session tokens to blend in with normal operations. 
 41They may then execute sensitive IAM API actions such as `CreateAccessKey`, `PutUserPolicy`, or `UpdateAssumeRolePolicy` to 
 42establish persistence, escalate privileges, or disable protections.
 43
 44#### Possible investigation steps
 45
 46- **Identify the actor**
 47  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine the originating user or role.
 48  - Check `event.original` if ingested, look for `sessionCredentialFromConsole: true`. If this is present, the temporary session token was created as part of a legitimate console login session and this alert can be ignored. 
 49  - Examine `aws.cloudtrail.user_identity.session_context.mfa_authenticated` — absence of MFA may indicate token misuse.
 50
 51- **Analyze the API context**
 52  - Review `event.action` and `aws.cloudtrail.request_parameters` for the exact IAM operation performed.
 53  - Identify whether the action modifies roles, user policies, trust relationships, or credentials.
 54  - Determine if this session token was associated with prior `sts:GetSessionToken`, `sts:AssumeRole`, or `AWS SSO` events.
 55
 56- **Evaluate source and behavior**
 57  - Inspect `source.ip` and `user_agent.original` for unexpected origins or tools.
 58  - Check if the request came from known infrastructure (e.g., CI/CD nodes, bastion hosts) or an anomalous network.
 59  - Compare `@timestamp` against normal operating hours or deployment schedules.
 60
 61- **Correlate related activity**
 62  - Look for subsequent or preceding activity using the same access key:
 63    - IAM changes (`CreateUser`, `AttachUserPolicy`, `EnableMFADevice`)
 64    - STS operations (`AssumeRole`, `GetCallerIdentity`)
 65    - CloudTrail or GuardDuty configuration changes (possible defense evasion)
 66  - If applicable, search for multiple users exhibiting similar patterns, a sign of large-scale token misuse.
 67
 68### False positive analysis
 69
 70- **Expected automation**
 71  - Some CI/CD pipelines, monitoring tools, or AWS SDK-based automation may perform IAM operations using temporary credentials.
 72  - Validate whether the IAM user or assumed role performing these actions belongs to an authorized automation workflow.
 73- **Administrative operations**
 74  - Security or DevOps engineers may temporarily use session credentials for maintenance or testing.
 75  - Cross-reference with recent change tickets or known operations schedules.
 76- **Federated identity scenarios**
 77  - Federated logins (via AWS SSO or external IdPs) can also generate temporary "ASIA" credentials. Verify if the source identity 
 78    aligns with expected roles or groups.
 79- **Console Login Session**
 80  - Console login sessions result in temporary "ASIA" credentials and can typically be ignored for this alert. This can be verified in `event.original` as `sessionCredentialFromConsole: true`
 81
 82### Response and remediation
 83
 84- **Containment**
 85  - If activity is unauthorized, immediately revoke the temporary session by invalidating the associated IAM credentials.
 86  - Rotate long-term credentials (access keys, passwords) for the parent IAM user or role.
 87
 88- **Investigation**
 89  - Search for all actions linked to the same `access_key_id` to assess potential persistence or lateral movement.
 90  - Examine the creation of new users, keys, or policies during or shortly after the detected session.
 91
 92- **Recovery and hardening**
 93  - Require MFA for all privileged actions using `aws:MultiFactorAuthPresent` conditions.
 94  - Implement detection coverage for follow-on persistence actions such as:
 95    - `iam:CreateAccessKey`
 96    - `iam:PutUserPolicy`
 97    - `iam:UpdateAssumeRolePolicy`
 98  - Educate administrative users and developers on secure token handling and the risks of shared credential reuse.
 99
100### Additional information
101
102For more information on detecting and mitigating session token abuse:
103- **[AWS Security Token Service (STS) Documentation](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html)**
104- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
105- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
106- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
107"""
108references = ["https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/"]
109risk_score = 21
110rule_id = "c70d9f0d-8cb6-4cfc-85df-a95c1ccf4eab"
111severity = "low"
112tags = [
113    "Domain: Cloud",
114    "Data Source: AWS",
115    "Data Source: Amazon Web Services",
116    "Data Source: AWS CloudTrail",
117    "Data Source: AWS IAM",
118    "Data Source: AWS STS",
119    "Tactic: Persistence",
120    "Tactic: Privilege Escalation",
121    "Resources: Investigation Guide",
122]
123timestamp_override = "event.ingested"
124type = "new_terms"
125
126query = '''
127event.dataset: aws.cloudtrail
128    and event.provider: ("iam.amazonaws.com")
129    and event.outcome: "success"
130    and aws.cloudtrail.user_identity.type: "IAMUser"
131    and aws.cloudtrail.user_identity.access_key_id: ASIA*
132    and source.ip: *
133    and not user_agent.original : "AWS Internal"
134'''
135
136
137[[rule.threat]]
138framework = "MITRE ATT&CK"
139[[rule.threat.technique]]
140id = "T1098"
141name = "Account Manipulation"
142reference = "https://attack.mitre.org/techniques/T1098/"
143
144
145[rule.threat.tactic]
146id = "TA0003"
147name = "Persistence"
148reference = "https://attack.mitre.org/tactics/TA0003/"
149
150[rule.investigation_fields]
151field_names = [
152    "@timestamp",
153    "user.name",
154    "user_agent.original",
155    "source.ip",
156    "aws.cloudtrail.user_identity.arn",
157    "aws.cloudtrail.user_identity.type",
158    "aws.cloudtrail.user_identity.access_key_id",
159    "event.action",
160    "event.outcome",
161    "cloud.account.id",
162    "cloud.region",
163    "aws.cloudtrail.request_parameters",
164]
165
166[rule.new_terms]
167field = "new_terms_fields"
168value = ["aws.cloudtrail.user_identity.arn"]
169[[rule.new_terms.history_window_start]]
170field = "history_window_start"
171value = "now-14d"