ATT&CK Impact Tactic (TA0040) Guide: Detecting Encryption, Destruction and Disruption

The Impact tactic (TA0040) is where an intrusion becomes a business outage: encrypted servers, wiped devices, deleted backups, stopped services and stolen money. ATT&CK v20 describes it as the adversary "trying to manipulate, interrupt, or destroy your systems and data", and notes that business processes can sometimes look fine while having been altered to benefit the attacker. This guide is the hub over the ransomware, wiper and denial of service material on this site. It maps the 15 Impact techniques in v20, explains where they appear (including cloud storage and device management consoles), and concentrates on the late-stage detections and recovery controls that limit damage. It is written for SOC analysts, infrastructure and backup owners, and incident responders.

Key takeaways

• Impact is the end of a chain, not the start. Encryption or wiping usually follows days of credential theft, discovery and collection, so detections earlier in the chain buy more time than any Impact analytic.
• Encryption, recovery inhibition and service stops travel together. In the v20 dataset Data Encrypted for Impact (T1486) has 87 recorded uses, and Service Stop (T1489) and Inhibit System Recovery (T1490) 57 each.
• Cloud and management planes are now impact tools. v20 includes Lifecycle-Triggered Deletion (T1485.001), Cloud Service Hijacking (T1496.004) and SMS Pumping (T1496.003); real attacks have used S3 server-side encryption with customer keys and Intune remote wipe.
• Backups are the decisive mitigation. MITRE maps M1053 Data Backup to encryption, destruction, recovery inhibition, defacement and disk wipe; backups the attacker's identity cannot delete are what make recovery possible.
• Destructive actions need a second identity. Multi-admin approval, separate backup credentials and no standing global admin rights stop one hijacked account from destroying everything.

How the attack works

By the time Impact techniques run, the adversary usually holds administrative credentials and has prepared the ground: security tools impaired, backups located, data exfiltrated for extortion. The 15 techniques group by outcome.

Service Stop and Account Access Removal often run seconds before encryption so that databases release file locks and administrators cannot intervene. See the T1490 Inhibit System Recovery Defensive Guide, the Wiper Malware Guide and the Cryptojacking Guide for the individual families.

Where it shows up

• Ransomware on Windows estates: encryptors pushed through group policy or deployment tools, preceded by service stops and shadow copy deletion. See the Ransomware Groups Guide.
• Hypervisors: encryption of VMDK and VMX files on ESXi datastores, which takes every guest down at once. See the ESXi Ransomware Playbook.
• Cloud storage: objects re-encrypted with attacker keys, versioning disabled, lifecycle rules set to delete, snapshots removed. See the Cloud Ransomware Guide.
• Device management consoles: a hijacked administrator issuing remote wipe through a mobile device management or endpoint management service, with no malware on the endpoints.
• State-linked destructive operations: wipers disguised as ransomware, aimed at disruption rather than payment.
• Financially motivated abuse: cryptomining on stolen cloud accounts and business email compromise payments (T1657).

Impact

This is the tactic where cost becomes visible: downtime, lost revenue, regulatory reporting, ransom demands and recovery labour. Recovery time depends far more on preparation than on the attack itself. Organisations with immutable, isolated backups and rehearsed rebuilds restore in days; those whose backups shared credentials with production may not recover data at all. Destruction through legitimate management channels is particularly damaging because the commands are valid, fast and fleet-wide. Data Manipulation can be the hardest outcome to recover from, because the organisation must first establish which records are still trustworthy.

Detection

Impact detections fire late, so they should trigger automated containment, not just a ticket. The v20 detection strategies below name the key log sources.

Containment triggers

• Endpoint: EDR automatic isolation on ransomware behaviour and on shadow copy deletion by a non-backup process.
• Identity: automatic session revocation and account disable when one identity performs bulk deletes, bulk wipes or bulk account changes.
• Cloud: alerts on PutBucketLifecycleConfiguration, versioning suspension, DeleteSnapshot and backup vault policy changes, with a runbook to apply a deny policy to the acting principal.
• Canaries: decoy files in shares whose modification triggers isolation of the writing host.

Metrics that show it is working

• Restore test success: percentage of critical systems restored from backup in the last quarter within their recovery time objective.
• Backup isolation: share of backup copies that are immutable or offline and administered by separate identities.
• Time to contain: seconds from the first encryption or mass-delete alert to host or identity isolation in exercises.
• Destructive action control: share of bulk wipe, delete and retire actions in management consoles that require a second approver.

Prevention and hardening

Phased rollout

1. Know what must come back first: agree a critical asset list and recovery order with the business, as the #StopRansomware Guide's triage step expects.
2. Separate backup identity: move backup consoles and vaults to accounts and MFA outside the production directory. See the Backup Identity Isolation Guide.
3. Enable immutability: turn on object lock or vault lock in governance mode first, test restores, then move to compliance mode where retention must be guaranteed.
4. Deploy detections in alert mode: tune shadow copy, mass delete and lifecycle analytics against backup software and maintenance jobs, then enable automatic isolation.
5. Rehearse and roll back: run a full restore exercise; keep automatic containment reversible per host or identity so a false positive can be undone quickly.

Decision guidance

• Governance versus compliance immutability: compliance-mode locks cannot be shortened even by the root account, which protects against a full tenant compromise but makes mistakes permanent; governance mode allows authorised overrides.
• Small organisations: a managed backup service with immutable copies and separate credentials, plus EDR with ransomware protection, covers most of the risk.
• Large organisations: prioritise hypervisors, identity providers and device management consoles, where one action affects thousands of systems.

Framework mapping

Where identity fits

Almost every large-scale Impact action is an authenticated administrative call: a deployment tool pushing an encryptor, a cloud key re-encrypting objects, a console administrator issuing wipes, or a backup administrator deleting restore points. Non-human identities matter here too. App registrations and service principals with device management or Microsoft Graph permissions can issue the same destructive commands as a human administrator, and long-term cloud access keys with write and delete rights are a ready-made ransomware tool. Inventory every identity that can delete, wipe, encrypt or change retention, remove standing access, and alert on its use outside expected pipelines. See the Ransomware Playbook Template.

Lessons from incidents

• Destruction without malware: in the Stryker attack (March 2026), a compromised administrator account was used to create a new Global Administrator and issue Intune remote wipe commands; a source cited by BleepingComputer put the number of wiped devices near 80,000. Multi-admin approval for bulk wipes and just-in-time admin rights are the controls that break this pattern.
• Cloud-native encryption: in the Codefinger S3 ransomware campaign (January 2025), leaked long-term AWS keys with read and write permissions were used to re-encrypt objects with SSE-C keys AWS does not store, and lifecycle rules set deletion within seven days. Blocking SSE-C where unused, short-lived credentials and versioning with object lock remove the leverage.

Common failure patterns

• Backups on the same identity plane: backup servers joined to the production domain, or vaults administered by the same cloud admin roles the attacker holds.
• Untested restores: backups exist but restores of whole applications have never been timed.
• Alert without action: encryption detections that open a ticket rather than isolating the host or identity.
• Unlimited console power: a single administrator can wipe, retire or delete the whole fleet with no second approval.
• Ignoring the hypervisor: ESXi hosts with shared credentials and SSH enabled, outside EDR coverage.

Practitioner checklist

• Keep immutable or offline backup copies administered by identities separate from production.
• Test full restores of critical applications against recovery time objectives every quarter.
• Alert and auto-contain on shadow copy deletion, mass file renames and ransom note creation.
• Alert on cloud lifecycle, versioning, snapshot and backup policy changes, and block SSE-C where unused.
• Require multi-admin approval for bulk wipe and delete actions in device and cloud consoles.
• Remove standing global administrator rights and alert on new top-tier role assignments.
• Bring ESXi hosts into monitoring, disable SSH by default and use unique credentials.
• Maintain golden images and a predefined critical asset recovery order.
• Rehearse the ransomware playbook, including identity reset and token revocation.

Standards and references

• MITRE ATT&CK: Impact (TA0040)
• MITRE ATT&CK: Data Encrypted for Impact (T1486)
• MITRE ATT&CK: Inhibit System Recovery (T1490)
• MITRE ATT&CK: Data Destruction (T1485)
• CISA: #StopRansomware Guide
• Microsoft Learn: Attack surface reduction rules reference
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Ransomware Response and Recovery Guide · Ransomware Prevention Guide · T1490 Inhibit System Recovery Defensive Guide · ATT&CK Collection Tactic Guide