Try in Splunk Security Cloud

Description

This analytic is designed to identify instances where Dynamic Link Libraries (DLLs) with a known history of being exploited are created in locations that are not typical for their use. This could indicate that an attacker is attempting to exploit the DLL search order hijacking or sideloading techniques. DLL search order hijacking involves tricking an application into loading a malicious DLL instead of the legitimate one it was intending to load. This is often achieved by placing the malicious DLL in a directory that is searched before the directory containing the legitimate DLL. Sideloading, similarly, involves placing a malicious DLL with the same name as a legitimate DLL that an application is known to load, in a location that the application will search before finding the legitimate version. Both of these techniques can be used by attackers to execute arbitrary code, maintain persistence on a system, and potentially elevate their privileges, all while appearing as legitimate operations to the untrained eye. This analytic aims to shed light on such suspicious activities by monitoring for the creation of known abused DLLs in unconventional locations, thereby helping in the early detection of these stealthy attack techniques.

  • Type: Anomaly
  • Product: Splunk Enterprise, Splunk Enterprise Security, Splunk Cloud
  • Datamodel: Endpoint
  • Last Updated: 2024-02-19
  • Author: Steven Dick
  • ID: ea91651a-772a-4b02-ac3d-985b364a5f07

Annotations

ATT&CK

ATT&CK

ID Technique Tactic
T1574.001 DLL Search Order Hijacking Persistence, Privilege Escalation, Defense Evasion
T1574.002 DLL Side-Loading Persistence, Privilege Escalation, Defense Evasion
T1574 Hijack Execution Flow Persistence, Privilege Escalation, Defense Evasion
Kill Chain Phase
  • Installation
  • Exploitation
NIST
  • DE.AE
CIS20
  • CIS 10
CVE 


1
2
3
4
5
6
7
8
9
10
11
12
13
14



| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Processes where Processes.parent_process_name!="unknown" Processes.process_name=* Processes.process_guid!=null by _time span=1h Processes.dest Processes.user Processes.process_guid Processes.process_name Processes.process Processes.parent_process Processes.parent_process_name 
| `drop_dm_object_name(Processes)` 
| join max=0 process_guid dest [
| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Filesystem where Filesystem.file_path IN ("*\\users\\*","*\\Windows\Temp\\*","*\\programdata\\*") Filesystem.file_name="*.dll" by _time span=1h Filesystem.dest Filesystem.file_create_time Filesystem.file_name Filesystem.file_path Filesystem.process_guid 
| `drop_dm_object_name(Filesystem)` 
| lookup hijacklibs_loaded library AS file_name OUTPUT islibrary, ttp, comment as desc 
| lookup hijacklibs_loaded library AS file_name excludes as file_path OUTPUT islibrary as excluded 
| search islibrary = TRUE AND excluded != TRUE 
| stats latest(*) as * by dest process_guid ] 
| where isnotnull(file_name) 
| `security_content_ctime(firstTime)` 
| `security_content_ctime(lastTime)` 
|  `windows_known_abused_dll_created_filter`

Macros

The SPL above uses the following Macros:

:information_source: windows_known_abused_dll_created_filter is a empty macro by default. It allows the user to filter out any results (false positives) without editing the SPL.

Lookups

The SPL above uses the following Lookups:

Required fields

List of fields required to use this analytic.

  • _time
  • Processes.dest
  • Processes.user
  • Processes.process_guid
  • Processes.process_name
  • Processes.process
  • Processes.parent_process
  • Processes.parent_process_name
  • Filesystem.dest
  • Filesystem.file_create_time
  • Filesystem.file_name
  • Filesystem.file_path
  • Filesystem.process_guid

How To Implement

The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the Processes and Filesystem nodes of the Endpoint data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.

Known False Positives

This analytic may flag instances where DLLs are loaded by user mode programs for entirely legitimate and benign purposes. It is important for users to be aware that false positives are not only possible but likely, and that careful tuning of this analytic is necessary to distinguish between malicious activity and normal, everyday operations of applications. This may involve adjusting thresholds, whitelisting known good software, or incorporating additional context from other security tools and logs to reduce the rate of false positives.

Associated Analytic Story

RBA

Risk Score Impact Confidence Message
10.0 40 25 The file [$file_name$] was written to an unusual location by [$process_name$] on [$dest$].

:information_source: The Risk Score is calculated by the following formula: Risk Score = (Impact * Confidence/100). Initial Confidence and Impact is set by the analytic author.

Reference

Test Dataset

Replay any dataset to Splunk Enterprise by using our replay.py tool or the UI. Alternatively you can replay a dataset into a Splunk Attack Range

source | version: 1