AWS IAM API Calls via Temporary Session Tokens
Detects use of sensitive AWS IAM API operations using temporary credentials (session tokens starting with 'ASIA'). This may indicate credential theft or abuse of elevated access via a stolen session. It is not common for legitimate users to perform sensitive IAM operations with temporary session tokens.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2025/04/16"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2025/07/10"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects use of sensitive AWS IAM API operations using temporary credentials (session tokens starting with 'ASIA'). This may indicate credential theft or abuse of elevated access via a stolen session. It is not common for legitimate users to perform sensitive IAM operations with temporary session tokens.
11"""
12false_positives = [
13 """
14 Some CI/CD pipelines or administrative users may use session tokens. Review user context, IP, and timing to validate.
15 """,
16]
17from = "now-6m"
18index = ["filebeat-*", "logs-aws.cloudtrail-*"]
19language = "kuery"
20license = "Elastic License v2"
21name = "AWS IAM API Calls via Temporary Session Tokens"
22note = """
23## Triage and analysis
24
25### Investigating AWS IAM API Calls via Temporary Session Tokens
26
27This rule detects sensitive IAM API operations performed using temporary AWS credentials (session tokens starting with 'ASIA'). These are short-lived credentials commonly obtained via sts:GetSessionToken, sts:AssumeRole, or AWS SSO login. While temporary credentials are often used for development and automation, they are rarely associated with direct IAM manipulation and may indicate credential theft, privilege escalation, or abuse of developer access.
28
29#### Possible investigation steps:
30
31- Review `aws.cloudtrail.user_identity.arn` to determine which IAM user or assumed role initiated the request.
32- Check `aws.cloudtrail.user_identity.access_key_id` to confirm if the credential starts with 'ASIA', indicating a temporary session token.
33- Examine `aws.cloudtrail.user_identity.session_context.mfa_authenticated` to verify whether MFA was present during session creation.
34- Investigate `source.ip` to assess whether the request originated from a known network, office IP, or corporate VPN.
35- Look at `user_agent.original` to determine if the API call came from a known CLI version or unexpected tool (e.g., unknown SDK, custom script).
36- Confirm whether a recent sts:GetSessionToken, sts:AssumeRole, or AWS SSO login event issued the temporary credential.
37- Correlate other events using the same access key ID to identify additional privileged actions, such as iam:CreateAccessKey, iam:PutUserPolicy, or iam:EnableMFADevice.
38- Analyze timing via @timestamp to determine if the action occurred during off-hours or deviates from normal user behavior.
39- Review the `event.outcome` to check if the API call was successful or failed, which may indicate unauthorized access attempts.
40- Check for related events in the same session, such as iam:CreateUser, iam:AttachUserPolicy, or sts:GetCallerIdentity, to identify potential lateral movement or privilege escalation.
41
42### False positive analysis:
43
44- Determine if the IAM user or automation pipeline routinely performs privileged actions using temporary session tokens.
45- Validate whether the MFA context and source IP match expected developer or CI/CD behavior.
46- Review recent IAM policy changes or deployments that may explain the behavior.
47- Confirm if the user has a legitimate reason to perform sensitive IAM operations with temporary credentials, such as during a deployment or maintenance window.
48
49### Response and remediation:
50
51- Revoke the temporary session token and rotate long-term access keys for the associated user if the behavior is unauthorized.
52- Audit related CloudTrail events within the same session to identify policy changes, resource creation, or lateral movement.
53- Add explicit deny statements in IAM policies to prevent sensitive IAM actions when aws:authType is not "console".
54- Implement IP restrictions for IAM and STS API actions using aws:SourceIp conditions.
55- Strengthen monitoring for IAM activity initiated by session tokens with MFA to improve detection coverage.
56"""
57
58references = ["https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/"]
59risk_score = 21
60rule_id = "c70d9f0d-8cb6-4cfc-85df-a95c1ccf4eab"
61severity = "low"
62tags = [
63 "Domain: Cloud",
64 "Data Source: AWS",
65 "Data Source: Amazon Web Services",
66 "Data Source: AWS CloudTrail",
67 "Data Source: AWS IAM",
68 "Data Source: AWS STS",
69 "Tactic: Persistence",
70 "Tactic: Privilege Escalation",
71 "Resources: Investigation Guide"
72]
73timestamp_override = "event.ingested"
74type = "new_terms"
75
76query = '''
77event.dataset: aws.cloudtrail
78 and event.provider: ("iam.amazonaws.com")
79 and event.outcome: "success"
80 and aws.cloudtrail.user_identity.type: "IAMUser"
81 and aws.cloudtrail.user_identity.access_key_id: ASIA*
82'''
83
84[rule.investigation_fields]
85field_names = [
86 "@timestamp",
87 "user.name",
88 "user_agent.original",
89 "source.ip",
90 "aws.cloudtrail.user_identity.arn",
91 "aws.cloudtrail.user_identity.type",
92 "aws.cloudtrail.user_identity.access_key_id",
93 "event.action",
94 "event.outcome",
95 "cloud.account.id",
96 "cloud.region",
97 "aws.cloudtrail.request_parameters"
98]
99
100[[rule.threat]]
101framework = "MITRE ATT&CK"
102
103[[rule.threat.technique]]
104id = "T1098"
105name = "Account Manipulation"
106reference = "https://attack.mitre.org/techniques/T1098/"
107
108[rule.threat.tactic]
109id = "TA0003"
110name = "Persistence"
111reference = "https://attack.mitre.org/tactics/TA0003/"
112
113[rule.new_terms]
114field = "new_terms_fields"
115value = ["aws.cloudtrail.user_identity.arn"]
116[[rule.new_terms.history_window_start]]
117field = "history_window_start"
118value = "now-14d"
Triage and analysis
Investigating AWS IAM API Calls via Temporary Session Tokens
This rule detects sensitive IAM API operations performed using temporary AWS credentials (session tokens starting with 'ASIA'). These are short-lived credentials commonly obtained via sts:GetSessionToken, sts:AssumeRole, or AWS SSO login. While temporary credentials are often used for development and automation, they are rarely associated with direct IAM manipulation and may indicate credential theft, privilege escalation, or abuse of developer access.
Possible investigation steps:
- Review
aws.cloudtrail.user_identity.arn
to determine which IAM user or assumed role initiated the request. - Check
aws.cloudtrail.user_identity.access_key_id
to confirm if the credential starts with 'ASIA', indicating a temporary session token. - Examine
aws.cloudtrail.user_identity.session_context.mfa_authenticated
to verify whether MFA was present during session creation. - Investigate
source.ip
to assess whether the request originated from a known network, office IP, or corporate VPN. - Look at
user_agent.original
to determine if the API call came from a known CLI version or unexpected tool (e.g., unknown SDK, custom script). - Confirm whether a recent sts:GetSessionToken, sts:AssumeRole, or AWS SSO login event issued the temporary credential.
- Correlate other events using the same access key ID to identify additional privileged actions, such as iam:CreateAccessKey, iam:PutUserPolicy, or iam:EnableMFADevice.
- Analyze timing via @timestamp to determine if the action occurred during off-hours or deviates from normal user behavior.
- Review the
event.outcome
to check if the API call was successful or failed, which may indicate unauthorized access attempts. - Check for related events in the same session, such as iam:CreateUser, iam:AttachUserPolicy, or sts:GetCallerIdentity, to identify potential lateral movement or privilege escalation.
False positive analysis:
- Determine if the IAM user or automation pipeline routinely performs privileged actions using temporary session tokens.
- Validate whether the MFA context and source IP match expected developer or CI/CD behavior.
- Review recent IAM policy changes or deployments that may explain the behavior.
- Confirm if the user has a legitimate reason to perform sensitive IAM operations with temporary credentials, such as during a deployment or maintenance window.
Response and remediation:
- Revoke the temporary session token and rotate long-term access keys for the associated user if the behavior is unauthorized.
- Audit related CloudTrail events within the same session to identify policy changes, resource creation, or lateral movement.
- Add explicit deny statements in IAM policies to prevent sensitive IAM actions when aws:authType is not "console".
- Implement IP restrictions for IAM and STS API actions using aws:SourceIp conditions.
- Strengthen monitoring for IAM activity initiated by session tokens with MFA to improve detection coverage.
References
Related rules
- AWS IAM Virtual MFA Device Registration Attempt with Session Token
- AWS STS Role Assumption by Service
- AWS STS Role Assumption by User
- AWS IAM Create User via Assumed Role on EC2 Instance
- AWS IAM Group Creation