MITRE ATT&CK M1024 Restrict Registry Permissions Guide

On Windows, a service's executable path, the DLLs loaded at logon, the code signing policy and the switches for logging and the firewall are all registry values, so whoever can write those keys can run code as SYSTEM or blind defenders without touching a file. MITRE ATT&CK M1024 Restrict Registry Permissions is the mitigation that limits who can modify sensitive keys and hives. In ATT&CK v20 it is linked to 20 techniques and sub-techniques across persistence, privilege escalation, credential access and defence impairment. This guide reads M1024 from the ATT&CK point of view: which techniques it blunts, which keys matter most, where permissions alone fall short and what covers those gaps, and how to verify the control. It is for Windows platform owners, detection engineers and incident responders. Detecting registry tampering itself is covered in the MITRE ATT&CK T1112 Modify Registry guide; this page focuses on prevention through access control.

Key takeaways

The registry is configuration with an ACL. Every key has a security descriptor, and the rights that matter for M1024 are KEY_SET_VALUE, KEY_CREATE_SUB_KEY, WRITE_DAC and WRITE_OWNER. Any of those held by a non-administrator on a sensitive key is a finding.
Service keys are the top priority. Windows stores service configuration under HKLM\SYSTEM\CurrentControlSet\Services, and a writable service key lets a low-privilege user point a SYSTEM service at their own binary (T1574.011).
Credential hives need more than ACLs. ATT&CK's M1024 text pairs restricting SAM, SECURITY and SYSTEM with LSA Protection, which runs LSASS as a protected process.
M1024 does not stop administrators. Most defence impairment keys already need administrator rights to change, so the real controls there are privileged access management, tamper protection and monitoring.
Audit narrowly. Registry auditing (Security event 4657) and Sysmon events 12, 13 and 14 only help when scoped to a short list of security-relevant keys.

What M1024 asks for

The ATT&CK M1024 page lists five measures: review and adjust permissions on critical keys such as Run, RunOnce and Services; enable registry auditing; protect credential-related hives (SAM, SECURITY, SYSTEM) and use LSA Protection; restrict registry editor use for non-administrators through Group Policy; and deploy baseline configuration tools such as the Microsoft Security Compliance Toolkit or CIS Benchmarks. D3FEND relates M1024 to System Configuration Permissions (D3-SCP), defined as restricting system configuration modifications to a specific user or group of users.

Microsoft's registry documentation explains the mechanics. Each key's security descriptor controls which rights a caller gets when the key is opened; a key created without an explicit descriptor inherits its ACLs from its direct parent key. The rights are:

Right	What it allows	Why it matters for M1024
KEY_QUERY_VALUE, KEY_ENUMERATE_SUB_KEYS (KEY_READ)	Read values and list subkeys	Read access to credential hives enables offline credential extraction
KEY_SET_VALUE	Create, delete or set a value	Changing ImagePath, ServiceDll or a policy value
KEY_CREATE_SUB_KEY	Create a subkey	Adding a Parameters subkey or a new provider registration
WRITE_DAC	Modify the key's DACL	Lets the holder grant itself any other right
WRITE_OWNER	Change the owner	Owner can then rewrite the DACL
ACCESS_SYSTEM_SECURITY	Read or write the SACL	Removing audit settings on a key

Techniques M1024 mitigates, by tactic

All 20 v20 mappings, collapsed where ATT&CK gives sub-techniques the same text. "How it helps" paraphrases ATT&CK's per-technique usage text; the key column names the registry location from the technique or mitigation text; priority is an NHI Mgmt Group judgement.

Tactic	Technique (v20)	Key involved	How M1024 helps, per ATT&CK	Priority
Stealth, execution	T1574 Hijack Execution Flow, T1574.011 Services Registry Permissions Weakness	`HKLM\SYSTEM\CurrentControlSet\Services\<service>`	Stop users modifying keys for system components that lead to privilege escalation	High
Stealth, execution	T1574.012 COR_PROFILER	COR_PROFILER environment values	Stop users modifying keys associated with COR_PROFILER	Medium
Persistence	T1505 Server Software Component, T1505.005 Terminal Services DLL	Terminal Services service parameters (ServiceDll)	Use Group Policy to block modifications to service and Terminal Services parameters	High
Persistence, privilege escalation	T1037 Boot or Logon Initialization Scripts, T1037.001 Logon Script (Windows)	Logon script keys	Set hive permissions so users cannot modify keys for logon scripts	Medium
Persistence, privilege escalation	T1547.003 Time Providers	W32Time parameters	Use Group Policy to block modifications to W32Time parameters	Medium
Defence impairment, persistence, credential access	T1556 Modify Authentication Process, T1556.008 Network Provider DLL	`HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order`	Disallow modification of sensitive keys such as NetworkProvider\Order	High
Defence impairment	T1553 Subvert Trust Controls, T1553.003 SIP and Trust Provider Hijacking	SIP and trust provider registrations	Stop users modifying SIP and trust provider keys; ATT&CK warns components can still be hijacked to functions already on disk if changes are not prevented	Medium
Defence impairment	T1553.006 Code Signing Policy Modification	Code signing policy values	Stop users modifying code signing policy keys	High
Defence impairment, persistence	T1112 Modify Registry	Any system component key	Set hive permissions so users cannot modify keys that lead to privilege escalation	Medium
Defence impairment	T1685 Disable or Modify Tools, T1685.001 Disable or Modify Windows Event Log	Security tool and event log settings, including the MiniNT key	Registry permissions stop interference with security services and logging; ATT&CK notes adding a MiniNT key disables Event Viewer	High
Defence impairment	T1686 Disable or Modify System Firewall, T1686.003 Windows Host Firewall	Firewall policy keys	Registry permissions stop firewall settings being disabled or modified	High
Stealth	T1070.007 Clear Network Connection History and Configurations	Network history keys	Protect locally stored history with proper permissions and limit privilege escalation	Low
Impact	T1489 Service Stop	Service start configuration	Registry permissions stop critical services being disabled	Medium

Technique guides: T1574 Hijack Execution Flow Defensive Guide, T1505 Server Software Component Defensive Guide, MITRE ATT&CK T1556 Modify Authentication Process Guide, MITRE ATT&CK T1553 Subvert Trust Controls, T1685 Disable or Modify Tools Defensive Guide and MITRE ATT&CK T1489 Service Stop.

Where M1024 does the most work: services

ATT&CK's T1574.011 description explains the main case: flaws in permissions on a service's registry key let an adversary redirect the configured executable to one they control, so their code runs when the service starts, often as SYSTEM. Microsoft's service security documentation makes the same point for the service object: SERVICE_CHANGE_CONFIG grants the right to change the executable the system runs and should be granted only to administrators, and granting it or SERVICE_STOP to untrusted users can let them run applications under LocalSystem. By default, local authenticated users get only read and query rights on a service. Two places hold the same configuration, so check both:

Service object DACL: controls what sc.exe and the Service Control Manager APIs allow. Third-party installers sometimes loosen it.
Service registry key ACL: controls direct writes to ImagePath, ServiceDll, Parameters and Start under the service key. Write access here for Users, Authenticated Users or Everyone is the T1574.011 condition.

The service binary file and its folder must be locked down too; that is M1022, covered in the M1022 Restrict File and Directory Permissions guide.

Where identity fits: credential hives and LSA

The SAM, SECURITY and SYSTEM hives hold local account hashes, LSA secrets (which include stored service account passwords) and the keys needed to decrypt them. ATT&CK's M1024 guidance is to limit access to these hives and add LSA Protection. Microsoft documents LSA Protection as running LSASS as a protected process so that unprotected processes cannot read its memory or inject code. It is configured with the RunAsPPL DWORD under HKLM\SYSTEM\CurrentControlSet\Control\Lsa: value 1 enables it with a UEFI lock (stored in firmware, so registry changes cannot turn it off), value 2 enables it without the lock (enforced on Windows 11 22H2 and later). On new enterprise-joined Windows 11 22H2 installations on HVCI-capable hardware, Microsoft enables it automatically. Before enforcing, set AuditLevel to 8 under the LSASS.exe Image File Execution Options key and review CodeIntegrity events 3065 and 3066 for plug-ins and drivers that would fail; LSA plug-ins such as password filters and smart card drivers must be Microsoft-signed. Confirm enforcement with WinInit event 12 in the System log.

For non-human identities this matters directly: services running under domain accounts with stored passwords leave those secrets in LSA, and anyone who can read the hives offline can recover them. Group Managed Service Accounts remove the static password from the picture. See the Group Managed Service Accounts (gMSA) Guide and Credential Guard and VBS.

What M1024 does not stop

Gap	Why	What covers it
Administrator or SYSTEM intruder	Administrators can take ownership and rewrite any DACL; most defence impairment keys already require admin rights	M1026 Privileged Account Management, M1018 User Account Management, security tool tamper protection
HKCU persistence such as user Run keys	The user's own hive is writable by that user by design, and T1547.001 Registry Run Keys is not mapped to M1024 in v20	M1038 Execution Prevention, M1047 Audit, endpoint detection on autostart keys. See the T1547 Boot or Logon Autostart Execution Defensive Guide
Offline hive copies	Volume shadow copies and backups of SAM and SYSTEM carry the same secrets outside the live ACL	Protect backups and shadow copies; restrict backup operator rights
Hijack to existing components	ATT&CK notes SIP components can still be redirected to functions already on disk	M1038 Execution Prevention and code integrity policy
Remote registry modification	Valid admin credentials plus the Remote Registry service allow changes across the network	Disable Remote Registry where unused; M1035 Limit Access to Resource Over Network

Choosing an approach

Baselines first: Microsoft security baselines and CIS Benchmarks already set safe values for most defence-relevant keys and restrict registry editing tools. Applying a baseline is cheaper than hand-tuning ACLs. See the Microsoft Security Baselines and Security Compliance Toolkit Guide and CIS Benchmarks Guide.
Targeted ACL fixes second: scan for weak service key ACLs and third-party software keys that grant write to broad groups. These are the findings baselines do not touch.
Regedit restriction is a speed bump: ATT&CK lists restricting registry editor use through Group Policy, but that setting governs the tools, not the keys. It changes no ACL, so do not count it as access control.
Small estates: baseline plus LSA Protection plus a scheduled scan for writable service keys covers the high-priority rows.
Large estates: enforce through Group Policy or MDM, and add configuration drift reporting so that re-loosened keys after software installs are caught.

Implementation: a phased rollout

Inventory weak keys: enumerate every key under HKLM\SYSTEM\CurrentControlSet\Services and report any ACE granting KEY_SET_VALUE, KEY_CREATE_SUB_KEY, WRITE_DAC or WRITE_OWNER to non-administrative principals. Do the same for the NetworkProvider, Lsa, W32Time and Terminal Services keys named in the table.
Export before changing: export key ACLs (for example with PowerShell Get-Acl output saved per key) so every change has a rollback.
Fix service keys: remove broad write on service keys, working with the software owner, and test service start, update and uninstall in a pilot ring.
Apply the baseline: deploy the Microsoft or CIS baseline through Group Policy or MDM in audit-then-enforce rings.
Enable LSA Protection: audit mode first, review events 3065 and 3066, then enforce, choosing the UEFI lock for high-value servers once compatibility is proven.
Turn on scoped auditing: add SACLs on the short list of keys and forward events centrally.
Re-scan after every software deployment: installers are the most common source of new weak ACLs.

Verifying and measuring

Microsoft's Audit Registry subcategory generates events including 4657 (a registry value was modified), 4663 (an attempt was made to access an object) and 4670 (permissions on an object were changed), but only for keys with a SACL. Microsoft strongly recommends planning a registry monitoring policy and SACLs before enabling it. Sysmon adds event 12 (registry object create and delete), 13 (registry value set, with the value recorded for DWORD and QWORD types) and 14 (key and value rename), filtered by rules in its configuration. Monitoring design is covered in the Sysmon Guide and the Windows Event Log Guide.

Service keys with non-administrator write rights (target zero), trended by software package.
Hosts with LSA Protection enforced, confirmed by WinInit event 12, as a percentage of Windows estate.
Baseline compliance for registry settings per device group.
Event 4670 permission changes on watched keys per month, with every one reviewed.
Time from a new weak ACL appearing (scan) to remediation.

Common failure patterns

Trusting installers. Third-party software that grants Users or Everyone full control on its service key reopens T1574.011 on every host it reaches.
Counting the regedit block as protection. It does not change any key's ACL.
Disabling LSA Protection to fix a plug-in. An unsigned password filter or smart card driver blocks enforcement; teams turn the feature off rather than replacing the component.
Auditing whole hives. SACLs on HKLM\SOFTWARE generate noise that buries the 4670 and 4657 events that matter.
Forgetting the service object. Fixing the registry key but not the service DACL leaves sc.exe config open.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	CM-5 Access Restrictions for Change; CM-6 Configuration Settings	Who can change system configuration; enforced baselines
NIST SP 800-53 Rev. 5	AC-3 Access Enforcement; AC-6 Least Privilege	Key ACLs and least privilege on configuration
NIST SP 800-53 Rev. 5	AU-9 Protection of Audit Information	Keys that control event logging
NIST CSF 2.0	PR.PS-01; PR.AA-05; DE.CM-09	Configuration management, permissions enforcement, monitoring software and runtime environments
ISO/IEC 27001:2022 Annex A	A.8.9 Configuration management	Secure configurations established and monitored
MITRE D3FEND	D3-SCP System Configuration Permissions	The defensive technique D3FEND relates to M1024

Related mitigations: M1022 Restrict File and Directory Permissions, M1026 Privileged Account Management, M1028 Operating System Configuration, M1047 Audit and M1052 User Account Control. All are listed in the MITRE ATT&CK Mitigations hub.

Practitioner checklist

Scan every service key for write, WRITE_DAC or WRITE_OWNER held by non-administrators, and fix findings.
Check service object DACLs for SERVICE_CHANGE_CONFIG granted to non-administrators.
Lock down NetworkProvider\Order, Lsa, W32Time and Terminal Services parameter keys to administrators.
Apply a Microsoft or CIS security baseline through Group Policy or MDM.
Enable LSA Protection after an audit-mode compatibility check, and verify with WinInit event 12.
Move service accounts with stored passwords to gMSA where possible.
Put SACLs on a short list of security-relevant keys and forward 4657 and 4670 events.
Disable the Remote Registry service where it is not needed.
Export ACLs before every change and re-scan after every software deployment.

M1024 Restrict Registry Permissions: Locking Down the Registry Keys Attackers Abuse