« Potential Credential Access via Trusted Developer Utility Potential Credential Access via DCSync »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

First Time Seen Account Performing DCSync

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

First Time Seen Account Performing DCSync

edit

This rule identifies when a User Account starts the Active Directory Replication Process for the first time. Attackers can use the DCSync technique to get credential information of individual accounts or the entire domain, thus compromising the entire domain.

Rule type: new_terms

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
  • Tactic: Privilege Escalation
  • Use Case: Active Directory Monitoring
  • Data Source: Active Directory
  • Resources: Investigation Guide
  • Data Source: Windows Security Event Logs

Version: 119

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating First Time Seen Account Performing DCSync

Possible investigation steps

  • What did the alerted 4662 prove about the subject and replication request?
  • Focus: winlog.event_data.SubjectUserSid, winlog.event_data.SubjectUserName, winlog.event_data.Properties, winlog.event_data.AccessMask, and winlog.computer_name.
  • Hint: replication-right GUIDs map to DS-Replication-Get-Changes (1131f6aa-9c07-11d1-f79f-00c04fc2dcd2), DS-Replication-Get-Changes-All (1131f6ad-9c07-11d1-f79f-00c04fc2dcd2), and DS-Replication-Get-Changes-In-Filtered-Set (89e95b76-444d-4c62-991a-0facbeda640c).
  • Implication: escalate faster when a human admin, new service account, or other non-machine principal used Control Access with DS-Replication-Get-Changes rights; lower suspicion only when the same stable SID and controller match one recognized directory-replication connector or AD backup/recovery job.
  • Do the 4662 object-access details show domain-wide replication or access to especially sensitive naming contexts?
  • Why: DCSync stands out when the event shows replication extended rights plus access to the domain root or other high-value directory objects.
  • Focus: winlog.event_data.Properties, winlog.event_data.AccessMask, winlog.event_data.ObjectName, and winlog.event_data.ObjectType.
  • Hint: treat the domain naming context or root DN, such as DC=corp,DC=example,DC=com, as broader and higher risk; interpret Configuration, DomainDNSZones, ForestDNSZones, or specific object paths against the exact connector or job workflow before lowering severity.
  • Implication: escalate on broad domain naming-context, high-value object, or DS-Replication-Get-Changes-All / In-Filtered-Set scope because the request can expose domain secrets; lower suspicion only when the same rights and object scope fit the exact connector workflow from step 1.
  • Does the subject logon session resolve to another domain controller or an unexpected source system?
  • Focus: match winlog.event_data.SubjectLogonId to 4624 winlog.event_data.TargetLogonId on the same host.id, then read source.ip, winlog.logon.type, and winlog.event_data.AuthenticationPackageName. !{investigate{"description":"","label":"Authentication events for the subject logon session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}}
  • Range: search backward from @timestamp on the same host.id because the session-creating 4624 can predate the 4662 by minutes or hours.
  • Hint: if the linked 4624 is missing or source.ip is absent, preserve winlog.event_data.SubjectLogonId, winlog.computer_name, and @timestamp. Missing authentication telemetry is unresolved, not benign.
  • Implication: escalate when the session originates from a workstation, member server, rare admin host, or a DC interactive / remote-interactive logon; lower suspicion when the 4624 source, logon type, and auth package match recognized replication infrastructure.
  • Do surrounding authentication events show explicit-credential use or a session pattern that does not fit routine replication?
  • Why: stolen or relayed credentials often leave 4624 or 4648 context riskier than the 4662 event alone.
  • Focus: linked 4624 events where winlog.event_data.TargetLogonId matches the alerted winlog.event_data.SubjectLogonId, plus 4648 events for the same session; read source.ip, winlog.logon.type, winlog.event_data.AuthenticationPackageName, and winlog.event_data.TargetServerName.
  • Hint: 4648 means credentials were presented, not that the replication succeeded; missing linked authentication telemetry is unresolved, not benign.
  • Implication: escalate when the subject shows new remote-interactive or network sessions from unusual origins, explicit credentials for the alerted account or controller, or NTLM where the workflow normally uses Kerberos.
  • Did surrounding directory-object changes or related 4662 activity show how the account obtained or expanded replication rights?
  • Focus: surrounding 4662 activity for winlog.event_data.SubjectUserSid, plus 5136 changes using winlog.event_data.ObjectDN, winlog.event_data.AttributeLDAPDisplayName, winlog.event_data.AttributeValue, and winlog.event_data.OpCorrelationID. !{investigate{"description":"","label":"Directory replication and rights events for the subject","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4662","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.Properties","queryType":"phrase","value":"DS-Replication-Get-Changes","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4662","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.Properties","queryType":"phrase","value":"DS-Replication-Get-Changes-All","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4662","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.Properties","queryType":"phrase","value":"DS-Replication-Get-Changes-In-Filtered-Set","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4662","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.Properties","queryType":"phrase","value":"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4662","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.Properties","queryType":"phrase","value":"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4662","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.Properties","queryType":"phrase","value":"89e95b76-444d-4c62-991a-0facbeda640c","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}}
  • Hint: group related 5136 records by winlog.event_data.OpCorrelationID; if 5136 visibility is absent, preserve the gap and answer from surrounding 4662 activity.
  • Implication: escalate when 5136 shows recent ACL or delegation changes granting DS-Replication-Get-Changes rights to the subject or its groups, when another grantor touched sensitive delegation or domain-level objects, or when privileged 4662 access appears on multiple controllers.
  • If local evidence is still suspicious, did the same subject or replication-right scope touch other controllers?
  • Focus: Windows Security 4662 and 5136 records for winlog.event_data.SubjectUserSid and winlog.event_data.Properties, grouped by winlog.computer_name and winlog.event_data.ObjectName.
  • Range: start with the surrounding window, then expand only if the local subject, source, or rights scope remains suspicious.
  • Implication: escalate domain-wide when the same subject or rights scope appears on multiple controllers or directory objects; keep scope local when only this controller shows activity, but do not close unresolved DCSync evidence from absence alone.
  • Based on the evidence gathered, what disposition is supported?
  • Focus: identity, replication scope, session origin, authentication pattern, directory-rights changes, and controller spread.
  • Implication: escalate when those categories show an unrecognized subject, broad scope, unexpected source, explicit-credential use, or privilege changes; close only when alert-local evidence plus supported recovery tightly bind one exact directory-replication connector or AD backup/recovery job, with outside confirmation when telemetry alone cannot prove legitimacy; preserve and escalate if evidence is mixed or incomplete.

False positive analysis

  • Directory-replication connectors and AD backup/recovery jobs can legitimately trigger this rule. Confirm only when winlog.event_data.SubjectUserSid, winlog.event_data.Properties, winlog.event_data.ObjectName, recovered 4624 source.ip, and winlog.computer_name align to one exact connector or job run. For backup/recovery tooling, require 5136 or owner/product evidence that the activity was tool-driven rather than hands-on operator behavior. If telemetry cannot prove the workflow, require outside confirmation for that exact run; do not close from prior-alert recurrence alone.
  • Build exceptions from the minimum confirmed workflow: stable winlog.event_data.SubjectUserSid, recovered 4624 source.ip, winlog.event_data.Properties, winlog.event_data.ObjectName, and winlog.computer_name, plus the specific product or connector identity that explains the access. Avoid exceptions on winlog.event_data.SubjectUserName alone, broad replication-right strings, or "first benign occurrence" claims without exact workflow confirmation.

Response and remediation

  • If confirmed benign, reverse temporary containment and document the exact evidence that validated the directory-replication connector or AD backup/recovery job: subject SID, connector source, replication rights, object scope, controller, and confirming product or owner record. Create an exception only from those same workflow anchors.
  • If suspicious but unconfirmed, preserve a case export containing the triggering 4662 event, linked 4624/4648 authentication records, recovered source.ip, replication rights/object fields, and any 5136 delegation-change records before containment. Apply reversible containment first, such as temporarily blocking the recovered source.ip from reaching domain controllers or isolating the unexpected non-domain-controller source host when its role tolerates isolation. Escalate to broader account disablement or host isolation only if credential-theft, relay, or privilege-change evidence appears.
  • If confirmed malicious, use endpoint or identity-response tooling to isolate the unexpected source host and disable or reset the implicated account. If direct response is unavailable, escalate with the same artifact set to the AD or incident-response team. Record all preserved evidence before terminating processes, revoking access, or removing delegated rights.
  • If confirmed malicious activity included broad domain scope in winlog.event_data.ObjectName or winlog.event_data.ObjectType, hand off to the AD incident-response team with the preserved evidence before privileged-account resets or delegated-rights cleanup.
  • Review other controllers and sync hosts for the same winlog.event_data.SubjectUserSid, source.ip, and winlog.event_data.Properties before removing delegated rights or cleaning up changes.
  • Eradicate only the unauthorized replication-right delegation or directory changes identified during the investigation: remove "DS-Replication-Get-Changes*" grants, restore modified directory objects or ACLs, and remediate the path that let the subject obtain replication capability.
  • Post-incident hardening: restrict replication rights to authorized service accounts and sync hosts, retain Security 4662, 4624, 4648, and 5136 coverage on controllers, and document any uncovered variant or logging gap in the incident record for follow-up ownership.

Setup

edit

Setup

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

Rule query

edit
event.code:"4662" and host.os.type:"windows" and
  winlog.event_data.Properties:(
    *DS-Replication-Get-Changes* or *DS-Replication-Get-Changes-All* or
    *DS-Replication-Get-Changes-In-Filtered-Set* or *1131f6ad-9c07-11d1-f79f-00c04fc2dcd2* or
    *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2* or *89e95b76-444d-4c62-991a-0facbeda640c*) and
  not winlog.event_data.SubjectUserName:(*$ or MSOL_*)

Framework: MITRE ATT&CKTM

« Potential Credential Access via Trusted Developer Utility Potential Credential Access via DCSync »