car.mitre.org Open in urlscan Pro
185.199.111.153  Public Scan

Form analysis
0 forms found in the DOM

Text Content

MITRE Cyber Analytics Repository
Analytics Data Model Sensors Coverage Comparison


CAR-2013-03-001: REG.EXE CALLED FROM COMMAND SHELL

Submission Date: 2013/03/28

Information Domain: Host

Data Subtypes: Process

Analytic Type: TTP

Applicable Platforms: Windows

Contributors: MITRE

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


ATT&CK DETECTION

Technique Subtechnique(s) Tactic(s) Level of Coverage Query Registry N/A
Discovery Moderate Modify Registry N/A Defense Evasion Moderate Boot or Logon
Autostart Execution Registry Run Keys / Startup Folder Persistence Moderate
Hijack Execution Flow Services Registry Permissions Weakness Persistence,
Privilege Escalation Moderate


DATA MODEL REFERENCES

Object Action Field process create command_line process create hostname process
create exe process create parent_exe process create pid process create ppid


APPLICABLE SENSORS

 * osquery_4.1.2
 * osquery_4.6.0
 * Sysmon_10.4
 * Sysmon_11.0
 * Sysmon_13


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


DNIF, 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



UNIT TESTS

TEST CASE 1

Configurations: Windows 7

Execute reg.exe from cmd.exe. Note that the analytic joins back to the
grandparent process, which in this case is explorer.exe. The query time window
must include the user log on. For example, if you logged in at 8am and tested
the analytic at 10am, the query needs to search from 8am to 10am, not just at
10am. Within a command window, run the command.

reg.exe QUERY HKLM\Software\Microsoft


Copyright © 2020, The MITRE Corporation. MITRE ATT&CK and ATT&CK are trademarks
of The MITRE Corporation.

License | Contribute