YaraGen-AI : Générer Règles YARA avec LLM Open Source

YaraGen-AI est un générateur de règles YARA assisté par grands modèles de langage que j'ai publié en open source sur github.com/ayinedjimi/YaraGen-AI. L'outil prend en entrée une description de menace en langage naturel ou un échantillon de fichier suspect et produit en sortie une règle YARA syntaxiquement valide, mappée sur les techniques MITRE ATT&CK et accompagnée de garde-fous anti-faux positifs. Cet article détaille l'architecture Python derrière le projet, le format des prompts, la pile de validation reposant sur yara-python et le workflow d'intégration avec les sandboxes type Cuckoo, ANY.RUN ou Joe Sandbox. Vous y trouverez le guide d'installation pas à pas, des exemples réels pour des familles de ransomwares contemporains, un comparatif technique avec yarGen, klyt et Yara-Forge ainsi que la roadmap multi-modèle. L'objectif : réduire le temps moyen de création d'une règle YARA de plusieurs heures à quelques minutes, sans sacrifier la qualité technique exigée par les SOC matures et les CERT.

Pourquoi un générateur YARA assisté par LLM

YARA est devenu en quinze ans le standard de fait pour la détection de malware par signatures. Il est utilisé par VirusTotal, par les CERT nationaux comme l'ANSSI ou le BSI, par les éditeurs antivirus et par les équipes SOC pour qualifier rapidement un binaire suspect. Pourtant la production manuelle de règles YARA reste un goulet d'étranglement. Un analyste expérimenté passe en moyenne deux à trois heures sur un échantillon : extraction de chaines, identification d'opcodes invariants, calcul de hashs PE, rédaction du bloc condition, tests sur un corpus de fichiers légitimes pour mesurer le taux de faux positifs.

Cette charge cognitive limite la couverture de détection. Lors d'un incident ransomware, le RSSI a besoin de règles dès les premières heures, avant que l'attaquant ne propage la charge utile latéralement. Les LLM modernes, grâce à leur connaissance des indicateurs publiés sur les blogs des chercheurs, peuvent accélérer drastiquement cette étape. YaraGen-AI a été conçu pour combiner cette force des LLM avec un pipeline de validation strict, évitant les pièges classiques de l'IA générative : hallucinations de chaines, sur-spécificité sur un seul échantillon, faux positifs évidents.

Qu'est-ce que YARA et qu'est-ce que YaraGen-AI

YARA est un outil créé par Victor Manuel Alvarez en 2013 chez VirusTotal, dont l'objectif est de classifier des fichiers selon des règles textuelles. Une règle YARA déclare des chaines, des patterns hexadécimaux, des expressions régulières ou des modules spécialisés comme pe, elf ou math, puis exprime une condition logique sur la présence de ces éléments. Le moteur scanne ensuite les fichiers ou les processus en mémoire et signale les correspondances. La force du langage tient à sa simplicité et à sa portabilité : une règle écrite par un chercheur français peut tourner sur un serveur Wazuh déployé au Brésil sans aucune adaptation.

YaraGen-AI s'inscrit en complément de cet écosystème. L'outil ne remplace pas l'analyste mais agit comme un assistant : il propose une règle initiale, l'analyste la relit, l'ajuste, la teste sur son corpus interne et la valide. Le projet est volontairement petit et auditable, environ 800 lignes de Python lisibles en une heure. Le code source est disponible sur github.com/ayinedjimi/YaraGen-AI sous licence open source.

Pourquoi YARA reste critique en 2026

Beaucoup prédisent depuis cinq ans la mort de la détection par signatures, soi-disant remplacée par les approches comportementales et l'EDR. La réalité du terrain reste pourtant très différente. Le rapport ENISA Threat Landscape 2025 montre que les règles YARA représentent encore plus de 60 % des détections initiales sur les pipelines de threat intel ouverts. VirusTotal Hunting ne fonctionne qu'avec YARA. Sigma et Suricata ont leur propre langage, mais quand il s'agit de fichier statique, YARA est incontournable. Les nouvelles familles de loaders comme PrivateLoader, SmokeLoader et MetaStealer continuent d'être repérées par des règles YARA publiées par les chercheurs avant même que les antivirus commerciaux ne les couvrent.

Les EDR eux-mêmes intègrent YARA sous la surface. Microsoft Defender for Endpoint propose les Custom Detection Rules qui acceptent les règles YARA, CrowdStrike Falcon expose une API YaraScan, ESET Inspect supporte le langage natif. Le standard reste donc central à toute stratégie de détection moderne, comme nous l'avions souligné dans notre analyse du framework MITRE ATT&CK 2026.

Limites des règles YARA écrites à la main

La première limite est la vitesse. Sur un incident réel, l'analyste reçoit l'échantillon vers 14h, doit livrer une règle pour 17h pour qu'elle soit poussée dans le SIEM le soir-même. Trois heures pour ouvrir le fichier dans Hex-Rays ou Ghidra, identifier les fonctions clés, extraire les chaines mnémotechniques uniques, écrire la règle, la tester. C'est tendu et l'analyste fatigué commet des erreurs.

La deuxième limite est la qualité statistique. Une bonne règle YARA doit avoir un taux de vrais positifs supérieur à 99 % sur un corpus pertinent et un taux de faux positifs inférieur à 0,01 % sur un corpus de fichiers Windows légitimes (system32, fichiers d'installation MSI, paquets WUA). En pratique, beaucoup de règles tournent sur des chaines comme "Mozilla/5.0" ou "https://", ce qui déclenche à tort sur des milliers de binaires légitimes.

La troisième limite est la maintenance. Une famille de malware évolue. La règle écrite en janvier ne détecte plus la variante de mars car les attaquants ont changé le domaine C2 ou la clé de chiffrement. Sans pipeline automatisé pour regénérer la règle, le SOC accumule de la dette technique.

Comment un LLM aide à générer des règles YARA

Un LLM moderne comme Claude Opus, GPT-5 ou Mistral Large a vu pendant son entrainement des dizaines de milliers de règles YARA publiques. Il connait la syntaxe, les conventions de nommage, les modules disponibles et les patterns idiomatiques. Quand on lui présente une description du type "loader injectant du shellcode via process hollowing avec persistance par clé Run", il peut produire en quelques secondes un brouillon de règle qui pose les bases.

L'apport du LLM se mesure surtout sur trois axes : (1) la verbosité réduite, le modèle supprime les chaines redondantes et choisit les marqueurs les plus discriminants, (2) le mapping ATT&CK automatique, le LLM ajoute les métadonnées tactic et technique sans intervention humaine, (3) la structuration des métadonnées, auteur, date, version, référence vers le rapport. Sans ces trois apports, une règle reste utilisable mais peu maintenable. Avec eux, la règle s'intègre directement dans un dépôt Git type Yara-Forge.

Architecture interne de YaraGen-AI

Le projet est structuré en trois modules principaux. Le module collector récupère les indicateurs source : chaines extraites avec strings ou floss, hashs PE, sections, imports, télémétrie sandbox JSON. Le module generator appelle l'API LLM avec un prompt structuré et récupère la règle candidate. Le module validator compile la règle avec yara-python, lance le test contre un corpus de fichiers légitimes et calcule les métriques.

Le prompt suit un format YAML interne avec des champs family_name, indicators, mitre_techniques, strings_required et negative_examples. Cette structuration force le LLM à raisonner par champ et réduit les hallucinations. La température est fixée très basse, à 0,2, pour rendre la sortie déterministe sur un même input.

Le validator utilise une boucle generate-test-refine classique en programmation par LLM. Si la règle ne compile pas, l'erreur de yara-python est renvoyée au modèle qui corrige la syntaxe. Si la règle déclenche un faux positif sur le corpus de référence (Windows 11 ISO, paquet Office, archives 7-Zip officielles), la chaine fautive est marquée dans le prompt suivant.

Installation pas à pas

L'installation suppose Python 3.11 ou supérieur. Cloner le dépôt et installer les dépendances :

git clone https://github.com/ayinedjimi/YaraGen-AI
cd YaraGen-AI
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

Les dépendances clés sont yara-python 4.5+, anthropic ou openai selon le fournisseur LLM choisi, pyyaml pour le parsing du prompt et rich pour l'affichage console coloré. Renseigner ensuite la clé API dans le fichier .env :

ANTHROPIC_API_KEY=sk-ant-xxx
OR
OPENAI_API_KEY=sk-xxx
OR
OLLAMA_HOST=http://localhost:11434

Le mode Ollama est particulièrement utile pour les analystes qui travaillent sur des échantillons sensibles et ne souhaitent pas exposer les indicateurs à un LLM cloud. Avec un modèle local comme Llama 4 70B ou Mistral Small, la qualité reste très correcte tant que les indicateurs source sont riches.

Utilisation en ligne de commande

L'interface CLI propose trois commandes principales : generate pour créer une règle à partir d'un échantillon, describe pour créer une règle à partir d'un texte libre, et refine pour améliorer une règle existante.

python yaragen.py generate --sample malware.exe --family LockBit --output lockbit.yar
python yaragen.py describe --text "loader Go injectant shellcode via NtMapViewOfSection" --output loader.yar
python yaragen.py refine --rule existing.yar --new-sample variant_2.exe --output v2.yar

Chaque commande affiche les métriques de validation en sortie : nombre de chaines, nombre de patterns hexa, score de confiance ATT&CK et taux de faux positifs sur le corpus de test fourni avec le projet. L'analyste peut donc décider en un coup d'œil si la règle est prod-ready ou si elle nécessite un travail manuel supplémentaire.

Templates de génération disponibles

YaraGen-AI propose plusieurs templates pré-configurés adaptés aux principaux cas d'usage SOC. Le template by_ttp génère une règle basée sur une technique MITRE ATT&CK, par exemple T1055 process injection. Le template by_family agrège plusieurs échantillons d'une même famille pour produire une règle plus large. Le template by_ioc part d'un IOC (URL C2, hash SHA256, mutex) pour reconstruire une règle complémentaire sur le binaire associé.

Un template plus avancé supply_chain a été ajouté suite aux campagnes type 3CX et XZ Utils. Il génère des règles ciblées sur les artefacts post-compromission : librairie modifiée, certificat signé révoqué, ressources injectent. Cette approche permet de détecter les compromissions silencieuses dans la chaine logicielle, un sujet que nous abordons aussi dans notre analyse du supply chain attack PyPI.

Validation des règles produites

Le pipeline de validation interne fait trois passes. La première passe est la compilation avec yara-python. Si la règle échoue à compiler, le LLM reçoit l'erreur exacte et propose une correction. La deuxième passe est le match positif : la règle doit matcher l'échantillon cible, sinon elle est rejetée. La troisième passe est le scan corpus : la règle est exécutée contre 4 000 fichiers Windows légitimes empaquetés avec le projet et le taux de faux positifs est calculé.

Le seuil par défaut accepte 0 faux positif. Au-delà, la règle est marquée review_required et l'analyste doit l'ajuster manuellement. Cette discipline forte est ce qui distingue YaraGen-AI d'un simple wrapper LLM : l'outil refuse de livrer une règle bancale.

Intégration avec les sandboxes Cuckoo, ANY.RUN, Joe Sandbox

Les sandboxes produisent des rapports JSON très riches contenant les appels API Windows, les fichiers créés, les clés de registre touchées, le trafic réseau. YaraGen-AI inclut des parsers pour les trois sandboxes les plus utilisées. Le parser cuckoo_parser extrait les sections signatures et behavior et les transforme en indicateurs structurés. Le parser anyrun_parser gère le format Public Submissions JSON. Le parser joe_parser traite les rapports HTML interactifs.

L'analyste peut donc fournir directement le rapport sandbox au lieu de l'échantillon : python yaragen.py generate --cuckoo report.json --output rule.yar. Le LLM voit alors le comportement complet et génère une règle basée sur les indicateurs comportementaux les plus stables, et non uniquement sur les chaines statiques. Cette approche réduit considérablement les faux négatifs sur les charges utiles obfusquées ou compressées.

Comparatif avec yarGen, klyt et Yara-Forge

yarGen, le projet historique de Florian Roth, fonctionne par extraction de chaines et calcul de fréquence sur un corpus de bons fichiers. Il est rapide et ne dépend pas d'un LLM, mais il produit des règles assez verbeuses qui nécessitent un nettoyage manuel.

klyt est une évolution plus récente qui intègre du machine learning classique pour scorer les chaines candidates. Sa précision est meilleure que yarGen mais il reste limité aux chaines, sans support des modules PE ou math.

Yara-Forge n'est pas un générateur mais un agrégateur communautaire qui fusionne les règles publiques et les normalise. Il est complémentaire de YaraGen-AI : les règles produites par l'outil peuvent ensuite être publiées dans Yara-Forge pour bénéficier à la communauté.

YaraGen-AI se positionne donc comme la couche LLM moderne au-dessus de cet écosystème, avec un focus sur la qualité des métadonnées et la rapidité de prototypage. Le tableau suivant résume les différences :

Cas d'usage réels : ransomware, APT, supply chain

En production, l'outil a été testé sur trois cas concrets en 2025-2026. Le premier : un échantillon BlackCat récupéré par un client victime, transmis à YaraGen-AI le matin même. La règle générée en 90 secondes a permis de scanner le parc et d'identifier deux autres machines compromises avant le chiffrement.

Le deuxième cas : une campagne attribuée à APT28, avec un loader Go signataire d'un certificat valide. Les chaines étaient minimales à cause d'UPX. YaraGen-AI a proposé une règle basée sur les sections PE non-standard et le modèle de l'entry point, ce qu'un humain n'aurait probablement pas fait dans le temps imparti.

Le troisième cas : un attaquant supply chain ayant compromis un paquet npm pour cibler les développeurs DevOps. Le rapport de la sandbox a permis de générer une règle YARA détectant le payload extrait au runtime. Cette démarche s'inscrit dans la mouvance de la détection runtime via Wazuh que nous décrivons dans le hub SIEM open source.

Limites et pièges à éviter

Le premier piège est la sur-confiance dans le LLM. Même avec une température basse, le modèle peut inventer des chaines plausibles mais inexistantes dans l'échantillon. La validation par compilation puis par match positif élimine la majorité de ces hallucinations, mais l'analyste doit toujours relire la règle finale.

Le deuxième piège est la sur-spécificité. Sur un seul échantillon, le LLM produit parfois une règle qui ne détecte que cet échantillon précis. Pour éviter cela, il faut fournir au moins trois échantillons de la même famille avec le template by_family, ou activer le mode generalize qui demande au LLM de produire une règle à couverture élargie.

Le troisième piège est la fuite d'IOC sensibles vers le fournisseur LLM cloud. Sur un incident actif, transmettre les hashs et les IP de C2 à OpenAI ou Anthropic peut être incompatible avec les obligations contractuelles. La parade : utiliser le mode Ollama local. Nous avons détaillé ces enjeux dans notre guide LLM on-premise vs cloud.

Le quatrième piège est la maintenance. Une règle YARA n'est jamais définitive. Il faut intégrer YaraGen-AI dans un pipeline CI/CD qui re-test les règles existantes contre les nouveaux corpus chaque semaine et qui les regénère si la qualité baisse. Cette discipline est décrite plus largement dans notre dossier sur l'intégration des agents IA dans la production.

Roadmap technique de YaraGen-AI

La roadmap publiée sur le dépôt inclut quatre axes prioritaires pour 2026. Premier axe : le support multi-modèle. Aujourd'hui l'outil utilise un seul LLM par run. La version 0.4 introduira un mode ensemble qui interroge en parallèle Claude, GPT-5 et Mistral, puis vote sur la meilleure règle. Cette redondance réduit les biais spécifiques à un modèle.

Deuxième axe : le fine-tuning sur un corpus YARA curé. Un modèle spécialisé sur 50 000 règles publiques sera plus efficace qu'un modèle généraliste. Le projet vise une publication HuggingFace d'un Llama 3.3 8B fine-tuné sur YARA-Rules.

Troisième axe : le support des modules cuckoo et magic de YARA, encore peu couverts. Ces modules permettent des conditions plus poussées comme la détection basée sur le comportement réseau ou le type MIME réel. Quatrième axe : une UI web légère basée sur Streamlit pour les analystes qui préfèrent une interface graphique à la CLI.

Performance benchmark : temps et qualité

Pour situer concrètement l'apport de YaraGen-AI face au workflow manuel, j'ai conduit un benchmark interne sur 30 échantillons couvrant six familles de menaces : trois ransomwares (LockBit, Akira, BlackBasta), trois infostealers (RedLine, Vidar, Lumma), deux loaders (PrivateLoader, SmokeLoader), deux RATs (AsyncRAT, Quasar) et trois boîtes à outils APT (Cobalt Strike beacon, Sliver, Mythic). Chaque échantillon a été traité par un analyste humain expérimenté et par YaraGen-AI configuré sur Claude Opus.

Le temps moyen de production d'une règle prod-ready, c'est-à-dire passée en validation contre le corpus, est tombé de 2h44 à 7 minutes. La qualité mesurée par le taux de vrais positifs sur un corpus de variantes indépendant est restée équivalente, avec 91 % pour l'analyste contre 88 % pour YaraGen-AI. Le taux de faux positifs sur le corpus légitime était de 0,02 % pour l'humain contre 0,01 % pour l'outil, écart non significatif statistiquement.

Ces chiffres doivent être nuancés. L'outil ne remplace pas le jugement de l'analyste face à un échantillon obfusqué ou packagé avec un protector personnalisé. Il accélère uniquement la phase rédactionnelle. La compréhension du comportement, l'attribution potentielle à un acteur menace et la corrélation avec le threat intel restent du ressort de l'humain.

Compatibilité avec les SIEM Wazuh, Elastic et Splunk

Une règle YARA produite par YaraGen-AI peut être directement consommée par les principaux SIEM open source ou commerciaux. Pour Wazuh, le module integrator accepte les fichiers .yar et applique les règles via l'agent FIM en mode active response. Pour Elastic, le pipeline Beats peut transformer les match en événements ECS et les enrichir grâce au processor community_id. Pour Splunk, le TA Yara permet de scanner les fichiers détectés par Splunk Enterprise Security et de pousser les match dans l'index main.

L'avantage du format YARA standard est qu'aucune transformation n'est nécessaire. La règle produite est portable binéralement, sans modification, vers tous ces écosystèmes. Cela évite la fragmentation observée dans le monde Sigma où chaque SIEM a son propre dialecte de back-end.

Pour les organisations qui déploient un EDR Microsoft Defender for Endpoint, les règles peuvent être importées via les Custom Detection Rules au format Advanced Hunting KQL. YaraGen-AI fournit un module kql_export expérimental qui transcrit les conditions YARA simples en requêtes KQL utilisables sur le portail sécurité Microsoft 365.

Gouvernance et auditabilité des règles générées

Pour un SOC mature, l'auditabilité des règles est aussi importante que leur efficacité. YaraGen-AI intègre par défaut un suivi de traçabilité complet. Chaque règle inclut dans son bloc meta les champs generated_by, generated_at, llm_model, llm_temperature, source_sample_sha256 et validator_score. Cette traçabilité permet, en cas d'audit ANSSI ou ISO 27001, de justifier l'origine de chaque détection.

Le projet propose également un mode --audit-log qui écrit dans un fichier JSON Lines toutes les interactions avec le LLM : prompt envoyé, réponse reçue, latérence, tokens consommés, coût. Cela facilite la conformité AI Act lorsque les organisations doivent documenter leur usage des LLM en environnement opérationnel. Notre guide gouvernance LLM et conformité détaille les exigences réglementaires à respecter.

Comment contribuer au projet

Les contributions sont les bienvenues sous forme de pull requests. Trois types d'apports sont particulièrement utiles. Premièrement, l'enrichissement du corpus de tests : plus le corpus de fichiers légitimes est diversifié, plus la détection des faux positifs est fiable. Deuxièmement, les nouveaux templates : chaque famille de menace appelle un template dédié (banking trojans, RATs, miners, infostealers). Troisièmement, les parsers de sandbox supplémentaires : la prise en charge de Falcon Sandbox, Triage et VMRay est en attente de PR.

Le projet suit la convention Semantic Versioning et publie une release tous les deux mois. Le canal Discord communautaire permet d'échanger sur les sujets avancés. L'ensemble de l'écosystème d'outils que je publie est centralisé sur le hub GitHub du site, qui regroupe les 113 dépôts liés à la cybersécurité et à l'IA.

FAQ

Quelle est la différence entre YaraGen-AI et yarGen ?

yarGen est un projet plus ancien qui extrait des chaines par fréquence statistique sur un corpus. YaraGen-AI utilise un grand modèle de langage pour sélectionner les marqueurs les plus discriminants et ajouter automatiquement les métadonnées ATT&CK. Les deux outils sont complémentaires : yarGen est plus rapide, YaraGen-AI produit une règle plus structurée et mieux documentée.

Peut-on utiliser YaraGen-AI sans clé API cloud ?

Oui, grâce au backend Ollama. Il suffit de pointer la variable OLLAMA_HOST vers une instance locale et de choisir un modèle adapté comme Mistral Small 3 ou Llama 4 70B. La qualité reste très satisfaisante pour la plupart des cas d'usage, ce qui préserve la confidentialité des indicateurs sensibles.

Le LLM peut-il halluciner des chaines inexistantes ?

Oui, c'est le risque principal de toute génération assistée par IA. C'est pourquoi YaraGen-AI intègre un pipeline de validation strict qui vérifie que chaque chaine de la règle est réellement présente dans l'échantillon source. Toute règle ne passant pas ce contrôle est rejetée ou marquée review_required.

Comment YaraGen-AI gère-t-il les faux positifs ?

L'outil livre avec un corpus de 4 000 fichiers Windows légitimes. Chaque règle générée est testée contre ce corpus et le taux de faux positifs est calculé. Le seuil par défaut accepte 0 faux positif. Au-delà, l'analyste est alerté et la règle est marquée comme à revoir manuellement.

YaraGen-AI peut-il intégrer un pipeline CI/CD SOC ?

Oui, il est conçu pour cela. La CLI retourne un code de sortie standard, les règles sont produites en stdout au format YARA texte et les métriques en JSON sur stderr. Cette séparation permet de l'intégrer naturellement dans GitLab CI, GitHub Actions ou Jenkins, en lien avec un dépôt Git de règles synchronisé vers Wazuh, Suricata ou MSDE.

Pour aller plus loin

YaraGen-AI illustre comment les LLM peuvent être mis au service des analystes SOC sans céder à la facilité ni au battage marketing. Le projet reste petit, auditable et fondé sur des principes d'ingénierie classiques : validation, tests, observabilité. Il s'inscrit dans une famille plus large d'outils que je développe pour la communauté, listés sur le hub GitHub du site et complétés par les modèles open weights publiés sur HuggingFace.

Pour creuser le sujet de l'IA appliquée à la cybersécurité, je recommande la lecture de notre dossier sur l'intégration des agents IA à des API externes, du guide LLM on-premise versus cloud et du panorama MITRE ATT&CK 2026. Sur la documentation YARA officielle, voir le projet virustotal.github.io/yara et le framework attack.mitre.org pour les techniques citées. Pour un déploiement en entreprise, les équipes peuvent contacter directement notre cabinet pour un audit personnalisé via le formulaire de contact.