How does a snapshot or backup of a virtualised domain controller yield every hash offline?
answer
- the database file plus the SYSTEM hive
- hashes are encrypted, need the boot key
- snapshot or backup copies both
- nothing executes on the live DC
basics
~20 sThe directory database file NTDS.dit and the SYSTEM registry hive both sit on a controller's disk. A VM snapshot or backup copies them without touching running processes; offline, the SYSTEM hive's boot key decrypts the hashes NTDS.dit stores. So backup or snapshot access equals replication rights.
solid answer
~40 s`NTDS.dit` is the on-disk database (an ESE database) holding every account's encrypted hashes; the hashes are encrypted under a Password Encryption Key that is itself sealed with the **boot key** (SYSKEY) derived from the `SYSTEM` registry hive. So to read the hashes offline an attacker needs *both* files — the database and the `SYSTEM` hive. A **VM snapshot**, a volume shadow copy, an exported **backup**, or the copies held by backup infrastructure all yield both, with nothing executing on the running controller. This is the 'nothing runs on the controller' route in its purest form. Its consequence for scoping: anyone who can snapshot the DC's virtual machine or restore its backup image is as powerful as anyone with replication rights or Domain Admin — a fact that org charts and admin-group counts entirely miss.
go deeper
Know that the directory has an on-disk database file and that a copy of it, plus a decryption key, can be taken away and read elsewhere.
Explain that NTDS.dit stores encrypted hashes and needs the SYSTEM hive's boot key to decrypt, so both files must be captured together.
Show you treat every copy of a DC's disk — snapshots, backups, volume access — as equivalent to replication rights, and that a quiet running controller proves nothing about the database's safety.
Own the conclusion that backup, virtualization, and storage teams are effectively domain-privileged and must be governed as tier-zero regardless of title.
## The two files A domain controller stores the directory in a single database file, **`NTDS.dit`** — an Extensible Storage Engine (ESE) database — under the system directory. Inside it, every account's password hashes and Kerberos long-term keys are stored **encrypted**. The encryption is layered: 1. Each secret attribute is encrypted with a **Password Encryption Key** (PEK), stored inside the database. 2. The PEK is itself encrypted under the **boot key** (also called SYSKEY), which is derived from data in the **`SYSTEM` registry hive** on the same host. So the database on its own is ciphertext. To turn it into usable hashes you need the `SYSTEM` hive as well. ## Why a copy is enough Both files live on the controller's disk. Any mechanism that copies that disk state — a **volume shadow copy**, a **virtual-machine snapshot**, an **exported or scheduled backup**, or simply access to the backup repository holding a DC's image — captures `NTDS.dit` and the `SYSTEM` hive together. None of this runs code on the live controller or requires a logon to it; the extraction and decryption happen entirely **offline**, on the attacker's own machine. This is why the leaf's framing is *nothing runs on the controller*: the domain's secrets are stolen without ever executing on the machine that holds them. ## The privilege equivalence The sharp consequence is an **equivalence of powers** that formal role models routinely miss: | Who | Access they hold | Effective power | |---|---|---| | Domain Admin | logon + replication | all domain secrets | | Account with delegated replication rights | DCSync over the interface | all domain secrets | | Virtualization admin | snapshot the DC's VM | all domain secrets | | Backup operator | restore the DC's backup image | all domain secrets | | Storage/SAN admin | read the DC's volume | all domain secrets | Every row ends in the same place. Holding backup rights is the same power as holding the replication right — the leaf's point exactly. Yet the virtualization team, the backup team, and the storage team see themselves as infrastructure, not as domain-privileged, and they appear in no Active Directory admin group. ## Why this is a senior question A junior knows DCSync exists; a middle engineer knows the replication rights. The senior insight is that the **live interface is only one of two doors**, and the offline door is opened by people no admin roster lists. Diagnosing why 'the DC looks quiet' does not mean the database is safe — because the theft can happen against a copy that the running DC never sees — is production judgment. It reframes the protected asset from *the running controller* to *every copy of its disk*.
- Why isn't NTDS.dit alone enough — what else must the attacker copy?The hashes inside are encrypted with the Password Encryption Key, which is sealed under the boot key stored in the `SYSTEM` registry hive. Without that hive you hold ciphertext, so the `SYSTEM` hive must be captured alongside the database for the offline extraction to yield real hashes.
- Who in a typical enterprise can obtain a DC's disk without holding any Active Directory right?Virtualization admins who can snapshot the controller's VM, backup operators who hold its restore images, and storage or SAN admins who can read its volume. None appears in an AD privileged group, yet each can reconstruct the directory database offline — an equivalence of power the org chart hides.
saying these in an interview costs you the question
- Claims the controller must be running for hashes to be extracted.
- Thinks copying NTDS.dit alone yields the passwords, forgetting the SYSTEM hive/boot key.
- Believes only Domain Admins can read the directory database.
- Assumes a quiet, patched controller means the database cannot be stolen.