Eine YARA-Regel für Malware schreiben: von der Probe zur zuverlässigen Signatur (ohne Fehlalarme)

Sie erhalten eine Probe: einen präparierten Anhang aus einem Incident-Response-Einsatz, eine von Ihrer Sandbox gemeldete Binärdatei, eine von einem Threat-Intelligence-Feed markierte Datei. Die Frage ist nicht „Was ist das?" (die Analyse wird es zeigen) sondern „Wie viele weitere Exemplare dieser Familie schlummern in meinem Bestand?". YARA ist das Standardwerkzeug für die Antwort: eine Regelsprache, die Muster beschreibt (Zeichenketten, Bytes, Struktur) und sie in großem Maßstab in Dateien, Speicher oder einem Repository sucht.

Die Falle ist überall in der Erkennung dieselbe: eine zu lockere Regel löst bei völlig sauberer Software aus (Fehlalarm, Sie ertränken den Analysten), eine zu strenge Regel erkennt nur die exakte Probe und verpasst den Rest der Familie (falsch-negativ, Sie halten sich für geschützt). Dieser Artikel zeigt, wie man eine Regel schreibt, die die Familie fängt, ohne blinden Alarm zu schlagen, und vor allem, wie man es beweist.

Warum eine eigene Regel schreiben

• Frische, gezielte Bedrohungen. Malware, die bei Ihnen in einem DFIR-Einsatz gesehen wurde, eine regionale Variante, ein maßgeschneidertes Implantat: keine öffentliche Sammlung deckt sie rechtzeitig ab, wenn überhaupt.
• Ihre eigenen Proben. Was Ihre Sandbox und Ihre Vorfälle produzieren, ist exklusives Material. Die daraus entstehende Regel erkennt, was sonst niemand sieht.
• Die Präzision. Eine generische Drittanbieter-Regel mag eine Familie „treffen", um den Preis von Fehlalarmen, die Sie nicht dulden. Eine eigene Regel bedeutet, diesen Schwellenwert für Ihre Umgebung einzustellen.

Der Aufbau einer YARA-Regel

Eine Regel hat drei Blöcke: meta (die Metadaten), strings (die gesuchten Muster) und condition (die Logik, die sie kombiniert).

rule ACME_Stealer_Downloader {
    meta:
        description = "ACME Stealer - Download-Stufe"
        author      = "ihr-team"
        reference   = "interner DFIR-Bericht 2026-07"
        date        = "2026-07-16"
        hash        = "e3b0c44298fc1c149afbf4c8996fb924..."
 
    strings:
        $mz   = { 4D 5A }                       // PE-Header "MZ"
        $s1   = "acme_stealer_v" ascii
        $s2   = "/gate.php?id=" ascii
        $pdb  = "C:\\build\\acme\\loader.pdb" ascii
 
    condition:
        $mz at 0 and 2 of ($s1, $s2, $pdb)
}

(Das Beispiel ist illustrativ: Die Methode zählt mehr als die gewählte Familie.) Der meta-Block dokumentiert die Regel und macht sie nutzbar (Referenz, Hash, Datum). Der strings-Block listet die Muster, Text (ascii, wide), Bytes ({ 4D 5A }) oder reguläre Ausdrücke. Der condition-Block ist das Herzstück: Er entscheidet anhand der vorhandenen Muster, ob die Datei passt.

Von der Probe ausgehen, nicht von einer kopierten Regel

Der Reflex ist, eine bestehende Regel für die Familie zu suchen und zu übernehmen. Zwei Gründe zur Vorsicht.

Erstens die rechtliche Sorgfalt: eine unter Copyleft-Lizenz (GPL) oder ohne Lizenz veröffentlichte Regel darf nicht unverändert in ein geschlossenes oder weiterverkauftes Regelset, sie würde dessen Rechte kontaminieren. Die Tatsache hingegen, die die Probe trägt, eine bestimmte interne Zeichenkette, ein PDB-Pfad, ein C2-Marker, gehört niemandem. Die daraus abgeleitete Signatur ist Ihr Werk, so wie eine Antiviren-Signatur nicht die Rechte der Malware erbt, auf die sie zielt.

Zweitens die Qualität: eine gute Regel beschreibt, was die Familie charakterisiert, nicht, was zufällig in irgendeiner Datei steht. Man extrahiert die Zeichenketten und Byte-Folgen der Probe und behält die unterscheidenden. Werkzeuge wie yarGen automatisieren den ersten Entwurf: Sie extrahieren die Zeichenketten und vergleichen sie mit einer Datenbank legitimer Dateien („Goodware"), um jene auszusortieren, die überall vorkommen. Doch ihre Ausgabe ist ein Entwurf, die menschliche Prüfung bleibt unverzichtbar.

Gute Zeichenketten wählen: der springende Punkt

Hier wird die Zuverlässigkeit gewonnen oder verloren.

• Meiden Sie generische Zeichenketten. Microsoft Corporation, GetProcAddress, eine bekannte Bibliotheks-URL: sie stehen in Tausenden sauberer Dateien. Sie einzubauen heißt, Fehlalarme zu unterschreiben.
• Bevorzugen Sie eindeutige Marker. Eine interne Zeichenkette des Malware-Autors (acme_stealer_v), ein PDB-Kompilierpfad, ein Mutex, ein C2-Muster, eine ungewöhnliche Fehlermeldung. Das sind die Fingerabdrücke, die die Familie von Probe zu Probe mitschleppt.
• Verankern Sie mit der Struktur. Für eine Windows-Binärdatei ist imphash (der Hash der Importtabelle) ein starker Anker: zwei aus demselben Quellcode kompilierte Binärdateien teilen ihn oft. Kombiniert mit zwei oder drei unterscheidenden Zeichenketten macht er die Regel präzise und variantenresistent.

Die Bedingung: weder zu locker noch zu streng

Die Bedingung verwandelt Muster in ein Urteil. Einige Prinzipien:

• Begrenzen Sie. filesize < 500KB vermeidet unnötiges Scannen großer Dateien und schneidet Fehlalarme ab.
• Prüfen Sie den Typ. uint16(0) == 0x5A4D bestätigt eine PE-Datei, bevor es weitergeht.
• Fordern Sie ein Quorum. 2 of ($s*) (zwei Muster von mehreren) fängt Varianten, die nicht alle Zeichenketten haben, und bleibt dennoch unterscheidend. Alle fünf zu fordern beschränkt Sie auf die exakte Probe.

Die richtige Einstellung liegt zwischen „einem einzigen Muster" (zu viel Rauschen) und „allen Mustern" (Überanpassung an eine Datei). Zwei bis drei unterscheidende Marker, durch die Struktur verankert, sind oft der Gleichgewichtspunkt.

Validieren genügt nicht: man muss beweisen

YARA kompiliert die Regel und meldet Syntaxfehler:

yara meine_regeln.yar probe.bin

Und ein Linter wie yaraQA erkennt die klassischen Mängel, eine Regel, die nie treffen kann, einen für die Leistung ruinösen regulären Ausdruck. Notwendig, aber nicht ausreichend: „kompiliert" sagt nichts über „erkennt gut".

Der echte Beweis ist empirisch und läuft auf zwei Tests hinaus:

1. Löst die Regel bei der ganzen Familie aus? Lassen Sie sie über Ihr gesamtes Probenset der Familie laufen (Retro-Match). Fängt sie nur die Originaldatei, ist sie überangepasst, erweitern Sie die Zeichenketten oder senken Sie das Quorum.
2. Bleibt sie bei sauberer Software stumm? Lassen Sie sie über einen gutartigen Korpus (Goodware) laufen, Ihre Systembinärdateien, Ihre legitimen Anwendungen. Jeder Treffer ist ein Fehlalarm, der vor dem Ausrollen zu beheben ist. Das ist der Test, den die meisten öffentlichen Regeln nie durchlaufen haben.

Eine Regel, die beide Prüfungen bestanden hat, ist unendlich viel mehr wert als eine bloß „gültige". Das ist der Unterschied zwischen „kompiliert" und „funktioniert, bewiesen, ohne Rauschen".

Die Fallen, die teuer werden

• Die vergessene Goodware-Zeichenkette. Die häufigste Quelle von Fehlalarmen. Der Test gegen den gutartigen Korpus ist nicht optional.
• Die Regel, die nichts trifft. Eine falsch kopierte Zeichenkette, eine wide-Kodierung statt ascii, und die Regel löst nie aus, ein stiller Fehlalarm im Umkehrschluss. yaraQA fängt einen Teil davon.
• Die Leistung. Ein zu offener regulärer Ausdruck oder eine zu kurze Zeichenkette bremst einen ganzen Bestandsscan. Bevorzugen Sie lange, spezifische Muster.
• Nachlässige Metadaten. Füllen Sie hash, reference, date aus. Das macht eine Warnung nutzbar und eine Regel langfristig pflegbar.

Zusammenfassung

Eine gute YARA-Regel zu schreiben ist eine Methode: von der Probe ausgehen (nicht von einer kopierten Regel), unterscheidende, durch die Struktur verankerte Zeichenketten wählen (keine Bibliotheks-Zeichenketten), die Bedingung zwischen zu locker und zu streng justieren und empirisch beweisen, dass sie die Familie fängt, ohne saubere Software zu berühren. Der Rest (Kompilierung, Linting, Metadaten) ist Hygiene.

Genau diese Disziplin wenden wir in großem Maßstab im YARA-Feed von ThreatClaw an: jede Regel wird auf der echten Engine validiert, per Retro-Match gegen ihre Proben geprüft und gegen einen gutartigen Korpus getestet, um das schwierigste Versprechen eines Feeds zu halten, wenige Fehlalarme, bewiesen. Das kann eine bloße Regelsammlung nicht zeigen.