Sigma- und YARA-Regeln mit KI: vom Entwurf zur getesteten Detection

Detection-Regeln zu schreiben ist im Wesentlichen Übersetzungsarbeit: Eine Angriffsbeschreibung oder ein Haufen extrahierter Strings geht hinein, eine präzise Regel kommt heraus. Ein Sprachmodell ist gut in dieser Übersetzung, solange es sich nicht weigert, über das Angreiferverhalten zu sprechen, das du erkennen willst. Diese Anleitung zeigt, wie du mit Odin v1 Sigma- und YARA-Regeln entwirfst, tunst, in SIEM-Queries umwandelst und vor dem Produktiveinsatz testest.

Wo ein Modell hilft und wo nicht

Odin v1 beschleunigt die Teile, die langwierig, aber nicht schwer sind: einen Absatz aus einem Threat-Report in eine erste Sigma-Regel übersetzen, aus einem langen strings-Dump Kandidaten-Strings herauspicken, Filter für verrauschte Treffer vorschlagen und erklären, warum eine Regel ausgelöst hat oder eben nicht.

Testen ersetzt es nicht. Ein Modell hat deine Umgebung und deine Log-Pipeline nie gesehen. Behandle jede generierte Regel als Entwurf: Prüfe die Syntax mit echten Tools, lass die Regel gegen harmlose Daten laufen und dann im Lab gegen ein bekanntermaßen bösartiges Sample.

Sigma-Regeln aus einer Angriffsbeschreibung

Beginne mit einer kurzen, konkreten Beschreibung des Verhaltens. Vager Input („erkenne bösartige PowerShell“) ergibt vage Regeln. Ein guter Prompt nennt die Logquelle, das Verhalten und das Rauschen, das du bereits kennst:

Schreib eine Sigma-Regel für Windows-Logs zur Prozesserstellung (Sysmon Event ID 1 oder Security 4688 mit Kommandozeilen-Auditing). Erkenne powershell.exe oder pwsh.exe, gestartet mit -EncodedCommand oder einer seiner Kurzformen (-e, -ec, -en, -enc). Matche auf Image und OriginalFileName, damit auch umbenannte Binaries erfasst werden. Unser SCCM-Client (C:\Windows\CCM\CcmExec.exe) startet legitim kodierte Befehle, filtere ihn also heraus. Füge ATT&CK-Tags, False Positives und ein Level hinzu.

Rechne mit einer vollständigen YAML-Regel und Hinweisen zu den Abwägungen: -e mit umgebenden Leerzeichen verhindert einen Treffer auf -ExecutionPolicy, PowerShell akzeptiert jedes eindeutige Parameterpräfix, und ein Filter auf den Elternprozess kann von einem Angreifer missbraucht werden, der diesen Elternprozess kontrolliert. Nach dem Review sieht die Regel so aus:

title: PowerShell Started With an Encoded Commandid: 3f6b2a9e-5c1d-4e8a-9b27-0d4c8e1f7a63status: experimentaldescription: Detects powershell.exe or pwsh.exe launched with the -EncodedCommand parameter or one of its short forms, often used to hide script content.references:    - https://attack.mitre.org/techniques/T1059/001/author: InterOdin teamdate: 2026-10-20tags:    - attack.execution    - attack.t1059.001    - attack.t1027logsource:    category: process_creation    product: windowsdetection:    selection_img:        - Image|endswith:              - '\powershell.exe'              - '\pwsh.exe'        - OriginalFileName:              - 'PowerShell.EXE'              - 'pwsh.dll'    selection_cli:        CommandLine|contains:            - ' -e '            - ' -ec '            - ' -en '            - ' -enc '            - ' -enco'    filter_main_sccm:        ParentImage: 'C:\Windows\CCM\CcmExec.exe'    condition: all of selection_* and not 1 of filter_main_*falsepositives:    - Configuration management agents and admin scripts that pass encoded commandslevel: medium

Derselbe Ansatz funktioniert für Living-off-the-Land-Binaries (LOLBins). Beschreibe pro Regel genau ein Missbrauchsmuster, zum Beispiel „certutil.exe mit urlcache oder verifyctl lädt eine Datei über HTTP herunter“:

title: Certutil Used to Download a Remote Fileid: 8c41d0e7-2b6f-4a59-a3d8-61e9f2b07c14status: experimentaldescription: Detects certutil.exe called with urlcache or verifyctl and a URL on the command line, a common living-off-the-land download technique.references:    - https://attack.mitre.org/techniques/T1105/author: InterOdin teamdate: 2026-10-20tags:    - attack.command-and-control    - attack.t1105logsource:    category: process_creation    product: windowsdetection:    selection_img:        - Image|endswith: '\certutil.exe'        - OriginalFileName: 'CertUtil.exe'    selection_flags:        CommandLine|contains:            - 'urlcache'            - 'verifyctl'    selection_url:        CommandLine|contains:            - 'http://'            - 'https://'    condition: all of selection_*falsepositives:    - Rare administrative use to fetch certificates or revocation listslevel: high

Erzeuge für jede Regel selbst eine neue UUID; übernimm nie eine id aus einem Beispiel.

YARA-Regeln aus extrahierten Strings

Bei YARA ist der Input das Ergebnis deiner statischen Analyse: Ausgaben von strings oder FLOSS, PE-Metadaten, auffällige Bytefolgen aus einem Disassembler. Odin v1 akzeptiert nur Text, füge diese Daten also als Text ein. Dank des Kontextfensters von 1.000.000 Tokens kannst du Strings aus mehreren Vertretern einer Familie auf einmal mitgeben, und genau das willst du: Eine gute Familienregel baut auf Strings auf, die in mehreren Samples vorkommen und in sauberer Software selten sind.

Unten stehen FLOSS-String-Dumps von vier Samples derselben Loader-Familie, gesammelt in unserem Malware-Lab. Wähle Strings, die in mindestens drei Samples vorkommen und in harmloser Software unwahrscheinlich sind. Vermeide API-Namen, Compiler-Artefakte und gängige Library-Strings. Schreib eine YARA-Regel für PE-Dateien unter 2 MB und erkläre, warum du jeden String gewählt hast.

Rechne mit einer Regel, einer Begründung für jeden gewählten String und den verworfenen Strings (etwa kernel32.dll oder ein Standard-User-Agent eines Browsers). Für die fiktive Familie aus unserem Walkthrough zur Malware-Triage sieht das Ergebnis so aus:

rule SyncHost_Loader_Strings{    meta:        description = "Fictional loader family used as an example on the InterOdin blog"        author = "InterOdin team"        date = "2026-10-20"        reference = "Synthetic strings, not a real malware family"
    strings:        $pdb   = "C:\\build\\synchost\\Release\\loader.pdb" ascii        $mutex = "Global\\SyncHostUpdateMtx" ascii wide        $ua    = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) SyncHost/2.1" ascii        $task  = "OneDrive Sync Helper" ascii wide        $path  = "/a/upd.dat" ascii        $cfg   = { 53 48 43 46 47 01 00 ?? ?? 00 00 }
    condition:        uint16(0) == 0x5A4D and        filesize < 2MB and        ( $pdb or $cfg or 3 of ($mutex, $ua, $task, $path) )}

Ein String mit hoher Aussagekraft (der PDB-Pfad oder der Config-Header) reicht allein aus, schwächere Strings müssen gemeinsam auftreten. Lass das Modell jeden String begründen; kann es das nicht, streich den String.

False Positives tunen

Eine Regel, die 400-mal am Tag anschlägt, wird abgeschaltet. Beim Tuning spart ein Modell am meisten Zeit: Die Arbeit besteht darin, viele verrauschte Treffer zu lesen und Muster zu erkennen. Exportiere die Treffer aggregiert nach Eltern-Image, Benutzer und Kommandozeile, schwärze Hostnamen und Benutzernamen, die du nicht brauchst, und frag:

Das sind die Treffer der Regel für kodierte PowerShell aus 7 Tagen, gruppiert nach ParentImage und Präfix der CommandLine. Welche Gruppen sehen nach legitimer Software aus? Schlag Sigma-Filter vor, die so eng wie möglich sind, und sag mir, was ein Angreifer kontrollieren müsste, um den jeweiligen Filter zu missbrauchen.

Gute Tuning-Gewohnheiten, die du im Prompt und im Review durchsetzen solltest:

• Filtere auf vollständige Pfade plus Elternprozess, nicht auf einen Teilstring der Kommandozeile, den ein Angreifer kopieren kann.
• Verwende die Sigma-Konvention filter_main_* für Filter, die überall gelten, und filter_optional_* für umgebungsspezifische.
• Senke das level, statt einen Filter hinzuzufügen, wenn du den Filter nicht eng genug bekommst.
• Scanne bei YARA ein großes Goodware-Set (eine saubere Windows-Installation, dein Software-Repository) und entferne jeden String, der dort trifft.

Sigma in eine SIEM-Query umwandeln

Sigma-Regeln werden mit sigma-cli konvertiert. Es nutzt pySigma-Backends und Processing-Pipelines, um generische Felder auf dein Log-Schema abzubilden:

pip install sigma-clisigma plugin install splunksigma plugin install sysmonsigma check rules/sigma convert -t splunk -p sysmon rules/powershell_encoded_command.yml

Für die Regel zu kodierter PowerShell lautet die Splunk-Ausgabe:

EventID=1 Image IN ("*\\powershell.exe", "*\\pwsh.exe") OR OriginalFileName IN ("PowerShell.EXE", "pwsh.dll") CommandLine IN ("* -e *", "* -ec *", "* -en *", "* -enc *", "* -enco*") NOT ParentImage="C:\\Windows\\CCM\\CcmExec.exe"

Für Elastic installierst du das Plugin elasticsearch und verwendest -t lucene -p ecs_windows. Nimm lieber das Tool, als das Modell von Hand konvertieren zu lassen: Backends erledigen Escaping und Feld-Mapping konsistent.

Gegen harmlose Logs und Lab-Samples testen

Jede Regel braucht vor dem Deployment zwei Tests.

Ein Negativtest. Lass die Regel über eine bekanntermaßen saubere Baseline laufen, etwa eine Woche Prozesserstellungs-Logs von Lab-Maschinen und einigen repräsentativen Workstations. Tools wie Chainsaw und Zircolite wenden Sigma-Regeln direkt auf EVTX-Exporte an, oder du führst die konvertierte Query in deinem SIEM über ein ruhiges Zeitfenster aus. Jeder Treffer ist ein False Positive, den du erklären oder herausfiltern musst.

Ein Positivtest. Löse das Verhalten in einer isolierten Lab-VM aus und bestätige, dass die Regel anschlägt. Für die Regel zu kodierter PowerShell genügt ein harmloser Befehl:

$cmd = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes("Write-Output 'sigma test'"))powershell.exe -NoProfile -EncodedCommand $cmd

Bei YARA sieht das Pendant so aus:

yara -s -r synchost.yar ./family_samples/   # should match every known family memberyara -r synchost.yar ./goodware/            # should print nothing

Bewahre echte Samples in der Analyse-VM auf, niemals auf einer Workstation.

Die Schleife aus Entwurf und Prüfung automatisieren

Das folgende Skript schickt eine Verhaltensbeschreibung an Odin v1, extrahiert das YAML, parst es mit pySigma (das bei ungültigen Regeln einen Fehler wirft) und gibt die Splunk-Query aus. Installiere die Abhängigkeiten mit pip install openai sigma-cli pysigma-backend-splunk pysigma-pipeline-sysmon.

import osimport reimport sys
from openai import OpenAIfrom sigma.backends.splunk import SplunkBackendfrom sigma.collection import SigmaCollectionfrom sigma.pipelines.sysmon import sysmon_pipeline
client = OpenAI(base_url="https://api.interodin.com/v1", api_key=os.environ["INTERODIN_API_KEY"])
SYSTEM = (    "You are a detection engineer. Write exactly one Sigma rule in YAML for the behavior "    "described. Use logsource category process_creation and product windows, use Sigma "    "modifiers, list realistic false positives, and return only the YAML.")

def draft_rule(description: str) -> str:    resp = client.chat.completions.create(        model="odin-v1",        messages=[{"role": "system", "content": SYSTEM}, {"role": "user", "content": description}],    )    text = resp.choices[0].message.content    fenced = re.search(r"`{3}(?:ya?ml)?\n(.*?)`{3}", text, re.DOTALL)    return fenced.group(1) if fenced else text

def to_splunk(rule_yaml: str) -> str:    rules = SigmaCollection.from_yaml(rule_yaml)    return SplunkBackend(sysmon_pipeline()).convert(rules)[0]

if __name__ == "__main__":    rule = draft_rule(sys.stdin.read())    print(rule)    print("--- Splunk ---")    print(to_splunk(rule))

Starte es mit python draft_sigma.py < behavior.txt. Schlägt das Parsen fehl, gib die Fehlermeldung an das Modell zurück und bitte um einen Fix. Ein Harness, das YARA-Regeln gegen Ordner mit Samples und Goodware laufen lässt, findest du unter Security-Tooling mit Claude Code auf Odin bauen. Die Einrichtung des Clients beschreibt die Anleitung zum OpenAI SDK.

Loslegen

Erstelle einen API-Key in der Konsole, folge dem Quickstart und richte das Skript oben auf ein Verhalten aus deinem neuesten Threat-Report. Halte den Umgang mit Samples in deinem Lab und deine Arbeit innerhalb der Acceptable Use Policy.