---
{
  "title": "Disk Wipe",
  "summary": "Disk wiping damages raw storage or structures required to access data.",
  "topic": "grc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    3
  ],
  "aliases": [
    "T1561"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1561: Disk Wipe",
      "url": "https://attack.mitre.org/techniques/T1561"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Disk wiping damages raw storage or structures required to access data. It can affect availability beyond ordinary file deletion and complicate recovery.


## An investigation example

A suspicious privileged process performs low-level disk writes shortly before a system becomes unusable.

## Evidence to examine

Review raw-device access, process identity, storage errors, management actions, and independent recovery copies.

## A common analytical pitfall

A damaged volume can have hardware causes; corroborate malicious writes and their timing.

## Response considerations

Stop confirmed destructive activity, preserve available evidence, and recover through validated procedures using unaffected copies or replacement infrastructure.


## Raw storage damage differs from ordinary deletion

A disk-wiping action can overwrite storage content or damage structures needed to locate and use it. The effects may reach beyond a single application. A device might fail to start, partitions may become unreadable, or files may no longer be recoverable through ordinary tools. Actual recovery prospects depend on the storage medium, what was changed, and which trustworthy copies remain.

Secure disposal is a legitimate activity, so context is essential. Compare the action with asset-retirement approval, device identity, operator authorization, and timing. A disposal task run against the wrong target can also produce severe harm without malicious intent. Evidence should distinguish the observed operation from conclusions about motivation.

## A fictional workstation cluster

Several classroom workstations fail after an unusual administrative job. The team isolates the affected deployment mechanism, preserves central job records, and identifies which devices received the operation. It avoids repeatedly booting or writing to the affected storage while specialists assess acquisition options. Working on a copy may be preferable where feasible and appropriate.

Restoration may require rebuilding devices and recovering data from protected sources rather than relying on file recovery. Confirm that the distribution account and job configuration are trustworthy before reusing the same deployment path. A fast rebuild through a still-compromised management system can recreate the incident.

## Review a disposal workflow

For fictional retired laptops, identify how the target device is verified, who approves disposal, what method is appropriate, and what completion evidence is retained. Then consider how those controls would prevent a job reaching active classroom devices. This teaches the distinction between authorized sanitization and destructive misuse without running a wiping utility or experimenting on storage containing real information.

Keep asset identity separate from a changeable display name. A disposal approval referring only to a familiar hostname can become ambiguous after devices are renamed or reassigned. Recording the appropriate stable identifiers helps the operator and reviewer confirm which physical storage was intended.

## Related concepts

- [[business-continuity]]
- [[disaster-recovery]]
- [[incident-response]]
- [[valid-accounts]]
- [[os-credential-dumping]]
- [[remote-services]]
- [[command-and-scripting-interpreter]]