Shadow Credentials
Also calledkey credential abuse, msDS-KeyCredentialLink abuse
A key added to an account lets a certificate sign in as it, past a password reset.
- Hooks Into
- Kerberos AS Request
- Needs
- Directory Write
- Gives
- Account AccessandNT Hash
How the Attack Works
Every account object can carry key credentials in its msDS-KeyCredentialLink attribute, which Windows Hello for Business uses for passwordless sign-in. Where an account's access control list lets another principal write that attribute, a key placed there lets a certificate sign in as the account through PKINIT, and the account's own password is never involved. A reset of that password does not remove the key, so the access lasts until the attribute itself is cleared. MITRE maps this to Account Manipulation and has no dedicated shadow-credential sub-technique.
Read first Password Hashes and Kerberos Keys, Certificate Sign-In (PKINIT)
How It Plays Out
The attack step by step. Each step shows which machines take part, what travels, the keys and tickets each side now holds, what is logged and what a defender can see.
ws-042 Foothold
dc-01 Domain controller
- krbtgt key
Step 1 of 3: Key Credential Written
ws-042 Foothold to dc-01 Domain controller
A write to the key-credential attribute
LDAP ModifyRequestLDAP, port 389A key credential is written to adm-alice's msDS-KeyCredentialLink on dc-01, the attribute meant for passwordless sign-in.
Logged
5136 A directory service object was modified
On dc-01, in the Security log When enabled
msDS-KeyCredentialLink written on CORP\adm-alice.
What Defenders See
With Audit Directory Service Changes on and an audit entry on the account objects, dc-01 writes event 5136 showing the attribute changed.
Step 2 of 3: Certificate Sign-In
ws-042 Foothold to dc-01 Domain controller
A certificate sign-in as adm-alice
KRB_AS_REQKerberos, port 88ws-042 asks dc-01 for a TGT as adm-alice, proving it with the key in place of a password (PKINIT).
Keys and Tickets
- ws-042 now holds TGT (new at this step) TGT session key (new at this step)
Logged
4768 A Kerberos authentication ticket (TGT) was requested
On dc-01, in the Security log
A TGT issued to adm-alice with certificate issuer and serial filled in.
AS Reply: The TGT explains how to read it.
What Defenders See
The Security log on dc-01 shows event 4768 for adm-alice with certificate details filled in, though she never uses a certificate.
Hooks into Kerberos AS Request
Step 3 of 3: Access as the Admin
ws-042 Foothold to dc-01 Domain controller
Reaching services as adm-alice
KRB_TGS_REQKerberos, port 88The TGT gets service tickets as adm-alice, and a later password reset does not stop the key credential signing in again.
What Defenders See
The Security log on dc-01 shows event 4769 as adm-alice, which looks like her own work. Defender for Identity raises its shadow-credential takeover alert.
Needs First
What the attacker must already hold for this attack to be possible.
- Write Access to a Directory ObjectWrite access to the key-credential attribute on the target account.
Comes From
- Directory Write: DCShadow
Gives the Attacker
What running it hands the attacker to use next.
- Access as Another AccountA certificate sign-in as that account, which a password reset does not undo.
- An NT HashThat account's NT hash, which the certificate sign-in returns inside the PAC.
Leads To
- NT Hash: Pass-the-Hash, Overpass-the-Hash
What Defenders See
What this attack leaves for a defender to find, and what to read in each. None of it is proof on its own, so treat each as a lead and confirm it against the rest.
| Event and Log | Written On | Look For | Switch It On |
|---|---|---|---|
| 5136 A directory service object was modified (opens in a new tab) Security log | Domain controllers, for objects with a matching audit entry | msDS-KeyCredentialLink written on an account, with an audit entry set on the account objects and Audit Directory Service Changes on. | Audit Directory Service Changes, and an audit entry (SACL) on the object |
| 39 to 41 No strong mapping, Certificate predates account, Users SID does not match Certificate SID (opens in a new tab) System log | Domain controllers | A certificate sign-in refused because its key maps to the account only weakly, which can follow a key the directory does not fully trust. | Domain controllers with the May 2022 or later updates (KB5014754) |
What It Looks Like
One event from the worked example, decoded field by field, so you can see what to read in it and what each value means.
5136 A directory service object was modified
In the Security log on dc-01,
A key credential written to a Domain Admin on dc-01.
The attribute that changed. It holds passwordless-sign-in keys, so a write to it on a privileged account is the shadow-credential signal.
As Windows writes it:
LDAP Display NamemsDS-KeyCredentialLinkThe account that gained the key, a Domain Admin. From now on a certificate can sign in as her.
As Windows writes it:
DNCN=adm-alice,OU=Admins,DC=corp,DC=exampleA value was added to the attribute. The matching Value Deleted event, if any, shows what was there before.
As Windows writes it:
Operation TypeValue AddedThe raw key material is not shown here. Its presence on this account is the finding, so read the account object to list its current keys.
As Windows writes it:
Value(a key credential, binary)
Defender for Identity Alerts
Where Defender for Identity runs, its sensors raise these from what they read on the servers they are installed on, domain controllers above all. Each names what it flags, which is a lead to confirm, not proof on its own.
- Shadow credentials added to account (opens in a new tab)The key credential written to an account.
- Shadow Credentials Added to Account and Used for Authentication (opens in a new tab)The same key then used to sign in.
- Suspected account takeover using shadow credentials (opens in a new tab)
Blind Spots
Where this attack leaves little or nothing to see, so a quiet log is not read as an all-clear.
- A key credential is a normal attribute, so without an audit entry on the account objects a write leaves no event 5136 at all.
- A password reset leaves the key working, so resetting the account is not enough. The msDS-KeyCredentialLink value has to be cleared.
Hunt It
The query to run in each tool, and how well each one sees this attack. Pick the tool you use, and the others load their query when you open them.
Needs Defender for Identity sensors on every DC. The alert fires on the key-credential write and on its first use for sign-in. It names the account, so confirm by reading that account's current key credentials.
// Defender for Identity shadow-credential alerts: the key credential written, used, and the takeoverAlertEvidence| where Timestamp > ago(How to Prevent It
The controls that break this attack, each with how it helps here and, where the Registry topic has it, where to check it on a machine.
Least-privilege administration (opens in a new tab)
Review who can write the key-credential attribute, and keep that right off ordinary accounts.
Strong certificate mapping (opens in a new tab)
Keep domain controllers in full certificate-mapping enforcement, so a weakly mapped key is refused at sign-in.
Tiered administration (opens in a new tab)
Use privileged accounts only from privileged access workstations, so their objects are harder to reach and rewrite.
Sources
- MITRE ATT&CK T1098: Account Manipulation (opens in a new tab)
- [MS-ADA2] 2.358 msDS-KeyCredentialLink (opens in a new tab)
- Microsoft Learn: how Windows Hello for Business provisioning works (opens in a new tab)
- [MS-PAC] 2.6 PAC Credentials (opens in a new tab)
- Microsoft Learn: 5136, a directory service object was modified (opens in a new tab)
- Microsoft Support: KB5014754, certificate-based authentication changes on domain controllers (opens in a new tab)
- Microsoft Learn: Defender for Identity persistence alerts (XDR) (opens in a new tab)