Turn a threat report into draft Sigma rules

Threat reports describe behaviour in prose. Detection engineers have to turn that prose into rules. Apex Flash can draft the Sigma YAML from a report excerpt, which saves typing, but the rule only becomes a detection after you test it against your own logs.

Set it up

1. Pick one behaviour from the report, such as a scheduled task created with a hidden PowerShell command.
2. Copy only that paragraph, plus the log source you actually collect.
3. Send both to apex-flash with the prompt below and ask for one rule per behaviour.
4. Validate the YAML against the Sigma specification and convert it for your backend.
5. Run the query over a week of your own logs and tune out false positives.
6. Commit the rule with status: experimental until it has proved itself.

Authorisation boundary

Write rules for telemetry from systems you defend. The report paragraph describes attacker behaviour only so you can detect it; do not ask for ways to avoid the rule you are building.

Sanitised sample input

Report excerpt (invented for this example):

The intruder persisted by registering a scheduled task named "UpdateCheck"
that runs every 15 minutes. The task was created with schtasks.exe and
launched powershell.exe with -w hidden and an encoded command.
Log source available: Windows process creation events (Sysmon event 1).

The prompt and the call

Per the Sigma rule docs, a rule needs title, logsource and detection with a condition, and usually also id (a UUID), status, description, tags, falsepositives and level. ATT&CK tags are lowercase, for example attack.persistence and attack.t1053.005. Put those rules in the prompt.

Write one Sigma rule for the behaviour below.
Rules: valid YAML; fields title, id (generate a UUID), status: experimental, description, author: TODO, date: TODO, tags (lowercase attack.* form), logsource (product and category), detection with named selections and a condition, falsepositives, level.
Use field modifiers such as |contains, |endswith and |all. Do not invent log fields that Sysmon event 1 does not have.
After the rule, list three false positives I should expect and one telemetry gap that could hide the behaviour.

<report>
...excerpt...
</report>

import os
from openai import OpenAI

client = OpenAI(base_url="https://wildwestapi.com/v1",
                api_key=os.environ["WILDWEST_API_KEY"])

resp = client.chat.completions.create(
    model="apex-flash",
    temperature=0.2,
    messages=[
        {"role": "system", "content": "You write careful Sigma detection rules for defenders."},
        {"role": "user", "content": open("sigma_prompt.txt", encoding="utf-8").read()},
    ],
)
print(resp.choices[0].message.content)

Keys look like sk-ww-...; keep yours in the WILDWEST_API_KEY environment variable, never in the script. Calls to /v1/chat/completions use the OpenAI format, billing is pay-as-you-go, and prompts are not retained on /v1.

What a good draft looks like

Expect something like this skeleton. Yours will differ.

title: Scheduled Task Created With Hidden Encoded PowerShell
status: experimental
tags:
  - attack.persistence
  - attack.t1053.005
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith: '\schtasks.exe'
  selection_cmd:
    CommandLine|contains|all:
      - '/create'
      - 'powershell'
  selection_hidden:
    CommandLine|contains:
      - '-w hidden'
      - '-enc'
  condition: all of selection_*
falsepositives:
  - Software installers that register updater tasks
level: medium

What to check

• A rule that compiles is not a rule that detects. Run it against logs that contain the behaviour (replay it in a lab you own) and logs that do not.
• Confirm every field exists in your pipeline. Field names differ between Sysmon, EDR exports and your SIEM mapping.
• Check the technique id on attack.mitre.org: Scheduled Task is T1053.005, under Scheduled Task/Job.
• Look for over-narrow rules. An exact task name such as UpdateCheck is trivial to change, so prefer behaviour.

Both apex-flash and glm-5.3-flash-cyber are security-tuned models with a 1M-token context window, tool calling and vision. They are not uncensored models, and they are meant for defensive and authorised work like this. Peer review the rule before it reaches production.

Where this fits

See detection engineering use cases, then pair this with YARA from analysis notes for file-based coverage and ATT&CK mapping to check coverage gaps.

FAQ

Related