AWS IAM API Calls via Temporary Session Tokens

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