Een onderzoek gepresenteerd op Black Hat USA 2026 identificeert NatJack, een nieuwe klasse aanvallen op Network Address Translation (NAT) die niet afhankelijk is van een specifieke softwarekwetsbaarheid, maar van hoe verschillende implementaties de verbindingen en het vertrouwen tussen systemen die een NAT-tabel delen beheren. Tests uitgevoerd door onderzoeker Malcolm Stagg tonen getroffen gedragingen in Windows, Linux en macOS aan, terwijl twee gerelateerde kwetsbaarheden al een CVE-identificatie hebben gekregen.
De kernpunten van NatJack in 30 seconden
- NatJack combineert vier technieken om de werking van NAT-implementaties te manipuleren.
- Het kan TCP-verbindingen kapen, DNS-antwoorden wijzigen, toegewezen poorten ontdekken en NAT-tabellen uitputten.
- Tests onthulden beïnvloed gedrag in onafhankelijke codebases van Windows, Linux en macOS.
- Er bestaan al twee CVE’s: CVE-2026-56181 en CVE-2026-63913, met CVSS-scores tussen 7,2 en 9,6.
- Er is geen universeel patch: cloudomgevingen, Kubernetes en multi-tenant omgevingen vereisen speciale aandacht.
NatJack is ontwikkeld over meerdere jaren door Malcolm Stagg, onderzoeker bij SODIUM-24 en lid van het Synack Red Team. Het werk werd gepresenteerd op Black Hat USA 2026 onder de titel Breaking Trust Boundaries: Exploiting Design Assumptions in Network Infrastructure.
Voor systeembeheerders en infrastructuurverantwoordelijken is vooral belangrijk dat NatJack niet simpelweg wordt gezien als een andere routerkwetsbaarheid.
NAT komt tegenwoordig voor binnen hypervisors, container hosts, Kubernetes, cloud-gateways, firewalls, virtuele bruggen en andere netwerkomgevingen. Eenzelfde tabel kan verbindingen beheren van virtuele machines of workloads met volledig verschillende vertrouwensniveaus.
Daar ligt een oude ontwerpkeuze uit de eerste jaren van het internet, die nu nieuwe implicaties krijgt.
Het probleem ligt niet bij NAT, maar bij wie de tabel deelt
Oorspronkelijk was NAT bedoeld om meerdere apparaten met privé-adressen te laten communiceren met het internet door het gebruik van veel minder publieke IPv4-adressen.
Om communicatie mogelijk te maken, moet het apparaat dat NAT uitvoert, weten welke verbinding bij welk systeem hoort.
Kort gezegd: wanneer een machine met een privé-adres een verbinding initieert naar internet, kan NAT het bronadres en -poort aanpassen. Vervolgens houdt het deze vertalingen bij, zodat antwoorden weer naar het juiste apparaat gaan.
Een vereenvoudigd voorbeeld:
Server A
10.0.0.10:49152
│
▼
┌─────────────────────────┐
│ NAT-gateway │
│ │
│ 10.0.0.10:49152 │
│ ↕ │
│ 203.0.113.10:62001 │
└─────────────────────────┘
│
▼
InternetDe implementatie vereist dat er toestandsinformatie, poorttoewijzingen en verbindingstracking is, zodat dit mechanisme functioneert.
In Linux is een kerncomponent hiervoor netfilter conntrack, dat informatie bijhoudt over actieve flows. Windows beschikt ook over NAT-mechanismen, bijvoorbeeld binnen Hyper-V en virtualisatietechnologieën.
De NatJack-onderzoeksvraag was eenvoudig: wat gebeurt er als een van de systemen dat dezelfde NAT-infrastructuur deelt, opzettelijk probeert het gedrag te manipuleren?
Volgens Synack gingen veel implementaties ervan uit dat onderling vertrouwen bestond tussen de apparaten achter dezelfde NAT-tabel.
In een moderne datacenter-omgeving kan deze veronderstelling niet altijd meer standhouden.
Vier verschillende aanvalstechnieken
Stagg documenteerde vier technieken binnen NatJack, elk gericht op een ander aspect van NAT-functionering.
De eerste maakt het mogelijk om actieve TCP-verbindingen te kapen.
De aanvaller probeert de NAT-standaard te manipuleren rondom een bestaande verbinding om verkeer van een ander systeem te verstoren. De effecten hangen af van het hogere protocol: controle over een TCP-stroom betekent niet automatisch dat TLS-gegevens worden geknipt.
De tweede techniek beïnvloedt DNS over UDP.
NatJack kan bepaalde kenmerken van connection tracking gebruiken om verkeerde DNS-antwoorden in te voeren. Als dat lukt en er geen aanvullende beveiligingen zijn, kan een systeem een valse respons accepteren en een domein naar een controleerbare IP laten verwijzen.
De derde techniek maakt het mogelijk om te ontdekken welke poort NAT extern heeft toegewezen aan een andere verbinding.
Deze informatie kan handig zijn bij verdere aanvallen, bijvoorbeeld om het zoekruimte voor exploits te verkleinen.
De vierde techniek betreft een andere invalshoek: resource exhaustion.
NAT-apparaten houden een beperkte hoeveelheid toestanden bij. Een aanvaller die veel verbindingen creëert, kan proberen de NAT-tabel of conntrack te vullen, wat connectivity kan verstoren of verstikken, met een denial-of-service als gevolg.
| Techniek | Doel |
|---|---|
| TCP hijacking | Controle of verstoring van actieve TCP-verbindingen |
| DNS poisoning | Injectie van valse DNS-responses |
| Port discovery | Ontdekken welke poorten door NAT zijn toegewezen |
| NAT exhaustion | Uitputting van NAT-tabellen en netwerkverbindingen |
Niet alle technieken werken op elk apparaat en de impact varieert afhankelijk van de implementatie, configuratie en topologie. De exploitatie hangt af van de capaciteiten van de aanvaller.
Al CVE’s voor Hyper-V en netfilter
Tot nu toe zijn twee CVE’s publiek gemaakt via gedeelde coordinatie.
CVE-2026-56181 betreft het NAT-onderdeel van Microsoft Windows in Hyper-V.
De tweede, CVE-2026-63913, is gerelateerd aan het conntrack-systeem van netfilter in Linux.
Synack plaatst de CVSS-scores voor deze kwetsbaarheden tussen 7,2 en 9,6, variërend van hoog tot kritiek.
Het feit dat er CVE’s uit verschillende platforms bestaat, benadrukt de aard van het probleem. Het is niet dat Windows en Linux dezelfde code delen, maar dat beide implementaties kwetsbaar zijn door vergelijkbare ontwerpkeuzes.
Ook macOS vertoont gedrag dat kwetsbaar kan zijn volgens de onderzoekers.
Synack ziet NatJack daarom als een klasse aanvallen op aannames in het ontwerp van NAT, in plaats van een kwetsbaarheid in één specifieke functie.
De disclosures blijven lopen en nieuwe adviseringen of CVE’s kunnen nog volgen.
Waarom Kubernetes en cloudomgevingen meer aandacht vereisen
De meest interessante use case voor NatJack ligt niet in thuisnetwerken, maar in multi-tenant infrastructuren.
Moderne servers draaien vaak tientallen of honderden virtuele machines of containers.
┌──────────────┐
│ VM klant A │──┐
└──────────────┘ │
│
┌──────────────┐ │ ┌─────────────┐
│ VM klant B │──┼─────▶│ Shared NAT │────▶ Internet
└──────────────┘ │ └─────────────┘
│
┌──────────────┐ │
│ Container X │──┘
└──────────────┘Indien al die systemen onder dezelfde beheerder vallen en het vertrouwen gelijk is, is dat risico beheersbaar.
Maar bij publieke clouds, gedeelde Kubernetes-platforms of services met derden, kunnen vertrouwelijke en niet-vertrouwde workloads hetzelfde NAT gebruiken, met al hun kwetsbaarheden.
Synack adviseert om routers, firewalls, Docker, Kubernetes, Hyper-V, cloud-NAT gateways, virtuele switches en containerplatforms nauwkeurig te controleren op mogelijke blootstellingen.
Dit betekent niet dat alle Kubernetes-clusters automatisch kwetsbaar zijn, maar dat beheerders moeten nadenken:
Kan een niet-vertrouwde workload dezelfde NAT-infrastructuur delen als systeemsituaties met hogere vertrouwensniveaus?
Bij een bevestigend antwoord verdient NatJack een extra kritische beoordeling.
Een conntrack-tabel is ook een potentieel aanvalspunt
Voor Linux-beheerders is vooral conntrack van belang.
De kernel gebruikt dit subsysteem om actief verbonden toestanden bij te houden, met parameters om het aantal entries te controleren en te beperken.
Enkele belangrijke parameters:
nf_conntrack_count
nf_conntrack_max
nf_conntrack_bucketsnf_conntrack_count geeft het huidig aantal verbindingen aan, terwijl nf_conntrack_max het maximum instelt.
Een toename in verbindingen tot boven de limiet kan de mogelijkheid om nieuwe flows te creëren, verstoren.
NatJack kan deze situatie uitbuiten door bewust de tabel te vullen, wat tot een denial-of-service kan leiden.
Voor operationeel personeel betekent dat dat conntrack-metrieken niet alleen voor prestaties, maar ook als een beveiligingssignaal kunnen dienen.
Abnormale pieken in verbindingen, ongewone tabelgebruik of patroonherkenning in pakketten kunnen verdere analyse rechtvaardigen.
Geen universeel patch voor NatJack
Dit is misschien de opvallendste feature die NatJack onderscheidt van een gewone kwetsbaarheid.
Er bestaat geen all-in-one patch die in elke infrastructuur een complete oplossing biedt.
Synack meldt dat sommige systemen al maatregelen hebben geïmplementeerd, zoals Linux kernel 6.6.142 en hoger en FreeBSD 15.0 en hoger.
Maar deze veranderingen adresseren niet de onderliggende ontwerpkeuzes.
Fabrikanten zullen hun eigen implementaties opnieuw moeten beoordelen en aanpassen op gebieden zoals poorttoewijzing, verbindingscontrole en packetvalidatie.
Het proces kan nog enige tijd voortduren zolang de disclosures plaatsvinden.
Daarom zijn architecturale mitigaties net zo belangrijk als updates.
Wat kunnen beheerders doen?
De eerste stap is het up-to-date houden van kernels, hypervisors, besturings- en netwerkproducten, firewalls en gateways. Maar NatJack onderstreept ook het belang van netwerkarchitectuur.
Synack adviseert om te voorkomen dat workloads met verschillende vertrouwensniveaus dezelfde NAT-infrastructuur delen.
Segmentatie via verschillende netwerksegmenten, gateways of beveiligingsdomeinen kan voorkomen dat een niet-vertrouwd systeem toegang krijgt tot hetzelfde NAT-kader als gevoelige systemen.
Intern verkeer zou bovendien versleuteld moeten worden.
TLS wordt vaak gebruikt voor communicatie met internet, maar binnen private netwerken blijven sommige interne diensten onversleuteld, tenzij expliciet versleuteld.
NatJack illustreert waarom deze uitbreiding van vertrouwen problematisch is.
Voor DNS beveelt Synack DNSSEC en versleuteling aan, terwijl mechanismen zoals IP Source Guard kunnen helpen om spoofing te voorkomen.
Ook het beperken van netwerkprivileges voor workloads die ze niet nodig hebben, helpt risico’s te verminderen.
Tot slot: infrastructuurbeheer moet ook gebruik van NAT- en conntrack-tabellen monitoren, evenals patronen in pakketgedrag en onverwachte verbindingstoenames.
De kernboodschap van NatJack is niet dat NAT defect is, maar dat NAT niet automatisch een veiligheidsverdedigingslinie zou moeten zijn tussen workloads met verschillende vertrouwensniveaus.
Deze nuance is vooral relevant in 2026, wanneer technologieën voor het delen van IPv4-adressen nu onderdeel zijn geworden van hypervisors, containers en cloudplatforms, waarop systemen van verschillende gebruikers op gedeelde infrastructuur draaien.
NatJack bewijst dat sommige ontwerpkeuzes uit de tijd dat die scenario’s nog niet bestonden, heroverwogen moeten worden.
Veelgestelde vragen
Wat is NatJack?
NatJack is een klasse aanvallen ontdekt door Malcolm Stagg die misbruik maken van bepaalde gedragingen en vooronderstellingen over vertrouwen in NAT-implementaties. Het omvat technieken tegen TCP, DNS, poorttoewijzing en NAT-tabellen.
Welke systemen zijn getroffen door NatJack?
Testen wijzen op kwetsbaar gedrag in los van elkaar ontwikkelde systemen voor Windows, Linux en macOS. Het concrete risico hangt af van de implementatie, configuratie en architectuur.
Welke CVE’s zijn gerelateerd aan NatJack?
Tot nu toe zijn CVE-2026-56181 (Windows NAT in Hyper-V) en CVE-2026-63913 (netfilter-conntack in Linux) toegewezen. Het onderzoek wordt verder voortgezet.
Hoe kan NatJack worden beperkt?
Naast het installeren van beschikbare updates adviseert Synack het versleutelen van communicatie, het scheiden van workloads, het vermijden van gedeeld NAT tussen verschillende vertrouwensniveaus, DNS-beveiliging zoals DNSSEC, netwerkprivileges beperken en het monitoren van NAT- en conntrack-activiteiten.
Bronnen: