NatJack détourne vos sessions TCP et spoofe votre DNS en manipulant les tables NAT — Black Hat 2026 expose une faille de conception universelle

Le 6 août 2026, sur la scène de Black Hat USA, le chercheur en sécurité Malcolm Stagg a présenté NatJack — une nouvelle classe d’attaques qui ne cible pas un OS ou un firmware particulier, mais le concept même de Network Address Translation. La faille est dans la RFC, pas dans l’implémentation.

Stagg a démontré quatre capacités offensives distinctes, toutes reproductibles contre des implémentations NAT développées indépendamment : le stack TCP/IP de Windows, le framework netfilter de Linux, et les firmwares de routeurs grand public OpenWrt et pfSense.

Comment NatJack fonctionne

Le NAT maintient une table de suivi de connexion (conntrack sous Linux, NAT mapping table sous Windows). Chaque entrée associe un tuple (IP source, port source, IP destination, port destination) à un port externe mappé.

NatJack exploite une propriété fondamentale de ces tables : la course entre la fermeture d’une connexion et la réutilisation de son entrée. Stagg a identifié une fenêtre temporelle — de l’ordre de quelques dizaines de millisecondes sur des implémentations récentes, jusqu’à plusieurs secondes sur des routeurs grand public — pendant laquelle une entrée NAT est marquée comme libérable mais reste encore en mémoire.

Pendant cette fenêtre, un attaquant capable d’envoyer des paquets vers la cible peut :

1. Injecter un paquet dans une session TCP encore active en devinant les numéros de séquence (rendus prévisibles par le fait que l’entrée NAT est toujours chaude).
2. Usurper une réponse DNS en émettant une réponse forgée dont le port source correspond à une entrée NAT encore ouverte.
3. Scanner les ports internes en testant quelles entrées NAT répondent encore.
4. Saturer la table NAT en provoquant la création et l’abandon rapide de milliers de connexions, menant à un déni de service.

L’impact par plateforme

Windows. Le comportement du NAT dans le stack TCP/IP de Windows (utilisé par Internet Connection Sharing et le rôle Routing and Remote Access) est le plus prévisible. La fenêtre de réutilisation est de 30 ms, suffisante pour une attaque locale ou sur un LAN à faible latence. Microsoft a classé la faille comme Important et prévoit un correctif dans le Patch Tuesday de septembre 2026.

Linux / netfilter. Le module nf_conntrack de Linux netfilter est vulnérable quand le paramètre nf_conntrack_tcp_timeout_time_wait est supérieur à zéro — ce qui est le cas par défaut. La fenêtre est plus courte (8 à 12 ms) mais l’attaque peut être menée depuis le même hôte virtualisé, ce qui réduit la latence effective à quasiment zéro. Le kernel 7.1.6 (et les backports 6.18.42, 6.12.101, 6.6.148) inclut un correctif qui supprime la fenêtre de réutilisation pour les connexions en état TIME_WAIT.

Routeurs grand public. C’est la plus mauvaise nouvelle. Les firmwares OpenWrt et pfSense présentent des fenêtres de réutilisation allant jusqu’à 4 secondes sur certains modèles. Un attaquant sur le même réseau Wi-Fi peut mener l’attaque sans contrainte de timing. La mise à jour vers OpenWrt 24.10.1 ou pfSense 2.8.0 colmate la brèche, mais la réalité du parc installé est que moins de 15 % des routeurs grand public exécutent un firmware patché dans les six mois suivant une divulgation.

Ce que vous devez patcher

La parade immédiate dépend de votre rôle dans la chaîne réseau :

• Administrateurs de parc Windows : Désactivez Internet Connection Sharing sur tous les postes qui n’en ont pas strictement besoin. Planifiez le déploiement du correctif de septembre 2026.
• Admins Linux : Passez en kernel 7.1.6 / 6.18.42 / 6.12.101 / 6.6.148 ou appliquez le contournement :

echo 0 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_time_wait

Cette modification supprime immédiatement la fenêtre vulnérable, au prix d’une réutilisation légèrement moins efficace des entrées conntrack.

• Utilisateurs de routeurs : Appliquez la mise à jour firmware aujourd’hui. Si votre routeur n’est plus supporté, remplacez-le ou placez-le derrière un pare-feu qui filtre les paquets entrants usurpés.

• Fournisseurs d’accès et opérateurs cloud : Auditez vos équipements CGNAT (Carrier-Grade NAT). Les fenêtres de réutilisation y sont souvent plus longues, car les tables sont massives et les algorithmes de nettoyage moins agressifs. Une seule entrée CGNAT compromise peut exposer des centaines d’abonnés.

Le problème de fond : le NAT n’est pas une sécurité

Stagg a conclu sa présentation par un rappel que l’industrie refuse d’entendre depuis vingt ans : le NAT n’a jamais été conçu comme un mécanisme de sécurité. C’est une rustine contre la pénurie d’adresses IPv4, transformée par habitude en pseudo-firewall.

NatJack est la démonstration éclatante que cette habitude est dangereuse. Un pare-feu stateful correctement configuré (iptables avec politique DROP par défaut, Windows Firewall avec blocage entrant) n’est pas vulnérable à NatJack — justement parce qu’il ne fait pas de NAT. C’est le NAT qui crée la surface d’attaque.

Verdict

Si votre réseau utilise du NAT, vous êtes vulnérable. La question n’est pas de savoir si, mais à quelle vitesse vous allez patcher.

Pour les particuliers : mettez à jour votre routeur ce soir. La fenêtre de 4 secondes sur un routeur non patché est une invitation ouverte à tout attaquant sur le même réseau Wi-Fi — y compris vos voisins, vos invités, ou le malware qui a infecté l’imprimante connectée.

Pour les entreprises : priorisez les équipements exposés — routeurs de bureau, appliances VPN, passerelles CGNAT — et appliquez les correctifs avant la fin de la semaine. NatJack n’est pas un proof of concept académique : le code d’exploitation est public depuis la présentation de Black Hat.

Et à long terme : commencez à planifier votre migration vers IPv6. Le jour où vous n’aurez plus de NAT, NatJack n’aura plus de surface d’attaque.

Références

• Malcolm Stagg, « NatJack: Hijacking TCP and DNS Through NAT Table Manipulation », Black Hat USA, 6 août 2026
• The Hacker News, « New NatJack Attacks Hijack TCP Sessions and Spoof DNS by Manipulating NAT Tables », 7 août 2026
• netfilter documentation — nf_conntrack_tcp_timeout_time_wait
• Microsoft Security Response Center, « CVE-2026-XXXXX — Windows NAT Table Reuse Vulnerability », août 2026