La plupart des enquêtes s’arrêtent sur une question simple : où sont les journaux, et comment les extraire ? Sous Windows, les journaux d’événements se trouvent dans %SystemRoot%System32winevtLogs en tant que fichiers binaires .evtx. Exportez-les depuis le Visualiseur d’événements (cliquez avec le bouton droit sur un journal, puis Enregistrer tous les événements sous…) ou depuis une invite élevée avec wevtutil epl Security C:IRSecurity.evtx. Sous Linux basé sur systemd, le journal se trouve dans /var/log/journal/ lorsque le stockage persistant est activé, ou /run/log/journal/ lorsqu’il est volatile, et journalctl -o json l’écrit sous forme d’un objet JSON par ligne. Le syslog classique texte reste dans /var/log/auth.log sur Debian et Ubuntu, ou /var/log/secure sur les hôtes de la famille RHEL. Les plateformes Cloud et SaaS exposent leurs traces d’audit sous forme de JSON via la console ou l’API.
Obtenir le fichier est la partie facile. La partie difficile commence quand un seul hôte vous remet 400 000 événements, l’horloge tourne, et les services juridiques veulent savoir qui voit les données brutes. C’est là que les meilleurs outils d’analyse de journaux basés sur l’IA se démarquent des simples consoles de recherche. Certains appliquent des modèles d’apprentissage automatique au-dessus d’un SIEM. D’autres, comme le LogTotal, comparent chaque événement à une bibliothèque de détection précompilée et renvoient des chaînes d’attaque corrélées, pas une liste de correspondances.
Ce guide couvre ce que font les outils d’analyse de journaux, quelles fonctionnalités sont importantes lors de la réponse à un incident, dix outils qui valent la peine d’être connus en 2026, et un workflow étape par étape pour exporter les journaux Windows et Linux et les analyser avec LogTotal. Il se termine par des étapes de dépannage et des réponses aux questions courantes.
Qu’est-ce que les outils d’analyse de journaux ?
Les outils d’analyse de journaux transforment les enregistrements générés par machine en réponses : qui a agi, sur quel actif, quand, d’où, et par quel mécanisme. Ils analysent les formats bruts, normalisent les champs, appliquent une logique de détection, et lient les événements connexes afin qu’un analyste puisse reconstruire une intrusion au lieu de la lire ligne par ligne.
La catégorie est plus large que le SIEM. Dans un SOC typique, quatre types d’outils partagent le travail :
- SIEM et plateformes d’analyse de sécurité (Splunk, Microsoft Sentinel, Google SecOps, Elastic) centralisent l’ingestion, exécutent des détections programmées et en flux, et gèrent le triage et la gestion des cas.
- Pipelines de données de sécurité (Cribl Stream, Fluent Bit, Vector) dirigent, filtrent, et enrichissent les événements avant le stockage, ce qui contrôle le coût d’ingestion et normalise les schémas tels que ECS ou OCSF.
- Utilitaires DFIR (Hayabusa, Chainsaw, EvtxECmd) traitent les artefacts collectés hors ligne, généralement EVTX, et produisent des chronologies pour un seul hôte.
- Analyseurs de captures instantanées comme LogTotal prennent un ensemble de journaux exporté et restituent une enquête complète sans travail d’intégration ni d’onboarding.
L’analyse des journaux est également distincte de la gestion des journaux. La gestion est de la plomberie : collecte, rétention, contrôle d’accès, intégrité. L’analyse est l’interprétation. Une équipe peut exécuter un pipeline propre avec 12 mois de rétention et encore manquer une campagne de Kerberoasting si rien n’évalue les événements 4769 avec un type de chiffrement RC4 0x17.
Alors, qu’est-ce qui sépare les meilleurs outils d’analyse de journaux du reste ? Trois choses : combien de formats ils lisent sans conversion, combien de contenus de détection maintenus ils appliquent, et s’ils corrèlent des hits isolés en un récit d’attaque. La vitesse et les contrôles de gestion des données décident du reste, surtout lorsque les journaux proviennent d’un hôte qui n’a jamais été intégré au SIEM.
Quelles fonctionnalités importent, et que vous apportent-elles ?
Les listes de fonctionnalités sur les pages des fournisseurs se ressemblent. Lors d’un incident, sept capacités font la plupart du travail.
- Analyseurs natifs. EVTX est un format binaire segmenté avec des charges utiles d’événements en XML, donc grep est inutile contre lui. Un outil doit lire EVTX, JSON/NDJSON, syslog (RFC 3164 et RFC 5424), et CEF sans script de conversion.
- Normalisation des champs. Une IP source doit être le même champ qu’elle provienne d’un pare-feu, d’un IdP, ou de l’ID d’événement Sysmon 3. Des schémas tels que ECS et OCSF font fonctionner une détection avec plusieurs fournisseurs.
- Contenu de détection maintenu. Règles Sigma, analyses des fournisseurs, et correspondances avec le renseignement sur les menaces. Le volume compte, mais aussi la cadence de mise à jour : une bibliothèque qui retarde de plusieurs mois les TTP émergents donne un faux confort.
- Corrélation. Les hits atomiques ne prouvent que rarement la compromission. La séquence et la corrélation de niveau supérieur lient une rafale 4625, une connexion de type 10 4624, et une installation de service 7045 en une chaîne mappée à MITRE ATT&CK.
- Temps jusqu’au résultat. Une recherche programmée de 15 minutes sur un backlog indexé est bien pour la surveillance. Pour le triage d’un ensemble de journaux exporté, les minutes sont le budget.
- Contrôles de gestion des données. Les journaux transportent des noms d’utilisateur, des noms d’hôte, des jetons porteurs, et des cookies de session. La pseudonymisation clé avant le téléversement maintient la corrélation intacte et garde le DPO à bord.
- Exportation et accès à l’API. Les conclusions doivent quitter l’outil sous forme de JSON ou CSV pour la gestion des cas, la billetterie, et les rapports.
Les avantages en découlent directement. Un balayage plus rapide réduit le temps de confinement. Les conclusions corrélées réduisent la file d’alertes qu’un analyste doit lire. Les preuves au niveau des événements soutiennent les rapports réglementaires, tels que la révision des journaux d’audit sous la norme PCI DSS v4.0 Exigence 10. La télémétrie réelle alimente également l’ingénierie de détection, car les règles sont testées contre ce que les attaquants laissent réellement derrière eux.
10 outils d’analyse de journaux que vous devriez connaître
Aucun produit unique ne couvre chaque étape. La liste ci-dessous mélange des plateformes pour une surveillance continue avec des outils conçus pour les premières heures d’un incident.
- LogTotal (SOC Prime). Un analyseur gratuit basé sur navigateur pour les ensembles de journaux exportés. Il assainit les journaux localement, détecte automatiquement EVTX, JSON/NDJSON, et syslog, compare les événements à environ 1 000 000 règles de détection et 13 000 labels de menace, et retourne des chaînes d’attaque classées mappées à MITRE ATT&CK. Il gère jusqu’à 1,7 million d’événements en moins d’une minute.
- Splunk Enterprise Security. Le SIEM de référence pour de nombreux grands SOCs. SPL est expressif, l’alerte basée sur les risques réduit le bruit, et l’écosystème d’applications couvre la plupart des sources.
- Microsoft Sentinel. SIEM natif pour le cloud sur les espaces de travail Log Analytics, interrogé avec KQL. Des connecteurs natifs pour Entra ID, Microsoft 365, et Defender en font le choix par défaut pour les environnements fortement orientés Microsoft.
- Opérations de sécurité Google. Anciennement Chronicle. Il normalise les données dans le Modèle de Données Unifié (UDM), détecte avec YARA-L, et recherche rapidement dans de grandes fenêtres de rétention.
- Sécurité Elastic. Construit sur Elasticsearch avec le schéma commun Elastic. Les requêtes de séquences EQL conviennent aux comportements en plusieurs étapes, et les règles de détection sont publiques sur GitHub.
- Sumo Logic. Une plateforme d’analyse des journaux SaaS avec un niveau Cloud SIEM.
- Graylog. Disponible en éditions open source et commerciales. Les entrées GELF, les pipelines de traitement, et le routage de flux en font un choix pratique pour les équipes de taille moyenne qui souhaitent gérer leur propre stack.
- Wazuh. Un XDR et SIEM open source avec des agents pour Windows, Linux, et macOS. Il fournit des décodeurs et des règles pour la surveillance de l’intégrité des fichiers, la détection des vulnérabilités, et la cartographie de conformité.
- Hayabusa. Générateur de chronologie EVTX basé sur Rust de Yamato Security. Il applique des règles Sigma et ses propres règles aux journaux d’événements hors ligne et écrit des chronologies CSV ou JSONL pour le triage à hôte unique.
- Chainsaw. Outil Rust de WithSecure pour la chasse rapide à travers des fichiers EVTX en utilisant Sigma et la logique de détection intégrée. Il est rapide, scriptable, et laisse la corrélation à l’analyste.
Le schéma est clair. Les SIEM brillent une fois que les données sont intégrées. Les utilitaires DFIR sont rapides mais utilisent des ensembles de règles plus petits et laissent la corrélation à l’analyste. LogTotal comble le fossé entre eux : la profondeur complète de détection appliquée aux journaux qui n’ont jamais rejoint le SIEM.
Analyse des journaux avec LogTotal : de l’exportation à la chaîne d’attaque
LogTotal est la réponse de SOC Prime à l’analyse des journaux au moment de l’incident. Il a été lancé en aperçu public le 26 août 2026 et atteint la version générale le 15 octobre 2026. Il est gratuit et ne nécessite aucune intégration ou accès à l’API. Le workflow ci-dessous emmène un hôte Windows ou Linux des journaux bruts à des résultats corrélés.
Étape 1 : Exporter les journaux
Windows (Visualiseur d’événements). Ouvrez eventvwr.msc, développez Journaux Windows, cliquez avec le bouton droit sur Sécurité, et sélectionnez Enregistrer tous les événements sous…. Gardez le type de fichier en .evtx. Pour Sysmon, accédez à Journaux d’applications et de services > Microsoft > Windows > Sysmon > Operational et répétez.
Windows (ligne de commande). Depuis une invite élevée :
wevtutil epl Security C:IRSecurity.evtx
wevtutil epl « Microsoft-Windows-Sysmon/Operational » C:IRSysmon.evtx
wevtutil epl « Microsoft-Windows-PowerShell/Operational » C:IRPowerShell.evtx
Pour limiter l’exportation aux dernières 72 heures, ajoutez un filtre XPath : /q: »*[System[TimeCreated[timediff(@SystemTime) <= 259200000]]] ». Ajoutez /ow:true pour écraser un fichier existant. Exécutez wevtutil el pour lister les noms exacts des canaux.
Linux (journal systemd). Exécutez en tant que root ou en tant que membre du groupe systemd-journal ou adm :
journalctl –since « 2026-10-17 00:00 » –until « 2026-10-20 00:00 » -o json > host-journal.json
La sortie est en NDJSON, une entrée par ligne. Pour les hôtes utilisant le syslog texte, copiez /var/log/auth.log (Debian, Ubuntu) ou /var/log/secure (RHEL, Rocky, Alma).
Étape 2 : Assainir
Ouvrez logtotal.com et chargez les fichiers. L’assainissement s’exécute dans le navigateur avant que tout ne soit téléversé. Le désinfectant open source remplace les secrets, les adresses IP, les noms d’hôte, les noms d’utilisateur, et d’autres identificateurs par des jetons HMAC stables tels que <USER:…> ou <IP:…>. Le même utilisateur sur trois hôtes reste une entité après censure. Examinez l’aperçu, téléchargez la copie assainie pour votre dossier de cas, et conservez la clé.
Pour les environnements isolés ou strictement contrôlés, exécutez la même bibliothèque localement (Node.js 20 ou supérieur) :
npx logtotal-sanitize ./auth.log -o ./auth.sanitized.log –report ./report.json –print-key
npx logtotal-sanitize ./secure.log -o ./secure.sanitized.log –key « $KEY »
La réutilisation de la clé garde les jetons cohérents entre les fichiers.
Étape 3 : Analyser et lire les résultats
Après avoir confirmé l’aperçu assaini, LogTotal l’exécute sur une instance jetable et immuable qui est supprimée ensuite. Rien n’est stocké, et les données ne sont pas utilisées pour l’entraînement. Les résultats reviennent sous forme de chaînes d’attaque classées mappées aux techniques ATT&CK, avec les événements sous-jacents attachés. Des drapeaux mettent en évidence les techniques de furtivité et les pics d’activité à l’air bénin, un schéma typique d’intrusions assistées par l’IA. Mettez en correspondance les jetons avec des identités réelles en interne en utilisant votre clé.
Pourquoi elle se démarque
- Profondeur : environ 1 000 000 de règles de détection et 13 000 labels de menace, corrélées avec les règles Sigma d’Ordre Supérieur et l’IA agentique.
- Vitesse : jusqu’à 1,7 million d’événements en moins d’une minute. C’est environ 100 fois le lot de journaux de 17 000 événements de Hugging Face que les modèles de pointe ont refusé de traiter en juillet 2026.
- Confidentialité : assainissement local, une clé que vous détenez, pas de rétention.
- Chemin vers une couverture continue : le même moteur fonctionne dans Prime Hunt à travers SIEM, EDR, et les lacs de données, et dans Prime Detect sur le flux de données avant le SIEM.
Dépannage
| Symptôme | Cause | Solution |
| wevtutil epl Security … échoue avec « Accès refusé » | La commande n’a pas été exécutée à partir d’une invite élevée | Réexécutez à partir d’une invite élevée avec un compte administrateur local |
| Le .evtx exporté ouvert sur une station d’analyse indique « La description pour l’ID d’événement … ne peut être trouvée » | Les fichiers de messages de l’éditeur d’événements ne sont pas installés sur cette machine | Exécutez wevtutil al C:IRSecurity.evtx sur l’hôte source pour archiver les métadonnées locales avec le journal. Les champs de données brutes des événements restent intacts dans les deux cas |
| journalctl ne renvoie que les entrées de votre propre utilisateur, ou aucune entrée avant le dernier redémarrage | Membre de groupe manquant, ou le journal est volatile (/run/log/journal) | Utilisez sudo ou rejoignez systemd-journal. Définissez Storage=persistent dans /etc/systemd/journald.conf pour la collecte future |
| Le même utilisateur apparaît sous différents jetons dans deux fichiers assainis | Chaque fichier a été assaini avec une clé HMAC différente | Réutilisez une clé : –key « $KEY » ou –key-file dans le CLI |
FAQ
LogTotal est-il gratuit ?
Oui. L’analyse sur logtotal.com est gratuite, et le désinfectant est open source sous Apache-2.0.
SOC Prime garde-t-il mes journaux ?
Non. Les journaux sont assainis dans votre navigateur, chaque analyse est effectuée sur une instance jetable qui est supprimée ensuite, rien n’est stocké, et les données ne sont pas utilisées pour l’entraînement des modèles.
Quels formats de journaux puis-je téléverser ?
LogTotal détecte automatiquement EVTX, JSON/NDJSON, et syslog. Exportez les journaux Windows en .evtx et les journaux Linux avec journalctl -o json.
Puis-je assainir des journaux sans rien envoyer sur internet ?
Oui. Installez @socprime/logtotal-sanitizer avec npm et exécutez-le dans votre propre infrastructure, y compris les réseaux isolés. Téléversez uniquement la sortie assainie.
En quoi LogTotal est-il différent de mon SIEM ?
Un SIEM analyse les données déjà intégrées, en continu. LogTotal analyse un instantané que vous exportez, en moins d’une minute, sans intégration. Pour une couverture continue avec le même moteur de détection, utilisez Prime Hunt ou Prime Detect.