New Parent Process for cmd.exe or regedit.exe

New Parent Process for cmd.exe or regedit.exe


cmd.exe and regedit.exe tend to be used in the same ways. New parent processes can be suspicious. (MITRE CAR Reference)

Content Mapping

This content is not mapped to any local saved search. Add mapping

Use Case

Advanced Threat Detection


Endpoint Compromise

Security Impact

As described above, we want to carefully monitor certain executables on our Windows endpoints and understand what is calling them. For example, if we see a program like Word or Excel launching cmd.exe, it is probably up to no good especially if we’ve never seen it do that before. Programs that behave in this way legitimately should be whitelisted - others should be immediately investigated.

Alert Volume


SPL Difficulty


Data Availability



Stage 3



MITRE ATT&CK Techniques

Command and Scripting Interpreter

MITRE Threat Groups

Stealth Falcon
Dragonfly 2.0

Kill Chain Phases


Data Sources

Windows Security
Endpoint Detection and Response

   How to Implement

Implementation of this example (or any of the First Time Seen examples) is generally very simple.

  • Validate that you have the right data onboarded, and that the fields you want to monitor are properly extracted. For this search you may wish to alter the process names that are tracked.
  • Save the search.

For most environments, these searches can be run once a day, often overnight, without worrying too much about a slow search. If you wish to run this search more frequently, or if this search is too slow for your environment, we recommend leveraging a lookup cache. For more on this, see the lookup cache dropdown below and select the sample item. A window will pop up telling you more about this feature.

   Known False Positives

This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately reflect the first occurrence in the time period you're searching over (or for the lookup cache feature, the first occurrence over whatever time period you built the lookup). But while there are really no "false positives" in a traditional sense, there is definitely lots of noise.

This detection should have relatively few false positives given the rarity of new parent processes for these standard Windows processes. Most noise that will come from new systems management scripts, or from new software installers. These can be whitelisted in the search.

   How To Respond

When this search returns values, initiate your incident response process and identify the parent process that initiated cmd.exe or regedit.exe. Determine the user account this is running under and the system it is running on. Contact the user and system owner of this action. If it is authorized, document that this is and by whom. If not, the user credentials have been used by another party and additional investigation is warranted to ensure that processes are not spawning these commands.


New Parent Process for cmd.exe or regedit.exe Help

This example leverages the Detect New Values search assistant. Our dataset is a anonymized collection of process launch logs from Microsoft Sysmon (EventCode=1). For this analysis, we are looking at the processes that spawned cmd.exe, regedit.exe, and powershell.exe. If we've seen that ParentProcess before, then all is fine, but if we've never seen it before we'll raise an alert.

SPL for New Parent Process for cmd.exe or regedit.exe

Demo Data

First we pull in our demo dataset.
Then we filter for process launches of cmd.exe, regedit.exe, or powershell.exe
Here we use the stats command to calculate what the earliest and the latest time is that we have seen this combination of fields.
Next we calculate the most recent value in our demo dataset
We end by seeing if the earliest time we've seen this value is within the last day of the end of our demo dataset.

Live Data

First we pull in our basic dataset, which consists of XML format Sysmon logs from the endpoints (ingested via the sysmon TA) with process launches of cmd.exe or regedit.exe. This could be any EDR data source that provides file hash information. Because we're looking for process launches, we then filter for EventCode=1 (the Sysmon Process Launch code).
Then we use table to include just the fields we're apt to care about. (Technically we need to use | table for this app because we show you the intermediate results, but in production you should drop this line because it will reduce search performance.)
Here we use the stats command to calculate what the earliest and the latest time is that we have seen this combination of fields.
We end by seeing if the earliest time we've seen this value is within the last day.