Active Directory DCSync: Deconstructing MS-DRSR Architecture

Overview & Threat Landscape#

In modern enterprise identity infrastructure, Active Directory Domain Services (AD DS) relies on a multi-master replication model to synchronize directory objects, schema definitions, and cryptographic secrets across distributed Domain Controllers. The protocol governing this distributed synchronization is the Directory Replication Service Remote Protocol (MS-DRSR). Under normal operations, authentic Domain Controllers exchange update sequence number (USN) vectors and request incremental directory changes over remote procedure calls (RPC).

However, when an adversary obtains control over a security principal granted specific directory replication privileges, they can invoke this replication mechanism to extract the entire domain's credential database. This attack technique, universally known as DCSync, fundamentally alters the attack calculus for enterprise identity environments:

• Bypassing the Domain Controller Operating System: Traditional credential dumping methodologies—such as creating a Volume Shadow Copy of NTDS.dit via ntdsutil.exe or dumping the Local Security Authority Subsystem Service (lsass.exe) process memory using minidump APIs—require local administrative or NT AUTHORITY\SYSTEM access directly on the Domain Controller. These actions leave high-visibility forensic artifacts: process creation events (Event ID 4688), service installations (Event ID 7045), and direct handle opens against lsass.exe (Sysmon Event ID 10).
• Protocol-Native Execution: DCSync executes entirely across the network over standard DCE/RPC transports. The attacker does not execute a single line of code on the Domain Controller, drop any binaries to the DC's filesystem, or inject into any DC processes. Instead, the attacker impersonates a domain controller in the directory replication topology, prompting the genuine Domain Controller to parse, package, encrypt, and transmit credential objects over RPC.
• Extraction of Master Kerberos Keys: DCSync allows the extraction not only of standard NTLM password hashes (unicodePwd), but also the complete Kerberos key history (Primary:Kerberos-Newer-Keys), including AES-256 and AES-128 master keys for the krbtgt account. Armed with the krbtgt AES-256 key, an attacker can mint arbitrary Kerberos Ticket-Granting Tickets (Golden Tickets), achieving persistent and undetectable domain dominance across the entire Active Directory forest.

[!WARNING] DCSync does not exploit a software memory corruption bug or an unpatched operating system flaw. It abuses the legitimate architectural design of Active Directory's replication protocol. If an account possesses directory replication extended rights, the Domain Controller considers the credential request completely legitimate.

---

Vulnerability & Attack Root-Cause Analysis#

The root cause of DCSync lies in the delegation of Active Directory Extended Rights on the root of the Domain Naming Context (NC). To understand why this protocol mechanism is vulnerable to abuse, we must analyze the DCE/RPC interface definition, the Update Sequence Number (USN) synchronization model, and the access check evaluated by the Directory System Agent (DSA).

The MS-DRSR Interface & RPC Bind Sequence#

Directory replication operates over DCE/RPC using the drsuapi interface. The interface is defined with the following UUID and version:

• Interface UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2
• Interface Version: 4.0
• Transport: RPC dynamic endpoints over TCP (negotiated via the RPC Endpoint Mapper on TCP port 135)
• Required Authentication Level: RPC_C_AUTHN_LEVEL_PKT_PRIVACY (Packet privacy enforces payload encryption and integrity via Kerberos or NTLMSSP session keys).

The client establishes an RPC session and executes IDL_DRSBind (Opnum 0). During this handshake, the client passes a DRS_EXTENSIONS_INT structure containing capability flags:

C

typedef struct {
    DWORD cb;
    DWORD dwFlags;
    GUID  siteObjGuid;
    DWORD Pid;
    DWORD dwReplEpoch;
    DWORD dwFlagsExt;
    GUID  configObjGuid;
    FILETIME rtTime;
} DRS_EXTENSIONS_INT;

Key extension flags negotiated during bind include:

• DRS_EXT_GETCHGREQ_V8 (0x00000008): Indicates support for version 8 of the DRSGetNCChanges request structure.
• DRS_EXT_STRONG_ENCRYPTION (0x00000020): Indicates that the caller supports 128-bit/256-bit session key encryption for confidential attributes.

Once the Domain Controller verifies the authentication ticket and negotiates extensions, it returns an opaque RPC context handle (DRS_HANDLE).

Access Check Mechanics: The Three Replication Extended Rights#

When the client invokes IDL_DRSGetNCChanges (Opnum 3) to request directory objects, the Domain Controller's Directory System Agent (DSA)—executing within lsass.exe—evaluates the caller's security token against the Discretionary Access Control List (DACL) located at the head of the target naming context (e.g., DC=corp,DC=local).

The security evaluation specifically verifies whether the caller's token contains the following Active Directory Extended Rights:

1. DS-Replication-Get-Changes:
   • Rights GUID: {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2}
   • Description: Allows replicating directory changes across unprivileged partitions.
2. DS-Replication-Get-Changes-All:
   • Rights GUID: {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2}
   • Description: Allows replicating all attributes, including confidential and secret attributes (unicodePwd, supplementalCredentials).
3. DS-Replication-Get-Changes-In-Filtered-Set:
   • Rights GUID: {89e77b59-d782-4706-9acb-3da2be3880b6}
   • Description: Required when replicating to a Read-Only Domain Controller (RODC) utilizing filtered attribute sets.

In standard installations, these permissions are restricted to the Domain Controllers and Enterprise Domain Controllers built-in security groups. However, administrative misconfigurations, legacy synchronization tools (such as Azure AD Connect / Entra Connect service accounts), or delegated administration policies often assign these extended rights directly to regular user accounts, service principals, or compromised helpdesk groups.

Wire Encryption and the Session Key Decryption Vector#

When IDL_DRSGetNCChanges returns confidential attributes, the Domain Controller does not transmit them in cleartext. Sensitive properties—specifically unicodePwd (attribute ID 0x00020084) and supplementalCredentials (attribute ID 0x00020083)—are encapsulated inside ENCRYPTED_SECRET structures.

The encryption mechanism utilizes the RPC session key established during the initial SPNEGO/Kerberos authentication handshake:

C

typedef struct {
    DWORD cbSessionKey;
    BYTE  rgbSessionKey[16]; // Or 32 bytes for AES
} DRS_SESSION_KEY;

typedef struct {
    DWORD EncryptedDataLength;
    BYTE  Salt[16];
    BYTE  CheckSum[16];
    BYTE  EncryptedData[1];
} ENCRYPTED_SECRET;

Because the attacking client negotiated the RPC session key during the authentication bind, the client possesses the exact cryptographic material required to decrypt the payload in user space. The attacker decrypts the ciphertext, strips the 16-byte CRC checksum, and extracts the raw attribute bytes.

---

Exploit Architecture#

The sequence diagram below details the complete protocol exchange between an adversary holding replication extended rights and a targeted Active Directory Domain Controller:

sequenceDiagram
    autonumber
    actor Attacker as Compromised Principal (Client)
    participant EPM as RPC Endpoint Mapper (TCP 135)
    participant KDC as Kerberos KDC / Auth Service
    participant DC as Target Domain Controller (drsuapi)

    Note over Attacker,EPM: Phase 1: RPC Endpoint Resolution
    Attacker->>EPM: ept_map request (UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2)
    EPM-->>Attacker: ept_map response (Dynamic TCP Port e.g. 49155)

    Note over Attacker,KDC: Phase 2: Mutual Authentication
    Attacker->>KDC: TGS-REQ (SPN: LDAP/dc01.corp.local)
    KDC-->>Attacker: TGS-REP (Session Key & Ticket with RPC_C_AUTHN_LEVEL_PKT_PRIVACY)

    Note over Attacker,DC: Phase 3: DRS Replication Context Binding
    Attacker->>DC: RPC Bind (Interface: drsuapi, Security Provider: Kerberos)
    DC-->>Attacker: RPC BindAck
    Attacker->>DC: IDL_DRSBind (Opnum 0: Negotiate DRS Extensions)
    DC-->>Attacker: IDL_DRSBind Response (Returns DRS_HANDLE Context)

    Note over Attacker,DC: Phase 4: Target Object Resolution
    Attacker->>DC: IDL_DRSCrackNames (Opnum 12: Resolve "corp\krbtgt" to Object GUID)
    DC-->>Attacker: IDL_DRSCrackNames Response (DN: CN=krbtgt,CN=Users,DC=corp,DC=local)

    Note over Attacker,DC: Phase 5: Replicating Secret Attributes
    Attacker->>DC: IDL_DRSGetNCChanges (Opnum 3: Request Object with DRS_SYNC_PAS)
    critical Access Check on Domain NC Head
        DC->>DC: Evaluate Token DACL against Extended Rights GUIDs
        Note over DC: Verified: DS-Replication-Get-Changes-All (1131f6ad-9c07...)
    end
    DC->>DC: Package unicodePwd & supplementalCredentials
    DC->>DC: Encrypt Secrets using Negotiated RPC Session Key
    DC-->>Attacker: DRS_MSG_GETCHGREPLY_V6 (Encrypted Object Data)

    Note over Attacker: Phase 6: Local Decryption & Extraction
    Attacker->>Attacker: Decrypt Secrets with RPC Session Key
    Note over Attacker: Extracted krbtgt NTLM Hash, AES-128, AES-256 Keys

---

Attack Path Step-by-Step#

Understanding the concrete execution stages of a DCSync attack allows Digital Forensics and Incident Response (DFIR) analysts to reconstruct attacker activity, identify affected accounts, and pinpoint logging gaps.

Step 1: Enumerating Active Directory Extended Replication Rights#

Before initiating the replication request, an adversary enumerates the Domain Naming Context security descriptor to verify if their current execution context possesses replication rights.

An attacker queries the root domain object via LDAP for explicit Access Control Entries (ACEs) matching the replication GUIDs:

BASH

# Inspecting Active Directory Domain Root DACL for Replication Extended Rights
Get-Acl "AD:DC=corp,DC=local" | Select-Object -ExpandProperty Access | Where-Object {
    $_.ObjectType -eq "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2" -or
    $_.ObjectType -eq "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" -or
    $_.ObjectType -eq "89e77b59-d782-4706-9acb-3da2be3880b6"
} | Select-Object IdentityReference, ActiveDirectoryRights, ObjectType, AccessControlType

If the IdentityReference points to a compromised user, service account, or a security group under attacker control, the adversary proceeds to DCSync.

Step 2: The IDL_DRSBind Protocol Handshake#

The attacker initiates a TCP connection to the Domain Controller's RPC Endpoint Mapper (TCP port 135) to resolve the active port binding for the drsuapi interface. Upon receiving the high-order dynamic RPC port (typically within 49152-65535), the client initiates the RPC connection:

1. RPC Authentication: The client transmits an RPC_BIND packet requesting authentication service 0x10 (Kerberos) or 0x0A (NTLMSSP) with RPC_C_AUTHN_LEVEL_PKT_PRIVACY (0x06).
2. Context Creation: The client calls IDL_DRSBind with DRS_EXT_GETCHGREQ_V8 set. The Domain Controller responds with an opaque 20-byte DRS_HANDLE.

Step 3: Targeted Object Synchronization via IDL_DRSGetNCChanges#

Rather than requesting a massive full-partition synchronization (which would transfer gigabytes of directory data and alert network monitoring systems), the attacker sends an optimized DRS_MSG_GETCHGREQ_V8 structure targeting a specific object:

C

typedef struct {
    GUID          uuidDsaObjDest;    // Invoking Client GUID
    GUID          uuidInvocIdSrc;    // Source DC Invocation ID
    DSNAME        *pNC;              // Target Object DN (e.g. CN=krbtgt,CN=Users,DC=corp,DC=local)
    USN_VECTOR    usnvecFrom;        // High-water mark (USN: 0)
    SCHEMA_PREFIX_TABLE PrefixTableDest;
    ULONG         ulFlags;           // DRS_INIT_SYNC | DRS_WRIT_REP | DRS_SYNC_PAS
    ULONG         cExtendedInfo;
    ULONG         ulExtendedOp;      // EXOP_REPL_OBJ (0x00000006 - Single Object Replication)
} DRS_MSG_GETCHGREQ_V8;

By setting ulExtendedOp to EXOP_REPL_OBJ (0x00000006), the request instructs the Domain Controller to bypass standard USN vector replication tracking and immediately export the attributes of the single object identified by pNC.

Step 4: Deconstructing supplementalCredentials#

The response returned by the Domain Controller contains the encrypted directory attributes. Once decrypted with the RPC session key, the attacker parses the supplementalCredentials property.

This property is a binary property structured as a user property store containing nested property records:

JSON

{
  "PropertyCount": 3,
  "Properties": [
    {
      "Name": "Primary:Kerberos-Newer-Keys",
      "Type": "WSTR",
      "Data": {
        "DefaultSalt": "CORP.LOCALkrbtgt",
        "KeyEntries": [
          { "KeyType": 18, "KeyName": "AES256-CTS-HMAC-SHA1-96", "Key": "e4a2...98f1" },
          { "KeyType": 17, "KeyName": "AES128-CTS-HMAC-SHA1-96", "Key": "5c11...88ab" },
          { "KeyType": 23, "KeyName": "RC4-HMAC", "Key": "0cb2...44f9" }
        ]
      }
    },
    {
      "Name": "Primary:WDigest",
      "Type": "WSTR",
      "Data": { "DigestHashes": ["..."] }
    },
    {
      "Name": "Packages:DPAPI",
      "Type": "WSTR",
      "Data": { "DomainBackupKeys": ["..."] }
    }
  ]
}

By extracting the Primary:Kerberos-Newer-Keys payload for the krbtgt account, the attacker obtains the AES-256 master key. This key allows immediate forgery of Kerberos TGTs with customized SIDs, group memberships (such as Domain Admins SID S-1-5-21-...-512), and arbitrary lifespans.

Step 5: DFIR Triage & Event Log Reconstitution#

When investigating a potential DCSync incident, forensic analysts must correlate multiple disparate event logs on the targeted Domain Controller:

1. Windows Security Event ID 4662: An Operation Was Performed on an Object

Event ID 4662 is the primary detection artifact generated by the Directory Service access check:

• Object Server: DS
• Object Type: domainDNS
• Object Name: DC=corp,DC=local
• Access Mask: 0x100 (Control Access)
• Properties:
  • {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} (DS-Replication-Get-Changes)
  • {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2} (DS-Replication-Get-Changes-All)
• Subject: The user account and domain SID that initiated the RPC call.

[!IMPORTANT] Authentic Domain Controllers legitimately generate Event ID 4662 during normal replication cycles. The critical forensic indicator is the Subject Security ID: if Event ID 4662 is generated by a user account, service principal, or computer account located outside the Domain Controllers organizational unit (OU), it is an indicator of compromise.

2. Windows Security Event ID 4624: Network Logon Correlation

Immediately preceding Event ID 4662, the Domain Controller records a network logon event:

• Logon Type: 3 (Network Logon)
• Authentication Package: Kerberos or NTLM
• Source Network Address: The IP address of the attacking workstation.
• Workstation Name: The hostname of the originating host.

By correlating the LogonId from Event ID 4624 with the SubjectLogonId in Event ID 4662, incident responders can pinpoint the network location of the attacker.

---

Fast Cyber Defense Morning Takeaways#

1. Protocol Legitimacy Masks Adversarial Intent: DCSync is stealthy because it leverages legitimate Microsoft Directory Replication APIs. It bypasses endpoint security controls on the Domain Controller because lsass.exe is performing expected operations, never triggering process-injection or memory-scraping detections.
2. Extended Rights Are the Perimeter: The security of an entire Active Directory forest relies on the integrity of the DACLs applied to the root domain object. Any unvetted principal holding DS-Replication-Get-Changes-All represents an unmonitored backdoor to full domain compromise.
3. Forensic Correlation Is Mandatory: Detecting DCSync requires enabling Directory Service Access auditing (SACL on the domain head) to capture Event ID 4662 and filtering out known computer accounts belonging to authorized Domain Controllers.

In tonight's Evening Defense Guide (EDITION 2), we will engineer end-to-end blue team defenses:

• Automated PowerShell scripts to audit and strip unauthorized replication ACEs across all domain partitions.
• Production-grade Sigma rules to detect anomalous Event ID 4662 and network RPC replication calls from non-DC IPs.
• Windows Filtering Platform (WFP) and host firewall rules to restrict TCP/135 and dynamic RPC replication traffic strictly to authorized Domain Controller IP addresses.

---

Authoritative References#

1. Microsoft Open Specifications: [MS-DRSR]: Directory Replication Service (DRS) Remote Protocol — Microsoft Learn
2. Microsoft Open Specifications: [MS-DRSA]: Directory Replication Service (DRS) Administrative Protocol — Microsoft Learn
3. Benjamin Delpy & Vincent Le Toux: Mimikatz DCSync Architecture and Technical Reference — GitHub
4. Cybersecurity and Infrastructure Security Agency (CISA): Active Directory Security Best Practices & Privilege Escalation Mitigation — CISA Advisory