« Sensitive Privilege SeEnableDelegationPrivilege assigned to a Principal User account exposed to Kerberoasting »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

Potential Shadow Credentials added to AD Object

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Potential Shadow Credentials added to AD Object

edit

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*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

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

Investigation guide

edit

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{"description":"","label":"Successful logon for the modifying session","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • 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{"description":"","label":"Directory changes in the same operation","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.OpCorrelationID","queryType":"phrase","value":"{{winlog.event_data.OpCorrelationID}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • 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{"description":"","label":"Alerts associated with the modifying account","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Hint: compare with alerts scoped to the modified object’s winlog.event_data.ObjectGUID. !{investigate{"description":"","label":"Alerts associated with the modified object","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ObjectGUID","queryType":"phrase","value":"{{winlog.event_data.ObjectGUID}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • 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.

Setup

edit

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

Rule query

edit
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&CKTM

« Sensitive Privilege SeEnableDelegationPrivilege assigned to a Principal User account exposed to Kerberoasting »