Recovery becomes far harder because local restore mechanisms are removed alongside the encrypted data. Shadow copies can no longer provide quick file rollback, and deleted system state backups eliminate critical recovery material for registry, boot, and system files. In practice, responders are pushed toward slower rebuilds, wider data loss, and a more disruptive restoration effort.
Why This Matters for Security Teams
When ransomware removes shadow copies and system state backup, it is not just encrypting data, it is stripping away the fastest local recovery path on the endpoint. That changes the incident from a file recovery problem into a broader resilience problem, where rebuild time, business interruption, and loss of forensic evidence all become harder to control. This is why backup protection, privilege restriction, and recovery testing belong together rather than as separate disciplines.
Security teams often miss that Windows restore features are only useful if the malware cannot reach and delete them. A practical control set has to assume the endpoint is already partially compromised and focus on preventing tampering with restore points, backup catalogs, and administrative tooling. NIST’s control families around backups, access enforcement, and recovery planning are a useful reference point in this context, especially in NIST SP 800-53 Rev 5 Security and Privacy Controls. In practice, many security teams encounter backup deletion only after the endpoint has already been isolated, not through intentional recovery design.
How It Works in Practice
On Windows, shadow copies are typically created through Volume Shadow Copy Service, while system state backups capture recovery-relevant system components such as the registry, boot configuration, and other critical operating state. Ransomware commonly targets both because deleting them prevents fast rollback and narrows the defender’s options to full rebuilds or remote restoration. In many cases, the malware also disables services, clears logs, and attempts to remove administrative recovery paths so that local remediation becomes slower and less reliable.
The operational impact depends on what was protected before the attack. If the endpoint had only local restore points, deletion may eliminate the only practical recovery source. If backups were copied off-host, immutable, or centrally managed, the endpoint compromise is still serious, but restoration can shift to trusted recovery infrastructure. That difference is why incident response plans should separate endpoint repair from backup trust decisions.
- Restrict local administrative rights so malware cannot easily delete restore artifacts.
- Use centralized or immutable backup storage rather than relying on endpoint-local recovery points.
- Test whether recovery works after endpoint compromise, not just after routine file loss.
- Monitor for commands and behavior associated with backup deletion and service tampering.
Operational guidance from ENISA Threat Landscape is useful here because it reinforces the broader pattern: ransomware is designed to reduce defender options before negotiation or extortion begins. These controls tend to break down in highly privileged, lightly managed Windows environments because local admin access lets malware delete recovery material faster than defenders can isolate the host.
Common Variations and Edge Cases
Tighter backup protection often increases administrative overhead, requiring organisations to balance recovery speed against access restrictions and operational complexity. That tradeoff matters because overly convenient recovery paths are often the same paths ransomware abuses.
There is no universal standard for every Windows environment, but the common edge cases are consistent. On some endpoints, shadow copies may never have been enabled in a meaningful way, so their deletion changes little. On others, system state backups may exist only on the same disk or the same management plane as the compromised host, which means the attacker can erase both production data and recovery data in one pass. In regulated environments, the question is not only whether files can be restored, but whether the restoration path preserves evidentiary integrity and auditability.
This is also where identity and privilege governance intersects with endpoint resilience. If service accounts, local administrator access, or remote management credentials are too broad, ransomware can often perform the same destructive actions as a legitimate operator. The practical answer is to assume local recovery artifacts are disposable unless they are protected by separate trust boundaries, separate credentials, and separate storage. In mixed estates, recovery plans often fail because the organisation treats backup deletion as a rare anomaly rather than a deliberate attacker objective.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RC.RP-1 | Ransomware deletion of backups directly affects recovery planning and restoration execution. |
| MITRE ATT&CK | T1490 | Inhibit System Recovery describes the exact attacker behavior of deleting restore options. |
| NIST SP 800-53 Rev 5 | CP-9 | Contingency backup controls map to preserving recoverable copies outside the endpoint. |
Define recovery roles and restore priorities before an endpoint is compromised.
Related resources from NHI Mgmt Group
- What happens when BlackCat ransomware is executed on a Windows endpoint without recovery controls?
- What breaks when ransomware can delete shadow copies and disable backup services?
- Why do backups fail during ransomware incidents even when they exist?
- What breaks when teams rely on system state restore for identity servers?
