LiveActive security incident?Get immediate response
MITRE ATT&CK® Technique

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]

EnterpriseT1556.001Sub-techniqueObject v3.0Modified
Discuss defensive coverageBack to ATT&CK
Glexia's Take · Automated analysis

Security context for executives and security teams

Automation confidenceHigh

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.
Additional 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.

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Official MITRE ATT&CK definition

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]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

1 rows
DomainIDNameRelationship / procedure
EnterpriseT1556Modify Authentication ProcessThis object subtechnique of Modify Authentication Process.
Associated objects

Groups, software, and campaigns

GroupEnterprise

G0114: Chimera

Chimera is a suspected China-based threat group that has been active since at least 2018 targeting the semiconductor industry in Taiwan as well as data from the airline industry.[1][2]

Relationship explorer

All related ATT&CK context

subtechnique of · TechniqueT1556: Modify Authentication ProcessEnterpriseuses · GroupG0114: ChimeraEnterprisemitigates · MitigationM1026: Privileged Account ManagementEnterprisemitigates · MitigationM1025: Privileged Process IntegrityEnterprisedetects · Detection StrategyDET0271: Detect Domain Controller Authentication Process Modification (Skeleton Key)Enterprisemitigates · MitigationM1032: Multi-factor AuthenticationEnterprisemitigates · MitigationM1017: User TrainingEnterpriseuses · MalwareS0007: Skeleton KeyEnterprise
Mitigations

Mitigation direction

MitigationEnterprise

M1026: Privileged Account Management

Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts). This includes restricting access, limiting the scope of permissions, monitoring privileged account usage, and ensuring accountability through logging and auditing.This mitigation can be implemented through the following measures:

Account Permissions and Roles:

- Implement RBAC and least privilege principles to allocate permissions securely. - Use tools like Active Directory Group Policies to enforce access restrictions.

Credential Security:

- Deploy password vaulting tools like CyberArk, HashiCorp Vault, or KeePass for secure storage and rotation of credentials. - Enforce password policies for complexity, uniqueness, and expiration using tools like Microsoft Group Policy Objects (GPO).

Multi-Factor Authentication (MFA):

- Enforce MFA for all privileged accounts using Duo Security, Okta, or Microsoft Azure AD MFA.

Privileged Access Management (PAM):

- Use PAM solutions like CyberArk, BeyondTrust, or Thycotic to manage, monitor, and audit privileged access.

Auditing and Monitoring:

- Integrate activity monitoring into your SIEM (e.g., Splunk or QRadar) to detect and alert on anomalous privileged account usage.

Just-In-Time Access:

- Deploy JIT solutions like Azure Privileged Identity Management (PIM) or configure ephemeral roles in AWS and GCP to grant time-limited elevated permissions.

*Tools for Implementation*

Privileged Access Management (PAM):

- CyberArk, BeyondTrust, Thycotic, HashiCorp Vault.

Credential Management:

- Microsoft LAPS (Local Admin Password Solution), Password Safe, HashiCorp Vault, KeePass.

Multi-Factor Authentication:

- Duo Security, Okta, Microsoft Azure MFA, Google Authenticator.

Linux Privilege Management:

- sudo configuration, SELinux, AppArmor.

Just-In-Time Access:

- Azure Privileged Identity Management (PIM), AWS IAM Roles with session constraints, GCP Identity-Aware Proxy.

MitigationEnterprise

M1025: Privileged Process Integrity

Privileged Process Integrity focuses on defending highly privileged processes (e.g., system services, antivirus, or authentication processes) from tampering, injection, or compromise by adversaries. These processes often interact with critical components, making them prime targets for techniques like code injection, privilege escalation, and process manipulation. This mitigation can be implemented through the following measures:

Protected Process Mechanisms:

- Enable RunAsPPL on Windows systems to protect LSASS and other critical processes. - Use registry modifications to enforce protected process settings: `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL`

Anti-Injection and Memory Protection:

- Enable Control Flow Guard (CFG), DEP, and ASLR to protect against process memory tampering. - Deploy endpoint protection tools that actively block process injection attempts.

Code Signing Validation:

- Implement policies for Windows Defender Application Control (WDAC) or AppLocker to enforce execution of signed binaries. - Ensure critical processes are signed with valid certificates.

Access Controls:

- Use DACLs and MIC to limit which users and processes can interact with privileged processes. - Disable unnecessary debugging capabilities for high-privileged processes.

Kernel-Level Protections:

- Ensure Kernel Patch Protection (PatchGuard) is enabled on Windows systems. - Leverage SELinux or AppArmor on Linux to enforce kernel-level security policies.

*Tools for Implementation*

Protected Process Light (PPL):

- RunAsPPL (Windows) - Windows Defender Credential Guard

Code Integrity and Signing:

- Windows Defender Application Control (WDAC) - AppLocker - SELinux/AppArmor (Linux)

Memory Protection:

- Control Flow Guard (CFG), Data Execution Prevention (DEP), ASLR

Process Isolation/Sandboxing:

- Firejail (Linux Sandbox) - Windows Sandbox - QEMU/KVM-based isolation

Kernel Protection:

- PatchGuard (Windows Kernel Patch Protection) - SELinux (Mandatory Access Control for Linux) - AppArmor

MitigationEnterprise

M1032: Multi-factor Authentication

Multi-Factor Authentication (MFA) enhances security by requiring users to provide at least two forms of verification to prove their identity before granting access. These factors typically include:

- *Something you know*: Passwords, PINs. - *Something you have*: Physical tokens, smartphone authenticator apps. - *Something you are*: Biometric data such as fingerprints, facial recognition, or retinal scans.

Implementing MFA across all critical systems and services ensures robust protection against account takeover and unauthorized access. This mitigation can be implemented through the following measures:

Identity and Access Management (IAM):

- Use IAM solutions like Azure Active Directory, Okta, or AWS IAM to enforce MFA policies for all user logins, especially for privileged roles. - Enable conditional access policies to enforce MFA for risky sign-ins (e.g., unfamiliar devices, geolocations). - Enable Conditional Access policies to only allow logins from trusted devices, such as those enrolled in Intune or joined via Hybrid/Entra.

Authentication Tools and Methods:

- Use authenticator applications such as Google Authenticator, Microsoft Authenticator, or Authy for time-based one-time passwords (TOTP). - Deploy hardware-based tokens like YubiKey, RSA SecurID, or smart cards for additional security. - Enforce biometric authentication for compatible devices and applications.

Secure Legacy Systems:

- Integrate MFA solutions with older systems using third-party tools like Duo Security or Thales SafeNet. - Enable RADIUS/NPS servers to facilitate MFA for VPNs, RDP, and other network logins.

Monitoring and Alerting:

- Use SIEM tools to monitor failed MFA attempts, login anomalies, or brute-force attempts against MFA systems. - Implement alerts for suspicious MFA activities, such as repeated failed codes or new device registrations.

Training and Policy Enforcement:

- Educate employees on the importance of MFA and secure authenticator usage. - Enforce policies that require MFA on all critical systems, especially for remote access, privileged accounts, and cloud applications.

MitigationEnterprise

M1017: User Training

User Training involves educating employees and contractors on recognizing, reporting, and preventing cyber threats that rely on human interaction, such as phishing, social engineering, and other manipulative techniques. Comprehensive training programs create a human firewall by empowering users to be an active component of the organization's cybersecurity defenses. This mitigation can be implemented through the following measures:

Create Comprehensive Training Programs:

- Design training modules tailored to the organization's risk profile, covering topics such as phishing, password management, and incident reporting. - Provide role-specific training for high-risk employees, such as helpdesk staff or executives.

Use Simulated Exercises:

- Conduct phishing simulations to measure user susceptibility and provide targeted follow-up training. - Run social engineering drills to evaluate employee responses and reinforce protocols.

Leverage Gamification and Engagement:

- Introduce interactive learning methods such as quizzes, gamified challenges, and rewards for successful detection and reporting of threats.

Incorporate Security Policies into Onboarding:

- Include cybersecurity training as part of the onboarding process for new employees. - Provide easy-to-understand materials outlining acceptable use policies and reporting procedures.

Regular Refresher Courses:

- Update training materials to include emerging threats and techniques used by adversaries. - Ensure all employees complete periodic refresher courses to stay informed.

Emphasize Real-World Scenarios:

- Use case studies of recent attacks to demonstrate the consequences of successful phishing or social engineering. - Discuss how specific employee actions can prevent or mitigate such attacks.

Change history

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.

ATT&CK release
19.1
Object version
3.0
Created
Modified
Raw hash
b729f13c47e655a9...
Imported snapshots across ATT&CK releases(1)
ReleaseBundle importedObject versionModifiedStatusRaw hash
19.13.0Current bundleb729f13c47e6…
Raw source

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.

Open mirrored raw JSONOpen MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Dell Skeleton

    Dell SecureWorks. (2015, January 12). Skeleton Key Malware Analysis. Retrieved April 8, 2019.

    Open source URL
  2. [2]
    Cycraft Chimera April 2020

    Cycraft. (2020, April 15). APT Group Chimera - APT Operation Skeleton key Targets Taiwan Semiconductor Vendors. Retrieved August 24, 2020..

    Open source URL
  3. [3]
    TechNet Credential Theft

    Microsoft. (2016, April 15). Attractive Accounts for Credential Theft. Retrieved June 3, 2016.

    Open source URL
  4. [4]
    TechNet Least Privilege

    Microsoft. (2016, April 16). Implementing Least-Privilege Administrative Models. Retrieved June 3, 2016.

    Open source URL
  5. [5]
    Microsoft Securing Privileged Access

    Plett, C., Poggemeyer, L. (12, October 26). Securing Privileged Access Reference Material. Retrieved April 25, 2017.

    Open source URL
  6. [6]
    Microsoft LSA

    Microsoft. (2013, July 31). Configuring Additional LSA Protection. Retrieved February 13, 2015.

    Open source URL
  7. [7]
    Dell Skeleton

    Dell SecureWorks. (2015, January 12). Skeleton Key Malware Analysis. Retrieved April 8, 2019.

    Open source URL
  8. [8]
    Dell Skeleton

    Dell SecureWorks. (2015, January 12). Skeleton Key Malware Analysis. Retrieved April 8, 2019.

    Open source URL
  9. [9]
    mitre-attackT1556.001
    Open source URL
  10. [10]
    mitre-attackT1556.001
    Open source URL
  11. [11]
    mitre-attackT1556.001
    Open source URL
  12. [12]
    Cycraft Chimera April 2020

    Cycraft. (2020, April 15). APT Group Chimera - APT Operation Skeleton key Targets Taiwan Semiconductor Vendors. Retrieved August 24, 2020..

    Open source URL
  13. [13]
    Microsoft Securing Privileged Access

    Plett, C., Poggemeyer, L. (12, October 26). Securing Privileged Access Reference Material. Retrieved April 25, 2017.

    Open source URL
  14. [14]
    TechNet Credential Theft

    Microsoft. (2016, April 15). Attractive Accounts for Credential Theft. Retrieved June 3, 2016.

    Open source URL
  15. [15]
    TechNet Least Privilege

    Microsoft. (2016, April 16). Implementing Least-Privilege Administrative Models. Retrieved June 3, 2016.

    Open source URL
  16. [16]
    Microsoft LSA

    Microsoft. (2013, July 31). Configuring Additional LSA Protection. Retrieved February 13, 2015.

    Open source URL
  17. [17]
    Dell Skeleton

    Dell SecureWorks. (2015, January 12). Skeleton Key Malware Analysis. Retrieved April 8, 2019.

    Open source URL
Source and licensing

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.

Official MITRE ATT&CK siteOfficial STIX data repositoryMITRE ATT&CK terms of use