D3-RDI Restore Disk Image (MITRE D3FEND)

Reimaging a compromised host is only a recovery if the image is clean, current and actually the one you meant to restore. D3-RDI Restore Disk Image is the MITRE D3FEND countermeasure for writing a previously captured disk image back to a drive. D3FEND defines it as "Restoring a previously captured disk image a hard drive", places it in the Restore tactic under Restore Object (D3-RO) and cites CISA's Cybersecurity Incident and Vulnerability Response Playbooks as its reference. D3FEND's data for this technique is thin: it names no digital artefact relationship and no ATT&CK mapping. This card therefore concentrates on the practical questions: which image to trust, how to restore physical and cloud disks, how to verify the result and where the technique fails. It is written for infrastructure, endpoint and incident response teams. Siblings are D3-RD Restore Database, D3-RF Restore File, D3-RS Restore Software and D3-RC Restore Configuration.

Key takeaways

D3-RDI restores a whole disk, not selected data. Operating system, applications, configuration and any embedded credentials all return to the state of the capture.
Image provenance is the control. Restore only from images with a known build date, a recorded hash and storage the attacker could not reach.
Old images bring old risk. An image captured before the compromise may still carry the vulnerability that was exploited, so patch before reconnecting.
Preserve before you reimage. The compromised disk is evidence; capture it before writing the restore over it.
D3FEND lists no ATT&CK techniques for D3-RDI. In practice it answers destructive and ransomware techniques such as T1561 Disk Wipe and T1486 Data Encrypted for Impact (NHI Mgmt Group assessment).

D3-RDI at a glance

Field	D3-RDI Restore Disk Image
D3FEND ID	D3-RDI
Tactic	Restore
Parent technique	Restore Object (D3-RO)
Siblings	Restore Configuration (D3-RC), Restore Database (D3-RD), Restore File (D3-RF), Restore Software (D3-RS)
Digital artefact	None declared for D3-RDI. D3FEND separately defines Disk Image as "a snapshot of a storage device's structure and data typically stored in one or more computer files on another storage device"
ATT&CK mapping in D3FEND	None (checked November 2026)
D3FEND reference	CISA: Cybersecurity Incident and Vulnerability Response Playbooks (November 2021)
Usually follows	D3-DKE Disk Erasure or D3-DKF Disk Formatting during eviction

Which image to restore

Image type	What it contains	Trust question
Golden image	A preconfigured build of the operating system and applications	Is it maintained and patched, and was the build pipeline itself unaffected?
Host backup image	A full image of a specific machine at a point in time	Was it captured before the attacker's first access, and was it stored where the attacker could not change it?
Hypervisor or cloud volume snapshot	A point-in-time copy of a virtual disk	Was the snapshot account separated from the compromised environment, and is the snapshot crash-consistent or application-consistent?
Forensic image	A bit-for-bit copy taken for investigation	Never restore it to production: it contains the compromise by design

CISA's ransomware guidance recommends maintaining and regularly updating golden images of critical systems so they can be deployed quickly to rebuild a system, and keeping infrastructure-as-code templates backed up offline for cloud resources. It also warns that some images may not install correctly on different hardware or platforms, so plan for spare hardware or alternative build routes. Where a golden image and a host backup are both available, rebuilding from the golden image and restoring data separately with D3-RF Restore File avoids bringing back unknown changes made to that host. See the Server Build and Golden Image Hardening Guide.

Where it is implemented

Image restore is provided by backup and imaging products, endpoint deployment tools, hypervisors and cloud block storage. For cloud disks the documented patterns are below; providers are listed alphabetically.

Provider	Restore pattern	Notes from the documentation
Amazon EBS	Create a new volume from the snapshot in the same Availability Zone as the instance, detach the damaged volume and attach the new one	Blocks of a volume created from a snapshot are downloaded from Amazon S3; until initialisation completes the volume may show higher latency. Fast snapshot restore or a provisioned initialisation rate removes or bounds that delay
Azure managed disks	Create a new managed disk from the snapshot, then use it as the OS disk of a new VM or attach it as a data disk	A snapshot is described as a full, read-only copy of a managed disk that exists independently of the source; shut the VM down cleanly before snapshotting if you plan to create a VM from it
Google Compute Engine	Create a disk from a standard or archive snapshot, create an instance from a boot disk snapshot, or attach a restored disk to a new instance	The documentation states a disk restored from a snapshot reaches its maximum performance immediately without pre-warming

Restoring to a new disk, rather than overwriting the existing one, keeps the compromised disk available for investigation and makes rollback a simple detach and reattach.

Implementation steps

Capture evidence. Take a forensic image or snapshot of the compromised disk and record its hash before any restore. NIST SP 800-86 covers integrating this into incident response.
Find dropper malware first. CISA advises identifying dropper malware before rebuilding from backups, otherwise the rebuilt host can be compromised again.
Select and validate the image. Confirm the capture date against the incident timeline and compare the image hash with the value recorded when it was created. See D3-FH File Hashing.
Restore on an isolated segment. Rebuild critical systems on a clean network in priority order, as CISA's guidance recommends.
Patch and harden before reconnecting. Apply updates released since the capture and close the entry point used in the incident.
Reset machine identity. Rotate local administrator passwords, host keys and certificates, and service credentials stored on the image.
Restore data and reconnect. Bring back user and application data separately, then return the host to production with enhanced monitoring.

Where identity fits

A disk image holds machine credentials: the local administrator password, SSH host keys, TLS private keys, cached service account secrets and, for domain-joined Windows machines, the computer account's secret. Restoring an old image puts those values back. Any that were exposed in the incident are compromised again, and a domain-joined host restored from an older image may hold an outdated computer account secret and fail to authenticate to the domain until the account is reset. Treat every secret on a restored image as needing rotation, and prefer images that pull secrets at boot from a secrets manager rather than storing them. See D3-RIC Reissue Credential.

How to verify the restore

Hash check: the image used matches the hash recorded at capture.
Boot and service test: the host boots, required services start and the application passes a smoke test.
Patch level: the restored host is at the current approved patch baseline before network access.
Credential check: local and service credentials on the host differ from those in the image.
Security tooling: endpoint detection, logging and management agents are installed and reporting.

Metric (example, not a standard)	What it shows	Direction
Golden images rebuilt or patched within the agreed cycle	Images are current enough to use	100%
Images with a recorded hash and capture date	Provenance can be proved	100%
Measured time to rebuild a critical host from image	Realistic recovery time	Within target
Restored hosts reconnected before reaching patch baseline	Reintroduced vulnerabilities	Zero
Restored hosts with machine credentials rotated	Identity hygiene after reimage	100%

Limits and failure patterns

Infected image: the image was captured after the attacker arrived, or the build pipeline was compromised.
Images within reach of the attacker: snapshots and image stores reachable with the same administrator credentials are deleted or encrypted alongside the hosts (T1490 Inhibit System Recovery).
Stale image: the restored host is missing months of patches and is exploited again.
Evidence destroyed: reimaging over the only copy of the compromised disk.
Hardware or platform mismatch: the image does not boot on replacement hardware, delaying recovery.
Embedded secrets reused: keys and passwords inside the image are not rotated after the restore.

For the destructive techniques D3-RDI recovers from, see T1561 Disk Wipe and T1486 Data Encrypted for Impact.

Framework mapping

Framework	Reference	Relationship to D3-RDI
NIST SP 800-53 Rev 5	CP-9 System Backup, CP-10 System Recovery and Reconstitution	Image backups and system reconstitution
NIST SP 800-53 Rev 5	CP-4 Contingency Plan Testing	Rebuild tests
NIST SP 800-53 Rev 5	SI-7 Software, Firmware, and Information Integrity	Verifying image integrity
NIST SP 800-86	Guide to Integrating Forensic Techniques into Incident Response	Evidence capture before reimaging
MITRE ATT&CK mitigation	M1053 Data Backup	Closest in intent

D3FEND cites only the CISA playbook for D3-RDI; the other rows are NHI Mgmt Group's mapping by intent.

Practitioner checklist

Maintain patched golden images for critical systems with recorded hashes.
Store images and snapshots where compromised administrator accounts cannot delete them.
Capture the compromised disk before reimaging.
Identify the initial access and dropper malware before rebuilding.
Restore to a new disk on an isolated segment.
Patch to baseline before reconnecting.
Rotate every credential and key held on the image.
Test rebuild times for critical hosts on a schedule.

D3-RDI Restore Disk Image: Rebuilding Hosts From Trusted Images