D3-DKP Disk Partitioning: Rebuilding Partition Tables After Wipers and Compromise

When an attacker corrupts a partition table or plants code in the boot area of a disk, cleaning files is not enough: the disk layout itself has to be rebuilt from a known good definition. MITRE D3FEND names this countermeasure Disk Partitioning (D3-DKP) and defines it as "the process of dividing a disk into multiple distinct sections, known as partitions." It sits under the Evict tactic as a child of Disk Formatting (D3-DKF), which in turn sits under Object Eviction. This card explains what repartitioning achieves during eviction and recovery, which ATT&CK techniques D3FEND relates it to, how to run it on Windows and Linux estates, how to verify the rebuilt layout, and where it falls short. It is written for incident responders, endpoint engineers and recovery teams who already have a wiper or reimaging runbook and want the partition step done properly.

Key takeaways

• Repartitioning replaces the layout, not the data. Recreating a partition table removes attacker changes to the MBR, GPT headers and partition entries, but on its own it leaves file data in the sectors behind them.
• D3FEND's links are inferred. D3-DKP creates a Partition Table, so D3FEND relates it to Disk Content Wipe (T1561.001) and Disk Structure Wipe (T1561.002), which modify that artefact.
• It is a recovery and eviction step, not a sanitisation method. D3FEND's own reference for the technique is a study showing that data survives on drives that were only reformatted. Use NIST SP 800-88 methods when data must be made unrecoverable.
• Build from a defined layout. Repartition from a scripted, version-controlled layout (for Windows, the documented UEFI/GPT layout) so every rebuilt host matches and drift is easy to detect.
• Verification is cheap. Compare the rebuilt partition table against the expected layout and keep a backup of known good GPT data for each server class.

D3-DKP at a glance

How it works

D3FEND describes partitioning in general terms: each partition can be managed separately with its own file system, and partitioning helps segregate data, support recovery and isolate operating systems or environments on one disk. As an eviction countermeasure, the useful act is narrower. Writing a fresh partition table discards whatever the attacker did to the structures that tell firmware and the operating system where things are.

• MBR disks: the first sector holds boot code and the partition table. Destructive malware that overwrites this sector leaves the machine unbootable. Microsoft's analysis of the WhisperGate malware used against Ukrainian organisations in January 2022 describes a first stage that overwrote the Master Boot Record with a fake ransom note and had no recovery mechanism.
• GPT disks: a protective MBR, a primary GPT header and partition entry array at the start of the disk, and a backup copy of the GPT structures at the end. A wiper that only damages the primary copy can sometimes be repaired from the backup; one that damages both needs a rebuild.
• Boot partitions: on UEFI systems the EFI System Partition holds boot loaders. Recreating it from scratch, then reinstalling the boot loader from trusted media, removes files an attacker placed there.

D3FEND's reference for D3-DKP, its parent Disk Formatting and its sibling Disk Erasure is the same paper: Garfinkel and Shelat's "Remembrance of Data Passed: A Study of Disk Sanitization Practices", which examined second-hand drives and found recoverable data on drives whose owners had only formatted or repartitioned them. That is the key boundary for this technique. A new partition table evicts the attacker's structures; it does not make old data unreadable.

ATT&CK techniques D3FEND relates to D3-DKP

Relationship type: inferred only. D3FEND derives these rows through a shared digital artefact and labels them inferred and experimental (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.

Neither wipe technique is prevented by D3-DKP. Repartitioning is what you do after the damage, as part of rebuilding the host. Prevention and detection for wipers sit in other controls, covered in the MITRE ATT&CK T1561 Disk Wipe guide and the Wiper Malware Guide. Boot-area persistence through a bootkit (T1542.003) is a related case where a rebuilt layout helps, but D3FEND does not list that relation.

Where it is implemented

Implementation steps

1. Decide that a rebuild is warranted. Use repartitioning when the boot area or partition table is damaged or untrusted: after a disk structure wipe, after evidence of boot-area tampering, or as a standard step in reimaging any host that held attacker code with administrative rights.
2. Preserve evidence first. Take a forensic image of the disk, or at least of the first and last megabytes where MBR and GPT structures live, before anything is overwritten. Once the table is replaced, the attacker's changes are gone.
3. Store known good layouts in advance. For each server and workstation class, keep the scripted layout in version control and, for GPT servers, an sgdisk backup file taken from a clean build of that class. Microsoft's guidance and the sgdisk documentation both assume you restore to the disk the backup came from, so keep backups per class and per disk model.
4. Rebuild from trusted media. Boot from known good installation or recovery media, not the compromised operating system. Clear the old structures (DiskPart clean, Clear-Disk or sgdisk --zap-all), then create the defined layout.
5. Erase as well, if the data must not survive. If the disk will be reused for a different purpose or leaves your control, apply a sanitisation method from NIST SP 800-88 Rev. 2 rather than relying on repartitioning. See the Media Sanitisation Guide.
6. Reinstall and restore. Apply the golden image, reinstall boot loaders from trusted media and restore data only from backups verified as clean. The Wiper Attack Response Playbook covers the wider sequence.
7. Rollback. There is no rollback for a destructive repartition, which is why step 2 matters. For a failed rebuild, repeat from step 4; for a disk whose primary GPT only was damaged and whose data is needed, try a verified restore from the backup GPT before choosing a full rebuild.

How to verify it works

• Layout match: list the partitions after the rebuild (sgdisk --print on Linux, Get-Partition on Windows) and compare count, order, sizes and type IDs against the defined layout for that class.
• Structure integrity: on GPT disks run sgdisk --verify and expect no CRC errors and no mismatch between main and backup structures.
• Boot chain: confirm the host boots with Secure Boot enabled and that the EFI System Partition contains only the expected boot loader files. See the Linux Secure Boot and Shim Guide for Linux hosts.
• Fleet drift: collect partition layouts through endpoint inventory and flag hosts whose layout differs from their class definition.

Limits, bypasses and failure patterns

• Treating repartitioning as erasure: DiskPart clean and sgdisk --zap-all remove layout structures, not file contents. Data remains recoverable, as D3FEND's own reference shows.
• Firmware persistence survives: implants in UEFI firmware or device firmware sit outside the partition table. Repartitioning does nothing about them; firmware verification controls do.
• Rebuilding from the compromised OS: running the partition tool inside the infected operating system lets the attacker interfere with the process. Boot trusted media.
• Restoring a backup GPT from the wrong disk: sgdisk's documentation advises against restoring from anything other than the original disk. A mismatched restore can make data inaccessible.
• Losing the evidence: repartitioning before imaging destroys the very structures that show how the wiper or bootkit worked.
• Rebuilding without fixing the way in: in the Stryker Intune wiper attack, devices were wiped through a hijacked administrative account in the device management platform. Rebuilding disks while that access remains only invites a second wipe; the identity has to be contained first.

Framework mapping

Related countermeasures

• Disk Formatting (D3-DKF): the parent, which creates a new file system on the partitions. See D3-DKF Disk Formatting.
• Disk Erasure (D3-DKE): the sibling to use when data must not survive. See D3-DKE Disk Erasure.
• Object Eviction (D3-OE): the broad class for removing attacker objects from a host.
• The wider D3FEND model is summarised in the MITRE D3FEND Guide.

Practitioner checklist

• Keep a version-controlled partition layout for every server and workstation class.
• Store an sgdisk backup of known good GPT data per Linux server class and disk model.
• Capture the boot structures (start and end of disk) before any rebuild in a confirmed incident.
• Rebuild from trusted boot media, never from the compromised operating system.
• Use NIST SP 800-88 sanitisation, not repartitioning, when data must be unrecoverable.
• Verify every rebuilt layout against its class definition and run a GPT integrity check.
• Confirm Secure Boot is on and the EFI System Partition holds only expected files.
• Contain the account or management path the attacker used before mass rebuilds.

Standards and references

• MITRE D3FEND: Disk Partitioning (D3-DKP)
• MITRE ATT&CK: T1561 Disk Wipe
• NIST: SP 800-88 Rev. 2 Guidelines for Media Sanitization
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• Microsoft Learn: DiskPart clean
• Microsoft Learn: UEFI/GPT-based hard drive partitions
• Debian manpages: sgdisk(8)
• Microsoft Security Blog: Destructive malware targeting Ukrainian organizations

Related NHI Mgmt Group resources: Wiper Attack Response Playbook · Media Sanitisation Guide · Device Reassignment and Reimaging · Server Build and Golden Image Hardening Guide · MITRE D3FEND Guide