AWS IAM Deactivation of MFA Device
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.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/05/26"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2025/11/03"
6
7[rule]
8author = ["Elastic", "Austin Songer"]
9description = """
10Detects the deactivation of a Multi-Factor Authentication (MFA) device in AWS Identity and Access Management (IAM). MFA
11provides critical protection against unauthorized access by requiring a second factor for authentication. Adversaries or
12compromised administrators may deactivate MFA devices to weaken account protections, disable strong authentication, or
13prepare for privilege escalation or persistence. This rule monitors successful DeactivateMFADevice API calls, which
14represent the point at which MFA protection is actually removed.
15"""
16false_positives = [
17 """
18 MFA device deactivation may occur legitimately during device rotation, user offboarding, or troubleshooting. For
19 example, AWS requires deactivation of an existing MFA device before adding a replacement. These actions are often
20 performed by administrators following approved change-control processes. To reduce false positives, validate whether
21 the deactivation aligns with a documented workflow, known device replacement, or expected maintenance window. If
22 performed outside of expected operational hours, by an unexpected user, or from an unfamiliar source IP, this event
23 should be investigated for potential credential compromise or unauthorized tampering.
24 """,
25]
26from = "now-6m"
27index = ["filebeat-*", "logs-aws.cloudtrail-*"]
28language = "kuery"
29license = "Elastic License v2"
30name = "AWS IAM Deactivation of MFA Device"
31note = """## Triage and analysis
32
33> **Disclaimer**:
34> This investigation guide was created using generative AI technology and validated for accuracy and relevance. Always
35> tailor the steps to your organization's environment and operational context.
36
37### Investigating AWS IAM Deactivation of MFA Device
38
39This rule detects successful deactivation of a Virtual MFA device in AWS IAM.
40Deactivation removes MFA enforcement from an IAM user, significantly lowering account resilience against credential theft or unauthorized access.
41Since MFA devices must be deactivated before deletion, this represents the earliest and most critical opportunity to detect potential account compromise or persistence activity.
42
43For more information about using MFA in AWS, access the [official documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html).
44
45#### Possible investigation steps
46
47- **Identify the actor and context**
48 - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the deactivation.
49 - Check whether the actor typically manages MFA or has the IAM permissions to perform such actions.
50 - Review `user_agent.original` to confirm if the operation was performed via the AWS Console, CLI, or SDK.
51
52- **Review the source and location**
53 - Investigate `source.ip` and `source.geo` fields for unusual origins or unrecognized locations.
54 - Determine if this request originated from known automation infrastructure, internal IP ranges, or a personal endpoint.
55
56- **Correlate with other related activity**
57 - Look for preceding API calls such as `ListMFADevices`, `GetSessionToken`, or `ListUsers`, which may indicate reconnaissance or IAM enumeration.
58 - Search for subsequent `DeleteVirtualMFADevice` calls to confirm whether the deactivated device was later deleted — a common follow-up action.
59 - Check for any privilege changes, credential creations (`CreateAccessKey`, `AttachUserPolicy`), or unexpected login attempts following the deactivation.
60
61- **Validate authorization**
62 - Confirm with IAM or security administrators whether the action was part of an authorized device rotation or remediation.
63 - If not documented or approved, escalate as a potential credential compromise or persistence attempt.
64
65### False positive analysis
66
67- **Legitimate device rotation**
68 - When replacing an MFA device, AWS requires deactivation of the existing device before the new one can be enabled.
69- **Administrative maintenance**
70 - IAM administrators or automation pipelines may deactivate MFA as part of account management or recovery workflows.
71
72### Response and remediation
73
74- **Containment**
75 - Re-enable MFA for the affected IAM user (`EnableMFADevice`) or temporarily disable their login access until legitimacy is confirmed.
76 - Revoke temporary credentials or tokens associated with the actor to prevent further misuse.
77
78- **Investigation and scoping**
79 - Review CloudTrail history for additional IAM configuration changes or access key creation events tied to the same principal.
80 - Determine whether sensitive resources were accessed after MFA removal.
81 - Identify whether multiple users had MFA devices deactivated in a short timeframe — an indicator of broader compromise.
82
83- **Recovery and hardening**
84 - Require MFA for all privileged IAM users and enforce it using service control policies (SCPs).
85 - Enable GuardDuty or Security Hub findings for IAM anomaly detection related to account takeover or configuration changes.
86
87### Additional information
88- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**
89- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)**
90- **[DeactivateMFADevice API Reference](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html)**
91- **[Managing MFA Devices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)**
92"""
93references = [
94 "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/deactivate-mfa-device.html",
95 "https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html",
96]
97risk_score = 47
98rule_id = "d8fc1cca-93ed-43c1-bbb6-c0dd3eff2958"
99severity = "medium"
100tags = [
101 "Domain: Cloud",
102 "Data Source: AWS",
103 "Data Source: Amazon Web Services",
104 "Data Source: AWS CloudTrail",
105 "Data Source: AWS IAM",
106 "Resources: Investigation Guide",
107 "Tactic: Impact",
108 "Tactic: Persistence",
109]
110timestamp_override = "event.ingested"
111type = "query"
112
113query = '''
114event.dataset: aws.cloudtrail
115 and event.provider: iam.amazonaws.com
116 and event.action: DeactivateMFADevice
117 and event.outcome: success
118'''
119
120
121[[rule.threat]]
122framework = "MITRE ATT&CK"
123[[rule.threat.technique]]
124id = "T1531"
125name = "Account Access Removal"
126reference = "https://attack.mitre.org/techniques/T1531/"
127
128
129[rule.threat.tactic]
130id = "TA0040"
131name = "Impact"
132reference = "https://attack.mitre.org/tactics/TA0040/"
133[[rule.threat]]
134framework = "MITRE ATT&CK"
135[[rule.threat.technique]]
136id = "T1556"
137name = "Modify Authentication Process"
138reference = "https://attack.mitre.org/techniques/T1556/"
139[[rule.threat.technique.subtechnique]]
140id = "T1556.006"
141name = "Multi-Factor Authentication"
142reference = "https://attack.mitre.org/techniques/T1556/006/"
143
144
145
146[rule.threat.tactic]
147id = "TA0003"
148name = "Persistence"
149reference = "https://attack.mitre.org/tactics/TA0003/"
150
151[rule.investigation_fields]
152field_names = [
153 "@timestamp",
154 "user.name",
155 "user_agent.original",
156 "source.ip",
157 "aws.cloudtrail.user_identity.arn",
158 "aws.cloudtrail.user_identity.type",
159 "aws.cloudtrail.user_identity.access_key_id",
160 "target.entity.id",
161 "event.action",
162 "event.outcome",
163 "cloud.account.id",
164 "cloud.region",
165 "aws.cloudtrail.request_parameters",
166]
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
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.
Possible investigation steps
-
Identify the actor and context
- Review
aws.cloudtrail.user_identity.arnandaws.cloudtrail.user_identity.access_key_idto determine who initiated the deactivation. - Check whether the actor typically manages MFA or has the IAM permissions to perform such actions.
- Review
user_agent.originalto confirm if the operation was performed via the AWS Console, CLI, or SDK.
- Review
-
Review the source and location
- Investigate
source.ipandsource.geofields for unusual origins or unrecognized locations. - Determine if this request originated from known automation infrastructure, internal IP ranges, or a personal endpoint.
- Investigate
-
Correlate with other related activity
- Look for preceding API calls such as
ListMFADevices,GetSessionToken, orListUsers, which may indicate reconnaissance or IAM enumeration. - Search for subsequent
DeleteVirtualMFADevicecalls 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.
- Look for preceding API calls such as
-
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
- 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
-
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.
- Re-enable MFA for the affected IAM user (
-
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
References
Related rules
- AWS IAM Virtual MFA Device Registration Attempt with Session Token
- AWS IAM API Calls via Temporary Session Tokens
- AWS IAM Group Creation
- AWS IAM Group Deletion
- AWS IAM User Created Access Keys For Another User