M1024: Restrict Registry Permissions
Restricting registry permissions involves configuring access control settings for sensitive registry keys and hives to ensure that only authorized users or processes can make modifications. By limiting access, organizations can prevent unauthorized changes that adversaries might use for persistence, privilege escalation, or defense evasion. This mitigation can be implemented through the following measures:
Review and Adjust Permissions on Critical Keys
- Regularly review permissions on keys such as `Run`, `RunOnce`, and `Services` to ensure only authorized users have write access. - Use tools like `icacls` or `PowerShell` to automate permission adjustments.
Enable Registry Auditing
- Enable auditing on sensitive keys to log access attempts. - Use Event Viewer or SIEM solutions to analyze logs and detect suspicious activity. - Example Audit Policy: `auditpol /set /subcategory:"Registry" /success:enable /failure:enable`
Protect Credential-Related Hives
- Limit access to hives like `SAM`,`SECURITY`, and `SYSTEM` to prevent credential dumping or other unauthorized access. - Use LSA Protection to add an additional security layer for credential storage.
Restrict Registry Editor Usage
- Use Group Policy to restrict access to regedit.exe for non-administrative users. - Block execution of registry editing tools on endpoints where they are unnecessary.
Deploy Baseline Configuration Tools
- Use tools like Microsoft Security Compliance Toolkit or CIS Benchmarks to apply and maintain secure registry configurations.
*Tools for Implementation*
Registry Permission Tools:
- Registry Editor (regedit): Built-in tool to manage registry permissions. - PowerShell: Automate permissions and manage keys. `Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "KeyName" -Value "Value"` - icacls: Command-line tool to modify ACLs.
Monitoring Tools:
- Sysmon: Monitor and log registry events. - Event Viewer: View registry access logs.
Policy Management Tools:
- Group Policy Management Console (GPMC): Enforce registry permissions via GPOs. - Microsoft Endpoint Manager: Deploy configuration baselines for registry permissions.
Analyst context for executives and security teams
Restrict Registry Permissions is a hardening control that reduces how easily attackers can use Windows Registry changes for persistence, privilege escalation, credential access, defense impairment, or execution-flow hijacking. Its business value is not just “locking down keys”; it is preserving endpoint and server integrity so logon behavior, services, authentication components, firewall settings, event logging, and trust controls cannot be changed by unauthorized users or processes.
Executive priority
Prioritize this where Windows systems support critical operations, privileged administration, remote access, authentication, or security tooling. Leaders should ask whether sensitive Registry locations have approved baselines, whether changes are audited, and whether SOC/IR teams can prove who changed high-risk keys. This mitigation supports resilience and audit readiness because many related ATT&CK behaviors depend on weak write permissions or unaudited Registry modification paths.
Technical view
Validate permissions and auditing on sensitive Registry keys and hives identified by the ATT&CK object, including Run, RunOnce, Services, SAM, SECURITY, SYSTEM, Windows logon script locations, service configuration paths, trust/provider settings, firewall and event log related configuration, and credential/authentication-related locations where applicable. SOC and IR teams should confirm that Registry ACL changes, key/value modifications, and access attempts on protected keys are visible in endpoint and SIEM telemetry. Detection content should be tied to the mitigated techniques, especially Modify Registry, Services Registry Permissions Weakness, Windows logon script persistence, Terminal Services DLL, Time Providers, Network Provider DLL, Windows Event Log modification, and Windows host firewall modification.
Likely telemetry
- Registry key/value modification events from endpoint sensors or Sysmon
- Windows Security auditing for Registry success and failure events where enabled
- Registry ACL and permission change records
- Process execution telemetry for registry editing or configuration tools such as regedit, PowerShell, reg, icacls, or policy tooling
- Group Policy or endpoint management baseline application and drift records
Detection direction
- First validate that Registry auditing is enabled for sensitive keys; absence of auditing is a coverage gap, not evidence of safety.
- Tune alerts around unauthorized writes or ACL changes to high-risk keys rather than all Registry activity, because normal software installation, patching, endpoint management, and administrative maintenance can create high volumes of benign changes.
- Correlate Registry changes with the initiating user, process, host role, recent privilege changes, and management-system activity to separate approved configuration drift from suspicious modification.
- Pay special attention to changes connected to persistence and defense impairment relationships: logon scripts, service registry paths, event logging, firewall configuration, trust providers, time providers, terminal services components, and network provider DLL registration.
- Use baseline comparison to identify drift from approved Registry permissions and values on critical servers and privileged workstations.
Mitigation priorities
- Define and maintain approved Registry permission baselines for sensitive keys and hives.
- Restrict write access to authorized administrators, system processes, and managed configuration mechanisms only.
- Enable Registry auditing on critical keys, including success and failure events where operationally feasible.
- Protect credential-related hives such as SAM, SECURITY, and SYSTEM, and use LSA Protection where appropriate.
- Restrict Registry editing tools for non-administrative users and endpoints where direct editing is unnecessary.
Analyst notes and limits
This is a mitigation object, so the main analytic value is control validation and drift detection rather than adversary procedure identification. The relationship set shows why Registry permissions matter across persistence, privilege escalation, defense impairment, credential access, execution, stealth, and impact-adjacent behaviors. Although the official platform field is not specified, the description and many related techniques are Windows Registry focused; apply conclusions to local Windows estate evidence and do not generalize to non-Windows controls without separate validation.
Official MITRE detection text is not provided. The object does not specify platforms at the mitigation level, and several related techniques include non-Windows platforms even though this mitigation’s description is Registry-focused. Local key lists, approved administrators, baseline policies, audit settings, and endpoint telemetry availability are required to determine actual coverage.
Restrict Registry Permissions
Restricting registry permissions involves configuring access control settings for sensitive registry keys and hives to ensure that only authorized users or processes can make modifications. By limiting access, organizations can prevent unauthorized changes that adversaries might use for persistence, privilege escalation, or defense evasion. This mitigation can be implemented through the following measures:
Review and Adjust Permissions on Critical Keys
- Regularly review permissions on keys such as `Run`, `RunOnce`, and `Services` to ensure only authorized users have write access. - Use tools like `icacls` or `PowerShell` to automate permission adjustments.
Enable Registry Auditing
- Enable auditing on sensitive keys to log access attempts. - Use Event Viewer or SIEM solutions to analyze logs and detect suspicious activity. - Example Audit Policy: `auditpol /set /subcategory:"Registry" /success:enable /failure:enable`
Protect Credential-Related Hives
- Limit access to hives like `SAM`,`SECURITY`, and `SYSTEM` to prevent credential dumping or other unauthorized access. - Use LSA Protection to add an additional security layer for credential storage.
Restrict Registry Editor Usage
- Use Group Policy to restrict access to regedit.exe for non-administrative users. - Block execution of registry editing tools on endpoints where they are unnecessary.
Deploy Baseline Configuration Tools
- Use tools like Microsoft Security Compliance Toolkit or CIS Benchmarks to apply and maintain secure registry configurations.
*Tools for Implementation*
Registry Permission Tools:
- Registry Editor (regedit): Built-in tool to manage registry permissions. - PowerShell: Automate permissions and manage keys. `Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "KeyName" -Value "Value"` - icacls: Command-line tool to modify ACLs.
Monitoring Tools:
- Sysmon: Monitor and log registry events. - Event Viewer: View registry access logs.
Policy Management Tools:
- Group Policy Management Console (GPMC): Enforce registry permissions via GPOs. - Microsoft Endpoint Manager: Deploy configuration baselines for registry permissions.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1547.003 | Time Providers Sub-technique | Consider using Group Policy to configure and block modifications to W32Time parameters in the Registry. CitationMicrosoft W32Time May 2017 |
| Enterprise | T1574.012 | COR_PROFILER Sub-technique | Ensure proper permissions are set for Registry hives to prevent users from modifying keys associated with COR_PROFILER. |
| Enterprise | T1037.001 | Logon Script (Windows) Sub-technique | Ensure proper permissions are set for Registry hives to prevent users from modifying keys for logon scripts that may lead to persistence. |
| Enterprise | T1556.008 | Network Provider DLL Sub-technique | Restrict Registry permissions to disallow the modification of sensitive Registry keys such as `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order`. |
| Enterprise | T1556 | Modify Authentication Process | Restrict Registry permissions to disallow the modification of sensitive Registry keys such as `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order`. |
| Enterprise | T1686 | Disable or Modify System Firewall | Ensure proper Registry permissions are in place to prevent adversaries from disabling or modifying firewall settings. |
| Enterprise | T1505 | Server Software Component | Consider using Group Policy to configure and block modifications to service and other critical server parameters in the Registry.CitationMicrosoft System Services Fundamentals |
| Enterprise | T1505.005 | Terminal Services DLL Sub-technique | Consider using Group Policy to configure and block modifications to Terminal Services parameters in the Registry.CitationMicrosoft System Services Fundamentals |
| Enterprise | T1685.001 | Disable or Modify Windows Event Log Sub-technique | Ensure proper Registry permissions are in place to prevent adversaries from disabling or interfering logging. The addition of the MiniNT registry key disables Event Viewer.Citationdef_ev_win_event_logging |
| Enterprise | T1574.011 | Services Registry Permissions Weakness Sub-technique | Ensure proper permissions are set for Registry hives to prevent users from modifying keys for system components that may lead to privilege escalation. |
| Enterprise | T1070.007 | Clear Network Connection History and Configurations Sub-technique | Protect generated event files and logs that are stored locally with proper permissions and authentication and limit opportunities for adversaries to increase privileges by preventing Privilege Escalation opportunities. |
| Enterprise | T1112 | Modify Registry | Ensure proper permissions are set for Registry hives to prevent users from modifying keys for system components that may lead to privilege escalation. |
| Enterprise | T1574 | Hijack Execution Flow | Ensure proper permissions are set for Registry hives to prevent users from modifying keys for system components that may lead to privilege escalation. |
| Enterprise | T1553.003 | SIP and Trust Provider Hijacking Sub-technique | Ensure proper permissions are set for Registry hives to prevent users from modifying keys related to SIP and trust provider components. Components may still be able to be hijacked to suitable functions already present on disk if malicious modifications to Registry keys are not prevented. |
| Enterprise | T1037 | Boot or Logon Initialization Scripts | Ensure proper permissions are set for Registry hives to prevent users from modifying keys for logon scripts that may lead to persistence. |
| Enterprise | T1553 | Subvert Trust Controls | Ensure proper permissions are set for Registry hives to prevent users from modifying keys related to SIP and trust provider components. Components may still be able to be hijacked to suitable functions already present on disk if malicious modifications to Registry keys are not prevented. |
| Enterprise | T1685 | Disable or Modify Tools | Ensure proper Registry permissions are in place to prevent adversaries from disabling or interfering with security services. |
| Enterprise | T1686.003 | Windows Host Firewall Sub-technique | Ensure proper Registry permissions are in place to prevent adversaries from disabling or modifying firewall settings. |
| Enterprise | T1489 | Service Stop | Ensure proper registry permissions are in place to inhibit adversaries from disabling or interfering with critical services. |
| Enterprise | T1553.006 | Code Signing Policy Modification Sub-technique | Ensure proper permissions are set for the Registry to prevent users from modifying keys related to code signing policies. |
All related ATT&CK context
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 | 1.2 | Current bundle | 6ad8589eafd7… |
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 M1024Open 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.