Modify Registry (T1112) is a technique in MITRE ATT&CK that spans two tactics, defense impairment and persistence. MITRE lists Windows as the platform.
The registry is a configuration database that holds settings for the OS and for installed software. Almost every intrusion on Windows touches it, either as a goal or as a side effect of another technique. That makes it both a rich source of detection signal and a noisy one.
How attackers use it
MITRE describes interacting with the Windows Registry as part of a variety of other techniques, to aid in defense evasion, persistence and execution.
Several points from MITRE show the range:
- Access depends on permissions. Some keys need administrator rights. The built-in command line utility Reg can modify the registry locally or remotely. Other tools, including remote access tools, can reach it through the Windows API.
- Hiding data. The registry may be modified to hide configuration information or payloads, through obfuscated files or information.
- Weakening defenses. MITRE lists examples such as enabling macros for all Microsoft Office products, allowing privilege escalation without alerting the user, increasing the maximum number of allowed outbound requests, and setting systems to store plaintext credentials in memory.
- Remote modification. The registry of a remote system may be modified to help run files as part of lateral movement. This needs the remote registry service running on the target, usually valid accounts, and access to the remote system's SMB and Windows admin shares for RPC communication.
- Pseudo-hidden keys. Adversaries may hide keys, for example by prepending key names with a null character. This causes an error or is ignored when read through Reg or other utilities using the Win32 API. The hidden keys can then conceal payloads or commands used for persistence.
The takeaway is that registry changes are a means, not a single behavior. Detection has to be about which keys change, who changed them and what ran afterwards.
How to detect it
MITRE's strategy is Behavior-Based Registry Modification Detection on Windows. The analytic describes a chain: abnormal registry modifications through the command line, PowerShell, WMI or direct API calls, especially to keys tied to persistence, privilege escalation or defense evasion, potentially followed by a service restart or a process starting. MITRE's examples include editing Notify, Userinit and Startup keys, and disabling SafeDllSearchMode.
What to log:
- Sysmon registry events: event ID 12 for key create and delete, event ID 13 for value set, and event ID 14 for key and value rename. A tuned Sysmon configuration is the most practical source.
- Process creation with command lines (Security event 4688 or Sysmon event ID 1), to catch reg.exe and PowerShell registry cmdlets.
- Security event 4657 for a registry value modified, which needs object access auditing and a system access control list on the keys of interest.
- Remote registry service starts and incoming administrative share connections, for the remote case.
Targets worth watching closely:
- Run and RunOnce keys, and similar autostart locations.
- Winlogon values such as Userinit.
- Service configuration keys.
- Security settings that control credential storage and Office macro behavior.
- Keys with unusual or non-printable characters in their names.
Do not try to alert on every change. Build a short list of sensitive keys, alert on writes to them by anything other than your management tooling, and use the broader stream for hunting.
How to reduce the risk
MITRE lists one mitigation, restrict registry permissions: ensure proper permissions are set for registry hives to stop users from modifying keys for system components that could lead to privilege escalation.
Supporting steps that follow from the description:
- Keep users out of local administrator groups so most sensitive keys are not writable.
- Disable the remote registry service where it is not needed, which removes the remote path MITRE describes.
- Manage security-relevant settings through group policy or device management, and alert when the live value drifts from the policy.
- Use application control so unauthorized tools cannot run Reg-like functions from user-writable paths.
Check your own environment
- Do you collect registry events for autostart and security-relevant keys?
- Do you know which of your tools legitimately write those keys?
- Is the remote registry service running on servers and workstations that do not need it?
- Can you spot registry key names containing non-printable characters?
- Do you detect policy drift for credential protection and Office macro settings?
Read-only commands:
# Windows (cmd): list autostart values under the machine Run key
reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Run"
# Windows (cmd): list autostart values for the current user
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run"
# Windows (PowerShell): check the state of the Remote Registry service
Get-Service -Name RemoteRegistry
Unknown entries in the Run keys, or a running Remote Registry service on a machine that does not need it, are the first things to chase.
Quick check
Which Sysmon event IDs cover registry changes?
Event ID 12 for key create and delete, 13 for value set, and 14 for key and value rename.
What does MITRE say about hidden registry keys?
Prepending key names with a null character can cause an error or be ignored when read through Reg or other Win32 API tools, which lets adversaries conceal persistence payloads.
What does remote registry modification require?
The remote registry service running on the target, usually valid accounts, and access to SMB and Windows admin shares for RPC communication.
Sources
- MITRE ATT&CK, Modify Registry (T1112)
