Elad Shamir’s post on Shadow Credentials is the right place to read the details of this interesting approach: https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab. He documented the approach back in June, 2018.
Short Version for Blue Teamers:
The way I simplify (probably oversimplify) this when talking to people about it is:
- There’s an Active Directory attribute called
- If an adversary or malicious insider is able to write to the attribute for a principal they want to use they can add their own self-generated key material and authenticate with that material.
- Meaning, an adversary could be logging on as you or anyone in the domain, without your password, without you knowing anything about it IF they had write access to this attribute.
The other note I call out explicitly on this one is that there is no need to do anything with the corporate certificate server. The adversary can create their own keypair.
Bloodhound is calling out the attack path where
Ollyhappens to have write to the
Sallyhas domain admin privileges. In practice though, domain admin might not even be the goal, we might just be looking for accounts to take over. One horrible situation I think about is a rouge admin who might have these permissions by nature of creating lots of user accounts and is looking for a way to do sneaky things or access materials they shouldn’t:
How does this happen in practice though?
If your first reaction was that it should be rare for someone to just have that weird permission on it’s own, you’d be right. What usually happens in practice is that a principal will have one of:
WriteOwnerpermissions and with any of those, they can write the
msDS-KeyCredentialLinkin one or two steps. And to further drive home how this can happen in practice: if you create a user, you usually become the owner (unless you are a domain admin in which case ‘domain admins’ become the owner). So in practice if someone is creating a lot of users, and especially if they are creating privileged accounts, that user will have write permissions to the
msDS-KeyCredentialLinkattribute. Here’s a quick picture: The
testOwneraccount was created by
net user /add testOwner P@ssw0rd123 /domain
How easily can this be abused?
Very. If the red team, or adversary is able to compromise an account that has the ability to write
msDS-KeyCredentialLinkon another principal they can do it with a small amount of effort. Bloodhound even provides instructions:
Simple Abuse Example:
Keep in mind, we discovered that “olly” has the ability to write the
msDS-KeyCredentialLinkattribute on the “sally” principal.
- Download and Compile Whisker: https://github.com/eladshamir/Whisker
whisker.exe add /target:sally /domain:jmpesp.xyz /dc:dc1.jmpesp.xyz /path:file.pfx /password:pass
- Download and Compile Rubeus: https://github.com/GhostPack/Rubeus
- Run the command provided in the output of whisker:
rubeus.exe /asktgt /user:sally /certificate:file.pfx /password:"pass" /domain:jmpesp.xyz /dc:dc1.jmpesp.xyz /getcredentials /show
- We now have both a TGT and the NTLM hash for Sally and can now use this principal for whatever we need. On Sally’s end, not much has changed, she just goes about her day unaware that Olly has added this credential to her Active Directory object and can leverage it for whatever he needs. As a red-teamish example just to close this out with a screenshot abusing Sally’s account: But in reality the type of things that has me most worried about this attack is the malicious insider who is just using this from time to time to access other users things undetected. // more on detections to come…