Comment limiter le mouvement latéral après compromission

Comment limiter le mouvement latéral après compromission

Un accès initial à un poste n’est pas une victoire isolée : c’est souvent un point d’observation, puis un relais vers les identités, serveurs et données qui comptent vraiment. Le mouvement latéral se joue à l’intérieur du système d’information, là où le pare-feu périmétrique regarde poliment ailleurs.

Explication de la marmotte

Après être entré dans un bâtiment, un intrus cherche rarement à rester dans le hall : il repère les portes, les badges et les couloirs qui mènent aux pièces les plus intéressantes. Limiter ces passages réduit ce qu’il peut atteindre, même si la première porte a déjà été forcée.

→ Lire l’explication complète de la marmotte

Reconnaissance interne : annuaire, partages et chemins d’administration

Le mouvement latéral commence par une cartographie. Un poste compromis révèle les réseaux accessibles, les serveurs de noms, les partages, les sessions ouvertes, les groupes d’administration et les relations de confiance. Cette phase ne déclenche pas forcément une alerte : une requête vers l’annuaire ou un accès à un partage peut employer les mêmes protocoles qu’un administrateur légitime.

Dans un domaine Windows, Active Directory (AD) concentre une quantité déraisonnable d’informations : comptes de service, groupes privilégiés, postes joints, unités d’organisation, relations d’approbation entre domaines et délégations Kerberos. Une lecture non restreinte de ces objets transforme l’annuaire en plan du bâtiment avec les badges des gardiens annotés au stabilo.

Le protocole Lightweight Directory Access Protocol (LDAP) sert à interroger cet annuaire. Désactiver les connexions LDAP anonymes et les authentifications en clair ne suffit pas à arrêter un compte de domaine déjà compromis, mais empêche une reconnaissance sans identité et supprime des chemins inutilement larges. La page désactiver LDAP simple bind et anonymous bind traite ce durcissement précis.

Les partages Server Message Block (SMB) exposent une seconde carte : scripts de déploiement, répertoires d’installation, sauvegardes, exports et parfois mots de passe abandonnés dans un fichier de configuration. La permission de lecture sur un partage d’administration est déjà une capacité de reconnaissance. La permission d’écriture y devient une capacité d’exécution si un service, une tâche planifiée ou un agent de déploiement consomme le contenu.

Le contrôle à appliquer est brutal mais sain : séparer les comptes d’administration des comptes bureautiques, interdire les sessions administratives sur les postes utilisateurs, et retirer les droits locaux qui ne correspondent à aucun flux d’exploitation. Un groupe « administrateurs du domaine » utilisé pour installer une imprimante est une dette technique déguisée en raccourci.

Vol d’identifiants et réutilisation des authentifications

Une authentification réussie ne prouve pas que le mot de passe a été saisi. Elle peut résulter de la réutilisation d’un secret dérivé, d’un ticket ou d’une session déjà disponible sur le poste compromis.

Sur Windows, le processus Local Security Authority Subsystem Service (LSASS) maintient des informations nécessaires aux sessions authentifiées. L’extraction de secrets en mémoire vise notamment les hachages NTLM (NT LAN Manager), les tickets Kerberos et, selon la configuration, des identifiants réutilisables. Le chiffrement de disque ne protège pas une mémoire déjà active : il protège un support éteint ou volé. Les slogans de slide ont parfois des limites physiques assez vexantes.

Le pass-the-hash consiste à présenter un hachage NTLM capturé au lieu du mot de passe original, lorsque le service cible accepte NTLM. Le pass-the-ticket réemploie un ticket Kerberos valide afin d’obtenir des services accessibles par son détenteur. Ces techniques contournent la connaissance du mot de passe, pas les autorisations du compte : un compte peu privilégié reste peu privilégié, ce qui est précisément l’intérêt d’une séparation stricte des rôles.

Le durcissement repose sur plusieurs couches qui ne se remplacent pas :

• Désactiver NTLM lorsque les dépendances l’autorisent, ou au minimum journaliser son usage et interdire NTLM sur les chemins d’administration. Les vulnérabilités et limites de ce protocole sont détaillées dans NTLM, vulnérabilités et durcissement.
• Activer Credential Guard lorsque la version de Windows et le matériel le permettent. Cette fonction isole une partie des secrets, mais ne rend pas un poste administré par un attaquant magiquement fréquentable.
• Employer des comptes d’administration distincts, sans messagerie, navigation web ni accès aux postes bureautiques.
• Réduire la durée de vie des tickets et supprimer les délégations Kerberos non contraintes. Une délégation non contrainte permet à un système de recevoir des éléments d’authentification transférables : c’est une frontière de confiance, pas un paramètre décoratif.
• Administrer avec des postes dédiés et des accès conditionnés par l’état du terminal, pas seulement par le mot de passe et un second facteur.

Les relations d’approbation entre domaines ou forêts méritent le même traitement. Une approbation ouvre un chemin d’authentification, mais ne devrait jamais devenir une permission implicite d’administration. Vérifier les groupes imbriqués, les identités externes et le filtrage des identifiants de sécurité sur chaque frontière. Une forêt enfant compromise ne doit pas devenir un ascenseur express vers la forêt racine.

Segmentation réseau et micro-segmentation : réduire les chemins disponibles

Le compromis central est net : la segmentation réduit le rayon d’action d’une compromission, mais impose de connaître et maintenir les flux réels. Le prix est opérationnel, avec des règles à versionner, des dépendances à documenter et des exceptions à refuser. Le gain est stratégique : un poste utilisateur compromis ne peut plus balayer librement les serveurs, l’administration et les sauvegardes.

La recommandation est de partir d’un refus par défaut entre zones, puis d’autoriser des flux nommés et justifiés. Au minimum, isoler :

• les postes utilisateurs ;
• les serveurs applicatifs ;
• les bases de données ;
• les services d’identité ;
• les postes et réseaux d’administration ;
• les sauvegardes et leur plan de contrôle ;
• les équipements réseau et les hyperviseurs.

Une règle autorisant les postes utilisateurs vers tous les serveurs sur SMB, Remote Desktop Protocol (RDP) ou Windows Remote Management (WinRM) annule pratiquement cette séparation. Les flux d’administration doivent partir d’un réseau dédié vers les cibles, jamais des postes utilisateurs vers l’ensemble du parc. Les serveurs doivent aussi être segmentés entre eux : un serveur web n’a aucune raison structurelle de joindre tous les serveurs de fichiers.

La micro-segmentation applique cette logique au niveau de la charge de travail ou de l’identité du service, plutôt qu’au seul sous-réseau. Elle réduit les mouvements entre machines d’une même zone, mais dépend d’un inventaire de flux fiable. Sans inventaire, la micro-segmentation devient une collection de règles « any-any temporairement », cette espèce invasive qui survit mieux que les plantes d’intérieur.

Le filtrage réseau ne garantit pas l’intégrité d’un système autorisé à communiquer. Un serveur applicatif compromis peut toujours atteindre sa base de données si le flux est nécessaire. Il faut donc compléter par des identités de service dédiées, des privilèges minimaux, un chiffrement Transport Layer Security (TLS) avec authentification mutuelle lorsque possible, et une journalisation exploitable côté serveur.

Exemple : bloquer les flux latéraux depuis un réseau utilisateur

L’exemple suivant applique un refus des protocoles d’administration Windows depuis 10.40.10.0/24, réseau de postes utilisateurs, vers 10.40.0.0/16, réseau de serveurs. Les flux vers un bastion d’administration restent autorisés. Tester d’abord en environnement représentatif : bloquer une console de supervision cachée dans un script de 2014 reste un classique sans gloire.

# nftables : table et chaîne de filtrage pour les flux sortants
nft add table inet segmentation
nft 'add chain inet segmentation forward { type filter hook forward priority filter; policy accept; }'

# Autoriser les postes utilisateurs à atteindre le bastion d'administration en HTTPS
nft add rule inet segmentation forward ip saddr 10.40.10.0/24 ip daddr 10.40.250.10 tcp dport 443 accept

# Bloquer SMB, RDP et WinRM des postes utilisateurs vers les serveurs
nft add rule inet segmentation forward ip saddr 10.40.10.0/24 ip daddr 10.40.0.0/16 tcp dport { 445, 3389, 5985, 5986 } counter drop

# Journaliser les refus avant de les analyser dans la supervision
nft add rule inet segmentation forward ip saddr 10.40.10.0/24 ip daddr 10.40.0.0/16 tcp dport { 445, 3389, 5985, 5986 } log prefix "LATERAL_DENY "

L’ordre des règles compte : une autorisation large placée avant le refus rend la politique inopérante. Les règles doivent être testées avec les flux applicatifs, les agents de sauvegarde, les outils de déploiement et les scénarios de reprise. Une sauvegarde inaccessible le jour d’un incident n’est pas une sauvegarde, c’est une promesse avec un costume.

Détection des authentifications et de l’énumération anormales

Les défenses périmétriques détectent mal une connexion interne autorisée. La détection du mouvement latéral nécessite des journaux d’identité, de postes, de serveurs et de réseau corrélés dans un SIEM (Security Information and Event Management).

Sur Windows, surveiller au minimum les événements d’ouverture de session 4624, de validation NTLM 4776, de demande de ticket Kerberos 4768 et 4769, ainsi que les accès aux partages 5140. Une authentification de type réseau depuis un poste utilisateur vers un serveur d’administration, surtout avec un compte privilégié, est un signal à haute valeur. Un compte de service qui demande soudain des tickets pour des dizaines d’hôtes constitue un autre signal, même si chaque demande prise isolément est valide.

L’énumération anormale de l’annuaire se détecte par le volume, la diversité des objets lus et l’origine de la requête. Une station bureautique qui interroge massivement utilisateurs, groupes, ordinateurs et relations d’approbation sort de son profil attendu. Les journaux LDAP, les événements d’accès aux objets lorsque l’audit est configuré, et la télémétrie d’un EDR (Endpoint Detection and Response) permettent de relier la requête au processus qui l’a lancée.

La détection doit comparer les communications observées à une base de référence : quel poste parle habituellement à quel serveur, avec quel compte, sur quel port et à quel horaire. Sans cette référence, une alerte « connexion interne » produit surtout du bruit, ressource déjà abondante dans l’univers connu.

La réponse exige une capacité de confinement rapide : isoler le terminal, désactiver ou réinitialiser les comptes concernés, purger les sessions lorsque l’environnement le permet, puis vérifier les hôtes atteints. Changer un mot de passe sans invalider les sessions ni examiner les délégations laisse parfois l’accès en place. La rotation doit inclure les comptes de service, les secrets d’automatisation et les comptes locaux administrateurs, avec sauvegarde chiffrée des configurations de sécurité et procédure de restauration testée.

🐝 Ce qui arrive si on s’en passe

Sans segmentation ni détection interne, la conséquence la plus coûteuse arrive après l’incident : il devient impossible de délimiter le périmètre compromis. Faute de journaux d’authentification corrélés et de frontières réseau, tout hôte joignable depuis le poste initial doit être considéré comme suspect, ce qui transforme le nettoyage ciblé d’une machine en reconstruction complète du domaine, y compris la rotation de l’ensemble des secrets de service. La durée d’investigation s’allonge, les obligations de notification portent sur un périmètre non chiffrable, et les sauvegardes atteignables depuis la même zone perdent leur valeur de point de reprise fiable. S’ajoute une perte de traçabilité durable : sans base de référence des flux, aucune preuve ne permet d’affirmer qu’un serveur n’a jamais été atteint.

🦫 Explication de la marmotte 🍫

Après avoir pris le contrôle d’un premier ordinateur, un attaquant cherche ce qui est accessible depuis cette machine. Il peut consulter l’annuaire de l’entreprise, qui recense les comptes, les ordinateurs, les groupes et parfois les droits accordés. Il cherche aussi les dossiers partagés, les serveurs et les comptes ayant davantage de pouvoir.

Si des informations de connexion restent en mémoire sur l’ordinateur, elles peuvent permettre de se connecter à d’autres machines sans connaître le mot de passe d’origine. Des autorisations trop larges, des comptes administrateurs utilisés sur des postes ordinaires ou des liens de confiance mal contrôlés accélèrent cette progression.

La segmentation réseau limite ce problème en empêchant certains échanges. Un poste utilisateur ne doit pas pouvoir joindre directement tous les serveurs, les systèmes de sauvegarde ou les outils d’administration. Les communications nécessaires sont autorisées une par une. Si une connexion est bloquée, l’attaquant ne peut pas emprunter ce chemin, même s’il contrôle déjà un ordinateur.

La surveillance cherche ensuite des comportements rares : un poste qui contacte soudain un serveur sensible, un compte qui se connecte à de nombreuses machines, ou une machine qui consulte une grande partie de l’annuaire. En cas d’alerte, isoler le poste et remplacer les accès compromis limite la suite. Cela échoue si les journaux manquent, si les règles réseau sont trop larges ou si les comptes puissants restent utilisables partout.

À lire aussi

• Sécuriser une interface HMI industrielle WindowsCette page décrit comment réduire le rôle de pivot d'une interface homme-machine industrielle entre le réseau informatique et les automates.
• Gouverner les facteurs d’authentification en entreprisePolitique de choix des facteurs, déploiement progressif du passwordless, vérification d’identité et récupération de compte dans un parc hétérogène.
• Comment formuler une hypothèse de threat huntingConstruire, exécuter et industrialiser une hypothèse de threat hunting à partir du renseignement sur la menace et des données déjà collectées.
• Configurer Windows Hello for Business sans mot de passeGuide pratique de déploiement de l’authentification sans mot de passe sur Active Directory avec Windows Hello for Business.

Pages voisines

La citent

• Attaque de l'intercepteur par ARP, DHCP, DNS, Wi-Fi et proxy TLS
• EDR : fonctionnement, angles morts et contournements
• Prioriser les vulnérabilités avec CVSS 4.0, EPSS, KEV et exposition
• Réponse à incident NIST SP 800-61r3, cycle complet et architecture
• SOC centre des opérations de sécurité : rôle, organisation, mesure
• Ethernet, trames et commutation locale
• Filtrage, segmentation, NAC et Zero Trust
• L'administration Active Directory en tiers en une page

Comment limiter le mouvement latéral après compromission

Elle cite

• Comment structurer Active Directory et déléguer sans escalade
• Grand-père Castor raconte : bind LDAP en clair, corrigé
• Kerberos et KDC dans Active Directory, attaques et durcissement
• NTLM : protocole authentification LAN Manager New Technology Microsoft