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