Software restored from the wrong source reinstalls the compromise you just removed. D3-RS Restore Software is the MITRE D3FEND countermeasure for putting software back on a host after it was tampered with, removed or replaced during an incident. D3FEND defines it as "Restoring software to a host", 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 gives no implementation article, so this card covers the practical questions: which source to trust, the repair and reinstall mechanisms operating systems provide, how to verify the restored software, and the limits. It is written for incident responders, endpoint and server engineers and the teams that run software distribution.
Key takeaways
- D3-RS returns software to a trusted state. It covers reinstalling or repairing applications, operating system components, add-ins, server modules and agents after tampering or removal.
- The source decides the outcome. Reinstall from signed vendor packages, a verified internal repository or a gold image, never from a copy on the compromised host.
- Supply chain cases need a different restore point. If the vendor package itself was compromised (T1195.002), restore a version the vendor has confirmed clean, not the latest one.
- D3FEND's ATT&CK links are inferred from the Software artefact. They point to where tampered software hides: add-ins, IIS modules, SQL stored procedures, installers, firmware and deployment tools.
- Verify with the platform's own integrity tools. Package manager verification, signature checks and component store scans show whether the restore worked.
D3-RS at a glance
| Field | D3-RS Restore Software |
|---|---|
| D3FEND ID | D3-RS |
| 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-RF Restore File |
| Digital artefact | Software (D3FEND: the technique "restores" Software) |
| D3FEND reference | CISA: Cybersecurity Incident and Vulnerability Response Playbooks (November 2021) |
| Typical trigger | Tampered binaries or modules, malicious add-ins or extensions removed during eradication, security agents uninstalled by an attacker, corrupted system components |
Restore Software is distinct from Software Update (D3-SU) in the Harden tactic: updating moves software forward to fix flaws, while restoring returns it to a known-good state. In practice a restore usually ends with the current patched version.
What CISA's playbook asks of a software restore
- Eradicate first: remove malicious code and account for every persistence mechanism; attackers often maintain several, so allow time to be sure.
- Rebuild from trusted sources: the playbook's eradication activities include rebuilding or reimaging systems, often from trusted gold images, and its checklist says to reimage affected systems from clean backups ("gold" sources). Hardware may need rebuilding where rootkits are involved.
- Patch and reset: install updates and patches and reset compromised credentials as part of the same phase.
- Test before production: test systems, including security controls, before returning them to operational use.
CISA's ransomware guide adds that golden images (preconfigured operating system and application templates) should be kept and regularly updated so systems can be rebuilt quickly, and infrastructure as code templates should be version-controlled and their backups kept offline. See the Server Build and Golden Image Hardening Guide.
ATT&CK techniques D3FEND relates to D3-RS
Relationship type: inferred only. D3FEND relates D3-RS to ATT&CK because these techniques act on the Software artefact, and states that the mappings "are inferred, experimental, and will improve as the knowledge graph grows" (checked November 2026). Restoring software does not prevent these techniques; it removes their effect when the restore source is clean. All IDs were checked against ATT&CK v20.
| ATT&CK ID | Technique | What the restore must address (NHI Mgmt Group assessment) |
|---|---|---|
| T1195.001 | Compromise Software Dependencies and Development Tools | Rebuild from a dependency set confirmed clean; a reinstall that pulls the same poisoned dependency repeats the compromise |
| T1195.002 | Compromise Software Supply Chain | Restore the version the vendor names as clean, or remove the product until one exists |
| T1072 | Software Deployment Tools | Check the deployment platform and its packages before using it to push restored software |
| T1554 | Compromise Host Software Binary | Replace altered binaries from signed packages and verify hashes afterwards |
| T1137.006 | Add-ins | Reinstall Office applications and remove unapproved add-ins from user and machine locations |
| T1505.004 | IIS Components | Compare installed IIS modules with the approved list before and after restoring the web server |
| T1505.001 | SQL Stored Procedures | Restore database code from source control, not from the compromised instance |
| T1574.005, T1574.010 | Executable Installer File Permissions Weakness; Services File Permissions Weakness | Reinstalling restores binaries but not always permissions; check folder and service binary ACLs |
| T1546.011 | Application Shimming | Remove unapproved shim databases; reinstalling the target application does not remove them |
| T1547.008 | LSASS Driver | Treat as a reimage case; component-level repair is not enough when authentication packages were altered |
| T1542.001, T1542.003 | System Firmware; Bootkit | Software reinstall does not reach firmware or boot code; reflash firmware from vendor images and rebuild |
| T1218.014, T1127.001 | MMC; MSBuild | Legitimate tools abused by the attacker; restore them unchanged and control their use instead |
The D3FEND page also lists, without IDs on the page, techniques such as Inhibit System Recovery (T1490), Service Stop (T1489) and Software Extensions (T1176), and further IDs including T1056.003 Web Portal Capture, T1497.003 Time Based Checks and T1564.006 Run Virtual Instance. Related guides: MITRE ATT&CK T1195 Supply Chain Compromise, MITRE ATT&CK T1072 Software Deployment Tools, MITRE ATT&CK T1137 Office Application Startup and T1505 Server Software Component Defensive Guide.
Where it is implemented
| Mechanism | What it restores | Verification it offers |
|---|---|---|
| Reimage from a gold image or infrastructure as code | The whole operating system and application stack | Image version and build record; rebuilt from a template under version control |
Windows System File Checker (sfc /scannow) | Protected Windows system files, replacing overwritten versions from the local cache or installation source | Scan result for protected files |
Windows DISM (/ScanHealth, /CheckHealth, /RestoreHealth) | The Windows component store that repairs draw on; /Source names a trusted repair source and /LimitAccess stops DISM using Windows Update | Image reported healthy, repairable or non-repairable (Microsoft says to discard a non-repairable image) |
Linux package managers (for example rpm -V and rpm --reinstall) | Files owned by installed packages | rpm -V compares size, digest, permissions, type, owner and group with the package database and flags each difference |
| Software distribution and endpoint management platforms | Applications and agents across many hosts | Deployment compliance reports; only as trustworthy as the platform itself |
| Container and serverless redeployment | Workloads, by redeploying signed images or packages from the registry | Image digest and signature checks at deploy time |
Two cautions. First, local repair sources sit on the host being repaired: if the attacker could write to them, use an offline repair source (DISM's /Source with /LimitAccess) or reimage. Second, the package database is itself on the host; rpm -V against a tampered database proves little, so compare with an external baseline where compromise was deep. Products are named to explain mechanisms, not recommended. See the Patch Management Guide and M1045 Code Signing.
Where identity fits
Software restores at scale run through deployment platforms whose service accounts and agents hold administrative rights on every managed host; ATT&CK tracks their abuse as T1072. Before using such a platform to push restored software, confirm its administrator accounts, API tokens and signing keys were not exposed, and rotate them if in doubt. Software that embeds credentials (agents with enrolment tokens, applications with service account passwords in configuration) also needs those secrets reissued after a reinstall. See Securing the patch management tool itself.
Implementation steps
- Keep trusted sources ready. Maintain current gold images, an internal repository of signed installers with recorded hashes, and offline repair sources for operating system components.
- Preserve evidence. Collect the tampered binaries, modules and add-ins before removal; they show what the attacker changed and help find the same changes elsewhere.
- Decide repair or rebuild. Repair in place (SFC, DISM, package reinstall) is acceptable for corruption or limited, well-understood tampering. Rebuild when the attacker had administrative or kernel-level access, altered authentication components, or the scope is unclear, as CISA's playbook favours reimaging from gold sources.
- Check the source for supply chain cases. Where the vendor product was the entry point, follow the vendor advisory for the clean version and any additional clean-up steps.
- Restore, then update. Install the clean version, apply current patches, and restore approved configuration from D3-RC Restore Configuration sources rather than from the compromised host.
- Pilot before fleet-wide rollout. When restoring software across many hosts, push to a small ring first and confirm function and integrity before widening.
- Keep rollback ready. Retain the previous clean package and image versions so a faulty restore can itself be reversed.
How to verify the restore
- Integrity: package verification output shows no unexpected differences; binary signatures validate; hashes match the internal repository records.
- Inventory: installed software, add-ins, browser extensions and server modules match the approved list for the host role.
- Security tooling: EDR and logging agents are installed, healthy and reporting before the host returns to production.
- Function: applications pass functional tests so there is no pressure to bypass controls.
- Watch period: monitor restored hosts for repeat tampering of the same files or modules; recurrence means persistence was missed.
| Metric (example, not a standard) | What it shows | Direction |
|---|---|---|
| Software restores sourced from signed or hash-verified packages | Trust in the restore source | Close to 100% |
| Gold images updated within the agreed patch window | Readiness to rebuild | Rising |
| Restored hosts passing package or signature verification | Restore effectiveness | Close to 100% |
| Hosts with the same tampering recurring within 30 days | Missed persistence or a tainted source | Falling |
| Time to rebuild a critical server from image | Recovery speed | Stable or falling |
Limits and failure patterns
- Repairing from a local, tainted source: the repair cache or package database on the host was altered, so the repair restores the attacker's version or reports a clean state that is false.
- Reinstalling over persistence: the application is restored but shims, scheduled tasks, services or add-ins that load it remain. Hunt for persistence before declaring the host clean.
- Software does not reach firmware: bootkits and firmware implants survive any operating system reinstall.
- Restoring the vulnerable version: a clean restore of the version that was exploited invites the same intrusion; restore and update together.
- Trusting a compromised deployment platform: using an attacker-controlled distribution tool to push "clean" software spreads the compromise.
- Stale gold images: images months behind on patches turn a fast rebuild into a long patch cycle under pressure.
Framework mapping
| Framework | Reference | Relationship to D3-RS |
|---|---|---|
| NIST SP 800-53 Rev. 5 | CP-10 System Recovery and Reconstitution | Returning systems to a known state |
| NIST SP 800-53 Rev. 5 | SI-7 Software, Firmware, and Information Integrity | Detecting unauthorised software changes and verifying restored software |
| NIST SP 800-53 Rev. 5 | CM-2 Baseline Configuration | The approved software baseline the restore returns to |
| NIST SP 800-53 Rev. 5 | CM-14 Signed Components | Requiring signed software before installation |
| NIST SP 800-53 Rev. 5 | SI-2 Flaw Remediation | Patching restored software to current versions |
| NIST CSF 2.0 | RC.RP-03 The integrity of backups and other restoration assets is verified before using them for restoration | Checking images and packages before use |
D3FEND cites only the CISA playbook for D3-RS; the NIST rows are NHI Mgmt Group's mapping by intent. For the mitigation view see M1051 Update Software.
Practitioner checklist
- Keep gold images current and rebuildable from version-controlled templates.
- Store signed installers with recorded hashes in a protected internal repository.
- Keep offline repair sources for operating system components.
- Preserve tampered binaries, modules and add-ins as evidence.
- Rebuild, not repair, when attackers had administrative or kernel-level access.
- Follow vendor advisories for supply chain incidents to pick the clean version.
- Patch immediately after restoring and verify signatures and package integrity.
- Confirm the deployment platform and its credentials are trustworthy before mass restore.
Standards and references
- MITRE D3FEND: Restore Software (D3-RS)
- CISA: Cybersecurity Incident and Vulnerability Response Playbooks (D3FEND reference)
- CISA: #StopRansomware Guide
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- Microsoft Learn: Repair a Windows image
- Microsoft Learn: System File Checker
- RPM: rpm(8) manual, verify and reinstall
Related NHI Mgmt Group resources: Server Build and Golden Image Hardening Guide · Patch Management Guide · D3-RF Restore File · MITRE D3FEND Guide