DC0045: Windows Registry Key Deletion
The removal of a registry key within the Windows operating system.
*Data Collection Measures:*
- Windows Event Logs - Event ID 4658 - Registry Key Handle Closed: Captures when a handle to a registry key is closed, which may indicate deletion. - Event ID 4660 - Object Deleted: Logs when a registry key is deleted. - Sysmon (System Monitor) for Windows - Sysmon Event ID 12 - Registry Key Deleted: Logs when a registry key is removed. - Sysmon Event ID 13 - Registry Value Deleted: Captures removal of specific registry values. - Endpoint Detection and Response (EDR) Solutions - Monitor registry deletions for suspicious behavior.
Analyst context for executives and security teams
Windows Registry Key Deletion is a telemetry component that records when registry keys or values are removed in the Windows operating system. For leaders, its value is not the deletion itself, but whether the organization can prove what changed, when it changed, and on which endpoint during an investigation. Registry deletion evidence can help SOC and IR teams separate normal software activity from suspicious configuration tampering or cleanup behavior, but ATT&CK does not provide a detection analytic for this object.
Executive priority
Treat this as a coverage and evidence question for endpoint monitoring and incident response readiness. Security leaders should ask whether Windows registry deletion events are collected consistently, retained long enough for investigations, and available to analysts through Windows Event Logs, Sysmon, or EDR. This data component can support auditability and incident decision-making, but it requires local baselining because legitimate administrative tools, software updates, and uninstallers may also delete registry keys.
Technical view
Validate whether the environment captures registry key and value deletion evidence using the ATT&CK-listed sources: Windows Event Logs including Event ID 4658 for registry key handle closure and Event ID 4660 for object deletion, Sysmon Event ID 12 for registry key deletion, Sysmon Event ID 13 for registry value deletion, and EDR registry monitoring. Because no ATT&CK detection logic or relationship context is supplied, detection engineering should focus on confirming event fidelity, endpoint coverage, field normalization, retention, and correlation with process, user, host, and time context.
Likely telemetry
- Windows Event Logs for registry object activity, including Event ID 4658 and Event ID 4660 where configured
- Sysmon registry events, including Event ID 12 for registry key deletion and Event ID 13 for registry value deletion
- EDR telemetry that records registry deletions and related process, user, and host context
- Endpoint inventory or logging coverage evidence showing which systems produce and forward these events
Detection direction
- Confirm that registry deletion events are actually enabled, collected, parsed, and searchable; default logging may not provide uniform visibility across all endpoints.
- Tune detections around context rather than deletion alone, because normal software installation, uninstallation, patching, and administration can generate registry deletion activity.
- Correlate registry deletion events with initiating process, account, host, time window, and nearby endpoint activity when those fields are available in local telemetry.
- Review blind spots where Sysmon is not deployed, EDR policy does not capture registry activity, Windows audit settings are incomplete, or retention is too short for incident response.
- Use this data component as supporting evidence in investigations rather than as a standalone indicator, since ATT&CK provides no official detection analytic for this object.
Mitigation priorities
- Prioritize reliable endpoint logging coverage for registry deletion activity through Windows auditing, Sysmon, or EDR where appropriate.
- Standardize event forwarding, parsing, retention, and access so SOC and IR teams can use the data during investigations.
- Baseline expected registry deletion patterns from approved software management, patching, and administrative workflows to reduce false positives.
- Ensure analysts can correlate registry deletion telemetry with process execution, user activity, and host context in the SIEM or investigative platform.
- Document collection coverage and gaps as compliance and incident response readiness evidence.
Analyst notes and limits
This is a data component, not a technique, and the supplied object has no tactics, platforms, aliases, labels, official detection, or relationship context. The official description is limited to removal of a registry key within the Windows operating system, with collection measures for Windows Event Logs, Sysmon, and EDR. Local environment configuration determines whether the listed events are available and useful.
No active exploitation, attribution, affected techniques, or ATT&CK relationship context was supplied. No official detection logic was provided. Recommendations are therefore limited to defensive validation, telemetry coverage, correlation, and operational readiness based on the official data collection measures.
Windows Registry Key Deletion
The removal of a registry key within the Windows operating system.
*Data Collection Measures:*
- Windows Event Logs - Event ID 4658 - Registry Key Handle Closed: Captures when a handle to a registry key is closed, which may indicate deletion. - Event ID 4660 - Object Deleted: Logs when a registry key is deleted. - Sysmon (System Monitor) for Windows - Sysmon Event ID 12 - Registry Key Deleted: Logs when a registry key is removed. - Sysmon Event ID 13 - Registry Value Deleted: Captures removal of specific registry values. - Endpoint Detection and Response (EDR) Solutions - Monitor registry deletions for suspicious behavior.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 0989583be35a… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DC0045Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.