Concentration of Attacker Tools by SHA1 Hash

Description

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


Use Case

Advanced Threat Detection, Security Monitoring

Category

Endpoint Compromise

Security Impact

Building on the two examples of surfacing concentrations of attacker or discovery tools via filename, a more accurate method for doing this is to use the SHA1 cryptographic hashes for these tools, because tools can always be renamed before executing. By correlating the process hashes being executed on endpoints with a list of 'known hacker tool executable hashes' 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
Privilege Escalation
Persistence
Exfiltration
Defense Evasion

MITRE ATT&CK Techniques

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

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

Endpoint Detection and Response

   How to Implement

The hardest part of implementing this correctly, once you have EDR logs ingested, will be to make sure that the fields correctly set. (Why EDR? The boundary between EDR logs and Windows Security Logs for most Splunk customers is that Windows Process Launch Logs won't contain hashes, or the right variety of hashes, but EDR tools including the free Sysmon tool will.)

  • 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 EDR logs live (index=epintel 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 second to last field you have to think about, which if you use our Splunk Add-on for Sysmon on your Search Head, will also work automatically for you (again, docs are key!)
  • Finally, Sysmon will return multiple different hashes. In order for the hashes to show up correctly in the table, make sure that you have a field named sha1 (or change the search to match what you see in the events).

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 SHA1 Hash Help

This example leverages the Simple Search assistant. Our dataset is a collection of Windows process launch logs (Event ID 4688), where we have hashing turned on (look for tools like WLS, or Sysmon to help here). It then filters for a set of file hashes 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 SHA1 Hash

Demo Data

First we pull in our demo dataset. This could be any EDR data source that provides file hash information.
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 hashes 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.

Live Data

First we pull in our basic dataset, which consists of XML format Sysmon logs from the endpoints (ingested via the Sysmon TA). 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).
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 hashes 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.