MFA is only as strong as its configuration. MITRE ATT&CK technique T1556.006, Multi-Factor Authentication, covers adversaries who disable or modify MFA to keep access to compromised accounts. The tactics are defense impairment, persistence and credential access. Platforms include IaaS, Identity Provider, Linux, macOS, Office Suite, SaaS and Windows.
How attackers use it
The starting point is access. MITRE says adversaries first get in by compromising an account that lacks MFA, or by an MFA bypass such as Multi-Factor Authentication Request Generation (T1621). Then they change MFA so the access lasts.
The methods MITRE lists abuse legitimate features: excluding users from Azure AD Conditional Access Policies, registering a new MFA method that the adversary controls, or patching MFA programs and configuration files to bypass expected behavior.
One example shows the fail-open risk. Modifying the Windows hosts file at C:\windows\system32\drivers\etc\hosts to point MFA calls to localhost makes the MFA process fail. If the policy is fail open, an otherwise successful login is granted access without MFA being enforced.
Scope varies. MFA may be disabled for single accounts or for all accounts tied to a larger group, such as every domain account.
How to detect it
MITRE lists no data sources on this page, but its audit mitigation tells you where to look: MFA actions next to authentication logs.
- New MFA methods registered on an account, particularly right after a password reset or from a new location.
- Users added to exclusion lists in conditional access or MFA policies.
- Successful sign-ins with no MFA event where policy requires one.
- Changes to the hosts file on systems that run an MFA agent, and changes to MFA client configuration files.
- MFA service errors followed by successful logins, which can show a fail-open path being used.
How to reduce the risk
MITRE lists three mitigations.
- User account management. Define policies for secure enrollment and deactivation of MFA on user accounts.
- Audit. Review MFA actions alongside authentication logs to confirm MFA based logins work as intended, and review accounts to confirm every one has MFA enabled.
- Multi-factor authentication. Apply MFA policy to existing, deactivated and dormant accounts and devices. Where possible, configure MFA solutions to fail closed instead of granting access when a serious error occurs.
Fail closed is the decision that matters most. An outage is better than silent access without a second factor, so decide ahead of time who may override it and how that is logged.
Check your own environment
- List accounts with no registered MFA method and any excluded from MFA policy.
- Review recently registered MFA methods, especially for privileged accounts.
- Check each MFA agent's failure behavior and document it.
- Alert on changes to MFA policy and exclusion groups.
On Windows, a read-only check of the hosts file on a server that runs an MFA agent:
Get-Content C:\Windows\System32\drivers\etc\hosts
Any entry that redirects your MFA service name needs explaining.
Quick check
What does fail open mean for MFA?
If the MFA service cannot be reached or errors out, access is granted anyway. An adversary who breaks the MFA call, for instance by redirecting it to localhost, then bypasses the second factor.
Name two ways adversaries keep access after reaching an account.
Excluding users from conditional access policies, and registering a new MFA method that they control.
