Détecter les Attaques Active Directory avec Wazuh : Guide Complet

Règles Wazuh pour Golden Ticket

La détection des Golden Tickets est difficile car Kerberos est conçu pour valider les tickets sans requête DC. Les indicateurs les plus fiables sont les anomalies dans les événements 4768 (TGT request) : durée de vie du ticket anormale, type de chiffrement inhabituel, ou demande TGT pour un compte administrateur depuis une source inattendue.

<!-- Golden Ticket - TGS avec options suspectes et RC4 -->
<rule id="100230" level="13">
  <if_sid>60007</if_sid>
  <field name="win.system.eventID">^4769$</field>
  <field name="win.eventdata.ticketOptions">^0x40810010$</field>
  <field name="win.eventdata.ticketEncryptionType">^0x17$</field>
  <description>Potential Golden Ticket - Forged TGS with RC4 and anomalous options</description>
  <mitre><id>T1558.001</id></mitre>
</rule>

<!-- Golden Ticket - compte admin TGS request RC4 -->
<rule id="100231" level="14">
  <if_sid>60007</if_sid>
  <field name="win.system.eventID">^4769$</field>
  <list field="win.eventdata.accountName" lookup="match_key">etc/lists/sensitive-accounts</list>
  <field name="win.eventdata.ticketEncryptionType">^0x17$</field>
  <description>Golden Ticket Suspected - Admin account TGS request with RC4 encryption</description>
  <mitre><id>T1558.001</id></mitre>
  <group>attack,persistence</group>
</rule>

Règles Wazuh pour la reconnaissance LDAP (BloodHound)

BloodHound effectue une reconnaissance LDAP massive pour cartographier les chemins d'attaque AD. L'Event 1644 du journal Directory Service enregistre les requêtes LDAP coûteuses. Un pic de requêtes LDAP non indexées depuis une workstation est un signal fort d'activité BloodHound. Pour le contexte des chemins d'attaque, voir notre article sur BloodHound et la cartographie des chemins d'attaque AD.

<!-- LDAP Recon - Event 1644 (requêtes LDAP non optimisées) -->
<rule id="100240" level="10">
  <if_sid>60007</if_sid>
  <field name="win.system.eventID">^1644$</field>
  <field name="win.system.channel">Directory Service</field>
  <description>LDAP Expensive Query - Potential AD reconnaissance</description>
  <mitre><id>T1018</id></mitre>
</rule>

<!-- BloodHound/LDAP recon en masse - volume anormal -->
<rule id="100241" level="13" frequency="20" timeframe="60">
  <if_matched_sid>100240</if_matched_sid>
  <same_field>win.eventdata.clientIPAddress</same_field>
  <description>BloodHound Suspected - Mass LDAP queries from single source</description>
  <mitre><id>T1482</id></mitre>
  <group>attack,discovery</group>
</rule>

<!-- LDAP recon via Sysmon Event 3 (connexions réseau vers port 389/636) -->
<rule id="100242" level="8">
  <if_sid>61600</if_sid>
  <field name="win.system.eventID">^3$</field>
  <field name="win.eventdata.destinationPort">^(389|636|3268|3269)$</field>
  <field name="win.eventdata.initiated">true</field>
  <description>LDAP Connection from non-DC host - Potential reconnaissance</description>
  <mitre><id>T1018</id></mitre>
</rule>

Règles Wazuh — Modifications groupes privilégiés

Toute modification des groupes Domain Admins, Enterprise Admins ou Schema Admins doit générer une alerte de niveau critique immédiate. Ces groupes sont les cibles d'escalade de privilèges les plus directes.

<!-- Ajout membre groupe sécurité global (Domain Admins, etc.) -->
<rule id="100250" level="13">
  <if_sid>60007</if_sid>
  <field name="win.system.eventID">^4728$</field>
  <description>Member Added to Global Security Group - Potential Privilege Escalation</description>
  <mitre><id>T1098</id></mitre>
</rule>

<!-- Ajout à groupe local administrateurs sur DC -->
<rule id="100251" level="13">
  <if_sid>60007</if_sid>
  <field name="win.system.eventID">^4732$</field>
  <description>Member Added to Local Administrators Group on DC</description>
  <mitre><id>T1098</id></mitre>
</rule>

<!-- Ajout groupe universel (Enterprise Admins) -->
<rule id="100252" level="14">
  <if_sid>60007</if_sid>
  <field name="win.system.eventID">^4756$</field>
  <description>Member Added to Universal Security Group - Enterprise Admin escalation risk</description>
  <mitre><id>T1098</id></mitre>
  <group>attack,privilege_escalation</group>
</rule>

<!-- Règle spécifique Domain Admins / Enterprise Admins -->
<rule id="100253" level="15">
  <if_sid>100250,100252</if_sid>
  <list field="win.eventdata.targetUserName" lookup="match_key">etc/lists/privileged-groups</list>
  <description>CRITICAL - Member Added to Domain/Enterprise Admins</description>
  <mitre><id>T1098</id></mitre>
  <group>attack,privilege_escalation,critical</group>
</rule>

Règles Wazuh — Modifications GPO

Les attaquants qui ont compromis AD modifient souvent les GPO pour déployer des payloads ransomware ou des backdoors sur l'ensemble du parc. L'Event 5136 enregistre les modifications d'attributs AD, dont les objets GPO.

<!-- Modification attribut GPO - Event 5136 -->
<rule id="100260" level="12">
  <if_sid>60007</if_sid>
  <field name="win.system.eventID">^5136$</field>
  <field name="win.eventdata.objectClass">groupPolicyContainer</field>
  <description>GPO Modified - Potential malicious policy deployment</description>
  <mitre><id>T1484.001</id></mitre>
</rule>

<!-- Création d'une nouvelle GPO -->
<rule id="100261" level="11">
  <if_sid>60007</if_sid>
  <field name="win.system.eventID">^5137$</field>
  <field name="win.eventdata.objectClass">groupPolicyContainer</field>
  <description>New GPO Created - Verify if authorized change</description>
  <mitre><id>T1484.001</id></mitre>
</rule>

<!-- Liaison GPO à une OU critique -->
<rule id="100262" level="13">
  <if_sid>60007</if_sid>
  <field name="win.system.eventID">^5136$</field>
  <field name="win.eventdata.attributeLDAPDisplayName">gPLink</field>
  <description>GPO Linked to OU - Verify scope of policy application</description>
  <mitre><id>T1484.001</id></mitre>
  <group>attack,defense_evasion</group>
</rule>

Intégration Sysmon sur les DC pour enrichir les détections

Sysmon (System Monitor) de Sysinternals enrichit considérablement les capacités de détection sur les DC en loguant les créations de processus, les connexions réseau, et les modifications de clés de registre avec des détails que les événements Windows natifs ne fournissent pas.

<!-- Sysmon Event 1 - Création processus suspect sur DC -->
<rule id="100270" level="12">
  <if_sid>61600</if_sid>
  <field name="win.system.eventID">^1$</field>
  <field name="win.eventdata.image">(mimikatz|mimilove|wce\.exe|fgdump|pwdump)</field>
  <description>Known Credential Dumper Executed on DC</description>
  <mitre><id>T1003</id></mitre>
</rule>

<!-- Sysmon Event 10 - Accès au processus LSASS -->
<rule id="100271" level="14">
  <if_sid>61600</if_sid>
  <field name="win.system.eventID">^10$</field>
  <field name="win.eventdata.targetImage">lsass\.exe</field>
  <field name="win.eventdata.grantedAccess">0x1010</field>
  <description>LSASS Memory Access - Credential Dumping Detected</description>
  <mitre><id>T1003.001</id></mitre>
</rule>

<!-- Sysmon Event 11 - Création fichier dans répertoire NTDS -->
<rule id="100272" level="15">
  <if_sid>61600</if_sid>
  <field name="win.system.eventID">^11$</field>
  <field name="win.eventdata.targetFilename">[Nn][Tt][Dd][Ss]</field>
  <description>CRITICAL - File Created in NTDS Directory - Potential NTDS.dit copy</description>
  <mitre><id>T1003.003</id></mitre>
  <group>attack,credential_access,critical</group>
</rule>

La configuration Sysmon recommandée pour les DC est disponible sur le projet SwiftOnSecurity/sysmon-config. Pour le déploiement complet, consultez notre guide sur le déploiement de Wazuh SIEM/XDR open source.

Tableau de bord Wazuh recommandé pour AD

Le tableau de bord Wazuh (OpenSearch/Kibana) doit être configuré avec les visualisations suivantes pour une surveillance AD efficace :

Active Response Wazuh — Blocage automatique des attaques AD

La fonctionnalité Active Response de Wazuh permet de déclencher des actions automatiques en réponse à des alertes de sécurité. Pour la protection AD, trois réponses automatiques sont particulièrement utiles : le blocage de compte lors de détection de Kerberoasting massif, l'isolement réseau d'un hôte lors de détection d'accès LSASS, et la notification d'urgence vers le SOC lors d'une tentative DCSync.

Configuration de la réponse automatique — désactivation compte

<!-- ossec.conf sur le manager — active response pour Kerberoasting -->
<ossec_config>
  <command>
    <name>disable-ad-account</name>
    <executable>disable-ad-account.cmd</executable>
    <timeout_allowed>yes</timeout_allowed>
  </command>

  <active-response>
    <command>disable-ad-account</command>
    <location>local</location>
    <rules_id>100211</rules_id>
    <timeout>3600</timeout>
  </active-response>
</ossec_config>

# disable-ad-account.cmd (script PowerShell appelé par Wazuh Active Response)
# Récupère le nom du compte depuis les données d'alerte Wazuh
param($AlertData)
$accountName = ($AlertData | ConvertFrom-Json).data.win.eventdata.targetUserName
if ($accountName -and $accountName -ne "Administrator") {
    Disable-ADAccount -Identity $accountName
    Write-EventLog -LogName Security -Source "Wazuh-ActiveResponse" `
        -EventId 9999 -EntryType Warning `
        -Message "Account $accountName disabled by Wazuh Active Response (Kerberoasting)"
}

Alertes critiques vers le SOC — intégration PagerDuty/Teams

Pour les alertes de niveau 14 et 15 (DCSync, Golden Ticket, accès LSASS), une notification immédiate vers le canal SOC est indispensable. Wazuh propose des intégrations natives avec Slack, Microsoft Teams, PagerDuty et les webhooks génériques.

<!-- Integration Teams pour alertes critiques AD -->
<integration>
  <name>custom-teams</name>
  <hook_url>https://outlook.office.com/webhook/VOTRE-WEBHOOK-TEAMS</hook_url>
  <level>14</level>
  <rule_id>100200,100201,100230,100271,100272</rule_id>
  <alert_format>json</alert_format>
</integration>

Tuning et gestion des faux positifs sur les règles AD

Sans tuning approprié, les règles de détection AD génèrent un volume d'alertes qui noie les vrais incidents. Le tuning est un processus itératif qui nécessite au minimum deux semaines de collecte de données avant d'être stabilisé.

Sources courantes de faux positifs AD dans Wazuh

Exemple de règle de whitelist pour Azure AD Connect

<!-- Exclure Azure AD Connect du DCSync (compte MSOL_xxxxxxxx) -->
<rule id="100203" level="0">
  <if_sid>100200</if_sid>
  <field name="win.eventdata.subjectUserName">^MSOL_</field>
  <description>DCSync from Azure AD Connect - Whitelisted</description>
</rule>

<!-- Exclure les comptes de backup AD -->
<rule id="100204" level="0">
  <if_sid>100200</if_sid>
  <list field="win.eventdata.subjectUserName" lookup="match_key">etc/lists/ad-backup-accounts</list>
  <description>DCSync from authorized backup account - Whitelisted</description>
</rule>

Métriques de qualité des règles AD

Pour évaluer l'efficacité de votre configuration Wazuh, suivez ces métriques sur une fenêtre glissante de 7 jours : taux de vrais positifs confirmés (objectif supérieur à 95%), temps moyen de détection (objectif inférieur à 5 minutes pour DCSync/Golden Ticket), volume d'alertes niveau 12+ par jour (objectif inférieur à 20 alertes non-tuned après la phase initiale). Un dépassement de ces seuils indique soit un tuning insuffisant, soit une activité malveillante réelle à investiguer. La corrélation avec des données de threat intelligence via MISP, comme décrit dans la section suivante, améliore significativement la précision de la qualification des alertes.

Cas terrain France — SOC PME avec Wazuh + MISP

Intégration MISP pour la corrélation des IoC ANSSI

Une PME industrielle de 800 employés a déployé Wazuh 4.7 sur 6 DC Windows Server 2022 avec une intégration MISP pour la corrélation automatique des Indicateurs de Compromission publiés par l'ANSSI (flux CERT-FR). La configuration utilise le module d'intégration Wazuh-MISP qui enrichit chaque alerte avec les informations de threat intelligence.

# Integration Wazuh-MISP — custom-misp.py (dans /var/ossec/integrations/)
import json, sys, urllib3, requests

urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

MISP_URL = "https://misp.votre-soc.fr"
MISP_KEY = "votre-api-key-misp"

def query_misp(ioc_value):
    headers = {"Authorization": MISP_KEY, "Accept": "application/json", "Content-Type": "application/json"}
    payload = {"returnFormat": "json", "value": ioc_value, "type": ["ip-src","ip-dst","domain","hostname"]}
    r = requests.post(f"{MISP_URL}/events/restSearch", headers=headers, json=payload, verify=False)
    return r.json()

# Lire l'alerte Wazuh depuis stdin
alert = json.loads(sys.stdin.readline())
src_ip = alert.get("data", {}).get("win", {}).get("eventdata", {}).get("ipAddress", "")

if src_ip:
    misp_result = query_misp(src_ip)
    if misp_result.get("response"):
        print(json.dumps({"misp_match": True, "threat_level": misp_result["response"][0]["Event"]["threat_level_id"]}))

Résultats après 6 mois de déploiement

Après 6 mois, le SOC PME a identifié : 3 tentatives de Kerberoasting bloquées automatiquement par active response Wazuh (désactivation du compte source) ; 2 cas de reconnaissance LDAP BloodHound par des pentesteurs autorisés (tests positifs du système de détection) ; 1 alerte Golden Ticket généré lors d'un Red Team interne. Le taux de faux positifs après tuning a été ramené à moins de 2% pour les règles critiques. La corrélation MISP a permis d'identifier un IP scanneur référencé dans un rapport CERT-FR lié à un groupe APT ciblant l'industrie française. Pour comprendre les frameworks de référence utilisés dans les règles Wazuh, consultez notre article sur MITRE ATT&CK — TTPs 2026.

FAQ — Détection des Attaques Active Directory avec Wazuh

Wazuh peut-il détecter les attaques Kerberos en temps réel ?

Oui, à condition que l'audit Kerberos soit activé sur les DC (subcategory "Kerberos Service Ticket Operations") et que l'agent Wazuh collecte le canal Security. La détection du Kerberoasting (Event 4769 avec etype RC4) est quasi temps réel, avec un délai typique de 5 à 30 secondes entre l'événement et l'alerte Wazuh. La détection du Golden Ticket est plus complexe et repose sur des corrélations comportementales plutôt que sur un événement unique.

Quels événements Windows activer sur les DC pour Wazuh ?

Les événements critiques pour la surveillance AD sont : 4662 (accès objet AD avec GUID), 4768/4769 (authentification Kerberos TGT/TGS), 4624/4625 (logon succès/échec), 4728/4732/4756 (modifications groupes), 5136 (modification attribut AD), 1644 (requête LDAP coûteuse). Ces événements nécessitent l'activation de l'audit avancé via auditpol ou GPO. Sans cette configuration, Wazuh ne reçoit pas les événements nécessaires à la détection AD.

Comment différencier un faux positif d'une vraie attaque DCSync ?

Les vraies demandes de réplication DCSync proviennent de comptes qui ne sont pas des contrôleurs de domaine (l'Event 4662 sera généré par un compte utilisateur ou de service, pas par un compte machine DC$). Les faux positifs courants viennent des outils de sauvegarde AD (Veeam, Windows Server Backup) et des solutions de synchronisation d'identité (Azure AD Connect, Okta AD agent). Créez une liste blanche de ces comptes autorisés dans la règle Wazuh via l'opérateur not_match_key pour les exclure de la règle DCSync.

Wazuh supporte-t-il les alertes Sysmon pour les DC ?

Oui, nativement depuis Wazuh 4.2. L'agent Wazuh collecte le canal "Microsoft-Windows-Sysmon/Operational" et des règles pré-configurées (SID 61600-61699) mappent les événements Sysmon vers les techniques MITRE ATT&CK. Déployez Sysmon avec la configuration SwiftOnSecurity sur tous les DC pour enrichir les détections : accès LSASS (Event 10), créations de processus suspects (Event 1), connexions réseau vers les ports LDAP (Event 3), et modifications de registre liées à AD (Event 13).

Quel est le coût de déploiement de Wazuh pour surveiller Active Directory ?

Wazuh est entièrement open source (licence GPLv2). Le coût de déploiement est donc limité à l'infrastructure : un serveur dédié (4 vCPU, 8 Go RAM minimum pour moins de 50 agents), le temps d'intégration (estimé à 3-5 jours pour un environnement de 5 DC avec tuning des règles), et la formation des analystes SOC. Pour les entreprises sans équipe SOC interne, des prestataires MSSP français proposent Wazuh géré à partir de 500-1 500 euros/mois selon le nombre de DC surveillés. Cette solution représente un ROI significatif face aux coûts d'un incident AD non détecté (coût moyen d'un ransomware en France : 500k à 2M euros selon la taille de l'organisation).