Adversaries may disable or modify multi-factor authentication (MFA) mechanisms to enable persistent access to compromised accounts.
Once adversaries have gained access to a network by either compromising an account lacking MFA or by employing an MFA bypass method such as Multi-Factor Authentication Request Generation, adversaries may leverage their access to modify or completely disable MFA defenses. This can be accomplished by abusing legitimate features, such as excluding users from Azure AD Conditional Access Policies, registering a new yet vulnerable/adversary-controlled MFA method, or by manually patching MFA programs and configuration files to bypass expected functionality.[1][2]
For example, modifying the Windows hosts file (C:\windows\system32\drivers\etc\hosts) to redirect MFA calls to localhost instead of an MFA server may cause the MFA process to fail. If a "fail open" policy is in place, any otherwise successful authentication attempt may be granted access without enforcing MFA. [3]
Depending on the scope, goals, and privileges of the adversary, MFA defenses may be disabled for individual accounts or for all accounts tied to a larger group, such as all domain accounts in a victim's network environment.[3]
| ID | Name | Description |
|---|---|---|
| S0677 | AADInternals |
The AADInternals |
| G1015 | Scattered Spider |
After compromising user accounts, Scattered Spider registers their own MFA tokens.[4] |
| S1104 | SLOWPULSE |
SLOWPULSE can insert malicious logic to bypass RADIUS and ACE two factor authentication (2FA) flows if a designated attacker-supplied password is provided.[5] |
| ID | Mitigation | Description |
|---|---|---|
| M1047 | Audit |
Review MFA actions alongside authentication logs to ensure that MFA-based logins are functioning as intended. Review user accounts to ensure that all accounts have MFA enabled.[6] |
| M1032 | Multi-factor Authentication |
Ensure that MFA and MFA policies and requirements are properly implemented for existing and deactivated or dormant accounts and devices. If possible, consider configuring MFA solutions to "fail closed" rather than grant access in case of serious errors. |
| M1018 | User Account Management |
Ensure that proper policies are implemented to dictate the secure enrollment and deactivation of MFA for user accounts. |
| ID | Name | Analytic ID | Analytic Description |
|---|---|---|---|
| DET0190 | Detect MFA Modification or Disabling Across Platforms | AN0543 |
Detects registry and Group Policy modifications that disable or weaken MFA, suspicious PowerShell usage modifying MFA-related attributes, and anomalous login sessions succeeding without expected MFA challenge. |
| AN0544 |
Detects conditional access policy changes, exclusion of accounts from MFA enforcement, or registration of new MFA factors by non-admin or anomalous users. |
||
| AN0545 |
Detects API calls to cloud secrets/MFA configurations where MFA enforcement policies are disabled or bypassed. |
||
| AN0546 |
Detects PAM module modifications or removal of MFA hooks in /etc/pam.d/ configurations, correlated with successful authentications lacking MFA prompts. |
||
| AN0547 |
Detects modifications to authorization plugins responsible for MFA enforcement and correlates with suspicious login sessions missing MFA prompts. |
||
| AN0548 |
Detects suspicious MFA method changes, such as registration of weaker factors (e.g., SMS), or removal of MFA requirements for specific accounts or groups. |
||
| AN0549 |
Detects MFA bypass attempts by modifying tenant-wide authentication policies or excluding high-value accounts from MFA enforcement. |