How do adversaries modify the registry?

Considering how common it is to perform registry operations in Windows and all the different techniques it facilitates, there are many different ways to modify the registry. An adversary has the following, non-exhaustive list of options when modifying the registry:

Win32 APIs, Native APIs, Syscalls

An adversary can interact with registry APIs directly, including RegCreateKey, RegSetValue, [Nt/Zw]CreateKey, and [Nt/Zw]SetValueKey, among others.

Windows Script Host (VBScript/JScript)

Both VBScript and JScript code can perform registry modifications by using the RegWrite method.

Registry modification will occur within the context of the process that executed the VBScript or JScript code: e.g., cscript.exe, wscript.exe, scrcons.exe, etc.

PowerShell

PowerShell has the following built-in cmdlets for performing registry modification: New-Item and Set-ItemProperty.

reg.exe

The built-in reg.exe utility can be used to perform registry modifications both directly on the command line and by importing a text file consisting of desired registry modifications.

Registry modification will occur within the context of reg.exe.

regini.exe

The built-in regini.exe utility can be used to perform registry modifications. It consumes a text file consisting of registry modifications to perform.

Registry modification will occur within the context of regini.exe.

Windows Management Instrumentation (WMI)

The WMI StdRegProv class exposes the following methods for performing registry modification: CreateKey, SetBinaryValue, SetDWORDValue, SetQWORDValue, SetExpandedStringValue, SetMultiStringValue, and SetStringValue.

Registry modification will occur within the context of wmiprvse.exe.

MSI files

MSI files expose a WriteRegistryValues Action to support the creation and modification of registry keys and values.

Registry modification will occur within the context of msiexec.exe.

Associated threats

• ChromeLoader
• BaoLoader

There is no generalized guidance for preventing registry modification. Registry modification needs to occur in Windows, as it is the primary storage mechanism for software configurations.

Tactical prevention is possible in limited scenarios, however, where more restrictive Access Control Lists (ACL) can be defined for specific, targeted registry keys. Registry access is already locked down fairly well, however. For example, the majority of modifications to the HKEY_LOCAL_MACHINE (HKLM) hive requires administrative access. Be mindful, however, that modifying existing registry key ACLs can affect system stability if performed incorrectly. Detection should be a priority over prevention/mitigation beyond the default operating system ACLs.

Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.

Windows Registry

MITRE tracks Windows Registry (DS0024) as a data source for observing registry modification. Windows supports native registry monitoring through the application of System Access Control Lists (SACL), which will log registry modification events as event ID 4657. Vendors can also track registry modification in the kernel using a RegistryCallback routine.

Note: The collection sections of this report showcase specific log sources from Windows events, Sysmon, and elsewhere that you can use to collect relevant security information.

Sysmon event IDs 12, 13, and 14: RegistryEvents

Sysmon is a wonderful tool for collecting registry modification events with its support of RegistryEvent events (event ID 12, 13, and 14).

The following Sysmon configuration snippet can be used to log registry modification. This will log registry events that will be used in the tests below.

Here is the content of an example captured event:

Due to the broad applicability of registry modification for legitimate and malicious purposes, higher-signal detection strategies will entail narrowing the scope of detections to registry modifications targeting specific techniques and/or threats, some of which are outlined above. There can never be a generic, high-signal “registry modification” detection analytic due to the overly broad scope of the registry and its inherent dual-use nature.

To that point, as of this writing, we have 103 detection analytics that look for various flavors of malicious and suspicious registry modifications. Many of them rely on exclusions or regular expressions, and, while they’re effective at Red Canary scale, they’re prohibitively complicated and difficult to synthesize into a report like this one. As such, in lieu of specific pseudo-detectors, we offer the following guidance as a starting point for detection:

Some registry modification utilities are used much less than others and could serve as the basis of a more tool-focused, generic detection. For example, wscript.exe and regini.exe are used relatively infrequently for legitimate purposes.

Depending on the size and maturity of the environment, spending the time to tune out expected activity for run keys can provide your detection team with an easy way to detect a common persistence mechanism for commodity malware.

There are many ways to perform registry modification. The following tests will highlight setting a single registry value using multiple techniques. These tests are not meant to be all-inclusive, but represent a significant cross-section of methods for performing registry modification at an adversary’s disposal. The registry value that will be set using the varying techniques is the following:

HKCU\Software\Microsoft\Windows Script\Settings - AmsiEnable (REG_DWORD) - 0x00000000

You can find removal instructions here.

VBScript

Save the following VBScript content to amsi.vbs:

WScript.CreateObject("WScript.Shell").RegWrite "HKCU\Software\Microsoft\Windows Script\Settings\AmsiEnable", 0, "REG_DWORD"

Execute the above VBScript code by executing the following:

cscript.exe amsi.vbs

Alternatively, wscript.exe can be used:

wscript.exe amsi.vbs

JScript

Save the following VBScript content to amsi.js:

(new ActiveXObject("WScript.Shell")).RegWrite("HKCU\\Software\\Microsoft\\Windows Script\\Settings\\AmsiEnable", 0, "REG_DWORD");

Execute the above VBScript code by executing the following:

cscript.exe amsi.js

Alternatively, wscript.exe can be used:

wscript.exe amsi.js

PowerShell

Set-ItemProperty -Path 'Registry::HKEY_CURRENT_USER\Software\Microsoft\Windows Script\Settings' -Name 'AmsiEnable' -Type DWord -Value 0

reg.exe

The following example demonstrates setting a registry value directly at the command line:

reg.exe ADD "HKCU\Software\Microsoft\Windows Script\Settings" /v AmsiEnable /t REG_DWORD /d 0x00000000

Alternatively, reg.exe can import a text file consisting of the desired registry settings. Save the following text to amsi.reg:

And execute the following:

reg.exe import amsi.reg

regini.exe

Save the following content to amsi.txt:

And execute the following:

regini.exe amsi.txt

WMI

There are many different ways to interact with WMI. We will use PowerShell in this example:

The Set-ATHRegistry function within the AtomicTestHarnesses module can also be used to generate most of the above examples automatically. The following examples generated most of the above content: