Atomic & Stateful Detection Rules

Harnessing the Power of Precision and Context in Detection Engineering

Oct 14, 2024

Hello, readers! I had a topic in mind that I felt might make a good post for those breaking into the defensive side of information security: atomic and stateful detections.

What are they?

In detection engineering, effective detection strategies hinge on understanding the two primary types of detection rules: atomic and stateful. Both serve crucial purposes, and neither is inherently better than the other, as each has specific strengths depending on the goal.

Atomic detections focus on single, isolated events or activities that can be identified as malicious or benign without further context. These are quick and precise but limited in scope.

Stateful detections, often called correlation rules, rely on analyzing multiple events over time to build context and detect patterns of malicious behavior. They offer more depth but come with added complexity.

Simply put, atomic detections focus on identifying a single event as potentially harmful, while stateful rules analyze multiple events to reveal behaviors that might indicate a larger issue.

Example of an Atomic Detection

Let’s first look at a simple example for an atomic detection. Sigma is an open-source standard for writing detection rules in a platform-agnostic format, making it easier to share and apply detection logic across different systems and SIEMs. Below is an example of an atomic Sigma rule which looks for execution of whoami.exe with an unusually high privileged context for this process.

title: Whoami.EXE Execution From Privileged Process
id: 79ce34ca-af29-4d0e-b832-fc1b377020db
related:
    - id: 80167ada-7a12-41ed-b8e9-aa47195c66a1
      type: obsolete
status: test
description: Detects the execution of "whoami.exe" by privileged accounts that are often abused by threat actors
references:
    - https://speakerdeck.com/heirhabarov/hunting-for-privilege-escalation-in-windows-environment
    - https://web.archive.org/web/20221019044836/https://nsudo.m2team.org/en-us/
author: Florian Roth (Nextron Systems), Teymur Kheirkhabarov
date: 2022-01-28
modified: 2023-12-04
tags:
    - attack.privilege-escalation
    - attack.discovery
    - attack.t1033
logsource:
    category: process_creation
    product: windows
detection:
    selection_img:
        - OriginalFileName: 'whoami.exe'
        - Image|endswith: '\whoami.exe'
    selection_user:
        User|contains:
            - 'AUTHORI'
            - 'AUTORI'
            - 'TrustedInstaller'
    condition: all of selection_*
falsepositives:
    - Unknown
level: high

This rule only needs a single process creation event to find this criteria, therefore, it is atomic.

Example of a Stateful Detection

While Sigma is an extremely popular collection of open source detection rules, it has historically been limited to only atomic rules. However, recent advancements in the Sigma project have introduced support for stateful rules for some conversion backends.

One of the simplest and most popular examples of a stateful rule is looking for brute force activity. The approach is often “look for X number of failed logons over Y amount of time.” The logic is simple enough, but cannot be accomplished with atomic rules because the rule must observe multiple events over a time period. It gets even trickier when you add “X number of logons, by the same username OR from the same source IP, over Y amount of time.”

Here is an atomic detection looking for a single failed logon. (source)

title: Windows Failed Logon Event
name: failed_logon # Rule Reference
description: Detects failed logon events on Windows systems.
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4625
    condition: selection

This would be an incredibly noisy rule as failed logons happen all of the time.

If we want to detect only an unusually high number of failed logons in a short period of time, we’d need a stateful rule.

title: Multiple failed logons for a single user (possible brute force attack)
correlation:
    type: event_count
    rules:
        - failed_logon # Referenced here
    group-by:
        - TargetUserName
        - TargetDomainName
    timespan: 5m
    condition:
        gte: 10

Notice that we can define a timespan, condition, and even group-by values to fine-tune the behavior of our stateful rule. With this logic, our rule will only fire when 10 or more failed logons occur within 5 minutes, where the same username is observed across all events.

Now, it’s important to state that there are other types of stateful rules beyond a simple “X count over Y amount of time”… You can also track more complex things such as event ancestry. For instance, you might want to detect on a very particular process chain such as winword.exe → cmd.exe → wscript.exe → mshta.exe. This would be nearly impossible in an atomic rule, because often only the parent process information is available in the context of a process creation event. This means an atomic rule can only know one level above any given process event.

In the first example, if we only need to know when winword.exe directly launches mshta.exe, we could accomplish this by observing a single Event 4688 (or Sysmon Event 1) and find both the Image and Parent Image fields containing the required detection data.

In the second example, winword.exe still launches mshta.exe, but not directly. Multiple other processes are chained together before mshta.exe is ultimately executed. The only way to know that mshta.exe was a grandchild of winword.exe is with a stateful rule engine that can keep track of the entire chain.

Summary

In conclusion, both atomic and stateful detection rules play critical roles in detection engineering, each excelling in different scenarios. Atomic rules are fast, straightforward, and effective for simple, well-defined threats like detecting the execution of a specific malicious file, such as mimikatz.exe. In such cases, only a single event or piece of telemetry needs to be observed to trigger an alert, making atomic rules ideal for pinpointing specific behaviors quickly.

On the other hand, when dealing with more complex attack patterns that unfold over time or across multiple data points, stateful detection becomes invaluable. For instance, detecting a series of 12 failed login attempts by a user like john.doe within a 5-minute window requires correlating several events across a timeline to identify suspicious behavior. In this case, stateful rules are crucial for building context and uncovering more advanced or stealthy threats that might otherwise go unnoticed.

To build a robust detection strategy, it’s essential to leverage both atomic and stateful rules in your environment. Start by using atomic rules for known, high-confidence threats, while stateful rules can help uncover stealthy or advanced attacks that unfold over time.

To enhance your understanding and dive deeper into stateful and atomic detections, I recommend exploring the following resources:

Eric’s Substack

Discussion about this post