How should security teams detect ransomware activity from file creation and shadow copy deletion on Windows endpoints?

Why File Creation and Shadow Copy Deletion Matter on Windows

Ransomware detections that focus only on encryption leave teams late in the kill chain. On Windows endpoints, the early and mid-stage signals are often simpler: new ransom-note artefacts, unusual payload files written to temp locations, and commands that remove volume shadow copies to weaken recovery options. The value of this question is not just identifying malware, but recognising the sequence of destructive activity before business impact becomes irreversible. Guidance from the ENISA Threat Landscape is useful here because it frames ransomware as an operationally disruptive threat pattern rather than a single file event.

Teams often miss the connection between file-creation anomalies and recovery sabotage until restore points are already gone and incident response has fewer containment options.

How to Correlate Endpoint Telemetry into a Reliable Detection

Effective detection depends on correlation, not any single indicator. A lone file write may be benign, and shadow copy activity can occasionally occur during legitimate administration, but the combination of unusual file creation, executable activity from suspicious paths, and shadow copy deletion is materially more suspicious. Endpoint telemetry should capture process creation, command-line arguments, file system writes, and parent-child process relationships so that a detection rule can score the sequence instead of each event in isolation.

Practical detections usually start with three analytic layers. First, watch for creation of ransom-note style filenames and extension changes in user and temp directories. Second, inspect for uncommon payload placement, especially image or icon-like files in temporary paths where staging often occurs. Third, flag use of vssadmin.exe and similar native tools when they are invoked to delete shadow copies, because native binaries are commonly abused to blend destructive action into normal administration. Where available, correlating these signals with rapid burst file writes and broad directory touch patterns improves precision. A detection that fires only after encryption has finished is weaker than one that fires when the operator begins staging and disabling recovery.

• Use file integrity monitoring to surface unexpected creation of ransom notes and payload artefacts.
• Pair those events with endpoint process telemetry so command-line abuse is visible.
• Correlate shadow copy deletion with abnormal write bursts and suspicious parent processes.
• Tune for local administrator paths, scripts, and remote execution tools that commonly precede destructive activity.

This approach breaks down when telemetry is partial, file-system monitoring is too coarse, or legitimate backup and administrative workflows are not baselined well enough to separate normal recovery maintenance from abuse.

When the Pattern Is Normal Maintenance, Not Ransomware

Tighter detections often increase operational noise, requiring organisations to balance sensitivity against the risk of false positives. That tradeoff matters because some legitimate tasks can also create files, manipulate temporary directories, or manage shadow copies during backup operations. The question is not whether a single action is suspicious in isolation, but whether the surrounding context makes the sequence consistent with destructive intent.

Consensus is clearer on the shadow copy side than on every file-creation artefact. Native deletion of shadow copies is a strong signal when it appears alongside user-facing ransom artefacts, recent privilege escalation, or mass file activity, but it is less conclusive if backup tooling or endpoint management software is known to trigger it under controlled conditions. Teams should therefore treat context as part of the detection logic, not as an after-the-fact excuse. The most common edge case is an overbroad rule that alerts on any vssadmin.exe use, which quickly becomes noisy unless it is scoped to suspicious parent processes, unusual accounts, or a concurrent burst of destructive file writes.

In practice, defenders get the best results when they distinguish administrative maintenance from coordinated sabotage, rather than treating every shadow copy event as an incident.

Practitioner Guidance

What to prioritise: Build detections around the sequence, not the single event. A suspicious file write becomes much more actionable when it appears near shadow copy deletion, unusual command-line execution, or a burst of modifications across many directories.

What to verify: Confirm that endpoint telemetry includes process ancestry, command-line capture, and enough file-system visibility to separate ordinary temp-file creation from staged payload drops. If those data points are missing, detection quality will degrade quickly.

Common mistake: Teams often tune only for encryption or only for vssadmin.exe, which creates blind spots and noise at the same time. The stronger pattern is the combination of file creation, recovery sabotage, and speed of execution.

Practitioner takeaway: Treat this as a chained behavioural detection problem, because ransomware usually reveals itself through correlated destructive actions before it finishes the encryption phase.

Related resources from NHI Mgmt Group

• How should security teams detect BlackCat ransomware on Windows endpoints before encryption spreads?
• How should security teams detect LodaRAT activity on Windows endpoints before the malware fully settles in?
• How should security teams combine file integrity monitoring and active response to contain ransomware on endpoints?
• How should security teams detect and contain destructive wiper malware on Windows endpoints before it renders systems unusable?