Doogree
Défense · NDR

Détecter le déplacement latéral avant qu'il n'atteigne les joyaux de la couronne

06/07/2026 · ~6 min de lecture
NDRDéplacement latéralT1021ADN de connexion

Les attaquants n'atterrissent presque jamais directement sur les joyaux de la couronne. Ils prennent pied sur une machine — un poste de travail utilisateur ordinaire, sans importance — et de là, ils rampent latéralement, de machine en machine, jusqu'à atteindre le serveur de fichiers ou le contrôleur de domaine. L'antivirus classique et l'EDR regardent un hôte unique ; ils manquent précisément ce qui se passe entre les hôtes. Le NDR, lui, regarde le trafic lui-même.

Pourquoi l'est-ouest est l'angle mort

Une attaque typique est une chaîne : accès initial (hameçonnage, identifiant volé) → déplacement latéral (est-ouest, de machine en machine) → impact (chiffrement par rançongiciel, vol de données). Un outil de sécurité qui regarde une seule machine voit un processus s'exécuter et un port en écoute — mais il ne voit pas que cette machine parle soudain en SMB à dix autres machines auxquelles elle n'avait jamais parlé auparavant. C'est la signature du déplacement latéral, et elle n'est visible que lorsqu'on regarde le réseau interne comme un système.

Pourquoi c'est crucial pour une petite entreprise : le déplacement latéral est le milieu de l'attaque — la partie entre la prise de pied et le chiffrement. C'est exactement la fenêtre où vous avez encore le temps d'arrêter le rançongiciel avant qu'il ne touche vos fichiers.

Comment nous détectons le déplacement latéral

Doogree historise les connexions vers les pairs internes de chaque machine — l'IP, le port et le processus qui a initié la connexion. Pour chaque connexion, nous classons le port en une technique ATT&CK : SMB → T1021.002, RDP → T1021.001, WinRM → T1021.006, SSH → T1021.004, VNC → T1021.005. Après la fenêtre d'apprentissage, un tout premier pair interne sur un port d'administration/de contrôle à distance est un candidat au déplacement latéral — et il ressort comme une anomalie de l'ADN comportemental, étiquetée avec la technique précise.

L'identité de connexion comme ADN (serveurs)

Le revers de la même médaille est qui se connecte, et d'où. L'agent serveur remonte les comptes humains et les connexions réussies depuis auth.log — le compte, l'adresse IP source, et s'il s'agit d'une connexion root/administrateur. Le cloud construit une base de référence des comptes connus et des sources de connexion connues. Un nouveau compte, ou une connexion administrateur/root depuis une IP jamais vue, est une anomalie critique — un candidat au détournement de compte — projetée sur T1078 (Valid Accounts) et T1098.

Orienté sans agent. La collecte de l'identité de connexion repose sur un collecteur côté serveur, et non sur un agent lourd installé sur chaque machine. C'est l'approche « sans agent d'abord » : le poids est dans le cloud, l'empreinte sur le terminal est minimale et non perturbatrice.

Tout se replie dans une seule histoire d'attaque

Ces deux capacités ne vivent pas isolément. Elles se replient dans le moteur de corrélation SIEM en tant qu'étapes de la kill-chain : le déplacement latéral est l'étape latéral, et l'anomalie d'identité de connexion est l'étape accès. Au lieu de deux alertes isolées, vous obtenez un incident unique qui raconte une histoire : quelqu'un s'est connecté depuis une source étrangère, puis a rampé latéralement via WinRM — avec escalade automatique de la gravité.

Pourquoi cela surpasse l'EDR mono-hôte : l'EDR voit un processus ; le NDR voit le trafic. Combiner l'étiquetage port→technique avec une base de référence des pairs internes et des sources de connexion vous donne ce qui manque à la plupart des petites entreprises — la visibilité sur le milieu de l'attaque, au point où vous pouvez encore l'arrêter. Le tout sur le même agent et le même collecteur déjà installés.

← Retour au blog · Comment ça marche →