Detect this behaviour by monitoring for backup-service tampering, shadow copy deletion attempts, and unexpected use of native administration tools that remove recovery points. Watch for sudden failures in backup jobs, loss of restore points, and commands run by unusual users or processes. Treat backup destruction as an early sign of destructive ransomware.
How to tell backup destruction from ordinary backup failures
Backup destruction is usually not subtle when you know what to look for. The key distinction is intent: ordinary failures tend to break one path, while destructive activity often targets the recovery layer itself, including Windows backups, shadow copies, and related management services. That means you should correlate backup job failures with administrative activity on the same host, not treat them as isolated noise.
One useful anchor point is whether the backup system still behaves normally but the recovery points disappear. Sudden loss of restore points, especially after suspicious command execution, is more indicative of ransomware than routine misconfiguration. A good baseline comes from a Ransomware Prevention Guide because it covers the same backup and shadow copy protections that attackers commonly try to defeat.
Also look for abnormal use of native Windows tooling that can delete recovery data. When commands associated with shadow copy removal, backup catalogue tampering, or service stoppage appear from unusual users, parent processes, or remote management sessions, that is a strong behavioural signal. In practice, this is less about the exact command string and more about the context in which a trusted admin function is being abused.
What logs and telemetry are most useful
The most valuable telemetry is the one that links process execution to backup impact. Windows security logs, process creation events, backup product logs, and PowerShell or command-line telemetry can show whether the deletion attempt came from a script, an interactive session, or a management tool. If backup software logs show failed jobs at the same time that shadow copies vanish, the combined signal is much stronger than any single alert.
For host-level investigation, map the activity to the artefacts left behind by execution and administrative abuse. The Windows Forensic Artefacts Guide is useful because it helps you connect command execution, registry traces, and event log evidence into a coherent timeline. That matters when ransomware tries to hide behind built-in tools rather than dropping obviously malicious binaries.
Backup platform telemetry matters too. Watch for tampering with backup schedules, backup repositories, retention settings, or service accounts. If an attacker has obtained legitimate credentials, the activity can look operational unless you compare it with the expected operator, host, time window, and change request.
Why shadow copy deletion is an early ransomware warning
Deleting Windows backups and Volume Shadow Copies is usually a preparation step for impact, not the impact itself. Attackers remove recovery options so that encryption, extortion, or destructive payloads become harder to roll back. That is why backup destruction should be treated as an escalation point even before files are encrypted.
Credential abuse often sits behind this behaviour. When ransomware operators gain access to backup administration accounts or high-privilege Windows credentials, they can remove recovery material quickly and quietly. The Credential Dumping Guide is relevant because it shows how stolen credentials and privileged sessions can lead directly to destructive administrative action.
Protecting the backup plane also means protecting the people and service accounts that can touch it. If those credentials are reused, long-lived, or broadly delegated, recovery can be destroyed from inside the same trust boundary that is meant to preserve it.
Risk and Threat Considerations
Backup destruction creates a dual risk: it removes recovery options and signals that the attacker has likely reached a stage where impact is imminent. In a ransomware event, shadow copy deletion is often paired with credential theft, privilege escalation, and tampering with backup administration.
Failure mechanism: The attacker uses legitimate admin tooling, stolen credentials, or backup-management privileges to delete restore points, disable backup jobs, or corrupt retention settings before encryption or extortion begins.
Impact: Restoration becomes slower, more expensive, and sometimes impossible from local sources, which can turn a contained incident into a full outage or prolonged business interruption.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Backup deletion often follows misuse of privileged admin accounts. |
| Recommendation — Restrict and review backup-administration accounts with least privilege and separate duties. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Detects suspicious backup and shadow copy deletion activity in logs. |
| IA-5 — Authenticator Management | Stolen or weak credentials can enable backup destruction. | |
| CM-6 — Configuration Settings | Shadow copy and backup protections depend on hardened recovery settings. | |
| Recommendation — Correlate process, backup, and security logs to flag recovery-point tampering. Rotate and protect credentials for backup and recovery administration. Harden backup and shadow-copy configuration to reduce destructive tampering. | ||
| MITRE ATT&CK | T1490 — Inhibit System Recovery | Shadow copy deletion and backup removal are classic recovery-inhibition actions. |
| Recommendation — Map backup and shadow-copy deletion events to Inhibit System Recovery detections. | ||
Practitioner Guidance
What to verify: Confirm whether the deletion activity came from an approved backup operator, a known automation account, or a host that normally performs recovery administration. If the source is unusual, treat the event as compromise until proven otherwise.
Decision rule: If shadow copies or backup repositories disappear across multiple systems, prioritise containment and credential review before assuming a simple operational error. Cross-host consistency is a strong indicator that the activity is coordinated.
What good looks like: Backup deletion attempts generate high-fidelity alerts, the relevant service accounts are tightly scoped, and restore points are isolated from the same credentials used on production endpoints.
Practitioner takeaway: The most important judgment is to treat loss of recovery data as an attack signal, not a storage or backup support ticket, because the attacker is often trying to remove your last safe rollback path.
Related resources from NHI Mgmt Group
- How do you detect credential theft from Volume Shadow Copies on Windows?
- What happens when ransomware deletes shadow copies and system state backups on a Windows endpoint?
- How do you detect volume shadow copy abuse for credential theft on Windows?
- How should security teams detect ransomware activity from file creation and shadow copy deletion on Windows endpoints?