Concentration of Attacker Tools by Filename

Description

It's uncommon to see attacker tools used in rapid succession on an endpoint. This search will identify tools by filename, and look for multiple executions. (MITRE CAR Reference)


Use Case

Advanced Threat Detection, Security Monitoring

Category

Endpoint Compromise

Security Impact

These days, there are a lot of executables one can install and run on a Windows machine in order to cause mischief. The thing is, many amateur hackers will run a lot of these tools in succession (or automated scripts will run them, too). By correlating the process names being executed on endpoints with a list of 'known hacker tool executable names' we can detect this suspicious activity.

Alert Volume

Low (?)

SPL Difficulty

Basic

Journey

Stage 3

MITRE ATT&CK Tactics

Discovery
Lateral Movement
Execution
Credential Access
Persistence
Privilege Escalation
Exfiltration
Defense Evasion

MITRE ATT&CK Techniques

Account Discovery
Permission Groups Discovery
Process Discovery
Remote System Discovery
Security Software Discovery
System Information Discovery
System Network Configuration Discovery
System Network Connections Discovery
Application Window Discovery
System Owner/User Discovery
System Service Discovery
Query Registry
Network Service Scanning
Credential Dumping
Windows Admin Shares
New Service
Modify Existing Service
Service Registry Permissions Weakness
Scheduled Task
Service Execution
Scheduled Transfer
Account Manipulation
Disabling Security Tools
Indicator Blocking
Command-Line Interface

MITRE Threat Groups

APT1
APT18
APT19
APT28
APT29
APT3
APT32
APT33
APT37
APT38
APT39
APT41
Axiom
BRONZE BUTLER
Carbanak
Cleaver
Cobalt Group
Darkhotel
Deep Panda
Dragonfly 2.0
FIN10
FIN5
FIN6
FIN7
FIN8
Gamaredon Group
Gorgon Group
Honeybee
Ke3chang
Kimsuky
Lazarus Group
Leafminer
Leviathan
Machete
Magic Hound
Molerats
MuddyWater
Naikon
Night Dragon
OilRig
Orangeworm
PLATINUM
Patchwork
Poseidon Group
Putter Panda
Rancor
Silence
Soft Cell
Sowbug
Stealth Falcon
Stolen Pencil
Strider
Suckfly
TEMP.Veles
The White Company
Threat Group-1314
Threat Group-3390
Tropic Trooper
Turla
Winnti Group
admin@338
menuPass

Kill Chain Phases

Exploitation

Data Sources

Windows Security
Endpoint Detection and Response

   How to Implement

The hardest part of implementing this correctly, once you have process launch logs ingested, will be to make sure that the fields correctly set.

  • In the live version, we start with index=* which is bad Splunk form (but makes it a little bit easier to get started). You should make sure that you specify the index where your process launch logs live (index=oswinsec if you follow our best practices, and the documentation in this app).
  • The next field you have to worry about is the sourcetype, which should be pretty standard.
  • The EventCode field is the last field you have to think about, which if you use our SplunkTAwindows on your Search Head, will also work automatically for you (again, docs are key!)

Once you have the search itself running, then you need only schedule it (click "Schedule Alert") and have Splunk email you, create a ticket in Enterprise Security or Service Now, or take some other action for you.

   Known False Positives

This search should trigger very few false positives, because it's filtered to just very specific launches, and even more, looking for multiple process launches in a short period of time. The only scenario where you would expect to see this happen is if your organization happens to use some of those unusual tools for normal sysadmin tasks, and have them scripted. Beyond that, be suspicious!

   How To Respond

This alert is very clearly tied to a known threat, so when it fires your concern is that this represents an attacker inside of one of your systems. Recommended steps are to begin incident response on the host where this alert fired from, to look for signs of other suspicious activities. The first step in that process will be to look at the parent process that launched these suspicious processes, and see what other activities that process has done. That should guide you to the underlying problem. As you get more information about this particular system (for example, how did malware end up on it, what websites has it communicated with, etc.), make sure to pivot and look across your entire organization for other indications, and to look in Open Source Intelligence sites like VirusTotal to learn more about the attacker.

   Help

Concentration of Attacker Tools by Filename Help

This example leverages the Simple Search assistant. Our dataset is a collection of Windows process launch logs (Event ID 4688). It then filters for a set of filenames that are known to be hacker related (from a lookup called tools.csv) and uses the transaction command to group them by time. If there's a single transaction with many events, it surfaces those.

SPL for Concentration of Attacker Tools by Filename

Demo Data

First we bring in our basic dataset. This could be any EDR data source that provides process launch logs, including Windows 4688 logs. We're using a macro called Load_Sample_Log_Data to wrap around | inputlookup, just so it is cleaner for the demo data.
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 file names 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.
From Line 1-2, we have a list of suspicious process launches. Now we want to see if many of those fire around the same time. Transaction is great for that -- it lets us group together events that all have the same value for a field, in this case the same host. maxpause=5m lets us continue grouping together any events that have no more than 5 minutes between each one.
From line 1-3, we have grouping of suspicious process launches, but also transaction has added a few new fields, such as duration and eventcount. Eventcount lets us see how many process launches are in each transaction (each grouping of suspicious process launches), so we can filter for when there are at least 4 launch events together.
Finally, we filter out a few fields that we don't need here.

Live Data

First we bring in our basic dataset, which in this case is Windows Security EventID 4688 Process Launch Logs, but could come from any EDR data source. We use index=* here (though you should replace with the index you use for Windows Security events, like index=oswinsec) and specify the standard sourcetype of Windows Security events pulled from the Splunk TA for Windows. Finally, we look for EventCode 4688, which are the Windows Process Launch Logs.
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 file names 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.
From Line 1-2, we have a list of suspicious process launches. Now we want to see if many of those fire around the same time. Transaction is great for that -- it lets us group together events that all have the same value for a field, in this case the same host. maxpause=5m lets us continue grouping together any events that have no more than 5 minutes between each one.
From line 1-3, we have grouping of suspicious process launches, but also transaction has added a few new fields, such as duration and eventcount. Eventcount lets us see how many process launches are in each transaction (each grouping of suspicious process launches), so we can filter for when there are at least 4 launch events together.
Finally we clear up a few fields that Transaction adds.