Threat Detection 101: A Layered Approach

How YARA, Sigma and Suricata Work Together in Threat Detection

The Need for Layered Detection

If there’s one thing attackers are really good at, it’s taking advantage of assumptions. One of the most common ones on the defensive side is thinking that a single detection mechanism is “good enough”. And ... It rarely is.

Modern attacks are not loud, obvious or linear. Each detection mechanism gives us one point of view, and that’s the key idea here: no single point of view tells the full story.

That’s why layered detection matters. Not because we want more tools, but because we want different perspectives on the same problem.

At a very high level, detection layers answer different questions:

• What is this thing?

• What is it doing?

• How is it communicating?

Attackers constantly try to stay below thresholds, evade signatures, or imitate legitimate behavior. Forcing them to bypass multiple, independent layers at the same time raises the cost of an attack significantly. What slips through one layer often leaves traces in another.

For defenders, this approach also makes life easier. Instead of reacting to isolated alerts, layered detection helps us connect the dots and build a clearer picture of what’s actually happening. It turns scattered signals into something closer to a story, and stories are much easier to reason about than raw events.

Layer 1 – Files & Artifacts (YARA)

What is it?

YARA is a rule-based pattern matching engine designed to identify files and memory artifacts. In practice, it’s one of the most common tools used to describe what something is by looking at its content rather than its name or location.

What does it see?

YARA operates on artifacts, such as:

• Files on disk (executables, documents, scripts)

• File contents (strings, byte sequences, metadata)

• Memory regions and memory dumps

It doesn’t care how the artifact got there, only what it looks like.

Where does it usually run?

YARA is commonly used in:

• Malware analysis environments

• EDR and antivirus engines

• Sandboxes

• Forensic and incident response workflows

It can run on endpoints, servers, or analysis pipelines, depending on how it’s integrated.

How does YARA actually look?

At its core, a YARA rule describes patterns and conditions that must be met for an artifact to be considered a match.

A very simple example could look like this:

rule Suspicious_PDF_Embedded_JavaScript
{
    meta:
        description = "Detects PDF files with embedded JavaScript"
        author = "xHuntr3ss"
        reference = "https://xhuntr3ss.gitbook.io/..."
        date = "2026-01-02"

    strings:
        $js_1 = "/JavaScript"
        $js_2 = "/JS"
        $open_action = "/OpenAction"

    condition:
        uint32(0) == 0x25504446 and
        any of ($js_*) and
        $open_action
}

How to read a YARA rule

Section	Description	Why it matters?
rule	Rule name	Human-readable identifier for the detection
meta	Descriptivie metadata	Human-readable identifier for the detection
strings	Patterns to match	Defines what the artifact looks like
condition	Logical expression	Defines what the artifact looks like

So, in the example:

• uint32(0) == 0x25504446: checks for the PDF file header

• any of ($js_*): matches any JavaScript-related string

• $open_action: Looks for automatic execution triggers

How it fits in a layered detection model

YARA is often the first line of detection: it flags suspicious or malicious artifacts early, sometimes even before execution. However, attackers know this and frequently invest effort into making their payloads look harmless at rest.

This is where layered detection becomes critical. If a malicious artifact bypasses YARA, it may still reveal itself through behavior (captured by logs and Sigma rules) or through network communication (observed by tools like Suricata).

YARA answers the what, but it needs other layers to answer the what next.

Layer 2 – Behavior & Events (Sigma)

What is it?

Sigma is a generic rule format designed to describe suspicious behavior in logs. Instead of detecting files or network packets, Sigma focuses on what systems and users are doing. Think of Sigma as a way to describe detection logic, independent of any specific SIEM or platform.

What does it see?

Sigma operates on events and logs, such as:

• Process creation events

• Authentication logs

• PowerShell or command-line execution

• Windows Event Logs

• Linux audit logs

• Cloud and identity logs

It doesn’t execute code or inspect files, it only looks at recorded activity.

Where does it usually run?

Sigma rules themselves don’t “run” directly. They are usually:

• Translated into SIEM queries (Elastic, Splunk, Sentinel, QRadar, etc.)

• Used for threat hunting

• Integrated into detection pipelines

In practice, Sigma lives between log sources and detection platforms.

How does Sigma actually look?

At its core, a Sigma rule describes patterns in events that indicate suspicious or malicious behavior in YAML format.

A very simple example could look like this:

title: Suspicious PowerShell Download
id: 3f9b8d3a-1234-4c9a-9b9e-abcdef123456
status: experimental
description: Detects PowerShell downloading content from the internet
author: xHuntr3ss
date: 2026-01-02
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: powershell.exe
    CommandLine|contains:
      - Invoke-WebRequest
      - IEX
  condition: selection
level: medium

How to read a Sigma rule

Section	Description	Why it matters?
title, id, status, description, author, date	Descriptivie metadata	Human-readable identifier for the detection
logsource	Event source	Defines where the data comes from
detection	Matching logic	Describes the suspicious behavior
condition	Rule logic	Decides ehen the rules triggers
level	Severity hint	Helps with prioritization

So, in the example:

• Image|endswith: powershell.exe: detects the execution of PowerShell processes.

• CommandLine|contains: looks for suspicious PowerShell usage, such as downloading or executing remote content.

• condition: selection: triggers the rule when the defined behavior is observed in the logs.

How it fits in a layered detection model

Sigma usually catches what static detection misses. If a malicious file bypasses YARA, it still has to do something: spawn processes, execute commands, access credentials, or move laterally.

This layer focuses on intent and behavior, not appearance. However, behavior alone can be noisy and ambiguous, especially in complex environments.

That’s why Sigma works best when combined with other layers. File-based detection can tell us what something is, network detection can tell us where it talks to, and Sigma helps us understand what it’s actually doing.

Sigma answers the what is happening, but not necessarily how it entered or where it’s communicating.

Layer 3 – Network Communication (Suricata)

What is it?

Suricata is a network-based detection engine capable of inspecting traffic in real time. It’s commonly used as an IDS, IPS, or network security monitoring tool, and its main strength is visibility into how systems communicate over the network.

Unlike YARA or Sigma, Suricata doesn’t care about files or system events, it cares about packets, protocols and flows.

What does it see?

Suricata operates on network traffic, including:

• TCP and UDP traffic

• HTTP, DNS, TLS, SMTP, SMB and other protocols

• Metadata such as IPs, ports and domains

• Network flows and sessions

It observes communication as it happens, regardless of what’s happening on the endpoint.

Where does it usually run?

Suricata is typically deployed:

• On network taps or SPAN ports

• At network boundaries (ingress / egress)

• In data centers or cloud environments

• As part of a network monitoring stack (often with Elastic)

It runs outside the endpoint, which makes it very hard for an attacker to tamper with.

How does Suricata actually look?

At its core, Suricata uses rules to describe suspicious network activity.

A very simple example could look like this:

action protocol source source_port -> destination destination_port (
    msg:"Rule description";
    detection_logic;
    metadata;
)

👇

alert http any any -> any any (
    msg:"Suspicious HTTP User-Agent";
    flow:established,to_server;
    http.user_agent;
    content:"curl";
    classtype:bad-unknown;
    sid:1000001;
    rev:1;
)

How to read a Suricata rule

Section	Description	Why it matters?
action	Defines what Suricata should do when the rule matches (e.g. alert, drop, reject)	Determines whether the rule is only for visibility or actively blocks traffic
protcol	Specifies the network protocol (tcp, udp, icmp, http, etc)	Ensures the rule is evaluated only on the relevant traffic, reducing noise
source	Indicates where the traffic originates from (Ip, network, variable like $HOME_NFT, etc)	Helps scope detection to internal, external, or especific networks
source_port	Defines the originating port or port range	Useful for narrowing detection to expected or suspicious services
direction	Uses -> or <-> to describe traffic flow	Context is critical: client-to-server traffic is not the same as server-to-client
destination	Indicates the target IP or network	Helps distinguish attacks targeting internal assets vs external services
desrination_port	Specifies the destination service port	Allows precise matching against vulnerable or abused services
rule options	The content inside parentheses: keywords like msg, content, sid, classtype, etc	This is where the actual detection logic lives
msg	Human-readable description of the alert	Makes alerts understandable during triage and incident response
content / pcre	Defines patterns to match in packet payloads	Core detection mechanism for signatures and behavioral patterns.
sid	Unique rule identifier	Essential for rule management, tuning, and correlation
classtype / priority	Categorizes the alert severity	Helps SOCs prioritize alerts effectively

So, in the example:

In the example,

• flow:established,to_server: ensures the rule only applies to established connections going to a server.

• http.user_agent: tells Suricata to inspect the HTTP User-Agent header.

• content:"curl": looks for a specific value inside the User-Agent, often used by scripts or malware.

• sid: unique identifier for the rule.

How it fits in a layered detection model

Network detection often catches what both file and behavioral detection miss. Even if a payload is obfuscated and its execution looks normal, it still needs to communicate to download additional stages, reach a command-and-control server, or exfiltrate data.

Suricata provides an external, independent view of that communication. It doesn’t rely on logs generated by the host and doesn’t require an agent on the endpoint.

In a layered model:

• YARA tells us what the artifact looks like

• Sigma tells us what the system is doing

• Suricata tells us how it talks to the outside world

Suricata answers the how, completing the picture.

Rule Summary

Layer	LAYER 1	LAYER 2	LAYER 3
Rule Type	YARA	Sigma	Suricata / Snort(*)
Detects	Suspicious or malicious artifacts based on file or memory content	Suspicious or malicious behavior observed on a system	Suspicious or malicious network communication
Data Source	Files, memory dumps, artifacts at rest	Logs (process creation, file access, registry, auth, etc.)	Network traffic (packets, flows)
Key Question	What is this?	What is it doing?	Who is it talking to?
Why it matters	Stops or flags threats before execution, but can be bypassed with obfuscation or packing	Catches activity that looks benign on disk but becomes suspicious at runtime	Detects threats that evade host-based detection but reveal themselves on the wire

^(*) Snort is one of the earliest and most widely adopted network intrusion detection systems (NIDS). While Suricata is often preferred today due to its performance and modern architecture, Snort remains relevant and widely deployed, and many detection concepts and rule formats are shared between both engines.

No single rule tells the full story. YARA sees the artifact, Sigma sees the behavior, and Suricata sees the communication. Together, they describe the attack lifecycle.

A Practical Case: Designing Detection Backwards

Scenario

A developer is troubleshooting an internal issue. While browsing a GitHub repository, they find a comment in an issue thread suggesting a “temporary fix”.

The comment links to a small executable hosted on a file-sharing service.

The binary:

• Looks like a diagnostic tool

• Is unsigned

• Is downloaded and executed manually by the developer

There is no YARA rule covering this specific sample.

The file executes successfully.

Layer 1 – Files & Artifacts (YARA)

What happened

The binary was not detected at rest:

• No known signatures

• Packed

• No obvious malicious strings in plain text

Execution was allowed.

YARA rule that could have caught it

A rule focused on generic loader behavior, not on a specific malware family.

rule Generic_Loader_PowerShell_Stager
{
    meta:
        description = "Detects generic loaders embedding PowerShell stagers"
        author = "xHuntr3ss"
        confidence = "medium"

    strings:
        $ps_1 = "powershell.exe" nocase
        $ps_2 = "-EncodedCommand" nocase
        $ps_3 = "FromBase64String" nocase
        $ps_4 = "IEX" nocase

    condition:
        filesize < 2MB and
        3 of ($ps_*)
}

What this would have done: Flagged the binary before execution, even though it looked like a harmless tool.

Layer 2 – Behavior & Events (Sigma)

What happened

Once executed:

• The binary spawned powershell.exe

• PowerShell ran with encoded commands

• A scheduled task was created for persistence

Sigma rule that should have detected it

title: Suspicious PowerShell Spawned by User-Downloaded Binary
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    ParentImage|endswith: '.exe'
    Image|endswith: 'powershell.exe'
    CommandLine|contains:
      - '-EncodedCommand'
  condition: selection
level: high

What this would have done: Detected malicious behavior independently of the file itself.

Layer 3 – Network Communication (Suricata)

What happened

Shortly after execution:

• The host established outbound HTTPS connections

• The destination was a recently registered domain

• Traffic followed a regular beaconing pattern

Suricata rule that should have detected it

alert http any any -> any any (
    msg:"Possible C2 beaconing via suspicious User-Agent";
    flow:established,to_server;
    http.user_agent;
    content:"Mozilla/5.0";
    pcre:"/^[A-Za-z0-9]{8,12}$/";
    sid:900001;
    rev:1;
)

What this would have done: Exposed command-and-control traffic even if endpoint alerts were missed.

Final Thoughts

At first glance, the examples in this article may look reactive. They are built from a real scenario, after all.

But the rules proposed here are not tied to a single incident.

They do not depend on:

• File hashes

• Specific domains or IPs

• File names

• Malware families

Instead, they focus on detecting:

• Classes of behavior

• Techniques, not individual samples

• Abuse patterns, not isolated IOCs

That is what proactive detection actually looks like.

Good detection doesn’t try to predict the next hash or domain. It assumes failure will happen, and builds visibility around how attackers operate.

Layered detection is not about catching everything early. It’s about making sure that when something slips through, it can’t stay invisible.

Resources

Rules Documentation

YARA'S Documentation

Welcome to YARA's documentation! — yara 4.4.0 documentationyara.readthedocs.io

SIGMA'S Documentation

Explore Sigmasigmahq.io

SURICATA'S Doccumentation

Suricata User Guide — Suricata 8.0.2 documentationdocs.suricata.io

Rules Collections

YARA Rules Repositories

Community-driven repository with thousands of YARA rules for different malware families and techniques.

GitHub - Yara-Rules/rules: Repository of yara rulesGitHub

SIGMAHQ Rules Repository

The official collection of Sigma rules, ready to use or study.

GitHub - SigmaHQ/sigma: Main Sigma Rule RepositoryGitHub

Emerging Threar Rules (Suricata/Snort)

Up-to-date network rules for Suricata and Snort, useful for studying network patterns and real threats.

Proofpoint Emerging Threats Rulesrules.emergingthreats.net

Rules Tools

SIGMA Converter

Converts Sigma rules into formats like Splunk, EQL, KQL, etc. Great for seeing how the same pattern is implemented in different SIEMs.

sigconverter.io - sigma rule convertersigconverter.io

yarGen

Tool to automatically generate YARA rules from malware samples or file collections.

GitHub - Neo23x0/yarGen: yarGen is a generator for YARA rulesGitHub