1200KM / simulation
Adversaries may attempt to bypass multi-factor authentication (MFA) mechanisms and gain access to accounts by generating MFA requests sent to users. Adversaries in possession of credentials to Valid Accounts may be unable to complete the login process if they lack access to the 2FA or MFA mechanisms required as an additional credential and security control. To circumvent this, adversaries may abuse the automatic generation of push notifications…
Adversaries may attempt to bypass multi-factor authentication (MFA) mechanisms and gain access to accounts by generating MFA requests sent to users.
Adversaries in possession of credentials to Valid Accounts may be unable to complete the login process if they lack access to the 2FA or MFA mechanisms required as an additional credential and security control. To circumvent this, adversaries may abuse the automatic generation of push notifications to MFA services such as Duo Push, Microsoft Authenticator, Okta, or similar services to have the user grant access to their account. If adversaries lack credentials to victim accounts, they may also abuse automatic push notification generation when this option is configured for self-service password reset (SSPR).[Obsidian SSPR Abuse 2023]
In some cases, adversaries may continuously repeat login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls, potentially resulting in the user finally accepting the authentication request in response to “MFA fatigue.”[Russian 2FA Push Annoyance - Cimpanu][MFA Fatigue Attacks - PortSwigger][Suspected Russian Activity Targeting Government and Business Entities Around the Globe]
Official technique definition · Open in the interactive matrix
These contracts are selected through exact technique-to-data-component relationships or explicitly labelled planning overrides. Configure a collector at the relevant observation point; a telemetry name alone is not coverage.
DC0038 collection page — Select the application event family required by the detection and document its native schema before normalization.
Required normalized fields: service, action, actor, record_count, result.
Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.
{
"schema": "1200km.telemetry.example.v1",
"synthetic": true,
"timestamp": "2026-09-27T12:00:00Z",
"telemetry_id": "DC0038",
"collector": "illustrative-lab-collector",
"observation": {
"service": "lab-portal",
"action": "export_requested",
"actor": "lab-reader",
"record_count": 3,
"result": "authorized"
}
}Visibility limits: Debug output is not necessarily a durable audit trail. Application developers must emit the relevant event; installing a log pipeline does not make an absent event exist.
DC0088 collection page — Collect supported session inventory and correlate session IDs with authentication, logon and logoff events.
Required normalized fields: session_id, account, host, session_type.
Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.
{
"schema": "1200km.telemetry.example.v1",
"synthetic": true,
"timestamp": "2026-09-27T12:00:00Z",
"telemetry_id": "DC0088",
"collector": "illustrative-lab-collector",
"observation": {
"session_id": "lab-session-1",
"account": "LAB\\analyst",
"host": "lab-host-1",
"session_type": "interactive"
}
}Visibility limits: Snapshots miss short-lived objects and do not identify who caused a change. A generic inventory agent is not guaranteed to expose firmware or kernel-level details.
DC0002 collection page — Collect successful and failed sign-ins, authentication method, application and conditional-access context; distinguish account validation from session creation.
Required normalized fields: account, application, result, reason, source_ip.
Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.
{
"schema": "1200km.telemetry.example.v1",
"synthetic": true,
"timestamp": "2026-09-27T12:00:00Z",
"telemetry_id": "DC0002",
"collector": "illustrative-lab-collector",
"observation": {
"account": "analyst@example.test",
"application": "lab-portal",
"result": "failure",
"reason": "invalid_credential",
"source_ip": "192.0.2.10"
}
}Visibility limits: A token creation record is not evidence of token use; a sign-in is not a complete record of every resource access. Some provider-side data is unavailable to the customer.
Open the dedicated detection workspace · Existing query engineering
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.
Platforms: Identity Provider.
Detect abnormal MFA activity within cloud service provider logs, such as repeated generation of MFA challenges for the same user session or mismatched MFA device and login origin.
Platforms: IaaS.
Detect repeated failed login events followed by MFA challenges triggered in rapid succession, especially if originating from service accounts or anomalous IP addresses.
Platforms: Windows.
Monitor PAM and syslog entries for unusual frequency of login attempts that trigger MFA prompts, particularly when MFA challenges do not match expected user behavior.
Platforms: Linux.
Detect anomalous OAuth or SSO logins that repeatedly generate MFA challenges, particularly where MFA approvals are denied or timed out by the user.
Platforms: SaaS.
Detect user account logon attempts that trigger multiple MFA challenges through enterprise identity integrations, especially if MFA push requests are generated without successful interactive login.
Platforms: macOS.
2 exact-tagged source rules. A source tag is a discovery aid, not a relevance verdict. Check the observation point and actual condition of each rule.
COUNT(mfa_challenge BY account, 10m) >= threshold OR COUNT(mfa_denied BY account, 10m) >= threshold -> ALERTBurst Anomaly · Inter-Arrival-Time Anomaly · Ratio or Proportion Anomaly
Start from the exact analytic above. The collection-specific lenses below are analyst recommendations; they do not assert that an arbitrary statistical deviation detects this technique.
Anomaly Detection Atlas · Baseline, validation and blind spots
No reviewed lab-tool association is selected for this exact technique. This is a curation gap, not a statement that no tool can implement the behavior.
Atomic evidence: no compatible candidate in this snapshot. Live lab status: not run for these imported procedures.
Use disposable lab hosts and test accounts, explicit target allowlists, a clean snapshot, bounded egress and a restore plan. Review every candidate and dependency before any execution.
No compatible Atomic procedure is present in this pinned evidence set. Technical feasibility has not been ruled out. A custom procedure must define the behavior, target, collection point, success observable and rollback before execution.
Download synthetic collection fixture (JSON) · Download the complete engineering workbook
This fixture exercises the listed collection fields. It does not reproduce Multi-Factor Authentication Request Generation, label its example events as malicious, or measure detection effectiveness. Use the exact analytic and selected procedure to build an independently labelled behavior-positive dataset.
Not run in this browser. No network scan or attack command is executed by this control.
All-page audit and evidence inventory · This page’s machine-readable workbook
Pinned MITRE STIX source · SHA-256 81113ba98afa2928f3dcff62022539f7ce30c315c32e14422f11ff95ce534352. Definition and procedure context are reproduced from this snapshot, not independently re-investigated incidents.
Train users to only accept 2FA/MFA requests from login attempts they initiated, to review source location of the login attempt prompting the 2FA/MFA requests, and to report suspicious/unsolicited prompts.
Implement more secure 2FA/MFA mechanisms in replacement of simple push or one-click 2FA/MFA options. For example, having users enter a one-time code provided by the login screen into the 2FA/MFA application or utilizing other out-of-band 2FA/MFA mechanisms (such as rotating code-based hardware tokens providing rotating codes that need an accompanying user pin) may be more secure. Furthermore, change default configurations and implement limits upon the maximum number of 2FA/MFA request prompts that can be sent to users in period of time.[MFA Fatigue Attacks - PortSwigger]
Enable account restrictions to prevent login attempts, and the subsequent 2FA/MFA service requests, from being initiated from suspicious locations or when the source of the login attempts do not match the location of the 2FA/MFA smart device. Use conditional access policies to block logins from non-compliant devices or from outside defined organization IP ranges.[Microsoft Common Conditional Access Policies]
No reviewed association in this snapshot.
These are explicit actor-to-technique associations in the existing Threat Matrix snapshot, not attribution of an event or proof that a detector identifies the actor. No tool-to-actor relationship is inferred.
Curated research views reached through an exact source technique, a catalog model, or a reviewed collection reference. These are navigation associations, not claims of detector effectiveness or sensor equivalence.
Telemetry contracts · Maintained query examples · Validation and blind spots
Pinned research references. No browser attack runner or production-validated detector is asserted. Imported procedures remain unvalidated; any bounded lab evidence has its own scope. ATT&CK / Atomic provenance · Detection provenance.