CAR-2013-03-001.yaml

title: Reg.exe called from Command Shell
submission_date: 2013/03/28
information_domain: Host
platforms:
  - Windows
subtypes:
  - Process
analytic_types:
  - TTP
contributors:
  - MITRE
id: CAR-2013-03-001
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](https://en.wikipedia.org/wiki/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`
coverage:
  - technique: T1012
    tactics:
      - TA0007
    coverage: Moderate
  - technique: T1112
    tactics:
      - TA0005
    coverage: Moderate
  - technique: T1547
    tactics:
      - TA0003
    subtechniques:
      - T1547.001
    coverage: Moderate
  - technique: T1574
    tactics:
      - TA0003
      - TA0004
    subtechniques:
      - T1574.011
    coverage: Moderate
implementations:
  - description: '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 '
    code: |-
      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
    type: pseudocode
  - description: DNIF version of the above pseudocode.
    code: |-
      _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
    type: DNIF
    data_model: Sysmon native
data_model_references:
  - process/create/command_line
  - process/create/hostname
  - process/create/exe
  - process/create/parent_exe
  - process/create/pid
  - process/create/ppid
unit_tests:
  - configurations:
      - Windows 7
    description: '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.'
    commands:
      - reg.exe QUERY HKLM\Software\Microsoft
d3fend_mappings:
  - iri: d3f:ProcessLineageAnalysis
    id: D3-PLA
    label: Process Lineage Analysis