Onderzoekers hebben een nieuwe aanvalsklasse onthuld die zich richt op een fundamentele aanname in netwerkapparatuur: systemen achter dezelfde NAT zouden elkaar normaal gesproken niet kunnen manipuleren. De aanval heet NatJack-aanvallen en kan volgens de presentatie TCP-sessies kapen, DNS-reacties vervalsen, gekoppelde poorten blootleggen en zelfs NAT-tabellen uitputten.
De bevindingen zijn gepresenteerd op Black Hat USA 2026. Security researcher Malcolm Stagg werkte daarbij onafhankelijk en rapporteerde dat er gedrag is gezien in meerdere, los van elkaar ontwikkelde implementaties, waaronder omgevingen op zowel Windows als Linux.
Wat zijn NatJack-aanvallen?
Bij veel NAT-implementaties wordt de verbindingstoestand bijgehouden, bijvoorbeeld via vertaal- en conntrack-tabellen. NatJack-aanvallen proberen juist die toestanden te beïnvloeden, met als doel verkeer dat al in behandeling is naar de aanvaller om te leiden.
Stagg stelt dat de kern van het probleem is dat hosts achter dezelfde NAT doorgaans als “niet-veroorzakers” van andermans verbindingstoestanden worden beschouwd. Als een aanvaller wél controle heeft over een systeem binnen hetzelfde NAT-domein, kan de impact per implementatie verschillen, maar het uitgangspunt blijft: manipulatie van verbindingstracking.
Welke effecten kun je verwachten?
In het onderzoek worden vier hoofdpaden beschreven. In plaats van alleen nieuwe sessies te verstoren, richt NatJack zich ook op bestaande communicatie die al door NAT is “doorgezet”.
- TCP-verkeer omleiden via NAT-mapping: de aanvaller vervangt of beïnvloedt de NAT-verwijzing van een actieve TCP-verbinding, waardoor verkeer terecht kan komen bij de aanvaller.
- DNS-reacties spoofen: de aanvaller interfereert met de DNS-aanvraag, zodat de legitieme DNS-respons bij de aanvaller terechtkomt. Daarna kan de aanvaller een vervalste respons terugsturen.
- Extern gemapte poorten onthullen: sommige technieken zorgen voor informatie die laat zien welke poorten extern gekoppeld zijn.
- NAT-tabellen uitputten: door spoofed flows te vullen kan de NAT-verbindingstabel vol raken, waardoor legitieme clients geen nieuwe verbindingen meer kunnen opzetten.
Volgens de toelichting hangt de haalbaarheid sterk samen met de plaats van de aanvaller: vaak is bevoorrechte toegang nodig op een systeem dat zich achter dezelfde NAT bevindt als het slachtoffer.
Windows en Linux: twee CVE’s, maar geen één patch voor alles
Omdat NatJack-aanvallen meerdere componenten kunnen raken, is er volgens het onderzoek geen “enkelvoudige” fix voor de volledige aanvalsklasse. Wel zijn er implementatie-specifieke kwetsbaarheden met CVE’s toegewezen.
Windows NAT (Hyper-V)
Voor Windows NAT—met name relevant voor omgevingen waarin dit gebruikt wordt door Hyper-V—is een kwetsbaarheid gerapporteerd als CVE-2026-56181. De gerapporteerde CVSS-score is 8.3.
Microsoft’s CNA-registratie beschrijft het probleem als een origin-validation-fout die spoofing vanuit een aangrenzend netwerk mogelijk maakt. De getroffen releases die in de brontekst worden genoemd zijn:
- Windows 11 24H2 vóór 26100.8875
- Windows 25H2 vóór 26200.8875
- Windows 26H1 vóór 28000.2525
- Windows Server 2025 vóór 26100.33158
Linux Netfilter conntrack
Op Linux wordt het probleem gekoppeld aan Netfilter conntrack. Daar is CVE-2026-63913 toegewezen met een CVSS-score van 8.2.
De kern van de fix zit in een kernelwijziging. In de Linux CNA-registratie wordt beschreven dat een crafted SYN gevolgd door een resetpakket met een ongeldige sequence number een actieve Netfilter NAT-entry voortijdig in een gesloten toestand kan dwingen. Dat gebeurt doordat de conntrack-logica niet goed valideert met betrekking tot de richting.
De brontekst noemt daarnaast stabiele kernelreleases die als “fixed” worden aangeduid:
- 5.10.259
- 5.15.210
- 6.1.176
- 6.6.143
- 6.12.93
- 6.18.35
- 7.0.12
- 7.1
Wel is er nuance: de kernelwijziging zou volgens Stagg vooral de downstream-spoofing-techniek mitigeren. Dat maakt aanvallen complexer, maar pakt volgens de brontekst niet per definitie alle varianten van de bredere aanpak volledig af.
Wie loopt extra risico?
NatJack-aanvallen worden in de brontekst vooral gelinkt aan situaties waarin een aanvaller privileged toegang heeft tot een systeem achter dezelfde NAT-infrastructuur als het slachtoffer. Daarmee wordt het risico niet alleen een kwestie van perimeterverdediging, maar ook van interne segmentatie en netwerkontwerp.
Stagg benadrukt daarom een belangrijk mitigatiepunt: scheid onbetrouwbare workloads van vertrouwde systemen die NAT-infrastructuur delen. Met andere woorden: als meerdere “klant-achtige” omgevingen dezelfde NAT gebruiken, wordt het lastig om te garanderen dat verbindingstoestanden niet kunnen worden beïnvloed.
Mitigaties die je meteen kunt doorvoeren
Aangezien er geen enkele patch voor het hele probleem is, ligt de nadruk op een combinatie van maatregelen. De brontekst noemt de volgende richtingen.
- Patch Windows en Linux waar het om de betreffende kwetsbaarheden gaat. Werk daarnaast waar mogelijk kernel- en NAT-gerelateerde componenten bij.
- Versleutel verkeer ook binnen interne netwerken. Encryptie vermindert de impact van technieken waarbij reacties of datastromen worden gemanipuleerd.
- Internet Protocol (IP) Source Guard waar toepasbaar. Deze maatregel kan helpen om bronadressen strakker te valideren op netwerklaag.
- Segmenteer systemen achter NAT zodat onbetrouwbare workloads niet dezelfde NAT-infrastructuur delen met kritieke systemen.
Het praktische voordeel van deze combinatie is dat je niet volledig afhankelijk bent van één specifieke softwarefix. Tegelijkertijd voelt dit voor veel organisaties als een herbevestiging van bestaande best practices rond interne scheiding en sterke controles op netwerkverkeer.
Is er bewijs van misbruik in het wild?
De brontekst vermeldt dat er geen publieke aanwijzingen zijn dat NatJack-technieken al actief zijn ingezet in de praktijk, voor zover bekend op 7 augustus 2026. Wel geeft de onderzoeker aan dat proof-of-concept exploitatie is aangetoond in een gecontroleerde omgeving.
Daarbij is in de brontekst ook genoemd dat Stagg de aanpak testte tegen tientallen netwerkgerelateerde infrastructuurproducten van meerdere leveranciers. Interessant is dat de NatJack-site geen volledige matrix publiceert per productmodel of vendor—dus organisaties zullen vooral moeten sturen op patchstatus en hun eigen netwerkarchitectuur.
Vergelijking met eerdere NAT-manipulatie-onderzoeken
NatJack bouwt volgens de brontekst voort op eerdere publicaties over NAT-state manipulation. Zo wordt een NDSS-studie uit 2024 aangehaald: daarin werd TCP hijacking via NAT mapping manipulation onderzocht, waarbij 52 van 67 geteste routers kwetsbaar bleken. Die aanpak leidde toen tot tien CVE’s.
Dat maakt NatJack niet “uit het niets” ontstaan: het sluit aan bij een bredere lijn waarin NAT-gedrag en conntrack-aannamefouten onderwerp van aanvalstechnieken worden.
Wat betekent dit voor jouw beveiligingsstrategie?
De belangrijkste les van NatJack-aanvallen is dat NAT niet alleen een netwerk-functionaliteit is, maar ook een onderdeel van je beveiligingsmodel. Als je interne systemen dezelfde vertaalinfrastructuur delen, kan een compromis op één plek theoretisch invloed hebben op een andere plek.
Daarom helpt het om je aanpak in drie stappen te ordenen: (1) update en patch op Windows en Linux waar het relevant is, (2) versleutel intern verkeer om manipulatie minder bruikbaar te maken, en (3) heroverweeg NAT-deling door onbetrouwbare systemen beter te isoleren.
Wil je ook breder kijken naar recente ontwikkelingen rond vendorupdates en securitypatches? Lees dan eens welke vendorupdates je op Black Hat USA 2026 ziet.
Daarnaast zijn er binnen netwerk- en endpointsecurity vaker situaties waarin interne aanvallers misbruik kunnen maken van “verwachtingen” in systemen. Een voorbeeld van hoe patch- en kwetsbaarheidsupdates samenkomen met real-world risico’s vind je ook bij Cisco-patches voor kritieke SD-WAN, IOS XE en FMC.
Conclusie
NatJack-aanvallen laten zien dat het beïnvloeden van NAT-verbindingstoestanden kan leiden tot serieuze impact: TCP-sessies kapen, DNS-reacties spoofen, poorten blootleggen en NAT-tabellen uitputten. Bovendien geldt: het risico neemt toe zodra een aanvaller privileged toegang heeft tot een systeem achter dezelfde NAT als het slachtoffer.
Hoewel er implementatie-specifieke CVE’s zijn voor Windows en Linux, is er geen universele patch die alle varianten afdekt. Organisaties doen er daarom goed aan om gericht te patchen, intern verkeer te versleutelen, en NAT-deling tussen onbetrouwbare en vertrouwde workloads te beperken—liefst aangevuld met maatregelen zoals IP Source Guard waar dat past.
Bron: https://thehackernews.com/2026/08/new-natjack-attacks-hijack-tcp-sessions.html
