D3-RKD Registry Key Deletion: Removing Malicious Keys and Proving They Stay Gone

Windows malware rarely survives a reboot by luck: it writes a registry key that tells Windows to start it again, and an eradication that misses that key hands the attacker back their foothold. MITRE D3FEND names the countermeasure Registry Key Deletion (D3-RKD) and defines it in three words: "Delete a registry key." It sits under the Evict tactic as a child of Object Eviction (D3-OE), alongside File Eviction (D3-FEV). D3FEND's only reference for it is CISA's Federal Government Cybersecurity Incident and Vulnerability Response Playbooks, which give federal agencies standard procedures for identifying, remediating and recovering from incidents. This card explains which registry locations matter, which ATT&CK techniques D3FEND relates to D3-RKD, how to delete keys safely with evidence preserved, and how to prove they do not come back. It is written for incident responders and Windows endpoint engineers.

Key takeaways

• Collect before you delete. A registry key is evidence. Export it, record its last write time and note the process that created it before removal, or the investigation loses its best persistence clue.
• Delete the key and its payload together. Removing an autostart key while the referenced DLL or executable stays on disk, or deleting the file while the key remains, leaves a half-cleaned host. Pair D3-RKD with File Eviction.
• D3FEND's mapping is narrow and inferred. Through the Windows Registry Key artefact, D3FEND relates D3-RKD to T1547.012 Print Processors, T1547.014 Active Setup and a command history technique tracked in ATT&CK v20 as T1690 Prevent Command History Logging.
• Re-creation is the real test. If a scheduled task, service, WMI subscription or second implant rewrites the key, deletion only buys minutes. Monitor the path after deletion with Sysmon event 12 or registry auditing.
• Scale needs tooling, not RDP. Use EDR remediation actions or managed scripts across all affected hosts at once, so the attacker cannot hop between hosts as you clean them one by one.

D3-RKD at a glance

How it works

D3FEND gives no further description beyond the definition, so the practice comes from incident response. Eradication removes the attacker's artefacts after containment, and registry keys are among the most common: autostart entries, service definitions, COM hijacks, image file execution options and the specific locations ATT&CK documents for each persistence technique. Removing them involves four steps.

• Identify: find suspicious keys by comparing autostart locations against a known-good baseline. Microsoft Sysinternals Autoruns lists startup folders, Registry Run and RunOnce keys, services, Winlogon notification DLLs, AppInit DLLs, image hijacks and more; its command-line form autorunsc exports all categories with hashes and signature status (for example -a * -c -h -s) so results from many hosts can be compared.
• Preserve: export the key (for example with reg export) and capture its last write time, the referenced file path and hash, and related event log entries before any change.
• Delete: remove the key or value with an EDR remediation action, a managed script, or the built-in reg delete command. Microsoft documents that reg delete <keyname> without /v deletes all entries and subkeys under the subkey, /v deletes one named value, /va deletes all values but keeps subkeys, and remote use is limited to HKLM and HKU. Choose the narrowest option that removes the persistence: a malicious value in a shared Run key should be removed with /v, not by deleting the whole Run key.
• Confirm: re-query the location, reboot or log on as the affected user where safe, and watch for re-creation.

The sibling technique and its child are covered in D3-FEV File Eviction and D3-ER Email Removal.

ATT&CK techniques D3FEND relates to D3-RKD

Relationship type: inferred only. D3FEND lists no hand-made ATT&CK mapping for D3-RKD. The rows below are inferred because D3-RKD deletes a Windows Registry Key and these ATT&CK techniques create or modify one (D3FEND 1.6.0 knowledge graph, checked November 2026). D3FEND labels these relations inferred and experimental. D3FEND still lists Impair Command History Logging under its revoked ID; ATT&CK v20 tracks it as T1690 Prevent Command History Logging, shown below. Each ID was checked against ATT&CK v20.

The list is short because D3FEND ties only these techniques to the registry key artefact. In practice D3-RKD is the eradication step for every registry-based persistence technique, most often T1547 Boot or Logon Autostart Execution sub-techniques such as T1547.001 Registry Run Keys / Startup Folder, and for changes made with MITRE ATT&CK T1112 Modify Registry. That wider use is NHI Mgmt Group's view, not a D3FEND mapping.

Where it is implemented

Implementation steps

1. Contain first. Isolate affected hosts and block attacker infrastructure before eradication, so the attacker cannot react to removals by planting new keys.
2. Scope every host. Search the whole estate for the same key paths, value names and payload hashes. Persistence found on one host is rarely unique.
3. Collect evidence. Export each key, record last write time, payload path and hash, and preserve related logs. Hand them to the investigation before deletion.
4. Remove keys and payloads together. Delete the narrowest key or value that removes persistence, remove the referenced file (D3-FEV), stop the related service or process, and delete any scheduled task or WMI subscription that recreates the key.
5. Do it in one coordinated window. Run eradication across all affected hosts at the same time.
6. Rollback plan. Keep the exported keys. If a deleted key turns out to belong to legitimate software (a print processor or Active Setup component from an installed product), re-import it from the export and reinstall the product from a trusted source.
7. Rotate exposed credentials. Registry persistence usually means administrative access. Rotate or reissue the credentials used on the host; see D3-RIC Reissue Credential.

How to verify it works

• Re-query the location: confirm the key or value no longer exists on every host in scope, using the same query that found it.
• Re-run the autostart baseline: export autorunsc results again and compare them with the pre-incident or golden image baseline; any unexpected entry is a missed artefact.
• Watch for re-creation: Sysmon event ID 12 (RegistryEvent, object create and delete) logs creation and deletion of keys and values, event 13 logs value sets and event 14 logs renames. Alert on any write to the deleted paths for at least the monitoring period after eradication.
• Use native auditing where Sysmon is absent: with the Audit Registry subcategory enabled and a SACL on the key, Windows event 4657 logs value creation, modification and deletion, and event 4663 records use of access rights such as DELETE on objects of type Key.
• Reboot test: where safe, reboot and log on as an affected user, then confirm the payload does not start.

Limits, bypasses and failure patterns

• Deleting before collecting: automated cleanup removes the key, and the investigation never learns how persistence was set or by which account.
• Removing the shared parent key: deleting a whole Run key or Print Processors key removes legitimate entries too and can break printing or startup applications. Delete the malicious value or subkey only.
• Missing the re-creator: a service, scheduled task, WMI event subscription or second implant rewrites the key within minutes.
• Per-user hives ignored: keys under HKCU exist per user profile. Removing one user's key leaves the same entry in other profiles; scan all loaded and unloaded user hives.
• Treating deletion as recovery: the attacker's credentials and any other access survive. Registry cleanup without credential reissue and access review leaves the door open.
• Permission errors read as success: scripts that do not check return codes report success when access was denied, often on keys the attacker protected with restrictive ACLs. See M1024 Restrict Registry Permissions for the preventive side.

Framework mapping

The mapping below is NHI Mgmt Group's view of where the control sits; D3FEND itself maps only to its digital artefact and inferred ATT&CK relations.

Practitioner checklist

• Contain hosts before deleting persistence.
• Scope the same key paths, values and payload hashes across the whole estate.
• Export every malicious key and record last write time before deletion.
• Delete the narrowest value or subkey, never a shared parent key.
• Remove the payload file and any task, service or WMI subscription that recreates the key.
• Scan all user hives, not only the logged-on user.
• Check script return codes and confirm removal by re-query.
• Alert on Sysmon event 12 or event 4657 for the deleted paths after eradication.
• Reissue credentials used on the affected hosts.

Standards and references

• MITRE D3FEND: Registry Key Deletion (D3-RKD)
• CISA: Federal Government Cybersecurity Incident and Vulnerability Response Playbooks
• MITRE ATT&CK: T1547.014 Active Setup
• MITRE ATT&CK: T1547.012 Print Processors
• Microsoft Learn: reg delete
• Microsoft Learn: Sysinternals Autoruns
• Microsoft Learn: Sysinternals Sysmon
• Microsoft Learn: Event 4657, a registry value was modified

Related NHI Mgmt Group resources: Incident Response Guide · T1547 Boot or Logon Autostart Execution Defensive Guide · MITRE ATT&CK T1112 Modify Registry · D3-FEV File Eviction · MITRE D3FEND Guide