cybernoz.com

Threat actors are increasingly weaponizing Microsoft’s Volume Shadow Copy Service (VSS) for two distinct objectives: removing recovery options before ransomware deployment and extracting credential material from protected Windows files.

The shift means VSS telemetry should no longer be treated as a simple backup or disk-maintenance event, but as behavior requiring process, identity, and endpoint context.

Backup products use it to capture data while applications such as Active Directory, SQL Server, and Exchange are running.

Yet the same capability gives attackers access to static copies of normally locked files and, conversely, allows them to destroy local recovery points before encryption begins.

The ransomware use case is well established. Operators commonly invoke native utilities including vssadmin.exe , wmic.exe , diskshadow.exe , wbadmin.exe , and bcdedit.exe to remove shadow copies, delete backup catalogs, or disable recovery features.

MITRE ATT&CK tracks this activity as T1490: Inhibit System Recovery, noting that it is frequently used to increase the impact of data-encryption and destructive attacks.

A familiar command such as vssadmin.exe delete shadows /all /quiet is therefore not merely cleanup activity. It can be the final preparatory step before a ransomware payload launches, denying victims an easy rollback path.

MITRE lists numerous ransomware families and groups associated with shadow-copy removal, including Akira, Black Basta, BlackCat, Conti, LockBit, Qilin, RansomHub, REvil, Ryuk, and WannaCry.

However, VSS abuse is not limited to deletion. Attackers can create a snapshot and access copies of sensitive files that would otherwise be locked by the operating system.

On domain controllers, this may include NTDS.dit , the Active Directory database containing password-hash data, alongside associated registry material required to extract secrets.

Copying data from a snapshot can be less conspicuous than attempting credential dumping directly against a live process or protected database.

The risk was illustrated in Huntress’ analysis of public Nightmare-Eclipse tooling.

The researchers reported that the BlueHammer local privilege-escalation technique abused a Windows Defender timing issue and a VSS snapshot to obtain access to the Security Account Manager (SAM) database.

VSS is a Windows framework designed to coordinate application-consistent, point-in-time snapshots.

The tool then parsed the SAM hive and decrypted user NT hashes as part of its elevation chain.

Huntress said the activity demonstrated, how a VSS snapshot can become a bridge between a protected credential store and an attacker-controlled process.

That makes simplistic shadow-copy alerts ineffective. Enterprises routinely create and remove snapshots through backup agents, remote monitoring and management platforms, storage maintenance tasks, and legitimate administrative activity.

An alert reading “shadow copy deleted” lacks enough context to distinguish a scheduled retention policy from an intrusion.

Detection engineering should instead correlate VSS activity with its surrounding sequence.

High-risk indicators include an unusual parent process launching vssadmin , wmic , or diskshadow ; execution from temporary or user-writable directories; use of remote shells; rapid backup-service or recovery-setting changes; credential-access attempts; discovery commands; and encryption-like file activity immediately afterward.

Shadow storage resize operations also warrant scrutiny, since adversaries can use them to force older snapshots out of available space.

Defenders should pay particular attention when VSS creation is followed by access to NTDS.dit , SAM, SYSTEM, or SECURITY hives; archival utilities; suspicious staging directories; or outbound transfer activity.

A shadow copy created by an expected backup service at its normal cadence is operational telemetry.

One created by an interactive user, an unknown binary, or a script immediately preceding registry-hive access is an incident candidate.

The defensive conclusion is straightforward: local snapshots remain useful for operational recovery, but they are not ransomware-resistant backups.

VSS has a 64 TB volume limitation, relies on Copy-on-Write behavior that can add overhead under heavy write loads, and remains a Windows-native mechanism rather than a complete resilience strategy.

Most importantly, local shadow copies are reachable from the systems ransomware operators compromise.

Organizations should maintain protected, off-host, and preferably immutable backups; restrict who can administer backup infrastructure; monitor native recovery utilities; and validate that restoration works under incident conditions.

MITRE additionally recommends keeping backup copies off the affected system, limiting backup access to necessary accounts, and using execution controls where utilities such as diskshadow.exe are not required.

★ Learn 7 Metric-Gated AI SOC Deployment Phases – Download Free AI SOC Deployment Playbook 2026 .