Audit Log : collecte et analyse en SOC

Un audit log est un enregistrement chronologique et immuable des événements système, applicatifs ou réseau, généré pour rendre compte de toute action significative sur une ressource. En cybersécurité, l'audit log constitue la matière première de toute investigation forensique et de toute détection d'incident. Sous Windows, la politique d'audit (configurée via GPO dans 'Computer Configuration / Windows Settings / Security Settings / Advanced Audit Policy Configuration') détermine quels événements sont capturés : ouvertures de session (Event ID 4624, 4625), création de processus (Event ID 4688), modifications de groupes privilégiés (Event ID 4728, 4732), ou encore accès aux objets (Event ID 4663). Sur Linux, les démons 'auditd' et 'syslog' jouent un rôle équivalent. Un audit log fiable doit garantir l'intégrité (non-altération), la complétude (aucun événement manquant) et l'horodatage précis (synchronisation NTP). Sans ces trois propriétés, la valeur probatoire des journaux s'effondre, tant pour la détection en temps réel que pour la reconstitution post-incident.

Côté Blue Team et SOC, la détection repose avant tout sur la centralisation des audit logs dans un SIEM (Splunk, Microsoft Sentinel, Elastic SIEM). Le premier indicateur à surveiller est l'absence soudaine de logs : un attaquant qui désactive l'audit Windows génère l'Event ID 4719 ('System audit policy was changed'), signal critique à alerter immédiatement. La suppression du journal de sécurité produit l'Event ID 1102 (Security) ou 104 (System). La détection d'abus de privilèges s'appuie sur les Event ID 4672 (attribution de privilèges spéciaux) et 4648 (ouverture de session avec credentials explicites). Les tentatives de brute-force génèrent une accumulation d'Event ID 4625 sur un compte cible en fenêtre temporelle courte. Pour les mouvements latéraux, les Event ID 4768 et 4769 (Kerberos TGT/TGS) associés à des anomalies de type 'ticket encryption type RC4' (indicateur de Kerberoasting) sont déterminants. La corrélation temporelle entre plusieurs sources de logs différentes (pare-feu, EDR, contrôleur de domaine) permet de reconstruire une chaîne d'attaque cohérente et de réduire le temps de détection.

Côté Red Team, la manipulation des audit logs est une technique de couverture de traces (T1070.001 dans MITRE ATT&CK). Un attaquant disposant de privilèges 'SeSecurityPrivilege' peut vider le journal de sécurité Windows via 'wevtutil cl Security' ou modifier la politique d'audit pour désactiver la journalisation ciblée. Des outils comme 'Invoke-Phant0m' permettent de suspendre le thread du service 'EventLog' sans l'arrêter, rendant la suppression invisible aux alertes classiques. La technique du 'log flooding' consiste à noyer les journaux d'événements légitimes sous un volume massif d'événements bruités, faisant sortir les alertes critiques de la fenêtre de rétention SIEM. Pour durcir l'environnement, plusieurs mesures sont indispensables : activer la politique 'Audit: Shut down system immediately if unable to log security audits' pour bloquer toute activité si les logs sont compromis ; restreindre 'SeSecurityPrivilege' aux seuls comptes de service d'audit ; centraliser les logs vers un collecteur en lecture seule (log shipper unidirectionnel) ; et définir une rétention minimale de 90 jours en ligne avec des archives longue durée pour répondre aux exigences réglementaires (NIS2, PCI-DSS).