Reg.exe called from Command Shell

Hypothesis and description

Registry modifications are often essential in establishing persistence via known Windows mechanisms. Many legitimate modifications are done graphically via regedit.exe or by using the corresponding channels, or even calling the Registry APIs directly. The built-in utility reg.exe provides a command-line interface to the registry, so that queries and modifications can be performed from a shell, such as cmd.exe. When a user is responsible for these actions, the parent of cmd.exe will likely be explorer.exe. Occasionally, power users and administrators write scripts that do this behavior as well, but likely from a different process tree. These background scripts must be learned so they can be tuned out accordingly.

### Output Description

The sequence of processes that resulted in reg.exe being started from a shell. That is, a hierarchy that looks like

- great-grand_parent.exe

- grand_parent.exe

- parent.exe

- reg.exe

Platforms: Windows
Domain: Host
Subtypes: Process
Submitted: 2013-03-28
Contributors: MITRE

ATT&CK coverage

Technique	Tactics	Coverage
T1012 Query Registry	Discovery	Moderate
T1112 Modify Registry	Stealth (formerly Defense Evasion)	Moderate
T1547 Boot or Logon Autostart ExecutionT1547.001	Persistence	Moderate
T1574 Hijack Execution FlowT1574.011	Persistence, Privilege Escalation	Moderate

4 techniques, 6 ATT&CK ids including sub-techniques. Links open MITRE ATT&CK.

Marked techniques are also explained, with detection notes and certification relevance, on our interactive ATT&CK map.

D3FEND techniques MITRE maps to this analytic

D3-PLA Process Lineage Analysis

Data model references

Fields from the CAR data model (object/action/field) the analytic reads.

Pseudocode and implementations

Pseudocode

To gain better context, it may be useful to also get information about the cmd process to know its parent. This may be helpful when tuning the analytic to an environment, if this behavior happens frequently. This may also help to rule out instances of users running

processes = search Process:Create
reg = filter processes where (exe == "reg.exe" and parent_exe == "cmd.exe")
cmd = filter processes where (exe == "cmd.exe" and parent_exe != "explorer.exe"")
reg_and_cmd = join (reg, cmd) where (reg.ppid == cmd.pid and reg.hostname == cmd.hostname)
output reg_and_cmd

DNIFData model: Sysmon native

DNIF version of the above pseudocode.

_fetch * from event where $LogName=WINDOWS-SYSMON AND $EventID=1 AND $Process=regex(.*reg\.exe.*)i AND $ParentProcess=regex(.*cmd\.exe.*)i as #A limit 100
>>_fetch * from event where $LogName=WINDOWS-SYSMON AND $EventID=1 AND $Process=regex(.*cmd\.exe.*)i NOT $ParentProcess=regex(.*explorer\.exe.*)i as #B limit 100
>>_checkif sjoin #B.$PPID = #A.$CPID str_compare #B.$SystemName eq #A.$SystemName include

Across MITRE's defensive frameworks

Linked through the 4 ATT&CK techniques above.

Counter with D3FEND

Defensive techniques MITRE D3FEND maps to the same ATT&CK techniques.

17 more in the full list

View CAR-2013-03-001 on car.mitre.org