What does a DCSync attack achieve, and why does it need no code on a domain controller?
answer
- pretend to be a domain controller
- use replication, not malware
- no logon, no dropped file
- one request, every account's hash
basics
~20 sDCSync abuses Active Directory replication: with the right permissions an attacker asks a domain controller to send accounts' long-term password hashes, just as a peer controller would. Nothing runs on the controller, so it resembles ordinary replication.
solid answer
~40 sDCSync (ATT&CK `T1003.006`) has an attacker impersonate a domain controller and issue a normal directory-replication request (`IDL_DRSGetNCChanges`) asking a real controller to replicate accounts' secret attributes — their long-term password hashes. Replication is a legitimate controller-to-controller function, so no binary is dropped and nothing executes on the target; from the controller's point of view a peer asked for an update. Given the right permissions, a single request can pull hashes for one account or for every principal in the domain, including computer and service accounts. That is why it is the domain database's cheapest route: no malware, no logon to the controller, just a request over an interface the directory is built to answer.
go deeper
Recall that DCSync steals password hashes by asking a domain controller to replicate them, that it needs permissions rather than malware, and that nothing runs on the controller.
Be ready to explain the replication request itself — impersonating a DC and calling the directory-replication interface for secret attributes — and why that leaves no trace on the target host.
Show you understand the scope: one request can dump the entire directory, including machine and service accounts, which is what makes the database the highest-value and quietest target.
Frame it as the reason the privileged tier must be defined by who can reach the database at all, not by who can log on to a controller.
## The target Active Directory keeps every account's authentication material — password hashes and Kerberos long-term keys — in a database on each **domain controller** (DC), the servers that authenticate users and hold the directory. Controllers keep in step by **replication**: when one changes, it tells the others, and a peer can ask for the changed data. That machinery is the target. ## What DCSync does DCSync is a technique (MITRE ATT&CK `T1003.006`, *OS Credential Dumping: DCSync*) in which an attacker with sufficient rights **pretends to be a domain controller** and sends a legitimate replication request — the `IDL_DRSGetNCChanges` call in the directory replication service protocol — asking a real DC to hand over the secret attributes of one account or of the whole directory partition. The DC, seeing a request it is designed to answer, replies with the requested hashes. ## Why nothing runs on the controller The crucial property is that **no code executes on the DC and no one logs on to it**. The request comes from any domain-joined host over the replication RPC interface. There is no dropped file, no new process, no service on the controller — only network traffic that looks like one DC talking to another. This is what makes the database the quietest place to steal from at the host level: an attack on a workstation leaves something on that workstation, but DCSync leaves nothing on the machine it robs. ## What you get A single request can be scoped to one account or to the entire directory naming context. Replicating the whole directory returns current and historical hashes for **every principal**: ordinary users, computer (machine) accounts, service accounts, and the domain's most sensitive keys. One request, and the offline copy of the domain's secrets is complete. That is the difference in value between this and dumping a single host — a host yields whatever logged on there; the database yields everyone. ## The two routes to the same data There are two ways to reach the domain database. DCSync uses the *live* replication interface with the right permissions. The other route is *offline*: obtain a copy of the database file and the key that decrypts it, from a snapshot or backup, so that again nothing runs on the running controller. Both end at the same prize — every long-term key held at once. ## Why juniors are asked this It is the canonical demonstration that a domain's crown jewels can be taken by *using* the directory as designed rather than by breaking anything. Knowing that DCSync needs permissions, not malware, and that it targets the replication interface, is the entry point to everything else about protecting the domain database.
- Does DCSync require you to log on to the domain controller itself?No. It is a remote request over the directory-replication RPC interface issued from any domain-joined host and aimed at the controller. You never need an interactive session, a shell, or code execution on the DC — only the network path and sufficient replication rights.
- What accounts' secrets can a single DCSync request return?Anywhere from one to all of them. You can target a single account or replicate the whole directory naming context, which returns current and historical long-term hashes for every user, computer account, service account, and the domain's key accounts at once.
saying these in an interview costs you the question
- Claims DCSync installs a rootkit or malware on the domain controller.
- Says you must be logged into the DC console to run it.
- Thinks DCSync can only target one account at a time.
- Believes it exploits a software vulnerability rather than using replication as designed.