Sigma Detection Node

Quick Reference

• Input event format: whether your events are already OCSF, or raw logs as your log shipper sends them.
• Log type: OCSF input. The kinds of OCSF events you send, for example Windows Sysmon or AWS CloudTrail.
• Data sources: raw-log input. The products and logs you send, for example Windows Security or Okta System Log.
• Severity level: the lowest rule severity to run.
• Rule exclusions: rules to leave out.
• Total Applied: how many rules the node will run; click it to browse them.

Configuration

Configuration keys below are relative to the node configuration. Use the field name in the panel when following instructions in the builder; required markers such as an asterisk are not part of the name.

Field in the panel	Configuration key	Where to edit / when shown
Input event format	inputFormat	Configure detection input. OCSF or Non-OCSF (raw logs). Required: Yes.
Log type	logTypeIds[]	Configure detection input, for OCSF input; disabled until an input format is selected. Pick one or more. Required: Yes.
Data sources	sourceIds[]	Configure detection input, for raw-log input instead of Log type. Pick one or more; they are grouped by product. Required: Yes.
Severity level	minLevel	Configure detection rule. Runs rules of this severity and higher. Required: Yes. Placeholder: Select a severity package.
Rule exclusions	excludedRuleIds[]	Configure detection rule. Add exclusion or Edit Exclusions opens the rule browser, where you move rules out of the applied set. Required: No.
Total Applied	UI only; no separate config key	Shows how many rules will run for your choices; opens a read-only list of those rules.

Overview

The Sigma Detection node checks your security logs for known attacker behavior. It runs Sigma rules, the open, community-maintained detection rules from SigmaHQ, against every event that passes through it: for example a credential-dumping tool starting on a Windows host, the AWS root account being used, or someone listing all secrets in a Kubernetes cluster.

Every event continues downstream unchanged. When an event matches one or more rules, the node adds a sigma_matches field that names each rule, its severity and its MITRE ATT&CK tags. Route or filter on that field to send alerts to your SIEM, a ticketing system or a notification channel.

Use it when you want detections on logs as they flow through Fleak, without writing the rules yourself.

Setting behavior

1. Choose the Input event format:
   • OCSF if your events are already in the Open Cybersecurity Schema Framework format, for example from AWS Security Lake or the Fleak OCSF mapper. Then choose one or more Log types.
   • Non-OCSF (raw logs) if you send logs as your shipper or product writes them. Then choose one or more Data sources.
2. Choose a Severity level. Higher levels run fewer rules and raise fewer, more serious alerts.
3. Optionally exclude rules that are noisy in your environment.
4. Check Total Applied for the rules that will run, then use a test run with a sample of your logs (see Test runs).

The panel shows which SigmaHQ rule release the node uses, linked to that release on GitHub. The list of log types, data sources and rules comes from Fleak's rule catalog. If it does not load, use Retry; the panel cannot be completed without it. In a read-only workflow you can view the configuration but not change exclusions.

Behavior

Raw logs: what you can send

Data sources

• Windows event logs: Sysmon, Security, System, PowerShell, Application, Defender, Firewall, Task Scheduler, DNS Client and about 25 other Windows logs (the panel lists them all), plus Microsoft Exchange Management.
• AWS CloudTrail, Okta System Log, GitHub audit log and Kubernetes audit log.

Pick every data source you send to the node. Events from a data source you did not pick are not checked.

Windows log shippers

Send one Windows event per message, as one of these shippers writes it:

• Winlogbeat 8 or later, or Elastic Agent, sent to Fleak directly (not after Elasticsearch has processed the events)
• NXLog
• Fluent Bit, with event_data_as_map: true on the winevtlog input (see below)
• OpenTelemetry Collector windowseventlog receiver in map mode, sent directly or through Fleak's OTel source node, which is not generally available
• Microsoft Sentinel SecurityEvent or WindowsEvent tables, read with Fleak's Microsoft Sentinel source, which is not generally available (for WindowsEvent, see below)
• Windows event XML, one event per message, read with the XML encoding

Other products: send each CloudTrail record, Okta System Log event, GitHub audit log event or Kubernetes audit event as its own message, as the product writes it. If your source delivers several events in one message (a CloudTrail log file with Records, an Azure Event Hub message with records, a Kubernetes EventList), split it into one event per message first.

Not supported yet: Windows events forwarded inside another product's JSON (for example Splunk), EVTX files, Velociraptor or Wazuh output, the Parser node's Windows Multiline output, OpenTelemetry array mode, Kubernetes audit logs from GKE or AKS, and products not listed above. For these, forward the events with one of the shippers above, or convert them to OCSF and use OCSF input.

Raw logs: settings your data may need

Microsoft Sentinel WindowsEvent: Fleak's Microsoft Sentinel source delivers the EventData column as text, so rules cannot read the event fields. Add a Parser node before the Sigma Detection node with:

• Target Field: EventData
• Extraction Type: JSON
• Output Field Name (Optional): EventData (replace the default parsed_json)
• Remove Target Field: off

SecurityEvent needs no Parser node.

Fluent Bit: by default Fluent Bit sends Windows event data without field names, so only rules on basic event properties (event ID, log name, provider, computer) can match. Set event_data_as_map: true on the winevtlog input.

Kubernetes: rules about pod settings, such as privileged containers or host-path volumes, need your audit policy to log pod creation at the Request or RequestResponse level.

OCSF: what your events need

The node decides which log type an OCSF event belongs to from a few of its fields. If they are missing, the event is not checked by that log type's rules:

• Windows: metadata.log_name holds the Windows event log name, such as Security or Microsoft-Windows-Sysmon/Operational, and metadata.event_code holds the event ID as text, such as "4624".
• Web Server and Proxy: the event is HTTP Activity (OCSF class 4002).
• Azure: the product name contains Azure or Entra.
• Microsoft 365: the product name contains Microsoft 365, Office 365 or O365.

Some Windows logs, such as WMI Activity, LSA, OpenSSH and Terminal Services, have no OCSF log type; send them as raw logs instead. OCSF made by a mapper may need adjusting to meet these points, and a test run shows the events it did not recognize.

Test runs

A test run of the workflow shows, for each Sigma Detection node, how many sample events the node did not recognize, and why:

• the events come from a data source or log type you did not select
• the events are wrapped in an array; split them into one event per message
• Windows events lack the log name or event ID
• the Windows log is not supported yet
• the events were already processed by Elasticsearch
• OCSF input only: the events are not OCSF, or no log type takes them (their OCSF class is not covered, or they lack the fields above)
• the format is not one the node reads

It also warns when Sentinel WindowsEvent data still has its event data as text (add the Parser node above), or when Fluent Bit sends event data without field names. Unrecognized events still pass downstream; they are just not checked.

Known limitations

• A small number of community rules depend on data that one of these log formats does not carry, and never match on it. For example, on raw Windows logs the rule "Eventlog Cleared" never matches, and "Important Windows Eventlog Cleared" alerts whenever any Windows event log is cleared, not only important ones; exclude it if that is too noisy.
• Raw-log Sigma nodes need the current Sigma engine. If your compute cluster is pinned to an older engine version, the node fails to start with Unrecognized field "inputNormalizer". Ask an administrator to clear the cluster's zephflow-plus version setting or set it to latest, then redeploy the workflow.

Examples

With Input event format Non-OCSF (raw logs), Data sources AWS CloudTrail and Severity level Low, Medium, High, Critical, this CloudTrail record, an S3 bucket listing by the root account:

{
  "eventVersion": "1.04",
  "eventTime": "2017-02-12T19:57:06Z",
  "eventSource": "s3.amazonaws.com",
  "eventName": "ListBuckets",
  "eventType": "AwsApiCall",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "255.253.125.115",
  "userAgent": "[S3Console/0.4]",
  "userIdentity": {
    "type": "Root",
    "principalId": "811596193553",
    "arn": "arn:aws:iam::811596193553:root",
    "accountId": "811596193553",
    "sessionContext": {
      "attributes": { "mfaAuthenticated": "false", "creationDate": "2017-02-12T19:57:05Z" }
    }
  },
  "requestParameters": null,
  "responseElements": null,
  "requestID": "83A6C73FE87F51FF",
  "eventID": "3038ebd2-c98a-4c65-9b6e-e22506292313",
  "recipientAccountId": "811596193553"
}

leaves the node with this field added:

"sigma_matches": [
  {
    "rule_id": "8ad1600d-e9dc-4251-b0ee-a65268f29add",
    "title": "AWS Root Credentials",
    "level": "medium",
    "tags": ["attack.privilege-escalation", "attack.initial-access", "attack.persistence", "attack.stealth", "attack.t1078.004"]
  },
  {
    "rule_id": "f305fd62-beca-47da-ad95-7690a0620084",
    "title": "Potential Bucket Enumeration on AWS",
    "level": "low",
    "tags": ["attack.discovery", "attack.t1580", "attack.t1619"]
  }
]

To pass on only the events that matched a rule, follow the node with a Filter node on $.sigma_matches != null.

Related nodes

• Parser: Parse Microsoft Sentinel WindowsEvent data before detection
• Filter: Keep only events that matched a rule
• Throttle: Limit repeated alerts for the same host or user