A database restore after an incident can bring back the attacker's changes, stale credentials or corrupt pages as easily as it brings back the data. D3-RD Restore Database is the MITRE D3FEND countermeasure for returning a database to a known-good state. D3FEND defines it as "Restoring the data in a database", 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. This card covers choosing the recovery point, restoring with the native tools of the main database engines, proving the restored data is complete and clean, and the limits of the technique. It is written for database administrators, backup teams and incident responders. Sibling techniques under Restore Object are D3-RF Restore File, D3-RS Restore Software, D3-RC Restore Configuration and D3-RDI Restore Disk Image.
Key takeaways
- D3-RD is about the data, not the server. The digital artefact is Database; rebuilding the host or the engine binaries is a separate step (D3-RDI, D3-RS).
- The recovery point is the main decision. Point-in-time recovery lets you stop just before the first malicious or destructive change, but only if you know when that was.
- A backup that reads cleanly is not a verified restore. Header and checksum checks do not prove the data structure or the business content is right.
- D3FEND's ATT&CK links are inferred and mostly about Windows Registry and password stores. D3FEND models those as kinds of database, so the mapping looks unusual for a DBA; read it with that in mind.
- Restoring a database also restores its accounts. Logins, roles and stored credentials come back as they were at the recovery point, including any rotated during the incident.
D3-RD at a glance
| Field | D3-RD Restore Database |
|---|---|
| D3FEND ID | D3-RD |
| Tactic | Restore ("used to return the system to a better state") |
| Parent technique | Restore Object (D3-RO), the broadest class for object restoral |
| Siblings | Restore Configuration (D3-RC), Restore Disk Image (D3-RDI), Restore File (D3-RF), Restore Software (D3-RS) |
| Digital artefact | Database (D3FEND: the technique "restores" a Database) |
| D3FEND reference | CISA: Cybersecurity Incident and Vulnerability Response Playbooks (November 2021) |
| Typical triggers | Ransomware encryption, destructive deletes or drops, unauthorised data changes, storage corruption |
| Main risk | Restoring to a point after the attacker's change, or into an environment the attacker still controls |
ATT&CK techniques D3FEND relates to D3-RD
Relationship type: inferred only. D3FEND has no direct ATT&CK mapping for D3-RD. Its technique page lists offensive techniques because they act on Database or one of its sub-classes, and states that these mappings "are inferred, experimental, and will improve as the knowledge graph grows" (checked November 2026). In the D3FEND ontology the sub-classes of Database include System Configuration Database (which covers the Windows Registry), Password Store, Password File, macOS Keychain and Code Repository. That is why most rows below are registry and credential-store techniques. All IDs were checked against ATT&CK v20.
| D3FEND artefact | ATT&CK techniques listed on the D3-RD page |
|---|---|
| Windows Registry and System Configuration Database | T1112 Modify Registry, T1012 Query Registry, T1207 Rogue Domain Controller, T1546.012 Image File Execution Options Injection, T1546.015 Component Object Model Hijacking, T1543.003 Windows Service, T1137.006 Add-ins, T1548.004 Elevated Execution with Prompt, T1552.002 Credentials in Registry, T1218.014 MMC, T1564.003 Hidden Window, T1564.005 Hidden File System, T1614.001 System Language Discovery |
| System Password Database and Password File | T1003.002 Security Account Manager, T1003.004 LSA Secrets, T1003.008 /etc/passwd and /etc/shadow, T1033 System Owner/User Discovery |
| Password Store and macOS Keychain | T1555.001 Keychain, T1555.002 Securityd Memory, T1555.003 Credentials from Web Browsers |
| Code Repository | T1213.003 Code Repositories (under T1213 Data from Information Repositories) |
For an application database, the techniques that create the need for a restore are impact techniques such as T1485 Data Destruction, T1486 Data Encrypted for Impact, T1565.001 Stored Data Manipulation (see T1565 Data Manipulation) and T1490 Inhibit System Recovery, which targets the backups themselves. D3FEND does not list these against D3-RD; this is NHI Mgmt Group's assessment of practical relevance.
Choosing the recovery point
| Restore type | What it gives you | When to choose it |
|---|---|---|
| Full backup only | The database as it was when the backup finished | The last clean full backup predates the incident and the data loss since then is acceptable |
| Full backup plus log replay to a time | The database at a chosen moment after the backup | You know when the destructive or malicious change happened and want to stop just before it |
| Full backup plus log replay to a named point or transaction | A precise stop before a known event | The bad transaction has been identified in the log |
| Logical export (dump) reload | Selected schemas or tables | Only some objects were damaged, or you need to extract data into a clean, rebuilt instance |
| Storage or volume snapshot | A crash-consistent or application-consistent copy of the data files | Fast whole-instance recovery where the snapshot was taken with the engine's backup mode or a supported integration |
Pick the recovery point from evidence, not from the newest backup. The attacker may have been present for weeks, so the newest backup can contain planted accounts, altered stored procedures or tampered rows. Where dwell time is unknown, restore to an isolated environment first and compare candidate points.
Where it is implemented
Database engines are listed alphabetically. Each provides native backup verification and point-in-time recovery; the table names the documented features to look for.
| Engine | Point-in-time recovery | Backup and restore verification |
|---|---|---|
| Microsoft SQL Server | Full backup restored WITH NORECOVERY, then transaction log backups applied with a STOPAT time or marked transaction | RESTORE VERIFYONLY checks the backup set is complete and readable, checks some page header fields and verifies the checksum where one is present on the media. Microsoft states it "does not attempt to verify the structure of the data", so run DBCC CHECKDB on the restored copy |
| MySQL | Restore the full backup, then replay binary logs with mysqlbinlog, selecting events by time or log position so the unwanted event is skipped. Binary logging is on by default in MySQL 8.4 | Review the decoded binary log before applying it; for encrypted binary logs read them from the server with --read-from-remote-server and a verified TLS mode |
| Oracle Database | RMAN restore and recover to a time, SCN or restore point | VALIDATE checks database files for physical and logical corruption; BACKUP ... VALIDATE CHECK LOGICAL adds logical checks; RESTORE DATABASE VALIDATE reads every block of the backups RMAN would use without writing files; RECOVER ... TEST runs a trial recovery in memory |
| PostgreSQL | Base backup (pg_basebackup) plus continuous WAL archiving; set restore_command and a stop point such as recovery_target_time or recovery_target_name, then create recovery.signal | The documentation tells you to test archiving before the first base backup and to check the restored database reached the intended state. pg_dump output cannot be used for point-in-time recovery |
Managed cloud database services wrap the same mechanisms in automated backups and point-in-time restore to a new instance. Restoring to a new instance, rather than over the damaged one, keeps the original for investigation. For engine hardening see the Database Security Guide.
Where identity fits
A restored database brings back its own identity store: database logins, roles, application service accounts and any credentials held in tables. If credentials were rotated during containment, the restore reverts them to the pre-rotation values, and accounts the attacker created before the recovery point return too. After the restore, compare logins and role grants with an approved baseline, rotate application and service account credentials again, and confirm connection strings in the applications match. See How to audit SQL Server service accounts and logins. PostgreSQL also notes that its WAL archive holds the whole cluster and must be protected from group or world read access, which matters because the archive contains credential tables.
Implementation steps
- Preserve first. Copy the damaged data files and logs before overwriting anything; they are evidence and a fallback. PostgreSQL's own procedure starts by saving the existing data directory and WAL where space allows.
- Restore into isolation. Use a separate instance on a clean network segment. CISA's ransomware guidance tells responders to prioritise critical systems for restoration on a clean network and to take care not to re-infect clean systems.
- Choose and test the recovery point. Use log review and incident timeline evidence to set the stop point, and keep the next earlier point ready in case the first is contaminated.
- Verify integrity. Run the engine's structural checks (DBCC CHECKDB, RMAN VALIDATE, or the equivalent) on the restored copy, not only on the backup file.
- Verify content. Row counts and checksums against reference tables, application smoke tests, and review of objects that attackers alter: stored procedures, triggers, scheduled jobs and linked server definitions.
- Reset identity. Remove unknown logins, re-apply least privilege and rotate credentials, then update dependent applications.
- Cut over with a rollback path. Keep the damaged copy and the restore candidate until the application owners sign off; rollback is switching the connection back or restoring the next earlier point.
How to verify the restore
| Metric (example, not a standard) | What it shows | Direction |
|---|---|---|
| Critical databases with a successful test restore in the last quarter | Restores are practised, not assumed | 100% |
| Measured restore time against the agreed recovery time objective | Whether the objective is realistic | Within target |
| Actual data loss window against the recovery point objective | Log backup or archiving gaps | Within target |
| Restores followed by a structural integrity check with zero errors | Corruption is caught before cutover | 100% |
| Restored databases with logins reconciled and credentials rotated | Identity hygiene after restore | 100% |
Monitor the backup chain continuously as well: archive or log backup failures, gaps in sequence numbers and backup deletions. PostgreSQL warns that if archiving falls behind, the WAL directory grows until the disk fills and the server shuts down. For a test programme see the Backup and Recovery Testing Checklist.
Limits and failure patterns
- Backups destroyed with the database: attackers look for reachable backups to delete or encrypt. CISA advises offline, encrypted backups with regular tests of availability and integrity. See the Backup Security and Immutable Backup Guide.
- Broken log chain: a missing log or WAL segment ends point-in-time recovery at the gap, often far earlier than wanted.
- Restoring the attacker's state: a recovery point after a planted trigger, job or account brings the persistence back.
- Verifying the file, not the data: a readable backup with valid checksums can still hold logically wrong or tampered rows.
- Configuration left behind: PostgreSQL notes that postgresql.conf, pg_hba.conf and pg_ident.conf are not in WAL and need their own backup; the same applies to other engines' server settings. See D3-RC Restore Configuration.
- Restoring over the only copy: overwriting the damaged database removes evidence and the option to try a different point.
Framework mapping
| Framework | Reference | Relationship to D3-RD |
|---|---|---|
| NIST SP 800-53 Rev 5 | CP-9 System Backup, CP-10 System Recovery and Reconstitution | Backing up and restoring system and user data |
| NIST SP 800-53 Rev 5 | CP-4 Contingency Plan Testing | Test restores |
| NIST SP 800-53 Rev 5 | SI-7 Software, Firmware, and Information Integrity | Integrity checks on restored data |
| NIST SP 800-184 | Guide for Cybersecurity Event Recovery | Recovery planning, playbooks and testing |
| MITRE ATT&CK mitigation | M1053 Data Backup | Closest in intent |
D3FEND cites only the CISA playbook for D3-RD; the other rows are NHI Mgmt Group's mapping by intent.
Practitioner checklist
- Keep at least one backup copy offline or immutable, with its own credentials.
- Monitor log backup or WAL archiving for gaps and failures.
- Preserve the damaged database before restoring.
- Restore to an isolated instance and choose the recovery point from incident evidence.
- Run a structural integrity check on every restored copy.
- Review triggers, procedures, jobs and logins for attacker changes.
- Rotate database and application credentials after the restore.
- Back up server configuration files separately from the data.
- Test restores of critical databases on a schedule and record the times.
Standards and references
- MITRE D3FEND: Restore Database (D3-RD)
- CISA: Cybersecurity Incident and Vulnerability Response Playbooks (D3FEND reference)
- CISA: #StopRansomware Guide
- NIST: SP 800-184 Guide for Cybersecurity Event Recovery
- Microsoft: RESTORE VERIFYONLY (Transact-SQL)
- MySQL: Point-in-Time Recovery Using Binary Log
- Oracle: Validating Database Files and Backups
- PostgreSQL: Continuous Archiving and Point-in-Time Recovery
Related NHI Mgmt Group resources: MITRE D3FEND Guide · Database Security Guide · M1053 Data Backup · D3-RF Restore File