Most recovery programmes can restore a file or a server, yet few can say in what order to restore software, configuration, data and images, or how to prove that what came back is clean. MITRE D3FEND groups these activities under Restore Object (D3-RO), which it calls "the broadest class for object restoral" and places in the Restore tactic. This guide treats D3-RO as a programme: what each child technique restores, how to choose and combine them, the order that avoids reinfection, how to verify a restore, and where the family meets the attack behaviours D3FEND relates to it. It is written for recovery leads, infrastructure owners and incident responders. Each child technique has its own page on this site with deployment detail; this page does not repeat them. For D3FEND itself see the MITRE D3FEND Guide, and for the attacker side of recovery see the ATT&CK Impact Tactic Guide.
Key takeaways
- D3-RO is a family, not a single control. D3FEND defines it as restoring an object for an entity to access, with five direct children (configuration, database, disk image, file, software) and Restore Email beneath Restore File.
- Order matters more than tooling. Restoring data onto an unrebuilt host, or software with poisoned configuration, brings the intruder back with the business.
- Every restore needs a known good point. The hard question is not "can we restore" but "which copy predates the compromise and is still intact".
- Verification is part of the technique. NIST CSF 2.0 RC.RP-03 and RC.RP-05 ask for backup integrity to be checked before use and restored assets to be checked after.
- D3FEND's ATT&CK links are inferred. The D3FEND site marks the offensive relationships for D3-RO as inferred and experimental, derived from the objects the children restore.
What D3FEND means by Restore Object
In the D3FEND ontology D3-RO is a defensive technique that enables the Restore tactic. Its definition is short: restoring an object for an entity to access. The parent carries no digital artefact relation of its own; the relations sit on the children, which each "restore" a specific artefact (a configuration resource, a database, a file, software). The D3FEND site derives the family's related ATT&CK techniques from those artefacts.
Restore Object is the companion to Restore Access (D3-RA), the other Restore family, which returns an entity's ability to use resources (credentials, accounts and network access) rather than the resources themselves. In a real recovery you run both: objects come back first, and access is returned once the objects are trusted. See the MITRE D3FEND Restore Access Implementation Guide.
The child techniques
The table lists every child of D3-RO in the D3FEND ontology, with the artefact D3FEND says it restores and its practical purpose. The D3FEND site counts the family as seven techniques including the parent.
| D3FEND technique | D3FEND definition (summary) | Artefact restored | Practical purpose |
|---|---|---|---|
| D3-RDI Restore Disk Image | Restoring a previously captured disk image to a hard drive | Disk image (no explicit relation in the ontology) | Rebuild a host wholesale from a trusted image |
| D3-RS Restore Software | Restoring software to a host | Software | Reinstall trusted binaries and packages from a verified source |
| D3-RC Restore Configuration | Restoring a software configuration | Configuration resource | Return settings, registry keys, policies and IdP or cloud configuration to a trusted baseline |
| D3-RD Restore Database | Restoring the data in a database | Database | Recover structured data to a clean recovery point |
| D3-RF Restore File | Restoring a file for an entity to access | File | Recover unstructured data from backups or snapshots |
| D3-RE Restore Email (child of D3-RF) | Restoring email for an entity to access | Email (a file subtype) | Return deleted or quarantined mail without re-delivering the threat |
Choosing and combining the children
The children are not alternatives. Which ones you run depends on how deep the compromise went and on what you can still trust.
| Situation | Usual combination | Why |
|---|---|---|
| Ransomware encrypted file shares, hosts intact and clean | D3-RF, then D3-RD for affected databases | Data is the loss; the platform still holds |
| Host persistence found (run keys, services, web shell) | D3-RDI or D3-RS, then D3-RC, then data | Cleaning in place leaves uncertainty; rebuild the platform first |
| Disk wipe or destroyed boot records | D3-RDI, then D3-RC, then D3-RF and D3-RD | Nothing on the host survives to clean |
| Tampered settings only (logging off, security tools disabled, policy changes) | D3-RC | Restoring the baseline is faster than a rebuild if no code was planted |
| Data manipulated rather than destroyed | D3-RD or D3-RF to a point before the change | Requires finding when the first unauthorised change happened |
| Mailbox deletion or a bulk purge that removed legitimate mail | D3-RE | Mail-specific retention and recovery features apply |
A useful rule, which is our view at NHI Mgmt Group rather than D3FEND's: if you cannot explain how the intruder got persistence on a host, restore the host (D3-RDI or D3-RS plus D3-RC) instead of restoring files onto it.
Sequencing a restore
NIST SP 800-184, the Guide for Cybersecurity Event Recovery, asks organisations to plan recovery around ranked critical resources and to build playbooks for it. Applied to D3-RO, the order below avoids the most common reinfection paths. It is our recommended sequence, not one D3FEND prescribes.
- Establish the clean point. From the investigation timeline, find the earliest evidence of compromise and pick recovery points before it. For identity platforms this includes backups of IdP configuration; see the IdP configuration backup and restore for Entra ID and Okta.
- Verify the restoration assets first. Check backup integrity, immutability and that the backup system itself was not touched (CSF 2.0 RC.RP-03). See the Backup Security and Immutable Backup Guide.
- Rebuild the platform. D3-RDI from a trusted golden image or D3-RS from verified installation sources, in an isolated recovery network.
- Restore configuration. D3-RC from a version-controlled baseline, then compare against the pre-incident baseline for drift the attacker introduced.
- Restore data. D3-RD and D3-RF, scanning restored content before it is exposed to users. D3-RE last for mail, after mail flow controls are back.
- Hand over to access restoration. Only then reissue credentials, unlock accounts and reconnect hosts under D3-RA.
Rollback: keep the pre-restore state (or a snapshot of the compromised system) preserved as evidence and as a fallback, so a failed restore does not destroy both the evidence and the last working copy.
How to verify a restore worked
- Integrity: compare file and image hashes with values recorded at backup time; for software, verify signatures and package manager checksums.
- Configuration: diff restored settings against the version-controlled baseline; confirm logging, endpoint protection and audit policy are on.
- Data: application-level checks (row counts, checksums, business reconciliation) for databases; spot checks for file shares.
- Cleanliness: scan restored hosts and content for the indicators found during the investigation before reconnecting them.
- Function: the service owner signs off that the business process works, which is the "normal operating status" in CSF 2.0 RC.RP-05.
Test all of this before an incident. See the Restore Testing and Recovery Assurance Guide and the CIS Control 11 Data Recovery Guide.
ATT&CK behaviours D3FEND relates to Restore Object
D3FEND lists the related offensive techniques for D3-RO as inferred and experimental, derived because the children restore configuration, files, software and databases. The list is long because almost any technique that writes to those artefacts qualifies. The selection below, using ATT&CK v20 IDs that also appear on the child pages, shows where restoration undoes the attacker's effect. Restoration reverses damage after the fact; it does not prevent the behaviour.
| ATT&CK technique | Most relevant child | What restoration undoes |
|---|---|---|
| T1486 Data Encrypted for Impact | D3-RF, D3-RD, D3-RDI | Encrypted data replaced from clean copies |
| T1485 Data Destruction | D3-RF, D3-RD | Deleted data returned |
| T1561 Disk Wipe | D3-RDI | Wiped volumes rebuilt from images |
| T1490 Inhibit System Recovery | All children, if backups survived | Recovery depends on copies the attacker could not reach |
| T1565.001 Stored Data Manipulation | D3-RD, D3-RF | Data rolled back to before the change |
| T1547.001 Registry Run Keys / Startup Folder | D3-RC | Autostart entries returned to baseline |
| T1505.003 Web Shell | D3-RS, D3-RF | Server files replaced from a trusted build |
See the MITRE ATT&CK T1486 Data Encrypted for Impact and T1490 Inhibit System Recovery Defensive Guide pages for those behaviours in depth.
Where identity fits
Restores are run by backup service accounts, snapshot roles and automation pipelines. If an attacker holds those identities, they can delete the recovery points (T1490) or plant changes that you then restore faithfully. Keep backup and recovery identities separate from the production directory, give restore permissions only to the recovery role, and require approval for deletion of recovery points. Restored configuration can also bring back old secrets embedded in it, so treat any credential inside a restored object as compromised until reissued. See the Backup Identity Isolation Guide and Recovering IAM and PAM After Ransomware or Domain Compromise.
Detection and measurement
Monitor the recovery estate as closely as production: deletion or retention changes on backups, new restore jobs outside a declared incident or test, and access to backup consoles from unusual identities. Metrics we suggest at NHI Mgmt Group (example targets, not standards):
- Child coverage: percentage of critical services with a documented, tested path for each relevant D3-RO child.
- Restore test success rate: percentage of scheduled restore tests that met integrity and function checks.
- Measured recovery time against the agreed recovery time objective, per tier.
- Recovery point age: age of the newest verified clean copy for each critical system.
- Reinfection rate: restored systems that showed the same indicators again within 30 days.
- Immutable coverage: percentage of critical backups held in immutable or offline storage.
Framework mapping
| Framework | Reference | Link to D3-RO |
|---|---|---|
| NIST CSF 2.0 | PR.DS-11, RC.RP-01, RC.RP-03, RC.RP-05 | Backups maintained and tested; recovery executed; integrity checked before and after |
| NIST SP 800-53 Rev. 5 | CP-9 System Backup, CP-10 System Recovery and Reconstitution, CP-4 Contingency Plan Testing | The control basis for every child technique |
| NIST SP 800-53 Rev. 5 | IR-4 Incident Handling | Recovery as part of incident handling |
| NIST SP 800-184 | Cybersecurity event recovery planning | Playbooks, prioritisation and testing |
| CIS Controls v8.1 | Control 11 Data Recovery | Backup, protection and recovery testing |
| MITRE D3FEND | D3-RA Restore Access | The other Restore family, run after objects are trusted |
Common failure patterns
- Restoring data onto an unrebuilt host. Files come back clean and the persistence mechanism re-encrypts them.
- Picking the newest backup by default. The newest copy often postdates the intrusion and contains its changes.
- Backups reachable from the production directory. One compromised domain admin deletes production and recovery together. The Ransomware Response and Recovery Guide covers this pattern.
- Configuration left out of backup scope. Data restores, but nobody holds a copy of firewall rules, group policy or IdP settings.
- No verification step. A restore job reporting success is taken as proof that the data is complete and clean.
- Treating inferred mappings as coverage. D3FEND's ATT&CK list is a set of test ideas, not evidence that restoration works for each technique.
Practitioner checklist
- Map each critical service to the D3-RO children it needs and a named owner for each.
- Bring configuration (including IdP and cloud settings) into backup scope under version control.
- Keep immutable or offline copies and isolate backup identities from production.
- Write the restore sequence into playbooks: clean point, verify assets, platform, configuration, data, then access.
- Record hashes and baselines at backup time so restores can be verified.
- Scan restored content for investigation indicators before reconnecting.
- Run scheduled restore tests and report success rate and recovery time against objectives.
- Hand over to the Restore Access family only after restored objects are verified.
Standards and references
- MITRE D3FEND: Restore Object
- MITRE D3FEND: Restore Access
- NIST: SP 800-184 Guide for Cybersecurity Event Recovery
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
- CISA: Cybersecurity Incident and Vulnerability Response Playbooks
- MITRE ATT&CK: Inhibit System Recovery
Related NHI Mgmt Group resources: MITRE D3FEND Guide · ATT&CK Impact Tactic Guide · Cybersecurity Event Recovery Guide · Restore Testing and Recovery Assurance Guide · AWS Backup Security Guide