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, and user_agent.original for 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

to-top