ADVERSARIAL TECHNIQUE ANALYSIS: File Recovery from Backup via WBAdmin.exe

This research provides a comprehensive technical analysis of a post-exploitation technique that abuses Windows’ native backup and recovery infrastructure to obtain sensitive system files that are normally protected on a live operating system. By leveraging wbadmin.exe — a Microsoft-signed, built-in administrative utility — an attacker with sufficient privileges can silently recover historical copies of credential stores and configuration files, bypassing modern endpoint defences entirely.

The technique is particularly dangerous because it requires no custom tooling, leaves a minimal forensic footprint compared to direct memory-access methods, and exploits data that administrators often overlook in their security posture. Historical backups may contain credentials that predate password-rotation policies, making them a goldmine for lateral movement and privilege escalation.

1. Background: Windows Server Backup and WBAdmin.exe

Windows Server Backup (WSB) is a built-in feature available on Windows Server editions and, in limited form, on Windows 10/11. It enables administrators to create full system backups, volume-level snapshots, and individual file backups to local disks, network shares, or removable media. The command-line interface for this service is wbadmin.exe, which ships as part of the operating system and carries a valid Microsoft digital signature.

Because wbadmin.exe is a legitimate administrative binary, it appears in most organisations’ software allowlists and rarely triggers alerts on its own. This makes it an ideal living-off-the-land binary (LoLBin) for adversaries operating in environments with mature endpoint detection capabilities.

Key wbadmin.exe Capabilities Relevant to Attackers

• Enumerate all backup versions stored on the system or connected storage.
• Recover individual files or folders from a selected backup version.
• Restore entire volumes without requiring a reboot into the Windows Recovery Environment.
• Operate entirely via the command line with no GUI interaction required.
• Accept UNC paths for remote backup-source targeting.

Relevant Windows Event IDs

Event ID	Description
4688	Process creation — wbadmin.exe execution will be logged here
4663	File object access — may appear when backup files are accessed
4656	Handle request on object — relevant when protected files are opened
7045 / 7040	Service installation or change — triggered by WSB service activity
Microsoft-Windows-Backup	Dedicated ETW channel for all WSB operations

2. How the Attack Works

The attack unfolds in a sequence of deliberate steps, each designed to minimise noise and maximise the value of recovered data. The attacker exploits the gap between what the operating system protects at runtime and what it stores on disk in backup archives.

Step 1 — Gaining Sufficient Privileges

Execution of wbadmin.exe in recovery mode requires administrative or SYSTEM-level privileges. The attacker must first achieve these permissions through an initial access vector (phishing, exploitation) and a privilege escalation chain. On domain controllers, a domain administrator account is sufficient. On member servers, a local administrator account may be enough to access locally stored backups.

Step 2 — Enumerating Available Backups

With the necessary privileges, the attacker runs wbadmin.exe to list all backup versions available on the system or connected storage. The output includes version identifiers (timestamps), the backup target location, and which volumes or components were included.

wbadmin get versions
wbadmin get versions -backupTarget:\\BackupServer\ShareName

Sample output reveals backup version identifiers in the format MM/DD/YYYY-HH:MM (e.g., 01/15/2024-02:30). The attacker selects a specific version which is typically the oldest available or one predating a known password-rotation event to maximise the chance of recovering still-valid credentials.

Step 3 — Recovering Target Files

Rather than restoring an entire volume (which would be noisy and disruptive), the attacker uses file-level recovery to extract only the specific sensitive files needed. This is done with get items to verify availability within a backup, followed by start recovery to extract them.

wbadmin get items -version:01/15/2024-02:30

wbadmin start recovery -version:01/15/2024-02:30 \
  -itemtype:file -items:C:\Windows\NTDS\ntds.dit \
  -recoverytarget:C:\Temp\Recovery -notRestoreAcl

wbadmin start recovery -version:01/15/2024-02:30 \
  -itemtype:file -items:C:\Windows\System32\config\SAM \
  -recoverytarget:C:\Temp\Recovery -notRestoreAcl

wbadmin start recovery -version:01/15/2024-02:30 \
  -itemtype:file -items:C:\Windows\System32\config\SYSTEM \
  -recoverytarget:C:\Temp\Recovery -notRestoreAcl

The -notRestoreAcl flag is significant: it instructs wbadmin.exe to restore the files without applying the original access control lists. The recovered files land in the target directory as fully accessible copies, stripped of the runtime protections that prevent direct access on the live system.

Step 4 — Offline Extraction and Analysis

Once the files are recovered to a writable directory, the attacker exfiltrates them or processes them locally. Because these are offline copies, none of the runtime protections apply — LSASS does not mediate access, VSS protections are irrelevant, and there is no Credential Guard to bypass.

Tools such as Impacket’s secretsdump, DSInternals, or NTDSutil can then be used to extract password hashes, Kerberos keys, and plaintext credentials from the recovered files.

# Impacket
impacket-secretsdump -ntds ntds.dit -system SYSTEM LOCAL

# PowerShell / DSInternals
Import-Module DSInternals
$key = Get-BootKey -SystemHivePath '.\SYSTEM'
Get-ADDBAccount -All -DBPath '.\ntds.dit' -BootKey $key

3. High-Value Target Files

The following files represent the most sensitive targets recoverable through this technique. Each provides a different class of credential or secret material that can be leveraged for further access.

File / Path	Contents	Attack Impact
NTDS.dit C:\Windows\NTDS\	All AD accounts, password hashes, Kerberos keys, group memberships	Full domain compromise — pass-the-hash, Kerberoasting, Golden Ticket
SAM System32\config\SAM	Local account NTLM hashes for all local users	Local privilege escalation, lateral movement to hosts with shared passwords
SYSTEM System32\config\SYSTEM	Boot key (SYSKEY) — required to decrypt SAM and NTDS.dit	Must be collected alongside SAM or NTDS.dit for offline decryption
SECURITY System32\config\SECURITY	LSA secrets: service account passwords, cached domain credentials, DPAPI master keys	Reveals service account creds and cached credentials for disconnected login
NTDS.jfm / edb.chk	Transaction logs for NTDS.dit — may contain recent uncommitted changes	Can fill in data missing from a partial NTDS.dit snapshot
Web.config / appsettings.json	Application connection strings, API keys, embedded credentials	Access to databases, third-party services, cloud providers
unattend.xml / sysprep.xml	Plaintext admin credentials from automated deployment	Immediate administrative access if credentials are still active

4. Why This Technique Bypasses Modern Defences

Modern endpoint protection platforms and SIEMs are tuned primarily for runtime attack patterns. This technique sidesteps most of those detection investments by operating on historical, offline data using a signed, native binary.

Defence Mechanism	Why It Is Bypassed
LSASS memory protection (PPL)	No LSASS access required — credentials extracted from offline database files
Windows Credential Guard	Credential Guard protects runtime secrets in VSM; offline NTDS.dit bypass is unaffected
Antivirus / EDR process injection detection	No injection occurs; only a native, signed Microsoft binary is executed
NTDS.dit VSS direct access monitoring	Access is through the backup service API, not direct file-system reads of the live file
Application whitelisting (AppLocker / WDAC)	wbadmin.exe is Microsoft-signed and passes most allowlist policies
Behavioural detection of credential dumping tools	Mimikatz, ProcDump, and similar tools are not used at any stage
File integrity monitoring on live NTDS.dit	The live file is never touched; only a historical backup copy is accessed

5. Practical Attack Scenarios

Scenario A: Domain Controller Compromise

An attacker who has compromised a domain administrator account on a domain controller uses wbadmin.exe to restore NTDS.dit from a backup taken six months prior. The password for the built-in Administrator account has not changed since then. The attacker extracts the NTLM hash and uses pass-the-hash to authenticate to systems throughout the domain, including those to which the current (post-rotation) password no longer grants access.

Scenario B: Service Account Credential Recovery

A backup from three months ago contains the SECURITY hive with LSA secrets. The secrets include the password for a service account used by a legacy application. The service account password was rotated after the backup was taken, but the account still exists. The attacker reuses the recovered password against other services and discovers it was reused on the organisation’s VPN gateway, gaining external access.

Scenario C: Targeting a Remote Backup Share

A backup administrator has stored Windows Server Backups on a network-attached storage (NAS) device. The attacker, who has compromised a workstation with Backup Operator rights, runs wbadmin.exe against the UNC path of the NAS share. They enumerate and recover NTDS.dit from the network backup without ever touching the domain controller directly, significantly reducing the forensic footprint on the DC itself.

wbadmin start recovery -version:03/01/2024-22:00 \
  -backupTarget:\\nas01\Backups \
  -itemtype:file -items:C:\Windows\NTDS\ntds.dit \
  -recoverytarget:C:\Temp\r1 -notRestoreAcl -quiet

Scenario D: Backup Operator Privilege Abuse

Members of the Backup Operators built-in group hold SeBackupPrivilege and SeRestorePrivilege — rights specifically designed to allow bypassing file ACLs for backup purposes. These privileges are frequently granted to service accounts and junior IT staff without a full understanding of their implications. An attacker who compromises any such account can directly leverage these privileges for file recovery without needing to escalate to full Domain Admin.

6. Detection Guidance

While this technique is designed to blend in with administrative activity, it is not invisible. Defenders who tune their monitoring for backup operations can identify anomalous usage patterns that distinguish legitimate backup tasks from adversarial recovery attempts.

Process and Command-Line Monitoring

• Alert on wbadmin.exe executions with start recovery in the command line.
• Flag wbadmin.exe processes spawned by interactive user sessions or unusual parent processes (e.g., cmd.exe spawned from a web server process).
• Monitor for use of the -notRestoreAcl flag, which has no legitimate purpose in standard operations.
• Correlate wbadmin.exe execution against expected maintenance windows and authorised administrator accounts.

File System Monitoring

• Alert on the creation of ntds.dit, SAM, SYSTEM, or SECURITY files outside their canonical paths.
• Monitor temporary directories (C:\Temp, C:\Users\*\AppData\Local\Temp) for the appearance of registry hive files.
• Implement file integrity monitoring for backup catalogue directories.

Windows Event Log Correlation

The Microsoft-Windows-Backup ETW provider logs detailed information about all backup and recovery operations. The following query pattern can be used in Splunk or a SIEM:

source="WinEventLog:Microsoft-Windows-Backup" (EventCode=4 OR EventCode=8 OR EventCode=14)
| where like(Message, "%recovery%") OR like(Message, "%ntds%") OR like(Message, "%sam%")

Supplement with Sysmon Event ID 11 (file creation) filtered for the target file names, and Event ID 1 (process creation) with command-line logging enabled.

Behavioural Baselines

Establish a baseline of legitimate wbadmin.exe usage in your environment. Most organisations run backups on a schedule from dedicated service accounts. Any deviation from this pattern, especially execution from an interactive session, a novel account, or at an unexpected hour, should trigger investigation.

7. Mitigations and Hardening Recommendations

1. Restrict Backup Operator Group Membership. Audit membership in the built-in Backup Operators group regularly. This group’s privileges are equivalent to administrative access for credential recovery purposes. Remove any non-essential accounts.
2. Protect Backup Storage with Separate Credentials. Backup storage targets (NAS, network shares) should require authentication distinct from domain credentials. An attacker with domain admin credentials should not automatically gain access to the backup repository.
3. Implement Backup Encryption. Enable encryption for all Windows Server Backup jobs. Encrypted backups require a valid certificate or password to restore, ensuring that even if backup files are accessed, the contents cannot be read offline.
4. Apply the Principle of Least Privilege to Backup Accounts. Service accounts used for automated backup operations should be restricted to only the backup-related privileges they require. They should not be domain administrators.
5. Monitor and Alert on wbadmin.exe Recovery Operations. Establish SIEM rules specifically for recovery operations. Most organisations should see near-zero legitimate interactive recovery events outside documented DR exercises.
6. Enforce Regular Password Rotation. While this does not prevent recovery of backup contents, it reduces the window during which recovered credentials remain valid. Combine with LAPS or managed service account randomisation.
7. Implement Tiered Administration. Use Microsoft’s Enterprise Access Model to isolate domain controllers, backup servers, and management hosts in separate administrative tiers, limiting the blast radius of a single compromised account.
8. Restrict wbadmin.exe Execution via AppLocker or WDAC. In environments where interactive use of wbadmin.exe is not required, use application control policies to restrict its execution to authorised service accounts or scheduled task identities only.

8. Forensic Artifacts Left Behind

Despite being a relatively quiet technique, wbadmin.exe recovery operations do leave artifacts that incident responders can use during post-incident analysis.

Artifact Location	Artifact Type	What It Reveals
Microsoft-Windows-Backup ETW log	Event log	Full record of all backup and recovery operations with timestamps
C:\Windows\Logs\WindowsServerBackup\	Log files	Detailed backup job logs including source, destination, and file lists
Prefetch (C:\Windows\Prefetch\)	Prefetch file	Evidence of wbadmin.exe execution with timestamps
ShimCache / AppCompatCache	Registry	Execution evidence even if Prefetch is disabled
$MFT and $LogFile	NTFS metadata	File creation timestamps for recovered files in the target directory
Security Event Log (4688)	Event log	Process creation record including command-line arguments if auditing is enabled

Summary

File recovery via wbadmin.exe represents a mature, sophisticated post-exploitation technique that embodies the living-off-the-land philosophy at its most effective. By working entirely within the legitimate administrative framework Windows provides, an attacker can recover the most sensitive credential stores in an environment — NTDS.dit, SAM, SECURITY — without triggering the bulk of detection mechanisms tuned for runtime attack patterns.

The technique’s true danger lies not just in its stealth but in its exploitation of a commonly neglected attack surface: historical backup data. Organisations that diligently rotate credentials, patch systems, and monitor for known attack tools may still be fully exposed through backup repositories that predate their security improvements.

Effective defence requires a combination of restricted access to backup infrastructure, encryption of backup data, behavioural monitoring of wbadmin.exe usage, and a genuine understanding that backup data represents a second copy of the most sensitive information in the environment — and must be protected accordingly.

---

References and Further Reading

• MITRE ATT&CK T1003.003 — OS Credential Dumping: NTDS  |  attack.mitre.org
• Microsoft Docs: wbadmin start recovery  |  learn.microsoft.com
• Impacket secretsdump.py  |  github.com/fortra/impacket
• DSInternals PowerShell module  |  github.com/MichaelGrafnetter/DSInternals
• SpecterOps: “Certified Pre-Owned” — related backup operator abuse research
• CIS Benchmark for Windows Server — Backup Operators hardening guidance
• Microsoft Enterprise Access Model  |  learn.microsoft.com/security