YARA Rules

Qu'est-ce qu'une règle YARA ?

YARA est un langage de pattern matching conçu pour identifier et classifier des logiciels malveillants à partir de leurs caractéristiques observables : chaînes de caractères, séquences d'octets, structures de fichier ou métadonnées. Créé par Victor Alvarez (VirusTotal), il est souvent décrit comme « le couteau suisse des chercheurs en malware ». Une règle YARA décrit une famille de menaces sous forme de conditions booléennes appliquées à un fichier sur disque, à un flux réseau capturé ou à l'espace mémoire d'un processus vivant.

Contrairement à une signature antivirale classique fondée sur un condensat (MD5, SHA-256) qui ne détecte qu'un échantillon unique, une règle YARA vise le trait générique d'une famille : elle continue de fonctionner après recompilation, changement de clé de chiffrement ou modification cosmétique du binaire.

Anatomie technique d'une règle

Une règle se compose de trois blocs :

• meta : métadonnées non évaluées (auteur, date, référence CTI, identifiant MITRE ATT&CK, niveau de confiance). Essentiel pour la traçabilité en réponse à incident.
• strings : les motifs recherchés. Trois formes coexistent — chaînes textuelles avec modificateurs (ascii, wide, nocase, fullword, xor), chaînes hexadécimales acceptant des jokers ({ 4D 5A ?? ?? E8 [4-8] C3 }), et expressions régulières.
• condition : l'expression logique qui déclenche la détection. Elle combine les motifs (all of them, any of ($s*), 2 of ($api*)), des compteurs (#a > 5), des positions ($mz at 0) et des primitives d'inspection binaire (uint16(0) == 0x5A4D, filesize < 2MB).

rule Suspect_Loader_XorStub
{
    meta:
        author      = "SOC"
        description = "Loader avec stub de dechiffrement XOR"
        reference   = "T1027 - Obfuscated Files"
    strings:
        $mz   = { 4D 5A }
        $api1 = "VirtualAlloc"      ascii
        $api2 = "CreateRemoteThread" ascii
        $stub = { 8A 04 ?? 34 ?? 88 04 ?? 4? }
    condition:
        $mz at 0 and filesize < 1MB and $stub and 2 of ($api*)
}

Des modules étendent le langage : pe (sections, imports, certificat de signature, rich header, imphash), elf, dotnet, math (calcul d'entropie pour repérer un packer), hash ou magic. La réécriture YARA-X, en Rust, améliore nettement les performances et la sûreté mémoire tout en restant compatible avec la syntaxe existante.

Cas d'usage concrets

• Analyse forensique : balayage récursif d'une image disque montée (yara -r regles.yar /mnt/evidence) ou d'un dump mémoire via yarascan sous Volatility, pour retrouver un beacon Cobalt Strike injecté en mémoire alors qu'aucun artefact ne subsiste sur disque.
• Threat hunting : diffusion d'une règle sur un parc via Velociraptor, THOR ou Loki afin de mesurer l'ampleur d'une compromission après identification d'un premier hôte.
• Chasse rétrospective : Retrohunt et Livehunt sur VirusTotal permettent de tester une règle contre l'historique des soumissions ou d'être alerté sur tout nouvel échantillon correspondant.
• Détection de webshells : recherche de fonctions PHP dangereuses (eval, assert, base64_decode) combinées dans un fichier de faible taille sous une racine web.
• Pipelines d'analyse : intégration dans une sandbox, un CI/CD de sécurité applicative ou une passerelle de messagerie pour trier les pièces jointes.

Positionnement par rapport aux autres formats

YARA occupe la couche fichier et mémoire. Il se complète naturellement avec Sigma, qui exprime des détections sur les journaux (SIEM), et avec Snort/Suricata, orientés flux réseau. Dans la Pyramid of Pain, une bonne règle YARA se situe au niveau « outils » : elle coûte bien plus cher à contourner à un attaquant qu'une simple adresse IP ou un condensat. Les règles sont souvent diffusées par les CERT et les éditeurs de CTI en accompagnement d'indicateurs STIX/TAXII et de références MITRE ATT&CK.

Bonnes pratiques de rédaction

• Filtrer avant de chercher : placer uint16(0) == 0x5A4D ou filesize < N en tête de condition évite d'appliquer des motifs coûteux à tout le système de fichiers.
• Bannir les chaînes trop génériques : "kernel32.dll" ou "http://" seuls génèrent un volume ingérable de faux positifs. Privilégier des artefacts propres à l'auteur du code (mutex, chemin PDB, clé de chiffrement, message de rançon).
• Valider contre un corpus sain (goodware) : exécuter systématiquement la règle sur un jeu de binaires légitimes Windows et Linux avant mise en production.
• Documenter et versionner : stocker les règles dans Git, renseigner le bloc meta, adopter une convention de nommage stable (APT_Famille_Variante).
• Éviter le sur-ajustement à un unique échantillon : une règle qui ne détecte qu'un hash n'apporte rien de plus qu'un IOC.

Limites à connaître : YARA reste une analyse statique. Un binaire chiffré, empaqueté ou entièrement chargé en mémoire par un loader tiers échappera aux motifs disque — d'où l'intérêt d'un scan mémoire post-déballage et d'une corrélation avec la télémétrie comportementale d'un EDR.