Detection rules › Splunk

Trickbot Named Pipe

Author
Teoderick Contreras, Splunk
Source
upstream

The following analytic detects the creation or connection to a named pipe associated with Trickbot malware. It leverages Sysmon EventCodes 17 and 18 to identify named pipes with the pattern "\pipe\*lacesomepipe". This activity is significant as Trickbot uses named pipes for communication with its command and control (C2) servers, facilitating data exfiltration and command execution. If confirmed malicious, this behavior could allow attackers to maintain persistence, execute arbitrary commands, and exfiltrate sensitive information from the compromised system.

MITRE ATT&CK coverage

TacticTechniques
Privilege EscalationT1055 Process Injection
Defense EvasionT1055 Process Injection

Event coverage

ProviderEvent IDTitle
Sysmon17PipeEvent (Pipe Created)
Sysmon18PipeEvent (Pipe Connected)

Stages and Predicates

Stage 1: search

search EventCode IN (17, 18) PipeName="\\pipe\\*lacesomepipe"

Stage 2: stats

stats BY dest, dvc, pipe_name, process_exec, process_guid, process_id, process_name, process_path, signature, signature_id, user_id, vendor_product, Image, PipeName

Stage 3: search

search

Stage 4: search

search

Stage 5: search

search `macro`

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
EventCodein
  • 17 corpus 6 (splunk 6)
  • 18 corpus 6 (splunk 6)
PipeNameeq
  • "\\pipe\\*lacesomepipe"

Neighbors

Often fire together

Rules that target events appearing in the same incident timelines. They pattern-match on adjacent steps of the same TTP, so an alert from one is often paired with alerts from these. Useful for triage context and for assembling chained-detection rules.

Share event IDs (chain-detection candidates)

Rules that observe the same Windows event-ID pairs as this one. If you're authoring a multi-stage / sequence rule that spans these events, these are the existing detections that already cover one or both endpoints.