NatJack nimmt NAT-Tabellen ins Visier: Sitzungen gekapert und Ports offengelegt

Eine Angriffsklasse gegen den Verbindungsstatus

Der Sicherheitsforscher Malcolm Stagg stellte auf der Black Hat USA 2026 NatJack vor – eine Angriffsklasse, die den von NAT-Geräten verwalteten Verbindungsstatus manipuliert.

Die Technik kann es ermöglichen,

• bereits aktive TCP-Sitzungen zu kapern;
• DNS-Antworten zu fälschen;
• aus dem Internet erreichbare Ports zu ermitteln;
• die NAT-Tabelle zu überlasten und dadurch neue legitime Verbindungen zu verhindern.

Der Angriff setzt im Allgemeinen privilegierten Zugriff auf ein System voraus, das sich hinter demselben NAT wie das Ziel befindet. Grundlage ist eine verbreitete Designannahme: Nicht vertrauenswürdige Hosts, die dasselbe Gerät nutzen, sollten den Verbindungsstatus anderer Hosts nicht verändern können.

Die Untersuchung stellte vergleichbare Verhaltensweisen in unabhängig entwickelten Implementierungen fest, darunter auch in den von Windows und Linux verwendeten Komponenten.

Wie NatJack Verbindungen verändert

Bei einer der Techniken wird das einer aktiven TCP-Verbindung zugeordnete NAT-Mapping ersetzt. Der Datenverkehr des Opfers wird dadurch zum Angreifer umgeleitet, wodurch das Abfangen oder Kapern der Sitzung möglich wird.

Ein zweites Szenario betrifft DNS. Der Angreifer kann eine Anfrage des Opfers manipulieren, die legitime Antwort an sich selbst zustellen lassen und dem Client anschließend eine gefälschte Antwort senden.

NatJack kann außerdem eingesetzt werden, um über die externen NAT-Mappings erreichbare Ports zu ermitteln. Bei einem Überlastungsangriff werden dagegen gefälschte Datenströme angelegt, bis der verfügbare Platz in der Tabelle erschöpft ist. Legitime Clients können dann keine neuen Verbindungen mehr aufbauen.

Zu den Auswirkungen zählen somit Session-Hijacking, DNS-Spoofing, die Offenlegung von Diensten und Denial of Service. Nach den zum 7. August 2026 verfügbaren Informationen gibt es keine öffentlichen Belege für eine Ausnutzung in realen Angriffen.

Identifizierte Schwachstellen in Linux und Windows

Unter Linux wurde das Problem als CVE-2026-63913 mit einem CVSS-Score von 8.2 im Netfilter-Conntrack-Modul registriert.

Ein speziell präpariertes SYN-Paket, gefolgt von einem RST-Paket mit einer ungültigen Sequenznummer, kann einen aktiven NAT-Eintrag vorzeitig in den geschlossenen Zustand versetzen. Die Conntrack-Logik überprüft die Richtung des Datenverkehrs nicht korrekt.

Die korrigierten Stable-Releases sind:

• 5.10.259
• 5.15.210
• 6.1.176
• 6.6.143
• 6.12.93
• 6.18.35
• 7.0.12
• 7.1

Laut Stagg behebt die Änderung den Fehler im Code, beseitigt jedoch nicht vollständig die umfassendere Downstream-Spoofing-Technik. Der Angriff wird dadurch komplexer, aber nicht unmöglich.

Unter Windows betrifft die Schwachstelle CVE-2026-56181 das von Hyper-V verwendete NAT und hat einen CVSS-Score von 8.3. Das Problem wird als Fehler bei der Herkunftsvalidierung eingestuft und kann aus einem benachbarten Netzwerk ausgenutzt werden.

Betroffen sind:

• Windows 11 24H2 vor Build 26100.8875;
• Windows 11 25H2 vor Build 26200.8875;
• Windows 11 26H1 vor Build 28000.2525;
• Windows Server 2025 vor Build 26100.33158.

Umfang der Untersuchung und Schutzmaßnahmen

Stagg führte die Analyse im Rahmen von SODIUM-24 durch. Synack zufolge wurden Dutzende realer Netzwerkprodukte verschiedener Hersteller getestet; die Proofs of Concept wurden in kontrollierten Umgebungen ausgeführt.

Eine vollständige produktbezogene Übersicht ist jedoch nicht verfügbar. Neben Windows und Linux könnten daher auch weitere NAT-Implementierungen betroffen sein, allerdings wurden nicht alle potenziell betroffenen Produkte öffentlich identifiziert.

Eine frühere NDSS-Studie aus dem Jahr 2024 hatte bereits das Kapern von TCP-Verbindungen durch die Manipulation von NAT-Mappings gezeigt: 52 der 67 getesteten Router waren anfällig; aus der Analyse gingen zehn CVEs hervor.

Administratoren sollten:

• die für Linux und Windows bereitgestellten Updates installieren;
• nicht vertrauenswürdige Workloads von vertrauenswürdigen Systemen trennen, die dasselbe NAT verwenden;
• den Datenverkehr auch innerhalb von Unternehmensnetzwerken verschlüsseln;
• IP Source Guard aktivieren, sofern verfügbar;
• einzelne Patches nicht als umfassende Lösung für NatJack betrachten.

Für diese Angriffsklasse gibt es keine einheitliche Abhilfe. Segmentierung und Verschlüsselung bleiben auch nach der Aktualisierung der Systeme erforderlich.