Active Directory backup extraction

Threat snapshot

Windows Server Backup includes a command-line utility called wbadmin.exe that can create and manage backups of Windows Server system state, including the Active Directory database. In its intended use, wbadmin.exe helps administrators create recoverable snapshots of domain controllers for disaster recovery purposes. In an attacker's hands, it is a built-in, signed Microsoft tool that can produce a portable copy of the NTDS.dit credential database without requiring direct file access, VSS manipulation, or any third-party tooling.

When an attacker runs wbadmin.exe with arguments targeting the Active Directory database specifically, the result is a backup set that contains NTDS.dit and the SYSTEM registry hive required to decrypt it. Those two files together contain every domain password hash in extractable form. The attack requires Domain Admin or Backup Operator rights to execute, which means detecting it provides confirmation that a highly privileged account has been compromised and is being used for credential extraction. Log360 detects this activity through the WBadmin NTDS Dump rule, which fires on wbadmin.exe invocations that target the Active Directory database.

At a glance

How this attack works

The wbadmin.exe command used to extract the Active Directory database takes the following form:

wbadmin start recovery -version:<version_id>-itemtype:file

-items:c:\windows\ntds\ntds.dit

-recoverytarget:<output_path>

-notrestoreacl

The critical argument is the -items flag pointing to the ntds.dit file path, combined with -recoverytarget specifying a writable output directory. The -notrestoreacl flag is typically included to prevent the backup tool from applying the original file's access control list to the output, making the extracted file readable without requiring the same permissions that protect the original. The -version argument identifies which backup version to recover from, which the attacker first enumerates using wbadmin get versions.

What makes this technique particularly effective is that wbadmin.exe is a legitimate Windows Server utility included in the operating system. It produces a file that is indistinguishable from a routine system state backup output by its format and metadata. The backup operation itself uses VSS to access locked files, meaning the attacker does not need to interact with the VSS subsystem directly or stop any services. The entire operation can complete in a few minutes and requires only the permissions already available to an account with Backup Operator or Domain Admin rights.

After obtaining the NTDS.dit file and the SYSTEM hive from the backup output, the attacker can transfer these files off the domain controller and process them offline using publicly available tools to extract all domain password hashes. No further domain controller access is required once the backup set has been transferred.

Why this technique is used alongside other NTDS extraction methods
Attackers who have domain controller access frequently attempt multiple credential extraction techniques in the same session, using whichever succeeds first. The wbadmin method is favoured when ntdsutil IFM creation or direct VSS copy attempts fail due to policy restrictions or EDR blocking, because wbadmin.exe is a backup utility rather than a directory services administration tool and may be subject to less restrictive execution policies on some domain controllers. Detecting it independently from other NTDS extraction rules ensures that coverage does not depend on a single technique being attempted.

Attack chain

The table below maps each stage of an Active Directory backup extraction attack to the corresponding MITRE ATT&CK technique.

Real-world scenario

An insurance company runs a single Active Directory domain with 800 user accounts managed from two domain controllers. A threat actor who gained access via a spear-phishing email targeting a senior IT engineer has spent four days escalating privileges and mapping the environment. Having obtained Domain Admin credentials from a cached credential on a compromised server, the attacker connects to the primary domain controller via RDP using the Domain Admin account.

The attacker first runs wbadmin get versions to confirm that a Windows Server Backup history exists on the domain controller, which it does from the organisation's nightly backup job. Using the version identifier from that output, the attacker runs wbadmin start recovery with -items pointing to ntds.dit and -recoverytarget pointing to a newly created directory under C:\Windows\Temp\svc. The operation completes in four minutes. The output directory contains ntds.dit and the SYSTEM registry hive.

The attacker compresses the output directory and transfers it to a compromised workstation via the existing RDP session clipboard. From there it is exfiltrated to an external host over HTTPS. The temporary directory is then deleted from the domain controller. Log360 fires the WBadmin NTDS Dump alert 30 seconds after the wbadmin start recovery command executes. The SOC analyst who receives the alert recognises the NTDS path in the command-line arguments and initiates immediate host isolation and KRBTGT rotation. The extracted file has already been transferred by the time containment is complete, but the KRBTGT rotation invalidates any tickets derived from it.

Why this happens
wbadmin.exe is included in Windows Server as a built-in backup utility. In environments where Windows Server Backup is in use, wbadmin.exe executions are routine and expected. Security teams that have not configured specific detection for wbadmin invocations targeting ntds.dit may miss this technique entirely, particularly if process creation monitoring is enabled but command-line logging is disabled or if the alert is buried in a high volume of legitimate backup-related events. The presence of a prior backup history on the domain controller is what makes the version enumeration step work, meaning the technique is specifically more viable in environments that have been diligently backing up their domain controllers.

Business impact: What can go wrong

Successful extraction of the Active Directory database via wbadmin.exe carries the same consequences as any confirmed NTDS.dit compromise:

• Total domain credential exposure: NTDS.dit combined with the SYSTEM hive yields password hashes for every account in the domain. These hashes can be cracked offline or used directly in Pass-the-Hash attacks against every domain-joined system.
• Golden Ticket capability: the KRBTGT account hash extracted from NTDS.dit allows the attacker to forge Kerberos tickets for any account with any group membership and any validity period. A Golden Ticket forged from an extracted KRBTGT hash survives password resets on all accounts except KRBTGT itself and provides indefinite domain access.
• Credential reuse across services: domain account hashes extracted from NTDS.dit may be reused against cloud services synchronised via Azure AD Connect, VPN solutions using domain authentication, and any external service where domain credentials are accepted. The compromise extends beyond the on-premises domain boundary.
• Delayed discovery: the wbadmin extraction technique produces a backup file that is transferred off the domain controller and processed entirely offline. The attacker needs no further domain controller access after the file transfer completes. If the extraction is not detected in near-real-time, the attacker may already have extracted all credentials before any containment action is taken.
• Recovery cost: confirmed NTDS.dit extraction requires mandatory KRBTGT password rotation performed twice with a minimum 10-hour interval, forced password resets for all privileged accounts, and a full audit of all service accounts. The operational disruption of these mandatory steps is significant.
• Regulatory exposure: extraction of a credential database containing personal data associated with staff or customer accounts may trigger breach notification obligations under GDPR, HIPAA, or PCI DSS depending on the nature of the data accessible via the compromised credentials.

Indicators of compromise and detection signals

Prerequisites for detection using Log360

Before the WBadmin NTDS Dump rule can fire reliably, ensure the following are in place:

• Windows Process Creation auditing with command-line logging is enabled on all domain controllers, generating Event ID 4688 with the full ProcessCommandLine field populated. This is the primary telemetry source for the rule. Without command-line logging, process creation events for wbadmin.exe will not include the -items and -recoverytarget arguments needed to confirm the NTDS extraction intent.
• Sysmon is deployed on all domain controllers with a configuration capturing Event ID 1 (Process Create) and Event ID 11 (File Create). Sysmon provides enriched process context including parent process details and captures the file creation event when ntds.dit is written to the recovery target path, providing a secondary confirmation signal independent of the process creation event.
• Object Access auditing is enabled for the NTDS directory on domain controllers, generating Event ID 4663 when ntds.dit is accessed. This provides an independent audit record of the file access that is generated by the Windows kernel rather than by process monitoring, making it harder for an attacker to suppress.
• Domain controller logs are forwarded to Log360 in near-real-time via the Log360 agent or Windows Event Forwarding. The wbadmin NTDS extraction can complete in under five minutes. Prompt log forwarding is essential for the alert to reach the SOC while the attacker may still be on the domain controller and before the extracted files are transferred off the host.

Note
The WBadmin NTDS Dump rule fires on domain controller telemetry. If domain controllers are not covered by the Log360 agent or Windows Event Forwarding, the rule will not generate alerts. Additionally, if command-line logging is disabled on domain controllers, wbadmin.exe process creation events will appear in the log but without the arguments that identify the ntds.dit extraction intent. Verify both domain controller agent coverage and command-line logging are active before enabling this rule.

Detecting Active Directory backup extraction using Log360

Once log collection is configured, follow these steps to enable and tune detection in Log360:

Step 1: Enable the detection rule

Navigate to Security > Manage Rules > Rule Library in the Log360 console. Install and enable the rule: WBadmin NTDS Dump. Configure an alert profile for the same. Set the severity to Critical and configure immediate SOC queue notification. Any invocation of wbadmin.exe targeting ntds.dit on a domain controller outside a documented backup maintenance window should be treated as a potential credential extraction attempt until confirmed otherwise.

Step 2: Tune the rule for your environment

After enabling the rule, review the following:

• Document all legitimate wbadmin.exe executions in your environment. If Windows Server Backup runs scheduled jobs on domain controllers, identify the account used, the schedule, and the target paths. Legitimate backup jobs will not target ntds.dit directly via start recovery. They will use start backup with a system state or critical volumes argument. Any wbadmin invocation with start recovery and an ntds.dit item path falls outside the scope of routine backup jobs.
• Review who holds Backup Operator rights in your environment. The Backup Operator group grants the rights needed to run this extraction technique without Domain Admin credentials. Audit Backup Operator membership and verify that only documented, named accounts are members. Unexpected Backup Operator membership is a pre-condition that significantly lowers the privilege requirement for this attack.

Step 3: Read the alert

When the rule fires, the alert will display the domain controller hostname, the account that executed wbadmin.exe, the full command line including the -items path and -recoverytarget directory, and the timestamp. Review the -recoverytarget path first: a path in a Temp directory, a user profile folder, or any path that is not a documented backup destination confirms malicious intent. Then review the account: any execution by an account outside a documented backup service account during a documented backup window warrants immediate escalation.

Investigating an alert

When the WBadmin NTDS Dump rule fires, an L2 analyst should work through the following steps:

• Confirm the command-line arguments. Open the alert detail and verify the full wbadmin command line. Confirm that -items references the ntds.dit path and that -recoverytarget specifies an output location. If both arguments are present, treat this as a confirmed NTDS extraction attempt regardless of the account involved. The combination of wbadmin start recovery and the ntds.dit item path has no legitimate use outside a documented domain controller recovery procedure.
• Check whether the extraction completed. Query Log360 for Sysmon Event ID 11 (File Create) on the same domain controller in the minutes following the wbadmin execution. Look for ntds.dit and a file matching the SYSTEM registry hive appearing in the -recoverytarget directory. If both files are present, the extraction completed successfully and the NTDS credential database is now in an accessible, portable form on the domain controller's file system.
• Check for outbound data transfer. Query Log360 for network connections from the domain controller in the 30 minutes following the extraction command. Look for large outbound transfers via SMB to internal hosts, HTTPS connections to external IPs, or RDP clipboard activity. If the extracted files have been transferred off the domain controller, treat the extraction as confirmed exfiltrated and initiate mandatory KRBTGT rotation immediately.
• Check for the preceding wbadmin get versions command. Query Log360 for Event ID 4688 or Sysmon Event ID 1 records showing wbadmin.exe get versions on the same domain controller in the 15 minutes before the extraction alert. The presence of a version enumeration step immediately before the recovery command confirms deliberate, prepared execution rather than accidental or scripted invocation.
• Identify the account and session context. Determine which account ran wbadmin.exe, the logon type of the session (interactive versus network versus remote desktop), and the source IP address if the session was remote. A remote desktop session from an unrecognised IP executing wbadmin NTDS extraction is the highest-confidence indicator of an active intrusion. Disable the executing account immediately if the session is not attributable to a documented administrative task.
• Verify against documented backup activity. Check the change management system and the Windows Server Backup schedule on the affected domain controller for any authorised system state recovery or DR testing activity that would explain the wbadmin invocation. If no such activity is documented, treat the event as confirmed malicious and initiate incident response.

Escalation trigger
Escalate immediately to L3 and initiate mandatory KRBTGT password rotation if the extraction completed and ntds.dit is confirmed present in the recovery target directory; if network connections from the domain controller suggest the extracted files have already been transferred off the host; if the executing account is not a documented backup service account; or if the wbadmin execution occurred via a remote session from an unrecognised source IP. Confirmed NTDS.dit extraction requires KRBTGT rotation performed twice with a 10-hour interval, forced password resets for all privileged accounts, and a full service account audit.

Responding and remediating

Immediate containment

• Isolate the affected domain controller from the network immediately if an active attacker session is in progress. Use EDR host isolation rather than shutting down the DC to preserve volatile memory evidence and prevent replication events that could mask attacker activity on other domain controllers.
• Delete the extracted files from the recovery target directory immediately. Remove the ntds.dit copy and the SYSTEM hive from the output path. Preserving a hash of each file before deletion provides the forensic record without leaving an accessible credential database on the domain controller's file system.
• Initiate mandatory KRBTGT password rotation if the extraction is confirmed or if network transfer evidence suggests the files have left the domain controller. The rotation must be performed twice with a minimum 10-hour interval between the first and second reset to invalidate all outstanding Kerberos tickets across the domain.
• Disable the executing account immediately if it is not a documented backup service account. Force a password reset and audit all systems the account has authenticated to in the preceding 72 hours.

Forensic preservation

• Export the Windows Security event log and Sysmon operational log from the affected domain controller covering the full period from the first unusual event to the time of containment. These logs contain the wbadmin command line, the file creation events in the recovery target directory, and all network connection and authentication events during the session.
• Hash the extracted ntds.dit and SYSTEM hive files before deleting them from the recovery target directory. Document the file hashes, creation timestamps, and the recovery target path in the incident record.
• Preserve the Windows Server Backup catalog on the domain controller. The backup catalog records the version identifiers that were enumerated during the attack and may provide additional context about which backup version was targeted.

Eradication and recovery

• Rotate the KRBTGT password twice with a 10-hour interval. This is mandatory for any confirmed or suspected NTDS.dit extraction regardless of whether the file has been confirmed as exfiltrated. The KRBTGT hash is always present in a successful NTDS.dit extraction and its rotation is the only mechanism for invalidating any Golden Tickets that may have been forged from it.
• Reset passwords for all privileged accounts: Domain Admins, Enterprise Admins, Schema Admins, Backup Operators, and all service accounts with domain rights. Treat all credentials accessible on the compromised domain controller as exposed.
• Audit Backup Operator group membership across the domain. The Backup Operator right is sufficient to execute this technique. Verify that only named, documented accounts are members and remove any unexpected entries.
• Review and rotate credentials for all accounts synchronised to Azure AD or external identity providers. NTDS.dit extraction yields hashes for synchronised accounts that may be usable against cloud-connected services.

False positive guidance

The WBadmin NTDS Dump rule has a very narrow false positive surface. wbadmin start recovery targeting ntds.dit has no routine administrative use case outside of a deliberate credential extraction attempt or a genuine Active Directory recovery procedure. The following scenarios may produce false positive alerts:

• Active Directory disaster recovery testing: organisations that test their domain controller recovery procedures may run wbadmin start recovery targeting NTDS files as part of a DR rehearsal. This will generate an alert identical to an attacker-initiated extraction. Verify the activity aligns with a documented DR test schedule, the executing account is the documented DR test account, and the recovery target is a documented test environment path. Notify the SOC in advance before running DR tests that will trigger this rule.
• Domain controller recovery from actual failure: in a genuine domain controller recovery scenario following hardware failure or data corruption, an administrator may use wbadmin start recovery to restore NTDS files from backup. This is the intended use of the feature and will trigger the rule. The account will be a named Domain Admin or the backup service account, the session will be from a documented administrator workstation, and there will be a corresponding support ticket or change record. Verify these conditions and document the event as a legitimate recovery operation.
• Automated backup verification scripts: some backup verification workflows programmatically invoke wbadmin to confirm backup integrity by performing test recoveries to isolated paths. If your environment uses such scripts, identify the service account, the target path, and the schedule, and create a scoped exclusion covering that exact process, account, and output path combination.

Key differentiator
Legitimate wbadmin start recovery operations targeting ntds.dit are rare, documented, and performed by named administrators during planned maintenance or recovery windows. The executing account will be a known Domain Admin or documented backup service account, the recovery target will be a documented restoration path, and the activity will align with a change ticket or a DR test schedule. An attacker-initiated extraction will use a temporary or unusual output path, will occur outside any documented maintenance window, and in most cases will be preceded by wbadmin get versions enumeration in the same session. Any wbadmin NTDS recovery that cannot be immediately attributed to a documented procedure should be treated as malicious.

Hardening and prevention

The following controls reduce the risk of Active Directory backup extraction via wbadmin.exe in your environment:

• Restrict Backup Operator group membership to the minimum number of named, documented accounts required for backup operations. Backup Operator rights are sufficient to run this extraction technique without Domain Admin credentials. Regular quarterly audits of this group should be a standing security hygiene control.
• Restrict execution of wbadmin.exe on domain controllers via AppLocker or WDAC policies to the documented backup service account and the documented Domain Admin accounts responsible for DR procedures. Any execution by an account outside this allow list should be blocked at the execution layer before it reaches log-based detection.
• Implement tiered access controls that prevent domain controllers from being accessible via RDP from general-purpose workstations. Requiring jump server access for all domain controller administration limits the paths available to an attacker for running extraction tools interactively.
• Enable Windows Defender Credential Guard on all domain controllers to protect LSASS-stored credential material. While Credential Guard does not prevent wbadmin-based NTDS extraction, it reduces the credential material accessible via complementary techniques such as LSASS MiniDump, limiting the attacker's options if the wbadmin attempt is blocked.
• Rotate the KRBTGT password on a scheduled basis, at minimum twice per year in addition to any emergency rotation following a security incident. Regular KRBTGT rotation limits the validity window of any Golden Tickets that may have been silently forged from a prior extraction that was not detected in real-time.
• Monitor Windows Server Backup catalog changes on domain controllers. Unexpected additions to the backup catalog, or backup versions created at times that do not align with the documented backup schedule, may indicate that an attacker ran a backup operation to generate a version identifier for subsequent recovery-based extraction.