---
{
  "title": "Inhibit System Recovery",
  "summary": "Inhibiting system recovery removes or disables features needed to restore an affected system.",
  "topic": "grc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    3
  ],
  "aliases": [
    "T1490"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1490: Inhibit System Recovery",
      "url": "https://attack.mitre.org/techniques/T1490"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Inhibiting system recovery removes or disables features needed to restore an affected system. It can make a later destructive event harder to recover from.


## An investigation example

A privileged process alters recovery settings and removes accessible restore copies before encryption begins.

## Evidence to examine

Review backup and recovery configuration changes, identity privileges, deletion records, and independent copy availability.

## A common analytical pitfall

A visible backup job succeeding does not prove its data remains isolated, intact, or restorable.

## Response considerations

Protect independent recovery copies, stop confirmed destructive changes, and verify restoration capability through controlled testing.


## An attacker can target the way back

Recovery depends on more than the primary data. Backup copies, snapshots, recovery configuration, catalogs, credentials, and administrative tools may all be necessary. Interfering with these resources can extend disruption or make a later destructive action harder to reverse. Protect recovery capability as a separate security boundary rather than assume it survives any incident affecting production.

Legitimate maintenance can also remove snapshots or change backup settings. Investigators should examine authorization, timing, responsible identities, and the relationship to other suspicious events. A deletion event alone does not establish malicious intent, but an unexplained sequence affecting multiple recovery mechanisms deserves prompt attention.

## A fictional missing restore point

An academy experiences file corruption and discovers that recent restore points were removed shortly beforehand. The team preserves backup administration logs and reviews which identity performed the changes. It checks whether protected copies exist outside the affected administrative boundary and whether the incident also changed retention or scheduled jobs.

The response must address the access path that allowed recovery changes, not only re-enable the jobs. Restoring from a trustworthy copy may require an isolated environment and validation of the application state. Confirm which recovery points are usable through an authorized test rather than treating a catalog entry as proof that the data can be restored.

## Examine a recovery boundary

Draw a fictional production account, backup administration account, and protected copy. Ask whether one compromised identity could modify all three. Identify one separation that would reduce that concentration of authority and one monitoring event that would reveal an unexpected recovery change. Keep the exercise architectural; there is no need to delete snapshots or disable actual backups to understand the risk.

Consider where backup administration logs are retained. If the same identity can remove recovery copies and erase the only record of doing so, investigation becomes harder. An independently protected audit trail can preserve context even when the recovery platform itself is affected.

## Related concepts

- [[business-continuity]]
- [[disaster-recovery]]
- [[incident-response]]
- [[data-destruction]]
- [[data-encrypted-for-impact]]
- [[windows-management-instrumentation]]
- [[disk-wipe]]