AWS IAM User Console Login Without MFA
Description
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.
Query · kuery
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
Investigation fields
Pivot points the source recommends for triage.
@timestampuser.nameuser_agent.originalsource.ipsource.geo.country_nameaws.cloudtrail.user_identity.arnaws.cloudtrail.user_identity.typeevent.actionevent.outcomeaws.cloudtrail.console_login.additional_eventdata.mfa_usedcloud.account.idcloud.region
Known false positives
- Environments that do not enforce MFA for all IAM users will see this regularly. This is a New Terms rule, so it only 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 incident, unless MFA is a mandated control in your environment.
Analyst notes
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.