Threat Hunting : Méthodologie, Outils et Pratique pour Analystes SOC

1. Introduction : du SOC réactif au SOC proactif

Le modèle traditionnel du SOC repose sur une posture fondamentalement réactive : les analystes attendent que le SIEM génère des alertes, puis trient, qualifient et répondent. Ce modèle a démontré ses limites face à des adversaires qui opèrent sous le radar des règles de détection, exploitant des techniques inédites, des outils légitimes et des fenêtres d'exposition entre la compromission initiale et la première alerte -- un délai moyen (dwell time) qui reste supérieur à 10 jours selon le rapport M-Trends 2025 de Mandiant.

Le threat hunting (chasse aux menaces) est la discipline qui comble ce fossé. Contrairement à la détection classique qui dépend de signatures et de règles prédéfinies, le threat hunting part d'une hypothèse formulée par un analyste humain, exploite les données télémétriques disponibles pour valider ou invalider cette hypothèse, et découvre des menaces qui échappent aux mécanismes automatisés. C'est une activité intellectuellement exigeante qui combine la connaissance des techniques adverses, la maîtrise des outils d'analyse de données et l'intuition développée par l'expérience opérationnelle.

Les résultats parlent d'eux-mêmes : selon le SANS 2025 Threat Hunting Survey, les organisations qui pratiquent le threat hunting de manière structurée réduisent leur dwell time de 67% et découvrent en moyenne 3 à 5 compromissions non détectées par leurs outils automatisés lors de la première année de mise en oeuvre. Plus qu'une amélioration de la détection, le threat hunting génère un retour d'expérience qui renforce l'ensemble du dispositif de sécurité : nouvelles règles de détection, meilleure compréhension des surfaces d'attaque, identification des lacunes de visibilité.

Ce guide s'adresse aux analystes SOC de niveau 2/3, aux responsables de programmes de threat hunting et aux RSSI souhaitant structurer cette capacité. Nous couvrons le modèle PEAK (Prepare, Execute, Act, Knowledge), les techniques d'analyse de données, les outils essentiels, des exemples concrets de hunts (C2 beaconing, lateral movement, data staging), les métriques de programme et les étapes pour construire une équipe de hunters efficace.

Point clé : Le threat hunting n'est pas un produit que l'on achète -- c'est une capacité que l'on construit. Aucun outil, aussi sophistiqué soit-il, ne remplace l'analyste qui formule l'hypothèse, interprète les données et connecte les indices. L'outil accélère ; l'humain décide.

2. Fondamentaux : proactif vs réactif

2.1 Le spectre de la détection

Pour comprendre la place du threat hunting, il faut le situer sur le spectre de la détection qui va du purement réactif au pleinement proactif :

Approche	Déclencheur	Automatisation	Exemple
Détection par signature	Pattern connu	100% automatique	Règle Snort, antivirus
Détection par règles SIEM	Corrélation d'événements	95% automatique	5 échecs auth en 2 min
Détection par anomalie (ML)	Déviation du baseline	90% automatique	UEBA, traffic anomaly
Threat hunting guidé	IOC / renseignement	50% manuel	Recherche d'un hash IOC
Threat hunting proactif	Hypothèse analyste	80% manuel	"Un adversaire utilise le DNS tunneling pour exfiltrer"

Le threat hunting guidé par les IOC (aussi appelé "IOC sweeping") est le niveau d'entrée : on recherche des indicateurs spécifiques (hashes, IPs, domaines) issus du renseignement sur les menaces. C'est utile mais limité, car les IOC ont une durée de vie courte -- un attaquant change d'infrastructure en quelques heures.

Le threat hunting proactif basé sur les hypothèses est la forme la plus mature. L'analyste formule une hypothèse sur le comportement d'un adversaire (basée sur les TTPs MITRE ATT&CK, le renseignement sectoriel ou l'intuition opérationnelle), puis conçoit une requête ou une analyse pour tester cette hypothèse contre les données télémétriques de l'organisation. Cette approche cible les comportements plutôt que les indicateurs, ce qui la rend résistante au changement d'infrastructure de l'adversaire.

2.2 Prérequis pour le threat hunting

Le threat hunting ne peut fonctionner sans une base solide. Les prérequis sont :

• Visibilité (télémétrie) : vous ne pouvez chasser que ce que vous pouvez voir. Les données essentielles incluent : logs d'authentification, événements de processus (Sysmon), logs DNS, flux réseau (NetFlow/Zeek), logs proxy/firewall, événements FIM et logs cloud. Un déploiement Wazuh avec agents sur les endpoints fournit une base solide.
• Rétention : le dwell time moyen étant de 10+ jours, il faut au minimum 30 à 90 jours de rétention sur les données détaillées. Les hunts sur les APT peuvent nécessiter des recherches sur 6 à 12 mois.
• Capacité d'interrogation : un SIEM ou un data lake (Elasticsearch, Splunk, Azure Data Explorer) avec des performances de requête suffisantes pour des recherches ad-hoc sur de gros volumes.
• Connaissance des menaces : compréhension des TTPs adverses, du framework MITRE ATT&CK, des rapports de threat intelligence sectoriels et des techniques offensives documentées.
• Compétences analytiques : capacité à formuler des hypothèses, à construire des requêtes complexes, à interpréter des données statistiques et à identifier les anomalies significatives dans le bruit.

3. Le modèle PEAK : structurer la chasse

3.1 Présentation du modèle PEAK

Le modèle PEAK (Prepare, Execute, Act, Knowledge), développé par les équipes SQRRL (aujourd'hui intégrées à Amazon Security), est le framework de référence pour structurer les opérations de threat hunting. Il fournit un processus itératif qui garantit la rigueur méthodologique et la capitalisation des connaissances.

3.2 Phase Prepare : formuler l'hypothèse

La phase Prepare est la plus critique. Une hypothèse mal formulée conduit à un hunt stérile. Une bonne hypothèse de chasse possède trois caractéristiques : elle est testable (on peut la valider ou l'invalider avec les données disponibles), spécifique (elle cible un comportement ou une technique précis) et pertinente (elle est motivée par le renseignement sur les menaces ou l'évaluation des risques de l'organisation).

Exemples d'hypothèses bien formulées :

• "Un adversaire utilise le protocole DNS pour exfiltrer des données en encodant le payload dans les sous-domaines de requêtes vers un domaine contrôlé." -- Technique : DNS Tunneling (T1071.004).
• "Un implant C2 communique avec son infrastructure via des requêtes HTTPS périodiques avec un intervalle régulier (beaconing), détectable par l'analyse de fréquence des connexions sortantes." -- Technique : Application Layer Protocol (T1071.001).
• "Un attaquant ayant compromis un poste utilisateur utilise des outils natifs Windows (PsExec, WMI, WinRM) pour se déplacer latéralement vers d'autres systèmes du réseau." -- Technique : Lateral Movement via Living off the Land (T1021).
• "Des credentials volés par un infostealer sont utilisés pour accéder à nos applications cloud depuis des géolocalisations inhabituelles." -- Technique : Valid Accounts (T1078), lien avec les infostealers.

Pour chaque hypothèse, documentez : les sources de données nécessaires (logs DNS, NetFlow, événements Sysmon, etc.), les requêtes ou analyses prévues, le scope (quels segments du réseau, quelle période temporelle), et les critères de succès/échec (quand considère-t-on que l'hypothèse est validée ou invalidée).

3.3 Phase Execute : mener la chasse

La phase Execute est le coeur opérationnel du hunt. L'analyste exécute les requêtes planifiées, examine les résultats, affine les recherches et investigue les anomalies. Cette phase est itérative : chaque résultat peut mener à une nouvelle requête plus ciblée, dans un processus de "pivoting" analytique similaire au pivoting technique en pentest.

La durée d'un hunt varie de quelques heures (IOC sweep simple) à plusieurs jours (investigation comportementale complexe). Il est recommandé de timeboxer les hunts : si aucun résultat significatif n'émerge après le temps alloué, documentez les résultats négatifs (qui ont aussi de la valeur) et passez à l'hypothèse suivante.

3.4 Phase Act : transformer les découvertes en action

Lorsqu'un hunt identifie une menace réelle ou potentielle, la phase Act déclenche les actions nécessaires :

• Réponse immédiate : si une compromission active est détectée, déclencher le processus d'incident response (containment, eradication, recovery). La chaîne de preuve numérique doit être préservée.
• Nouvelles règles de détection : transformer le pattern identifié en règle SIEM/XDR automatisée (Sigma, Wazuh, Splunk SPL, KQL). Le hunt ponctuel devient une détection permanente.
• Amélioration de la visibilité : si le hunt a révélé des lacunes de télémétrie (logs manquants, sources non collectées), initier les actions pour combler ces lacunes.
• Mise à jour du modèle de menace : intégrer les découvertes dans l'évaluation des risques de l'organisation.

3.5 Phase Knowledge : capitaliser et partager

La phase Knowledge est souvent négligée mais elle est fondamentale pour la maturité du programme. Chaque hunt, qu'il ait trouvé quelque chose ou non, produit de la connaissance qui doit être documentée et partagée :

• Hunt report : hypothèse, méthodologie, requêtes utilisées, résultats, conclusions et recommandations. Format standardisé pour faciliter la réutilisation.
• Hunt playbook : procédure reproductible qui peut être exécutée par un autre analyste. Inclut les requêtes, les critères d'analyse et les seuils de décision.
• Analytics : requêtes ou détections réutilisables produites par le hunt (au format Sigma pour la portabilité).
• Formation : partager les enseignements avec l'équipe SOC pour élever le niveau collectif.

4. Techniques d'analyse pour le threat hunting

4.1 Stack Counting (Least Frequency Analysis)

Le stack counting est la technique de base du threat hunter. Le principe : compter les occurrences de chaque valeur d'un champ donné et examiner les valeurs les moins fréquentes (la "longue queue" de la distribution). L'intuition est qu'un processus malveillant, un domaine C2 ou un binaire suspect apparaîtra rarement par rapport au comportement normal.

# Exemple: Stack count des processus parents dans Sysmon (Event ID 1)
# Elasticsearch / OpenSearch Query
GET wazuh-alerts-*/_search
{
  "size": 0,
  "query": {
    "bool": {
      "must": [
        { "match": { "data.win.system.eventID": "1" }},
        { "range": { "timestamp": { "gte": "now-7d" }}}
      ]
    }
  },
  "aggs": {
    "parent_processes": {
      "terms": {
        "field": "data.win.eventdata.parentImage.keyword",
        "size": 500,
        "order": { "_count": "asc" }
      }
    }
  }
}

Un processus parent qui n'apparaît qu'une ou deux fois sur 7 jours mérite investigation -- c'est potentiellement un binaire dropped par un attaquant qui lance d'autres processus. Le stack counting est applicable à presque tous les champs : noms de processus, chemins d'exécution, domaines DNS, user-agents HTTP, clés de registre modifiées, etc.

4.2 Long Tail Analysis

La long tail analysis étend le stack counting en analysant la distribution statistique complète des valeurs. Dans un environnement normal, la plupart des distributions de données de sécurité suivent une loi de puissance (power law) : un petit nombre de valeurs sont très fréquentes (tête), et un grand nombre de valeurs sont rares (queue). Les menaces se cachent dans la queue.

# Long tail analysis des requêtes DNS - Python/Jupyter
import pandas as pd
import matplotlib.pyplot as plt
from collections import Counter

# Charger les logs DNS depuis Elasticsearch
dns_queries = es.search(
    index="wazuh-alerts-*",
    body={
        "size": 10000,
        "query": {"match": {"rule.groups": "dns"}},
        "_source": ["data.dns.question.name"]
    }
)

# Extraire les domaines de second niveau
domains = [extract_sld(hit['_source']['data']['dns']['question']['name'])
           for hit in dns_queries['hits']['hits']]

# Compter et trier par fréquence
domain_counts = Counter(domains)
sorted_counts = sorted(domain_counts.values(), reverse=True)

# Visualiser la distribution
plt.figure(figsize=(14, 6))
plt.subplot(1, 2, 1)
plt.plot(sorted_counts)
plt.title("Distribution des requêtes DNS par domaine")
plt.xlabel("Rang du domaine")
plt.ylabel("Nombre de requêtes")

plt.subplot(1, 2, 2)
plt.plot(sorted_counts)
plt.yscale('log')
plt.xscale('log')
plt.title("Distribution log-log (power law)")
plt.xlabel("Rang (log)")
plt.ylabel("Fréquence (log)")
plt.tight_layout()
plt.show()

# Identifier la queue : domaines avec < 5 requêtes
tail_domains = {d: c for d, c in domain_counts.items() if c < 5}
print(f"Domaines dans la longue queue: {len(tail_domains)}")
for domain, count in sorted(tail_domains.items(), key=lambda x: x[1]):
    print(f"  {domain}: {count} requêtes")

4.3 Frequency Analysis (détection de beaconing)

L'analyse de fréquence cible spécifiquement les communications C2 beaconing. Un implant C2 contacte typiquement son serveur à intervalles réguliers (avec ou sans jitter), créant un pattern de fréquence détectable. La technique consiste à calculer les intervalles entre connexions successives vers une même destination et à identifier les patterns de régularité anormale.

# Détection de beaconing C2 - Python/Jupyter
import numpy as np
from scipy import stats

def detect_beaconing(connection_times, jitter_threshold=0.15):
    """
    Détecte le beaconing C2 par analyse des intervalles.
    
    Args:
        connection_times: liste de timestamps (triés)
        jitter_threshold: seuil de coefficient de variation
    
    Returns:
        dict avec les métriques de beaconing
    """
    if len(connection_times) < 10:
        return None
    
    # Calculer les intervalles entre connexions
    intervals = np.diff(connection_times)
    
    # Métriques statistiques
    mean_interval = np.mean(intervals)
    std_interval = np.std(intervals)
    cv = std_interval / mean_interval  # Coefficient de variation
    
    # Skewness (asymétrie) - un beaconing parfait a skewness = 0
    skew = stats.skew(intervals)
    
    # Mode (intervalle le plus fréquent)
    hist, bin_edges = np.histogram(intervals, bins=50)
    mode_interval = bin_edges[np.argmax(hist)]
    
    # Score de beaconing (0 = pas de beaconing, 1 = beaconing parfait)
    beacon_score = max(0, 1 - cv) * max(0, 1 - abs(skew)/3)
    
    return {
        'mean_interval': mean_interval,
        'std_interval': std_interval,
        'cv': cv,
        'skew': skew,
        'mode_interval': mode_interval,
        'beacon_score': beacon_score,
        'num_connections': len(connection_times),
        'is_beaconing': beacon_score > 0.7 and cv < jitter_threshold
    }

# Appliquer à chaque paire (source, destination)
for (src, dst), connections in grouped_flows.items():
    result = detect_beaconing(connections['timestamps'].values)
    if result and result['is_beaconing']:
        print(f"BEACONING DETECTED: {src} -> {dst}")
        print(f"  Interval: {result['mean_interval']:.1f}s +/- {result['std_interval']:.1f}s")
        print(f"  Beacon score: {result['beacon_score']:.2f}")
        print(f"  Connections: {result['num_connections']}")

L'outil RITA (Real Intelligence Threat Analytics) automatise cette analyse sur les logs Zeek. Il calcule automatiquement les scores de beaconing pour chaque paire source-destination et fournit un dashboard des résultats. Nous y reviendrons dans la section outils.

4.4 TTP-Based Hunting

Le hunting basé sur les TTP (Tactics, Techniques and Procedures) utilise le framework MITRE ATT&CK comme guide structuré. Pour chaque technique ciblée, le hunter identifie les data sources pertinentes, les indicateurs comportementaux attendus et construit les requêtes correspondantes. Cette approche est systématique et reproductible.

Exemple de hunt TTP-based pour la technique T1053.005 - Scheduled Task (création de tâches planifiées pour la persistance) :

# Hunt: Scheduled Tasks suspectes (T1053.005)
# Data sources: Sysmon Event ID 1 (Process Create), Windows Event ID 4698 (Task Created)

# Étape 1: Identifier toutes les tâches créées récemment
GET wazuh-alerts-*/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "data.win.system.eventID": "4698" }},
        { "range": { "timestamp": { "gte": "now-30d" }}}
      ]
    }
  },
  "aggs": {
    "task_creators": {
      "terms": { "field": "data.win.eventdata.subjectUserName.keyword", "size": 100 },
      "aggs": {
        "tasks": {
          "terms": { "field": "data.win.eventdata.taskName.keyword", "size": 50 }
        }
      }
    }
  }
}

# Étape 2: Filtrer les créateurs de tâches inhabituels
# - Comptes de service créant des tâches → normal
# - Comptes utilisateur standard créant des tâches → suspect
# - Tâches avec des actions pointant vers %TEMP%, %APPDATA%, C:\Users\Public → suspect
# - Tâches avec des déclencheurs "AtLogon" ou "AtStartup" → persistance probable

# Étape 3: Pour chaque tâche suspecte, pivoter vers le processus créateur
# Correler avec Sysmon EventID 1 pour identifier la chaîne de processus complète

5. Outils essentiels du threat hunter

5.1 SIEM et plateformes de requêtage

Le SIEM est l'outil central du threat hunter. Il centralise les logs, permet les requêtes ad-hoc et fournit les capacités d'agrégation statistique indispensables au stack counting et à la long tail analysis. Les principales plateformes utilisées en threat hunting :

Plateforme	Forces pour le hunting	Limites	Coût
Elastic / OpenSearch	Requêtes DSL puissantes, agrégations, rétention longue	Courbe d'apprentissage DSL, gestion cluster	Open source / licence
Splunk	SPL très expressif, lookups, macros, apps communautaires	Coût par volume ingéré, licensing complexe	Licence commerciale
Wazuh	SIEM + XDR open source, agents endpoint intégrés, décodeurs	Performance à très gros volume, UI moins avancée	Open source
Microsoft Sentinel	KQL natif, intégration Azure/M365, notebooks Jupyter	Coût GB ingéré, vendor lock-in	Pay-as-you-go
Velociraptor	Interrogation live des endpoints (VQL), artefacts, hunting distribué	Pas un SIEM classique, nécessite déploiement agents	Open source

Pour les organisations à budget limité, la combinaison Wazuh + Elastic + Velociraptor offre une stack de hunting complète et open source. Wazuh collecte les événements endpoint et réseau, Elastic fournit le moteur de requêtage et d'agrégation, et Velociraptor permet l'interrogation live quand le SIEM ne contient pas les données nécessaires.

5.2 Velociraptor : le couteau suisse du hunter

Velociraptor mérite une attention particulière car c'est l'outil le plus transformateur pour le threat hunting endpoint. Contrairement à un SIEM qui recherche dans les logs historiques, Velociraptor interroge les endpoints en temps réel via son langage VQL (Velociraptor Query Language). Cela permet de répondre à des questions que le SIEM ne peut pas traiter :

• Quels processus sont actuellement en cours d'exécution avec des connexions réseau actives vers l'extérieur ?
• Quels fichiers ont été modifiés dans les répertoires Startup de tous les endpoints dans les dernières 24h ?
• Quels services Windows ont des binaires signés par des certificats inhabituels ?
• Quel est le contenu de la table ARP sur tous les serveurs du segment critique ?

# VQL Hunt: Processus avec connexions réseau vers IPs externes
SELECT Pid, Name, CommandLine, {
    SELECT Raddr.IP AS RemoteIP, Raddr.Port AS RemotePort, Status
    FROM netstat()
    WHERE Raddr.IP != "127.0.0.1"
      AND Raddr.IP != "::1"
      AND NOT Raddr.IP =~ "^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)"
      AND Status = "ESTABLISHED"
} AS ExternalConnections
FROM pslist()
WHERE ExternalConnections

# VQL Hunt: Tâches planifiées suspectes (persistance)
SELECT TaskName, ActionPath, Arguments, Principal, TriggerType, Enabled
FROM schedule_service()
WHERE ActionPath =~ "(powershell|cmd\.exe|mshta|wscript|cscript|rundll32)"
   OR ActionPath =~ "(\\\\Users\\\\Public|\\\\AppData\\\\Local\\\\Temp|%TEMP%)"

# VQL Hunt: DLLs non signées chargées par des processus système
SELECT Pid, Name AS ProcessName, ModuleName, ExePath, Authenticode.Trusted AS Signed
FROM modules()
WHERE Name =~ "(svchost|lsass|services|csrss)"
  AND NOT Authenticode.Trusted = "trusted"

La fonctionnalité Hunt de Velociraptor permet de lancer une requête VQL sur l'ensemble du parc (ou un sous-ensemble) en quelques clics, de collecter les résultats de manière asynchrone et de les analyser dans l'interface ou de les exporter pour analyse dans un notebook. C'est exactement ce dont le hunter a besoin pour valider rapidement une hypothèse à l'échelle.

5.3 RITA : détection automatisée de beaconing

RITA (Real Intelligence Threat Analytics) est un outil open source développé par Active Countermeasures qui automatise la détection de beaconing C2 dans les logs réseau Zeek. RITA analyse les connexions réseau et calcule un score de beaconing pour chaque paire source-destination en évaluant la régularité temporelle, la cohérence de la taille des paquets et la fréquence des connexions.

# Installation et utilisation de RITA
# 1. Installer RITA (nécessite MongoDB)
wget https://github.com/activecm/rita/releases/latest/download/install.sh
chmod +x install.sh && sudo ./install.sh

# 2. Importer des logs Zeek
rita import /opt/zeek/logs/2026-03-01/ dataset_20260301

# 3. Afficher les résultats de beaconing
rita show-beacons dataset_20260301

# Score | Source          | Destination     | Connections | Avg Bytes | Ts Score | Ds Score
# 0.987 | 10.10.5.42     | 185.141.25.168  | 8432        | 128       | 0.99     | 0.95
# 0.912 | 10.10.12.88    | cdn-static.xyz  | 2156        | 256       | 0.94     | 0.88
# 0.034 | 10.10.1.15     | update.msft.com | 48          | 4096      | 0.12     | 0.02

# 4. Afficher les connexions longues (potential tunnels)
rita show-long-connections dataset_20260301

# 5. Analyser les requêtes DNS (domains suspects, exfiltration)
rita show-exploded-dns dataset_20260301

Un score de beaconing supérieur à 0.80 est généralement suspect et justifie une investigation approfondie. RITA est particulièrement efficace pour détecter les C2 qui utilisent des intervalles réguliers (Cobalt Strike avec son jitter par défaut, par exemple). Pour les C2 avec un jitter élevé, l'analyse manuelle de fréquence décrite dans la section 4.3 reste nécessaire.

5.4 Jupyter Notebooks : l'environnement d'analyse avancée

Les Jupyter Notebooks sont devenus l'environnement de prédilection des threat hunters avancés. Ils permettent de combiner code Python, visualisations, requêtes SIEM et documentation dans un document unique et reproductible. Le projet MSTIC Jupyter Notebooks de Microsoft et la bibliothèque MSTICPy fournissent des composants prêts à l'emploi pour le hunting :

• Connecteurs data : interrogation directe d'Elasticsearch, Splunk, Sentinel, VirusTotal, Shodan depuis le notebook
• Enrichissement : résolution IP/domaine, géolocalisation, réputation, whois automatisés
• Visualisations : timelines d'événements, graphes de processus, heatmaps de connexions
• Analyse statistique : bibliothèques pandas, scipy, scikit-learn pour le clustering, la détection d'anomalies et l'analyse de séries temporelles

# Jupyter Notebook: Hunt C2 Beaconing avec analyse statistique
import pandas as pd
import numpy as np
from msticpy.data import QueryProvider
from msticpy.vis.timeline import display_timeline

# Connexion au SIEM
qry = QueryProvider("Elasticsearch")
qry.connect(connection_str="http://wazuh-indexer:9200")

# Requête: toutes les connexions sortantes vers une IP spécifique sur 7 jours
df = qry.exec_query("""
    SELECT timestamp, src_ip, dst_ip, dst_port, bytes_sent, bytes_recv
    FROM zeek-conn-*
    WHERE dst_ip = '185.141.25.168'
    AND timestamp >= now() - INTERVAL 7 DAY
    ORDER BY timestamp
""")

# Calcul des intervalles entre connexions
df['interval'] = df['timestamp'].diff().dt.total_seconds()
intervals = df['interval'].dropna()

# Statistiques de régularité
print(f"Nombre de connexions: {len(df)}")
print(f"Intervalle moyen: {intervals.mean():.1f}s")
print(f"Écart-type: {intervals.std():.1f}s")
print(f"Coefficient de variation: {intervals.std()/intervals.mean():.3f}")
# CV < 0.10 = très régulier (beaconing probable)
# CV 0.10-0.30 = modérément régulier (jitter modéré)
# CV > 0.50 = irrégulier (probablement légitime)

# Visualisation timeline
display_timeline(df, title="Connexions vers 185.141.25.168", source_columns=["src_ip"])

5.5 Sigma et les règles de détection portables

Chaque hunt réussi doit produire une règle de détection automatisée. Le format Sigma est le standard de facto pour écrire des règles de détection portables, convertibles vers n'importe quel SIEM. Un hunt qui découvre un comportement malveillant devrait systématiquement se conclure par la rédaction d'une règle Sigma qui automatisera la détection de ce comportement à l'avenir :

# Règle Sigma produite par un hunt sur le DNS tunneling
title: Potential DNS Tunneling - High Entropy Subdomains
id: a7f21e3c-9b4d-4e8a-b6c2-1d5f3a7e9c4b
status: experimental
description: |
    Détecte les requêtes DNS avec des sous-domaines à haute entropie,
    indicateur potentiel de DNS tunneling (exfiltration ou C2).
    Produit par le hunt TH-2026-012.
author: SOC Team - Hunt TH-2026-012
date: 2026/03/01
references:
    - https://attack.mitre.org/techniques/T1071/004/
tags:
    - attack.command_and_control
    - attack.t1071.004
    - attack.exfiltration
    - attack.t1048.003
logsource:
    category: dns_query
    product: windows
detection:
    selection:
        QueryName|re: '^[a-z0-9]{20,}\.'
    filter_legitimate:
        QueryName|endswith:
            - '.windowsupdate.com'
            - '.microsoft.com'
            - '.office.com'
            - '.akamaized.net'
    condition: selection and not filter_legitimate
level: medium
falsepositives:
    - CDN with encoded URLs
    - Anti-spam DKIM verification queries

6. Hunts pratiques : scénarios complets

6.1 Hunt #1 : Détection de C2 beaconing via DNS

Ce hunt cible les communications C2 qui utilisent le protocole DNS comme canal de communication (DNS tunneling, DNS-over-HTTPS C2, ou simplement le DNS comme canal de commande).

Prepare

Hypothèse : "Un adversaire utilise le DNS tunneling pour communiquer avec son infrastructure C2, générant des requêtes DNS avec des sous-domaines anormalement longs ou à haute entropie vers des domaines récemment enregistrés."

Data sources requises : logs DNS (Sysmon Event ID 22 ou logs DNS server), données de résolution passive (PassiveDNS), registre whois.

Execute

# Étape 1: Identifier les domaines avec un volume anormal de sous-domaines uniques
GET dns-logs-*/_search
{
  "size": 0,
  "query": { "range": { "timestamp": { "gte": "now-7d" }}},
  "aggs": {
    "domains": {
      "terms": {
        "field": "registered_domain.keyword",
        "size": 1000,
        "order": { "unique_subdomains": "desc" }
      },
      "aggs": {
        "unique_subdomains": {
          "cardinality": { "field": "query.keyword" }
        },
        "total_queries": {
          "value_count": { "field": "query.keyword" }
        },
        "sources": {
          "terms": { "field": "src_ip.keyword", "size": 10 }
        }
      }
    }
  }
}

# Étape 2: Pour chaque domaine suspect, vérifier:
# - Ratio sous-domaines uniques / total requêtes > 0.8 = suspect
# - Longueur moyenne des sous-domaines > 30 chars = très suspect
# - Entropie Shannon des sous-domaines > 3.5 = encodage probable
# - Domaine enregistré < 30 jours = risque élevé

# Étape 3: Enrichissement
# - Whois du domaine (date création, registrar, privacy)
# - VirusTotal, URLhaus pour réputation
# - Analyse de la structure des sous-domaines (base64? hex?)

Act

Si le hunt confirme un C2 DNS actif : (1) isoler immédiatement le endpoint source, (2) bloquer le domaine au niveau DNS resolver et firewall, (3) rechercher les autres endpoints ayant contacté le même domaine, (4) lancer une investigation forensique complète sur le endpoint compromis, (5) escalader à l'équipe de réponse à incident.

Knowledge

Documenter : (1) la technique C2 identifiée et ses caractéristiques (intervalles, encodage, domaine), (2) rédiger la règle Sigma de détection, (3) ajouter le domaine et les IOC associés à la watchlist, (4) mettre à jour le playbook de réponse DNS tunneling.

6.2 Hunt #2 : Mouvement latéral via outils natifs Windows

Ce hunt cible l'utilisation d'outils natifs Windows pour le mouvement latéral -- une technique privilégiée par les attaquants avancés car elle utilise des outils légitimes déjà présents sur les systèmes (Living off the Land).

Prepare

Hypothèse : "Un attaquant ayant compromis un compte utilisateur utilise PsExec, WMI ou WinRM pour se déplacer latéralement vers des serveurs du réseau interne, en dehors des patterns d'administration normaux."

Execute

# Étape 1: Baseline - Qui administre normalement quoi ?
# Identifier les paires (compte, machine cible) normales via les 30 derniers jours

# WinRM (Event ID 4624, LogonType 3, AuthPackage Kerberos/NTLM via port 5985/5986)
GET wazuh-alerts-*/_search
{
  "size": 0,
  "query": {
    "bool": {
      "must": [
        { "match": { "data.win.system.eventID": "4624" }},
        { "match": { "data.win.eventdata.logonType": "3" }},
        { "range": { "timestamp": { "gte": "now-30d", "lt": "now-7d" }}}
      ]
    }
  },
  "aggs": {
    "admin_pairs": {
      "composite": {
        "size": 10000,
        "sources": [
          { "user": { "terms": { "field": "data.win.eventdata.targetUserName.keyword" }}},
          { "target": { "terms": { "field": "agent.name.keyword" }}}
        ]
      }
    }
  }
}

# Étape 2: Rechercher les nouvelles paires dans les 7 derniers jours
# Toute paire (compte, machine) apparaissant dans les 7 derniers jours
# mais ABSENTE du baseline des 30 jours précédents = anomalie

# Étape 3: Filtrer les résultats
# - Exclure les comptes de service connus (svc_*, SYSTEM)
# - Exclure les accès depuis les jump servers / PAW officiels
# - Exclure les logons liés au patching (SCCM, WSUS)
# - Se concentrer sur: comptes utilisateur standard → serveurs
#   et comptes admin → machines hors de leur périmètre

La clé de ce hunt est la comparaison baseline vs actuel. Un mouvement latéral crée par définition de nouvelles paires d'accès qui n'existaient pas auparavant. L'attaquant peut utiliser des outils légitimes, mais il ne peut pas empêcher la création de nouveaux patterns d'accès.

6.3 Hunt #3 : Data staging avant exfiltration

Avant d'exfiltrer des données, un adversaire doit les collecter et préparer (data staging). Cette phase génère des indicateurs détectables : compression de gros volumes, copie de fichiers sensibles vers un répertoire de staging, chiffrement de données.

Prepare

Hypothèse : "Un attaquant collecte des fichiers sensibles dans un répertoire de staging (répertoire temporaire, répertoire utilisateur) puis les compresse avant exfiltration. Cette activité génère des événements de création de fichiers anormaux et des exécutions de binaires de compression."

Execute

# Hunt: Utilisation suspecte d'outils d'archivage/compression
# Sysmon Event ID 1 (Process Create) + Event ID 11 (File Create)

# Requête 1: Exécutions de 7z, rar, tar, makecab avec des cibles suspectes
GET wazuh-alerts-*/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "data.win.system.eventID": "1" }},
        { "range": { "timestamp": { "gte": "now-14d" }}},
        {
          "bool": {
            "should": [
              { "wildcard": { "data.win.eventdata.originalFileName.keyword": "*7z*" }},
              { "wildcard": { "data.win.eventdata.originalFileName.keyword": "*rar*" }},
              { "match_phrase": { "data.win.eventdata.commandLine": "Compress-Archive" }},
              { "match_phrase": { "data.win.eventdata.commandLine": "makecab" }}
            ]
          }
        }
      ]
    }
  },
  "_source": ["agent.name", "data.win.eventdata.user", 
              "data.win.eventdata.commandLine", "data.win.eventdata.parentImage",
              "timestamp"]
}

# Requête 2: Fichiers archives créés dans des répertoires inhabituels
# Sysmon Event ID 11 - File Create
GET wazuh-alerts-*/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "data.win.system.eventID": "11" }},
        { "range": { "timestamp": { "gte": "now-14d" }}},
        {
          "bool": {
            "should": [
              { "wildcard": { "data.win.eventdata.targetFilename.keyword": "*.7z" }},
              { "wildcard": { "data.win.eventdata.targetFilename.keyword": "*.zip" }},
              { "wildcard": { "data.win.eventdata.targetFilename.keyword": "*.rar" }}
            ]
          }
        },
        {
          "bool": {
            "should": [
              { "wildcard": { "data.win.eventdata.targetFilename.keyword": "*\\Temp\\*" }},
              { "wildcard": { "data.win.eventdata.targetFilename.keyword": "*\\Public\\*" }},
              { "wildcard": { "data.win.eventdata.targetFilename.keyword": "*\\ProgramData\\*" }}
            ]
          }
        }
      ]
    }
  }
}

# Indicateurs de staging:
# - Archives > 100 MB créées par des comptes utilisateur standard
# - Archives dans C:\Users\Public, C:\ProgramData, %TEMP%
# - Processus parent = cmd.exe ou powershell.exe (interactif)
# - Suivi par une connexion sortante (upload) dans les heures qui suivent

7. Métriques et mesure de l'efficacité

Un programme de threat hunting doit être mesuré pour démontrer sa valeur et s'améliorer continuellement. Voici les métriques clés à suivre :

7.1 Métriques d'activité

Métrique	Description	Cible
Nombre de hunts/mois	Volume d'activité de hunting	4-8 hunts/mois (équipe de 2-3)
Couverture ATT&CK	% de techniques ATT&CK couvertes par au moins un hunt dans l'année	> 40% des techniques pertinentes
Durée moyenne d'un hunt	Temps de la formulation d'hypothèse à la clôture	2-5 jours ouvrés
Data sources utilisées	Nombre de sources de données différentes exploitées	Augmentation progressive

7.2 Métriques de résultats

Métrique	Description	Interprétation
Taux de découverte	% de hunts qui découvrent un vrai positif (menace confirmée)	5-15% est normal ; 0% = problème de télémétrie ou d'hypothèses
Nouvelles détections créées	Nombre de règles Sigma/SIEM produites par les hunts	> 2 règles par hunt (même sans finding)
Lacunes de visibilité identifiées	Data sources manquantes découvertes pendant les hunts	Chaque lacune comblée = amélioration permanente
Dwell time réduction	Temps moyen entre compromission et détection	Objectif : réduction de 50%+ en 12 mois
Incidents découverts	Incidents de sécurité découverts uniquement par le hunting (pas par les alertes)	Justification directe du programme

7.3 Le hunt report : modèle de documentation

Chaque hunt doit produire un rapport standardisé. Voici le modèle recommandé :

# Hunt Report Template
## Metadata
- Hunt ID: TH-2026-XXX
- Hunter: [Nom]
- Date début: YYYY-MM-DD
- Date fin: YYYY-MM-DD
- Statut: Terminé / En cours / Abandonné

## Hypothèse
[Formulation claire et testable]

## Scope
- Environnement cible: [endpoints Windows / serveurs Linux / réseau / cloud]
- Période analysée: [date début - date fin]
- Data sources utilisées: [Sysmon, DNS, Zeek, etc.]

## Méthodologie
[Description de l'approche, requêtes utilisées, outils]

## Résultats
### Findings (vrais positifs)
[Description détaillée de chaque découverte]

### Faux positifs notables
[Patterns légitimes qui ressemblent à des menaces - utile pour le tuning]

### Lacunes de visibilité
[Données manquantes qui auraient été nécessaires]

## Actions
- [ ] Règles de détection créées (liens vers les règles Sigma)
- [ ] Incidents escaladés (liens vers les tickets)
- [ ] Recommandations de visibilité (nouvelles data sources à déployer)
- [ ] Playbook de hunt mis à jour

## Leçons apprises
[Ce qui a bien fonctionné, ce qui pourrait être amélioré]

8. Construire une équipe de threat hunting

8.1 Profils et compétences

Le threat hunting requiert un profil hybride qui combine des compétences rarement réunies chez une seule personne. L'équipe idéale associe :

• Connaissance offensive : compréhension des TTPs adverses, expérience du pentest ou du red team. Le hunter doit penser comme l'attaquant pour formuler des hypothèses pertinentes.
• Compétence data : maîtrise des requêtes SIEM (DSL, SPL, KQL), scripting Python/PowerShell, analyse statistique. Le hunter doit manipuler de gros volumes de données efficacement.
• Connaissance de l'environnement : compréhension de l'infrastructure IT de l'organisation, des flux réseau normaux, des applications métier. Sans cette connaissance, le hunter ne peut pas distinguer le normal de l'anormal.
• Curiosité et persévérance : le hunting est une activité intellectuellement exigeante qui produit souvent des résultats négatifs. Le hunter doit être intrinsèquement motivé par la recherche et la résolution de problèmes.

8.2 Modèle organisationnel

Trois modèles organisationnels sont observés dans l'industrie :

Modèle	Description	Avantages	Inconvénients
Dédié	Équipe 100% dédiée au hunting, séparée du SOC opérationnel	Focus, expertise profonde, pas de distraction par les alertes	Coûteux, risque d'isolation du SOC
Rotatif	Analystes SOC L2/L3 font du hunting en rotation (ex: 1 semaine/mois)	Montée en compétence de l'équipe, connaissance terrain, coût réduit	Continuité limitée, interruptions par les alertes
Hybride	1-2 hunters dédiés qui animent un programme incluant des analystes en rotation	Meilleur des deux mondes, mentoring, scalable	Nécessite un lead expérimenté

Pour la plupart des organisations, le modèle hybride est le plus réaliste. Un hunt lead expérimenté définit les hypothèses, structure le programme et mentore les analystes SOC qui participent aux hunts en rotation. Cette approche permet de faire monter en compétence l'ensemble de l'équipe tout en maintenant la continuité du programme.

8.3 Montée en maturité progressive

La mise en place d'un programme de hunting suit généralement un parcours en 4 niveaux de maturité :

• Niveau 1 - IOC Sweeping (0-3 mois) : recherche réactive d'IOC issus du threat intelligence dans les logs SIEM. Pas d'hypothèse originale, mais développe la compétence de requêtage et la familiarité avec les données.
• Niveau 2 - Hunts structurés (3-6 mois) : formulation d'hypothèses basées sur ATT&CK, exécution de hunts avec le modèle PEAK, documentation systématique. Focus sur les techniques les plus courantes (T1059, T1053, T1021).
• Niveau 3 - Hunts avancés (6-12 mois) : utilisation de Jupyter notebooks, analyses statistiques avancées (clustering, anomaly detection), corrélation multi-sources, hunts proactifs basés sur le renseignement sectoriel.
• Niveau 4 - Programme mature (12+ mois) : couverture ATT&CK systématique, métriques de programme, création automatisée de détections, partage inter-organisations, contribution aux communautés (règles Sigma, threat intelligence).

9. Conclusion

Le threat hunting représente l'évolution nécessaire du SOC face à des adversaires qui opèrent sous le radar des détections automatisées. En passant d'une posture purement réactive à une capacité de chasse proactive, les organisations réduisent drastiquement le dwell time, découvrent des compromissions invisibles aux outils et construisent progressivement une défense plus robuste et plus adaptée à leur environnement spécifique.

Les clés du succès sont claires : une méthodologie structurée (le modèle PEAK), des techniques d'analyse maîtrisées (stack counting, long tail, beaconing detection), des outils adaptés (SIEM + Velociraptor + RITA + Jupyter) et surtout des analystes compétents et motivés par la chasse. Le threat hunting n'est pas un projet avec un début et une fin -- c'est un programme continu qui s'améliore à chaque itération.

Commencez petit : un analyste, un hunt par semaine, basé sur les techniques ATT&CK les plus courantes dans votre secteur. Documentez tout, capitalisez les enseignements, transformez chaque découverte en détection automatisée. En 12 mois, vous aurez construit une capacité qui transforme fondamentalement la posture de sécurité de votre organisation.

En résumé : Le threat hunting est l'art de formuler la bonne question, de la poser aux bonnes données et d'agir sur la réponse. C'est la discipline qui transforme un SOC réactif en un SOC proactif -- et un défenseur passif en un chasseur qui prend l'initiative.