Event-Driven YARA Scanning on a Windows Endpoint

This case study was implemented in the same lab used for the LSASS and shadow copy scenarios. The environment remained unchanged:

• Windows 10 endpoint
• Sysmon (SwiftOnSecurity config)
• LimaCharlie sensor
• Sliver C2

Unlike the previous two case studies, which focused on behavioral detection, this one addresses artifact inspection: how to integrate YARA scanning into an endpoint workflow without turning it into a blunt-force periodic scanner.

Why Add YARA at All?

The LSASS case study detects behavior and the shadow copy case study blocks destructive preparation. Neither identifies the payload itself. In this lab, the Sliver implant was freshly generated. It was not present in public malware databases. VirusTotal returned no hits, which is expected for custom-generated implants.

That created a realistic condition: A previously unseen binary appears and executes.

The question wasn’t “Can YARA detect malware?” It was:

• When should scanning occur?
• What should trigger it?
• Should scanning target disk, memory, or both?
• How do you avoid scanning everything constantly?

Threat Model & Detection Positioning

This scenario models a post-compromise intrusion where an attacker has already established execution capability on the endpoint and introduces a custom payload artifact. The payload may not yet exhibit overtly malicious behavior, and may not be detected by reputation-based controls. The attacker is assumed to have interactive access through C2, the ability to drop executables to disk, and the ability to execute or relocate those artifacts at will. Privilege escalation is not required for artifact detection itself, but execution context influences memory visibility and subsequent telemetry.

Unlike the LSASS case study, which targeted a behavioral primitive tied to credential access, this project addresses a different layer of the detection stack: artifact identification. Behavioral controls detect what a payload does. YARA identifies what a payload is.

From an ATT&CK perspective, this layer intersects with Execution and Defense Evasion techniques. Tool transfer (T1105), user execution (T1204), and obfuscated payload staging (T1027) are all potential contexts in which artifact scanning becomes relevant. However, YARA does not detect those techniques directly. It amplifies detection confidence by associating observed activity with a known or characterized binary signature.

This distinction is important. YARA is not a primary behavioral control. It is a reinforcing signal within a layered architecture.

Rule Design Philosophy

I avoided two extremes:

1. Full-disk periodic YARA scanning (too heavy for most endpoints).

2. Passive YARA rules that only fire if manually triggered (too slow for response).

Instead, I implemented event-driven scanning:

• File-based scanning triggered by suspicious file creation
• Memory-based scanning triggered by suspicious execution context

YARA Rule Construction

Two rules were loaded:

I. A YARA signature published by the UK National Cyber Security Centre (NCSC) in its advisory on Sliver C2 usage was imported to represent intelligence-driven detection logic

II. A simple custom string rule targeting Sliver-specific markers

The custom rule:

rule sliver_strings {
  strings:
    $p1 = "/sliver/"
    $p2 = "sliverpb"
  condition:
    all of ($p*)
}

This rule is intentionally unsophisticated. It does not resist obfuscation. Its purpose is not resilience against advanced evasion but validation of scanning workflow and telemetry integration.

If the rule fails to match in a controlled lab, automation is pointless.

Manual Validation Before Automation

Before writing any D&R automation logic, I manually triggered a scan:

yara_scan hive://yara/sliver -f C:\Users\User\Downloads\[payload_name].exe

The detection appeared as a YARA_DETECTION event.

This step is non-negotiable. If you automate first and validate second, you end up debugging two systems at once.

File-Based Automation

The first automation rule targets file creation events: Filtered to:

• User directory path
• Downloads subfolder
• .exe extension

event: NEW_DOCUMENT
op: and
rules:
  - op: starts with
    path: event/FILE_PATH
    value: C:\Users\
  - op: contains
    path: event/FILE_PATH
    value: \Downloads\
  - op: ends with
    path: event/FILE_PATH
    value: .exe

The response:

• Report event
• Trigger YARA scan against that file path

- action: report
  name: EXE dropped in Downloads directory
- action: task
  command: >-
    yara_scan hive://yara/sliver -f "{{.event.FILE_PATH}}"
  investigation: Yara Scan Exe
  suppression:
    is_global: false
    keys:
      - '{{ .event.FILE_PATH }}'
      - Yara Scan Exe
    max_count: 1
    period: 1m

> This response action generates an alert for the EXE creation, but more importantly, kicks off a YARA scan using the Sliver signature against the newly created EXE.

The logic is intentionally narrow. Why Downloads? Because in this controlled scenario, user-executed payloads originate there. In a production deployment, this would expand to:

• AppData
• Temp directories
• Public user directories
• External media mount points

But broad scanning introduces performance cost.

Performance Considerations

YARA scanning is CPU-intensive. On large executables or frequent file creation events, repeated scanning can:

• Spike CPU usage
• Introduce endpoint latency
• Generate duplicate detections

To reduce this risk, suppression logic was implemented at the automation layer (see File-Based Automation section). This prevents repeated scanning of the same artifact during burst events such as file relocation or rapid rewrite operations.

Without suppression, event-driven scanning can amplify noise and introduce unnecessary CPU load.

Containment Threshold and Response Strategy

In the shadow copy case study, automated process termination was justified because recovery inhibition represents high-confidence destructive intent. That same response logic was intentionally not applied here. YARA detections are only as reliable as the rules behind them. In this lab, one rule was sourced from public reporting and the other was intentionally simplistic. Neither was engineered for obfuscation resistance or production-grade false positive control. Automatically terminating a process based on a low-complexity string rule would introduce operational risk disproportionate to detection certainty. In enterprise environments, legitimate software may contain overlapping strings or patterns depending on rule construction. For that reason, this implementation treats YARA detection as an enrichment signal rather than an autonomous containment trigger. A mature deployment would correlate YARA matches with behavioral anomalies, suspicious parent lineage, execution from user-controlled directories, or concurrent high-risk activity before escalating to active containment.

This maintains consistency with the broader detection philosophy across projects: response aggressiveness must scale with behavioral confidence.

Memory-Based Automation

Disk presence is not enough. Attackers frequently:

• Execute and delete payloads
• Inject into other processes
• Load reflective binaries

Therefore, I added a second rule triggered by:

event: NEW_PROCESS
op: and
rules:
  - op: starts with
    path: event/FILE_PATH
    value: C:\Users\
  - op: contains
    path: event/FILE_PATH
    value: \Downloads\

Filtered to processes launched from Downloads.

Instead of scanning file path, this rule scans by PID:

- action: report
  name: Execution from Downloads directory
- action: task
  command: yara_scan hive://yara/sliver-process --pid "{{ .event.PROCESS_ID }}"
  investigation: Yara Scan Process
  suppression:
    is_global: false
    keys:
      - '{{ .event.PROCESS_ID }}'
      - Yara Scan Process
    max_count: 1
    period: 1m

This shifts detection from static artifact to runtime memory. Memory scanning is heavier than file scanning. It inspects loaded memory regions rather than raw file content. In this lab environment, performance impact was negligible. In enterprise scale, PID-targeted scanning must be tightly scoped.

Observed Behavior During Testing

File-based trigger:

1. Moved payload out of Downloads

2. Moved it back

This generated "NEW_DOCUMENT" event, and shortly after, YARA detection fired.

Memory-based trigger:

1. Killed running implant

2. Executed payload again

Executed Sliver payload to create the "NEW_PROCESS" event we need to trigger the scanning of a process launched from the Downloads dir:

C:\Users\User\Downloads\[payload_name].exe

Followed by memory YARA detection.

In both cases, the pipeline worked as expected.

Failure Modes and Bypass Considerations

Event-driven YARA scanning assumes that malicious artifacts exist in an observable state, either on disk prior to execution or in memory during runtime. That assumption does not always hold. An adversary may stage payloads outside monitored directories, encrypt binaries with runtime decryption, inject into legitimate processes without leaving distinct file artifacts, or use reflective loading techniques that minimize static signature exposure. In such cases, file-based scanning produces no signal. Memory-based scanning may also fail if identifying strings are transient or obfuscated.

This reinforces a core architectural principle: artifact detection complements behavioral detection but does not replace it. If credential dumping or recovery inhibition telemetry appears without a corresponding artifact match, behavioral signals remain authoritative. Conversely, if a suspicious artifact is detected before high-risk behavior occurs, it becomes an early investigative pivot.

YARA adds depth to the stack. It does not define the stack.

Relationship to Other Detection Layers

Within the same lab: LSASS detection identifies credential access behavior, shadow copy detection blocks recovery inhibition and YARA scanning identifies the payload itself. These controls are not redundant; they operate at distinct phases of the intrusion lifecycle.

They address different phases:

• Artifact presence
• Behavioral abuse
• Destructive preparation

Layering them reduces dependency on any single signal.

Detection Engineering Discipline

This project followed the same engineering discipline applied in previous case studies. Telemetry was observed before automation was written. Manual YARA scanning confirmed that detection events were structured, consistent, and distinguishable between file and memory contexts. Only after validating that the sensor produced reliable YARA_DETECTION events was automation introduced.

Trigger conditions were deliberately scoped to reduce performance impact. Rather than scanning continuously, the design anchors scanning to meaningful system events: file introduction and process execution. Suppression controls were incorporated into the automation layer to ensure event-driven scanning remained operationally stable under burst conditions.

The architectural goal was not to demonstrate YARA capability. It was to validate how signature-based artifact inspection can be integrated into a behavior-driven detection stack without degrading endpoint stability.

Practical Takeaways

The Sliver implant was detected. That was expected.

What mattered was verifying that YARA scanning could be triggered by meaningful system events rather than scheduled sweeps, and that doing so would not introduce unnecessary load or alert noise.

File-based scanning validated artifact presence at introduction time. Process-based scanning extended visibility into runtime memory. Suppression controls prevented repeated execution during burst events.

The implementation is narrow by design. It does not attempt to solve artifact detection universally. It demonstrates how signature scanning can be attached to specific telemetry anchors without degrading endpoint stability.