Detecting unauthorized domain replication

What “unauthorized replication” actually means

Active Directory replication is how domain controllers keep directory partitions consistent. In normal operations, replication is performed by domain controllers using secure channels and well-understood topology rules. If you need a refresher on the mechanics, start with Active Directory Replication: What it is and how it works.

“Unauthorized domain replication” usually shows up in one of these patterns:

• Replication rights abuse (DCSync-style): A non-DC principal (user/service account) is granted extended rights that allow it to request directory replication data.
• Rogue/illicit DC behavior: A system that shouldn’t be a domain controller attempts to act like one, or a compromised DC begins replicating in abnormal ways.
• Topology/path manipulation: Replication connections and site links are changed to route replication traffic through places you don’t trust. This is rarer, but it matters in complex environments—especially multi-site designs (see Active Directory Sites and Services - An Overview).

Why replication abuse is so dangerous

Replication is privileged by design. Once an attacker can replicate sensitive directory attributes, they can often obtain credential material and impersonate users at will. Unlike brute force attempts or interactive logons, replication requests can blend into “normal DC chatter” unless you instrument the right signals and baseline expected behavior.

Real-world warning signs

• Replication requests initiated by a non-DC account
• Replication requests coming from a non-DC host
• New or modified ACLs granting replication extended rights on the domain root
• Sudden changes to replication topology/site links that do not match change management tickets
• Security tooling detects “suspicious directory replication” patterns

Establish the baseline: who is allowed to replicate?

Before you can detect what’s unauthorized, define what’s authorized in your environment:

• Which principals are expected to have replication rights? In most environments, this is effectively “domain controllers” (and tightly controlled admin workflows).
• Which hosts are expected to initiate replication traffic? Typically: DCs only.
• Which sites and links should carry replication traffic? Your Sites & Services design should reflect network boundaries and trust assumptions.

If you’re still rationalizing domain controller roles and responsibilities, ensure you understand where the “brain” of operations lives. FSMO placement affects recovery and can influence where certain changes originate: Active Directory FSMO Roles Explained.

Data sources that catch unauthorized replication

The most reliable detection comes from combining three layers: directory auditing, endpoint identity, and network/telemetry baselines.

1) Domain Controller Security Log (Directory Service Access)

The classic signal for replication-rights abuse is Security Event ID 4662 (“An operation was performed on an object”) when it includes extended rights associated with directory replication. To make 4662 useful, you must:

• Enable Advanced Audit Policy for Directory Service Access
• Configure SACL auditing on the right directory objects (often the domain root)

In a 4662 event, you’re looking for replication-related extended rights GUIDs in the event details, commonly:

• 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 (Replicating Directory Changes)
• 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (Replicating Directory Changes All)
• 89e95b76-444d-4c62-991a-0facbeda640c (Replicating Directory Changes In Filtered Set)

Detection logic (high level): Alert when 4662 shows one of these GUIDs and the caller is not a domain controller computer account.

2) Directory Service Changes (who changed the permissions?)

If an attacker grants themselves replication rights, the “permission change” is often the first and best time to catch them. Enable auditing for Directory Service Changes and monitor for modifications to:

• ACLs on the domain root
• Admin groups or delegated OU structures that can later lead to domain-root ACL changes
• Computer objects and settings associated with domain controllers

3) Microsoft Defender for Identity (MDI) / SIEM correlation

Many environments detect suspicious replication most effectively by forwarding DC events and correlating them with identity analytics. If you use Microsoft Defender for Identity, ensure your event collection is configured correctly: Event collection with Microsoft Defender for Identity.

Your SIEM should correlate:

• 4662 replication-rights usage
• Directory permission changes (who granted rights, when, and from where)
• Privileged logons and abnormal workstation-to-DC access patterns

4) Network telemetry (useful for confirmation and hunting)

Replication protocols and endpoints can be profiled at the network layer (e.g., RPC patterns). Network telemetry is rarely sufficient on its own, but it’s excellent for:

• Confirming the source host of suspicious activity
• Detecting “DC-like” behavior from a non-DC subnet
• Finding replication attempts across trust boundaries or unexpected routes

How to enable the right auditing (without drowning in noise)

The goal is to make replication abuse visible while keeping log volume manageable. A practical approach:

Step A: Enable Advanced Auditing on Domain Controllers

1. In GPMC, edit the Domain Controllers Policy (or a dedicated DC audit policy GPO).
2. Enable:
   • Advanced Audit Policy Configuration → DS Access → Directory Service Access
   • Advanced Audit Policy Configuration → DS Access → Directory Service Changes
3. Ensure events are forwarded centrally (WEF/MDI/SIEM).

Step B: Set SACLs only where needed

Directory Service Access events (like 4662) are heavily influenced by SACLs. Instead of auditing everything, focus on the domain root and other high-impact objects where replication rights would be abused.

Tip: treat SACL changes as a controlled security change. If you need to roll back, you should be able to do it quickly.

Practical detection rules you can implement

Rule 1: 4662 replication extended rights used by non-DC accounts

Trigger an alert when:

• Event ID is 4662 on a DC
• The event contains one of the replication extended rights GUIDs
• The caller is not a DC computer account (not ending with $, not in Domain Controllers)
• The source host is not a DC

Rule 2: New replication rights granted on the domain root

Trigger an alert when directory permissions are modified and the change includes granting: “Replicating Directory Changes”, “Replicating Directory Changes All”, or “Replicating Directory Changes In Filtered Set” to any principal outside of tightly controlled admin identities.

Rule 3: DC promotion/demotion and metadata anomalies

Unauthorized replication sometimes appears in environments where DC lifecycle controls are weak. Monitor for unexpected DC promotion/demotion signals and ensure cleanup is performed correctly. Reference for lifecycle hygiene: How to demote a Domain Controller: A step-by-step guide.

Rule 4: Replication topology changes outside maintenance windows

Changes in Sites & Services (site links, connection objects, bridgeheads) should be rare and ticketed. If your environment depends on carefully designed topology, alert on “unexpected changes” and correlate with change management.

Example PowerShell hunts (defender-friendly)

These snippets are intended for detection/hunting on domain controllers or centralized event collectors. Test in a lab before production use.

Hunt for suspicious 4662 events containing replication GUIDs

# Replication extended rights GUIDs commonly associated with DCSync-style activity
$replicationGuids = @(
  "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
  "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2",
  "89e95b76-444d-4c62-991a-0facbeda640c"
)

# Pull recent 4662 events and search message text for the GUIDs (simple but effective)
$start = (Get-Date).AddDays(-1)

Get-WinEvent -FilterHashtable @{ LogName="Security"; Id=4662; StartTime=$start } -ErrorAction SilentlyContinue |
  Where-Object {
    $msg = $_.Message
    $replicationGuids | ForEach-Object { if ($msg -match $_) { return $true } }
    return $false
  } |
  Select-Object TimeCreated, Id, MachineName, Message |
  Format-List

Quick triage: extract likely caller account from the event message

# Note: 4662 parsing is easier if you map the event XML fields.
# This quick method uses regex to pull common "Account Name" / "Subject" patterns from Message text.

$start = (Get-Date).AddHours(-12)

Get-WinEvent -FilterHashtable @{ LogName="Security"; Id=4662; StartTime=$start } -ErrorAction SilentlyContinue |
  ForEach-Object {
    $msg = $_.Message
    if ($msg -match "Account Name:\s+([^\r\n]+)") {
      [PSCustomObject]@{
        TimeCreated = $_.TimeCreated
        MachineName = $_.MachineName
        AccountName = $Matches[1].Trim()
        HasReplicationGuid = ($msg -match "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2|1131f6ad-9c07-11d1-f79f-00c04fc2dcd2|89e95b76-444d-4c62-991a-0facbeda640c")
      }
    }
  } |
  Where-Object { $_.HasReplicationGuid } |
  Sort-Object TimeCreated -Descending

For operational-grade analytics, parse the event XML and build a proper extraction of SubjectUserName, SubjectDomainName, ObjectName, and AccessMask/Properties—then ship those fields to your SIEM for robust filtering and correlation.

Incident response: what to do when you suspect unauthorized replication

Treat suspected unauthorized replication as a high-severity identity compromise. A practical response sequence:

1. Confirm the principal and source host: Identify the account and endpoint associated with the 4662 activity and any related permission changes.
2. Contain: Isolate the source host. If the account is a service identity, pause the service and restrict logon.
3. Scope: Determine how replication rights were obtained (ACL change vs. group membership vs. delegated OU path). Check for other persistence mechanisms (new admins, scheduled tasks, GPO abuse).
4. Eradicate: Remove illicit replication rights and any unauthorized delegations. Re-validate privileged group memberships.
5. Recover: If credential material may have been exposed, plan credential resets appropriately (including privileged accounts and service accounts). Consider a controlled KRBTGT rotation procedure as part of a broader recovery plan when warranted.
6. Harden: Improve monitoring, tighten delegation, and enforce tiering so the same path can’t be repeated.

Hardening checklist to prevent recurrence

• Minimize replication rights: Keep replication extended rights limited to DCs and tightly controlled admin workflows.
• Tier your administration: Prevent workstation compromise from becoming DC compromise.
• Audit and alert on directory permission changes: Catch the “grant” event, not just the “use” event.
• Centralize and normalize DC logging: Use Defender for Identity and/or SIEM with structured parsers.
• Protect replication pathways: Validate Sites & Services topology and restrict administrative access to it.
• Control DC lifecycle: DC promotions/demotions should be rare, approved, and audited end-to-end.

Related reading (internal)

• Active Directory Replication: What it is and how it works
• Active Directory Sites and Services - An Overview
• Active Directory FSMO Roles Explained
• Event collection with Microsoft Defender for Identity
• How to demote a Domain Controller: A step-by-step guide