Detecting and Mitigating Inhibit System Recovery (T1490)

Before the damage comes the part that makes it permanent. T1490, Inhibit System Recovery, is when adversaries delete or remove built in data and turn off services that help recover a corrupted system. MITRE files it under impact. It spans containers, ESXi, IaaS, Linux, macOS, network devices and Windows.

How attackers use it

Operating systems have recovery features: backup catalogs, volume shadow copies and automatic repair. Adversaries disable or delete them to amplify data destruction and data encrypted for impact. They may also disable recovery notifications and then corrupt backups.

MITRE lists native Windows utilities that have been used:

• vssadmin.exe to delete volume shadow copies
• WMI to delete volume shadow copies
• wbadmin.exe to delete the Windows Backup Catalog
• bcdedit.exe to turn off automatic Windows recovery by changing boot configuration data
• REAgentC.exe to disable the Windows Recovery Environment
• diskshadow.exe to delete volume shadow copies

Other platforms have equivalents. On network devices, adversaries can wipe backup firmware images and reformat storage, then reboot the device, which may leave it inoperable and hard to recover. On ESXi, attackers delete or encrypt VM snapshots so they cannot serve as backups. Backups reachable from the network, such as network storage or folders synced to cloud services, can be deleted. In the cloud, attackers may disable versioning and backup policies, then delete snapshots, database backups, machine images and prior object versions.

How to detect it

MITRE's detection strategy has one analytic per environment.

• Windows: process chains that run vssadmin, wbadmin, diskshadow, bcdedit, REAgentC or wmic to delete shadow copies, disable recovery or remove backup catalogs.
• Linux: shell commands or scripts that remove recovery files or partitions, such as the rescue target, fstab backups or the EFI boot partition, or that use chattr to block snapshot based recovery.
• ESXi: shell or vim-cmd activity that removes all VM snapshots, or deletes snapshot files directly.
• Network devices: erase, format and reload commands run back to back from a privileged session.
• Cloud: API calls that disable snapshot schedules, backup policies or versioning, followed by deletion of snapshots or volumes.

MITRE does not list event IDs. Collect process creation with full command lines on Windows and alert on these tools, because very few legitimate workflows call them on a workstation. For cloud, alert on a backup policy change followed by deletion by the same principal.

This technique is a strong early warning. It often happens minutes before encryption, so a fast alert can matter more here than almost anywhere else.

Click through it at your own pace, or open it full screen.

How to reduce the risk

MITRE lists four mitigations.

1. Execution prevention. Use application control to block utilities such as diskshadow.exe on systems that do not need them.
2. Operating system configuration. Use technical controls to prevent disabling services or deleting files involved in recovery. Make sure WinRE is enabled with reagentc /enable.
3. User account management. Limit which accounts can reach backups. In AWS, consider service control policies to restrict API calls that delete backups, snapshots and images.
4. Data backup. Keep disaster recovery plans, take regular backups, store them off system and protect them from the methods adversaries use to reach and destroy them. In the cloud, enable versioning on storage objects where possible.

Check your own environment

These are read-only checks on Windows, run in an elevated Command Prompt.

vssadmin list shadows
reagentc /info
bcdedit /enum

The first lists existing shadow copies, the second shows whether the recovery environment is enabled, and the third shows boot settings. Compare the results against a healthy machine.

Then work through these:

• Confirm that an alert fires when shadow copy deletion tools run, in a test, on a lab host.
• List who can delete snapshots and backups in your cloud accounts.
• Confirm at least one backup copy sits where production credentials cannot delete it.
• Check which network devices keep backup images and who can erase them.

Quick check

Sources

• MITRE ATT&CK T1490: Inhibit System Recovery