T1556.001: Domain Controller Authentication
Adversaries may patch the authentication process on a domain controller to bypass the typical authentication mechanisms and enable access to accounts.
Malware may be used to inject false credentials into the authentication process on a domain controller with the intent of creating a backdoor used to access any user’s account and/or credentials (ex: Skeleton Key). Skeleton key works through a patch on an enterprise domain controller authentication process (LSASS) with credentials that adversaries may use to bypass the standard authentication system. Once patched, an adversary can use the injected password to successfully authenticate as any domain user account (until the the skeleton key is erased from memory by a reboot of the domain controller). Authenticated access may enable unfettered access to hosts and/or resources within single-factor authentication environments.[1]
Analyst context for executives and security teams
Domain Controller Authentication is high-consequence because it targets the authentication process on a Windows domain controller itself. If an adversary can patch LSASS with a backdoor password such as Skeleton Key, normal password-based trust decisions can become unreliable: the attacker may authenticate as domain users until the in-memory modification is removed, such as by reboot. For leaders, this is less about one endpoint alert and more about whether the organization can prove its domain controllers are hardened, closely monitored, and covered by incident response procedures for identity-system compromise.
Executive priority
Treat this as a critical identity-resilience scenario. A modified domain controller authentication process can undermine single-factor authentication environments and create broad access risk across hosts and resources. Priority questions for executives and risk owners: Are domain controllers managed as tier-zero assets? Is privileged access tightly controlled and audited? Is MFA applied to critical access paths where feasible? Can the SOC and IR team detect or investigate authentication-process tampering on domain controllers, not just failed logons? Evidence of privileged process protection, privileged account management, MFA deployment, and domain controller monitoring can also support audit and compliance readiness.
Technical view
This Windows sub-technique sits under Modify Authentication Process and spans defense impairment, persistence, and credential access. The supplied ATT&CK description centers on patching the LSASS authentication process on a domain controller to inject false credentials and enable authentication as domain users. ATT&CK does not provide official detection text for this object, but a related detection strategy exists: DET0271, Detect Domain Controller Authentication Process Modification (Skeleton Key). SOC and IR teams should validate controls around domain controller process integrity, suspicious modification or injection into authentication processes, anomalous privileged access to domain controllers, and unusual successful authentications that may not align with expected credential use. Relationship context also links the behavior to Skeleton Key software and notes use by Chimera; use that as threat-intelligence context, not as proof of current activity in any environment.
Likely telemetry
- Windows domain controller security and authentication logs
- Process execution and process access telemetry on domain controllers, especially involving LSASS
- Endpoint detection or host integrity signals for privileged process tampering, injection, or memory modification
- Privileged account logon and administrative activity records for domain controllers
- Directory service and domain controller operational logs
Detection direction
- Validate whether domain controllers have telemetry deep enough to observe privileged process tampering, not only authentication success or failure.
- Use the DET0271 relationship as the ATT&CK-aligned detection direction for Skeleton Key-style domain controller authentication process modification.
- Tune for high-fidelity signals involving LSASS modification or suspicious access to authentication processes on domain controllers; these should be rare and require rapid triage.
- Correlate successful authentications, privileged account activity, and domain controller process-integrity events to reduce blind spots where a backdoor password could make logons appear superficially valid.
- Account for false positives from approved security tooling, administrative diagnostics, or maintenance that legitimately interacts with protected processes; require allowlisting to be tightly governed and documented.
Mitigation priorities
- Prioritize privileged process integrity controls for authentication processes on Windows domain controllers, including protected process mechanisms where appropriate and supported.
- Strengthen privileged account management: least privilege, restricted administrative access to domain controllers, monitoring of privileged account use, and accountability through logging and auditing.
- Deploy multi-factor authentication for critical systems and services to reduce reliance on single-factor authentication, which the ATT&CK description identifies as a key exposure condition.
- Maintain user training as a supporting control for threats that may begin with human interaction, while recognizing it is not the primary control for LSASS tampering on a domain controller.
- Treat domain controllers as tier-zero assets in hardening, monitoring, change control, and incident response planning.
Analyst notes and limits
The most important defensive decision is whether the organization can trust and verify its domain controllers under compromise conditions. This technique is material because it can turn apparently valid authentication into a persistence and credential-access problem. The Skeleton Key software relationship provides concrete context for what this behavior has looked like in ATT&CK, and the Chimera relationship provides group-use context without implying current activity or exposure.
ATT&CK provides no official detection text for this object, so detection guidance is derived from the description, platforms, tactics, and the DET0271 detection-strategy relationship. The supplied fields support Windows domain controller scope only. Local architecture, logging depth, EDR capabilities, MFA coverage, privileged access design, and incident-response procedures are required to determine actual defensive coverage.
Domain Controller Authentication
Adversaries may patch the authentication process on a domain controller to bypass the typical authentication mechanisms and enable access to accounts.
Malware may be used to inject false credentials into the authentication process on a domain controller with the intent of creating a backdoor used to access any user’s account and/or credentials (ex: Skeleton Key). Skeleton key works through a patch on an enterprise domain controller authentication process (LSASS) with credentials that adversaries may use to bypass the standard authentication system. Once patched, an adversary can use the injected password to successfully authenticate as any domain user account (until the the skeleton key is erased from memory by a reboot of the domain controller). Authenticated access may enable unfettered access to hosts and/or resources within single-factor authentication environments.[1]
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
G0114: Chimera
S0007: Skeleton Key
Skeleton Key is malware used to inject false credentials into domain controllers with the intent of creating a backdoor password. [1] Functionality similar to Skeleton Key is included as a module in Mimikatz.
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 | 3.0 | Current bundle | b729f13c47e6… |
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]
Dell Skeleton
Dell SecureWorks. (2015, January 12). Skeleton Key Malware Analysis. Retrieved April 8, 2019.
Open source URL -
[2]
mitre-attack T1556.001Open 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.