Most Windows persistence and many privilege escalation tricks need one thing: write access to a configuration store that the operating system trusts, and on a typical estate far too many accounts and processes have it. MITRE D3FEND names the countermeasure System Configuration Permissions (D3-SCP) and defines it as "Restricting system configuration modifications to a specific user or group of users." It sits under the Harden tactic as a child of Platform Hardening (D3-PH), and its single artefact relation is that it restricts the System Configuration Database, whose only sub-artefact in D3FEND is the Windows Registry. This card explains what D3-SCP covers, which ATT&CK techniques D3FEND relates to it, how to set and audit registry permissions, how to prove the restrictions hold, and where they stop helping. It is written for endpoint engineers, Windows administrators and detection teams; the ATT&CK mitigation view is in M1024 Restrict Registry Permissions, which this page links rather than repeats.
Key takeaways
- It is an access control on configuration, not a detection. D3-SCP limits who can change the system configuration database. Monitoring is a separate companion step that tells you whether the limits are being tested.
- The registry is the practical target. D3FEND's only named sub-artefact is the Windows Registry, and its single reference is a Microsoft article on changing registry values and permissions from a script.
- Write rights are the risk. KEY_SET_VALUE, KEY_CREATE_SUB_KEY, WRITE_DAC and WRITE_OWNER on service, autostart, COM and debugger keys are what persistence techniques need; read rights matter mainly where secrets are stored.
- Administrators bypass it. Registry ACLs stop standard users and low-privilege services, not an attacker who already holds local administrator or SYSTEM, so D3-SCP only works alongside privileged account management.
- Verify with ACL baselines and audit events. A scheduled ACL diff on critical keys, plus events 4657 and 4670 from the Audit Registry subcategory, shows whether permissions drifted or were changed.
D3-SCP at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-SCP (d3f:SystemConfigurationPermissions) |
| Tactic | Harden |
| Parent technique | Platform Hardening (D3-PH), synonyms "Endpoint Hardening" and "System Hardening" |
| Siblings under Platform Hardening | Bootloader Authentication, Disk Encryption, Driver Load Integrity Checking, File Encryption, Hardware-based Write Protection, Physical Enclosure Hardening, Radiation Hardening, Software Update, TPM Boot Integrity |
| Digital artefact | System Configuration Database, "A database used to hold system configuration data" (D3FEND relation: restricts). Sub-artefact: Windows Registry |
| D3FEND reference | Microsoft: How to change registry values or permissions from a command line or a script (KB 264584) |
| Knowledge base article | None yet: D3FEND 1.6.0 marks the entry "write kb-article" (checked November 2026) |
| Main limitation | Does not constrain administrators or SYSTEM, who can take ownership of any key |
How it works
D3FEND gives only the one-line definition, so the mechanics come from the platform. Every registry key carries a security descriptor with an owner, a discretionary ACL (DACL) and an optional system ACL (SACL). Microsoft's registry access rights documentation lists the rights that matter for hardening:
| Right | What it allows | Why it matters for D3-SCP |
|---|---|---|
| KEY_SET_VALUE | Create, delete or set a registry value | Changing a service ImagePath, an IFEO Debugger value or a COM server path |
| KEY_CREATE_SUB_KEY | Create a subkey | Adding a new service, a new IFEO entry or a per-user COM registration |
| WRITE_DAC | Modify the key's DACL | Granting yourself write access, which defeats the control |
| WRITE_OWNER | Change the key's owner | Taking ownership, then rewriting the DACL |
| DELETE | Delete the key | Removing security configuration |
| KEY_QUERY_VALUE, KEY_READ | Read values | Relevant where credentials or keys are stored in the registry |
| ACCESS_SYSTEM_SECURITY | Read or write the SACL | Turning off auditing on a key |
Microsoft notes that a key created without an explicit security descriptor inherits its ACLs from its direct parent. That inheritance is the usual source of weak permissions: a vendor installer creates a service or software key under a parent that grants broad write access, and the child inherits it. D3-SCP in practice means finding those keys, removing write, DACL and owner rights for anyone who does not need them, and keeping the result from drifting.
The reference D3FEND cites describes Regini.exe, a Resource Kit tool whose permission changes replace the existing ACL rather than edit it. Microsoft states the Windows 2000 version is no longer supported. Current estates set the same permissions through Group Policy security settings, configuration management or PowerShell ACL cmdlets, as the M1024 Restrict Registry Permissions guidance also describes.
ATT&CK techniques D3FEND relates to D3-SCP
Relationship type: inferred only. D3FEND has no hand-made ATT&CK mapping for D3-SCP. The site lists these techniques because they act on the same artefact the countermeasure restricts, the System Configuration Database, and labels them "inferred and experimental" (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20. The last column is NHI Mgmt Group's view of how much a permission change actually helps.
| ATT&CK ID | Technique | D3FEND relation (inferred via artefact) | Practical effect of D3-SCP (our view) |
|---|---|---|---|
| T1543.003 | Windows Service | Modifies System Configuration Database | High where a service key is writable by non-administrators; locking service keys blocks ImagePath and failure command changes |
| T1546.012 | Image File Execution Options Injection | Modifies System Configuration Database | High: IFEO keys under HKLM should be writable only by administrators |
| T1546.015 | Component Object Model Hijacking | Modifies System Configuration Database | Partial: HKLM COM registrations can be locked, but per-user registrations under HKCU are writable by the user by design |
| T1137.006 | Add-ins | May modify System Configuration Database | Partial: machine-wide add-in keys can be restricted; per-user add-in settings remain user-writable |
| T1218.014 | MMC | May modify System Configuration Database | Low: restricts snap-in registration, not execution of .msc files |
| T1564.003 | Hidden Window | May modify System Configuration Database | Low: only where the hiding relies on a registry setting |
| T1564.005 | Hidden File System | May modify System Configuration Database | Low: only where configuration of the hidden store is written to the registry |
| T1548.004 | Elevated Execution with Prompt | Creates System Configuration Database | Low on Windows: ATT&CK lists this technique for macOS only, where the configuration store is not the registry |
| T1207 | Rogue Domain Controller | Modifies System Configuration Database | Indirect: the relevant permissions are on Active Directory configuration objects, governed by directory ACLs and privileged group membership |
| T1552.002 | Credentials in Registry | Accesses System Configuration Database | Medium: read restrictions help, but the better fix is not storing credentials in the registry at all |
| T1012 | Query Registry | Accesses System Configuration Database | Low: most configuration must stay readable for software to work |
| T1614.001 | System Language Discovery | Queries System Configuration Database | Very low: language settings are read by every application |
| T1112 | Modify Registry | Sub-artefact: modifies Windows Registry | High for the keys that are locked; the umbrella technique for all registry tampering |
| T1553.006 | Code Signing Policy Modification | Sub-artefact: may modify Windows Registry | Medium: restricts registry-based policy changes; boot configuration changes are covered by other controls |
D3FEND also relates the ICS technique T0894 System Binary Proxy Execution through the same artefact. Treat the table as a list of where configuration write access matters, not as a coverage claim. Technique detail is in MITRE ATT&CK T1112 Modify Registry, the T1543 Create or Modify System Process Defensive Guide, the T1546 Event Triggered Execution Defensive Guide and the MITRE ATT&CK T1552 Unsecured Credentials Guide.
Where it is implemented
| Implementation class | What it provides | Fits when |
|---|---|---|
| Group Policy registry security settings | DACLs on named keys pushed to domain-joined machines from Computer Configuration security settings | Active Directory joined Windows estates; see the Group Policy Security Guide |
| Security baselines | Vendor and CIS baseline settings that include registry permissions and the policy values written to the registry | You want a maintained starting set; see the CIS Benchmarks Guide |
| Configuration management and scripts | PowerShell ACL cmdlets or desired-state tooling that sets and re-asserts key ACLs | Cloud-managed or non-domain fleets, and for drift correction |
| Endpoint management platforms | Configuration profiles that set registry-backed policy values and report compliance | Modern-managed Windows devices |
| Endpoint protection tamper features | Protection of the security product's own registry keys from local change | Always on for the security stack itself |
| Non-Windows equivalents | Root ownership and restrictive modes on system configuration files, with privilege elevation controlled through sudo policy | Linux and macOS hosts, where the configuration store is files, not a registry |
Where identity fits
The accounts that can change system configuration are privileged identities, and many are non-human: service accounts that run installers, deployment agents, management tools and backup software. A service running as LocalSystem can take ownership of any key and rewrite its ACL, and a deployment account in the local Administrators group on every host makes D3-SCP irrelevant for anyone who steals its credentials. Review which service and automation accounts hold local administrator rights as part of the same work; the M1026 Privileged Account Management page covers that side.
Implementation steps
- Pick the critical keys. Start with the keys the related techniques write to: HKLM\SYSTEM\CurrentControlSet\Services, the Image File Execution Options key, the Run and RunOnce keys under HKLM, machine-wide COM CLSID registrations, Office add-in keys, and the configuration keys of security tools.
- Baseline the current ACLs. Export the security descriptor (SDDL) of each key from a reference build and from a sample of production hosts. Any grant of KEY_SET_VALUE, KEY_CREATE_SUB_KEY, WRITE_DAC or WRITE_OWNER to Users, Authenticated Users, Everyone or a non-administrative service group is a finding.
- Fix inherited weaknesses at the source. Correct the parent key's DACL where installers keep creating weak children, and raise packaging defects with the software vendor.
- Turn on auditing before enforcing. Enable the Audit Registry advanced audit subcategory and add SACLs for Set Value, Write DAC and Write Owner on the critical keys only. Microsoft recommends defining SACLs by role first and enabling on critical computers first, because broad SACLs fill the log.
- Pilot the restricted ACLs. Apply the new permissions to a pilot ring for two to four weeks. Watch for application errors and audit failures, which reveal legitimate software that writes to a key you locked.
- Roll out and re-assert. Deploy through Group Policy or configuration management so that drift is corrected on the next refresh, not only reported.
- Keep a rollback. Store the original SDDL per key. Rolling back means re-applying the saved descriptor, not granting Full Control to make an error go away. Note that some tools replace ACLs wholesale, so capture the existing ACL before every change.
How to verify it works
| Check | Data source | What good looks like |
|---|---|---|
| ACL drift scan | Scheduled export of SDDL on critical keys compared with the baseline | No unapproved write, DACL or owner rights |
| Value change monitoring | Event 4657 (a registry value was modified), which needs Set Value auditing in the key's SACL; or Sysmon event 13 (Value Set) | Changes only from expected processes such as installers and the management agent |
| Permission change monitoring | Event 4670 (permissions on an object were changed), which needs Write DAC or Write Owner auditing on the key and records old and new SDDL | No permission changes outside change windows |
| Key create and delete | Sysmon event 12 (object create and delete) and event 14 (rename) | New service and IFEO entries match approved software |
| Negative test | An approved test from a standard user context attempting to set a value on each locked key | Access denied, with a failure audit recorded |
Microsoft's monitoring recommendations for 4657 and 4670 are the same pattern: list the processes expected to change each critical key and alert on any other process name, especially one running outside System32 or Program Files. Example metrics (NHI Mgmt Group suggestions, not a standard): percentage of hosts whose critical-key ACLs match the baseline (target close to 100%), count of unexpected 4670 events per month (target zero), time to correct ACL drift (within one policy refresh cycle), and number of service and automation accounts holding local administrator rights (falling).
Limits, bypasses and failure patterns
- Administrator and SYSTEM access: anyone with these rights can take ownership and rewrite the DACL. D3-SCP raises the bar for standard users and limited services only, so it must be paired with removal of unnecessary local administrator rights.
- Per-user hives: HKCU is writable by its user by design. Per-user COM hijacking and per-user add-ins sit outside machine-level ACLs and need detection or application control instead.
- Offline edits: registry hives on an unencrypted disk can be edited offline, ignoring every ACL. Disk encryption and boot integrity close this path; see D3-TBI TPM Boot Integrity.
- Weak service binary paths: a locked service key still runs whatever file sits at a writable ImagePath. File and directory permissions matter equally; see M1022 Restrict File and Directory Permissions.
- Breaking software: locking keys that applications legitimately write causes failures that get fixed by granting Everyone Full Control. Pilot rings and audit-first rollout prevent this.
- Auditing switched off: an attacker with ACCESS_SYSTEM_SECURITY can remove SACLs, so forward events off-host and alert on audit policy changes.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-5 Access Restrictions for Change | The control D3-SCP implements for configuration stores |
| NIST SP 800-53 Rev 5 | CM-6 Configuration Settings, AC-6 Least Privilege | Baseline settings and limiting who holds write rights |
| NIST SP 800-53 Rev 5 | AU-12 Audit Record Generation | Registry auditing used for verification |
| NIST CSF 2.0 | PR.PS-01, PR.AA-05 | Configuration management practices; access permissions managed and enforced |
| MITRE ATT&CK mitigation | M1024 Restrict Registry Permissions | The ATT&CK counterpart, which also lists registry auditing and baseline tools |
| MITRE D3FEND | D3-PH, D3-SCP | Parent and technique |
Related countermeasures
- Registry Key Deletion (D3-RKD): the eviction counterpart that removes malicious keys once found. See D3-RKD Registry Key Deletion.
- Driver Load Integrity Checking (D3-DLIC) and TPM Boot Integrity (D3-TBI): sibling Platform Hardening techniques that protect the boot and kernel path that registry ACLs cannot.
- Software Update (D3-SU): a sibling that removes vulnerable components whose installers often create weak keys.
- The parent, Platform Hardening (D3-PH), is summarised in the MITRE D3FEND Guide.
Practitioner checklist
- List the critical keys: Services, IFEO, HKLM Run and RunOnce, machine COM registrations, Office add-ins, security tool keys.
- Export and store the baseline SDDL for each key.
- Remove KEY_SET_VALUE, KEY_CREATE_SUB_KEY, WRITE_DAC and WRITE_OWNER from non-administrative principals.
- Enable the Audit Registry subcategory with targeted SACLs only.
- Collect 4657, 4670 and Sysmon 12, 13 and 14 events off-host.
- Deploy permissions through Group Policy or configuration management so drift is corrected.
- Remove unnecessary local administrator rights from users, service and automation accounts.
- Stop storing credentials in the registry rather than relying on read ACLs.
- Run a negative test per locked key after each baseline change.
Standards and references
- MITRE D3FEND: System Configuration Permissions (D3-SCP)
- MITRE ATT&CK: M1024 Restrict Registry Permissions
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (CM-5)
- Microsoft Learn: Registry key security and access rights
- Microsoft Learn: How to change registry values or permissions from a command line or a script
- Microsoft Learn: Audit Registry
- Microsoft Learn: Event 4657, a registry value was modified
- Microsoft Learn: Event 4670, permissions on an object were changed
- Microsoft Learn: Sysmon
Related NHI Mgmt Group resources: M1024 Restrict Registry Permissions · MITRE ATT&CK T1112 Modify Registry · Group Policy Security Guide · Least Privilege Techniques Guide · MITRE D3FEND Guide