MITRE ATT&CK T1556.001 Domain Controller Authentication: Detecting and Responding to Skeleton Key Style Patching

An attacker who patches the authentication code on a domain controller can sign in as any account in the domain with one password of their choosing, while every real user keeps logging in as normal. That is ATT&CK T1556.001 Domain Controller Authentication, best known from the Skeleton Key malware. It leaves almost nothing on disk, sends no network traffic of its own and disappears on reboot, so it is easy to miss and easy to under-react to. This guide goes deeper than the parent MITRE ATT&CK T1556 Modify Authentication Process Guide: the telemetry that actually catches in-memory patching on a domain controller, the hardening that makes it harder, and how to respond when you find it. It is written for detection engineers, Active Directory administrators and incident responders.

Key takeaways

• It is a Tier 0 compromise signal, not a malware clean-up. Deploying a Skeleton Key style patch needs domain administrator rights first, so finding one means your highest privilege has already been lost.
• A reboot removes the patch, not the attacker. The change lives in LSASS memory on the domain controller and is cleared on restart, but the credentials used to deploy it are still in the attacker's hands.
• Detect the delivery and the side effects. Unexpected service installs, remote execution and LSASS access on domain controllers, plus Kerberos encryption downgrade, are more reliable than looking for the patch itself.
• LSA protection raises the bar on domain controllers. Running LSASS as a protected process blocks non-protected processes from reading its memory or injecting code, and a UEFI lock stops a simple registry change from turning it off.
• Service accounts are exposed with no MFA safety net. A master password works for any domain account, and the non-human accounts that cannot use multi-factor authentication are the ones it cannot be stopped on at sign-in.

What T1556.001 is and how it differs from the parent

In ATT&CK v20 the sub-technique sits under T1556 Modify Authentication Process and is listed under the Credential Access, Persistence and Defense Impairment tactics. ATT&CK describes adversaries patching "the authentication process on a domain controller to bypass the typical authentication mechanisms", for example by injecting false credentials so that a backdoor password works for any user account. The page notes that this persists only until the domain controller reboots.

ATT&CK lists two procedure examples. S0007 Skeleton Key patches the domain controller authentication process with a backdoor password that works for all accounts. G0114 Chimera is recorded as having malware that altered the NTLM authentication program on domain controllers so the group could log in without a valid credential.

The parent T1556 guide covers nine sub-techniques at overview level, from password filter DLLs to conditional access changes. This page stays on the domain controller case because its evidence and its response are different from the rest:

It is also distinct from MITRE ATT&CK T1003.001 OS Credential Dumping. Both start with access to LSASS, but credential dumping reads secrets out, while T1556.001 writes code in to change how authentication decisions are made. Many of the same controls help with both.

How the attack works, at a defender's level of detail

ATT&CK describes Skeleton Key (S0007) as malware that patches a domain controller's authentication process with a backdoor password, which then works for every account authenticating to that controller. The points that matter for defenders, as NHI Mgmt Group reads them, are these:

• Access first: changing the authentication process on a domain controller needs privileged access to that domain controller, so a deployment means a Tier 0 compromise has already happened.
• Real users unaffected: legitimate users keep signing in with their own passwords, which is why nobody raises a help desk ticket.
• Single-factor services exposed: any service that relies on the Active Directory password alone, such as webmail and VPN, will accept the master password.
• Host evidence, not network evidence: the change sits inside the domain controller, so detection has to come from host and authentication telemetry rather than network traffic.
• Reboot and redeploy: an in-memory patch is lost when the domain controller restarts, and an attacker who still has access can simply apply it again.

Microsoft Defender for Identity adds one more observable. Its alert description says Skeleton Key "often uses weaker encryption algorithms to hash the user's passwords on the domain controller", which shows up as Kerberos encryption that is weaker than the learned norm. Removing RC4 from your environment therefore helps twice: it shrinks the attack surface and it makes any RC4 use stand out. See the Kerberos RC4 Deprecation guide.

Detection: what to collect on domain controllers

Because the patch itself is in memory, detection works best as a set of layers around it. Domain controllers are single-role servers, and Microsoft's Active Directory monitoring guidance notes that process tracking "can be safely turned on all the time" on them, so the volume concern that applies to member servers is much smaller here.

Turning signals into detections

• Allow-list LSASS access on domain controllers: the Sysmon documentation warns that ProcessAccess logging "should only be done so with filters that remove expected accesses". On domain controllers the expected list is short, so build it once from a baseline and alert on everything else.
• Correlate a privileged remote session with a service install: a domain admin logon to a domain controller followed within minutes by a new service or rundll32 process is a high-value pairing.
• Watch dormant and service accounts: a master password lets an attacker use accounts nobody watches. A successful interactive or network logon by a service account from a new source, or by a disabled-in-practice account, deserves a look. The Active Directory Security Monitoring and Event IDs Guide covers the wider event set.
• Treat Kerberos downgrade as high priority on Tier 0: Defender for Identity lists the alert at Medium severity and maps it to T1556.001. Our recommendation is to raise its priority when the source or target is a domain controller or a privileged account.
• Use memory scanning when you suspect it: scan memory images collected from domain controllers during an investigation with your EDR or forensic tooling, as the change lives in LSASS memory.

Prevention and hardening

ATT&CK maps four mitigations to T1556.001: M1025 Privileged Process Integrity, M1026 Privileged Account Management, M1032 Multi-factor Authentication and M1017 User Training. In practice the first three carry the weight.

Protect LSASS on every domain controller (M1025)

Microsoft's LSA protection documentation says it prevents "nonprotected processes from reading memory and injecting code" into LSA. Key points for domain controllers:

• Use the UEFI lock where hardware supports it: setting RunAsPPL to 1 stores the setting in a UEFI variable, and Microsoft states that with UEFI lock and Secure Boot, changing the registry key "has no effect". The value 2 configures protection without the lock and Microsoft says it is only enforced on Windows 11 22H2 and later, so confirm the current behaviour for your Windows Server version in Microsoft's documentation.
• Audit before you enforce: Microsoft provides an audit mode that logs CodeIntegrity events 3065 and 3066 for plug-ins that would fail to load. Smart card drivers, cryptographic plug-ins and password filters must be Microsoft signed to load into a protected LSA.
• Do not rely on client defaults: the automatic enablement Microsoft describes applies to new Windows 11 22H2 and later client installs that meet set criteria. Domain controllers need it configured deliberately.
• Know the limit: protected process status raises the cost of in-memory patching but an attacker with kernel access can still interfere. Driver loading on domain controllers should be rare and reviewed.

Keep domain admin rights away from the attacker (M1026)

• Tier the administration model: domain admin credentials should only ever be used from privileged access workstations into Tier 0 systems. See the Tiered Administration and Enterprise Access Model Guide and the Privileged Access Workstations Guide.
• Shrink the domain admin population: fewer standing members of Domain Admins, Enterprise Admins and equivalent groups means fewer credentials to steal. Use just-in-time elevation where you can.
• Restrict remote execution to domain controllers: limit which hosts and accounts can reach domain controllers over SMB administrative shares and remote service management. The AD Domain Controller Hardening Guide covers the baseline.

Make a master password insufficient (M1032)

ATT&CK maps Multi-factor Authentication (M1032) to this sub-technique. A patched domain controller still accepts the backdoor password, but services that also require a second factor will not let the attacker through on the password alone. Prioritise VPN, remote desktop gateways, webmail and privileged portals. See the Phishing-Resistant MFA Guide.

Where identity fits

T1556.001 changes the rules for every identity in the domain at once, which makes it a non-human identity problem as much as a human one. Service accounts, scheduled task accounts and application pool identities authenticate to Active Directory with a password and usually cannot use MFA, so the M1032 safety net does not apply to them. With a master password, an attacker can act as any of them, and their activity is often trusted and lightly monitored.

• Move service accounts to managed identities: group managed service accounts and similar mechanisms reduce the number of human-known passwords, and they make interactive sign-ins by those accounts clearly abnormal. See the Service Account Security Guide.
• Restrict where non-human accounts can log on: logon rights limited to the hosts they serve turn a master password into far less access.
• Baseline non-human account behaviour: source hosts, logon types and times for each service account are the comparison point that exposes misuse.

Responding to a suspected patch

The steps below are NHI Mgmt Group recommendations. Adapt them to your incident response plan and the Incident Response Guide.

1. Preserve memory before rebooting: a reboot destroys the best evidence. Capture a memory image of the affected domain controller with your forensic tooling first, if it can be done safely.
2. Assume every domain controller is affected: attackers have typically deployed to more than one. Check all of them for the same delivery and LSASS signals.
3. Treat it as a Tier 0 compromise: the deploying account had privileged access to domain controllers. Identify it, and reset privileged account credentials from a clean administrative path.
4. Reboot domain controllers in a planned order: this clears the in-memory patch. Watch for redeployment as a sign the attacker still has access.
5. Review sign-ins during the exposure window: any account, human or non-human, could have been used with the master password. Prioritise privileged and service accounts that signed in from unusual sources.
6. Escalate to forest recovery planning if trust is lost: if you cannot establish when access began or what else was changed, use the Active Directory Forest Recovery Runbook Template.

Common failure patterns

• Rebooting first: the domain controller is restarted to fix replication or performance issues and the only evidence of the patch goes with it.
• Closing the alert as malware removed: the patch is gone after a reboot, but the domain admin credentials that deployed it are not rotated.
• LSA protection on workstations only: client defaults or a workstation policy are assumed to cover domain controllers.
• Unfiltered LSASS logging: ProcessAccess logging is switched on without an allow-list, generates noise and is turned off again.
• RC4 still everywhere: weak Kerberos encryption is normal in the environment, so a downgrade blends in.
• MFA only for people: service accounts with interactive logon rights remain usable with a single password.

Framework mapping

Practitioner checklist

• Enable LSA protection on every domain controller, with UEFI lock where the hardware supports it, after an audit mode pass.
• Audit service installs (4697) and process creation with command lines on all domain controllers, and alert on any outside change windows.
• Log process access and remote thread creation targeting lsass.exe on domain controllers with an allow-list of expected tools.
• Monitor Kerberos encryption types and treat downgrades involving domain controllers or privileged accounts as high priority.
• Remove RC4 from Kerberos so any use of it stands out.
• Limit domain admin membership and use privileged access workstations for all Tier 0 administration.
• Require MFA on VPN, webmail, remote desktop gateways and privileged portals.
• Restrict logon rights for service accounts and baseline where each one normally signs in.
• Write a runbook step that captures domain controller memory before any reboot during a suspected compromise.

Standards and references

• MITRE ATT&CK: Modify Authentication Process: Domain Controller Authentication (T1556.001)
• MITRE ATT&CK: Skeleton Key (S0007)
• Microsoft Learn: Configure added LSA protection
• Microsoft Learn: Defender for Identity security alerts (classic)
• Microsoft Learn: Monitoring Active Directory for signs of compromise
• Microsoft Learn: 4697(S) A service was installed in the system
• Microsoft Sysinternals: Sysmon

Related NHI Mgmt Group resources: MITRE ATT&CK T1556 Modify Authentication Process Guide · AD Domain Controller Hardening Guide · DPAPI and Windows secret stores · MITRE ATT&CK T1558 Steal or Forge Kerberos Tickets Guide