Reformatting a compromised disk is one of the most common eviction steps in incident response, and one of the most misunderstood: a quick format removes the file system's view of the data, not the data. MITRE D3FEND names this countermeasure Disk Formatting (D3-DKF) and defines it as "the process of preparing a data storage device, such as a hard drive, solid-state drive, or USB flash drive, for initial use." It sits under the Evict tactic as a child of Object Eviction and is the parent of Disk Erasure (D3-DKE) and Disk Partitioning (D3-DKP). This card explains what formatting does and does not remove, when it is a sufficient eviction step, how to run it in a rebuild, and how to confirm the host came back clean. It is written for incident responders and endpoint and server teams who rebuild hosts after compromise.
Key takeaways
- Formatting resets structure, not necessarily content. D3FEND describes formatting as setting up an empty file system, directory structure and metadata. A quick format leaves the old data blocks in place.
- It is an eviction step, not sanitisation. Formatting removes disk-resident persistence from the attacker's view of the system. When data must be unrecoverable, use its child technique, Disk Erasure.
- The boot path sits outside the volume. Formatting a volume does not rewrite the partition table or boot code, and does nothing about firmware, so bootkits and firmware implants need their own steps.
- The rebuild source decides the outcome. A clean format followed by a restore from an infected image or backup reinstalls the attacker.
- Prove the result. Verification means checking the rebuilt host against a known-good baseline and watching it for reinfection, not just confirming the format command completed.
D3-DKF at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-DKF (d3f:DiskFormatting) |
| Tactic | Evict |
| Parent technique | Object Eviction |
| Child techniques | Disk Erasure (D3-DKE), Disk Partitioning (D3-DKP) |
| Digital artefact | Secondary Storage (D3FEND relation: modifies Secondary Storage) |
| How D3FEND describes it | Setting up an empty file system with a directory structure and metadata; can remove existing data to give a clean slate or prevent access to previously stored data |
| D3FEND reference | Garfinkel and Shelat, "Remembrance of Data Passed: A Study of Disk Sanitization Practices" |
| Main limitation | Old data may remain recoverable; boot records and firmware are out of scope |
The D3FEND reference is a study of second-hand drives whose title says what it found: data from previous owners survived on media that had been disposed of. That is the core caution for this technique.
ATT&CK techniques D3FEND relates to D3-DKF
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-DKF. Every row below is inferred through the shared Secondary Storage artefact, and D3FEND labels these relations "inferred, experimental" (checked November 2026). Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | Tactic | Practical meaning |
|---|---|---|---|
| T1619 | Cloud Storage Object Discovery | Discovery | A reformatted volume no longer presents prior objects to enumerate |
| T1561 | Disk Wipe | Impact | Shares the artefact: attackers use formatting and wiping destructively |
| T1561.001 | Disk Content Wipe | Impact | Destructive overwriting of volume content |
| T1561.002 | Disk Structure Wipe | Impact | Destruction of partition tables and boot structures |
The Disk Wipe rows describe the attacker's use of the same capability, not something formatting counters. Responding to destructive attacks is covered in the MITRE ATT&CK T1561 Disk Wipe page and the Wiper Attack Response Playbook.
What formatting removes and what it leaves
| Item | Quick format | Full format with overwrite | What else is needed |
|---|---|---|---|
| Files and persistence on the volume (services, scheduled tasks, startup items, web shells) | Removed from the file system view | Removed and overwritten on addressable sectors | Nothing further for eviction |
| Old data blocks | Left in place, recoverable with forensic tools | Zeroed on host-addressable sectors | Disk Erasure for media leaving your control |
| SSD spare and overprovisioned areas | Untouched | Not reachable by host writes, as NIST SP 800-88 Rev. 2 notes | Device sanitize command or cryptographic erase |
| Partition table and boot code outside the volume | Untouched | Untouched | Recreate partitions (D3-DKP) and verify the boot chain |
| System and component firmware | Untouched | Untouched | Firmware verification or hardware replacement |
| Other volumes, snapshots, backups | Untouched | Untouched | Scope every copy before restore |
On Windows the difference is explicit in Microsoft's documentation for the format command: /Q deletes the file table and root directory of a previously formatted volume; /P zeroes every sector and then overwrites the volume the given number of times with random data, and /Q overrides /P.
When formatting is enough
- Commodity malware on a managed endpoint: a reformat and reimage from a trusted build, plus credential rotation, is usually proportionate. See Device Reassignment and Reimaging.
- Hosts that stay in your custody: leftover data blocks matter less when the disk is reused inside the same trust boundary and is encrypted at rest. For disks leaving your control, use D3-DKE Disk Erasure.
- Suspected bootkit or firmware implant: formatting alone is not enough. Recreate the partition layout, verify Secure Boot and firmware, or replace the device. See D3-BA Bootloader Authentication.
- Cloud instances: replacing the instance and its volumes from a trusted image is simpler and more reliable than formatting attached disks in place.
- Remote endpoints: device management wipe actions reset the device without hands on it. Microsoft Intune offers a full wipe, a wipe that keeps enrolment state and user account, and "Wipe device, and continue to wipe even if device loses power", which Microsoft warns can leave some devices unable to start.
Implementation steps in a rebuild
- Capture evidence. Image the disk and capture memory before formatting, using the Disk Imaging and Forensic Acquisition Guide. Formatting first destroys the timeline.
- Scope the persistence. Confirm from the investigation whether persistence was limited to the volume or reached boot records, firmware, other hosts or identities. That decides whether formatting, erasure or replacement is needed.
- Cut the attacker's other routes. Rotate credentials, keys and tokens that were on the host or used from it, and block known command and control, before the host returns. Otherwise the clean host is re-entered with the same access.
- Format with the right depth. Use a full format with overwrite or a device sanitize where data remnants matter; recreate the partition table where boot tampering is possible.
- Rebuild from a trusted source. Install from a signed, known-good image and restore data from backups checked for integrity, following D3-RDI Restore Disk Image.
- Return under watch. Rejoin the host to a restricted network segment first, confirm EDR and logging are healthy, then return it to production.
Formatting cannot be rolled back. The rollback point is the forensic image and the last verified backup; confirm both before step 4.
Where identity fits
A rebuilt host often keeps its old identity: the same computer account, machine certificate or cloud instance role. If the attacker extracted those credentials, the format evicted the malware but not the access. Rotate machine account passwords and reissue certificates and workload credentials as part of the rebuild, using D3-RIC Reissue Credential.
How to verify it works
- Baseline comparison: compare the rebuilt host's services, scheduled tasks, startup items and installed software with the golden image, using D3-FIM File Integrity Monitoring or configuration management reports.
- Boot integrity check: confirm Secure Boot state and measured boot or TPM attestation where available after any suspected boot-level tampering.
- Indicator sweep: rescan the host for the incident's file hashes, domains and persistence locations after rebuild.
- Reinfection watch: keep heightened alerting on the host for a period after return (for example 30 days, an NHI Mgmt Group suggestion, not a standard) and alert on any connection to known attacker infrastructure.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Rebuilt hosts imaged before format | 100% of confirmed compromises | Protects the investigation |
| Rebuilt hosts matching the golden baseline on first check | 100% | Shows the source image and process are clean |
| Reinfections within 30 days of rebuild | Zero | Measures whether eviction actually held |
| Host credentials rotated before return to production | 100% | Formatting does not revoke stolen credentials |
| Median time from eviction decision to clean return | Tracked per incident | Shows rebuild readiness |
Limits, bypasses and failure patterns
- Quick format treated as sanitisation: recoverable data leaves with a disk that was only quick-formatted. Use erasure or sanitize before disposal or transfer.
- Restoring the attacker: restoring from a backup or image taken after compromise brings persistence back. Check backup integrity before use, as NIST CSF 2.0 RC.RP-03 requires.
- Boot-level persistence: a bootkit (T1542.003) lives in boot records outside the formatted volume, and system firmware implants (T1542.001) survive any disk operation.
- Same credentials, same attacker: rebuilding a host while its service accounts, keys and machine certificates stay unchanged leaves the door open.
- Rebuilding one host of many: an attacker with domain-wide access re-enters a rebuilt host through other systems. Large intrusions need coordinated eviction, as in the Network Rebuild After Compromise Playbook.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IR-4 Incident Handling | Eradication as part of incident handling |
| NIST SP 800-53 Rev 5 | CP-10 System Recovery and Reconstitution | Returning a system to a known state |
| NIST SP 800-53 Rev 5 | MP-6 Media Sanitization | Applies when formatted media leaves your control |
| NIST CSF 2.0 | RS.MI-02, RC.RP-03 | Incidents are eradicated; backup integrity verified before restore |
| MITRE ATT&CK mitigations | M1046 Boot Integrity, M1053 Data Backup | Boot chain checks and clean restore points |
| MITRE D3FEND | Object Eviction, D3-DKF, D3-DKE, D3-DKP | Parent, technique and children |
Practitioner checklist
- Image the disk and capture memory before formatting a compromised host.
- Scope persistence beyond the volume: boot records, firmware, other hosts, identities.
- Rotate host credentials, keys and certificates before the host returns.
- Use full format with overwrite or device sanitize when data remnants matter; never quick format for disposal.
- Recreate the partition table where boot tampering is possible.
- Rebuild only from a signed golden image and integrity-checked backups.
- Compare the rebuilt host with the baseline and sweep for incident indicators.
- Watch rebuilt hosts for reinfection for a defined period.
Standards and references
- MITRE D3FEND: Disk Formatting (D3-DKF)
- NIST: SP 800-88 Rev. 2 Guidelines for Media Sanitization
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (IR-4, CP-10, MP-6)
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: T1561 Disk Wipe
- Microsoft Learn: format command
- Microsoft Learn: Intune device wipe remote action
- NCSC: Secure sanitisation and disposal of storage media
Related NHI Mgmt Group resources: D3-DKE Disk Erasure · D3-DKP Disk Partitioning · Incident Response Guide · Media Sanitisation Guide · MITRE D3FEND Guide