diff --git a/rules/integrations/aws/impact_iam_deactivate_mfa_device.toml b/rules/integrations/aws/impact_iam_deactivate_mfa_device.toml index 39e4c59dd49..5107ec413f0 100644 --- a/rules/integrations/aws/impact_iam_deactivate_mfa_device.toml +++ b/rules/integrations/aws/impact_iam_deactivate_mfa_device.toml @@ -2,70 +2,94 @@ creation_date = "2020/05/26" integration = ["aws"] maturity = "production" -updated_date = "2024/10/25" +updated_date = "2025/11/03" [rule] author = ["Elastic", "Austin Songer"] description = """ -Identifies the deactivation of a specified multi-factor authentication (MFA) device and removes it from association with -the user name for which it was originally enabled. In AWS Identity and Access Management (IAM), a device must be -deactivated before it can be deleted. +Detects the deactivation of a Multi-Factor Authentication (MFA) device in AWS Identity and Access Management (IAM). MFA +provides critical protection against unauthorized access by requiring a second factor for authentication. Adversaries or +compromised administrators may deactivate MFA devices to weaken account protections, disable strong authentication, or +prepare for privilege escalation or persistence. This rule monitors successful DeactivateMFADevice API calls, which +represent the point at which MFA protection is actually removed. """ false_positives = [ """ - A MFA device may be deactivated by a system or network administrator. Verify whether the user identity, user agent, - and/or hostname should be making changes in your environment. MFA device deactivations from unfamiliar users or - hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule. + MFA device deactivation may occur legitimately during device rotation, user offboarding, or troubleshooting. For + example, AWS requires deactivation of an existing MFA device before adding a replacement. These actions are often + performed by administrators following approved change-control processes. To reduce false positives, validate whether + the deactivation aligns with a documented workflow, known device replacement, or expected maintenance window. If + performed outside of expected operational hours, by an unexpected user, or from an unfamiliar source IP, this event + should be investigated for potential credential compromise or unauthorized tampering. """, ] -from = "now-60m" +from = "now-6m" index = ["filebeat-*", "logs-aws.cloudtrail-*"] -interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS IAM Deactivation of MFA Device" note = """## Triage and analysis +> **Disclaimer**: +> This investigation guide was created using generative AI technology and validated for accuracy and relevance. Always +> tailor the steps to your organization's environment and operational context. + ### Investigating AWS IAM Deactivation of MFA Device -Multi-factor authentication (MFA) in AWS is a simple best practice that adds an extra layer of protection on top of your user name and password. With MFA enabled, when a user signs in to an AWS Management Console, they will be prompted for their user name and password (the first factor—what they know), as well as for an authentication code from their AWS MFA device (the second factor—what they have). Taken together, these multiple factors provide increased security for your AWS account settings and resources. +This rule detects successful deactivation of a Virtual MFA device in AWS IAM. +Deactivation removes MFA enforcement from an IAM user, significantly lowering account resilience against credential theft or unauthorized access. +Since MFA devices must be deactivated before deletion, this represents the earliest and most critical opportunity to detect potential account compromise or persistence activity. For more information about using MFA in AWS, access the [official documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html). -This rule looks for the deactivation or deletion of AWS MFA devices. These modifications weaken account security and can lead to the compromise of accounts and other assets. - #### Possible investigation steps -- Identify the user account that performed the action and whether it should perform this kind of action. -- Investigate other alerts associated with the user account during the past 48 hours. -- Contact the account and resource owners and confirm whether they are aware of this activity. -- Check if this operation was approved and performed according to the organization's change management policy. -- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the deactivation. + - Check whether the actor typically manages MFA or has the IAM permissions to perform such actions. + - Review `user_agent.original` to confirm if the operation was performed via the AWS Console, CLI, or SDK. + +- **Review the source and location** + - Investigate `source.ip` and `source.geo` fields for unusual origins or unrecognized locations. + - Determine if this request originated from known automation infrastructure, internal IP ranges, or a personal endpoint. + +- **Correlate with other related activity** + - Look for preceding API calls such as `ListMFADevices`, `GetSessionToken`, or `ListUsers`, which may indicate reconnaissance or IAM enumeration. + - Search for subsequent `DeleteVirtualMFADevice` calls to confirm whether the deactivated device was later deleted — a common follow-up action. + - Check for any privilege changes, credential creations (`CreateAccessKey`, `AttachUserPolicy`), or unexpected login attempts following the deactivation. + +- **Validate authorization** + - Confirm with IAM or security administrators whether the action was part of an authorized device rotation or remediation. + - If not documented or approved, escalate as a potential credential compromise or persistence attempt. ### False positive analysis -- While this activity can be done by administrators, all users must use MFA. The security team should address any potential benign true positive (B-TP), as this configuration can risk the user and domain. +- **Legitimate device rotation** + - When replacing an MFA device, AWS requires deactivation of the existing device before the new one can be enabled. +- **Administrative maintenance** + - IAM administrators or automation pipelines may deactivate MFA as part of account management or recovery workflows. ### Response and remediation -- Initiate the incident response process based on the outcome of the triage. -- Disable or limit the account during the investigation and response. -- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: - - Identify the account role in the cloud environment. - - Assess the criticality of affected services and servers. - - Work with your IT team to identify and minimize the impact on users. - - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. - - Identify any regulatory or legal ramifications related to this activity. -- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. -- Reactivate multi-factor authentication for the user. -- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. -- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. -- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). - -## Setup - -The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" +- **Containment** + - Re-enable MFA for the affected IAM user (`EnableMFADevice`) or temporarily disable their login access until legitimacy is confirmed. + - Revoke temporary credentials or tokens associated with the actor to prevent further misuse. + +- **Investigation and scoping** + - Review CloudTrail history for additional IAM configuration changes or access key creation events tied to the same principal. + - Determine whether sensitive resources were accessed after MFA removal. + - Identify whether multiple users had MFA devices deactivated in a short timeframe — an indicator of broader compromise. + +- **Recovery and hardening** + - Require MFA for all privileged IAM users and enforce it using service control policies (SCPs). + - Enable GuardDuty or Security Hub findings for IAM anomaly detection related to account takeover or configuration changes. + +### Additional information +- **[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)** +- **[DeactivateMFADevice API Reference](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html)** +- **[Managing MFA Devices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)** +""" references = [ "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/deactivate-mfa-device.html", "https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html", @@ -77,6 +101,7 @@ tags = [ "Domain: Cloud", "Data Source: AWS", "Data Source: Amazon Web Services", + "Data Source: AWS CloudTrail", "Data Source: AWS IAM", "Resources: Investigation Guide", "Tactic: Impact", @@ -86,7 +111,10 @@ timestamp_override = "event.ingested" type = "query" query = ''' -event.dataset:aws.cloudtrail and event.provider:iam.amazonaws.com and event.action:(DeactivateMFADevice or DeleteVirtualMFADevice) and event.outcome:success +event.dataset: aws.cloudtrail + and event.provider: iam.amazonaws.com + and event.action: DeactivateMFADevice + and event.outcome: success ''' @@ -114,7 +142,26 @@ name = "Multi-Factor Authentication" reference = "https://attack.mitre.org/techniques/T1556/006/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "target.entity.id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters", +] + diff --git a/rules/integrations/aws/persistence_aws_attempt_to_register_virtual_mfa_device.toml b/rules/integrations/aws/persistence_aws_attempt_to_register_virtual_mfa_device.toml index b1a49540d9f..045e926d2db 100644 --- a/rules/integrations/aws/persistence_aws_attempt_to_register_virtual_mfa_device.toml +++ b/rules/integrations/aws/persistence_aws_attempt_to_register_virtual_mfa_device.toml @@ -2,50 +2,101 @@ creation_date = "2025/04/11" integration = ["aws"] maturity = "production" -updated_date = "2025/04/15" +updated_date = "2025/11/03" [rule] author = ["Elastic"] description = """ -Identifies attempts to register or enable an IAM Virtual MFA device using temporary credentials (access keys -starting with 'ASIA'). This may indicate an adversary attempting to escalate privileges or establish persistence using -stolen session tokens. +Detects attempts to create or enable a Virtual MFA device (CreateVirtualMFADevice, EnableMFADevice) using temporary AWS +credentials (access keys beginning with ASIA). Session credentials are short-lived and tied to existing authenticated +sessions, so using them to register or enable MFA devices is unusual. Adversaries who compromise temporary credentials +may abuse this behavior to establish persistence by attaching new MFA devices to maintain access to high-privilege +accounts despite key rotation or password resets. """ false_positives = [ """ - Legitimate users or automation tools may register MFA devices using temporary session credentials, especially in - CI/CD or administrative workflows. Validate the source IP, user agent, and context of the registration. + Some legitimate administrative workflows or CI/CD automation pipelines may temporarily configure or re-enable MFA + devices using session-based credentials. Validate the calling identity’s purpose, source IP, and user agent to + confirm whether this activity was authorized. Additionally, when a user creates or enables a Virtual MFA device + through the AWS Management Console, the underlying CloudTrail event will also show a temporary credential (access + key ID beginning with ASIA), because the console itself issues short-lived STS session credentials for every + logged-in user. These events are expected and should not be considered suspicious. """, ] -from = "now-9m" +from = "now-6m" index = ["filebeat-*", "logs-aws.cloudtrail-*"] -language = "kuery" +language = "eql" license = "Elastic License v2" name = "AWS IAM Virtual MFA Device Registration Attempt with Session Token" note = """## Triage and Analysis -### Investigating AWS IAM Virtual MFA Device Registration Attempt with Session Token - -AWS temporary security credentials that begin with `ASIA` indicate they are session tokens. An attempt to create or enable a Virtual MFA device using such credentials is uncommon and may indicate malicious activity. - -#### Possible Investigation Steps - -- **Identify the User**: Check `user.name`, `user.arn`, and `aws.cloudtrail.user_identity.*` fields to determine which IAM entity made the request. -- **Check for Prior Reconnaissance or Access**: Correlate this event with any prior calls to `GetSessionToken`, `GetCallerIdentity`, or `ListUsers` to see if an adversary was enumerating IAM users. -- **Source Context**: Review `source.ip`, `user_agent`, and `event.origin` to determine whether this came from a legitimate device or a suspicious endpoint (e.g., Kali, Mythic, unknown VPN). -- **Validate MFA Setup**: Look for follow-up attempts to call `sts:get-session-token` or `iam:EnableMFADevice` using this same session. +> **Disclaimer**: +> This investigation guide was created using generative AI technology and validated for accuracy and relevance. Always +> tailor the steps to your organization's environment and operational context. -### False Positive Analysis - -- This may occur if an admin or automation tool is legitimately setting up a new MFA device using temporary credentials. -- Review the IP, agent, and context to differentiate expected automation from unauthorized access. - -### Response and Remediation +### Investigating AWS IAM Virtual MFA Device Registration Attempt with Session Token -- **Revoke Credentials**: If unauthorized, revoke the access keys or terminate the session. -- **Reset MFA and Passwords**: Rotate credentials for the affected IAM user. -- **Review IAM Policies**: Limit permissions to register MFA devices to trusted roles only. -- **Enable CloudTrail Alerts**: Monitor IAM changes more broadly with CloudTrail-based alerts. +Temporary credentials that start with the prefix `ASIA` are generated by the AWS Security Token Service (STS). These +session tokens are used for short-lived operations and should not be used to modify or register IAM +authentication mechanisms. This rule detects cases where an IAM user or role uses such temporary credentials to invoke either `CreateVirtualMFADevice` or `EnableMFADevice`. + +#### Possible investigation steps + +- **Identify the actor and session context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine the identity and confirm the `ASIA` prefix. + - If you ingest `event.original`, look for `sessionCredentialFromConsole: true` to determine if the temporary token is from a console login session (which uses temporary session tokens in the backend) rather than compromised session tokens. + - Check `user_agent.original`, `source.ip`, and `cloud.region` to determine if this activity originated from an expected host, VPN, or location. + - Cross-reference with prior activity by this identity—especially `GetSessionToken`, `AssumeRole`, or `GetCallerIdentity` calls. + +- **Correlate related IAM events** + - Search for subsequent or preceding calls to: + - `EnableMFADevice` (after `CreateVirtualMFADevice`) + - `DeactivateMFADevice` or `DeleteVirtualMFADevice` + - `ListMFADevices`, `ListUsers`, or `UpdateLoginProfile` + - Review whether new MFA devices were successfully enabled (`event.outcome:success`). + +- **Assess session scope and privileges** + - Identify what IAM policies are attached to the user or role that issued this request. + - If the temporary credentials were created via `AssumeRole` or `GetSessionToken`, check the originating principal’s permissions. + +- **Investigate possible persistence** + - Look for new MFA devices listed for privileged users (e.g., account root or admin roles). + - Review login history for those accounts following the MFA change. + +### False positive analysis + +- **Legitimate Administrative or Automated Actions** + Certain IAM administrative workflows or CI/CD automation tools may register or enable MFA devices using temporary + session credentials. Confirm whether the calling principal is part of an authorized automation process or a known + identity performing account configuration tasks. + +- **Expected Console Behavior** + When users create or enable Virtual MFA devices through the **AWS Management Console**, AWS automatically issues + temporary STS credentials (with access key IDs beginning with `ASIA`) for that session. As a result, these events will + appear identical to programmatic usage of session tokens in CloudTrail logs. + This is expected and does not indicate compromise. + +### Response and remediation + +- **Immediate containment** + - Revoke or expire the temporary credentials (`aws sts revoke-session` if applicable). + - Disable or delete any newly created virtual MFA devices using `DeleteVirtualMFADevice`. + - Rotate passwords and long-term access keys for the associated IAM users. + +- **Investigation and scoping** + - Review CloudTrail logs for related IAM modifications (`UpdateLoginProfile`, `AttachUserPolicy`, `CreateAccessKey`). + - Identify any new API keys or tokens created after the MFA registration. + - Cross-check whether the attacker leveraged the new MFA binding for session persistence or login. + +- **Recovery and hardening** + - Enforce the `iam:EnableMFADevice` and `iam:CreateVirtualMFADevice` permissions only for trusted admin roles. + - Implement `aws:MultiFactorAuthPresent` conditions in IAM policies. + - Monitor for any future `ASIA` credential–based IAM configuration changes. + +### Additional information +- **[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)** +- **[Managing MFA Devices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)** """ references = ["https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/"] risk_score = 47 @@ -62,13 +113,14 @@ tags = [ "Resources: Investigation Guide", ] timestamp_override = "event.ingested" -type = "query" +type = "eql" query = ''' -event.dataset: "aws.cloudtrail" - and event.provider: "iam.amazonaws.com" - and event.action: ("CreateVirtualMFADevice" or "EnableMFADevice") - and aws.cloudtrail.user_identity.access_key_id: ASIA* +iam where event.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + and event.outcome == "success" + and event.action in ("CreateVirtualMFADevice", "EnableMFADevice") + and startsWith (aws.cloudtrail.user_identity.access_key_id, "ASIA") ''' @@ -84,9 +136,36 @@ name = "Device Registration" reference = "https://attack.mitre.org/techniques/T1098/005/" +[[rule.threat.technique]] +id = "T1556" +name = "Modify Authentication Process" +reference = "https://attack.mitre.org/techniques/T1556/" +[[rule.threat.technique.subtechnique]] +id = "T1556.006" +name = "Multi-Factor Authentication" +reference = "https://attack.mitre.org/techniques/T1556/006/" + + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements", +] +