Hardening Active Directory: Blue Team DCSync Defense Guide

Overview & Defensive Context#

In this morning's architectural deep-dive, we deconstructed how threat actors weaponize the Directory Replication Service Remote Protocol (MS-DRSR) to perform DCSync attacks against Active Directory Domain Services (AD DS). By targeting the drsuapi remote procedure call (RPC) interface, an adversary with delegated directory replication rights can impersonate an authentic Domain Controller. The targeted Domain Controller then extracts, packages, encrypts, and transmits sensitive directory secrets—including NTLM hashes, WDigest credentials, and krbtgt Kerberos AES-256 master keys—directly to the attacker over the network.

Defending enterprise Active Directory against DCSync presents severe architectural hurdles for blue teams:

The Endpoint Detection Blind Spot on Domain Controllers: Unlike traditional credential theft techniques (such as dumping lsass.exe memory or creating a Volume Shadow Copy of NTDS.dit), DCSync executes entirely in-band as an authorized protocol request. The Domain Controller's Local Security Authority Subsystem Service (lsass.exe) acts as the server handling an ordinary replication request. No binaries are written to disk, no foreign DLLs are injected, and no suspicious process handles are opened. Standard host-based Endpoint Detection and Response (EDR) sensors on the Domain Controller remain completely silent.
Flat Internal Networks & Unrestricted RPC Ingress: In typical enterprise networks, any domain-joined workstation, server, or VPN-connected client can route directly to Domain Controllers on TCP port 135 (RPC Endpoint Mapper) and ephemeral dynamic ports (49152-65535). This lack of network microsegmentation allows compromised endpoints anywhere in the enterprise to initiate directory replication exchanges.
Privilege Creep on Domain Naming Context DACLs: Over years of operational changes, organizations frequently grant DS-Replication-Get-Changes-All permissions to service principals, synchronization tools (such as poorly isolated Microsoft Entra Connect service accounts), or backup applications. These unmonitored Access Control Entries (ACEs) create permanent, exploitable backdoors into the domain's credential store.
Persistent Forest-Wide Compromise via Golden Tickets: Once the krbtgt account's AES-256 key is stolen, threat actors can forge valid Kerberos Ticket-Granting Tickets (Golden Tickets) off-network. These forged tickets grant persistent Domain Admin access across the forest, surviving user password rotations and operating system reboots.

[!WARNING] DCSync cannot be resolved with an operating system patch because it exploits legitimate directory replication functionality. Mitigating DCSync requires architectural changes: eliminating unauthorized replication ACEs from domain DACLs, implementing network-level RPC segregation, enforcing strict SACL access auditing, and institutionalizing an emergency krbtgt rotation playbook.

Architecture Hardening#

Securing Active Directory against DCSync attacks requires defense-in-depth across three architectural tiers: DACL Least-Privilege Governance, Network RPC Microsegmentation, and Directory Service Access Auditing (SACL).

Defense Architecture Flowchart#

flowchart TD
    classDef client fill:#1e293b,stroke:#ef4444,stroke-width:2px,color:#f8fafc
    classDef gate fill:#0f172a,stroke:#3b82f6,stroke-width:2px,color:#93c5fd
    classDef dc fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#6ee7b7
    classDef siem fill:#4c1d95,stroke:#8b5cf6,stroke-width:2px,color:#ddd6fe
    classDef drop fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#fca5a5
    classDef pass fill:#065f46,stroke:#34d399,stroke-width:2px,color:#a7f3d0

    InboundClient[Inbound RPC Request to drsuapi]:::client --> NetFirewall{Tier 1: Host RPC Firewall Filter}:::gate

    NetFirewall -- Source IP: Workstation or Non-DC Subnet --> Drop1[Action: DROP TCP 135 and Dynamic RPC Ports]:::drop
    NetFirewall -- Source IP: Authorized Domain Controller --> AuthCheck{Tier 2: DSA Security Evaluation}:::dc

    AuthCheck -- Token Lacks Replication Extended Rights --> Drop2[Action: RPC STATUS ACCESS DENIED 0x5]:::drop
    AuthCheck -- Token Contains Extended Rights --> CallerVerify{Caller Identity Verification}:::dc

    CallerVerify -- Principal Outside Domain Controllers OU --> AlertDCSync[Trigger Severity 1 Alert: Non-DC DCSync]:::drop
    CallerVerify -- Authentic Enterprise Domain Controller --> Replicate[Process Legitimate Replication Request]:::pass

    AlertDCSync --> SIEMPipeline[Tier 3: SACL Telemetry Forwarding]:::siem
    SIEMPipeline --> SOCAction[Automated Quarantine and krbtgt Rotation]:::drop

Layer 1: DACL Least-Privilege Governance on the Domain Naming Context#

The first line of defense is ensuring that only authorized Domain Controllers hold replication rights. Active Directory requires three specific extended rights for credential synchronization:

DS-Replication-Get-Changes ({1131f6aa-9c07-11d1-f79f-00c04fc2dcd2})
DS-Replication-Get-Changes-All ({1131f6ad-9c07-11d1-f79f-00c04fc2dcd2})
DS-Replication-Get-Changes-In-Filtered-Set ({89e77b59-d782-4706-9acb-3da2be3880b6})

In a secure deployment, these extended rights must be strictly limited to:

NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS
Authentic computer accounts located within the OU=Domain Controllers,DC=domain,DC=local organizational unit.

If your organization utilizes Microsoft Entra Connect (formerly Azure AD Connect) for Password Hash Synchronization (PHS), the dedicated sync account (MSOL_xxxxxxxxxxxx) requires these rights. To mitigate risk:

Treat the Entra Connect server as a Tier-0 asset.
Isolate the server in a dedicated management VLAN with restricted administrative access.
Ensure the sync account is not a member of privileged groups (e.g., Domain Admins) and cannot log in interactively to standard workstations.

Layer 2: Network-Level RPC Segmentation & Port Isolation#

Standard enterprise workstations and application servers have no legitimate business requesting directory replication over RPC. Workstations require access only to core identity services:

Kerberos Authentication: TCP/UDP 88
DNS Resolution: TCP/UDP 53
LDAP / LDAPS: TCP/UDP 389, TCP 636
SMB / Group Policy: TCP 445
Kerberos Password Change: TCP 464

Replication over MS-DRSR utilizes the RPC Endpoint Mapper (TCP 135) and high-order dynamic RPC ports (TCP 49152-65535). Blue teams should isolate replication traffic using the following configuration steps:

1. Pinning Active Directory RPC to a Static Port

By default, the Active Directory Directory System Agent (DSA) listens on dynamic RPC ports. Configure a static port via the registry to simplify firewall enforcement:

BASH

# Set a static RPC port (e.g. 50000) for Active Directory Replication
reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v "TCP/IP Port" /t REG_DWORD /d 50000 /f

2. Restricting Inbound RPC via Windows Firewall with Advanced Security

Deploy a Group Policy Object (GPO) targeting all Domain Controllers to enforce host-based packet filtering:

POWERSHELL

# Windows Firewall Rule: Restrict AD Replication RPC to Domain Controllers Only
New-NetFirewallRule -DisplayName "ActiveDirectory-Replication-Inbound-Restricted" `
    -Direction Inbound `
    -Action Allow `
    -Protocol TCP `
    -LocalPort 50000 `
    -RemoteAddress @("10.10.1.10", "10.10.1.11") `
    -Description "Allows AD MS-DRSR replication exclusively between authentic Domain Controllers"

# Block inbound TCP 50000 from all other subnets
New-NetFirewallRule -DisplayName "ActiveDirectory-Replication-Block-Workstations" `
    -Direction Inbound `
    -Action Block `
    -Protocol TCP `
    -LocalPort 50000 `
    -RemoteAddress "10.20.0.0/16" `
    -Description "Blocks workstation subnets from accessing AD replication port"

Layer 3: System Access Control List (SACL) Auditing Configuration#

By default, Active Directory does not generate audit logs when an account reads directory objects or requests replication. Blue teams must explicitly configure a System Access Control List (SACL) on the root of the Domain Naming Context.

Execute the following commands on a Domain Controller to enable Directory Service Access auditing:

BASH

# Enable advanced auditing for Directory Service Access
auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable

# Enable Directory Service Changes auditing
auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable

Next, configure a SACL entry on DC=corp,DC=local auditing Control Access rights (0x100) for the Everyone group. When configured, any replication request generates Windows Security Event ID 4662, recording the initiating account, workstation IP, and requested GUIDs.

Production Detection Queries#

Blue teams must deploy multi-layered detection across Windows Security event logs, PowerShell audit telemetry, and network intrusion detection systems (NIDS).

1. Production Sigma Rule: Active Directory DCSync Attempt#

The following Sigma rule detects unauthorized security principals invoking replication extended rights:

YAML

title: Active Directory DCSync Replication Attempt by Non-DC Account
id: 8f2a1b94-4d2c-4e89-9a1b-6d3c5e7f9a01
status: production
description: |
  Detects an attempt to perform DCSync credential extraction by identifying
  Windows Security Event ID 4662 where a non-Domain Controller account requests
  Directory Replication Service extended rights (DS-Replication-Get-Changes-All).
references:
  - https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4662
  - https://attack.mitre.org/techniques/T1003/006/

tags:
  - attack.credential_access
  - attack.t1003.006
  - attack.s0002
logsource:
  product: windows
  service: security
detection:
  selection_event:
    EventID: 4662
    ObjectServer: 'DS'
    ObjectType: 'domainDNS'
  selection_rights:
    Properties|contains:
      - '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2' # DS-Replication-Get-Changes-All
      - '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2' # DS-Replication-Get-Changes
      - '89e77b59-d782-4706-9acb-3da2be3880b6' # DS-Replication-Get-Changes-In-Filtered-Set
  filter_legitimate_dcs:
    SubjectUserName|endswith: '$'
  filter_sync_service:
    SubjectUserName|startswith: 'MSOL_' # Exclude Entra Connect if using standard naming convention
  condition: selection_event and selection_rights and not (filter_legitimate_dcs or filter_sync_service)
fields:
  - EventID
  - SubjectUserName
  - SubjectDomainName
  - Properties
  - ObjectName
falsepositives:
  - Newly commissioned Domain Controllers not yet populated in exclusion lists.
  - Authorized identity synchronization service accounts (e.g. Entra Connect, Quest).
level: critical

2. PowerShell Host Audit Script: Auditing Domain Replication DACLs#

Run this PowerShell script periodically or integrate it into scheduled compliance audits to identify rogue accounts holding replication permissions:

POWERSHELL

# Audit-DCSyncPermissions.ps1
# Identifies all accounts holding directory replication rights on the Domain NC root

$DomainRoot = [ADSI]"LDAP://RootDSE"
$DefaultNC = $DomainRoot.Get("defaultNamingContext")
$DomainEntry = [ADSI]"LDAP://$DefaultNC"

$ReplicationGUIDs = @{
    "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2" = "DS-Replication-Get-Changes"
    "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" = "DS-Replication-Get-Changes-All"
    "89e77b59-d782-4706-9acb-3da2be3880b6" = "DS-Replication-Get-Changes-In-Filtered-Set"
}

$DACL = $DomainEntry.ObjectSecurity.GetAccessRules($true, $false, [System.Security.Principal.SecurityIdentifier])
$Findings = @()

foreach ($Rule in $DACL) {
    $GuidStr = $Rule.ObjectType.ToString()
    if ($ReplicationGUIDs.ContainsKey($GuidStr)) {
        $SID = $Rule.IdentityReference.Value
        try {
            $Account = (New-Object System.Security.Principal.SecurityIdentifier($SID)).Translate([System.Security.Principal.NTAccount]).Value
        } catch {
            $Account = "Unresolved SID: $SID"
        }

        # Filter out built-in Enterprise Domain Controllers and Domain Controllers
        if ($Account -notmatch "Enterprise Domain Controllers" -and $Account -notmatch "Domain Controllers") {
            $Findings += [PSCustomObject]@{
                Account           = $Account
                SID               = $SID
                Permission        = $ReplicationGUIDs[$GuidStr]
                AccessControlType = $Rule.AccessControlType
                IsInherited       = $Rule.IsInherited
            }
        }
    }
}

if ($Findings.Count -gt 0) {
    Write-Warning "Potentially unauthorized accounts holding DCSync replication rights detected:"
    $Findings | Format-Table -AutoSize
} else {
    Write-Host "Domain NC DACL is clean. No unauthorized replication principals identified." -ForegroundColor Green
}

3. Suricata / Snort Network Signature: Detecting Anomalous drsuapi Calls#

Deploy this NIDS signature on network taps inspecting Domain Controller traffic to detect drsuapi bind requests originating from workstation pools:

BASH

# Suricata Rule: Detect DRSUAPI Replication Bind from Non-DC Subnets
alert tcp !$DC_SERVERS any -> $DC_SERVERS [135,50000,49152:65535] (     msg:"FAST_CYBER_DEFENSE - Potential DCSync Attack: DRSUAPI RPC Bind from Non-DC Client";     flow:established,to_server;     content:"|e3 51 42 35 06 4b d1 11 ab 04 00 c0 4f c2 dc d2|";     reference:url,learn.microsoft.com/en-us/openspecs/windows_protocols/ms-drsr/;     classtype:attempted-admin;     sid:10008501; rev:1; )

Enterprise Mitigation Matrix#

When hardening enterprise Active Directory infrastructure against replication abuse, security leadership must balance rapid containment against operational directory synchronization dependencies:

Remediation Strategy	Implementation Effort	Blast Radius & Operational Risk	Detection & Prevention Efficacy	Performance Overhead	Architectural Longevity
Workaround: Network RPC Firewall Filtering	30 - 60 Minutes (Configure host firewalls to drop TCP 135 and dynamic RPC from workstation subnets)	Low Standard clients never require directory replication RPC interfaces.	High (90%) Stops network-based DCSync from standard workstation pools.	Negligible Kernel-level packet filtering.	Interim Barrier Does not stop attacks originating from servers in trusted subnets.
Operational Fix: DACL Remediation & SACL Auditing	2 - 4 Hours (Audit Domain NC DACL, strip unauthorized ACEs, enable Event 4662)	Moderate Requires verifying third-party sync service accounts before ACE removal.	Absolute for Targeted Accounts Denies DSA replication access at the protocol access-check boundary.	Zero Native Active Directory authorization check.	Permanent Hygiene Maintains least-privilege access control on the directory root.
Architecture Fix: Tier-0 Isolation, Protected Users & PAM	2 - 4 Weeks (Full Active Directory Tier-0 segregation, PAM jump boxes, Credential Guard)	High Requires restructuring administrative workflows and service account governance.	Comprehensive (100%) Eliminates credential harvesting pathways across all administrative tiers.	Zero Architectural boundary enforcement.	Permanent State Resilient zero-trust identity architecture immune to lateral movement.

[!IMPORTANT] When stripping replication ACEs, always test thoroughly in a staging environment if third-party identity providers or federated synchronization tools (such as Okta AD Agent, PingFederate, or Quest) are deployed. Ensure their dedicated service accounts are documented, restricted to dedicated host IPs, and explicitly exempted from automatic removal.

Incident Response & Verification Playbook#

If a DCSync event is detected or suspected in your enterprise, execute the following four-phase incident response and recovery playbook immediately:

flowchart TD
    classDef alert fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#fca5a5
    classDef check fill:#1e293b,stroke:#f59e0b,stroke-width:2px,color:#fef3c7
    classDef triage fill:#0f172a,stroke:#3b82f6,stroke-width:2px,color:#93c5fd
    classDef clean fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#6ee7b7

    Triage[Phase 1: Event 4662 Triage & Workstation Identification]:::triage --> CorrelateLogon{Correlate Event ID 4624 Logon ID}:::check
    
    CorrelateLogon --> ConfirmCompromise[Phase 2: Isolate Source Host & Revoke Account Privileges]:::alert
    ConfirmCompromise --> CheckTarget{Was krbtgt Account Synchronized?}:::check
    
    CheckTarget -- Yes or Suspected --> GoldenRisk[Declare Forest-Wide Severity 1: Golden Ticket Risk]:::alert
    CheckTarget -- No: Single Account Only --> ResetUser[Execute Targeted Account Password Reset]:::clean
    
    GoldenRisk --> Phase3[Phase 3: Execute krbtgt Double-Rotation Playbook]:::alert
    Phase3 --> WaitReplication[Wait 10-Hour Maximum Kerberos Ticket Lifetime]:::check
    WaitReplication --> SecondReset[Execute Second krbtgt Password Reset]:::clean
    
    SecondReset --> Phase4[Phase 4: Post-Remediation Verification & Health Checks]:::clean
    ResetUser --> Phase4

Phase 1: Live Triage & Workstation Attribution#

Correlate Event ID 4662 with Network Logon Events: Query the Domain Controller's Security log for the matching SubjectLogonId in Event ID 4624:

POWERSHELL

# Correlate Event 4662 SubjectLogonId to Event 4624 to find Source IP
$LogonId = "0x3F8A21" # Extracted from Event 4662
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddHours(-4)} | Where-Object {
    $_.Properties[7].Value -eq $LogonId
} | Select-Object TimeCreated, @{N='Workstation';E={$_.Properties[11].Value}}, @{N='SourceIP';E={$_.Properties[18].Value}}

Determine the Targeted Object: Inspect the ObjectName or OperationProperties in Event ID 4662. If the request targeted the root domain object or specific user accounts (especially krbtgt or members of Domain Admins), classify the incident as a Tier-0 Domain Compromise.

Phase 2: Containment & Source Isolation#

Network Quarantine: Immediately disconnect the originating workstation or server from the enterprise network using your EDR platform or switch port isolation.
Disable the Compromised Account: Immediately disable the user account or service principal identified in the SubjectUserName field.
Revoke Replication Permissions: Remove all unauthorized ACEs on DC=domain,DC=local using LDP.exe, ADSI Edit, or PowerShell.

Phase 3: The `krbtgt` Double-Rotation Protocol#

If the adversary extracted the krbtgt account's keys, they can mint Golden Tickets that bypass normal user password resets. To permanently invalidate all forged Kerberos tickets, the krbtgt password must be rotated twice:

[!CAUTION] Active Directory stores the current password and the previous password for the krbtgt account to allow active Kerberos tickets to remain valid during routine key rollovers. A single reset leaves forged tickets valid against the previous hash. A second reset invalidates all existing tickets.

First krbtgt Password Reset: Execute the first rotation using the official Microsoft script or Active Directory administrative tools:

POWERSHELL

# Execute First krbtgt Rotation (Using New-KrbtgtKeys.ps1 or Set-ADAccountPassword)
Set-ADAccountPassword -Identity "krbtgt" -NewPassword (ConvertTo-SecureString -AsPlainText "RandomComplexSecret1!" -Force) -Reset

Replication & Ticket Lifetime Hold:
- Force replication across all Domain Controllers using repadmin /syncall /AdeP.
- Wait for the maximum ticket lifetime (default is 10 hours in Active Directory Kerberos policy). This ensures that legitimately issued user and computer tickets expire gracefully without causing enterprise-wide authentication disruption.
Second krbtgt Password Reset:
- Execute the second rotation:

POWERSHELL

# Execute Second krbtgt Rotation to invalidate all historical keys
Set-ADAccountPassword -Identity "krbtgt" -NewPassword (ConvertTo-SecureString -AsPlainText "RandomComplexSecret2!" -Force) -Reset
repadmin /syncall /AdeP

Once the second rotation replicates, all forged Golden Tickets signed with historical keys become completely invalid.

Phase 4: Post-Remediation Verification & Health Checks#

Before returning systems to standard operations:

Verify replication health across all Domain Controllers:

BASH

repadmin /replsummary
repadmin /showrepl * /csv > repl_status.csv

Run Audit-DCSyncPermissions.ps1 to confirm that no non-DC accounts possess replication extended rights.
Confirm that host firewall rules blocking TCP 135 and static RPC ports from workstation subnets are active and enforcing.
Validate that the DCSync Sigma detection rule is active and alerting in your SIEM.

Authoritative References#

Microsoft Security Documentation: Detecting and Mitigating Active Directory DCSync Attacks — Microsoft Learn
Cybersecurity and Infrastructure Security Agency (CISA): Best Practices for Securing Active Directory Domain Controllers — CISA Advisory
National Security Agency (NSA) & CISA Joint Advisory: Active Directory Threat Hunting & Hardening Guidance — CISA Cybersecurity
Microsoft Open Specifications: [MS-DRSR]: Directory Replication Service (DRS) Remote Protocol — Microsoft Learn

Hardening Active Directory: Blue Team DCSync Defense Guide

Overview & Defensive Context#

Architecture Hardening#

Defense Architecture Flowchart#

Layer 1: DACL Least-Privilege Governance on the Domain Naming Context#

Layer 2: Network-Level RPC Segmentation & Port Isolation#

1. Pinning Active Directory RPC to a Static Port

2. Restricting Inbound RPC via Windows Firewall with Advanced Security

Layer 3: System Access Control List (SACL) Auditing Configuration#

Production Detection Queries#

1. Production Sigma Rule: Active Directory DCSync Attempt#

2. PowerShell Host Audit Script: Auditing Domain Replication DACLs#

3. Suricata / Snort Network Signature: Detecting Anomalous drsuapi Calls#

Enterprise Mitigation Matrix#

Incident Response & Verification Playbook#

Phase 1: Live Triage & Workstation Attribution#

Phase 2: Containment & Source Isolation#

Phase 3: The `krbtgt` Double-Rotation Protocol#

Phase 4: Post-Remediation Verification & Health Checks#

Authoritative References#

Comments

Post a Comment

Hardening Active Directory: Blue Team DCSync Defense Guide

Overview & Defensive Context#

Architecture Hardening#

Defense Architecture Flowchart#

Layer 1: DACL Least-Privilege Governance on the Domain Naming Context#

Layer 2: Network-Level RPC Segmentation & Port Isolation#

1. Pinning Active Directory RPC to a Static Port

2. Restricting Inbound RPC via Windows Firewall with Advanced Security

Layer 3: System Access Control List (SACL) Auditing Configuration#

Production Detection Queries#

1. Production Sigma Rule: Active Directory DCSync Attempt#

2. PowerShell Host Audit Script: Auditing Domain Replication DACLs#

3. Suricata / Snort Network Signature: Detecting Anomalous drsuapi Calls#

Enterprise Mitigation Matrix#

Incident Response & Verification Playbook#

Phase 1: Live Triage & Workstation Attribution#

Phase 2: Containment & Source Isolation#

Phase 3: The krbtgt Double-Rotation Protocol#

Phase 4: Post-Remediation Verification & Health Checks#

Authoritative References#

Comments

Post a Comment

Phase 3: The `krbtgt` Double-Rotation Protocol#