Comment detecter une intrusion dans votre reseau d'entreprise en 8 etapes

En 2026, le temps moyen de detection d'une intrusion dans un systeme d'information francais est de 207 jours selon le dernier rapport de l'ANSSI. Plus de six mois pendant lesquels un attaquant peut explorer votre reseau, exfiltrer vos donnees et preparer une attaque devastatrice — ransomware, sabotage ou espionnage industriel. Ce delai est inacceptable, et pourtant il reflete une realite : la majorite des entreprises francaises ne disposent pas d'un processus structure de detection d'intrusion.

Ce guide pratique vous presente les 8 etapes essentielles pour detecter une intrusion dans votre reseau d'entreprise. Chaque etape est accompagnee de techniques concretes, d'outils recommandes et de commandes que vos equipes peuvent implementer des aujourd'hui. L'objectif n'est pas de remplacer un SOC professionnel, mais de vous donner les cles pour structurer votre approche de detection et reduire significativement votre temps de decouverte.

— Etape 1 : Surveiller les connexions reseau anormales

La premiere etape de toute strategie de detection d'intrusion consiste a etablir une baseline de votre trafic reseau normal, puis a identifier les ecarts par rapport a cette reference. Sans baseline, il est impossible de distinguer un comportement anormal d'un comportement simplement inhabituel. C'est la difference entre un systeme d'alarme calibre et un detecteur de fumee qui sonne a chaque fois qu'on fait cuire un steak.

Pour construire votre baseline, collectez pendant au minimum 30 jours les metriques suivantes : le volume de trafic par segment reseau et par heure, les flux de communication entre sous-reseaux (qui parle a qui et sur quels ports), les connexions sortantes vers des destinations geographiques inhabituelles, et les protocoles utilises. Des outils comme Zeek (anciennement Bro), NetFlow/IPFIX ou ntopng permettent de collecter ces donnees sans impact significatif sur les performances reseau.

Une fois la baseline etablie, configurez des alertes sur les ecarts statistiques significatifs. Les indicateurs les plus revelateurs d'une intrusion incluent : des connexions sortantes vers des pays avec lesquels votre entreprise n'a pas de relations commerciales (attention : les attaquants sophistiques utilisent des relais dans des pays "normaux"), une augmentation soudaine du trafic DNS (indicateur potentiel de DNS tunneling ou de communication avec un serveur C2), des connexions sur des ports non standard (par exemple, du trafic HTTPS sur le port 8443 ou 4443), et des communications entre des segments reseau qui ne devraient normalement pas interagir (un poste de travail comptabilite qui communique directement avec un serveur de production).

— Etape 2 : Analyser les logs d'authentification

Les logs d'authentification sont une mine d'or pour la detection d'intrusion. Un attaquant qui a penetre votre reseau devra tot ou tard s'authentifier sur des systemes internes, et ces tentatives laissent des traces. Le probleme est que la plupart des entreprises collectent ces logs mais ne les analysent pas systematiquement — elles attendent qu'un incident soit detecte par un autre moyen pour aller fouiller dans les logs a posteriori.

Sur un environnement Windows/Active Directory, les evenements critiques a surveiller incluent : Event ID 4625 (echec de connexion) — recherchez des series de plus de 5 echecs en moins de 10 minutes sur le meme compte, signe d'une attaque par force brute ; Event ID 4768 (demande de ticket Kerberos TGT) et Event ID 4769 (demande de ticket de service Kerberos) — des patterns anormaux dans ces evenements peuvent indiquer une attaque Kerberoasting ; Event ID 4720 (creation de compte utilisateur) en dehors des processus RH standards ; et Event ID 4672 (attribution de privileges speciaux) sur des comptes qui ne devraient pas en avoir.

Portez une attention particuliere aux connexions en dehors des horaires de bureau. Si un compte du service comptabilite se connecte a 3h du matin un samedi depuis une adresse IP situee au Bresil, c'est probablement un indicateur de compromission. Croisez les heures de connexion avec les badgeages physiques (si disponibles) et les connexions VPN pour identifier les incoherences. Sur les systemes Linux, les fichiers /var/log/auth.log et /var/log/secure contiennent les memes informations : tentatives SSH echouees, escalade de privileges via sudo, et connexions PAM.

— Etape 3 : Detecter les mouvements lateraux

Le mouvement lateral est la phase ou un attaquant, apres avoir compromis un premier poste, se deplace dans votre reseau pour atteindre ses objectifs — un controleur de domaine, un serveur de fichiers sensibles ou un systeme de sauvegarde. C'est souvent la phase la plus longue et la plus discrete d'une intrusion, et c'est aussi celle ou la detection est la plus difficile car l'attaquant utilise des outils et des protocoles legitimes.

Les deux techniques de mouvement lateral les plus courantes en 2026 restent le Pass-the-Hash (PtH) et le Kerberoasting. Le Pass-the-Hash consiste a reutiliser le hash NTLM d'un mot de passe intercepte en memoire (via Mimikatz ou des techniques similaires) pour s'authentifier sur d'autres machines sans connaitre le mot de passe en clair. Pour le detecter, recherchez dans vos logs les connexions NTLM de type 3 (reseau) provenant de machines qui n'hebergent pas de services partages — un poste de travail qui s'authentifie en NTLM sur 15 serveurs differents en 10 minutes est hautement suspect.

Le Kerberoasting cible les comptes de service Active Directory qui utilisent des SPN (Service Principal Names). L'attaquant demande un ticket de service Kerberos pour ces comptes, puis tente de casser le hash hors ligne. Pour le detecter, surveillez les Event ID 4769 avec un type de chiffrement faible (RC4, code 0x17) et un volume anormal de demandes de tickets de service depuis un meme compte utilisateur. L'outil BloodHound peut etre utilise de maniere defensive pour identifier les chemins d'attaque potentiels dans votre Active Directory avant que les attaquants ne le fassent.

— Etape 4 : Identifier l'exfiltration de donnees

L'exfiltration de donnees est souvent l'objectif final de l'attaquant, et c'est aussi le moment ou l'intrusion cause des dommages irreversibles. Une fois les donnees sorties de votre reseau, il n'y a plus de retour en arriere. La detection de l'exfiltration repose sur deux approches complementaires : la detection par volume et la detection par protocole.

Le DNS tunneling est la technique d'exfiltration la plus insidieuse car le trafic DNS est rarement filtre ou inspecte en profondeur. L'attaquant encode les donnees a exfiltrer dans les requetes DNS (sous-domaines, enregistrements TXT) vers un serveur DNS qu'il controle. Les indicateurs de DNS tunneling incluent : des requetes DNS avec des sous-domaines anormalement longs (plus de 50 caracteres), un volume de requetes DNS par poste superieur a la normale (plus de 1 000 requetes/heure), des requetes vers des domaines enregistres recemment (moins de 30 jours), et un ratio requetes TXT / requetes totales anormalement eleve.

L'exfiltration par volumes inhabituels est plus simple a detecter mais reste souvent ignoree. Etablissez des seuils d'alerte sur le volume de donnees sortantes par utilisateur et par jour. Un compte qui uploade soudainement 500 Mo vers un service cloud personnel ou qui envoie 200 emails avec pieces jointes en une heure merite une investigation immediate. Les outils de DLP (Data Loss Prevention) comme Suricata (avec les regles ET Open) ou des CASB peuvent automatiser cette surveillance.

— Etape 5 : Inspecter les processus suspects

Les attaquants modernes n'installent plus systematiquement des malwares traditionnels detectables par un antivirus. Ils privilegient les techniques dites Living-off-the-Land (LOLBins) : l'utilisation de programmes Windows legitimes pour executer du code malveillant, echapper aux controles de securite et maintenir leur persistence. Cette approche rend la detection infiniment plus complexe car les processus utilises sont eux-memes des composants systeme signes par Microsoft.

Les LOLBins les plus frequemment detournes en 2026 incluent : powershell.exe avec des scripts encodes en Base64 (parametre -EncodedCommand ou -ec), mshta.exe executant des HTA malveillantes depuis une URL distante, certutil.exe utilise pour telecharger des fichiers (certutil -urlcache -split -f), rundll32.exe chargeant des DLL depuis des emplacements non standards, et wmic.exe pour l'execution de commandes a distance. Pour detecter ces usages malveillants, Sysmon (System Monitor de Microsoft, gratuit) est indispensable : configurez-le pour journaliser les creations de processus (Event ID 1), les connexions reseau (Event ID 3), les chargements de DLL (Event ID 7) et les acces en memoire a lsass.exe (Event ID 10, indicateur de Mimikatz).

Surveillez egalement les scripts PowerShell avec le Script Block Logging (Event ID 4104) et le Module Logging. Ces fonctionnalites, activables par GPO, enregistrent le contenu integral de chaque commande PowerShell executee, meme si elle est obfusquee. Recherchez les commandes contenant Invoke-Expression, IEX, Net.WebClient, DownloadString ou des chaines Base64 de plus de 100 caracteres.

— Etape 6 : Verifier l'integrite des fichiers critiques

La surveillance de l'integrite des fichiers (FIM — File Integrity Monitoring) est une couche de detection souvent negligee, pourtant essentielle. L'idee est simple : si un fichier systeme critique, un fichier de configuration ou un binaire est modifie en dehors d'un processus de maintenance planifie, c'est potentiellement le signe d'une compromission. Un attaquant qui modifie C:\Windows\System32\drivers\etc\hosts pour rediriger du trafic, qui ajoute une DLL dans un repertoire systeme, ou qui modifie un script de demarrage laisse des traces que le FIM peut capturer.

Les fichiers et repertoires a surveiller en priorite comprennent : les binaires systeme Windows (C:\Windows\System32\), les fichiers de configuration reseau (hosts, configurations DNS), les scripts de demarrage et de connexion (Startup, logon scripts dans les GPO), les taches planifiees (C:\Windows\System32\Tasks\), et les fichiers web des applications critiques (pour detecter les webshells). Sur Linux, surveillez /etc/passwd, /etc/shadow, /etc/sudoers, les fichiers crontab, et /root/.ssh/authorized_keys.

Les outils de reference pour le FIM incluent Wazuh (open-source, combine SIEM + FIM + HIDS), OSSEC (le predecesseur de Wazuh, toujours maintenu) et Tripwire (commercial, reference historique). L'essentiel est de configurer des alertes en temps reel pour les modifications de fichiers critiques, et non de se contenter de rapports quotidiens — un attaquant qui implante une backdoor a 2h du matin ne doit pas attendre le rapport de 8h pour etre detecte.

— Etape 7 : Correler les alertes avec la threat intelligence

Les etapes precedentes generent un volume considerable d'alertes. Sans correlation et sans contexte, votre equipe de securite sera noyee sous les faux positifs et passera a cote des vrais indicateurs de compromission. C'est ici qu'intervient la threat intelligence et le cadre MITRE ATT&CK — le referentiel mondial des tactiques, techniques et procedures (TTP) utilisees par les attaquants.

Le mapping MITRE ATT&CK consiste a associer chaque alerte ou indicateur detecte a une technique specifique du framework. Par exemple : une serie d'Event ID 4625 suivie d'un Event ID 4624 reussi correspond a la technique T1110 — Brute Force ; des connexions NTLM anormales correspondent a T1550.002 — Pass the Hash ; du DNS tunneling correspond a T1071.004 — Application Layer Protocol: DNS. En correlant plusieurs techniques observees sur une meme timeline, vous pouvez reconstituer la kill chain de l'attaquant et predire ses prochaines actions.

Pour operationnaliser la threat intelligence, utilisez des plateformes comme MISP (open-source, partage d'IoC entre organisations), OpenCTI (open-source, plateforme CTI complete avec integration MITRE ATT&CK) ou les feeds commerciaux d'AlienVault OTX, Recorded Future ou Mandiant Advantage. L'objectif est d'enrichir automatiquement vos alertes SIEM avec du contexte : cette IP qui se connecte a votre serveur web est-elle connue pour heberger un C2 ? Ce hash de fichier detecte par votre EDR est-il associe a un groupe APT connu ? Cette technique correspond-elle au modus operandi d'un groupe qui cible votre secteur d'activite ?

— Etape 8 : Documenter et declencher la reponse a incident

La detection n'a de valeur que si elle debouche sur une reponse structuree et documentee. Trop d'equipes de securite detectent une intrusion puis improvisent leur reponse, perdant un temps precieux et risquant de detruire des preuves numeriques essentielles pour l'investigation forensique et les eventuelles poursuites judiciaires. C'est pourquoi la huitieme et derniere etape de notre guide est consacree a la documentation et au declenchement du processus de reponse a incident.

L'ANSSI publie un guide de reference pour la gestion des incidents de securite qui definit un processus en 6 phases : preparation, identification, confinement, eradication, recuperation et retour d'experience. Chaque entreprise devrait adapter ce cadre a sa propre realite operationnelle sous forme de playbooks — des procedures pas-a-pas pour les scenarios d'incident les plus courants : ransomware, compromission de compte privilegie, exfiltration de donnees, compromission d'un serveur expose sur Internet.

Au moment de la detection, les actions immediates sont : 1) Documenter l'heure exacte de detection, les indicateurs observes et les systemes potentiellement affectes dans un journal d'incident horodate ; 2) Ne pas eteindre les machines suspectes (vous perdriez le contenu de la RAM qui peut contenir des preuves critiques) mais les isoler du reseau ; 3) Preserver les logs en realisant des copies forensiques avant toute action de remediation ; 4) Notifier les parties prenantes selon la matrice d'escalade predenie : RSSI, direction generale, equipe juridique, et si necessaire le prestataire de reponse a incident et l'ANSSI.

Pour les entreprises soumises a NIS2, rappelons que la notification a l'autorite competente (ANSSI en France) est obligatoire dans un delai de 24 heures pour les incidents significatifs, avec un rapport complet sous 72 heures. Ne pas documenter rigoureusement chaque etape de votre reponse peut avoir des consequences reglementaires majeures en plus des dommages lies a l'incident lui-meme.

Conclusion : de la detection reactive a la detection proactive

Ces 8 etapes constituent le socle d'une capacite de detection d'intrusion structuree. En les implementant methodiquement — de la baseline reseau a la reponse a incident en passant par l'analyse des logs, la detection du mouvement lateral, la surveillance de l'exfiltration, l'inspection des processus, le controle d'integrite et la correlation threat intelligence — vous reduirez considerablement votre temps de detection et augmenterez vos chances d'intercepter un attaquant avant qu'il n'atteigne ses objectifs.

Mais soyons realistes : implementer et operer ces 8 etapes demande des competences, des outils et surtout du temps humain dedié 24/7. Pour les entreprises qui ne disposent pas d'un SOC interne, l'externalisation de la detection et de la reponse a un prestataire SOC manage est souvent la solution la plus pragmatique et la plus efficace. L'essentiel est de ne pas rester dans l'angle mort : 207 jours de presence non detectee, c'est 207 jours de trop.