Detection Engineering

Overview

Fleet provides a complete detection engineering workflow: describe what you want to detect in natural language, and Fleet generates the rule, validates it, converts it to your SIEM’s query language, and optionally tests it against sample logs. Fleet supports YARA, Sigma, osquery, and Suricata rule formats.

The detection engineering workflow follows a consistent pattern across all rule types:

1. Describe — tell Fleet what you want to detect (a behavior, a malware family, an attack technique, or a specific indicator).
2. Generate — Fleet creates the rule with proper syntax, metadata, and detection logic.
3. Validate — Fleet compiles or checks the rule to ensure it is syntactically correct.
4. Convert (Sigma only) — Fleet converts the rule to Splunk SPL, Microsoft Sentinel KQL, or other SIEM query languages.
5. Test (optional) — Fleet runs the rule against sample files or logs to verify it triggers correctly.
6. Deploy (optional) — if connected to AIR, Fleet can deploy the rule to endpoints for live scanning.

YARA Rules

YARA is a pattern-matching tool used to identify and classify malware based on textual or binary patterns. Fleet can generate, validate, fix, and scan with YARA rules.

Generating YARA Rules

Fleet creates YARA rules from:

• Natural language descriptions — describe the malware behavior, indicators, or characteristics you want to detect.
• Malware analysis findings — after analyzing a binary, Fleet can generate a YARA rule based on the unique strings, imports, and structural indicators it found.
• Threat intelligence — provide IOCs or a threat report, and Fleet generates rules targeting the described indicators.
• Observable extraction — Fleet can run its full observable extraction and enrichment pipeline and generate YARA rules directly from the enriched results.

Example prompts:

Create a YARA rule to detect in-memory execution of Mimikatz.

Generate a YARA rule based on the strings and imports found in the attached binary.

Create a YARA rule that detects remote control software (TeamViewer, AnyDesk, Radmin) commonly abused by attackers.

Validating and Fixing YARA Rules

Fleet validates that generated rules compile successfully. If you provide a broken YARA rule, Fleet identifies the syntax errors, explains what is wrong, and fixes the rule.

Example prompt:

This YARA rule won't compile. Fix it and explain what was wrong.

Scanning with YARA Rules

Fleet can scan files in the workspace using a YARA rule to test for matches. Results include the matched rule name, file path, and which strings triggered the match.

Example prompt:

Scan all files in the workspace with this YARA rule and show me the matches.

Sigma Rules

Sigma is a generic signature format for log-based detections. Fleet can generate, validate, convert, and test Sigma rules.

Generating Sigma Rules

Fleet creates Sigma rules with proper metadata including rule ID, title, status, description, author, date, references, logsource definitions, and detection logic using selection/filter/condition patterns.

Inputs:

• Attack scenario descriptions with MITRE ATT&CK technique references
• Sample log entries showing the behavior to detect
• Threat intelligence reports describing adversary techniques
• Natural language descriptions of suspicious behavior

Example prompts:

Create a Sigma rule to detect encoded PowerShell execution via Event ID 4688.

Build a Sigma rule for detecting scheduled task creation used for persistence (T1053.005).

Generate Sigma rules for each stage of this attack: spearphishing -> encoded PowerShell -> process hollowing -> scheduled task -> HTTPS exfiltration.

Validating Sigma Rules

Fleet validates generated rules against the Sigma specification, checking for syntax errors, invalid logsource definitions, and detection logic issues.

Converting to SIEM Queries

Fleet converts validated Sigma rules to the query languages used by major SIEM platforms:

Target Platform	Query Language
Splunk	SPL (Search Processing Language)
Microsoft Sentinel	KQL (Kusto Query Language)

Example prompt:

Convert this Sigma rule to both Splunk SPL and Microsoft Sentinel KQL.

Testing Against Logs

Fleet can test Sigma rules against sample log files to verify they trigger correctly:

• EVTX files — Windows Event Log files are parsed and matched against the Sigma detection logic.
• JSONL files — JSON-lines log files are evaluated event by event against the Sigma detection block, supporting all standard modifiers (contains, endswith, startswith, regex, all) and condition combinators.

Example prompt:

Test this Sigma rule against the attached EVTX file and show me which events match.

Correlation Rules

For multi-stage attack detection, Fleet can create correlation meta-rules that chain individual Sigma rules together with time-based correlation windows. This enables detection of complete attack sequences rather than isolated events.

Example prompt:

Create a correlation rule that chains these five Sigma rules into a single detection for the full attack sequence, with a 24-hour correlation window.

osquery Queries

osquery uses SQL to query endpoint state. Fleet generates and validates osquery queries from natural language.

Generating osquery Queries

Fleet creates osquery SQL queries targeting the appropriate tables and columns for your request.

Example prompts:

Write an osquery query that lists all USB devices connected in the last 24 hours.

Create an osquery query to find all processes listening on network ports.

Generate an osquery query that checks for unauthorized SSH keys in all user home directories.

Validating osquery Queries

Fleet validates generated queries by checking:

• SQL syntax correctness
• Table and column name validity against the osquery schema
• Common mistakes (SELECT *, invalid strftime usage, wrong column names)

Suricata Rules

Suricata is a network-based IDS/IPS. Fleet can validate Suricata rule syntax to ensure rules are correctly formatted before deployment.

Example prompt:

Validate this Suricata rule for syntax errors.

End-to-End Workflow Example

Here is a typical detection engineering workflow in Fleet:

1. You: “An analyst reported seeing encoded PowerShell commands in Event ID 4688 logs. Create detection rules for this.”
2. Fleet: generates a Sigma rule targeting PowerShell execution with Base64-encoded commands in process creation events.
3. Fleet: validates the rule against the Sigma specification.
4. Fleet: converts the rule to Splunk SPL and Microsoft Sentinel KQL.
5. You: “Test it against this EVTX file.” (attach file)
6. Fleet: runs the rule against the EVTX file and reports which events match.
7. You: “Deploy this to all Windows endpoints.”
8. Fleet: deploys the rule to AIR endpoints via triage (requires AIR integration).

Limitations

• Sigma conversion is currently supported for Splunk SPL and Microsoft Sentinel KQL. Additional backends may be added in the future.
• Suricata support is limited to syntax validation. Fleet does not generate Suricata rules from scratch.
• YARA scanning runs against files in the workspace only. Live endpoint scanning requires deployment through AIR triage.