Skeleton Key Attack — In-Memory LSASS Patch for Universal DC Authentication

MITRE ATT&CK

Security Relevance

Skeleton Key is one of the most dangerous AD persistence techniques because it is nearly invisible: it requires no new accounts, no scheduled tasks, no registry changes, and no disk writes. Standard AD queries, auditing, and monitoring tools will show nothing abnormal. An attacker with Domain Admin access can apply the skeleton key and then have persistent, universal authentication capability for the lifetime of the DC's uptime — without any indicator in Active Directory itself. The only reliable event-log signals are the tooling used to deploy it (Mimikatz process execution, driver load) rather than the authentication backdoor itself. Microsoft Defender for Identity (MDI) is the only Windows-native product that reliably detects the LSASS patching behavior via DC replication traffic analysis.

Indicators of Malicious Use

• ⚑Event 4688: mimikatz.exe executing on a domain controller — the process name alone on a DC is a critical indicator regardless of arguments
• ⚑Event 7045: mimidrv.sys service installed — Mimikatz uses this driver for kernel-level LSASS access on modern Windows
• ⚑Event 4104 (PowerShell script block): misc::skeleton, Invoke-Mimikatz, or skeleton key strings in script block content
• ⚑Event 4688: lsass.exe spawning child processes or being accessed by non-standard processes — LSASS patching requires process injection or memory write access
• ⚑Defender for Identity alert: 'Skeleton Key attack (encryption downgrade)' — MDI detects the RC4 downgrade behavior the skeleton key patch causes in Kerberos authentication
• ⚑Unexpected NTLM authentication to a DC: skeleton key patches the NTLM authentication path; if your domain enforces Kerberos, sudden NTLM successes can indicate LSASS modification

Example Log Entry

Event ID: 4688 — A new process has been created

Creator Subject:
  Security ID:      CORP\DomainAdmin
  Account Name:     DomainAdmin
  Logon ID:         0x1F4A22

Target Process:
  New Process Name: C:\Users\DomainAdmin\Downloads\m.exe
                    ← renamed Mimikatz binary
  Process Command Line: m.exe privilege::debug misc::skeleton

Note: privilege::debug is required before misc::skeleton
— it grants SeDebugPrivilege to access and patch LSASS.
Event 4672 (special privileges) with SeDebugPrivilege will
precede this if process command-line auditing is enabled.

----

Event ID: 7045 — A new service was installed

Service Name:   mimidrv
Service File:   \??\C:\Users\DomainAdmin\Downloads\mimidrv.sys
Service Type:   kernel mode driver
Start Type:     demand start
Account:        LocalSystem

Investigation Steps

1. 1.Check Event 4688 on all domain controllers for mimikatz.exe or known variants (mimi.exe, m.exe, invoke-mimikatz). The presence of Mimikatz on a DC is an immediate critical escalation regardless of whether skeleton key was used.
2. 2.Check Event 7045 for mimidrv.sys or any unrecognized kernel driver installed on DCs. Mimikatz requires the driver for kernel-level LSASS access on Windows 10/Server 2016+.
3. 3.Review Event 4104 (PowerShell) on DCs for misc::skeleton, Invoke-Mimikatz, or skeleton key strings. Many attackers use PowerShell-based Mimikatz variants (Invoke-Mimikatz) to avoid dropping a binary.
4. 4.Check Event 4672 (special privileges) on DCs — privilege::debug (SeDebugPrivilege) is a prerequisite for skeleton key patching. An interactive session with SeDebugPrivilege on a DC that is not a domain admin task is suspicious.
5. 5.Assess the authentication blast radius: review Event 4624 Type 3 (network) logons across the environment for the suspected compromise window — any account may have been authenticated via the skeleton password. You cannot distinguish skeleton key logons from legitimate ones in event logs alone.
6. 6.Determine if MDI (Microsoft Defender for Identity) is deployed — if so, check for Skeleton Key or Encryption Downgrade alerts. MDI is the only reliable in-memory detection path.
7. 7.Incident response: the skeleton key patch does not survive a DC reboot. Rebooting affected DCs removes the in-memory patch immediately, but you must ensure the attacker cannot re-apply it — audit all Domain Admin accounts and active sessions before rebooting.
8. 8.After reboot, search for the persistence mechanism the attacker is using to maintain DA-level access (DCSync artifacts via Event 4662, Golden Ticket via 4769 RC4, new DA accounts via 4720/4728).

Common False Positives

• ◎There are no legitimate uses of Skeleton Key. Mimikatz misc::skeleton on a domain controller is always malicious or an authorized red team exercise.
• ◎Authorized red team and penetration testing exercises may deploy skeleton key against test DCs — confirm with your security team whether an engagement is in progress before escalating.
• ◎NTLM authentication to DCs in a Kerberos-enforced environment may have legitimate legacy causes (certain backup agents, older applications) — do not treat NTLM alone as proof of skeleton key; correlate with tooling indicators.

Remediation

• ✓Reboot all potentially affected domain controllers — the skeleton key patch is in-memory only and does not survive a restart. This removes the active backdoor immediately.
• ✓Before rebooting, identify and terminate the attacker's active sessions — if they have DA access, they can re-apply the patch after reboot. Audit all Domain Admin accounts and privileged sessions.
• ✓Enable Credential Guard on domain controllers (Windows Server 2016+) — Credential Guard uses virtualization-based security (VBS) to protect LSASS from in-memory patching. This is the most effective long-term mitigation against skeleton key.
• ✓Enable Protected Users Security Group for all privileged accounts — members cannot use NTLM and have reduced credential exposure.
• ✓Deploy Microsoft Defender for Identity — it provides behavioral detection of skeleton key via DC replication traffic analysis and encryption downgrade alerts, which event logs cannot provide.
• ✓Audit Domain Admin membership and remove unnecessary privileged accounts — skeleton key requires DA or SYSTEM on a DC to deploy. Reducing the attack surface limits who can apply it.
• ✓Reset all domain admin and service account passwords after a confirmed skeleton key incident — skeleton key logons are indistinguishable from legitimate logons, so all privileged account credentials must be treated as compromised.

Related Event IDs

Related Detection Guides

Frequently Asked Questions

Does a skeleton key survive a domain controller reboot?

No. The skeleton key patch is applied entirely in LSASS memory and does not write to disk or modify Active Directory objects. A DC reboot clears the patch immediately. This is why attackers combine skeleton key with a durable persistence mechanism — typically a Golden Ticket (requires the krbtgt hash) or a backdoor Domain Admin account — to re-apply the patch after reboots.

How do I know if a skeleton key is currently active?

You cannot reliably determine this from Windows event logs alone — the patch leaves no audit trail in the Security log during normal operation. The most reliable detection method is Microsoft Defender for Identity (MDI), which detects the encryption downgrade behavior caused by skeleton key LSASS patching. Short of MDI, look for Mimikatz tooling indicators (Event 4688 for mimikatz.exe, Event 7045 for mimidrv.sys, Event 4104 for PowerShell variants) in the recent history of your domain controllers.

What is the default skeleton key password?

The default Mimikatz skeleton key password is 'mimikatz'. However, attackers can specify a custom password, so you cannot test for skeleton key presence by attempting to authenticate with 'mimikatz' as a detection method — a sophisticated attacker will have changed it. The correct response is to assume any account may have been authenticated via skeleton key and audit all privileged logons during the suspected compromise window.

Does Credential Guard prevent skeleton key attacks?

Yes. Credential Guard uses virtualization-based security (VBS) to isolate LSASS in a protected virtual environment (LSAIso), preventing any process — even those with SYSTEM or SeDebugPrivilege — from patching LSASS memory directly. When Credential Guard is enabled, misc::skeleton fails with an error. This is the most effective technical control against skeleton key and similar LSASS patching techniques.