Threat Hunting avec Sigma et Elastic: De l'Indicateur a la Regle de Detection
Comment transformer des hypotheses d'attaque en regles Sigma testees dans Elastic, avec un pipeline de validation reproductible en lab.

Le threat hunting echoue quand il reste une intuition. Un analyste cherche un hash malveillant, ne trouve rien et declare l'environnement propre, ce qui prouve seulement qu'un artefact est absent. L'equipe Basilisk mene le hunting comme une pipeline d'ingenierie: une hypothese exprimee en regle Sigma portable, compilee en requete Elastic, validee contre de la telemetrie reelle, ajustee puis promue en detection permanente. Ce texte parcourt le chemin complet de l'indicateur a la detection avec des regles, requetes et etapes de tuning concretes que vous pouvez reproduire dans un lab ce soir, et il est concu pour s'apparier a une source d'emulation, afin que vous chassiez quelque chose de reel plutot que de fixer un index vide.
De l'indicateur a la detection: la pyramide de la douleur
La Pyramid of Pain de David Bianco est le modele mental qui rend le hunting rentable. Hashes et IP sont en bas: triviaux a changer pour un attaquant, donc une chasse basee dessus expire en heures. Domaines et artefacts reseau sont un peu plus durs. En haut se trouvent les outils et les TTP, les tactiques, techniques et procedures qu'un adversaire devrait re-concevoir pour evader, couteux pour lui et durable pour vous. Un bon hunting vise le comportement, pas les indicateurs: pas 'trouve le hash X' mais 'trouve tout processus qui lance un interpreteur de scripts depuis un document Office puis fait une connexion sortante'. Sigma existe precisement pour exprimer cette logique comportementale une fois et la faire tourner sur n'importe quel backend, afin que votre travail intellectuel ne soit pas verrouille a un seul langage de requete.
Anatomie d'une regle Sigma
Une regle Sigma est un petit document YAML au squelette fixe. Le bloc logsource declare la telemetrie necessaire, par exemple product: windows et category: process_creation, qui correspond a Sysmon Event ID 1 ou Windows 4688. Le bloc detection contient une ou plusieurs selections nommees et une condition qui les combine en logique booleenne. Une regle LOLBin minimale definit selection comme Image|endswith: '\\certutil.exe' avec CommandLine|contains: '-urlcache' puis pose condition: selection. Ajoutez une liste falsepositives et un level pour que le triage sache ponderer un hit, et taguez-la avec la technique ATT&CK qu'elle couvre. La discipline qui compte: une regle exprime un comportement testable, avec des noms de champ tires d'un schema que vous expediez vraiment, pas d'une capture de blog.
Monter la stack Elastic
Il vous faut de la telemetrie avant des regles. Montez Elasticsearch et Kibana, puis enrolez les endpoints avec l'Elastic Agent gere via Fleet, en expediant les integrations System et Windows pour que creation de processus, reseau et authentification tombent dans des index normalises au Elastic Common Schema (ECS). ECS est la piece maitresse: il renomme les champs vendeur en noms stables comme process.command_line, process.parent.name et destination.ip, pour qu'une requete ecrite une fois continue de marcher quand les sources changent. Sous Windows, deployez Sysmon avec une configuration curatee (une config communautaire maintenue est le defaut raisonnable) car le journal d'audit natif est trop grossier pour le hunting comportemental. Verifiez l'ingestion en confirmant qu'un certutil de test apparait dans Discover avec un process.command_line rempli avant de faire confiance a la moindre regle.
Compiler Sigma vers un backend Elastic
Sigma est portable parce qu'un compilateur le traduit dans le dialecte de chaque backend. La toolchain moderne est sigma-cli pilotant pySigma avec un plugin par cible. Installez le plugin Elasticsearch puis executez sigma convert -t elasticsearch -p ecs_windows rules/certutil_urlcache.yml pour emettre une requete Elasticsearch, ou visez -t eql pour l'Event Query Language de correlation entre evenements. Une pipeline comme ecs_windows est ce qui remappe les noms de champ generiques de la regle sur vos champs ECS, et l'omettre est la raison la plus courante pour laquelle une regle convertie renvoie zero resultat malgre un hit reel. Pour la logique de sequence, l'EQL d'Elastic exprime 'processus A puis reseau B par le meme processus en N secondes', tandis que le plus recent ES|QL excelle pour l'agregation exploratoire pendant la chasse elle-meme.
Une chasse concrete: binaires living-off-the-land
Les attaquants evitent de deposer un malware en abusant de binaires systeme signes: certutil pour telecharger, mshta et rundll32 pour executer, regsvr32 pour la technique Squiblydoo, bitsadmin pour transferer. Commencez large en ES|QL: FROM logs-* | WHERE process.name IN ("certutil.exe","mshta.exe","regsvr32.exe") | STATS count = COUNT(*) BY process.command_line, host.name | SORT count ASC, puis lisez les lignes de commande rares, car l'usage admin normal est a haut volume et repetitif tandis que l'invocation de l'attaquant est un outlier solitaire. Pivotez sur chaque hit vers le processus parent et la connexion reseau suivante pour confirmer l'intention. Les motifs KQL plus profonds par binaire, avec les baselines benignes a soustraire, sont catalogues dans Hunting des Living-off-the-Land Binaries sous Windows avec KQL.
Hunting guide par hypothese, mappe sur ATT&CK
Ne chassez pas au hasard; chassez une hypothese liee a une technique. Formulez-la en phrase: 'Si un adversaire a fait du Kerberoasting (T1558.003), je verrais un pic de requetes TGS en chiffrement RC4 depuis un seul compte.' Puis exprimez-la en regle et testez-la contre une activite emulee, car une chasse que vous ne pouvez declencher a la demande est une chasse a laquelle vous ne pouvez vous fier. Generez le comportement en toute securite dans le lab: lancez la chaine Kerberoasting de Pentest Active Directory : Kerberoasting Pas a Pas dans un Lab GOAD, ou automatisez toute une matrice ATT&CK avec Adversary Emulation avec Caldera et MITRE ATT&CK en Lab d'Entreprise. Pour le mouvement est-ouest, la telemetrie et les detections sont dans Mouvement Lateral en Lab: SMB, WMI et WinRM avec Focus Detection.
Tuning et faux positifs
Une regle qui se declenche a chaque job de sauvegarde est du bruit qui entraine les analystes a ignorer les alertes, ce qui est pire qu'aucune regle. Ajustez avec des donnees, pas des suppositions: passez le candidat sur 30 jours d'historique, lisez chaque hit et caracterisez les clusters benins, un compte de service precis, un outil de gestion de correctifs, un agent de supervision. Encodez-les en exclusions explicites dans la selection filter de la regle plutot que d'elargir le match, pour soustraire le connu-bon sans vous aveugler a la variante malveillante. Suivez la precision comme un nombre et exigez qu'une regle franchisse un seuil avant promotion. Attention a l'echec inverse: une regle sur-ajustee avec tant d'exclusions que l'attaquant reutilise simplement un compte exclu. Le tuning est soustraction de l'explique, jamais soustraction de l'inconfortable.
De la chasse a la detection permanente
Une chasse reussie est une hypothese qui a trouve quelque chose ou prouve une lacune; dans les deux cas elle ne doit pas s'evaporer. Promouvez la regle Sigma validee dans votre depot detection-as-code, versionnez-la dans Git avec ses tags ATT&CK et ses notes de faux positifs, et deployez-la en regle de detection planifiee dans Elastic qui leve une alerte avec le contexte dont un analyste a besoin pour trier en un seul ecran. Bouclez la boucle avec la red team pour que chaque technique emulee produise soit une detection soit un angle mort documente; ce cycle de feedback est tout le propos de Purple Team en Pratique: Construire une Boucle de Feedback Red vs Blue. Quand une detection se declenche pour de vrai, l'intervenant a besoin d'un triage au niveau de l'hote, ou DFIR sous Linux: Triage Vivant avec UAC et Velociraptor prend le relais.
Pieges et checklist
Les echecs recurrents: convertir une regle sans la pipeline ECS et faire confiance au resultat zero; chasser sur une source de donnees jamais ingeree, si bien que l'absence ne veut rien dire; miser sur des hashes et IP qui expirent; ecrire une regle qu'on ne peut declencher a la demande; et deployer une regle bruyante qui erode la confiance dans toute la pipeline. La checklist avant toute chasse: (1) hypothese ecrite en phrase liee a une technique ATT&CK; (2) source de log requise confirmee presente et remplie en ECS; (3) regle Sigma exprimant un comportement, avec faux positifs listes; (4) compilee avec la bonne pipeline et la requete verifiee a la main; (5) declenchee contre une activite emulee pour prouver qu'elle tire; (6) ajustee sur des donnees historiques avec la precision mesuree; (7) promue en detection-as-code versionnee; (8) reliee au backlog de la purple team.
FAQ
Pourquoi Sigma plutot qu'ecrire des requetes Elastic directement ? Portabilite et revue. Une regle Sigma est neutre vis-a-vis du vendeur, donc la meme logique comportementale compile vers Elastic aujourd'hui et vers un autre SIEM demain, et elle se relit comme un petit document declaratif plutot qu'une requete tentaculaire. Vous continuez a lancer de l'ES|QL natif pour l'exploration interactive; Sigma sert aux detections durables et partageables qui survivent a n'importe quelle plateforme. Les deux sont complementaires, pas concurrents.
En quoi le hunting differe-t-il de l'alerting ? L'alerting execute des detections de mauvais-connu en continu; le hunting teste proactivement des hypotheses sur une activite qu'aucune regle n'attrape encore, et sa sortie est souvent une regle nouvelle. Un programme mature reinjecte les resultats de hunting dans l'alerting, si bien que la chasse manuelle d'aujourd'hui devient la detection automatisee de demain. Si une chasse ne produit jamais d'artefact durable, une regle ou une lacune documentee, c'etait du divertissement, pas de l'ingenierie.
Conclusion
Traitez le hunting comme une pipeline, pas comme un pressentiment. Visez le comportement haut dans la Pyramid of Pain, exprimez chaque hypothese en une seule regle Sigma, compilez-la vers Elastic avec la bonne pipeline ECS et prouvez qu'elle se declenche contre une activite emulee avant de croire un resultat propre. Ajustez avec des donnees reelles, mesurez la precision et promouvez les survivantes en detections versionnees rebranchees a une boucle purple team. Ainsi fait, un resultat vide est une preuve significative plutot qu'un faux reconfort, et chaque chasse laisse l'environnement avec une detection durable de plus ou un angle mort honnetement documente. Cette accumulation, et non une seule requete astucieuse, est ce qui fait vraiment monter l'adversaire dans la pyramide et hors de votre portee.


