T1621
Multi-Factor Authentication Request Generation
Multi-Factor Authentication (MFA) abuse is a looming problem that deserves our collective attention.
Pairs with this song Threat sounds
Adversaries flood users with MFA requests, asking to be let in over and over until the user relents out of annoyance. Maybe that’s how R.E.M. managed to get inducted into the Rock ‘n’ Roll Hall of Fame before their fellow Athenians, the B-52s.
Editor’s note: While the detection opportunities and analysis on this page are still relevant, it has not been updated since 2023.
Analysis
Why do adversaries use Multi-Factor Authentication Request Generation?
Adversaries abuse MFA requests to log into valuable systems that are protected by second factors of authentication. To the surprise of many, some MFA implementations are susceptible to relatively unsophisticated social engineering attacks that could allow an adversary to impersonate victims and bypass security controls. Highly privileged identities are particularly juicy targets for adversaries seeking to turn corporate systems upside down to steal data, conduct espionage, and disrupt systems.
How do adversaries use Multi-Factor Authentication Request Generation?
Over the past year we’ve witnessed countries, governments, and some of the largest and most advanced technology companies in the world fall victim to an attack technique known by many names: “MFA fatigue,” “MFA bombing,” “MFA exhaustion,” and “MFA spamming,” to name a handful. It’s fairly simple to execute but initially requires an adversary to possess legitimate victim credentials that are usually acquired through information-stealing malware, credential stuffing or password spraying, and initial access brokers on dark web marketplaces.
Typically the adversary attempts to use these stolen credentials programmatically against cloud-based resources in rapid succession. Depending on the victim’s factor of choice, they may receive a push notification from their mobile authentication application, a phone call, a text message, or an email; all of which require users to take some form of action to complete the authentication sequence.
Adversaries then standby patiently waiting for their victim to relent out of annoyance or exhaustion from the constant bombardment of notifications or phone calls and finally fulfill the MFA request, enabling the adversary to impersonate the victim. Adversaries will subsequently register their own mobile device as the new MFA factor to avoid further annoyance to the victim. In general, the attack relies more on social engineering than advanced techniques.
Once an adversary has access to the victim organization, they’ll want to be able to re-enter the environment as needed, using their newly registered device to accept future MFA prompts. Upon successfully accessing the user’s account, adversaries will typically have access to a corpus of SaaS applications or systems that otherwise might have been challenging to access individually. Newly gained access means the adversary may be able to view the victim’s Single Sign-On (SSO) portal and choose what applications to use and abuse. One can only imagine the potential danger if a privileged user like a payroll manager or production system administrator is compromised.
Take Action
We’re conditioned to use MFA as a catch-all method to prevent credential theft attacks but this past year has challenged this notion. Preventing this sort of attack requires corporations to adopt new forms of MFA like passwordless authentication. With passwordless authentication, static credentials are an afterthought, offering users the convenience of quicker, phish-resistant mechanisms of authentication.
By using your unique physical features—like fingerprints or facial recognition in combination with second factor devices like FIDO2 or yubikeys—users are well protected against credential attacks because it’s harder for adversaries to physically copy your biometric identifiers than it is for them to phish your credentials.
We expect phish-resistant MFA to gain traction given the convenience it offers as it prevents users from common issues like password misplacement, weak password strength, and insecure storage of credentials. Cloud password storage product breaches in the last few years should solidify the need for enterprises to transition to passwordless authentication options.
Visibility
Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.
Visibility into these attacks will certainly vary as every identity provider offers different logs in different structures and retains them based on subscription level. Defenders will typically need to access the logs of their organization’s Identity provider, which are very noisy as they record all of the authentication sessions across your enterprise as well as additional auditing activities. This could easily be in the millions of records per day depending on the size of your organization. In general though, you’ll want to collect some version of the following:
Application logs
The contents of application logs may offer some visibility into T1621, depending on the level collection offered by the cloud provider in question. Understanding which users logged in and what they accessed can be important building blocks for developing detection coverage.
Logon session
Session telemetry is another potentially rich source of telemetry for observing and detecting MFA exhaustion, but the quality and relevance of this telemetry may vary from one cloud service provider to the next. Ideally though, telemetry can inform defenders of who logged into what, when, and where. In some cases, defenders may be able to leverage session telemetry to trace an adversary’s path through endpoint and cloud resources.
User account
User account information is among the most obvious data sources tracking MFA abuse, but, as is nearly always the case with cloud services, the robustness of user account data may vary from one service provider to the next. Particularly relevant for collection would be account metadata as well as records of account creation, deletion, and modification. Unusual login attempts and MFA requests are also potentially useful telemetry sources for detection.
Collection
Note: The collection sections of this report showcase specific log sources from Windows events, Sysmon, and elsewhere that you can use to collect relevant security information.
Many different SIEMs provide out-of-the-box integrations to automatically collect relevant data from your identity provider’s API. If you’re in the middle of an investigation, you may also be able to selectively gather data from this API, obviating the need to continually collect and manage the entire identity dataset.
Examples of useful log sources from popular cloud services include the following:
Okta System Log
Okta is an identity company that provides SSO, MFA, and other access-related solutions. Its system log API serves as an audit trail that collects relevant records of user activity. Relevant information stored in the log includes usernames, security context, IP addresses, geolocations, timestamps, and much more information associated with authentication and access activity. If an adversary is generating MFA authentication requests in an Okta environment, security teams can likely find evidence of it in the system log.
AWS Cloudtrail
CloudTrail records access attempts to all variety of AWS systems, including the management console. It logs both successful and unsuccessful login attempts, with or without MFA. It also logs password and MFA state changes, AWS command-line activity, and more.
Azure Active Directory audit Logs and sign-in logs
Azure audit and sign-in logs record relevant login event data from Azure Active Directory. Audit logs specifically collect information about user and group account changes, updates, passwords changes, and admin activity. They also collect information about application additions and removals, service principal changes, name changes, and more. Sign-in logs collect valuable information about login errors.
Duo authentication logs
Duo is an authentication provider that mainly sells MFA products. Their authentication logs offer a rich array of information about user login attempts, including information about authentication attempts, enrollments, factor methods, and more.
Google Workspace Login Auditing
Google Workspace Login Auditing records a wide variety of information related to Google Workspace login attempts, including successful and failed logins, suspicious application logins, password changes, and a wealth of other potentially valuable information.
Detection opportunities
MFA request generation is a powerful technique in part because detecting and investigating it can be difficult and time-consuming. Where an EDR-based detection analytic can simply look for process x and/or command line y, detecting MFA request generation requires data aggregation from multiple events, relies on chronological sequencing, and may necessitate extensive tuning for accurate results.
Since the nature of detection for T1621 is different from the endpoint techniques we usually cover, our detection advice is going to be different too. From the perspective of Okta’s System Log events, let’s look at what happens when a user completes an authentication sequence from start to finish.
The MFA Authentication Sequence
Once a user logs into their identity provider, in this case via Okta, a log is generated of the eventType user.session.start. At this point, Okta will determine if the user has MFA enabled, then determine what factor to use for them (e.g., push notification, phone call, SMS, etc.), which is represented by a policy.evaluate_sign_on event.
If the user prefers push notifications, we’ll see an event type that represents whether a push was successfully sent to the user’s device with the event type of system.push.send_factor_verify_push. If the user denies the push, which may or may not be expected in an MFA exhaustion attack, we’ll receive an event of user.mfa.okta_verify.deny_push. Take note that if the user allows the push request to timeout, there is no corresponding log entry.
Most importantly, the metadata and log entries associated with the system.push.send_factor_verify_push event are going to represent the adversary’s location. Okta provides a lot of great data points in their logs that can be invaluable during investigating potential malicious activity like:
- User Agent
- Client IP address
- Any proxy chain IP addresses
- Enriched Geo-location
- Session ID
- UEBA information
- Anomalous Device observed
- Anomalous Geo-Location
- Newly observed IP address
- Newly observed State
- Newly observed Country
- Velocity – indicating “impossible travel”
When the user finally accepts the push request and finishes the authentication flow, a user.authentication.auth_via_mfa event is recorded with a recorded outcome of SUCCESS. This sequence of events is important to understand because it will feed the aggregation and sequencing aspect of our detection logic. Understanding the order of operations of the login is important, but for our detection logic we need to be a bit more specific and only look at the necessary event types for this specific attack sequence:
Do we need to know when a user session started?
No, because even with failed logons with incorrect usernames or passwords, this is recorded. We only care when correct credentials are used, which will only be observed during the subsequent events.
Do we need to know if a user has MFA enabled via their sign-on policy?
No, because if it wasn’t enabled we wouldn’t identify the subsequent MFA sequence, meaning; we can ignore this in our detection logic.
Do we need to know that a user denied the push notification?
Not really, since our detection logic will only look at the count of MFA pushes sent to a user, the MFA push count will remain the same whether or not they deny or let it timeout. A detection analytic for counting denied push notifications may be a solid hunting query, but for automated detection it might be noisy for large organizations.
After some tuning, we’re left with two event types of interest:
| Event type | Event description |
|---|---|
| Event type:
| Event description: A push was sent to a user for verification |
| Event type:
| Event description: User rejected Okta push verify |
| Event type:
| Event description: Authentication of user via MFA |
Our detection logic should calculate a rolling count of MFA pushes over an arbitrary time period grouped by the user and their given session ID. Grouping by session ID allows us to follow along the sequence of events for a given authentication session in case the actual user coincidentally logs in at the same time as the adversary, which may skew our count.
Users may occasionally fail MFA accidentally multiple times due to accidental push notification denials, challenge timeouts, and network disruptions on their mobile device. We suggest you monitor for a threshold of three or more push notifications followed by a successful MFA authentication event in a 30-minute timeframe. This threshold was created arbitrarily, with false positive rates in mind, and is therefore not a magic number.
An example timeline of this detection may look like the following:
| Time | Event type | Session ID | Count |
|---|---|---|---|
| Time: 12:00 AM | Event type:
| Session ID: A | Count: 1 |
| Time: 12:05 AM | Event type:
| Session ID: A | Count: 2 |
| Time: 12:10 AM | Event type:
| Session ID: A | Count: 3 |
| Time: 12:11 AM | Event type:
| Session ID: D | Count: 1 |
| Time: 12:13 AM | Event type:
| Session ID: D | Count: 1 |
| Time: 12:15 AM | Event type:
| Session ID: A | Count: 4 |
| Time: 12:29 AM | Event type:
| Session ID: A | Count: 1 |
You can use the following pseudo logic for detection:
Successful User.authentication.auth_via_mfa
Perform a look back in a 30 minute window for more than 3 system.push.send_factor_verify_push events Additional threat hunting ideas:
- Monitor for more than two denied push notifications per session.
- Apply network threat intelligence to the IP addresses from your push notification events.
- Baseline user authentication from normal locations and identify abnormal countries of origin.
- Observe authentications from unsanctioned VPNs or proxies.
- Look for more than one IP address in the proxy chains provided in the Okta logs
- Monitor for newly registered devices or phone numbers for existing users.
- Okta event type:
device.enrollment.create
- Okta event type:
- Monitor for Okta threat suspected events.
- Okta event type:
security.threat.detected
- Okta event type:
- Monitor for users reporting suspicious activity.
- Okta event type:
user.account.report_suspicious_activity_by_enduser
- Okta event type:
Testing
Testing this attack is straightforward, and you can readily test any account you control. Make sure this test account has multi-factor enabled, with push notifications as their second factor. To execute the attack, enter the credentials into your identity provider’s SSO portal. Your test victim account should receive the push notification, which you can either manually deny or let timeout by ignoring it. Repeat this process multiple times until eventually accepting the push notification. We highly encourage you to review the resulting logs within your chosen identity provider, and record a timeline of your actions.