One Stolen Active Directory File Can Expose Credentials for an Entire Windows Domain

A single stolen Active Directory database can turn a limited Windows intrusion into a domain-wide credential compromise.

Threat actors that obtain the NTDS.dIT file from a domain controller, along with its corresponding SYSTEM registry hive, can extract password hashes, Kerberos keys, and password-history data for domain identities offline.

While attackers may rotate payloads, loaders, command-and-control infrastructure, and evasion techniques, the core objective remains stable: gain privileged execution, reach a domain controller, copy Active Directory secrets, and remove them before defenders can respond.

The intrusion can begin with commonplace initial-access methods, including spearphishing, malicious Office documents, weaponized LNK files, or trojanized installers.

A victim may execute a small stager that fetches a memory-resident payload. At the same time, process hollowing or DLL sideloading helps the malware blend into a legitimate process tree.

After establishing encrypted command-and-control communications, an attacker typically seeks elevated privileges.

Those credentials can be reused through pass-the-hash or pass-the-ticket activity to move laterally toward more valuable systems.

The decisive stage is access to a domain controller. The NTDS.dit file, usually located at %SystemRoot%\NTDS\Ntds.dit, is the Active Directory Domain Services database.

It holds information about domain objects, including password hashes for user and computer accounts.

A threat actor does not need to crack every password immediately; possession of hashes and Kerberos-related keys may be enough to authenticate to services, impersonate users, or extend access elsewhere.attack.

The database is normally locked by the Extensible Storage Engine while Active Directory is running.

Attackers frequently evade that restriction by creating or accessing a Volume Shadow Copy, then copying the database from the snapshot rather than the live path.

Trellix’s research demonstrates this technique, driven attack path by simulating the dump and exfiltration of NTDS.dit and the SYSTEM hive, then detecting behavior across the kill chain rather than relying solely on a known-tool signature.

Stolen Active Directory database

MITRE specifically recommends monitoring suspicious shadow-copy creation, unusual access to NTDS.dit, and abuse of utilities or volume-management APIs associated with dumping attempts.

The accompanying SYSTEM hive is equally important. It contains the boot key required to decrypt protected data within the copied database.

U.S. defense guidance notes that actors need to retrieve the SYSTEM hive from the same domain controller to decrypt relevant NTDS.dit information.

SYSTEM-level access enables credential theft from lsass.exe, where attackers may collect NTLM hashes and Kerberos authentication material.

The pairing of these two artifacts should therefore be treated as a critical incident, not merely as suspicious file activity.

Once stolen, the files can be transferred through SMB to a staging host or exfiltrated over HTTPS to cloud storage, blending with routine encrypted web traffic.

Tools such as Impacket and DSInternals can then process the database offline, separating the most damaging stage of the attack from the victim environment.

Detection needs to cover both collection and exfiltration. Trellix NDR reports visibility into suspicious SMB activity and high-fidelity signatures associated with NTDS.dit transfer attempts, while its research frames the broader problem as correlating the credential-dumping and outbound-data stages.

That approach matters because a security product that detects only a specific Meterpreter module or command can miss equivalent activity performed with another utility.

High-value telemetry includes unexpected Volume Shadow Copy activity on domain controllers, ntdsutil.exe use outside approved administrative workflows, registry hive exports, abnormal access to the NTDS directory, and new copies of NTDS dit created in staging locations.

Detection engineering should correlate these events with privileged logons, remote SMB administration, unusual service creation, and outbound transfers from domain controllers.

If NTDS.dit or the SYSTEM hive is suspected of leaving a domain controller, defenders should assume domain credentials may be exposed.

The affected host should be isolated, suspicious outbound connections blocked, and potentially compromised privileged accounts disabled or reset.

Investigators should examine authentication activity for pass-the-hash, pass-the-ticket, remote service execution, and other lateral-movement indicators.

The response must also include a carefully planned reset of the KRBTGT account typically twice, following Microsoft’s operational guidance to invalidate forged Kerberos tickets and reduce Golden Ticket persistence risk.

Trellix likewise recommends prioritizing privileged-account resets, blocking exfiltration paths, reviewing PsExec and authentication logs, and restricting unauthorized shadow-copy creation.

A stolen NTDS.dit file is therefore not an ordinary data-loss event. It is a potential compromise of the identity foundation of a Windows enterprise and it demands containment, credential recovery, and forensic scoping at domain scale.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC