Pivoting et tunneling : guide blue team de détection et durcissement

Le pivoting et le tunneling sont les techniques par lesquelles un intrus transforme un unique point d’appui en portée sur tout un réseau. Une fois qu’un attaquant contrôle une machine, il s’y arrête rarement : le véritable objectif se trouve généralement plus profond, sur des hôtes non directement accessibles depuis internet. Cet article examine le pivoting et le tunneling du point de vue de la blue team : comprendre le mécanisme afin de le détecter, le contenir et concevoir des réseaux qui le rendent difficile. Nous ne détaillerons pas d’étapes opérationnelles d’attaque ; nous nous concentrons sur la télémétrie que ce comportement produit, sur les sources de logs et Event IDs qui le révèlent, et sur les contrôles de segmentation et de durcissement qui l’émoussent. Si vous défendez un réseau d’entreprise, reconnaître la signature du mouvement latéral est l’une des détections les plus rentables que vous puissiez construire.

Ce que signifient vraiment le pivoting et le tunneling

Le pivoting est la pratique consistant à utiliser un hôte compromis comme tremplin pour atteindre des systèmes que l’attaquant ne peut pas toucher directement. La première machine devient un relais : le trafic qui provient de l’attaquant est transféré à travers elle vers des segments réseau censés être isolés. Le tunneling est l’idée étroitement liée d’envelopper un protocole dans un autre pour qu’il se faufile à travers le filtrage. Une connexion qu’un pare-feu bloquerait normalement est encapsulée dans un protocole autorisé — HTTPS, DNS, SSH ou ICMP — de sorte que, de l’extérieur, elle ressemble à du trafic ordinaire et permis. Ensemble, ces techniques permettent à un adversaire de traiter votre réseau interne comme s’il disposait d’un bureau à l’intérieur, alors que chaque paquet transite en réalité par un point d’appui qu’il n’aurait jamais dû avoir.

Pour les défenseurs, l’idée clé est que les deux techniques génèrent des relations inhabituelles entre hôtes. Un poste de travail qui agit soudain comme un routeur, un serveur qui ouvre des sessions sortantes de longue durée vers un endroit jamais contacté, ou un pic de requêtes DNS aux noms anormalement longs : ce sont des anomalies relationnelles, pas des correspondances de signature. La détection s’appuie donc fortement sur l’établissement d’une base de référence du comportement normal et sur l’alerte en cas d’écart, plutôt que sur la capture d’une chaîne précise.

Comment cela fonctionne à haut niveau

Sur le plan conceptuel, le pivoting repose sur une forme de transfert de trafic. L’hôte compromis écoute sur un port et relaie ce qui arrive vers une autre destination, ou il établit un canal sortant vers l’infrastructure contrôlée par l’attaquant puis accepte des instructions pour atteindre l’intérieur. Le pivoting par proxy transforme le point d’appui en passerelle généraliste, de sorte que de nombreux services internes deviennent atteignables via une seule connexion. Le tunneling ajoute une couche de déguisement : le trafic transféré est encapsulé pour que les dispositifs d’inspection voient le protocole extérieur autorisé plutôt que le protocole intérieur interdit. Le tunneling DNS, par exemple, dissimule des données dans les noms et réponses des requêtes DNS ; le tunneling ICMP les cache dans les charges de ping ; le tunneling HTTP(S) fond le trafic de commande dans des requêtes web qui ressemblent à de la navigation normale.

Ce qui compte en défense, c’est que chaque déguisement laisse un résidu. L’encapsulation n’est jamais gratuite : elle modifie la taille des paquets, le rythme, l’entropie, la fréquence des requêtes et le rapport entre requêtes et résultats applicatifs légitimes. Un résolveur DNS qui répond soudain à des milliers de requêtes pour un seul domaine inhabituel, ou un hôte interne qui garde une session SSH ouverte pendant des heures vers une adresse externe, produit exactement le type d’empreinte statistique qu’un environnement bien instrumenté peut capter.

La surface d’attaque : où se produit le pivoting

Le pivoting prospère sur les réseaux plats. Quand chaque hôte peut parler à tous les autres sur n’importe quel port, une seule compromission suffit pour atteindre contrôleurs de domaine, bases de données, serveurs de sauvegarde et interfaces d’administration. Parmi les facilitateurs courants figurent des règles de pare-feu est-ouest trop permissives, des identifiants d’administrateur local partagés qui laissent une machine s’authentifier sur beaucoup d’autres, des protocoles de gestion à distance exposés (RDP, SSH, WinRM, SMB) et des jump hosts auxquels trop de segments font confiance. Les environnements cloud ajoutent leurs propres chemins de pivot : rôles d’instance trop étendus, VPC apairés sans groupes de sécurité corrects et services de métadonnées capables de distribuer des identifiants. Chacun est un endroit où le défenseur peut ajouter de la friction.

Détection : logs, Event IDs et télémétrie

Détecter le pivoting, c’est repérer des hôtes au comportement atypique. Sous Windows, surveillez le Security Event ID 4624 (ouverture de session) en prêtant attention aux types de logon 3 (réseau) et 10 (interactif distant) provenant de postes qui ne devraient jamais initier de telles sessions, et le 4648 (ouverture avec identifiants explicites), qui accompagne fréquemment le relais d’identifiants. L’Event ID 4688 (création de processus) et l’Event ID 1 de Sysmon révèlent les utilitaires de tunneling et l’usage inattendu d’outils intégrés comme ssh.exe, les configurations portproxy de netsh ou le transfert via PowerShell. L’Event ID 3 de Sysmon (connexion réseau) est inestimable : il lie un processus au socket qu’il a ouvert, de sorte que vous voyez un processus sans navigateur maintenant une session sortante, ou un poste établissant des connexions que seul un routeur devrait établir.

Côté réseau, votre signal le plus riche est la donnée de flux. NetFlow, IPFIX ou les logs de connexion Zeek permettent de baseliner qui-parle-à-qui et d’alerter quand un hôte se met à relayer. Cherchez les sessions de longue durée, les connexions transportant bien plus d’octets qu’un canal de contrôle ne le devrait, et les hôtes internes qui apparaissent soudain comme source de balayages sur de nombreux ports. Pour le tunneling DNS, surveillez le fort volume de requêtes vers un seul domaine, des labels de sous-domaine anormalement longs ou à forte entropie, un rapport inhabituel de requêtes TXT ou NULL et des clients qui contournent vos résolveurs internes. Pour les tunnels chiffrés, les métadonnées TLS et les empreintes JA3/JA3S aident à signaler les sessions dont la signature client ne correspond à aucun logiciel autorisé. Les plateformes EDR relient tout cela en corrélant le processus, la lignée parentale et la connexion réseau en une seule histoire comportementale.

Une stratégie de détection pratique combine trois couches : anomalies d’identité (comptes et machines s’authentifiant selon des schémas jamais utilisés auparavant), anomalies de processus (binaires living-off-the-land invoqués avec des arguments de transfert) et anomalies réseau (nouveaux appairages, durées longues, incohérences protocole/port comme du trafic non-DNS sur le port 53). Chacune seule produit du bruit ; corrélées, elles produisent des alertes à forte confiance.

Atténuation et durcissement

Le contrôle le plus efficace contre le pivoting est la segmentation réseau. Divisez l’environnement en zones avec des règles de refus par défaut entre elles, et n’autorisez que les flux est-ouest spécifiques requis par les fonctions métier. La microsegmentation — appliquer une politique par charge de travail plutôt que par sous-réseau — réduit le rayon d’impact, de sorte que prendre un hôte ne signifie plus prendre le segment. Complétez cela par un filtrage de sortie strict : les hôtes internes ne devraient atteindre internet que via des proxys contrôlés, et des protocoles comme DNS devraient être forcés à travers des résolveurs internes inspectés, de sorte que le DNS sortant direct depuis des hôtes arbitraires soit bloqué et alertable.

Le durcissement de l’identité retire le carburant dont vit le pivoting. Éliminez les mots de passe d’administrateur local partagés avec une solution comme Windows LAPS, appliquez le modèle d’administration par niveaux pour que les identifiants à haut privilège ne touchent jamais des machines de faible confiance, et exigez une authentification multifacteur résistante au phishing sur tous les chemins d’accès distant et de gestion. Restreignez les protocoles latéraux : désactivez SMBv1, limitez RDP et WinRM à des jump hosts désignés et utilisez des pare-feu basés sur l’hôte pour refuser le trafic poste-à-poste sans justification métier. Maintenez les systèmes à jour et appliquez le principe du moindre privilège aux rôles cloud et comptes de service afin qu’un jeton volé ouvre peu de portes.

Pitièges courants pour les défenseurs

Les équipes supposent souvent qu’un pare-feu périmétrique et un antivirus de poste suffisent ; les deux sont largement aveugles au trafic interne d’apparence autorisée. Une autre erreur fréquente est de journaliser sans rétention ni corrélation : les Event IDs ci-dessus ne valent rien s’ils sont écrasés en un jour ou vivent dans des silos qu’aucune analyse ne joint. Autoriser un DNS et un HTTPS sortants sans restriction "parce que tout a besoin d’internet" offre aux attaquants des tunnels tout faits. Faire confiance implicitement aux jump hosts, ne pas surveiller du tout le trafic est-ouest et traiter les points de métadonnées cloud comme inoffensifs sont des lacunes récurrentes. Enfin, beaucoup d’organisations ne testent jamais leurs propres détections ; un exercice de purple team qui exerce en toute sécurité le comportement de pivoting dans un laboratoire contrôlé est le moyen le plus rapide de savoir si votre télémétrie se déclenche vraiment.

Une liste de contrôle défensive pratique

1. Segmentez le réseau avec des règles est-ouest de refus par défaut et adoptez la microsegmentation pour les charges critiques. 2. Forcez tout le trafic sortant à travers des proxys inspectés et des résolveurs DNS internes ; bloquez et alertez sur le DNS/ICMP sortant direct. 3. Déployez Sysmon (Event IDs 1 et 3) et centralisez les logs de flux (NetFlow/IPFIX/Zeek) avec une rétention utile. 4. Construisez des détections corrélées pour les anomalies d’ouverture de session (4624/4648), les outils de portproxy et de tunneling, et les nouveaux appairages hôte-à-hôte. 5. Établissez une base de référence DNS par client et alertez sur le fort volume, les labels longs, la forte entropie et les types d’enregistrement inhabituels. 6. Éliminez les identifiants d’admin local partagés, adoptez l’administration par niveaux et imposez une MFA résistante au phishing. 7. Restreignez RDP/SSH/WinRM/SMB à des jump hosts durcis et refusez le trafic latéral poste-à-poste. 8. Moindre privilège sur chaque rôle cloud et protection des services de métadonnées. 9. Corrigez de manière agressive. 10. Validez les détections par des exercices de purple team réguliers et autorisés.

FAQ

Tout tunneling est-il malveillant ? Non. Les VPN, l’administration SSH et de nombreuses applications légitimes utilisent le tunneling chaque jour. C’est précisément pourquoi la détection doit se fonder sur le contexte — quel hôte, quel processus, quelle destination et si le comportement correspond à une base établie — plutôt que sur la simple présence d’un protocole encapsulé. L’objectif est de distinguer les tunnels autorisés des non autorisés, pas d’interdire le concept.

Le chiffrement peut-il empêcher les attaquants de faire du tunneling ? Le chiffrement protège la confidentialité mais n’empêche pas le tunneling ; les adversaires préfèrent même les canaux chiffrés car l’inspection de charge devient impossible. Les défenseurs répondent par l’analyse de métadonnées (durée de session, volume d’octets, rythme, empreintes TLS), un contrôle de sortie strict via des proxys qui terminent ou courtent les connexions, et une corrélation comportementale sur le poste, où le trafic existe en clair avant d’être enveloppé.

Conclusion

Le pivoting et le tunneling sont la manière dont un unique hôte compromis devient un incident à l’échelle du réseau, et ils réussissent le plus facilement là où les réseaux sont plats, la sortie sans restriction et le trafic interne non surveillé. La réponse défensive est en couches et sans éclat : segmenter agressivement pour qu’un point d’appui ne puisse pas tout atteindre, contrôler et inspecter la sortie pour que les canaux déguisés n’aient nulle part où se cacher, instrumenter postes et flux pour que les relations inhabituelles remontent vite, et durcir l’identité pour que les identifiants volés ouvrent peu de portes. Construisez des détections corrélées sur les signaux d’identité, de processus et de réseau, conservez les logs assez longtemps pour enquêter, et entraînez-vous contre vos propres défenses avec des exercices autorisés. Faites cela, et le mouvement latéral cesse d’être un glissement invisible à travers votre parc pour devenir un événement bruyant et capturable.