Journaliser et détecter : les événements à surveiller

Prévenir ne suffit pas : il faut aussi voir une attaque pendant qu'elle se déroule. Les contrôleurs de domaine enregistrent, si on le leur demande, les ouvertures de session, les demandes de tickets, les changements de groupes et les modifications de l'annuaire. Ce chapitre explique quel audit activer, quels identifiants d'événements trahissent chaque attaque du chapitre 3, comment écrire les premières alertes, et pourquoi il faut centraliser ces journaux hors de portée de l'attaquant, vers le SIEM de Sorbier.

Activer le bon audit

Le journal Sécurité ne contient que ce que la stratégie d'audit demande d'enregistrer. Sur les contrôleurs, une partie est activée par défaut ; sur les serveurs membres et les postes, beaucoup moins. On règle l'audit par GPO, avec la configuration avancée de la stratégie d'audit (plus précise que les neuf catégories de l'ancienne stratégie) : Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Configuration avancée de la stratégie d'audit > Stratégies d'audit. Le cours Windows Server en donne le tableau complet ; pour la sécurité de l'annuaire, les sous-catégories essentielles sur les contrôleurs :

Pour que la configuration avancée soit prise en compte, on active aussi l'option Audit : force les paramètres de sous-catégorie... (Options de sécurité), et on vérifie le résultat avec auditpol /get /category:*. L'audit de l'accès à l'annuaire (4662) demande en plus une liste d'audit (SACL) sur l'objet concerné ; on ne l'active que là où c'est utile, pour ne pas noyer le journal.

Les événements qui trahissent chaque attaque

Deux champs affinent la lecture. Le type d'ouverture de session du 4624 dit comment la connexion s'est faite : 2 au clavier, 3 par le réseau (un partage), 10 par le bureau à distance. Le code d'état du 4625 donne la cause : 0xC000006A mauvais mot de passe, 0xC0000064 compte inexistant, 0xC0000234 compte verrouillé.

Lire une séquence

Face à une telle séquence, on raconte l'histoire : force brute réussie sur adm2-mdiallo, un compte de tier 2 ; puis demande d'un ticket de service en RC4, dont l'attaquant a cassé hors ligne le mot de passe d'un compte de service privilégié, utilisé pour l'ajout au groupe ; puis élévation de privilèges, avec adm2-mdiallo placé dans Admins du domaine, ce qu'un compte de tier 2 ne devrait jamais être ; enfin effacement des traces, de nuit. On traite comme un incident (cours Réponse à incident) : isoler le poste source, désactiver le compte, retirer l'appartenance au groupe, chercher d'autres actions, et, parce que le compte a touché au tier 0, prévoir le changement du mot de passe de krbtgt (chapitre 7).

Écrire les premières alertes en PowerShell

Get-WinEvent lit les journaux. Le paramètre -FilterHashtable filtre côté système, bien plus vite qu'un Where-Object.

# Les échecs Kerberos des dernières 24 heures, groupés par source : repère une pulvérisation
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4771; StartTime = (Get-Date).AddDays(-1) } |
    ForEach-Object { [pscustomobject]@{ Compte = $_.Properties[0].Value; Source = $_.Properties[6].Value } } |
    Group-Object Source | Sort-Object Count -Descending |
    Select-Object Count, Name -First 10

# Les ajouts aux groupes de sécurité de la dernière semaine (4728, 4732, 4756)
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4728, 4732, 4756; StartTime = (Get-Date).AddDays(-7) } |
    Format-List TimeCreated, Id, Message

# Les tickets de service chiffrés en RC4 (0x17), indice de Kerberoasting, sur les deux contrôleurs
Invoke-Command -ComputerName srv-ad, srv-ad2 -ScriptBlock {
    Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4769 } -MaxEvents 500 |
        Where-Object { $_.Message -match 'Type de chiffrement du ticket\s*:\s*0x17' }
} | Select-Object PSComputerName, TimeCreated

# Tout effacement du journal Sécurité, où qu'il soit, vu depuis le collecteur
Get-WinEvent -FilterHashtable @{ LogName = 'ForwardedEvents'; Id = 1102 }

La position des propriétés dépend de chaque identifiant d'événement ; pour un usage régulier, mieux vaut laisser le SIEM faire ces corrélations.

Poser un compte leurre (honeytoken)

Un compte leurre est un compte d'utilisateur qui ne sert à rien : personne ne s'en sert jamais, il n'a aucun droit, mais il porte un nom attirant (adm-sauvegarde, svc-backup-sql) et parfois un faux SPN. Comme aucun usage légitime ne le touche, toute activité le concernant (une tentative d'ouverture de session, une demande de ticket de service) est forcément le fait de quelqu'un qui explore l'annuaire. Une alerte sur un seul événement 4768, 4769 ou 4625 visant ce compte est donc à très faible taux de fausse alerte. C'est une mesure de détection simple et efficace, recommandée dans les guides de l'ANSSI et des éditeurs.

Centraliser : WEF et le SIEM

Les journaux laissés sur chaque machine ont trois défauts : il faut les lire un par un, ils sont écrasés quand ils sont pleins, et un attaquant qui a les droits d'administration peut les effacer (événement 1102). La parade est de les envoyer au fil de l'eau vers un point central, hors de sa portée.

• Le transfert d'événements Windows (WEF) envoie les événements choisis des postes, serveurs et contrôleurs vers un collecteur Windows, sans agent à installer, configuré par GPO. Le cours Windows Server détaille sa mise en place.
• Le SIEM reçoit, normalise, corrèle et alerte. Chez Sorbier, c'est Wazuh, installé sur srv-journaux (192.168.10.180) : un agent sur chaque machine (ou le collecteur WEF) envoie les journaux, et les règles de Wazuh déclenchent les alertes. La mise en place d'un agent, l'écriture des règles et les tableaux de bord sont l'objet du cours Wazuh (voir en particulier détecter les incidents courants) ; la supervision et les alertes, du cours Supervision.

Trois conditions pour que ces journaux servent de preuve, rappelées par l'ANSSI : une heure fiable et commune (tous les équipements synchronisés par NTP, service porté par srv-ad), un transport protégé (le collecteur et le SIEM dans une zone dédiée, les journaux chiffrés en transit), et une conservation suffisante (la CNIL recommande en général de six mois à un an pour les journaux d'activité). Le cours Réponse à incident détaille quoi journaliser et combien de temps.

La détection avancée : EDR, MDI, SIEM

Au-delà des journaux bruts, des outils repèrent les comportements d'attaque :

• un EDR surveille postes et serveurs et bloque ou isole une machine suspecte ;
• Microsoft Defender for Identity (MDI) installe un capteur sur les contrôleurs et alerte sur les comportements typiques (reconnaissance massive, demandes de tickets suspectes, DCSync, usage de golden ticket) ;
• le SIEM (Wazuh chez Sorbier) corrèle les sources et applique des règles.

Ces outils ne remplacent pas le durcissement : ils détectent ce qui passe malgré lui. Un domaine bien configuré et surveillé est bien plus solide que l'un ou l'autre seul.

Exercices

Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4728; StartTime = (Get-Date).AddDays(-30) } |
    Select-Object TimeCreated, Id, Message