Detection rules › Splunk

Suspicious .sys Created - Windows (Sysmon)

Group by
_time, file_name, host, process_name
Source
github.com/anvilogic-forge/armory

Adversaries may bring a signed vulnerable driver onto a compromised machine so that they can exploit the vulnerability to execute code in kernel mode. This process is sometimes referred to as Bring Your Own Vulnerable Driver (BYOVD). Adversaries may include the vulnerable driver with files delivered during Initial Access or download it to a compromised system via Ingress Tool Transfer or Lateral Tool Transfer. This use case detects rare file creation events for .sys files.

MITRE ATT&CK coverage

References

Event coverage

ProviderEventTitle
SysmonEvent ID 11FileCreate

Rule body yaml

id: '30491.54569'
title: Suspicious .sys Created - Windows
description: Adversaries may bring a signed vulnerable driver onto a compromised machine
  so that they can exploit the vulnerability to execute code in kernel mode. This
  process is sometimes referred to as Bring Your Own Vulnerable Driver (BYOVD). Adversaries
  may include the vulnerable driver with files delivered during Initial Access or
  download it to a compromised system via Ingress Tool Transfer or Lateral Tool Transfer.
  This use case detects rare file creation events for .sys files.
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_sysmon` (TERM(EventCode=11) OR "<EventID>11<")
  ".sys" | regex file_name="(?i)\.sys$" | table _time, host, user, process_name, signature_id,
  file_name, file_path `group_events("host, process_name, file_name", 5)` | eventstats
  c(file_name) as c_file_name dc(host) as dc_host by file_name| where c_file_name
  < 3 AND dc_host=1 '
techniques:
- persistence:create or modify system process:windows service
- privilege-escalation:exploitation for privilege escalation
technique_id:
- T1543.003
- T1068
data_category:
- Windows Sysmon
references:
- https://techcommunity.microsoft.com/t5/microsoft-security-experts-blog/strategies-to-monitor-and-prevent-vulnerable-driver-attacks/ba-p/4103985
- https://attack.mitre.org/techniques/T1068/
- https://attack.mitre.org/techniques/T1543/003/
- https://www.loldrivers.io/

Stages and Predicates

Stage 1: search

search EventCode=11 source="*" source IN ("WinEventLog:Microsoft-Windows-Sysmon/Operational", "XmlWinEventLog:Microsoft-Windows-Sysmon/Operational")

Stage 2: regex

regex match(file_name, "(?i)\.sys$")

Stage 3: table

table _time, file_name, file_path, host, process_name, signature_id, user

Stage 4: bucket

bucket _time

Stage 5: stats

stats BY host, process_name, file_name, _time

Stage 6: eventstats

eventstatsAS c_file_name,AS dc_host BY file_name

Stage 7: where

where c_file_name<3 dc_host=1

Indicators

Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.

FieldKindValues
EventCodeeq
  • 11 corpus 23 (splunk 21, kusto 2)
c_file_namelt
  • 3
dc_hosteq
  • 1 corpus 6 (splunk 6)
file_nameregex_match
  • "(?i).sys$"

Search terms

Bare-string tokens in the SPL search body. Splunk matches each token against _raw (the untyped raw event text) anywhere it appears, not against a specific field. These don't surface in the Indicators table because they aren't predicates on a known field.

StageTerm
1TERM
1"<EventID>11<"
1".sys"