AWS IAM User Console Login Without MFA
Identifies the first observed occurrence, within the configured New Terms history window, of a regular IAM user successfully signing in to the AWS Management Console without multi-factor authentication. A password alone is a weaker control than password-plus-MFA, and an adversary who has phished, guessed, or otherwise obtained a user's password can sign in directly if MFA is not enforced for that user. This rule is scoped to standard IAM users only; it excludes the AWS root user (covered by a dedicated rule) and federated/SSO sign-ins (covered by a dedicated rule that also accounts for IdP-side MFA), since MFAUsed: No is expected in both of those cases for reasons unrelated to this gap.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/07/13"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2026/07/13"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies the first observed occurrence, within the configured New Terms history window, of a regular IAM user
11successfully signing in to the AWS Management Console without multi-factor authentication. A password alone is a
12weaker control than password-plus-MFA, and an adversary who has phished, guessed, or otherwise obtained a user's
13password can sign in directly if MFA is not enforced for that user. This rule is scoped to standard IAM users
14only; it excludes the AWS root user (covered by a dedicated rule) and federated/SSO sign-ins (covered by a dedicated
15rule that also accounts for IdP-side MFA), since MFAUsed: No is expected in both of those cases for reasons unrelated
16to this gap.
17"""
18false_positives = [
19 """
20 Environments that do not enforce MFA for all IAM users will see this regularly. This is a New Terms rule, so it only
21 fires once per `user.id` within the configured history window (7d); use it to drive MFA enrollment and enforcement rather than treating every occurrence as an
22 incident, unless MFA is a mandated control in your environment.
23 """,
24]
25from = "now-6m"
26index = ["logs-aws.cloudtrail-*"]
27language = "kuery"
28license = "Elastic License v2"
29name = "AWS IAM User Console Login Without MFA"
30note = """## Triage and analysis
31
32### Investigating AWS IAM User Console Login Without MFA
33
34This rule identifies a standard IAM user (not root, not a federated/SSO sign-in) successfully signing in to the AWS
35Management Console where CloudTrail's `additionalEventData.MFAUsed` field is `No`. A username and password are
36comparatively easy for an adversary to obtain through phishing, credential stuffing, or password reuse; MFA is the
37control that prevents a stolen password alone from granting console access.
38
39This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule)
40rule and fires the first time each `user.id` is observed signing in without MFA within the configured history window (7d).
41
42### Possible investigation steps
43
44- **Confirm MFA enrollment status**: check whether the user has an MFA device registered at all. If not, this may
45 simply reflect that MFA is not yet enforced for this user rather than an active compromise.
46- **Review source context**: check `source.ip`, `source.geo`, and `user_agent.original` for anomalies relative to the
47 user's normal sign-in pattern.
48- **Correlate with recent credential exposure**: check for recent password resets, phishing reports, or leaked
49 credential alerts involving this user.
50- **Review post-login activity**: examine what the user did in the console session immediately following sign-in for
51 any unusual or high-privilege actions.
52
53### False positive analysis
54
55- Environments without a blanket MFA enforcement policy will see this for every user's first sign-in. Use this rule
56 to drive MFA adoption; if MFA is not currently mandated, treat repeated occurrences as a posture gap rather than an
57 incident, and consider excluding known-legacy or service-adjacent IAM users that cannot use MFA.
58
59### Response and remediation
60
61- If this sign-in is unexpected or the source is anomalous, treat the user's credentials as potentially compromised:
62 force a password reset and review recent console/API activity for the account.
63- Enforce MFA for all IAM users capable of console access, via IAM policy conditions (`aws:MultiFactorAuthPresent`) or
64 an SCP, and prioritize enrolling any user identified by this rule.
65- Consider moving console access to federated/SSO sign-in with IdP-enforced MFA rather than IAM user passwords.
66
67"""
68references = [
69 "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html",
70 "https://stratus-red-team.cloud/attack-techniques/AWS/aws.initial-access.console-login-without-mfa/",
71]
72risk_score = 47
73rule_id = "f5778acd-80e3-4ca0-a32a-6259386dfb20"
74severity = "medium"
75tags = [
76 "Domain: Cloud",
77 "Data Source: AWS",
78 "Data Source: Amazon Web Services",
79 "Data Source: AWS Sign-In",
80 "Use Case: Identity and Access Audit",
81 "Tactic: Initial Access",
82 "Resources: Investigation Guide",
83]
84timestamp_override = "event.ingested"
85type = "new_terms"
86
87query = '''
88data_stream.dataset: "aws.cloudtrail"
89 and event.provider: "signin.amazonaws.com"
90 and event.action: "ConsoleLogin"
91 and event.outcome: "success"
92 and aws.cloudtrail.user_identity.type: "IAMUser"
93 and aws.cloudtrail.console_login.additional_eventdata.mfa_used: false
94'''
95
96
97[[rule.threat]]
98framework = "MITRE ATT&CK"
99[[rule.threat.technique]]
100id = "T1078"
101name = "Valid Accounts"
102reference = "https://attack.mitre.org/techniques/T1078/"
103[[rule.threat.technique.subtechnique]]
104id = "T1078.004"
105name = "Cloud Accounts"
106reference = "https://attack.mitre.org/techniques/T1078/004/"
107
108
109
110[rule.threat.tactic]
111id = "TA0001"
112name = "Initial Access"
113reference = "https://attack.mitre.org/tactics/TA0001/"
114
115[rule.investigation_fields]
116field_names = [
117 "@timestamp",
118 "user.name",
119 "user_agent.original",
120 "source.ip",
121 "source.geo.country_name",
122 "aws.cloudtrail.user_identity.arn",
123 "aws.cloudtrail.user_identity.type",
124 "event.action",
125 "event.outcome",
126 "aws.cloudtrail.console_login.additional_eventdata.mfa_used",
127 "cloud.account.id",
128 "cloud.region",
129]
130
131[rule.new_terms]
132field = "new_terms_fields"
133value = ["user.id"]
134[[rule.new_terms.history_window_start]]
135field = "history_window_start"
136value = "now-7d"
Triage and analysis
Investigating AWS IAM User Console Login Without MFA
This rule identifies a standard IAM user (not root, not a federated/SSO sign-in) successfully signing in to the AWS
Management Console where CloudTrail's additionalEventData.MFAUsed field is No. A username and password are
comparatively easy for an adversary to obtain through phishing, credential stuffing, or password reuse; MFA is the
control that prevents a stolen password alone from granting console access.
This is a New Terms
rule and fires the first time each user.id is observed signing in without MFA within the configured history window (7d).
Possible investigation steps
- Confirm MFA enrollment status: check whether the user has an MFA device registered at all. If not, this may simply reflect that MFA is not yet enforced for this user rather than an active compromise.
- Review source context: check
source.ip,source.geo, anduser_agent.originalfor anomalies relative to the user's normal sign-in pattern. - Correlate with recent credential exposure: check for recent password resets, phishing reports, or leaked credential alerts involving this user.
- Review post-login activity: examine what the user did in the console session immediately following sign-in for any unusual or high-privilege actions.
False positive analysis
- Environments without a blanket MFA enforcement policy will see this for every user's first sign-in. Use this rule to drive MFA adoption; if MFA is not currently mandated, treat repeated occurrences as a posture gap rather than an incident, and consider excluding known-legacy or service-adjacent IAM users that cannot use MFA.
Response and remediation
- If this sign-in is unexpected or the source is anomalous, treat the user's credentials as potentially compromised: force a password reset and review recent console/API activity for the account.
- Enforce MFA for all IAM users capable of console access, via IAM policy conditions (
aws:MultiFactorAuthPresent) or an SCP, and prioritize enrolling any user identified by this rule. - Consider moving console access to federated/SSO sign-in with IdP-enforced MFA rather than IAM user passwords.
References
Related rules
- AWS IAM User Console Login from Multiple Geolocations
- AWS Management Console Root Login
- AWS Sign-In Console Login with Federated User
- AWS Sign-In Root Password Recovery Requested
- AWS Bedrock Foundation Model Enumeration Followed by Invocation via Long-Term Key