Écrire une règle YARA pour un malware : de l'échantillon à la signature fiable (sans faux positif)

Vous récupérez un échantillon : une pièce jointe piégée d'une mission de réponse à incident, un binaire remonté par votre sandbox, un fichier signalé par un flux de threat intelligence. La question n'est pas « qu'est-ce que c'est ? » (l'analyse le dira) mais « combien d'autres exemplaires de cette famille dorment sur mon parc ? ». YARA est l'outil de référence pour répondre : un langage de règles qui décrit des motifs (chaînes, octets, structure) et les recherche à grande échelle sur des fichiers, de la mémoire, un dépôt.

L'écueil est le même que partout en détection : une règle trop lâche se déclenche sur du logiciel parfaitement sain (faux positif, on noie l'analyste), une règle trop stricte ne reconnaît que l'échantillon exact et rate le reste de la famille (faux négatif, on se croit couvert). Cet article montre comment écrire une règle qui attrape la famille sans crier au loup, et surtout comment le prouver.

Pourquoi écrire sa propre règle

• Les menaces fraîches et ciblées. Un malware vu chez vous en mission DFIR, une variante régionale, un implant sur mesure : aucune collection publique ne le couvrira à temps, si tant est qu'elle le couvre un jour.
• Vos propres échantillons. Ce que votre sandbox et vos incidents produisent est une matière exclusive. La règle qui en sort détecte ce que personne d'autre ne voit.
• La précision. Une règle générique tierce peut « matcher » une famille au prix de faux positifs que vous ne tolérez pas. Écrire la vôtre, c'est régler ce curseur pour votre environnement.

L'anatomie d'une règle YARA

Une règle a trois blocs : meta (les métadonnées), strings (les motifs recherchés) et condition (la logique qui les combine).

rule ACME_Stealer_Downloader {
    meta:
        description = "ACME Stealer - étage de téléchargement"
        author      = "votre-equipe"
        reference   = "rapport interne DFIR 2026-05"
        date        = "2026-05-28"
        hash        = "e3b0c44298fc1c149afbf4c8996fb924..."
 
    strings:
        $mz   = { 4D 5A }                       // en-tête PE "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)
}

(L'exemple est illustratif : la méthode compte plus que la famille choisie.) Le bloc meta documente et rend la règle exploitable (référence, hash, date). Le bloc strings liste les motifs, texte (ascii, wide), octets ({ 4D 5A }), ou expressions régulières. Le bloc condition est le cœur : c'est lui qui décide, à partir des motifs présents, si le fichier correspond.

Partir de l'échantillon, pas d'une règle recopiée

Le réflexe est de chercher une règle existante pour la famille et de la reprendre. Deux raisons de s'en méfier.

D'abord la rigueur juridique : une règle publiée sous licence copyleft (GPL) ou sans licence ne peut pas entrer telle quelle dans un jeu de règles fermé ou revendu, elle en contaminerait les droits. En revanche, le fait que porte l'échantillon, telle chaîne interne, tel chemin PDB, tel marqueur de C2, n'appartient à personne. La signature que vous en tirez est votre œuvre, comme une signature d'antivirus n'hérite pas des droits du malware qu'elle vise.

Ensuite la qualité : la bonne règle décrit ce qui caractérise la famille, pas ce qui se trouve dans un fichier au hasard. On extrait de l'échantillon ses chaînes et ses séquences d'octets, puis on garde celles qui sont distinctives. Des outils comme yarGen automatisent le premier jet : ils extraient les chaînes et les comparent à une base de fichiers légitimes (« goodware ») pour écarter celles qui apparaissent partout. Mais leur sortie est un brouillon, la relecture humaine reste indispensable.

Choisir de bonnes chaînes : le nerf de la guerre

C'est là que se gagne ou se perd la fiabilité.

• Fuyez les chaînes génériques. Microsoft Corporation, GetProcAddress, une URL de bibliothèque connue : elles sont dans des milliers de fichiers sains. Les inclure, c'est signer des faux positifs.
• Préférez les marqueurs uniques. Une chaîne interne propre au développeur du malware (acme_stealer_v), un chemin PDB de compilation, un mutex, un motif de C2, un message d'erreur inhabituel. Ce sont les empreintes que la famille traîne d'échantillon en échantillon.
• Ancrez avec la structure. Pour un exécutable Windows, imphash (le hash de la table d'imports) est un ancrage fort : deux binaires compilés du même code source partagent souvent le même. Combiné à deux ou trois chaînes distinctives, il rend la règle à la fois précise et résistante aux variantes.

La condition : ni trop lâche, ni trop stricte

La condition transforme des motifs en verdict. Quelques principes :

• Bornez. filesize < 500KB évite de scanner inutilement de gros fichiers et coupe des faux positifs.
• Vérifiez le type. uint16(0) == 0x5A4D confirme un PE avant d'aller plus loin.
• Exigez un quorum. 2 of ($s*) (deux motifs sur plusieurs) attrape les variantes qui n'ont pas toutes les chaînes, tout en restant discriminant. Exiger les cinq, c'est se limiter à l'échantillon exact.

Le bon réglage se trouve entre « un seul motif » (trop de bruit) et « tous les motifs » (surapprentissage sur un fichier). Deux à trois marqueurs distinctifs, ancrés par la structure, est souvent le point d'équilibre.

Valider ne suffit pas : il faut prouver

YARA compile la règle et signale les erreurs de syntaxe :

yara mes_regles.yar echantillon.bin

Et un linter comme yaraQA repère les défauts classiques, une règle qui ne peut jamais matcher, une expression régulière ruineuse en performance. Nécessaire, mais insuffisant : « ça compile » ne dit rien de « ça détecte bien ».

La vraie preuve est empirique, et tient en deux tests :

1. La règle tire-t-elle sur toute la famille ? Passez-la sur l'ensemble de vos échantillons de la famille (rétro-match). Si elle n'attrape que le fichier d'origine, elle est surajustée, élargissez les chaînes ou baissez le quorum.
2. Reste-t-elle muette sur du logiciel sain ? Passez-la sur un corpus bénin (goodware), vos binaires système, vos applications légitimes. Le moindre déclenchement est un faux positif à corriger avant de déployer. C'est le test que la plupart des règles publiques n'ont jamais subi.

Une règle qui a passé ces deux épreuves vaut infiniment plus qu'une règle « valide ». C'est la différence entre « ça compile » et « ça marche, prouvé, sans bruit ».

Les pièges qui coûtent cher

• La chaîne goodware oubliée. La première source de faux positifs. Le test sur corpus bénin n'est pas optionnel.
• La règle qui ne matche rien. Une chaîne mal recopiée, un encodage wide au lieu d'ascii, et la règle ne se déclenche jamais, un faux négatif silencieux. yaraQA en attrape une partie.
• La performance. Une expression régulière trop ouverte ou une chaîne trop courte ralentit tout un scan de parc. Préférez des motifs longs et spécifiques.
• Les métadonnées bâclées. Renseignez hash, reference, date. C'est ce qui rend une alerte exploitable et une règle maintenable dans le temps.

En résumé

Écrire une bonne règle YARA, c'est une méthode : partir de l'échantillon (pas d'une règle recopiée), choisir des chaînes distinctives ancrées par la structure (pas des chaînes de bibliothèque), régler la condition entre le trop-lâche et le trop-strict, et prouver empiriquement qu'elle attrape la famille sans toucher au logiciel sain. Le reste (compilation, lint, métadonnées) est de l'hygiène.

C'est exactement la discipline que nous appliquons à l'échelle dans le feed YARA de ThreatClaw : chaque règle est validée sur le moteur réel, rétro-matchée sur ses échantillons, et testée contre un corpus bénin pour tenir la promesse la plus difficile d'un feed, peu de faux positifs, prouvés. C'est ce qu'un simple dépôt de règles ne peut pas montrer.