DET0329: Behavioral Detection for T1490 - Inhibit System Recovery
This detection strategy is intended to help identify behavior associated with ATT&CK technique T1490, Inhibit System Recovery. The business significance is...
Analyst context for executives and security teams
This detection strategy is intended to help identify behavior associated with ATT&CK technique T1490, Inhibit System Recovery. The business significance is recovery risk: if an adversary removes backup catalogs, disables recovery services, or deletes built-in recovery data, an incident can shift from a contained compromise to prolonged outage, failed restoration, or higher-cost rebuild activity. Because the ATT&CK object provides no official detection logic, teams should treat DET0329 as a prompt to validate whether recovery-inhibition behavior is visible across the environments ATT&CK lists for T1490: Containers, ESXi, IaaS, and Linux.
Executive priority
Prioritize this as an operational resilience and incident readiness issue. Leaders should ask whether backup and recovery controls are both protected and observable, whether SOC and IR teams can detect attempts to disable recovery mechanisms before or during an impact event, and whether evidence exists for audit or resilience reviews. This is especially material where recovery time objectives, immutable backups, cloud/virtualization recovery, or cyber-physical continuity depend on trusted restoration paths.
Technical view
For SOC, detection engineering, and IR teams, the key validation is not a single signature but whether telemetry can show changes to recovery-enabling services, backup catalogs, snapshots, repair features, and recovery-related configuration. Since DET0329 has no official detection text or platform list of its own, coverage should be mapped to the related T1490 context: impact-stage behavior affecting Containers, ESXi, IaaS, and Linux. Detection content should be tested against authorized administrative maintenance to reduce false positives, while still surfacing unusual timing, scope, privilege use, and changes occurring near other impact or intrusion activity.
Likely telemetry
- System and service logs showing recovery, backup, or repair services being stopped, disabled, or modified
- Audit logs for deletion or alteration of backup catalogs, snapshots, restore points, or recovery metadata
- Linux command, process, authentication, and privilege-escalation telemetry related to recovery or backup changes
- IaaS control-plane logs for snapshot, backup, image, volume, or recovery-configuration changes
- ESXi or virtualization management logs for datastore, snapshot, backup, or recovery-related changes
Detection direction
- Inventory the recovery mechanisms in scope for Containers, ESXi, IaaS, and Linux, then confirm the SOC receives logs for actions that disable, delete, or materially alter them.
- Correlate recovery-inhibition events with identity context, privilege level, asset criticality, change window, and concurrent impact-stage activity.
- Tune alerts to distinguish normal backup administration, decommissioning, or disaster-recovery testing from unusual bulk deletion, off-hours activity, or changes made by unexpected principals.
- Validate that cloud and virtualization control-plane events are monitored, not only host-level logs, because recovery features may be managed outside the workload.
- Use this relationship-driven context to hunt for attempts to deny restoration options, but avoid assuming DET0329 provides complete detection logic; local detection engineering is required.
Mitigation priorities
- Protect recovery systems and backup data with least privilege, separation of duties, and strong administrative authentication.
- Ensure backup, snapshot, and recovery configurations are monitored and retained in tamper-resistant logging where feasible.
- Use resilient recovery designs, such as protected or immutable backup copies, when aligned to business continuity requirements.
- Regularly test restoration procedures and confirm that detection and incident response playbooks cover attempts to disable or delete recovery mechanisms.
- Review change-management evidence so approved recovery maintenance can be separated from suspicious behavior during investigations.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy, DET0329, that detects T1490 Inhibit System Recovery. The object itself has no official description, no official detection text, no tactics, and no platforms. The practical guidance above is therefore derived from the explicit relationship to T1490 and the supplied T1490 description, tactics, and platforms.
This take does not assert active exploitation, attribution, specific procedures, or guaranteed detection coverage. It also does not provide vendor-specific detections because the official detection field is not provided. Teams must validate telemetry, controls, and false-positive patterns in their own environment.
Behavioral Detection for T1490 - Inhibit System Recovery
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1490 | Inhibit System Recovery | This object detects Inhibit System Recovery. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 4d376ebd5aaa… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0329Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.