Detecting NTDS.dit extraction attempts on domain controllers

NTDS.dit is the Active Directory database on a domain controller. It holds directory objects, password hashes, and other identity data that make it a high-value target. If an attacker can copy or extract it, they may be able to work offline against credentials and move from one compromised account to broader domain access. For that reason, detecting NTDS.dit extraction attempts on domain controllers is a useful control for organisations that rely on Active Directory for identity and access management.

This is not only a concern for large enterprises. UK SMEs often run a small number of domain controllers that support file access, line-of-business applications, remote administration, and privileged access. That concentration of identity services means one successful extraction attempt can have an outsized impact. The goal is not to assume every access to a domain controller is hostile. It is to identify the patterns that are unusual, risky, and worth investigating quickly.

What NTDS.dit is and why attackers target it

The Active Directory database stores the information that domain controllers use to authenticate users and authorise access. In practical terms, it is the source of truth for identities, group membership, and password-related material. The file is normally locked while the domain controller is running, so direct access is not straightforward. That is one reason attackers often rely on indirect collection methods rather than trying to read it in place.

From a defender’s point of view, the important point is that NTDS.dit extraction is usually a precursor to wider identity compromise. It is often associated with credential theft, privilege escalation, and lateral movement. If you already monitor for suspicious credential activity, as discussed in our article on fileless malware and living-off-the-land attacks, NTDS.dit-related activity should sit in the same detection family because the attacker is typically using legitimate Windows tools and administrative paths to achieve a malicious outcome.

How the Active Directory database is used on domain controllers

Domain controllers use NTDS.dit alongside supporting registry hives and log files to service authentication and directory lookups. In a healthy environment, the file is not something administrators normally browse, copy, or mount directly during routine operations. Access tends to be mediated by backup software, directory maintenance tasks, or controlled recovery procedures.

That operational reality gives defenders useful context. If a process on a domain controller is interacting with NTDS.dit, the SYSTEM hive, or shadow copy locations outside approved maintenance windows, that activity deserves attention. The same is true if the access pattern comes from an unusual host, account, or remote session type.

Why extraction attempts are high risk for identity compromise

NTDS.dit is valuable because it can expose password hashes and directory data that attackers can use offline. Even where modern password hashing and other controls are in place, the exposure of domain identity material can still create serious follow-on risk. The main defensive issue is not the file itself, but what it enables afterwards: impersonation, privilege abuse, and persistence.

For SMEs, this matters because identity compromise often outlives the initial intrusion. A single extracted database can be used long after the original access path has been closed. That is why detection should be paired with hardening and response planning, not treated as a standalone alert.

Common ways NTDS.dit extraction is attempted

Attackers generally prefer methods that blend into normal administration. They may create or use a Volume Shadow Copy, invoke built-in backup or directory tools, or stage files through remote management channels. The exact technique varies, but the defensive challenge is similar: identify when a legitimate-looking workflow is being used to collect sensitive directory data.

Volume Shadow Copy and other offline copy methods

One common pattern is to create a shadow copy of the system volume and then copy the database from the snapshot rather than from the live file. This avoids the file lock problem and can be done with built-in Windows capabilities. From a detection perspective, shadow copy creation, mounting, and deletion are all useful signals, especially when they occur on a domain controller outside expected backup activity.

Shadow copy activity is not inherently malicious. Backup products may use it legitimately. The key is to correlate it with the surrounding process tree, account context, and destination path. If the same host also launches unusual command shells, script interpreters, or file copy tools, the risk score should rise.

Use of built-in tools such as ntdsutil and IFM workflows

Administrators can use native tools for directory maintenance and recovery. One example is ntdsutil, which supports Install From Media workflows. Those workflows are legitimate in the right context, but they are also attractive to attackers because they can produce a copy of directory data without needing custom malware.

Detection here should focus on the command line, parent process, and the account that launched the tool. A domain admin running a documented recovery procedure from a known management host is very different from a service account or interactive user launching the same utility from an unusual workstation.

Abuse of remote administration, backup, and file copy paths

Another pattern is abuse of remote administration channels such as PowerShell remoting, WMI, scheduled tasks, or remote service creation. Once an attacker has administrative access, they may use standard file copy utilities or backup paths to stage the database or supporting files elsewhere. This is one reason it is important to monitor both the source and destination of administrative activity, not just the process name.

If you are already building detections around remote execution and administrative tooling, the same telemetry can help here. The difference is that NTDS.dit extraction often combines several benign-looking actions into a chain: remote execution, shadow copy creation, file access, and outbound transfer or staging.

What telemetry to collect from domain controllers

Good detection starts with good telemetry. On domain controllers, you want enough visibility to reconstruct process activity, file access, and administrative context without drowning in noise. A practical baseline usually includes Windows Security logs, System logs, Directory Service logs, and endpoint telemetry such as Sysmon. If you are still building out your logging estate, our article on what security logs you actually need and why is a useful companion piece.

Windows Security, System, and Directory Service logs

Security logs are useful for logon events, privilege use, service creation, and process creation where enabled. System logs can help with service changes, driver loads, and storage-related events. Directory Service logs may surface replication, directory service behaviour, and other domain controller-specific activity that can help explain whether a given action was expected.

For NTDS.dit-related hunting, the most useful approach is to ensure these logs are centrally collected and time-synchronised. Without that, correlating a process event with a shadow copy or file access event becomes much harder.

Process creation, command-line, and script telemetry

Process creation events are often the highest-value source for this use case. You want command-line visibility, parent-child relationships, and ideally script block logging for PowerShell. This helps you distinguish an approved administrative workflow from a suspicious one that uses the same built-in binaries.

On Windows, Sysmon is particularly useful because it can provide richer process telemetry than the default logs. Event ID 1 for process creation, Event ID 3 for network connections, Event ID 11 for file creation, and Event ID 22 for DNS queries can all contribute to the wider picture. For NTDS.dit extraction attempts, process creation and file access are usually more important than network indicators, but the network context can help confirm staging or exfiltration.

File, share, and volume shadow copy activity

File telemetry should cover access to NTDS.dit, the SYSTEM hive, and any backup or staging directories used on domain controllers. If your tooling supports it, monitor file creation, copy, rename, and deletion events in locations that are unusual for domain controller operations. Shadow copy activity is also worth tracking, especially creation and removal events.

Be careful not to over-collect without a plan. File telemetry on domain controllers can be noisy. Focus on the small set of paths and actions that matter most for this technique, then tune based on what your environment actually uses.

PowerShell, WMI, and remote execution signals

PowerShell, WMI, and remote service creation are common enablers for post-compromise activity. Script block logging can expose encoded commands, suspicious module use, and administrative scripts that interact with backup or shadow copy functions. WMI and remote execution events can help you identify when a domain controller is being managed from an unexpected source.

These signals are especially useful when combined with account context. A privileged account used from a jump host during a maintenance window is one thing. The same account used from a user workstation at an unusual time is another.

Detection logic that is most useful in practice

In practice, the best detections are not single-event rules. They are small chains of activity that make sense together. That approach reduces false positives and better reflects how NTDS.dit extraction is actually attempted.

Suspicious process chains and command-line patterns

Look for process chains that combine administrative tooling with file access or shadow copy operations. Examples include a shell spawning backup-related utilities, a script host launching a directory maintenance tool, or a remote management process followed by file copy activity. The exact command line will vary, so focus on the intent expressed by the chain rather than one fixed string.

In a SIEM, this is often best expressed as correlation logic. For example, a rule might alert when a domain controller sees shadow copy creation followed by access to NTDS.dit or the SYSTEM hive within a short time window, from the same host and account. That is much more useful than a simple keyword match on a tool name.

Indicators of shadow copy creation, mounting, or deletion

Shadow copy events are valuable because they often appear in the middle of an extraction workflow. Create, expose, mount, and delete operations can all be relevant. If your environment uses backup software that legitimately creates snapshots, build your detection around the surrounding context: source host, account, service name, process tree, and destination path.

One practical pattern is to alert on shadow copy creation on a domain controller followed by access to a database file in a snapshot path, especially if the process is not a known backup agent. Another is to alert on deletion of shadow copies shortly after their creation, which can indicate an attempt to reduce forensic evidence.

Unexpected access to NTDS.dit, SYSTEM hive, or backup locations

Direct access to NTDS.dit is a strong signal, but it is not always visible in a useful way. That is why supporting artefacts matter. Access to the SYSTEM hive, backup directories, temporary staging folders, or snapshot mount points can all indicate that someone is preparing to extract or package the data.

If you can collect file access telemetry, use it to identify which process touched the file and from where. If you cannot, use adjacent signals such as process creation, service activity, and file creation in nearby paths. The aim is to build enough confidence to investigate, not to prove the entire attack chain in one rule.

Correlating administrative activity with unusual source hosts or accounts

Context is often the difference between a useful alert and noise. Domain controller administration should normally come from a small set of approved hosts, using named admin accounts, during known maintenance windows. When the same activity comes from a different source, a different account type, or an unusual time, the risk increases.

This is where asset and identity context matter. If your SIEM can enrich events with host role, account privilege, and management zone data, use it. A simple allow-list of known admin hosts is not enough on its own, but it is a good starting point for reducing noise.

How to reduce false positives without losing coverage

False positives are common if you alert on every shadow copy or every backup-related command. The objective is not to eliminate them entirely. It is to make sure the alerts that remain are worth an analyst’s time.

Separating legitimate backup activity from hostile collection

Start by documenting which backup products, scripts, and maintenance tasks touch domain controllers. Then identify the process names, service accounts, and source hosts those workflows use. That gives you a baseline for comparison. Anything outside that baseline should be treated as suspicious until explained.

Where possible, place backup activity into a separate detection bucket. For example, you might suppress known backup agent events but still alert when a backup-related utility is launched interactively or from an unmanaged host. That preserves coverage while reducing routine noise.

Allow-listing known admin hosts and backup tooling carefully

Allow-listing can help, but it needs discipline. Keep the list short, reviewed, and tied to specific management functions. Do not allow-list broad subnets or generic user workstations. If a host is allowed to manage domain controllers, it should be hardened, monitored, and used only for that purpose.

This is also a good place to align with your broader hardening work. If you are tightening endpoint standards, our article on endpoint hardening using CIS Benchmarks and our guide to reducing attack surface using system hardening techniques both support the same principle: reduce the number of places from which sensitive actions can be performed.

Using time, host, and account context to raise fidelity

Time of day, day of week, host role, and account privilege are all useful enrichment fields. A shadow copy event during a planned backup window from a known backup server is low risk. The same event at 02:00 from a user workstation using an administrative account is much more concerning.

For small teams, this kind of context-based triage is often more effective than trying to write a perfect signature. It also scales better as your environment changes.

Example hunting approach for SOC and detection engineers

If you are building hunts rather than fixed alerts, start with a few hypotheses: who can access domain controllers, which hosts are allowed to manage them, and what normal backup activity looks like. Then test those assumptions against recent telemetry. The aim is to find deviations that indicate collection behaviour.

Sigma-style logic for SIEM content

Sigma is useful for expressing portable detection logic across multiple SIEM platforms. For NTDS.dit extraction attempts, a Sigma rule might look for suspicious parent-child process combinations, command-line fragments associated with shadow copy or directory maintenance activity, or file access to known sensitive paths. The important part is to combine conditions rather than rely on one indicator.

For example, you might correlate a process event where a shell launches a backup or directory utility, then a file event showing access to a snapshot path, then a network event showing outbound transfer. That three-step pattern is more robust than any single event on its own.

KQL hunting ideas for Microsoft Sentinel

In Microsoft Sentinel, KQL can be used to join process, file, and sign-in data across a short time window. A practical hunt might start with domain controller process creation events, filter for shadow copy or backup-related commands, and then join to file creation or access events on the same host. You can then enrich the result with account and device information to identify whether the activity came from an approved management path.

Keep the query simple at first. Overly complex hunts are hard to maintain and harder to explain. Once you have a working pattern, add exclusions for known backup agents and approved admin hosts.

Sysmon event combinations that improve confidence

Sysmon is most effective when you use it as a set of complementary signals. Process creation can show the command line, file creation can show staging, and network connections can show transfer. If you also collect DNS queries, you may spot a host resolving an unusual destination shortly after sensitive file access.

For this technique, the strongest combinations are usually process creation plus file access, or process creation plus shadow copy activity. Network telemetry is helpful, but it is often secondary unless the attacker is moving the data off the domain controller immediately.

How this technique fits into MITRE ATT&CK

Mapping detections to MITRE ATT&CK helps you understand where NTDS.dit extraction sits in the wider attack chain. It is closely related to credential dumping and other identity-focused techniques. That mapping is useful because it helps you prioritise controls around the most damaging stages of an intrusion.

It also helps with coverage reviews. If you already have detections for LSASS access, DCSync, and suspicious remote administration, NTDS.dit extraction should be part of the same identity defence programme rather than a one-off rule. If you want a broader framework for this kind of mapping, our article on mapping detections and controls to MITRE ATT&CK provides a useful structure.

Hardening steps that make extraction harder

Detection is important, but it is easier to defend against a technique that is difficult to perform in the first place. The most effective hardening steps are usually about reducing who can administer domain controllers, where that administration can happen from, and which tools are available on those systems.

Restricting domain controller access and admin paths

Use tiered administration and separate privileged accounts from everyday user accounts. Domain controller administration should be limited to a small number of hardened management hosts. Where possible, block interactive logon to domain controllers except for tightly controlled administrative use. This reduces the chance that an attacker can use a compromised workstation to reach the right tools and paths.

Also review local administrator membership, remote management permissions, and service account scope. The fewer accounts that can touch a domain controller, the easier it is to spot anomalous behaviour.

Limiting backup and shadow copy abuse opportunities

Backup tooling should be explicit, documented, and monitored. If a backup product needs to create shadow copies, that should be visible in your logs and tied to a known service account or agent. Avoid giving broad administrative rights to backup processes unless there is a clear operational need.

Where practical, separate backup infrastructure from general administration. That makes it easier to distinguish a backup workflow from a collection workflow. It also reduces the chance that a compromised admin account can be used to stage data through a legitimate backup path.

Improving tiering, privilege separation, and monitoring

Privilege separation is one of the most effective controls here. Admin accounts should not be used for email, web browsing, or general productivity. Management hosts should be hardened and monitored. Domain controllers should be treated as high-value assets with tighter logging and more restrictive access than standard servers.

From a monitoring perspective, make sure your SIEM can distinguish between normal administrative use and unusual activity. If you already have centralised visibility across endpoints, identity, and network, you are in a much better position to spot the multi-stage patterns that NTDS.dit extraction tends to involve.

Incident response considerations if you suspect extraction

If you suspect an extraction attempt, preserve evidence before making major changes. Capture relevant logs, process data, and any available file or shadow copy telemetry. If the activity is ongoing, consider isolating the affected domain controller in a way that preserves evidence and avoids unnecessary disruption to authentication services.

Then scope the likely exposure. Determine which accounts were used, which hosts initiated the activity, whether shadow copies were created, and whether any data was staged or transferred. Because NTDS.dit extraction can lead to offline credential abuse, you should also assess whether privileged accounts, service accounts, or other high-value identities may have been exposed.

At that point, containment may need to extend beyond the original host. That could include password resets for affected privileged accounts, review of recent sign-ins, and checks for persistence in adjacent systems. If you need a broader response framework, our article on incident response fundamentals for SMEs is a sensible place to anchor the process.

Practical checklist for small security teams

For a small team, the most useful approach is to implement a minimum viable detection set and then improve it over time. Start with the following:

• Collect process creation, command-line, and file telemetry from all domain controllers.
• Log shadow copy creation, mounting, and deletion events where your tooling supports it.
• Monitor access to NTDS.dit, the SYSTEM hive, and backup or staging locations.
• Restrict domain controller administration to known hosts and named privileged accounts.
• Separate approved backup workflows from interactive administrative activity.
• Review alerts weekly and tune exclusions based on real operational use.

As a detection programme matures, you can add more correlation, better enrichment, and stronger response automation. The important thing is to start with signals that are high value and operationally sustainable.

If you want support designing the logging, detection, and hardening layers together, we can help you shape that into a practical roadmap. For organisations that want advisory support aligned to an ISO 27001-style risk approach, Speak to a consultant.

Frequently asked questions

Can NTDS.dit extraction be detected reliably?

It can often be detected with good confidence, but not always with a single event. The most reliable approach is to correlate process creation, shadow copy activity, file access, and source host context on domain controllers.

What is the difference between legitimate backup activity and malicious extraction?

Legitimate backup activity should come from known backup tooling, approved service accounts, and expected management hosts. Malicious extraction often uses the same Windows capabilities but from unusual accounts, hosts, or times, and is more likely to be followed by staging or transfer activity.