How T1490 inhibit system recovery threatens your restore path
T1490 Inhibit system recovery is the step where an adversary removes your ability to get back after a bad day. In ATT&CK, it sits under the Impact tactic (TA0040), which MITRE defines as adversary activity that is trying to "manipulate, interrupt, or destroy your systems and data." Inhibiting recovery does not destroy data on its own. It takes away the fallback that would make destruction survivable: local shadow copies, backup catalogs, boot and repair options, and snapshots. For a SOC lead, the question shifts from whether the attacker got in to whether the restore path is still intact when the incident is declared. This page targets Enterprise ATT&CK version 20.0.
The technique is commonly observed in the run-up to destructive events such as encryption or wiping, because it is a low-effort step that removes the most convenient recovery option before the destructive action lands. It is not limited to Windows endpoints. Recovery features exist on Linux hosts, ESXi hosts, cloud IaaS accounts and container platforms, and each has its own management interface and logs. Confirm which recovery mechanisms exist on each platform in your estate, who can change them, and whether those changes generate events you can see. The detection approach on this page relies on Process Creation, Command Execution and File Deletion telemetry, so a recovery store changed outside those channels is a potential blind spot. See the ATT&CK tactic page for Impact for the current technique list.
Decide now, before an incident, what your recovery path is allowed to lose. Ask whether backup copies are stored under separate credentials, whether they are protected from deletion or modification by the same administrators who run production, and whether the hypervisor and cloud accounts that host them send management events to your monitoring. Check the answers against the vendor documentation for each product rather than relying on defaults. Treat the backup platform as a high-value asset, and map its controls to the ATT&CK mitigations Data Backup (M1053) and User Account Management (M1018), which are covered later on this page.
Which telemetry reveals T1490 inhibit system recovery
This table maps each data component ATT&CK links to Impact techniques onto the T1490 behavior it reveals and the open-source collector that gathers it. Read each row as a question to answer in your own environment: is the signal collected, forwarded and retained long enough to alert? The main takeaway is that recovery inhibition shows up most reliably in process and command activity on hosts and hypervisors, and in deletion events on backup and snapshot stores.
| Data component | Signal to look for (illustrative) | Open-source collector |
|---|---|---|
| Process Creation (DC0032) | Utilities launched on a host whose names or arguments relate to shadow copies, backup catalogs or boot recovery settings, from unexpected parent processes | Wazuh agent, Auditd on Linux, Velociraptor for hunts across endpoints |
| Command Execution (DC0064) | Commands run through a shell, hypervisor console or remote management session that alter recovery features, confirmed by the operator account and source host | Wazuh agent with command monitoring, Security Onion for correlated host and network context |
| File Deletion (DC0040) | Removal of backup files, snapshot directories, recovery partitions or catalog files, especially in bulk or outside a scheduled retention job | Auditd file watch rules, Wazuh file integrity monitoring, Velociraptor artifact collection |
| File Creation (DC0039) | Creation of marker or script files in temporary or admin paths shortly before recovery settings change | Wazuh file integrity monitoring, Auditd, Velociraptor |
| Application Log Content (DC0038) | Backup server, hypervisor or cloud audit entries showing disabled jobs, changed retention, or deleted restore points | Wazuh log collection from backup products, container runtime and Kubernetes audit logs, ESXi syslog forwarded to Wazuh or Security Onion |
| Hypervisor and syslog events | ESXi shell or SSH sessions, VM snapshot removal and configuration changes outside change windows | ESXi syslog forwarded to Wazuh or Security Onion, Zeek for management network sessions |
Detection logic for T1490 on Linux, containers and ESXi
T1490 shows up as a sequence: recovery services change state, snapshots or backup files disappear, recovery settings are altered, and deletions cluster in time. Each idea below is written as detection logic you can express in Sigma and tune against your own baseline, so that scheduled jobs and approved changes do not drown the signal.
Recovery service state changes
Alert when a service or daemon responsible for backup or snapshot scheduling is stopped, disabled or removed outside a change window. On Linux this usually means watching service manager lifecycle events for backup agents and cron-driven snapshot jobs. Build a baseline of which hosts normally stop these services, for example during patching. Tune the rule to fire on stop or disable events that are not followed by a start within a short, agreed window. Expected false positives come from backup software upgrades and host reboots, so exclude known maintenance accounts and change tickets. Name the ATT&CK version the rule targets in its metadata.
Snapshot and backup artifact deletion
Flag deletion of VM snapshots, volume snapshots, container volume backups or backup repository files, especially when the actor is not the backup service account. On ESXi and IaaS platforms, review snapshot removal events and compare them with the backup job calendar. Tuning thresholds should separate single expected retention prunes from bursts, for example many snapshot deletions for one host within a short window. Scheduled backup rotations and retention policies are the main false positive source, so document their schedules and owners before enabling the rule. Confirm with each platform vendor which audit events record snapshot deletion.
Recovery configuration changes
Detect edits to files and settings that govern recovery, such as backup job definitions, retention values, snapshot schedules and boot recovery options on Linux hosts. File modification telemetry on the configuration paths is the most direct source. Baseline who edits these files and how often, and treat any change that disables a job or shortens retention as higher priority than a routine edit. Approved maintenance, configuration management runs and backup software upgrades will produce expected changes, so tie the rule to the orchestration identity and change record where possible. Keep the file paths in a version-controlled list so the rule stays accurate after upgrades.
Bulk or unusual deletion events
Correlate deletion events for backup-related files or snapshots within a short time window and across several hosts. A single deletion is usually noise, but a cluster of deletions from one process or account is a stronger signal. Set thresholds from your own baseline of deletion volume per host per day, and alert on deviations rather than fixed counts. Common false positives include storage cleanup jobs, log rotation tools and disk reclamation routines on container hosts, so allowlist these by process and parent. Validate the threshold in the cyber range before it reaches production.
Command execution against recovery tooling
Watch for process creation events where command-line tooling for backup, snapshot or boot recovery is invoked by an unexpected parent, user or host. Process Creation and Command Execution telemetry from Linux auditing, container runtime logs and ESXi shell logs are the primary sources. Scope the rule to recovery utilities used by administrators, and record the approved invocation patterns per platform. Expect false positives from automation tools, configuration management and scheduled maintenance, so tag those sources explicitly. Do not publish detection content that doubles as a tutorial for the tooling itself.
Rule format and version governance
Write each detection as a Sigma rule so it can be converted to the query language of your SIEM, and record the ATT&CK version it targets in the rule metadata. Because releases can rename, deprecate or revoke techniques, review T1490 mappings against the current ATT&CK release notes at each update. Keep a changelog of threshold and allowlist changes with the approver's name. Confirm with your SIEM vendor how converted Sigma rules are tested before promotion.
How the detection fits into a Wazuh and Security Onion stack
The T1490 detection only works if the right logs reach the SIEM in the first place, so the first decision is which sources feed Wazuh or Security Onion. Endpoint Linux and Windows telemetry, including process creation and command execution, should arrive through Wazuh agents or Beats-style shippers. Hypervisor logs from ESXi, container runtime and orchestrator audit logs, and IaaS control plane events should be forwarded over syslog or the provider's native log export. Confirm for each source which events it produces, how long they are retained locally, and whether timestamps are normalized to UTC before ingestion. A rule that reads a field the pipeline has silently dropped will never fire, and the failure looks like a quiet, healthy dashboard.
Sigma rules for this technique are written once, converted to the query language of the chosen backend, and deployed as scheduled or streaming detections. Wazuh can host rules in its own rule format, and Sigma converters can target the backends used in a Security Onion deployment, so the team should decide which backend is authoritative and keep converted output under version control. Log gaps need explicit handling: ESXi shell and host logs may be absent unless remote syslog is configured, and IaaS control plane deletion events may appear with a delay or only in a separate audit trail. Record each known gap as a documented limitation and agree who investigates it when the detection goes silent.
Detection mappings must be reviewed whenever MITRE ATT&CK publishes a release. The October 2025 release, v18, replaced detections in technique pages with detection strategies and analytics and changed data component IDs, and later releases (v19 in April 2026 and v20 in October 2026) can rename, deprecate or revoke content. Each Sigma rule and Wazuh rule should therefore carry the ATT&CK version it targets, and the team should confirm the current detection strategy and data component IDs for T1490 in the MITRE ATT&CK updates page before each review. Schedule the review as a recurring task, owned by a named engineer, so mappings do not drift from the ATT&CK version the SOC reports against.
How to validate the T1490 detection in a lab before production
This sequence proves that the T1490 detections fire on the platforms in scope, with known telemetry, within a measured alert latency, and that every gap is recorded for tuning before the rules reach production. It runs in a private cyber range that mirrors the production logging path.
Define scope and target platforms
The detection owner and the platform leads agree in writing which platforms are in scope, such as Linux hosts, container hosts, ESXi hypervisors and IaaS control planes, and which ATT&CK version the detections target. Record the version explicitly, because releases can rename or deprecate techniques. Done means a signed scope sheet lists each platform, its log sources and its owner.
Map expected telemetry per platform
For each platform, document which data components should carry evidence of inhibited recovery, such as Process Creation, Command Execution and File Deletion, and which log source delivers them. Confirm the agent, audit rule or API log feed on each system, and note where a platform cannot produce the expected telemetry. Done means every in-scope platform has a telemetry matrix that a second engineer has reviewed.
Write the expected alert and success criteria
Define, for each detection, the alert name, severity, required fields and the response the on-call analyst should see. Set criteria for a pass, such as the alert firing with the correct host, user and platform tags. Keep this document separate from the emulation tooling so results can be compared against a fixed expectation. Done means each detection has a written expected outcome that the team can test against.
Select an approved emulation library
Choose emulation content from a library your security governance has approved, and label each item as benign or adversary-like. Benign sequences check false positive behavior on administrative work such as routine backup verification, while adversary-like sequences check detection coverage. Confirm with the range operator that every item runs only inside the isolated lab. Done means an approved, versioned list of test cases exists with its benign and adversary-like split recorded.
Replay benign and adversary-like sequences
The range operator replays the approved cases on each in-scope platform in a fixed order, starting with benign activity, then the adversary-like set. A second person observes the run and logs timestamps for each case. The run is complete when every case has a start time, an end time and an observed outcome. This step is about the sequence and the evidence, so any executable content stays in the approved library and out of this page.
Measure detection and alert latency
Compare the time each event was generated on the host or platform with the time the event was ingested by the SIEM and the time the alert was raised. Record detection latency and alert latency separately, since they usually have different causes. Do not set a target value until the business owner and the platform team agree one in writing. Done means each case has both latency figures and a pass or fail against the agreed criteria.
Record gaps and tune the rules
Log each missed alert, late alert, wrong severity or false positive as a gap with a root cause, such as a missing audit rule, a parser error or an overly broad exclusion. Tune the rule or fix the telemetry, then rerun the affected cases to confirm the change. Done means every gap has an owner, a fix and a retest result. Keep a copy of the before and after rule versions.
Sign off results and file the evidence
Produce a results record that lists the scope, the ATT&CK version, the telemetry matrix, each test case outcome, latency measurements, the gap log and the retest results. The detection owner and the security lead sign it before any rule moves toward production. Store the record with your change management evidence so that auditors and future reviewers can trace the decision. Done means the signed record is accessible to the teams that will operate the rule.
Mitigations that keep recovery possible
T1490 succeeds when an adversary removes the means to restore systems, so the mitigations here focus on keeping backups intact and under separate control. The cards cover backup copies, administrative separation, privileged account review and two supporting controls that protect recovery systems specifically.
Immutable and offline backup copies
Data Backup (M1053) is the mitigation most directly aimed at T1490, because it keeps restore points available after production systems and their local snapshots are deleted. Keep at least one copy that the production administrator account cannot modify or delete, such as object storage with write-once retention or an offline medium. Confirm with your backup vendor how retention locks are enforced and who can override them. Test a restore from the protected copy at a fixed interval and record the result.
Separate backup and production administration
An adversary who holds production administrator rights can often reach the backup console, which is why T1490 is so damaging. Assign backup administration to a distinct identity group, with separate credentials, separate management hosts and no standing trust from production domain administrators. Require a second approver for changes to retention, replication targets and deletion settings. Ask your team to document which accounts can disable backup jobs and confirm that the list matches the access review.
Privileged account review
User Account Management (M1018) covers how accounts are created, granted rights and removed, and T1490 commonly relies on accounts that have more rights than their role needs. Review every account and service identity that can delete snapshots, change backup policies or stop backup services. Remove shared accounts, retire unused service identities and require strong authentication for administrative sessions. Repeat the review after each change to the backup platform, because new integrations often create new privileged paths.
Restricted permissions on recovery storage
Restrict File and Directory Permissions (M1022) supports recovery when it is applied to the repositories, catalogs and configuration files that a backup product depends on. Limit write and delete rights on backup repositories to the backup service identity and named backup administrators. Verify that hypervisor snapshot directories and backup catalogs carry the same restriction as the data they protect. This control reduces the surface, but it does not replace an immutable copy.
Segmented recovery network
Network Segmentation (M1030) limits how far an adversary can move from production into the systems that hold backups and recovery tooling. Place the backup server, its repositories and its management interface on a network zone with explicit allow rules for the replication and restore paths only. Block interactive logons into that zone from general user networks. Confirm during an exercise that a compromised production host cannot reach the backup management plane directly.
What to do when the T1490 alert fires
The first decision is whether the alert describes a real change to recovery capability or a benign administrative action. A T1490 alert should be treated as a potential loss of recovery options until the analyst confirms otherwise. Start by confirming the event itself in the raw telemetry, not only in the summary rule output. Record the host or hypervisor name, the process or management command involved, the account that ran it, and the time. On ESXi, Linux and container hosts, check whether the activity came from an expected automation path such as a configuration management job, a backup agent update or a platform maintenance window. Then check the change management system for a ticket covering the same host, account and time window. If no ticket exists, treat the event as unexplained until the owner of the system or the account confirms it.
Next, establish whether recovery capability is actually degraded. Do not assume it is intact because the backup job ran last night. Verify backup integrity from a location and credential set the affected host cannot reach, such as a separately administered backup repository or an immutable copy, and confirm that the most recent restore point is readable. Keep the affected systems connected to the network only as far as needed for evidence collection. Isolate the host or hypervisor from production paths, restrict administrative sessions to the response team, and preserve logs from the SIEM, the host, the hypervisor management plane and the identity provider before any cleanup or reboot. Disable or restrict the account involved only after its recent activity is captured, so the analysis is not lost.
Escalate to incident response as soon as the event is unexplained or touches a backup platform, hypervisor management or identity provider, even if the scope is not yet clear. The incident lead should decide, with business owners, which restoration path is viable: restore from the verified copy, rebuild from known-good images, or hold restoration until the access path is closed. Document each decision and its evidence, because auditors and regulators will ask how recovery was chosen. The restoration decision should never rest on the affected system's own backup metadata alone. Confirm the operational steps, owners and escalation contacts in advance with your own environment, since response timelines and retention periods depend on your agreements and platform configuration.
Rehearsing T1490 detection in a private cyber range
A Linux rehearsal uses a small private range with a monitored host group, a backup target and a central log platform. The blue team sees the host telemetry through the same pipeline used in production, so the exercise tests the detection content as well as the analyst's response. The range is private and isolated, and DeployOpen designs the scenario but does not run live adversary tooling outside the agreed scope.
- Range topology: Two or three Linux hosts forwarding process and file activity to a Wazuh or Security Onion manager, plus an isolated backup repository that the hosts can reach only through its documented path.
- Injects: A scheduled, unplanned change to backup state on one host, such as a retention setting that is altered outside the change calendar, delivered as a scripted event the blue team must triage.
- Good detection: Process Creation and Command Execution events are matched to a Sigma rule for recovery inhibition, and an alert reaches the queue within the window the team has agreed in advance.
- Good response: The analyst confirms the host, checks the backup job history, isolates the host if needed and records who approved any change.
- Operational check: Confirm the log forwarding timing and the rule version with your own platform team before the exercise starts.
After the run, check that the alert, the ticket and the backup evidence all tell the same story.
A container rehearsal focuses on the orchestration layer and the persistent volumes that hold recovery data. The range runs a self-hosted cluster in an isolated environment with an audit log pipeline and a snapshot or backup controller. The purpose is to test whether a change to a backup resource, a snapshot policy or a volume retention setting is visible and attributable.
- Range topology: A small self-hosted Kubernetes cluster with audit logging enabled, a backup operator deployed in a separate namespace, and a Wazuh or Security Onion collector for the audit stream.
- Injects: An unscheduled change to a backup schedule or snapshot retention object, made with a service account that has not changed in the rehearsal window.
- Good detection: Audit events for the change are parsed, tied to the identity that made it, and matched against an approved change list. The detection should not depend on container image names alone.
- Good response: The team pauses the affected schedule, verifies the last good snapshot, reviews the service account's recent access and restores policy from version-controlled configuration.
- Operational check: Confirm with your platform team which audit levels are enabled, since the event detail varies with configuration.
Record whether the team could identify the actor from the audit trail alone, without asking the platform owner.
An ESXi rehearsal covers hypervisor-level changes to snapshot and backup behavior, which can affect many virtual machines at once. The range uses a lab host group, a separate management network, and a syslog pipeline from the hypervisors. The team tests whether management-plane activity is logged, forwarded and reviewed quickly enough to matter.
- Range topology: Two lab hypervisors forwarding syslog to a collector, a vCenter-style management host in a restricted network segment, and a backup appliance that holds the recovery points.
- Injects: A change to snapshot or backup configuration on a lab virtual machine group, made from an administrative session outside the normal change window.
- Good detection: Command Execution and authentication events from the management host are correlated with the change, and an alert names the affected virtual machines and the session source.
- Good response: The analyst restricts the management session, confirms which recovery points remain, and escalates to the hypervisor owner for a controlled rollback of the configuration.
- Operational check: Confirm which hypervisor and management log sources your version exposes and whether they reach your collector without gaps.
Note how long it took to identify every affected virtual machine, because that time drives the scope of recovery.
An IaaS rehearsal uses a dedicated test cloud account or subscription with its own backup vault, control plane logging and identity controls. The range checks whether changes to backup plans, retention policies or vault access are logged and reviewed. Because cloud control planes differ by provider, the team confirms each event source before the exercise.
- Range topology: A test account with a managed backup service, a separate vault with restricted deletion, and control plane audit logs routed to the team's log platform.
- Injects: An unplanned change to a backup plan's retention or a vault access policy, applied by a role that has not performed backup work recently.
- Good detection: The control plane event is ingested, mapped to the acting identity and matched to a rule that flags recovery-related policy changes outside the change calendar.
- Good response: The team reviews the identity's session, suspends the role, confirms vault immutability settings and restores the approved policy from infrastructure-as-code.
- Operational check: Ask the cloud provider and your security team which control plane events are logged by default and which require configuration.
After the exercise, confirm that the approved policy can be reapplied without manual steps, since that is what a real recovery will need.
Questions SOC leads ask about T1490 detection
How do we avoid false positives from scheduled backup jobs?
Start by allowlisting the backup service accounts, hosts and binaries that legitimately touch shadow copies, snapshots or backup catalogs, and key the rule on the account and parent process rather than the action alone. Scheduled jobs are predictable, so record their normal execution windows and alert on deviations such as a deletion run outside the window, from an unexpected host, or under an interactive user. Review the allowlist on a fixed schedule, because backup tooling changes after upgrades and stale exceptions become blind spots. Confirm each exception with the backup owner in writing and keep the reasoning in the detection repository so auditors and new analysts can follow it.
Do Sigma rules cover ESXi hosts for inhibit system recovery?
Coverage for ESXi depends on what your pipeline ingests, so verify it rather than assume it. Sigma is a rule format, and community rules exist for many Linux and Windows telemetry sources, but ESXi coverage is thinner and often needs a log source mapping you write yourself. Confirm that your hypervisor logs, shell activity and host configuration changes reach the SIEM, then test whether a translated rule fires on those events in a lab. Where a rule does not exist, write the detection logic in plain words first, then convert it to Sigma so it stays portable across backends.
How do we version detections against ATT&CK releases?
Tag every detection with the ATT&CK version it targets and the technique and detection strategy identifiers it maps to. MITRE's ATT&CK updates page lists releases that can rename, deprecate or revoke techniques, and ATT&CK v18 replaced technique-level detections with detection strategies and analytics. Keep the mapping in version control, and when a new release lands, diff the Enterprise content against your mapping and record which rules changed. This makes audit questions about coverage answerable without reconstructing history from memory.
How do we test T1490 detections without disrupting real backups?
Run the tests in a private cyber range or an isolated staging copy of your backup environment, never against production recovery points. Use a dedicated test tenant with disposable snapshots, and agree the exercise window, the owner and the rollback steps in writing before anyone runs it. Validate that the alert fires, reaches the right queue, carries the fields analysts need, and that the response playbook can be followed. Afterward, confirm that production backups remain intact by checking restore points, and document any gap found as a tracked change.
Which logs should we retain for forensics on inhibit system recovery?
Retain the events that show who ran a recovery-inhibiting action, from where, and what it touched, for longer than your routine log window. The most useful sources are process creation and command execution records on endpoints and hypervisors, file deletion records on backup storage, authentication events for the accounts involved, and the backup platform's own audit trail. Set retention with your legal and compliance owners, store logs in write-once or separately administered storage, and confirm time synchronization across sources so the sequence of events can be reconstructed. Retention periods should come from your own policy, not from a default.
How do we tell maintenance from adversary activity?
Look for context rather than the action itself, because maintenance and attacks can run identical commands. Maintenance is usually tied to a change ticket, a named operator, a known host and a window, while adversary activity often lacks those links, appears after unusual authentication, or spans several systems in a short period. Correlate the alert with identity events, recent privilege changes and network activity from the same host. When context is missing, escalate rather than close the alert, and require the change owner to confirm the activity before the case is closed.
Can our own team build and maintain this detection set?
Many SOC teams can build the initial rules themselves if they have analysts who understand both the backup platform and the telemetry, but the ongoing work is the harder part. Ownership usually splits between detection engineering, which writes and tunes rules, the backup team, which confirms legitimate jobs, and the SOC, which runs the response. DeployOpen can plan, implement and document a detection set inside your own infrastructure as a fixed-scope engagement, with scope and deliverables agreed in writing before work starts. Ask any partner to show how rules are tested in a cyber range and how changes are tracked against ATT&CK versions.
How DeployOpen builds T1490 detections and range exercises
DeployOpen works on T1490 Inhibit system recovery as a fixed-scope engagement inside the client's own environment, covering the detection, its validation and the response steps around it. The work is written down before it starts, so the client knows what is built, tested and handed over.
How we scope
- Agree in writing which platforms are in scope, such as Linux, ESXi, IaaS and container hosts.
- Confirm which telemetry sources exist today, including process creation, command execution and file deletion logs.
- Record the ATT&CK version the detection maps to, so later technique changes can be traced.
How we build
- Write detection logic for backup inhibition as Sigma rules and translate them to the client's SIEM stack.
- Map the rules to the Data Backup and User Account Management mitigations and document the coverage gaps.
- Tune alert thresholds with the client's administrators so routine backup maintenance does not flood the queue.
How we hand over
- Deliver detection documentation covering data sources, logic, expected false positives and triage steps.
- Provide a validation record showing which test scenarios in the private cyber range triggered each alert.
- Walk the client's security operations and backup teams through the response runbook and escalation path.
How we support
- Offer ongoing support and continuous testing as a retainer, scoped separately from the initial engagement.
- Review detection mappings when MITRE ATT&CK releases rename, deprecate or revoke related content.
- Confirm with DeployOpen during scoping which retainer terms, upgrade cycles and rehearsal frequency apply.
