Une nouvelle famille d’attaques baptisée NatJack met en lumière un point de fragilité des réseaux qui s’appuient sur la traduction d’adresses réseau (NAT) pour partager une infrastructure entre plusieurs hôtes. Présentée lors de Black Hat USA 2026 par le chercheur Malcolm Stagg, cette recherche décrit comment un acteur disposant d’un accès privilégié derrière le même NAT que la victime peut manipuler l’état des connexions, détourner des sessions TCP et fausser des réponses DNS.
Les résultats s’appuient sur des mises en œuvre indépendantes observées sur Windows et Linux. L’étude ne parle pas d’une seule vulnérabilité isolée, mais d’un ensemble de chemins d’attaque pouvant, selon le contexte, rediriger le trafic, interférer avec des requêtes DNS, ou encore saturer la table de connexions NAT.
Comprendre le principe derrière les Attaques NatJack
NatJack repose sur une hypothèse que beaucoup de systèmes NAT intègrent : lorsque plusieurs machines partagent la même couche NAT, elles sont généralement considérées comme ne manipulant pas les états de connexion des autres. Or, la recherche indique qu’un attaquant contrôlant un hôte placé derrière le même NAT peut, selon l’implémentation, modifier ou influencer des entrées de suivi de connexion associées à une autre machine.
Concrètement, l’attaque vise la manière dont le NAT conserve et met à jour l’état des flux (par exemple pour le routage et la translation). En perturbant ce suivi, l’adversaire peut produire des effets allant du détournement de session à des perturbations plus larges.
Quatre voies d’attaque décrites par la recherche
La publication décrit quatre grands chemins permettant d’atteindre différents objectifs. Tous dépendent de la capacité de l’attaquant à agir depuis un système situé derrière le même NAT que la victime, et de la façon dont la plateforme gère l’état des connexions.
1) Détourner une connexion TCP active
Le premier scénario consiste à rediriger un flux TCP déjà en cours en remplaçant la correspondance NAT utilisée par la connexion active. En altérant l’association attendue, la communication peut être orientée vers l’attaquant au lieu de rester fidèle au mapping initial.
2) Interférer avec une requête DNS
Une autre voie vise les échanges DNS : l’attaquant perturbe la requête pour que la réponse légitime soit livrée à sa destination, puis renvoie une réponse falsifiée. Résultat : le système de la victime peut croire à une résolution DNS malveillante, ouvrant la porte à d’autres actions (trafic redirigé, services usurpés, etc.).
3) Révéler des ports exposés
Selon l’environnement, NatJack peut aussi contribuer à mettre en évidence des ports mappés vers l’extérieur. L’objectif peut être d’obtenir des informations supplémentaires utiles pour la suite de l’intrusion, en identifiant ce qui est réellement accessible via les mécanismes de publication du NAT.
4) Saturer la table de connexions NAT
Enfin, certaines techniques cherchent à remplir la table des connexions NAT avec des flux falsifiés jusqu’à ce que des clients légitimes ne puissent plus établir de nouvelles sessions. Cette logique peut mener à une forme de déni de service, non pas nécessairement par surcharge applicative, mais par épuisement des capacités de suivi de la translation.
Vulnérabilités attribuées : CVE côté Windows et Linux
La recherche ne propose pas une unique correction couvrant toute la classe d’attaque. En revanche, deux défauts spécifiques ont été associés à des CVE correspondant à des erreurs d’implémentation propres à chaque plateforme NAT.
- CVE-2026-56181 (CVSS 8.3) : lié à la NAT de Windows, utilisée notamment par Hyper-V.
- CVE-2026-63913 (CVSS 8.2) : lié à Linux Netfilter conntrack.
Ces attributions visent des points précis. Toutefois, Stagg indique que les modifications apportées ne suffisent pas à elles seules à neutraliser intégralement l’ensemble des techniques dérivées de NatJack.
Correctifs Linux : ce que disent les informations de sécurité
Côté Linux, le registre CNA de kernel.org mentionne un comportement déclenché par une séquence réseau particulière : un SYN construit, suivi d’un paquet reset avec un numéro de séquence invalide, peut forcer prématurément une entrée active Netfilter NAT à passer à un état fermé. L’enjeu provient d’une défaillance dans la validation du sens (direction) au niveau de la logique conntrack.
Les versions stables fixées incluent 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.93, 6.18.35, 7.0.12 et 7.1. Le chercheur précise néanmoins que le changement corrige la faille de code, mais mitige surtout une partie du mécanisme plus large de “spoofing en aval”. Autrement dit, cela peut accroître la complexité de l’attaque sans supprimer toutes les variantes.
Correctifs Windows : validation d’origine et conditions d’exposition
Pour Windows, les informations CNA décrivent un problème de validation de l’origine permettant un spoofing depuis un réseau adjacent. Les versions concernées incluent :
- Windows 11 24H2 avant 26100.8875
- 25H2 avant 26200.8875
- 26H1 avant 28000.2525
- Windows Server 2025 avant 26100.33158
En pratique, cela signifie que les environnements non à jour peuvent laisser une fenêtre d’exploitation, notamment lorsque l’architecture réseau autorise une communication “adjacente” compatible avec les conditions décrites.
Pourquoi le patching ne suffit pas totalement
Le point le plus important dans l’étude réside dans l’absence de patch unique couvrant l’intégralité de la classe d’attaque NatJack. Les chercheurs indiquent donc que la réponse doit être multi-couches.
Par conséquent, les organisations sont invitées à appliquer les mises à jour disponibles côté Windows et Linux, tout en réduisant la surface d’attaque via des mesures de conception et de protection du trafic.
Recommandations de mitigation : isoler et sécuriser le trafic
La guidance met d’abord l’accent sur la séparation des charges “non fiables” et des systèmes “fiables” partageant la même infrastructure NAT. Comme NatJack requiert typiquement un accès privilégié depuis un hôte situé derrière le même NAT, l’isolation réduit fortement la probabilité qu’un attaquant puisse atteindre le contexte nécessaire.
Ensuite, plusieurs mesures complémentaires sont recommandées :
- Chiffrer le trafic, y compris à l’intérieur du réseau interne. Cela limite les impacts des manipulations réseau sur le contenu transmis.
- En fonction de l’environnement, utiliser IP Source Guard lorsque cela est applicable. Cette mesure vise à améliorer la validation des adresses sources et à réduire l’efficacité de certains scénarios de falsification.
Ces actions ne remplacent pas l’installation des correctifs, mais elles renforcent la résistance globale.
Preuves de concept et limites observées
Selon les informations publiées, Stagg a testé les techniques contre plusieurs produits d’infrastructure réseau issus de différents fournisseurs. L’objectif était de démontrer des preuves de concept dans un environnement contrôlé.
Par ailleurs, la recherche mentionne qu’il n’existe pas une matrice publique exhaustive “produit par produit”. Au moment de la publication, aucune preuve publique n’indiquait que NatJack aurait été exploité dans la nature (au 7 août 2026, d’après ce qui est rapporté).
Un prolongement d’études antérieures sur la manipulation de l’état NAT
NatJack s’inscrit dans un continuum de recherches autour de la manipulation de l’état réseau. Un travail présenté en 2024 lors de NDSS a montré une approche de détournement de sessions TCP via manipulation des mappings NAT et a identifié que 52 routeurs sur 67 testés étaient sensibles à l’attaque. Cette étude avait également abouti à dix CVE.
Autrement dit, NatJack ne surgit pas de nulle part : il s’appuie sur des constats précédents, tout en décrivant une classe d’attaques plus structurée autour de l’exploitation de l’état NAT.
Conclusion : agir maintenant contre les Attaques NatJack
Les Attaques NatJack rappellent que la NAT, tout en facilitant le partage des adresses, peut aussi devenir un point critique si la gestion de l’état des connexions est exploitable. Les capacités décrites — détournement de sessions TCP, falsification de réponses DNS, exposition de ports et saturation des tables NAT — montrent l’ampleur potentielle des impacts.
Pour réduire le risque, la stratégie la plus solide combine : application des correctifs Windows et Linux, isolation des environnements qui partagent la même infrastructure NAT, et chiffrement des communications internes. Avec ces mesures, vous limitez fortement les conditions qui rendent NatJack praticable.
Source: https://thehackernews.com/2026/08/new-natjack-attacks-hijack-tcp-sessions.html
