From 645a31fedc7c5b8e7a21b1ffd922c9480ba69a62 Mon Sep 17 00:00:00 2001 From: Isai <59296946+imays11@users.noreply.github.com> Date: Wed, 12 Nov 2025 17:10:46 -0500 Subject: [PATCH 1/2] [Rule Tuning] AWS IAM API Calls via Temporary Session Tokens Came across some false positives as I was rule testing. Temporary credentials are also created for AWS Internal operations and when an AWS service operates on your behalf. These both should be excluded from results. I saw this in my own testing, in prod data and in our alert telemetry. These cases can be excluded by looking for `source.ip:*` as this field is not populated for those internal AWS operations. NOTE: Another false positive instance has been highlighted in the investigation guide. A legitimate AWS console login session is given temporary (ASIA) credentials which are populated for all the operations performed during that session. The only way to distinguish between these events and other temporary session token events, like those granted via AssumeRole or GetSessionToken, is with a field populated as `sessionCredentialFromConsole: true`. Right now our Integration does not map this field and it can only be found in `event.original`. I am putting in an Integration request to populate this field, which we could then use to further reduce false positives for rules like this. - updated description , false positives, and investigation guide - added `source.ip:*` to query --- ..._iam_api_calls_via_user_session_token.toml | 154 ++++++++++++------ 1 file changed, 104 insertions(+), 50 deletions(-) diff --git a/rules/integrations/aws/persistence_iam_api_calls_via_user_session_token.toml b/rules/integrations/aws/persistence_iam_api_calls_via_user_session_token.toml index 8f7e341969e..62326b7793f 100644 --- a/rules/integrations/aws/persistence_iam_api_calls_via_user_session_token.toml +++ b/rules/integrations/aws/persistence_iam_api_calls_via_user_session_token.toml @@ -2,16 +2,22 @@ creation_date = "2025/04/16" integration = ["aws"] maturity = "production" -updated_date = "2025/07/10" +updated_date = "2025/11/12" [rule] author = ["Elastic"] description = """ -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. +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. """ false_positives = [ """ - Some CI/CD pipelines or administrative users may use session tokens. Review user context, IP, and timing to validate. + Some CI/CD pipelines or administrative users may use session tokens. Review user context, IP, and timing to + validate. 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" """, ] from = "now-6m" @@ -19,42 +25,86 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"] language = "kuery" license = "Elastic License v2" name = "AWS IAM API Calls via Temporary Session Tokens" -note = """ -## Triage and analysis +note = """## 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: +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. +> 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. -- 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: +### Investigating AWS IAM API Calls via Temporary Session Tokens -- 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. +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.arn` and `aws.cloudtrail.user_identity.type` to determine the originating user or role. + - 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. + - Examine `aws.cloudtrail.user_identity.session_context.mfa_authenticated` — absence of MFA may indicate token misuse. + +- **Analyze the API context** + - Review `event.action` and `aws.cloudtrail.request_parameters` for 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`, or `AWS SSO` events. + +- **Evaluate source and behavior** + - Inspect `source.ip` and `user_agent.original` for unexpected origins or tools. + - Check if the request came from known infrastructure (e.g., CI/CD nodes, bastion hosts) or an anomalous network. + - Compare `@timestamp` against normal operating hours or deployment schedules. + +- **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) + - If applicable, search for multiple users exhibiting similar patterns, a sign of large-scale token misuse. + +### 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 result in temporary "ASIA" credentials and can typically be ignored for this alert. This can be verified in `event.original` as `sessionCredentialFromConsole: true` + +### 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_id` to assess potential persistence or lateral movement. + - Examine the creation of new users, keys, or policies during or shortly after the detected session. + +- **Recovery and hardening** + - Require MFA for all privileged actions using `aws:MultiFactorAuthPresent` conditions. + - Implement detection coverage for follow-on persistence actions such as: + - `iam:CreateAccessKey` + - `iam:PutUserPolicy` + - `iam:UpdateAssumeRolePolicy` + - Educate administrative users and developers on secure token handling and the risks of shared credential reuse. + +### Additional information + +For more information on detecting and mitigating session token abuse: +- **[AWS Security Token Service (STS) Documentation](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html)** +- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** +- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** +- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/). """ - references = ["https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/"] risk_score = 21 rule_id = "c70d9f0d-8cb6-4cfc-85df-a95c1ccf4eab" @@ -68,7 +118,7 @@ tags = [ "Data Source: AWS STS", "Tactic: Persistence", "Tactic: Privilege Escalation", - "Resources: Investigation Guide" + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "new_terms" @@ -79,8 +129,23 @@ event.dataset: aws.cloudtrail and event.outcome: "success" and aws.cloudtrail.user_identity.type: "IAMUser" and aws.cloudtrail.user_identity.access_key_id: ASIA* + and source.ip: * ''' + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1098" +name = "Account Manipulation" +reference = "https://attack.mitre.org/techniques/T1098/" + + +[rule.threat.tactic] +id = "TA0003" +name = "Persistence" +reference = "https://attack.mitre.org/tactics/TA0003/" + [rule.investigation_fields] field_names = [ "@timestamp", @@ -94,25 +159,14 @@ field_names = [ "event.outcome", "cloud.account.id", "cloud.region", - "aws.cloudtrail.request_parameters" + "aws.cloudtrail.request_parameters", ] -[[rule.threat]] -framework = "MITRE ATT&CK" - -[[rule.threat.technique]] -id = "T1098" -name = "Account Manipulation" -reference = "https://attack.mitre.org/techniques/T1098/" - -[rule.threat.tactic] -id = "TA0003" -name = "Persistence" -reference = "https://attack.mitre.org/tactics/TA0003/" - [rule.new_terms] field = "new_terms_fields" value = ["aws.cloudtrail.user_identity.arn"] [[rule.new_terms.history_window_start]] field = "history_window_start" value = "now-14d" + + From 1aba16ee3cc05353412749c17fb9c3ba14b2a1c6 Mon Sep 17 00:00:00 2001 From: Isai <59296946+imays11@users.noreply.github.com> Date: Thu, 13 Nov 2025 13:22:23 -0500 Subject: [PATCH 2/2] excluding AWS Internal user agent excluding AWS Internal user agent --- .../aws/persistence_iam_api_calls_via_user_session_token.toml | 1 + 1 file changed, 1 insertion(+) diff --git a/rules/integrations/aws/persistence_iam_api_calls_via_user_session_token.toml b/rules/integrations/aws/persistence_iam_api_calls_via_user_session_token.toml index 62326b7793f..abd3df3748c 100644 --- a/rules/integrations/aws/persistence_iam_api_calls_via_user_session_token.toml +++ b/rules/integrations/aws/persistence_iam_api_calls_via_user_session_token.toml @@ -130,6 +130,7 @@ event.dataset: aws.cloudtrail and aws.cloudtrail.user_identity.type: "IAMUser" and aws.cloudtrail.user_identity.access_key_id: ASIA* and source.ip: * + and not user_agent.original : "AWS Internal" '''