Concentration of Discovery Tools by SHA1 Hash

Description

It's uncommon to see many discovery tools launched on an endpoint, except in specific situations. This search will identify tools by file hash, and look for several in quick succession. (MITRE CAR Reference)

(unless your company specifically does this)


Use Case

Advanced Threat Detection, Security Monitoring

Category

Scanning, Endpoint Compromise

Security Impact

Building on the two examples of surfacing concentrations of hacker 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 discovery tool executable hashes' we can detect this suspicious activity.

Alert Volume

Low (?)

SPL Difficulty

Basic

Journey

Stage 3

MITRE ATT&CK Tactics

Discovery

MITRE ATT&CK Techniques

Account Discovery
Permission Groups Discovery
System Network Configuration Discovery
System Information Discovery
System Owner/User Discovery
Process Discovery
System Service Discovery

MITRE Threat Groups

APT1
APT18
APT19
APT28
APT3
APT32
APT37
APT38
APT39
APT41
BRONZE BUTLER
Darkhotel
Deep Panda
Dragonfly 2.0
FIN10
FIN6
Gamaredon Group
Honeybee
Ke3chang
Kimsuky
Lazarus Group
Magic Hound
Molerats
MuddyWater
Naikon
OilRig
Patchwork
Poseidon Group
Soft Cell
Sowbug
Stealth Falcon
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

The most likely source of false positives for this script would be normal admin activity, particularly if you have login scripts (or periodic scripts) that enumerate information about hosts, they could show up here. The easy way to filter out these situations is to look at that scripted fingerprint and filter that out. For example, using | where (which has eval-style syntax different from | search) you could filter out | where mvcount(sha1)=4 AND sha1="430AA43010EEF3CD43ED445777F3D5CCF6BC4C27" AND sha1="4445BC58D64BCE3322F80690AF5405876D01C0AC" AND sha1="9A544E2094273741AA2D3E7EA0AF303AF2B587EA" AND sha1="EA18043FEDAF888F04C07F71F2006F3F479C0B41".

   How To Respond

This alert is intended to corroborate other suspicious actions in most environments, rather than being a major flag on its own. You might send this alert to your alert manager as a low or information alert so that you can search for the asset and find it later. More advanced organizations might send this alert into the ES Risk Framework (so that you can aggregate low level risk elements) or to Splunk UBA (so that the threat models can incorporate this event into their calculations).

   Help

Concentration of Discovery 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 filenames that are known to be discovery 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 Discovery 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 discovery 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, now we're going to look and see how many different unique programs were launched using mvcount, which gives us the # of events for a multi-value field.
Finally we clean up a few fields that transaction adds, so that we get a nice clean display.

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 discovery 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, now we're going to look and see how many different unique programs were launched using mvcount, which gives us the # of events for a multi-value field.
Finally we clean up a few fields that transaction adds, so that we get a nice clean display.