AN0449: Analytic 0449
Monitor for excessive or anomalous MFA push notifications or token requests, especially when login attempts originate from unusual IPs or geolocations and do not correspond to legitimate user-initiated sessions.
Analyst context for executives and security teams
This analytic matters because abnormal MFA push notifications or token requests can signal identity pressure against users before a full account compromise is confirmed. For leaders, the practical question is whether the organization can see and investigate suspicious MFA activity in the identity provider, especially when requests come from unusual IP addresses or geolocations and do not match a real user-initiated sign-in.
Executive priority
Prioritize this as an identity and access management readiness check. MFA is often treated as a control, but this analytic tests whether MFA events themselves are monitored as security telemetry. Executives should ask whether the SOC can identify excessive or anomalous MFA prompts, correlate them with unusual source locations, and provide evidence for incident response and audit reviews.
Technical view
For SOC and detection teams, validate that identity provider logs capture MFA push notifications, token requests, login attempts, source IPs, geolocation context, user identity, timestamps, and session outcomes. Detection should focus on excessive or anomalous MFA activity, especially where the activity originates from unusual IPs or geolocations and lacks evidence of a legitimate user-initiated session. Because no ATT&CK tactic or relationship context is supplied, treat this as an identity-provider detection analytic rather than mapping it to a broader intrusion chain without local evidence.
Likely telemetry
- Identity provider authentication logs
- MFA push notification events
- MFA token request events
- Login attempt records
- Source IP address and geolocation enrichment
Detection direction
- Baseline normal MFA request frequency per user, group, role, and geography before setting alert thresholds.
- Correlate MFA prompts or token requests with interactive login attempts and session creation to identify requests that do not match legitimate user activity.
- Tune alerts for unusual IPs or geolocations, while accounting for travel, VPNs, remote work, and known corporate egress points.
- Review whether failed, denied, expired, and repeated MFA events are retained and searchable in the identity provider logs.
- Avoid assuming compromise from volume alone; require analyst review of user context, source location, timing, and session outcome.
Mitigation priorities
- Ensure identity provider logging is enabled for MFA prompts, token requests, login attempts, source IPs, geolocation, and session outcomes.
- Define response procedures for suspicious MFA activity, including user verification, session review, and account risk assessment.
- Use this analytic to validate MFA monitoring coverage during compliance readiness and incident response exercises.
- Review MFA policies and exception handling so high-risk users and unusual access patterns receive appropriate scrutiny.
- Periodically test whether SOC workflows can triage anomalous MFA activity using available identity telemetry.
Analyst notes and limits
The supplied object is a detection analytic, AN0449, for the Identity Provider platform. Its value is strongest when used as a control-validation question: can defenders observe excessive or anomalous MFA push notifications or token requests and relate them to source location and legitimate session activity? No relationship context was supplied, so broader technique, actor, or campaign conclusions should not be inferred from this object alone.
ATT&CK provides a short description and no official detection details, tactics, relationships, aliases, or labels for this analytic. Local identity provider schema, MFA method, retention, geolocation quality, VPN usage, and user behavior baselines are required to operationalize it reliably.
Analytic 0449
Monitor for excessive or anomalous MFA push notifications or token requests, especially when login attempts originate from unusual IPs or geolocations and do not correspond to legitimate user-initiated sessions.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 7a07ec62f061… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0449Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.