Windows Event Forwarding pour les contrôleurs de domaine

Le journal Security d'un contrôleur de domaine est un tampon circulaire qui s'écrase lui-même, souvent en quelques heures sur un DC chargé. Un attaquant disposant des droits Domain Admin peut aussi l'effacer. Toute détection qui dépend de la lecture des journaux sur le DC lui-même est fragile : elle suppose que l'événement survive, que le DC soit joignable et que personne n'ait exécuté wevtutil cl Security. Windows Event Forwarding (WEF) est intégré à Windows et achemine en quelques secondes les événements de chaque DC vers un Windows Event Collector (WEC) central. De là, un agent SIEM les récupère.

Ce guide construit une chaîne WEF de production pour les contrôleurs de domaine à l'aide d'abonnements initiés par la source : le collecteur, la GPO, l'accès au journal Security, la requête d'abonnement, le dimensionnement et la supervision de l'état de santé. La stratégie d'audit qui détermine quels événements existent est traitée dans l'article pilier sur l'audit et la détection. La référence des ID d'événements explique lesquels conserver.

Architecture

• Sources. Chaque DC, ainsi que les serveurs AD CS, AD FS et Entra Connect. Le redirecteur intégré s'exécute dans le service WinRM en tant que Network Service et pousse les événements via WS-Management.
• Collecteur. Un serveur Windows dédié exécutant le service Windows Event Collector (Wecsvc), qui reçoit les événements dans le journal ForwardedEvents ou dans des canaux personnalisés.
• Aval. Un agent SIEM ou Azure Monitor Agent sur le collecteur transmet ensuite les événements. Le collecteur est un tampon, pas le stockage à long terme.

Le collecteur détient une copie de chaque événement de sécurité des DC : traitez-le comme un système sensible. Administrez-le depuis le même tier que les DC, ou depuis un tier de sécurité dédié que les administrateurs des DC ne peuvent pas administrer. L'objectif est qu'un Domain Admin compromis ne puisse pas effacer discrètement les preuves. Dans tous les cas, incluez-le dans votre inventaire Tier 0.

Mesurer : le volume d'événements avant de construire

Dimensionnez à partir de chiffres réels. Sur deux ou trois DC représentatifs, mesurez la vitesse de rotation du journal Security :

$log = Get-WinEvent -ListLog Security
$first = Get-WinEvent -LogName Security -MaxEvents 1 -Oldest
$last  = Get-WinEvent -LogName Security -MaxEvents 1
$span  = ($last.TimeCreated - $first.TimeCreated).TotalSeconds
[pscustomobject]@{
  DC              = $env:COMPUTERNAME
  RecordCount     = $log.RecordCount
  HoursCovered    = [math]::Round($span / 3600, 1)
  AvgEventsPerSec = [math]::Round($log.RecordCount / $span, 1)
  LogSizeMB       = [math]::Round($log.FileSize / 1MB)
}

Mesurez à nouveau pendant le pic d'ouvertures de session du lundi matin. Pour la planification, comptez environ 1 Ko par événement transféré avec ContentFormat à Events, et multipliez par le nombre d'événements par seconde en pointe sur l'ensemble des DC. Vous obtenez le débit d'ingestion pour le disque du collecteur et pour la licence SIEM.

Construire le collecteur

Sur un serveur membre Windows Server 2022 ou 2025 dédié :

# Écouteur WinRM (activé par défaut sur les Windows Server actuels), puis Wecsvc en démarrage automatique différé
winrm quickconfig -q
wecutil qc /q

# Agrandir le journal ForwardedEvents et le déplacer sur un volume dédié
wevtutil sl ForwardedEvents /ms:2147483648 /lfn:"E:\Logs\ForwardedEvents.evtx"
Get-WinEvent -ListLog ForwardedEvents | Select-Object LogName, MaximumSizeInBytes, LogFilePath

Placez le journal sur un volume dédié et rapide. Sur les collecteurs Windows Server 2016 et 2019, vérifiez le problème documenté par Microsoft dans lequel les sources ne peuvent pas se connecter parce que WinRM et Wecsvc partagent un hôte de service avec une ACL d'URL HTTP incorrecte. Appliquez le correctif documenté avant de dépanner quoi que ce soit d'autre.

Configurer les sources par GPO

Créez une GPO liée à l'UO Domain Controllers (et aux UO des autres serveurs Tier 0 dont vous transférez les événements).

1. Pointer les sources vers le collecteur. Computer Configuration > Policies > Administrative Templates > Windows Components > Event Forwarding > Configure target Subscription Manager : Enabled, avec la valeur :

   Server=http://wec01.corp.example.com:5985/wsman/SubscriptionManager/WEC,Refresh=60

2. S'assurer que WinRM s'exécute. Computer Configuration > Policies > Windows Settings > Security Settings > System Services > Windows Remote Management (WS-Management) : Automatic.

3. Autoriser le redirecteur à lire le journal Security. Le redirecteur s'exécute en tant que Network Service, qui ne peut pas lire le journal Security par défaut. Ajoutez NT AUTHORITY\NETWORK SERVICE au groupe intégré Event Log Readers, ou étendez l'ACL du canal via Computer Configuration > Policies > Administrative Templates > Windows Components > Event Log Service > Security > Configure log access. Avec la seconde option, ajoutez (A;;0x1;;;NS) à la fin du SDDL existant obtenu avec wevtutil gl Security.

Sur les DC, Event Log Readers est un groupe intégré à l'échelle du domaine : une seule modification d'appartenance, exécutée une fois sur n'importe quel DC, couvre tous les DC :

net localgroup "Event Log Readers" "NT AUTHORITY\NETWORK SERVICE" /add

4. Autoriser le trafic. Les DC ont besoin du port TCP 5985 sortant vers le collecteur, et le collecteur a besoin du port 5985 entrant depuis les DC uniquement. Reportez-le dans votre stratégie de pare-feu des DC.

Après gpupdate, redémarrez WinRM sur chaque DC, ou redémarrez le serveur, pour que le redirecteur prenne en compte la nouvelle appartenance à Event Log Readers.

Rédiger l'abonnement

Créez l'abonnement en XML afin qu'il soit versionné et reproductible. Le SDDL AllowedSourceDomainComputers accorde au groupe Domain Controllers (DD) l'autorisation de l'utiliser :

<Subscription xmlns="http://schemas.microsoft.com/2006/03/windows/events/subscription">
  <SubscriptionId>DC-Security</SubscriptionId>
  <SubscriptionType>SourceInitiated</SubscriptionType>
  <Description>Security events from domain controllers</Description>
  <Enabled>true</Enabled>
  <Uri>http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog</Uri>
  <ConfigurationMode>Custom</ConfigurationMode>
  <Delivery Mode="Push">
    <Batching>
      <MaxItems>500</MaxItems>
      <MaxLatencyTime>30000</MaxLatencyTime>
    </Batching>
    <PushSettings>
      <Heartbeat Interval="900000"/>
    </PushSettings>
  </Delivery>
  <Query><![CDATA[
    <QueryList>
      <Query Id="0">
        <Select Path="Security">*[System[(EventID=1102 or EventID=4719 or EventID=4706 or EventID=4707 or EventID=4716)]]</Select>
        <Select Path="Security">*[System[(EventID&gt;=4720 and EventID&lt;=4767)]]</Select>
        <Select Path="Security">*[System[(EventID=4768 or EventID=4769 or EventID=4771 or EventID=4776)]]</Select>
        <Select Path="Security">*[System[(EventID=4662 or EventID=5136 or EventID=5137 or EventID=5138 or EventID=5139 or EventID=5141)]]</Select>
        <Select Path="Security">*[System[(EventID=4624 or EventID=4625 or EventID=4648 or EventID=4672 or EventID=4697)]]</Select>
        <Select Path="System">*[System[(EventID=7045)]]</Select>
        <Select Path="Directory Service">*[System[(EventID=2887 or EventID=2889 or EventID=2089)]]</Select>
      </Query>
    </QueryList>
  ]]></Query>
  <ReadExistingEvents>false</ReadExistingEvents>
  <TransportName>HTTP</TransportName>
  <ContentFormat>Events</ContentFormat>
  <Locale Language="en-US"/>
  <LogFile>ForwardedEvents</LogFile>
  <AllowedSourceNonDomainComputers></AllowedSourceNonDomainComputers>
  <AllowedSourceDomainComputers>O:NSG:BAD:P(A;;GA;;;DD)</AllowedSourceDomainComputers>
</Subscription>

Remarques sur ces choix :

• La remise personnalisée (Custom) avec une latence maximale de 30 secondes est proche du mode intégré MinLatency, mais permet de dimensionner les lots. Le mode Normal peut retarder les événements jusqu'à 15 minutes, ce qui est trop lent pour l'alerte.
• ContentFormat à Events supprime le texte du message rendu, ce qui divise environ par deux le stockage. Votre SIEM reconstitue le message à partir des données de l'événement.
• Plusieurs éléments Select au lieu d'une longue chaîne de or. Les expressions XPath longues atteignent les limites de longueur de requête et échouent silencieusement côté source.
• ReadExistingEvents à false évite que chaque DC ne rejoue l'intégralité de son journal à la création de l'abonnement. Passez-le temporairement à true si vous avez besoin d'un rattrapage de l'historique.

Ajoutez un abonnement distinct pour les serveurs AD CS (4886 à 4900) avec son propre SDDL ou groupe de sécurité, plutôt que d'élargir l'abonnement des DC.

wecutil cs C:\WEF\DC-Security.xml
wecutil gs DC-Security

Montée en charge et résilience

Un collecteur unique est un point de défaillance unique pour votre détection. Une fois le premier abonnement fonctionnel, renforcez l'architecture :

• Deux collecteurs, un seul nom. Pointez la GPO du gestionnaire d'abonnements vers un alias DNS, ou listez deux entrées Server= dans la stratégie. Un alias DNS envoie chaque source vers un seul collecteur à la fois : basculer implique de repointer l'alias, mais il n'y a pas de double ingestion. La stratégie accepte aussi plusieurs valeurs, et chaque source transfère alors vers tous les collecteurs listés : cela apporte une vraie redondance mais double l'ingestion, décidez donc de ce qui compte le plus, la disponibilité ou le coût du SIEM.
• Répartir selon le volume, pas seulement selon le rôle des serveurs. Si une poignée de DC de sites principaux produisent l'essentiel des événements, donnez-leur leur propre collecteur. Un collecteur qui prend du retard présente des écarts croissants entre TimeCreated et l'heure d'arrivée des événements dans ForwardedEvents.
• Des canaux personnalisés pour les données à fort volume. Tout ce qui se trouve dans ForwardedEvents tient dans un seul fichier. Les très grands environnements créent des canaux d'événements personnalisés sur le collecteur (un par abonnement), afin de pouvoir dimensionner et conserver chacun séparément, et pour qu'un afflux d'événements 4662 ne puisse pas évincer des événements plus rares et plus précieux.
• Expédier, puis élaguer. Le collecteur est un tampon. Laissez l'agent SIEM le lire en continu et ne conservez que quelques jours en local. Si le SIEM est indisponible, c'est ce tampon qui vous sauve : dimensionnez-le pour la plus longue panne de SIEM réaliste.
• Superviser le collecteur lui-même. Déclenchez des alertes sur l'arrêt du service Windows Event Collector, sur un espace disque faible sur le volume des journaux et sur le journal ForwardedEvents atteignant sa taille maximale.

Vérifier

Sur le collecteur, confirmez que chaque DC est actif et a transmis récemment :

wecutil gr DC-Security          # état d'exécution par source : Active, heure du dernier heartbeat, erreurs
Get-WinEvent -LogName ForwardedEvents -MaxEvents 20 |
  Select-Object TimeCreated, MachineName, Id

# DC qui n'ont rien transmis au cours de la dernière heure
$dcs = (Get-ADDomainController -Filter *).HostName
$seen = Get-WinEvent -FilterHashtable @{ LogName='ForwardedEvents'; StartTime=(Get-Date).AddHours(-1) } |
  Select-Object -ExpandProperty MachineName -Unique
$dcs | Where-Object { $_ -notin $seen }

Sur un DC qui ne transmet pas, consultez Microsoft-Windows-Eventlog-ForwardingPlugin/Operational. L'événement 100 signifie que l'abonnement a été créé. Des erreurs comme 104 et 105 décrivent des échecs de connectivité ou d'accès, généralement une règle de pare-feu, une URL de gestionnaire d'abonnements erronée ou l'absence d'accès en lecture au journal Security.

Get-WinEvent -LogName 'Microsoft-Windows-Eventlog-ForwardingPlugin/Operational' -MaxEvents 10 |
  Format-List TimeCreated, Id, Message

Effectuez ensuite un test de bout en bout. Ajoutez puis retirez un compte de test d'un groupe surveillé, et confirmez que les 4728 et 4729 arrivent dans le SIEM dans votre objectif de latence. Intégrez à la supervision une version planifiée du contrôle de « DC silencieux » ci-dessus. Un DC qui cesse de transmettre constitue en soi une détection.

Ce que cela casse

• Conflits avec le durcissement de WinRM. Les GPO qui désactivent le service WinRM sur les serveurs, ou les référentiels de pare-feu qui bloquent le port 5985 sortant depuis les DC, interrompent le transfert en silence. Le redirecteur réessaie sans remonter d'erreur dans le journal System.
• Une panne du collecteur crée un trou. Les sources conservent un signet et renvoient les événements au retour du collecteur, mais uniquement tant qu'ils existent encore dans le journal local. Gardez des journaux Security de DC suffisamment grands (plusieurs Go) pour couvrir une panne du collecteur d'au moins une journée.
• Charge sur les DC. Le redirecteur consomme peu de CPU, mais ReadExistingEvents à true sur un journal volumineux provoque un pic de charge et de trafic réseau sur tous les DC en même temps.
• Coût du SIEM. Transférer les 4624 de type 3 et les 4662 de DC chargés peut dominer le volume d'ingestion. Ne filtrez au niveau du collecteur ou du SIEM qu'après avoir vu les données. Filtrer à la source les fait disparaître définitivement.
• Horloge et nommage. MachineName dans les événements transférés est le FQDN de la source. Les DC renommés ou reconstruits apparaissent comme de nouvelles sources : mettez à jour les tableaux de bord par DC.

Pour aller plus loin : alimentez cette chaîne avec les signaux de leurres décrits dans honeytokens et tromperie, protégez le collecteur dans le cadre du Tier 0 et des accès privilégiés, et consultez l'ensemble de la thématique audit, journalisation et détection.