Loading

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:

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

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

  • 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.

  • 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.
  • 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.
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

Framework: MITRE ATT&CK