T1556.006: Multi-Factor Authentication
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]
Analyst context for executives and security teams
This technique matters because MFA is often the control executives expect to contain account compromise. ATT&CK describes adversaries modifying or disabling MFA after gaining access, such as excluding users from conditional access policies, registering adversary-controlled MFA methods, or altering local MFA-related configuration so authentication fails open. The business issue is not simply “turn on MFA”; it is whether MFA settings, exceptions, and recovery paths are governed, logged, and reviewed well enough to prevent compromised access from becoming persistent access.
Executive priority
Prioritize this as an identity resilience and audit-evidence issue across IaaS, identity providers, SaaS, Office suites, and endpoints. Leaders should ask who can change MFA policy, approve exclusions, register new methods, or alter authentication components; whether those changes generate reviewed evidence; and whether incident response can quickly identify accounts or groups whose MFA posture changed during a compromise. MFA exceptions and fail-open behavior should be treated as high-risk control gaps, especially for privileged and operationally critical accounts.
Technical view
SOC, detection engineering, and IR teams should validate monitoring for MFA configuration changes, conditional access exclusions, new or changed authentication methods, and local authentication process modifications across Windows, Linux, macOS, identity provider, SaaS, Office Suite, and IaaS environments. ATT&CK provides no native detection text for this object, but relationship context includes DET0190, Detect MFA Modification or Disabling Across Platforms. Teams should also correlate this sub-technique with its parent, Modify Authentication Process, and with related software relationships such as AADInternals and SLOWPULSE where those technologies or artifacts are relevant to the environment.
Likely telemetry
- Identity provider audit logs for MFA policy changes, conditional access exclusions, and authentication method registration or removal
- SaaS and Office Suite administrative audit logs for account security setting changes
- IaaS identity and access logs showing privilege, policy, or authentication control changes
- Endpoint file and configuration monitoring for authentication-related files, including Windows hosts file changes where MFA calls could be redirected
- Privileged account management records showing who approved or performed MFA exceptions
Detection direction
- Baseline normal MFA administration activity and alert on changes to MFA enforcement, user exclusions, authentication method registration, and broad group-level policy changes.
- Prioritize high-signal detections for privileged accounts, service administrators, identity administrators, and accounts tied to critical business systems.
- Correlate MFA changes with recent suspicious authentication, MFA request generation or bypass indicators, new device or location patterns, and privilege changes.
- Tune for legitimate help desk, access recovery, and onboarding workflows to reduce false positives while preserving review of high-risk exceptions.
- Validate that endpoint monitoring can see authentication process tampering where applicable, not only cloud identity events.
Mitigation priorities
- Apply User Account Management by limiting who can modify MFA settings, create exclusions, or register authentication methods for other users.
- Strengthen MFA governance by minimizing exceptions, reviewing excluded users, and applying stricter controls to privileged and critical accounts.
- Use auditing to record and regularly review MFA configuration, access policy, authentication method, and account lifecycle changes.
- Ensure fail-open MFA behavior is identified and risk accepted only where business justified; prefer designs that do not silently bypass MFA when the MFA path fails.
- Include MFA modification checks in incident response playbooks so responders review affected accounts, groups, policies, and local authentication configuration before declaring containment.
Analyst notes and limits
The supplied ATT&CK relationships show this sub-technique is mitigated by User Account Management, Multi-factor Authentication, and Audit, and is detected by DET0190. ATT&CK also relates use by Scattered Spider, AADInternals, SLOWPULSE, and a named campaign; these relationships support awareness and validation, not assumptions about local exposure or current activity.
Official ATT&CK detection guidance is not provided for this technique, so detection content must be derived from local identity, SaaS, IaaS, endpoint, and change-management telemetry. The object supports broad platform coverage, but exact event names, log availability, and control behavior depend on the organization’s identity provider, MFA implementation, and endpoint configuration.
Multi-Factor Authentication
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]
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.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1556 | Modify Authentication Process | This object subtechnique of Modify Authentication Process. |
Groups, software, and campaigns
G1015: Scattered Spider
Scattered Spider is a native English-speaking cybercriminal group active since at least 2022. [1] [2] The group initially targeted customer relationship management (CRM) providers, business process outsourcing (BPO) firms, and telecommunications and technology companies before expanding in 2023 to gaming, hospitality, retail, managed service provider (MSP), manufacturing, and financial sectors. [2] Scattered Spider relies heavily on social engineering, including impersonating IT and help-desk staff, to gain initial access, bypass multi-factor authentication (MFA), and compromise enterprise networks. The group has adapted its tooling to evade endpoint detection and response (EDR) defenses and used ransomware for financial gain. [3] [4] [5] Scattered Spider had expanded into hybrid cloud and identity environments, using help-desk impersonation and MFA bypass to obtain administrator access in Okta, AWS, and Office 365. [6]
S1104: SLOWPULSE
S0677: AADInternals
AADInternals is a PowerShell-based framework for administering, enumerating, and exploiting Azure Active Directory. The tool is publicly available on GitHub.[1][2]
C0063: 2025 Poland Wiper Attacks
2025 Poland Wiper Attacks is a Russian state-sponsored campaign that conducted destructive cyberattacks against Polish energy infrastructure in December 2025. Targets included more than 30 wind and photovoltaic farms, a combined heat and power (CHP) plant, and a manufacturing sector company. The attacks on the distributed energy resources (DER) disrupted communications between affected facilities and the distribution system operator, but did not impact electricity generation or heat supply. Across the campaign, threat actors deployed two previously undocumented wiper tools, DynoWiper, a Windows-based wiper and LazyWiper, a PowerShell wiper, distributed via malicious Group Policy Objects. At the CHP plant, threat actors had maintained access since at least March 2025, using that foothold to obtain credentials and move laterally before attempting wiper deployment. Some reporting has assessed the activity to be consistent with Russian Federal Security Service (FSB) threat activity group Dragonfly, also tracked as STATIC TUNDRA, while other reporting attributes the destructive wiper activities to the Russian General Staff Main Intelligence Directorate (GRU) threat activity group ELECTRUM, also tracked as Sandworm Team.[1][2][3][4]
All related ATT&CK context
Mitigation direction
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 | 2.0 | Current bundle | c17c7c5ec28d… |
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]
Mandiant APT42
Mandiant. (n.d.). APT42: Crooked Charms, Cons and Compromise. Retrieved September 16, 2022.
Open source URL -
[2]
Azure AD Conditional Access Exclusions
Microsoft. (2022, August 26). Use Azure AD access reviews to manage users excluded from Conditional Access policies. Retrieved August 30, 2022.
Open source URL -
[3]
Russians Exploit Default MFA Protocol - CISA March 2022
Cyber Security Infrastructure Agency. (2022, March 15). Russian State-Sponsored Cyber Actors Gain Network Access by Exploiting Default Multifactor Authentication Protocols and “PrintNightmare” Vulnerability. Retrieved May 31, 2022.
Open source URL -
[4]
mitre-attack T1556.006Open 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.