Remote PowerShell Launches

Remote PowerShell Launches


It's unusual for new users to remotely launch PowerShell on another system. This will track the first time per user + host combination that powershel is remotely started.

(for most companies)

Content Mapping

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

Use Case

Advanced Threat Detection


Lateral Movement, Zero Trust

Security Impact

Remote execution of PowerShell is something that should rarely occur if at all within an network, and if it does should be associated with known executables or users. Therefore, unique instances of user and host combinations should be monitored and alerted upon for further investigation by security teams. This type of activity could be an indicator of compromised assets, user credentials, or a potential insider threat scenario.

Alert Volume


SPL Difficulty


Data Availability



Stage 1


Lateral Movement

MITRE ATT&CK Techniques

Remote Services

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.
  • 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 type of event should only occur for remote management, or potentially some systems management tools. It would be recommended to filter out the users who typically perform these actions (or alternatively you could alter the search to look for user + sourcetype instead of user + host, so that you will be alerted the first time a user takes this action, instead of the first time a user takes it on a particular host).

   How To Respond

When this search returns values, initiate your incident response process and identify the user and system responsible for initiating this behavior. Determine the time of the event and what process and associated parent processes where triggered. Contact the user and system owner to determine if it is authorized, and document that this is authorized and by whom. If not, the user credentials may have been used by another party and additional investigation is warranted.


Remote PowerShell Launches Help

This example leverages the Detect New Values search assistant. Our dataset is a anonymized collection of process launch events (Event ID 4688) filtered for the Image and ParentImage that show up when Powershell is remotely triggered. We check the first time that's occurred per host, and then alert if that was in the last day.

SPL for Remote PowerShell Launches

Demo Data

First we pull in our demo dataset.
Then we filter for where the parent process is svchost.exe and the actual process is wsmprovhost.exe, as that is what will show up for a remote Powershell launch.
For our demo data, we don't have a user, so we just default it as "unknown."
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 dataset of Windows process launch logs filtered to our common Windows executables, care of EventID 4688 documented in this app. Any other EDR solution giving process launch logs will suffice here, as well. Notably, this technique of doing the value and then the field=value can bypass some quirks around field extractions, and make searches faster for very large datasets (though that's an area of active work, and it's less true every year).
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.