Restoring a file is easy; restoring the right, clean version of it without bringing the attacker's changes back is not. D3-RF Restore File is the MITRE D3FEND countermeasure for putting files back after they were deleted, encrypted, tampered with or evicted during an incident. D3FEND defines it as "Restoring a file for an entity to access", places it in the Restore tactic under Restore Object (D3-RO) and cites CISA's Cybersecurity Incident and Vulnerability Response Playbooks as its only reference. D3FEND publishes no implementation article for it, so this card is practical: choosing the restore point, the restore mechanisms that exist, how to prove the restored file is the one you meant, and what goes wrong. It is written for incident responders, backup and storage administrators and endpoint engineers.
Key takeaways
- D3-RF reverses file damage. It covers restoring files that an attacker deleted, encrypted or altered, and files that defenders removed or quarantined during eradication.
- The restore point is the security decision. A version taken after the intrusion began can carry web shells, altered scripts or planted DLLs straight back into production.
- D3FEND's ATT&CK links are inferred from the File artefact. They span almost every tactic, because nearly every technique reads, writes or deletes a file; treat them as a list of things to check before restoring, not as techniques the restore stops.
- Verify by hash and content, not by file name. Compare restored files with known-good hashes or package manifests and scan them before users regain access.
- Keep the attacker's copy. Preserve the damaged or malicious version as evidence before overwriting it with the restored one.
D3-RF at a glance
| Field | D3-RF Restore File |
|---|---|
| D3FEND ID | D3-RF |
| Tactic | Restore |
| Parent technique | Restore Object (D3-RO): "Restoring an object for an entity to access. This is the broadest class for object restoral." |
| Siblings under Restore Object | D3-RC Restore Configuration, D3-RD Restore Database, D3-RDI Restore Disk Image, D3-RS Restore Software |
| Child technique | D3-RE Restore Email sits under Restore File |
| Digital artefact | File (D3FEND: the technique "restores" a File) |
| D3FEND reference | CISA: Cybersecurity Incident and Vulnerability Response Playbooks (November 2021) |
| Reverses | Attacker deletion, encryption or modification; defender actions such as D3-FEV File Eviction and quarantine |
What CISA's playbook asks of a file restore
CISA's playbook does not give a file restore procedure, but its eradication and recovery phase sets the conditions any D3-RF action has to meet:
- Persistence first: before eradication, account for all persistent access paths, confirm containment and collect evidence. Attackers often keep several backdoors, so allow time to be confident systems are clean.
- Clean sources: the eradication activities include replacing infected files with clean copies, and the checklist asks responders to reimage affected systems from clean backups ("gold" sources).
- Test before production: test restored systems, including their security controls, before returning them to operational use, and watch them closely afterwards.
CISA's ransomware guide adds the warning that matters most for files: care must be taken to identify dropper malware before rebuilding from backups, and backups should be kept offline and encrypted because many ransomware variants look for and delete or encrypt accessible backups. See the Ransomware Response and Recovery Guide for the wider sequence.
ATT&CK techniques D3FEND relates to D3-RF
Relationship type: inferred only. D3FEND relates D3-RF to ATT&CK because the techniques act on the File artefact, and states that these mappings "are inferred, experimental, and will improve as the knowledge graph grows" (checked November 2026). The list runs to dozens of techniques across most tactics, so it is grouped here by tactic with representative IDs. Restoring a file does not prevent any of them; the relation tells you which file changes to look for when choosing and checking a restore point. All IDs were checked against ATT&CK v20.
| Tactic | Examples D3FEND lists (ATT&CK v20) | What to check before restoring (NHI Mgmt Group assessment) |
|---|---|---|
| Persistence | T1505.003 Web Shell, T1547.001 Registry Run Keys / Startup Folder, T1543.002 Systemd Service, T1037.001 Logon Script (Windows), T1137.001 Office Template Macros, T1546.008 Accessibility Features | Do not restore web roots, startup folders, unit files, logon scripts or templates from a point after first attacker activity without diffing them |
| Stealth | T1036.005 Match Legitimate Resource Name or Location, T1036.006 Space after Filename, T1036.003 Rename Legitimate Utilities, T1070.004 File Deletion, T1027.002 Software Packing, T1574.001 DLL | A file with the right name in the right folder can still be the attacker's; check hashes and signatures, and look for planted DLLs beside restored executables |
| Credential access | T1552.001 Credentials In Files, T1555.003 Credentials from Web Browsers, T1003.008 /etc/passwd and /etc/shadow | Restoring a config file restores the secrets in it; rotate any credential the attacker could have read |
| Collection | T1005 Data from Local System, T1074.001 Local Data Staging, T1119 Automated Collection, T1560.001 Archive via Utility, T1114.001 Local Email Collection | Staged archives in backups show what was taken; keep them as evidence and exclude them from the restore |
| Discovery | T1083 File and Directory Discovery | Use the attacker's discovery activity to scope which shares and folders need checking |
| Execution and lateral movement | T1204.002 Malicious File, T1072 Software Deployment Tools | Restoring a share that held a malicious document or a deployment package can re-run the intrusion |
| Impact | T1565.001 Stored Data Manipulation, T1486 Data Encrypted for Impact | Identify when manipulation started; the newest clean version may be older than the encryption date |
D3FEND's list also includes several IDs that ATT&CK v20 has revoked or deprecated (for example the DLL Side-Loading sub-technique, now covered by T1574.001 DLL); use the current IDs. Related technique guides: T1070 Indicator Removal, T1036 Masquerading, T1505 Server Software Component and MITRE ATT&CK T1486 Data Encrypted for Impact.
Where it is implemented
| Mechanism | How a file is restored | Security consideration |
|---|---|---|
| Backup software (agent or image based) | Granular file restore from a selected backup set, to the original or an alternate location | Restore to an alternate, isolated location first and scan; backup consoles and their service accounts are high-value targets |
| Windows Volume Shadow Copy Service (VSS) | Previous Versions and Shadow Copies of Shared Folders let users and administrators recover earlier file versions | Microsoft states a shadow copy is not a backup on its own; copies live on the host, are deleted automatically when the diff area fills and can be removed with VssAdmin |
| Object storage versioning (for example Amazon S3 Versioning) | Copy a previous version over the current one, or remove the newer version or delete marker | AWS recommends copying the previous version so all versions are preserved; combine versioning with object lock or retention so versions cannot be purged |
| File sync and collaboration platforms | Version history and recycle bins at file, folder or library level | Retention periods are finite; mass restores need the platform's bulk restore feature, and the account used must be checked before acting |
| Storage array or NAS snapshots | Mount a snapshot or copy files out of a read-only snapshot directory | Snapshots on the same array as production share its administrative plane; see the NAS Ransomware Playbook |
| EDR and anti-malware quarantine | Release a quarantined file back to its original path | Release only after analysis confirms a false positive, and add a narrow exclusion by hash, not by path |
| Source control and package repositories | Check out a known commit or reinstall a signed package | Often the cleanest source for scripts and code; confirm the repository itself was not altered |
Mechanisms and products are listed as categories, not recommendations. For backup architecture see the Backup Security and Immutable Backup Guide and M1053 Data Backup.
Where identity fits
File restores run with powerful machine identities: backup service accounts, snapshot API keys, storage administrator roles and the credentials sync platforms use for bulk restore. Attackers who reach these identities can delete the versions you were going to restore from, which is why ransomware operators target backup consoles. Restored configuration files also bring back whatever secrets they contained. Separate the backup administration identities from the production directory, require MFA on restore actions, and rotate any API key, password or certificate found in a restored file the attacker could have read. See the Backup Identity Isolation Guide.
Implementation steps
- Set restore criteria in advance. Define who can approve a production restore, how far back retention goes for each data class, and the evidence needed before overwriting live files.
- Preserve the damaged state. Copy or snapshot the encrypted, modified or malicious files and their metadata before restoring over them; investigators need timestamps and content.
- Establish the clean point. Use the incident timeline to find the earliest attacker activity on the affected system, then choose a version from before it. Where only later versions exist, restore them to quarantine and diff against an older baseline.
- Restore to an isolated location first. Restore into a separate share, bucket or VLAN, scan it with current signatures, compare hashes and review high-risk file types (scripts, executables, DLLs, macros, web content).
- Promote in priority order. Move verified files back into production in order of business criticality, as CISA's ransomware guide recommends for systems and data, keeping a log of what was restored, from which version, by whom.
- Rotate exposed secrets. Rotate credentials found in restored files and confirm dependent services pick up the new values.
- Keep rollback ready. The rollback for a bad restore is another restore: keep the pre-restore copy until the restored data has been in use and monitored for the agreed period.
How to verify the restore
- Integrity: compare hashes of restored executables, scripts and libraries with known-good values (vendor manifests, package databases, source control or a baseline taken before the incident).
- Content: scan restored files with up-to-date anti-malware and, for web roots and script folders, diff against the last known-good release.
- Completeness: reconcile file counts and sizes with the backup catalogue; check that permissions and ownership came back as expected, since a restore can reset access control lists.
- Behaviour: watch file integrity monitoring and EDR telemetry on restored paths for the following days; unexpected writes to restored startup or web folders are a sign the attacker is still present.
- Restore tests: run scheduled restore tests outside incidents, as CISA advises testing the availability and integrity of backups; see the Backup and Recovery Testing Checklist.
| Metric (example, not a standard) | What it shows | Direction |
|---|---|---|
| Restores performed to an isolated location before promotion | Discipline of the restore process | Close to 100% for incident restores |
| Restored executable and script files verified by hash | Integrity checking coverage | Rising |
| Scheduled restore tests that met the recovery time objective | Whether backups are usable in practice | Rising |
| Restored paths re-infected or re-modified within 30 days | Restores from a compromised point or incomplete eradication | Falling |
| Critical data classes with an offline or immutable copy | Resistance to backup deletion | 100% of in-scope classes |
Limits and failure patterns
- Restoring the backdoor: the chosen version postdates the intrusion and carries a web shell, a modified script or a planted DLL. Choose by timeline, not by "latest good-looking backup".
- Shadow copies treated as backups: they sit on the same host and can be deleted by anyone with administrative rights; ATT&CK tracks this behaviour under T1490 Inhibit System Recovery. See T1490 Inhibit System Recovery Defensive Guide.
- Retention shorter than dwell time: if attackers were present longer than the oldest retained version, there is no clean restore point; size retention to realistic dwell times for critical data.
- Overwriting evidence: restoring in place destroys the modified files investigators needed.
- Permissions lost or widened: a restore that drops or flattens access control lists turns a recovery into a data exposure.
- Backup identities compromised: the attacker deletes versions and snapshots through the backup console before encrypting production.
Framework mapping
| Framework | Reference | Relationship to D3-RF |
|---|---|---|
| NIST SP 800-53 Rev. 5 | CP-9 System Backup | Backups that make file restore possible |
| NIST SP 800-53 Rev. 5 | CP-10 System Recovery and Reconstitution | Returning systems and data to a known state |
| NIST SP 800-53 Rev. 5 | IR-4 Incident Handling | Eradication and recovery as part of incident handling |
| NIST CSF 2.0 | RC.RP Incident Recovery Plan Execution | Executing restoration activities |
| NIST CSF 2.0 | PR.DS-11 Backups of data are created, protected, maintained, and tested | The precondition for any file restore |
| NIST SP 800-184 | Guide for Cybersecurity Event Recovery (December 2016) | Recovery planning, playbooks, testing and metrics |
D3FEND cites only the CISA playbook for D3-RF; the NIST rows are NHI Mgmt Group's mapping by intent.
Practitioner checklist
- Define restore approvers, retention per data class and pre-restore evidence steps.
- Keep at least one offline or immutable copy of critical data.
- Preserve damaged and malicious files before restoring over them.
- Choose restore points from the incident timeline, before first attacker activity.
- Restore to an isolated location, scan and hash-check before promotion.
- Review restored web roots, startup folders, scripts and DLLs for planted changes.
- Rotate secrets found in restored configuration files.
- Separate and protect backup administration identities with MFA.
- Test restores on a schedule and track recovery time against objectives.
Standards and references
- MITRE D3FEND: Restore File (D3-RF)
- CISA: Cybersecurity Incident and Vulnerability Response Playbooks (D3FEND reference)
- CISA: #StopRansomware Guide
- NIST: SP 800-184 Guide for Cybersecurity Event Recovery
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- Microsoft Learn: Volume Shadow Copy Service
- AWS: Restoring previous versions in Amazon S3
Related NHI Mgmt Group resources: Ransomware Response and Recovery Guide · Backup Security and Immutable Backup Guide · D3-RNA Restore Network Access · MITRE D3FEND Guide