DC0063: Windows Registry Key Modification
Changes made to an existing registry key or its values. These modifications can include altering permissions, modifying stored data, or updating configuration settings.
*Data Collection Measures:*
- Windows Event Logs - Event ID 4657 - Registry Value Modified: Logs changes to registry values, including modifications to startup entries, security settings, or system configurations. - Sysmon (System Monitor) for Windows - Sysmon Event ID 13 - Registry Value Set: Captures changes to specific registry values. - Sysmon Event ID 14 - Registry Key & Value Renamed: Logs renaming of registry keys, which may indicate evasion attempts. - Endpoint Detection and Response (EDR) Solutions - Monitor registry modifications for suspicious behavior.
Analyst context for executives and security teams
Windows Registry Key Modification is important because registry changes often represent meaningful configuration drift on Windows systems: startup behavior, security settings, permissions, and application or system configuration can all be altered there. For leaders, the value is not simply knowing that registry changes occur, but confirming whether the organization can distinguish expected administrative or software activity from changes that may affect resilience, security posture, or incident scope.
Executive priority
Prioritize this data component as evidence for endpoint visibility and change accountability. It can support incident response timelines, control validation, and audit discussions around whether critical Windows configuration changes are logged and reviewable. The key business question is whether registry modification telemetry is collected consistently enough to explain what changed, when it changed, and which process or account was involved during an investigation.
Technical view
SOC and IR teams should validate collection of registry value modification and rename events where available. The supplied ATT&CK collection measures specifically reference Windows Event ID 4657 for registry value modifications, Sysmon Event ID 13 for registry value set activity, Sysmon Event ID 14 for registry key and value rename activity, and EDR monitoring of registry modifications. Because no ATT&CK detection logic or related techniques are supplied, detection engineering should focus first on telemetry completeness, event normalization, and baseline behavior for expected administrative, software update, and configuration-management activity.
Likely telemetry
- Windows Event Logs, especially Event ID 4657 for registry value modification
- Sysmon Event ID 13 for registry value set activity
- Sysmon Event ID 14 for registry key and value rename activity
- EDR telemetry describing registry modifications
- Associated context such as timestamp, account, host, process, registry path, value name, and old/new value where available
Detection direction
- Confirm that registry modification events are actually enabled, retained, and searchable for relevant Windows assets.
- Validate that Sysmon or equivalent endpoint telemetry captures both value changes and key/value rename activity, not only process execution.
- Tune detections around sensitive or high-risk registry areas only after establishing local baselines, because routine software installation, updates, administration, and configuration management can generate substantial benign noise.
- Correlate registry changes with account, process, and host context to support triage; registry-path-only alerting is likely to be noisy.
- Account for blind spots where Windows auditing, Sysmon configuration, EDR policy, or retention settings do not capture the modified key or value.
Mitigation priorities
- Establish logging requirements for registry value modifications and rename activity on systems where this evidence is needed for security monitoring or investigations.
- Use endpoint configuration management to define and monitor expected registry settings for important security and startup-related configurations.
- Limit administrative access and registry modification rights according to least-privilege principles where operationally feasible.
- Ensure EDR and log retention policies preserve enough registry modification context to support incident response and compliance evidence needs.
- Regularly test whether representative registry changes produce the expected Windows Event Log, Sysmon, or EDR records.
Analyst notes and limits
No ATT&CK tactics, platforms field, detection analytics, or relationship context were supplied for this data component. The Windows focus is inferred from the object name and the official data collection measures, not from a populated platform field. Treat this as a telemetry and evidence-quality control area rather than a standalone indicator of malicious activity.
Registry modifications are common in normal administration and software operations, so this data component does not by itself establish malicious behavior. Local baselines, asset criticality, registry path sensitivity, and process/account context are required to turn this telemetry into reliable detection or response decisions.
Windows Registry Key Modification
Changes made to an existing registry key or its values. These modifications can include altering permissions, modifying stored data, or updating configuration settings.
*Data Collection Measures:*
- Windows Event Logs - Event ID 4657 - Registry Value Modified: Logs changes to registry values, including modifications to startup entries, security settings, or system configurations. - Sysmon (System Monitor) for Windows - Sysmon Event ID 13 - Registry Value Set: Captures changes to specific registry values. - Sysmon Event ID 14 - Registry Key & Value Renamed: Logs renaming of registry keys, which may indicate evasion attempts. - Endpoint Detection and Response (EDR) Solutions - Monitor registry modifications 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 | 7233c50ee504… |
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 DC0063Open 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.