After an intrusion, many of the attacker's footholds are not files or binaries but settings: a new autostart registry value, a disabled log, a weakened firewall rule, a mail forwarding rule or a loosened conditional access policy. MITRE D3FEND names the countermeasure that puts those settings back Restore Configuration (D3-RC) and defines it as "Restoring an software configuration." It sits under the Restore tactic as a child of Restore Object (D3-RO), and restores the Configuration Resource artefact, which D3FEND defines as "A resource used to configure a system including software and hardware." D3FEND's entry is short, so this card adds the practical parts: what to restore from, how to avoid restoring the attacker's changes, how to prove the restore worked and where it falls short. It is for incident responders, platform owners and recovery leads, and builds on the Cybersecurity Event Recovery Guide.
Key takeaways
- Restore from a known-good baseline. A configuration restore is only as clean as its source: a versioned baseline or backup captured before the intrusion and verified, not the latest export from a compromised system.
- Configuration is where persistence hides. D3FEND relates D3-RC, by inference through the Configuration Resource artefact, to autostart entries, event-triggered execution, logging and firewall tampering, Office and mail rules, authentication changes and cloud compute settings.
- Restore is not remediation on its own. Putting settings back does not remove the access path the attacker used to change them; credentials and the entry point still need eviction.
- Use confirmed, reversible changes. Platform features such as timed rollback on network devices and scoped GPO restore let you recover quickly while keeping a way back if the restore breaks service.
- Verify by comparison, then by behaviour. A restore is done when the live configuration matches the baseline and the security functions it controls (logging, firewall, authentication policy) are shown to work.
D3-RC at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-RC (d3f:RestoreConfiguration) |
| Tactic | Restore |
| Parent technique | Restore Object (D3-RO), "the broadest class for object restoral" |
| Siblings under Restore Object | Restore Database (D3-RD), Restore Disk Image (D3-RDI), Restore File (D3-RF), Restore Software (D3-RS); Restore Email (D3-RE) sits under Restore File |
| Digital artefact | Configuration Resource (D3FEND relation: restores) |
| D3FEND reference | CISA Federal Government Cybersecurity Incident and Vulnerability Response Playbooks |
| Typical sources of truth | Configuration management repositories, infrastructure as code, directory policy backups, network device configuration archives, identity provider configuration exports |
| Main limitation | Restores what was baselined; settings never captured, or captured after compromise, are not recovered |
What D3-RC covers in practice
Configuration Resource is broad: it covers any resource that configures software or hardware. In practice the restore targets fall into a few groups, each with its own source of truth and restore mechanism.
| Configuration class | Examples | Typical source of truth |
|---|---|---|
| Operating system settings | Registry autostart values, services, audit policy, host firewall, startup scripts, launch daemons | Configuration management baselines, golden images, policy objects. See the Configuration Drift and Baseline Enforcement Guide |
| Directory and domain policy | Group Policy Objects, domain trust and policy settings | GPO backups held outside the domain. See the Group Policy Security Guide |
| Identity provider and SaaS tenant settings | Conditional access policies, federation settings, application consent, mail transport and forwarding rules | Exported tenant configuration under version control. See IdP configuration backup and restore for Entra ID and Okta |
| Cloud control plane | Security groups, cloud firewall rules, logging configuration, instance and compute settings | Infrastructure as code repositories and configuration recording services |
| Network devices | Router, switch and firewall running configurations | Device configuration archives held off-device |
| Application configuration | Application settings files, Office templates and add-in settings, agent and tool configuration files | Application packaging and deployment pipelines |
Where it is implemented
D3-RC is delivered by platform features and configuration management tooling. Two documented platform examples show the patterns worth copying; vendors are listed alphabetically and are examples, not recommendations.
- Cisco IOS XE configuration rollback:
configure replacereplaces the running configuration with a saved file, and with atimevalue the change must be confirmed withconfigure confirm, otherwise the device reverts to the configuration active before the replace.configure reverttriggers an immediate rollback or resets the timer. Cisco requires a configuration archive (typically created witharchive config) before using the procedure. - Microsoft Group Policy:
Backup-GPObacks up one GPO or all GPOs in a domain (-All) to a backup directory with an optional-Comment.Restore-GPOrestores a backup to the original domain it came from, by-Name,-Guid, a specific older-BackupIdor-All, and supports-WhatIf. It fails if the original domain is unavailable or the GPO no longer exists there.
The common design points are the same everywhere: backups held outside the system they protect, selectable older versions so you can choose one from before the intrusion, a preview before applying, and an automatic or simple way back.
Where identity fits
Configuration restores are run by highly privileged identities: domain administrators, cloud automation roles, configuration management service accounts and pipeline tokens. If the attacker changed configuration, assume those identities may be compromised too. Restore from an isolated account or tool whose credentials were not exposed, and rotate the automation credentials before re-enabling scheduled configuration runs. See Recovering IAM and PAM After Ransomware or Domain Compromise and If your configuration management tool is compromised.
ATT&CK techniques D3FEND relates to D3-RC
Relationship type: inferred only. D3FEND lists these as inferred and experimental relations: they exist because D3-RC restores a Configuration Resource that each technique modifies or reads (D3FEND 1.6.0, checked November 2026). Rows are grouped by ATT&CK v20 tactic. D3FEND still lists six Impair Defenses sub-techniques under IDs that ATT&CK v20 has revoked; the table shows their v20 successors. Every ID was checked against ATT&CK v20.
| ATT&CK v20 group | Techniques (inferred via Configuration Resource) | What a configuration restore reverses |
|---|---|---|
| Autostart and logon scripts | T1547.001 Registry Run Keys / Startup Folder, T1547.002 Authentication Package, T1547.003 Time Providers, T1547.004 Winlogon Helper DLL, T1547.005 Security Support Provider, T1547.010 Port Monitors, T1037.004 RC Scripts, T1037.005 Startup Items | Autostart registry values and startup configuration added for persistence |
| Event triggered execution | T1546.001 Change Default File Association, T1546.002 Screensaver, T1546.007 Netsh Helper DLL, T1546.008 Accessibility Features, T1546.009 AppCert DLLs, T1546.010 AppInit DLLs, T1546.011 Application Shimming, T1546.014 Emond | Trigger settings that launch attacker code on an event |
| Privilege escalation | T1548.001 Setuid and Setgid, T1548.002 Bypass User Account Control, T1548.005 Temporary Elevated Cloud Access, T1134.005 SID-History Injection | Elevation-related settings and attributes |
| Defence impairment (v20 successors) | T1685.001 Disable or Modify Windows Event Log (successor to Disable Windows Event Logging), T1690 Prevent Command History Logging, T1686 Disable or Modify System Firewall, T1686.001 Cloud Firewall, T1685.002 Disable or Modify Cloud Log, T1688 Safe Mode Boot | Logging, firewall and boot settings switched off or weakened |
| Defence impairment (other) | T1556.002 Password Filter DLL, T1556.009 Conditional Access Policies, T1553.003 SIP and Trust Provider Hijacking, T1578.002 Create Cloud Instance, T1578.003 Delete Cloud Instance, T1578.004 Revert Cloud Instance, T1578.005 Modify Cloud Compute Configurations | Authentication process, trust provider and cloud compute configuration |
| Stealth and hijacked execution | T1574.011 Services Registry Permissions Weakness, T1574.012 COR_PROFILER, T1564.008 Email Hiding Rules, T1218.002 Control Panel | Service and environment settings, hidden mail rules |
| Office persistence and collection | T1137.001 Office Template Macros, T1137.002 Office Test, T1137.004 Outlook Home Page, T1137.005 Outlook Rules, T1114.003 Email Forwarding Rule | Office and mailbox configuration used for persistence or collection |
| Credential access and discovery | T1552.005 Cloud Instance Metadata API, T1552.006 Group Policy Preferences, T1518.001 Security Software Discovery | Settings that expose credentials or are read during reconnaissance; restore helps only where a setting was changed |
D3FEND also lists parent techniques by name without sub-technique rows, including Domain or Tenant Policy Modification (T1484), File and Directory Permissions Modification (T1222), Modify Cloud Resource Hierarchy (T1666), Group Policy Discovery (T1615), System Location Discovery (T1614) and Inhibit System Recovery (T1490). Discovery techniques read configuration rather than change it, so restore does little against them directly. Detection for the largest groups is in the T1547 Boot or Logon Autostart Execution Defensive Guide, the T1546 Event Triggered Execution Defensive Guide and the T1685 Disable or Modify Tools Defensive Guide.
Implementation steps
- Baseline before you need it. Keep versioned configuration for each class in the table above, captured automatically on change and on a schedule, with timestamps and authors. NIST SP 800-128 treats this as part of security-focused configuration management.
- Store baselines out of reach. Hold backups and repositories where a compromised administrator account of the protected system cannot change or delete them, with separate credentials and immutable or versioned storage. See the Backup Security and Immutable Backup Guide.
- Scope the change set. During the incident, diff the live configuration against the last baseline known to predate the intrusion. List every difference and classify it as attacker change, legitimate change made since, or unknown.
- Contain first. Revoke or rotate the credentials and close the entry point used to make the changes before restoring, otherwise the attacker re-applies them.
- Preview, then restore with a way back. Use preview modes (for example
-WhatIf) and confirmed or timed rollback features where they exist. Restore the security-critical settings first: logging, firewall, authentication policy, then persistence locations, then the rest. - Re-apply legitimate changes deliberately. Legitimate changes made after the baseline are re-applied through normal change control, not carried over in bulk.
- Roll back if service breaks. If the restored configuration breaks a service, revert to the post-incident state only for that component, record the exception and fix forward; never re-enable a setting identified as an attacker change.
How to verify the restore
- Configuration comparison: after the restore, the live configuration matches the chosen baseline, except for documented and approved differences. Run the same drift check again 24 hours later to catch re-application by surviving persistence.
- Functional checks: generate a test event and confirm it reaches the log platform; test that firewall rules block what they should; confirm conditional access applies to a test sign-in.
- Persistence hunt: check the autostart, event-trigger and mail-rule locations from the ATT&CK table on restored systems, since a baseline may not cover every location.
- Integrity of the source: confirm the backup or baseline used was itself verified before use, which NIST CSF 2.0 RC.RP-03 calls for.
- Exercise: rehearse configuration restores in recovery tests. See the Restore Testing and Recovery Assurance Guide.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Configuration classes with an automated, off-system baseline | All classes in scope | Nothing can be restored that was never captured |
| Drift between restored systems and baseline 24 hours after restore | Zero unexplained differences | Shows persistence did not re-apply changes |
| Time to restore security-critical settings in exercises | Tracked and falling | Logging and authentication policy should come back first |
| Restores performed with a tested rollback path | 100% | Avoids extended outages from a bad restore |
| Restore exercises per year per configuration class | At least one | Untested restores fail when needed |
Limits and failure patterns
- Restoring a poisoned baseline: if the attacker was present before the last baseline, the restore reinstates their changes. Choose the baseline by intrusion timeline, not by recency.
- Restoring before containment: settings are back for minutes before the attacker, still holding valid credentials, changes them again.
- Baselines that do not cover the attack surface: many autostart and event-trigger locations, Office settings and mailbox rules are not in any baseline, so they survive a restore. Pair D3-RC with a persistence hunt.
- Backups inside the blast radius: configuration backups stored on the domain, tenant or device they protect can be altered or deleted by the same administrator account. See the Backup Identity Isolation Guide.
- Bulk restore that drops legitimate change: restoring everything to an old baseline can undo security fixes applied since, such as patches to configuration or new detection settings.
- Automation that fights the restore: a compromised configuration management tool or pipeline pushes the attacker's version back on its next run. Freeze or verify the tool before relying on it.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-2 Baseline Configuration | The baseline that a restore returns to |
| NIST SP 800-53 Rev 5 | CM-3 Configuration Change Control, CM-6 Configuration Settings | Controlled re-application of legitimate change and approved settings |
| NIST SP 800-53 Rev 5 | CP-9 System Backup, CP-10 System Recovery and Reconstitution | Backing up configuration and reconstituting systems to a known state |
| NIST CSF 2.0 | PR.PS-01, RC.RP-01, RC.RP-03 | Configuration management practices; executing recovery; verifying backup integrity before restoring |
| MITRE D3FEND | D3-RO, D3-RC | Parent and technique |
Related countermeasures
- Restore Software (D3-RS) and Restore Disk Image (D3-RDI): used when configuration alone cannot be trusted and the system is rebuilt.
- Restore File (D3-RF): for configuration held in individual files on disk.
- System Init Config Analysis (D3-SICA): detects changes to initialisation configuration that D3-RC later reverses. See D3-SICA System Init Config Analysis.
- Credential Rotation (D3-CRO): evicts the access used to make the changes. See D3-CRO Credential Rotation. The wider framework is in the MITRE D3FEND Guide.
Practitioner checklist
- Keep versioned, automated baselines for every configuration class, stored outside the system they protect.
- Protect baseline storage with separate credentials and immutable or versioned storage.
- During an incident, diff live configuration against the last baseline that predates the intrusion.
- Contain and rotate credentials before restoring.
- Restore logging, firewall and authentication policy first.
- Use preview and confirmed or timed rollback features where the platform offers them.
- Re-check drift 24 hours after the restore and hunt persistence locations not in the baseline.
- Verify the integrity of the baseline before using it.
- Rehearse configuration restores at least once a year per class.
Standards and references
- MITRE D3FEND: Restore Configuration (D3-RC)
- CISA: Federal Government Cybersecurity Incident and Vulnerability Response Playbooks
- NIST: SP 800-184 Guide for Cybersecurity Event Recovery
- NIST: SP 800-128 Guide for Security-Focused Configuration Management of Information Systems
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- Cisco: Configuration Rollback Confirmed Change
- Microsoft Learn: Backup-GPO
- Microsoft Learn: Restore-GPO
Related NHI Mgmt Group resources: Cybersecurity Event Recovery Guide · Configuration Drift and Baseline Enforcement Guide · IdP configuration backup and restore for Entra ID and Okta · Restore Testing and Recovery Assurance Guide · MITRE D3FEND Guide