MITRE ATT&CK T1112 Modify Registry: Detecting Control Tampering

Most Windows security controls are, in the end, a registry value, and an intruder with the right access can switch a control off with one write that leaves no new file behind. MITRE ATT&CK T1112 Modify Registry covers interacting with the Windows Registry to hide configuration or payloads, weaken defences and support persistence and lateral movement. In ATT&CK v20 it belongs to the Defense Impairment (TA0112) and Persistence tactics, and ATT&CK records its use by a long list of groups and malware families. This guide is about the tampering itself: which security-relevant values intruders change, how to collect registry telemetry without drowning in it, how to protect the values that matter and how to restore them after an incident. It is for detection engineers, Windows platform owners and incident responders. Autostart keys are covered in the T1547 Boot or Logon Autostart Execution Defensive Guide, and stopping security tools in the T1685 Disable or Modify Tools Defensive Guide.

Key takeaways

• The registry is a control plane, not a data store. Values that turn on plaintext credential caching, disable Defender, switch off firewalls or silence event log channels are all single writes, so watch a short list of security values rather than the whole registry.
• Telemetry must be scoped. Sysmon Event IDs 12, 13 and 14 and Security event 4657 can see registry changes, but only for the keys you configure; a targeted list of security values gives high signal with low volume.
• Prevention beats detection for the worst values. Defender tamper protection blocks registry changes to Defender settings, and least privilege removes the administrator rights most of these values need.
• Remote registry access is lateral movement. ATT&CK notes that remote modification needs the Remote Registry service plus valid accounts and SMB admin share access, so disabling the service where unused closes a path.
• Recovery means restoring values, not just removing malware. A cleaned host with WDigest caching still on, or an event channel still disabled, stays exposed; reassert a known-good baseline after every incident.

How the technique works

ATT&CK describes T1112 as interacting with the Registry "to aid in defense evasion, persistence, and execution". Access depends on account permissions: HKCU is writable by the user, while most security values under HKLM need administrator rights. The technique shows up in four distinct ways, each with different detection logic.

ATT&CK also notes that registry key names can be prefixed with a null character, which causes an error or is ignored when read through Reg or other Win32 API tools, letting persistence commands hide from casual inspection. Payload storage in the registry is mapped to T1027 Obfuscated Files or Information.

The values intruders change

The CISA and FBI advisory on LockBit 3.0 (AA23-075A) is a useful real-world list, because it documents a ransomware affiliate toolset that sets many security values in one pass. The table combines values from that advisory with credential-related values that defenders should watch as a matter of course.

Several of these sit under \Policies\, so the same change can arrive through a malicious Group Policy Object. If the writing process is the Group Policy client rather than a script host, pivot to T1484 Domain or Tenant Policy Modification.

Detection: collecting registry telemetry that works

Registry auditing can generate huge volumes, so the design choice is which keys to collect, not whether to collect. There are two native sources and they complement each other.

Microsoft's 4657 guidance recommends monitoring every 4657 event for sensitive or critical keys and alerting when the writing process is outside System32 or Program Files. ATT&CK's detection strategy for this technique (Behavior-Based Registry Modification Detection on Windows) looks for a behaviour chain: an abnormal registry modification through the command line, PowerShell, WMI or direct API calls on persistence, privilege escalation or defence keys, followed by a service restart or process execution.

Detection rules worth building first:

• Any write to a security policy value: Defender, firewall, SmartScreen, UAC, WDigest and event channel values from the table. These change rarely in a managed estate, so alert on every change that does not come from your management agent.
• Value set to a weakening state: use Sysmon Event ID 13 data to alert specifically when a value moves to the insecure setting, for example UseLogonCredential to 1.
• Unexpected writer: reg.exe, powershell.exe or wmiprvse.exe writing to HKLM policy keys, especially from a user session. See the PowerShell Security Guide for script block logging that captures the command.
• Burst of security changes: five or more security values changed by one process within minutes is a strong ransomware precursor.
• Large or encoded values: hunt for values over a size threshold or containing Base64 or PowerShell, and for key names that standard tools fail to read.
• Remote registry use: the Remote Registry service starting on a host where it is normally stopped, combined with inbound SMB from a non-admin source.

The Sysmon Guide and Sigma Rules Guide cover configuration and rule portability.

Prevention and hardening

Choosing an approach

• Small organisation, no SIEM: turn on tamper protection, remove local admin rights, and let Intune or Group Policy reassert security values. That alone covers most of the table.
• Mid-size with a SIEM: add a Sysmon configuration scoped to 20 to 40 security values, with alerting on Event ID 13 transitions to insecure states.
• Large estate with EDR: use EDR registry telemetry for hunting, but still keep a short, explicit rule list for security values so coverage does not depend on vendor defaults; see the EDR Tuning and Exclusions Management Guide.
• Sysmon versus 4657: Sysmon is easier to scope centrally through one configuration file; 4657 needs a SACL per key but records the old value and is native. Many teams use Sysmon broadly and 4657 SACLs on the handful of most sensitive keys.

Implementation: a phased rollout

1. Define the watch list (week 1): start from the table above, add values from your own security baselines (for example the CIS or Microsoft security baseline values you enforce), and record the intended value for each.
2. Collect in audit mode (weeks 2 to 3): deploy Sysmon include rules and SACLs to a pilot group. Record which processes legitimately write each value: your management agent, Windows Update, the Defender platform.
3. Tune (week 4): allow-list the known writers by signed process path, not by name alone.
4. Alert (week 5 onwards): enable alerting for writes to insecure states and for unknown writers. Rollback is removing the rule or the Sysmon include; neither changes endpoint behaviour.
5. Harden: enable tamper protection, disable Remote Registry where unused and remove standing local admin. Test line-of-business applications on a pilot ring first.
6. Exercise: on a test host, set a benign watched value to its insecure state and measure detection time.

Response and recovery

• Scope by value, not host: query the whole estate for each tampered value. Ransomware affiliates often push the same changes to many hosts through policy or remote tooling.
• Find the writer: the account behind the change is compromised. If changes came through Group Policy, inspect and restore the GPO before touching hosts, or the tampering returns at the next refresh.
• Restore the baseline: reapply security values from your configuration source of truth, then confirm with a fresh query. Re-enable event channels before relying on host logs for the investigation.
• Assume credential exposure: if WDigest caching or UAC settings were weakened, reset credentials of every account that logged on to the host while the setting was active.

For the full response sequence after ransomware precursors, see the EDR Tampering and BYOVD Response Playbook.

Where identity fits

Almost every high-impact registry change needs an administrator identity, and remote changes need valid accounts with admin share access (MITRE ATT&CK T1078 Valid Accounts Guide). Shared local administrator passwords, deployment service accounts with local admin on every endpoint, and management agents running as SYSTEM are the identities that make T1112 scale. Unique local admin passwords, tiered admin accounts and monitoring of service account interactive use limit how far one stolen identity can tamper.

Measuring it

• Watch-list coverage: percentage of Windows endpoints sending registry events for the security value list.
• Tamper protection coverage: percentage of Defender-managed devices with tamper protection on.
• Baseline drift: number of hosts where a watched value differs from intended, per week (target zero).
• Unknown writers: count of security-value writes by processes not on the allow list, per month.
• Standing local admins: number of users with persistent local administrator rights, trending down.

Common failure patterns

• Collecting everything or nothing: full registry auditing is switched off after a week because of volume, leaving no coverage. Scope to security values instead.
• Monitoring Run keys only: persistence keys are well covered while policy values for Defender, firewall and logging have no rule.
• Restoring hosts but not the GPO: tampered values return at the next policy refresh.
• Allow-listing by process name: an attacker copies a tool to a name on the allow list; use signed path and signer.
• Treating disabled logging as an outage: a channel switched off by a registry change is an incident signal, not a logging fault. See the Windows Event Log Guide.

Framework mapping

Practitioner checklist

• Maintain a watch list of security registry values with the intended setting for each.
• Collect Sysmon Event IDs 12, 13 and 14 for those keys, and 4657 with SACLs on the most sensitive.
• Alert on any transition to an insecure value and on writes by unknown processes.
• Turn on Defender tamper protection on every managed device.
• Remove standing local admin rights and use unique local administrator passwords.
• Disable the Remote Registry service where no tool needs it.
• After an incident, restore GPOs first, then reapply and verify host values.
• Reset credentials used on hosts where WDigest caching was enabled.

Standards and references

• MITRE ATT&CK: Modify Registry (T1112)
• CISA: #StopRansomware: LockBit 3.0 (AA23-075A)
• Microsoft Sysinternals: Sysmon
• Microsoft: 4657(S) A registry value was modified
• Microsoft: Protect security settings with tamper protection
• Microsoft: Credentials protection and management
• Microsoft Tech Community: The importance of KB2871997 and KB2928120 for credential protection (UseLogonCredential)
• Microsoft MS-GPSB: EnableLUA
• Microsoft MS-GPSB: ConsentPromptBehaviorAdmin
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: ATT&CK Stealth and Defense Impairment Tactics Guide · T1685 Disable or Modify Tools Defensive Guide · Persistence Techniques Guide · LockBit Threat Actor Profile · MITRE ATT&CK T1037 Boot or Logon Initialization Scripts