AWS IAM User Console Login Without MFA

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

AWS IAM User Console Login Without MFA

edit

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.

Rule type: new_terms

Rule indices:

  • logs-aws.cloudtrail-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-6m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Data Source: AWS
  • Data Source: Amazon Web Services
  • Data Source: AWS Sign-In
  • Use Case: Identity and Access Audit
  • Tactic: Initial Access
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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.

Rule query

edit
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "signin.amazonaws.com"
    and event.action: "ConsoleLogin"
    and event.outcome: "success"
    and aws.cloudtrail.user_identity.type: "IAMUser"
    and aws.cloudtrail.console_login.additional_eventdata.mfa_used: false

Framework: MITRE ATT&CKTM