YARA pour le threat hunting et le DFIR : guide de fond

Un analyste DFIR arrive sur un poste compromis. Il n'a pas d'IOC exploitable (le hash change à chaque compilation, le nom de fichier est aléatoire), seulement un rapport d'un fournisseur qui décrit un comportement, une chaîne de caractères en mémoire, une structure de code partagée entre variantes. Chercher un hash exact ne servira à rien. Ce dont il a besoin, c'est de YARA appliqué en mode hunting : sur la mémoire vive, sur un corpus d'endpoints, avec des règles qui décrivent une famille et non un fichier.

C'est là que YARA change de registre. En scan antivirus, une règle vérifie un fichier connu. En threat hunting et en DFIR, la règle sert à répondre à une question opérationnelle : ce host est-il compromis, cette variante circule-t-elle ailleurs sur le parc, cet artefact retrouvé il y a six mois correspond-il à une menace identifiée aujourd'hui. Cet article couvre la méthode : scan mémoire, écriture orientée TTP, rétro-chasse, réduction du bruit et intégration dans un playbook de réponse à incident.

Scan mémoire versus scan disque

Le réflexe le plus courant est de scanner des fichiers sur disque. C'est utile, mais une part croissante des intrusions vit en mémoire : injection de code, chargeurs qui ne touchent jamais le disque, artefacts déchiffrés uniquement au runtime. Un scan disque seul les rate systématiquement.

YARA sait scanner un processus vivant directement :

yara -s regles.yar <pid>

Le flag -s affiche les chaînes qui ont matché, essentiel en investigation pour comprendre pourquoi une règle s'est déclenchée et vérifier qu'il ne s'agit pas d'un faux positif. Sur un dump mémoire complet (capturé par un outil de collecte forensique), la même règle s'applique au fichier image :

yara -s regles.yar memory.dmp

En pratique, l'analyste ne lance rarement YARA à la main sur chaque poste. L'intégration se fait via l'EDR ou un outil de collecte à distance type Velociraptor, qui embarque un moteur de scan YARA et permet de lancer une chasse mémoire sur des centaines d'endpoints en une seule requête, sans toucher au disque et sans déployer d'agent supplémentaire. C'est le pont entre « j'ai une règle » et « je sais en dix minutes combien de postes matchent sur mon parc entier ».

Écrire des règles hunting : viser le TTP, pas le hash

Une règle YARA taillée pour le hunting ne décrit jamais un fichier précis, elle décrit un comportement ou une technique qui survit à la recompilation, à l'obfuscation légère, au changement de nom. La structure combine plusieurs signaux :

rule Hunting_Reflective_Loader_InMemory
{
    meta:
        description = "Detects a reflective PE loader pattern combined with common process-injection API strings, independent of file hash"
        author = "hunt-team"
        ttp = "T1055 - Process Injection"
 
    strings:
        $api1 = "VirtualAllocEx" ascii
        $api2 = "WriteProcessMemory" ascii
        $api3 = "CreateRemoteThread" ascii
        $hex_stub = { 55 8B EC 83 EC ?? 53 56 57 }
        $marker = "MZ" 
 
    condition:
        uint16(0) == 0x5A4D and
        2 of ($api*) and
        $hex_stub and
        pe.number_of_sections < 4
}

Les blocs strings combinent trois natures de signaux : des chaînes ASCII qui trahissent une API sensible (injection, allocation mémoire distante), un motif hexadécimal correspondant à un stub de code générique, et un marqueur de format. Le module pe ajoute une dimension structurelle : un binaire légitime a rarement moins de quatre sections, un packer ou un loader minimal si. Le module hash complète pour épingler une famille par son empreinte de code (hash.md5(0, filesize) sur une section précise plutôt que sur le fichier entier, qui change au moindre octet ajouté).

La condition (2 of ($api*)) volontairement permissive sur les chaînes, resserrée par la structure, c'est exactement l'inverse d'une règle de scan antivirus qui vérifierait une suite d'octets exacte. Le TTP survit, le hash non.

La rétro-chasse : rejouer une règle sur un corpus déjà collecté

Une nouvelle règle n'a de valeur que si elle est aussi appliquée au passé. La rétro-chasse (retrohunt) consiste à rejouer une règle fraîchement écrite sur un corpus déjà constitué : artefacts collectés lors d'incidents précédents, images disque archivées, dumps mémoire d'investigations closes, échantillons remontés par la sandbox sur les derniers mois.

yara -r regles_nouvelle_famille.yar /data/corpus_endpoints/ > resultats_retrohunt.txt

Le flag -r parcourt récursivement l'arborescence. L'intérêt opérationnel est direct : un rapport de threat intelligence publié aujourd'hui décrit une campagne active depuis plusieurs semaines. Écrire la règle et la rejouer sur les artefacts déjà en stock permet de savoir en quelques minutes si l'organisation a déjà été touchée, sans attendre une nouvelle détection en temps réel. C'est souvent la première question que pose un RSSI face à un nouvel advisory : « est-ce qu'on l'a déjà eu ? ».

Réduire le bruit : qualifier avant de généraliser

Une règle orientée TTP, par construction, est plus permissive qu'une règle de hash exact. Le prix à payer, ce sont les faux positifs. Trois leviers de qualification, à mesurer et non à supposer :

• filesize : une règle qui cible un chargeur léger n'a aucune raison de matcher un exécutable de 200 Mo. Ajouter filesize < 500KB élimine une classe entière de faux positifs sans toucher à la logique de détection.
• pe.imphash : l'empreinte de la table d'imports est plus stable que le hash du fichier complet et beaucoup plus discriminante qu'une simple présence d'API. Comparer l'imphash observé à une liste connue resserre la règle sans la rendre fragile à la recompilation.
• private strings : marquer certaines chaînes comme private les retire de l'affichage -s tout en les gardant dans la condition. Utile pour des chaînes de contexte (bruit visuel) qu'on veut garder comme filtre logique sans polluer la sortie de l'analyste.

La mesure de précision ne se fait jamais sur un intitulé de règle mais sur un test empirique : faire tourner la règle sur un corpus bénin représentatif (postes sains, logithèque interne, outils d'administration légitimes) et compter les faux positifs, puis sur un échantillon confirmé de la famille visée pour vérifier qu'elle matche toujours. Une règle qui n'a pas traversé ce double test n'a pas sa place en production.

Intégrer YARA dans un playbook de réponse à incident

YARA seul ne fait pas un processus. L'usage structuré en IR suit trois temps :

1. Identification : une règle générique ou une alerte externe déclenche un scan large (EDR, Velociraptor) sur tout le parc pour repérer les postes qui matchent, même faiblement.
2. Scoping : sur les postes identifiés, un scan mémoire ciblé (yara -s) confirme la présence réelle et affiche les chaînes matchées pour évaluer la gravité et distinguer un vrai positif d'un artefact bénin proche.
3. Confirmation : les postes confirmés passent en investigation forensique complète (analyse de la timeline, corrélation avec les journaux, extraction de l'artefact pour analyse statique poussée), tandis que la règle affinée à partir de cette investigation repart en rétro-chasse sur le reste du corpus.

Ce cycle (identification large, scoping ciblé, confirmation forensique) est ce qui transforme une règle YARA isolée en capacité de chasse répétable, plutôt qu'en script ponctuel qu'on réécrit à chaque incident.

Un pack curé plutôt qu'un agrégat brut

Les agrégateurs publics de règles YARA (type collections communautaires assemblées automatiquement) ont un défaut connu : les règles s'accumulent, se chevauchent, vieillissent sans revalidation, et une part significative génère du bruit dès qu'on les pointe sur un parc réel. Elles restent utiles en première approche, mais elles déplacent le travail de qualification sur l'équipe qui les consomme, exactement le travail décrit plus haut (filesize, imphash, private strings, test sur corpus bénin).

Un pack construit sur la méthode inverse (familles à jour, chaque règle validée sur le moteur réel avant publication, testée contre un corpus bénin pour mesurer le taux de faux positifs) livre une chasse directement exploitable plutôt qu'un point de départ à retravailler.

C'est la logique du pack YARA ThreatClaw : des règles orientées TTP, curées et testées, prêtes à être rejouées en scan mémoire, en rétro-chasse sur votre corpus, ou intégrées à votre EDR sans passer des heures à filtrer le bruit avant de commencer à chasser.