---
title: Potential Shadow Credentials added to AD Object
description: Identify the modification of the msDS-KeyCredentialLink attribute in an Active Directory Computer or User Object. Attackers can abuse control over the...
url: https://www.elastic.co/elastic/docs-builder/docs/3466/reference/security/prebuilt-rules/rules/windows/credential_access_shadow_credentials
products:
  - Elastic Security
---

# Potential Shadow Credentials added to AD Object
Identify the modification of the msDS-KeyCredentialLink attribute in an Active Directory Computer or User Object.
Attackers can abuse control over the object and create a key pair, append to raw public key in the attribute, and obtain
persistent and stealthy access to the target user or computer object.
**Rule type**: query
**Rule indices**:
- winlogbeat-*
- logs-system.security*
- logs-windows.forwarded*

**Rule Severity**: high
**Risk Score**: 73
**Runs every**: 
**Searches indices from**: `now-9m`
**Maximum alerts per execution**: 100
**References**:
- [[https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab)](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab)
- [[https://www.thehacker.recipes/ad/movement/kerberos/shadow-credentials](https://www.thehacker.recipes/ad/movement/kerberos/shadow-credentials)](https://www.thehacker.recipes/ad/movement/kerberos/shadow-credentials)
- [[https://github.com/OTRF/Set-AuditRule](https://github.com/OTRF/Set-AuditRule)](https://github.com/OTRF/Set-AuditRule)
- [[https://cyberstoph.org/posts/2022/03/detecting-shadow-credentials/](https://cyberstoph.org/posts/2022/03/detecting-shadow-credentials/)](https://cyberstoph.org/posts/2022/03/detecting-shadow-credentials/)

**Tags**:
- Domain: Endpoint
- OS: Windows
- Use Case: Threat Detection
- Tactic: Credential Access
- Data Source: Active Directory
- Resources: Investigation Guide
- Use Case: Active Directory Monitoring
- Data Source: Windows Security Event Logs

**Version**: 219
**Rule authors**:
- Elastic

**Rule license**: Elastic License v2

## Setup

Audit Directory Service Changes must be enabled to generate the events used by this rule.
Setup instructions: [https://ela.st/audit-directory-service-changes](https://ela.st/audit-directory-service-changes)

## Investigation guide


## Triage and analysis


### Investigating Potential Shadow Credentials added to AD Object


#### Possible investigation steps

- What object received the key-trust change?
  - Focus: `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.ObjectClass`, `winlog.event_data.OperationType`, and `winlog.event_data.AttributeValue`.
- Implication: escalate when a sensitive user or computer receives an added or replaced key-trust value outside recognized enrollment; lower suspicion only when the object class, DN, and operation fit the same identity-registration workflow.
- Which account and logon session wrote the value?
  - Focus: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectLogonId`, recovered `source.ip`, and `winlog.logon.type`. $investigate_0
- Hint: match alert `winlog.event_data.SubjectLogonId` to same `host.id` authentication events with `winlog.event_data.TargetLogonId`; if no 4624 matches, keep the session unresolved.
- Implication: escalate for an unexpected user, admin, service, or machine writer, or source/logon type outside the object's enrollment path; lower suspicion when writer and session match recognized provisioning or device registration.
- Does the writer/object pair fit a recognized ADFS or Azure AD Connect-style path?
  - Why: the abuse path writes authentication material, so service-looking writers still need source and change-set validation.
- Focus: compare `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.ObjectClass`, `winlog.event_data.ObjectDN`, and `source.ip` to the expected service account, object type, and enrollment source.
- Implication: lower suspicion when recognized provisioning updates the expected object from the expected source; escalate when the writer is ad hoc, interactive, non-provisioning, object-class mismatched, or unexplained by source.
- Was the logical change limited to this key credential?
  - Focus: use same-operation 5136 events grouped by `winlog.event_data.OpCorrelationID`; compare `winlog.event_data.ObjectGUID`, `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.OperationType`, and `winlog.event_data.AttributeValue`. $investigate_1
- Implication: escalate when the operation touches unrelated objects, adds other authentication or delegation material, or removes cleanup evidence; lower suspicion when bounded to the expected object and enrollment attributes.
- Did the modified identity authenticate after the change?
  - Why: post-change authentication shows whether the new key material may already be in use.
- Focus: derive the principal from `winlog.event_data.ObjectDN`; review authentication events for `winlog.event_data.TargetUserName`, `winlog.event_data.TargetDomainName`, `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`.
- Hint: search after `@timestamp` for Target-side fields matching the derived principal; if `source.ip` is empty, lower origin confidence instead of treating absence as benign.
- Implication: escalate when the identity authenticates from a new source, unexpected logon type, or authentication path after the change; absence of follow-on use reduces urgency only when earlier evidence proves recognized provisioning.
- Do related alerts change the scope beyond this object?
  - Focus: recent alerts for the modifying account using `user.id` or `winlog.event_data.SubjectUserSid`. $investigate_2
- Hint: compare with alerts scoped to the modified object's `winlog.event_data.ObjectGUID`. $investigate_3
- Implication: broaden response when either scope shows privilege abuse, directory tampering, relay activity, or lateral movement; keep local when related alerts are quiet and local evidence resolves to one recognized workflow.
- Escalate on the key-trust change plus any suspicious or unresolved object, writer session, `winlog.event_data.OpCorrelationID` scope, post-change authentication, or related-alert finding; close only when all evidence binds to one recognized provisioning workflow; preserve and escalate when evidence is mixed, incomplete, or uncorroborated.


### False positive analysis

- AutoPilot or WHfB device enrollment can cause a computer to write its own key credential. Confirm `winlog.event_data.SubjectUserName` matches the CN in `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectClass` is "computer", `winlog.event_data.OpCorrelationID` is bounded, and no unexpected follow-on authentication occurs.
- ADFS or Azure AD Connect provisioning can update key credentials on user or computer objects. Confirm `winlog.event_data.SubjectUserSid`, `winlog.event_data.ObjectDN`, recovered `source.ip`, bounded `winlog.event_data.OpCorrelationID`, and post-change authentication align with one named workflow. Keep open when ownership is unresolved.
- Build exceptions from stable writer SID, object class or GUID, `host.id`, recovered source, and enrollment path across prior alerts. Avoid exceptions on "msDS-KeyCredentialLink", `user.name`, or host alone.


### Response and remediation

- Preserve a case export of the triggering 5136, recovered writer-session authentication events, `winlog.event_data.AttributeValue`, `winlog.event_data.ObjectGUID`, and `winlog.event_data.OpCorrelationID` before containment, reversal, or cleanup.
- If confirmed benign, reverse temporary containment and document the exact workflow evidence: writer SID, object GUID/class, domain naming context, recovered source, bounded change set, and post-change authentication pattern. Keep any exception narrow and only for the recurring workflow.
- If suspicious but unconfirmed, apply reversible controls to the writer first, such as heightened monitoring or temporary access review; restrict the modified identity only when object sensitivity or follow-on authentication shows active risk.
- If confirmed malicious, contain the writer account or source system using `winlog.event_data.SubjectLogonId`, `source.ip`, `host.id`, and follow-on authentication evidence. Disable the writer first when its session performed unauthorized changes; disable or rotate the modified identity only when post-change authentication or object sensitivity shows active risk.
- After containment, remove only the unauthorized key-trust value and verify rollback. Reset or rotate the modified identity according to `winlog.event_data.ObjectClass`: reset user passwords, rotate service credentials, or re-establish the expected computer trust path. Review the same `winlog.event_data.OpCorrelationID` or session for additional unauthorized changes.
- Post-incident hardening: restrict write access to "msDS-KeyCredentialLink" to dedicated identity-management accounts, retain 5136 auditing on domain controllers, and record the confirmed provisioning workflow or abuse pattern for future triage.


## Rule Query

```kuery
event.code:"5136" and host.os.type:"windows" and winlog.event_data.AttributeLDAPDisplayName:"msDS-KeyCredentialLink" and
  winlog.event_data.AttributeValue :B\:828* and
  not winlog.event_data.SubjectUserName: MSOL_* and
  not winlog.event_data.ObjectClass: "msDS-Device"
```

**Framework:** MITRE ATT&CK
- Tactic:
  - Name: Credential Access
- Id: TA0006
- Reference URL: [[https://attack.mitre.org/tactics/TA0006/](https://attack.mitre.org/tactics/TA0006/)](https://attack.mitre.org/tactics/TA0006/)
- Technique:
  - Name: Modify Authentication Process
- Id: T1556
- Reference URL: [[https://attack.mitre.org/techniques/T1556/](https://attack.mitre.org/techniques/T1556/)](https://attack.mitre.org/techniques/T1556/)

**Framework:** MITRE ATT&CK
- Tactic:
  - Name: Persistence
- Id: TA0003
- Reference URL: [[https://attack.mitre.org/tactics/TA0003/](https://attack.mitre.org/tactics/TA0003/)](https://attack.mitre.org/tactics/TA0003/)
- Technique:
  - Name: Account Manipulation
- Id: T1098
- Reference URL: [[https://attack.mitre.org/techniques/T1098/](https://attack.mitre.org/techniques/T1098/)](https://attack.mitre.org/techniques/T1098/)