AN0543: Analytic 0543
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.
Analyst context for executives and security teams
This analytic matters because MFA is often treated as a primary control for reducing account-takeover risk. The ATT&CK object focuses on signs that MFA expectations may have been weakened or bypassed on Windows, including registry or Group Policy changes, PowerShell activity affecting MFA-related attributes, and successful logins that did not receive the expected MFA challenge.
Executive priority
Security leaders should treat this as a control-assurance use case: can the organization prove that MFA enforcement cannot be silently weakened, and can the SOC detect when authentication behavior no longer matches policy? The business value is strongest for identity resilience, incident response triage, audit evidence, and prioritizing monitoring around policy changes that could reduce authentication protection.
Technical view
For Windows environments, validate whether telemetry exists for registry changes, Group Policy modifications, PowerShell activity, and authentication sessions where MFA was expected but not challenged. Because ATT&CK does not provide detailed detection logic for this analytic, teams should define local baselines for authorized MFA policy administration and compare login outcomes against expected MFA requirements.
Likely telemetry
- Windows registry modification events related to authentication or MFA configuration
- Group Policy change records and administrative change logs
- PowerShell execution and script block/module logging where available
- Authentication and session logs showing successful logins and whether MFA challenge occurred
- Identity or access policy audit logs that record MFA-related attribute changes
Detection direction
- Correlate MFA-related configuration changes with the administrator account, host, time, and approved change record.
- Review PowerShell activity that modifies MFA-related attributes, especially when executed outside normal administration patterns.
- Look for successful sessions where policy indicates MFA should have been required but no challenge is recorded.
- Tune for legitimate help desk, identity administration, and planned policy maintenance activity to reduce false positives.
- Confirm visibility gaps: registry, Group Policy, PowerShell, and authentication telemetry often live in different systems and may not be retained or correlated by default.
Mitigation priorities
- Establish explicit change control for MFA policy, registry, and Group Policy settings that affect authentication strength.
- Restrict administrative permissions capable of weakening MFA-related configuration.
- Enable and retain Windows, PowerShell, Group Policy, and authentication audit data needed to validate this analytic.
- Regularly test whether MFA enforcement and logging behave as expected for representative users and privileged accounts.
- Use incident response playbooks that treat unexpected MFA weakening as an identity-security event requiring rapid scoping.
Analyst notes and limits
This object is a detection analytic, not a technique description. It provides a concise description but no official detection logic, tactics, or relationship context. Local policy definitions are required to determine when MFA was expected and whether a successful login without challenge is suspicious.
The supplied ATT&CK fields support only Windows as a platform and do not provide vendor-specific telemetry, event IDs, detection queries, adversary attribution, active exploitation claims, or mapped relationships. Conclusions should therefore be validated against the organization’s identity architecture and logging coverage.
Analytic 0543
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.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 1.0 | Current bundle | f5c123fa9f7a… |
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]
mitre-attack AN0543Open 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.