Detecting modify registry (T1112)

What is modify registry (T1112)?

Modify registry (T1112) is a MITRE ATT&CK® defense evasion technique where adversaries interact with the Windows Registry to store configuration data, hide malicious payloads, disable security controls, or alter system behavior in ways that support their attack objectives. The Windows Registry is a central database controlling nearly every aspect of Windows system behavior, making it both a high-value target for attackers and a rich source of forensic evidence for defenders.

Registry modifications for defense evasion range from subtle (disabling a single logging key) to comprehensive methods, such as importing entire registry hive files that reconfigure multiple security settings simultaneously. Log360 maps 70+ pre-built correlation rules to T1112, covering the most commonly abused registry paths and the tools attackers use to reach them: reg.exe, regedit.exe, PowerShell registry cmdlets, and direct API access through malicious binaries.

How attackers modify the registry

Attackers use registry modification across multiple attack phases, with distinct objectives and target paths at each stage:

1. Security tool disabling: Modifying registry values under HKLM\SOFTWARE\Policies\Microsoft\Windows Defender or HKLM\SYSTEM\CurrentControlSet\Services to disable Windows Defender, modify audit policies, or stop security services from starting on reboot. These modifications may survive system restarts, creating a persistent blind spot.
2. Remote access configuration: Modifying RDP-related registry keys (HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\fDenyTSConnections) to enable Remote Desktop Protocol access on hosts where it was previously disabled, creating a persistent remote access channel. RestrictedAdminMode registry tampering enables pass-the-hash attacks over RDP.
3. Payload storage: Storing encoded or compressed malicious payloads as registry values in obscure keys, using PowerShell or reg.exe to retrieve and execute them later. This technique eliminates the need for malicious files on disk, defeating file-based AV scanning.
4. Persistence via run keys: Adding entries to HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce, and similar keys to execute malicious commands or scripts on every user logon or system startup.
5. AppCompat shimming (ShimCache manipulation): Flushing or modifying ShimCache (Application Compatibility Cache) registry entries to disrupt forensic timeline analysis, as ShimCache records the history of executed applications and is a standard forensic artifact.
6. Registry hive import: Using reg import [file.reg] to import an entire registry file that makes multiple security-relevant changes simultaneously, often used to batch-apply configuration changes that disable multiple defenses at once.

High-value registry targets

Understanding which registry areas are most commonly targeted helps prioritize detection rule coverage and investigation scope. Log360's T1112 rules are organized around three primary risk categories:

Defense disabling registry paths

Modifications to Windows Defender policy keys, audit configuration keys (HKLM\SYSTEM\CurrentControlSet\Services\EventLog), and UAC control keys (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA) are high-confidence attack indicators. A Defender exclusion added through the registry at an unusual time is almost always malicious. Log360's Reg Add Suspicious Paths rule targets these modification patterns directly.

Remote access enablement paths

RDP configuration keys are targeted specifically to create persistent remote access. The RestrictedAdminMode registry value tampering is especially significant, as enabling this mode allows pass-the-hash authentication over RDP, dramatically expanding what an attacker can do with captured NTLM hashes. Log360's Potential Tampering With RDP Related Registry Keys Via Reg.EXE rule fires on these specific modifications.

Forensic disruption paths

ShimCache (Application Compatibility Cache) at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache is a forensic gold mine, as it records a history of every executable that ran on the system. Attackers flush ShimCache to remove evidence of their tool execution before leaving a host. Log360's ShimCache Flush rule specifically detects this anti-forensic registry modification.

Detection indicators for T1112

Registry modification detection requires monitoring both the modification actions themselves and the tools used to make them:

Sysmon registry events (Event ID 12, 13, 14)

Sysmon provides comprehensive registry monitoring through three event types: Event ID 12 (registry key/value created or deleted), Event ID 13 (registry value set), and Event ID 14 (registry key or value renamed). These events include the process that made the change, the registry path, and the new value, providing the full context needed to distinguish legitimate administrative changes from attack activity. Log360's T1112 rules use Sysmon registry events as the primary detection primitive.

Process-based detection (Event ID 4688)

Even without Sysmon, process creation monitoring captures reg.exe and PowerShell registry modification commands with their full command-line arguments. A command like reg add HKLM\SOFTWARE\Policies\Microsoft\Windows Defender /v DisableAntiSpyware /t REG_DWORD /d 1 is unambiguous regardless of what user executed it. Log360's registry rules trigger on these command-line patterns as well as on Sysmon registry events.

Registry hive file access

Accessing .reg or .hive files using uncommon applications, especially command-line tools, script hosts, or processes with no legitimate reason to interact with registry export files, is an indicator of bulk registry manipulation. The Access To .Reg/.Hive Files By Uncommon Applications rule targets this pattern.

Log360 detection rules for T1112

Log360 ships with 70+ pre-built correlation rules directly mapped to Modify registry (T1112). Rules cover suspicious registry path modification, security tool disabling via registry, RDP configuration tampering, persistence via run keys, and anti-forensic registry manipulation:

Investigation steps

When Log360 fires a T1112 registry modification alert, follow this sequence to assess the impact of the modification, identify the attacker's objective, and determine the scope of changes made:

1. Identify the modification account and process: Determine which user account and process made the registry change. Service accounts, local system, and named administrative accounts all have distinct expected modification patterns. An unexpected account modifying security-relevant keys is a high-confidence indicator.
2. Assess the modification's security impact: Determine what the modified registry value controls. A change to a Windows Defender policy key may have disabled real-time protection. An RDP configuration change may have enabled remote access. A run key addition establishes persistence. Prioritize investigation based on the security impact of the specific key modified.
3. Check for correlated activity: Registry modifications for defense evasion are typically followed by primary attack activity, including malware execution, lateral movement, or data staging. Review the 30-60 minute window after the modification for suspicious process creation, network connections, or authentication events that indicate the attacker proceeded after disabling defenses.
4. Enumerate all recent registry changes on the affected host: A single detected modification may be one of many changes made by an attacker. Use Sysmon Event ID 13 data to enumerate all registry modifications on the affected host in the alert timeframe, looking for additional security-relevant path modifications that were not individually alerted.
5. Check for .reg file imports: If the alert involved a reg import operation, identify the .reg file that was imported and examine its contents to understand the full scope of changes made. The .reg file may be a packaged toolkit that applies dozens of security-disabling modifications simultaneously.
6. Verify current registry state: Examine the current values of modified registry keys on the affected host. The alert tells you what was changed, but the current state tells you whether the change persists and whether additional modifications were made after the initial alert.

Response playbook

• Revert security-impacting registry changes immediately: If the modification disabled Windows Defender, modified audit policy, or altered authentication settings, revert the change before any other investigation activity. Operating with compromised security controls while investigating extends attacker access.
• Document the current registry state before reverting: Before reverting, export the modified registry keys to preserve evidence. The current state may include additional attacker-made changes that were not individually alerted, and the registry export preserves all of them for analysis.
• Check persistence registry locations: Enumerate all run key, RunOnce, service, and scheduled task registry entries on the affected host and compare against the known baseline. Registry-based persistence may have been established alongside the defense-evasion modification.
• Audit registry hive file access: If hive files (.hive, .reg) were accessed by unexpected processes, determine whether this was a registry export (SAM, SECURITY hive exfiltration for offline credential harvesting) or import (bulk configuration change). Both warrant immediate escalation.
• Re-enable and verify security controls: After reverting attacker-made changes, verify that Windows Defender is running with real-time protection active, audit policies are configured correctly, and no Defender exclusions added by the attacker remain. Run a full endpoint scan after re-enabling protection.
• Apply registry access controls: After the incident, review which accounts have write access to security-relevant registry keys. Standard user accounts should not have write access to HKLM\SOFTWARE\Policies\Microsoft\Windows Defender or HKLM\SYSTEM\CurrentControlSet\Services. Implement access control list (ACL) restrictions on high-value registry paths.

Frequently asked questions