New Suspicious Executable Launch for User

Description

Some files rarely get used by legitimate activities, such as at.exe. This search will detect those executables being launched, regardless of the circumstance. (MITRE CAR Reference)


Use Case

Advanced Threat Detection

Category

Endpoint Compromise

Security Impact

There are certain executables launched on endpoints that generally mean that someone, or something, is up to no good. For this example, we have provided a lookup file ‘tools.csv’ that among other things identifies binaries by executable name as being used for discovery or attack purposes. It may be perfectly normal for one or more of these executables to launch on a given endpoint, but if one of these executables is seen where it hasn’t been seen before, this can be considered an alert-able condition.

Alert Volume

Low (?)

SPL Difficulty

Medium

Journey

Stage 3

MITRE ATT&CK Tactics

Execution

MITRE ATT&CK Techniques

Execution
Command-Line Interface

MITRE Threat Groups

APT1
APT18
APT28
APT3
APT32
APT37
APT38
APT41
BRONZE BUTLER
Cobalt Group
Dragonfly 2.0
FIN7
FIN8
Gorgon Group
Honeybee
Ke3chang
Lazarus Group
Leviathan
Magic Hound
MuddyWater
OilRig
Patchwork
Rancor
Silence
Soft Cell
Sowbug
Suckfly
Threat Group-1314
Threat Group-3390
Turla
admin@338
menuPass

Kill Chain Phases

Exploitation

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.

There are no known false positives for this search apart from some custom-designed scripts and the occasional sysadmin familiar with it. Both of these should be very easy to filter out.

   How To Respond

When this search returns values, initiate your incident response process and capture the time of the event, executable, its associated path, the system, user and other pertinent information. Contact the owner of the systems. If it is authorized, document that this is authorized and by whom. If not, the user credentials have been used by another party and additional investigation.

   Help

New Suspicious Executable Launch for User 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 suspicious filenames (from a lookup called tools.csv). We check the first time that's occurred per path, per user, and then alert if that was in the last day.

SPL for New Suspicious Executable Launch for User

Demo Data

First we pull in our demo dataset.
From line one we have our process launch logs, now we need to filter that down to just the potential attack tools. We do this via a subsearch. A subsearch goes and runs another search, and then takes those results and inserts them into the main search. You can copy-paste that subsearch into a new search window and see what the results look like -- there's a single field called "search" that has a bunch of filenames with ORs between them. That will effectively be inserted into our main search, giving us a really long search string without having to maintain a really long search.
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, care of EventID 4688 documented in this app. Any other EDR solution giving process launch logs will suffice here, as well.
From line one we have our process launch logs, now we need to filter that down to just the potential attack tools. We do this via a subsearch. A subsearch goes and runs another search, and then takes those results and inserts them into the main search. You can copy-paste that subsearch into a new search window and see what the results look like -- there's a single field called "search" that has a bunch of filenames with ORs between them. That will effectively be inserted into our main search, giving us a really long search string without having to maintain a really long search.
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.