D3FEND Restore Tactic Guide: Bringing Systems and Access Back Safely

Recovery is where many incidents quietly restart: data comes back onto a host that was never rebuilt, or an account is unlocked while the stolen credential still works. MITRE D3FEND gives this step its own tactic, Restore, defined in one line: "The restore tactic is used to return the system to a better state." It is one of seven D3FEND tactics, alongside Model, Harden, Detect, Isolate, Deceive and Evict. This hub lists all 12 techniques D3FEND places under Restore, explains how its two families fit together, suggests where to start and in what order to run them, and shows which ATT&CK behaviours D3FEND relates to them. It is written for incident responders, recovery leads and identity teams. Each technique has its own page on this site with deployment detail; for D3FEND as a whole see the MITRE D3FEND Guide.

Key takeaways

• Two families, twelve techniques. Restore Object (D3-RO) brings back things: files, email, databases, software, configuration and disk images. Restore Access (D3-RA) gives back the ability to use them: credentials, accounts and network connectivity.
• Objects first, access last. Returning a user or a host to a platform that is still compromised hands the intruder back their foothold, so access restoration should follow verified object restoration.
• Restore mirrors Evict. Most Restore Access techniques undo a containment action: Unlock Account reverses Account Locking, Restore Network Access reverses host isolation, Reissue Credential follows Credential Revocation.
• A known good point is the hard part. Every Restore technique assumes a trusted copy, image, configuration baseline or identity proof. Without one, the technique cannot be performed safely.
• D3FEND's ATT&CK links here are inferred. The D3FEND site derives them from the artefacts each technique restores and marks them inferred and experimental; they show which attacker effects restoration can undo, not what it prevents.

What Restore means in D3FEND

D3FEND organises defensive techniques under seven tactics. The first six aim to understand, protect, find, contain, mislead or remove. Restore is different: it assumes something has already gone wrong and asks how to return systems, data and access to a trustworthy state. In the D3FEND ontology every Restore technique sits under one of two parent techniques that "enable" the tactic, Restore Access (D3-RA) and Restore Object (D3-RO). Their children are linked to digital artefacts through a single relation, "restores", which D3FEND defines as returning an entity to its known good or previous state.

That definition carries the main practical lesson. "Previous state" and "known good state" are not always the same thing. A backup taken after an attacker planted a web shell is a previous state, but not a known good one. Most failures in recovery come from treating the two as equivalent.

All eleven technique entries below the tactic in the ontology cite the same reference, the CISA Federal Government Cybersecurity Incident and Vulnerability Response Playbooks, developed under Section 6 of Executive Order 14028. Restore Object has no reference of its own. The playbooks place recovery inside the incident response lifecycle rather than as a separate continuity exercise, which is also how this page treats it. For the planning side of recovery see the Cybersecurity Event Recovery Guide.

Every technique in the tactic

The table lists every technique D3FEND places under Restore, with the hierarchy taken from the D3FEND ontology file. Definitions are summarised from D3FEND. The D3FEND website shows Unlock Account directly under Restore Access; in the ontology it is a subclass of Restore User Account Access, and this page follows the ontology.

For depth on each family, see the MITRE D3FEND Restore Object Implementation Guide and the MITRE D3FEND Restore Access Implementation Guide.

How the two families fit together

Each technique answers one trust question. Restore Object asks whether a thing can be trusted again: is this image, binary, setting, database or file clean? Restore Access asks whether an entity can be trusted again: is this secret still private, is this account still controlled by its owner, is this machine clean enough to rejoin the network? A real recovery nearly always needs answers to both.

Restore Object: from the platform up

Inside the object family the order follows dependency. A host's platform (disk image or software) has to be trusted before its configuration is meaningful, and configuration has to be trusted before data is loaded onto it.

• Platform: D3-RDI when the whole host is rebuilt from a golden image, or D3-RS when trusted binaries and packages are reinstalled from a verified source.
• Configuration: D3-RC returns registry keys, Group Policy, service settings, identity provider settings and cloud policies to a baseline. Attackers who disable logging or security tools leave their mark here, so this step is often where persistence hides.
• Data: D3-RD and D3-RF bring back structured and unstructured data to a recovery point chosen to predate the compromise. D3-RE is the mail case of D3-RF, with the added risk of redelivering the phishing message that started the incident.

Restore Access: from secrets out

Inside the access family the order follows exposure. A credential known to the attacker must be superseded before the account that uses it is re-enabled, and an account must be cleaned before a host it logs on to rejoins the network.

• Secrets: D3-RIC replaces passwords, keys, certificates, tokens and secrets in the compromise scope. Reissue should be paired with revocation of sessions and refresh tokens, otherwise the old access continues alongside the new.
• Accounts: D3-RUAA re-enables accounts disabled during containment or removed by the attacker; D3-ULA unlocks accounts locked by failed sign-ins or by a defensive lock. Both depend on verifying the person or owning team before access returns.
• Network: D3-RNA removes the isolation applied by EDR, network access control or firewall rules once the host has been rebuilt or verified.

The mirror with Evict and Isolate

Many Restore techniques are the reverse of a containment technique. That makes the containment record the best input to recovery: every lock, isolation and revocation applied during the incident is a restore task waiting to be closed deliberately.

See the D3FEND Evict Tactic and D3FEND Isolate Tactic hubs for the containment side.

Where to start and in what order

D3FEND does not prescribe a sequence. The order below is NHI Mgmt Group's recommendation, built from the dependencies described above and from NIST CSF 2.0 recovery outcomes.

1. Confirm eradication and scope. The entry point is closed and persistence is understood. Use credential compromise scope analysis to list every secret, account and workload identity that may be exposed; see D3-CCSA Credential Compromise Scope Analysis.
2. Choose and verify the recovery point. For each system, pick the image, backup or snapshot that predates the earliest evidence of compromise and check its integrity before use (CSF 2.0 RC.RP-03).
3. Restore identity infrastructure first. Directory services, identity providers, PAM and secrets platforms come before the applications that depend on them. For a domain compromise this includes the krbtgt reset sequence; see the krbtgt account guide.
4. Rebuild platforms, then configuration, then data. D3-RDI or D3-RS, then D3-RC, then D3-RD, D3-RF and D3-RE, in the business priority order your recovery plan sets.
5. Reissue credentials. D3-RIC across the compromise scope, with session and token revocation. For non-human identities, rotate in a way consumers can absorb (dual secrets or staged rollout).
6. Restore accounts, then network access. D3-RUAA and D3-ULA after identity verification; D3-RNA by tier, management systems first, user endpoints last.
7. Verify and hold. Confirm integrity of restored assets and normal operation (CSF 2.0 RC.RP-05), keep heightened monitoring for an agreed period, then close.

Rollback: restoration steps are themselves reversible. If indicators reappear on a restored host or identity, re-isolate or relock it, return to the previous step and choose an earlier recovery point. Record each restore with the recovery point used so a rollback does not repeat the same mistake.

Small and large organisations: a small organisation may run the whole sequence for a handful of systems in one day, and the risk is skipping verification under pressure. A large organisation needs the sequence written into runbooks per service, with a named owner for each restore step and a clean recovery environment to verify in; see the Cloud Recovery and Clean Room Guide.

ATT&CK behaviours D3FEND relates to Restore

The D3FEND site lists offensive techniques for each Restore technique as inferred and experimental relationships, derived because both sides touch the same digital artefacts (files, databases, configuration, software, accounts, credentials and hosts). The lists are long because almost any technique that changes those artefacts qualifies. The selection below shows where restoration undoes an attacker's effect. Restoration does not prevent these behaviours; it is the point at which you make sure their effects are gone. IDs are ATT&CK v20.

For the attacker side of recovery as a whole see the ATT&CK Impact Tactic Guide.

Where identity fits

Half of the Restore tactic is about identity, and the hardest cases are non-human. A service account password, an API key in a CI pipeline or a workload certificate cannot be reset by a help desk call: every consumer has to receive the new value, or the reissue breaks production and teams are tempted to roll back to the exposed secret. Inventory of which workloads use which secret is therefore a precondition for D3-RIC, not a nice-to-have. Backups also carry identity risk: a restored configuration or database can bring back an old secret, a deleted account or a role assignment the attacker added, so restored identity objects need the same review as restored files. For practical playbooks see the Workload Identity Compromise Response Playbook and Recovering IAM and PAM After Ransomware or Domain Compromise.

Human account restoration has a different weak point: the restore request itself. Attackers target the service desk to get accounts unlocked or MFA reset. Identity proofing belongs inside D3-RUAA and D3-ULA; see the Account Recovery and Help Desk Security Guide.

Verification and measurement

A restore is complete only when it is verified. Log and check the following.

• Backup and image integrity: hash or signature checks before use, and malware scanning of recovery points in an isolated environment.
• Configuration drift: comparison of restored settings against the approved baseline, with special attention to logging, security tool and identity provider settings.
• Identity events after restore: sign-ins on reissued credentials from unexpected sources, use of any superseded credential (it should fail), re-enable and unlock events with a matching ticket and verifier.
• Network events after reconnection: EDR and network telemetry on reconnected hosts for the monitoring period.

Example metrics (examples, not standards; set targets in your recovery plan):

For a structured test programme see the Restore Testing and Recovery Assurance Guide.

Framework mapping

Common failure patterns

• Restoring the attacker's persistence. A recovery point taken after initial access brings back the web shell, scheduled task or added role. Pick recovery points from the incident timeline, not from the most recent backup.
• Backups the attacker could reach. Backup consoles and service accounts in the same directory as production are deleted or encrypted along with it (T1490). See the Backup Security and Immutable Backup Guide.
• Access before objects. Users and hosts are reconnected to applications still being rebuilt, so the intruder's access comes back with them.
• Password reset without session revocation. D3-RIC applied to a password while refresh tokens, cookies and app passwords remain valid.
• Unproofed unlocks. The service desk unlocks or resets an account on a phone call during the incident, when pressure and volume are highest.
• Identity infrastructure last. Applications are restored while the directory or identity provider is still untrusted, so every restored system has to be revisited.

Practitioner checklist

• Map each D3FEND Restore technique to a named runbook and owner in your recovery plan.
• Record every containment action during an incident as a matching restore task.
• Define how a recovery point is chosen and how its integrity is checked before use.
• Keep backups, images and their admin identities out of reach of the production directory.
• Restore identity infrastructure before the applications that depend on it.
• Follow platform, configuration, data order for object restoration.
• Reissue credentials in scope, with session and token revocation, before re-enabling accounts.
• Maintain an inventory of which workloads consume which secrets, so non-human credentials can be reissued without outages.
• Require identity verification for every unlock and re-enable during and after an incident.
• Test restores on a schedule and track reinfections after recovery.

Standards and references

• MITRE D3FEND: Restore Tactic
• MITRE D3FEND: Restore Object
• MITRE D3FEND: Restore Access
• CISA: Cybersecurity Incident and Vulnerability Response Playbooks
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-184 Guide for Cybersecurity Event Recovery
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Impact

Related NHI Mgmt Group resources: MITRE D3FEND Guide · D3FEND Evict Tactic · Cybersecurity Event Recovery Guide · Identity Incident Response Playbook · Identity Recovery Guide