Skeleton key
Theory
Skeleton key is a persistence attack used to set a master password on one or multiple Domain Controllers. The master password can then be used to authenticate as any user in the domain while they can still authenticate with their original password. It makes detecting this attack a difficult task since it doesn't disturb day-to-day usage in the domain.
Skeleton key injects itself into the LSASS process of a Domain Controller to create the master password. It requires Domain Admin rights and SeDebugPrivilege on the target (which are given by default to domain admins).
Since this attack is conducted in memory by reserving a region of memory with VirtualAllocEx() and by patching functions, the master password doesn't remain active after a DC reboot.
This attack currently supports NTLM and Kerberos (RC4 only) authentications. Below are a few explanation of how it works depending on the authentication protocol it injects a master key for.
The attack employs a three-steps process to create a master password for NTLM authentication.
Reserves a memory region using
VirtualAllocEx()for thelsass.exeprocess. This memory space is used to store a modified version of the NTLM password validation functionMsvpPasswordValidate().Attaches itself to the
lsass.exeprocess and locatesMsvpSamValidate()(authentication function) fromMSV1_0.dll(which is the DLL in charge of NTLM authentication).Finds the call to
MsvpPasswordValidate()(password validation function) inMsvpSamValidate()and patches it to make it point to the modifiedMsvpPasswordValidate()stored in the memory region from step 1.
When called, the modified version of MsvpPasswordValidate() first calls the original MsvpPasswordValidate(): therefore if a legitimate authentication is tried, it will succeed.
If the original MsvpPasswordValidate() fails, the modified version will call the originalMsvpPasswordValidate() again but will make it compare password hash supplied during the authentication with the hash of the master password set when launching the attack (i.e. mimikatz by default when using Mimikatz for this attack).
The attack doesn't support salt-enabled key-derivation functions (i.e. AES128 and AES256) since it would either require to
compute the relevant user’s Skeleton Key in real time (which is designed to be costly and would likely cause issues on the DC)
or compute all of the domain users’ Skeleton Keys offline and store them, which requires a lot of memory.
The Skeleton Key attack then only supports RC4-HMAC-based Kerberos authentication, as RC4-HMAC’s key-derivation function does not involve a user-based salt (making the Skeleton RC4-HMAC key the same for all users).
There are three steps to create a skeleton key for Kerberos authentication:
Reserving a memory region for the
lsass.exeprocess usingVirtualAllocEx(). This memory space is used to store a modified version ofDecryptandSamIRetrieveMultiplePrimaryCredentials()functions used in following steps.Making sure users will authenticate using RC4-HMAC encryption instead of AES encryption. In order to do that,
SamIRetrieveMultiplePrimaryCredentials()function is hooked just likeMsvpPasswordValidate()for NTLM and calls made to this function are patched. The hookedSamIRetrieveMultiplePrimaryCredentials()checks for the package nameKerberos-Newer-Keysand returnsSTATUS_DS_NO_ATTRIBUTE_OR_VALUEto effectively disable AES-based authentication.Patching
CDLocateCSystem()fromcryptdll.dllto call a modified version of theDecryptfunction. The modifiedDecryptfunction works like the modifiedMsvpPasswordValidate()for NTLM : it first calls the originalDecryptfunction to make sure the users can still log on with their original username and password. Then if the previous step fails, it replaces the retrieved password hash with the supplied Skeleton RC4-HMAC key (which is the same as the Skeleton Key NTLM hash) and calls the originalDecryptfunction again, making the authentication successful.
Practice
Skeleton Key can be injected with the misc::skeleton command in Mimikatz. It works in every 64-bits Windows Server version up to 2019 (included).
Mimikatz must be either launched as NT-AUTHORITY\SYSTEM or be executed with a domain admin account on the Domain Controller. For the latter, debug privileges (SeDebugPrivilege) must be set for Mimikatz to work. This can be done with the privilege::debug command.
mimikatz "privilege::debug" "misc::skeleton"
Resources
Last updated
Was this helpful?