Wprowadzenie do problemu / definicja
NatJack to nowo opisana klasa ataków wymierzonych w mechanizmy translacji adresów sieciowych (NAT) oraz śledzenia stanu połączeń. Sedno problemu nie dotyczy wyłącznie pojedynczego produktu, ale szerszego założenia projektowego obecnego w wielu implementacjach: urządzenia pośredniczące zwykle ufają, że systemy znajdujące się po tej samej stronie NAT nie będą aktywnie manipulować stanem komunikacji innych hostów.
Badania pokazują jednak, że w środowisku o mieszanym poziomie zaufania takie założenie może zostać złamane. W efekcie napastnik obecny po wewnętrznej stronie NAT może wpływać na wpisy mapowań oraz logikę connection tracking, uzyskując dostęp do cudzych sesji lub zakłócając ich działanie.
W skrócie
NatJack pozwala manipulować wpisami w tablicach NAT w sposób, który może prowadzić do przejęcia aktywnych sesji TCP, przekierowania odpowiedzi DNS, ujawnienia informacji o mapowaniach portów oraz wyczerpania zasobów tablicy połączeń. To sprawia, że problem wykracza poza klasyczne routery i obejmuje również firewalle, platformy wirtualizacyjne, środowiska kontenerowe oraz wybrane usługi chmurowe.
- możliwe jest przejęcie lub zakłócenie aktywnej komunikacji TCP,
- atak może objąć ruch UDP, w tym odpowiedzi DNS,
- napastnik może odtworzyć informacje o mapowaniach portów zewnętrznych,
- w skrajnych przypadkach możliwe jest doprowadzenie do odmowy usługi poprzez przeciążenie tablic NAT.
W obszarze tym ujawniono również dwie konkretne podatności implementacyjne: CVE-2026-56181 w Windows NAT oraz CVE-2026-63913 w linuxowym Netfilter conntrack. W większości scenariuszy warunkiem powodzenia pozostaje obecność atakującego lub przejętego systemu po tej samej stronie NAT co ofiara.
Kontekst / historia
Choć zagadnienie manipulacji stanem NAT nie jest całkowicie nowe, NatJack porządkuje je jako odrębną i systemową klasę ataków na infrastrukturę sieciową. Publiczne ujawnienie tematu nastąpiło w sierpniu 2026 roku podczas konferencji Black Hat USA 2026, co zwróciło uwagę branży na ryzyko, które do tej pory bywało marginalizowane.
Istotne jest to, że mowa nie tylko o urządzeniach brzegowych. Dzisiejsze środowiska IT, takie jak Docker, Kubernetes, Hyper-V czy platformy chmurowe, szeroko wykorzystują wirtualne przełączniki, mosty i mechanizmy translacji. W praktyce oznacza to, że dziedziczą podobne założenia bezpieczeństwa i mogą być podatne na analogiczne nadużycia, szczególnie gdy zaufane i niezaufane obciążenia współdzielą tę samą warstwę sieciową.
Analiza techniczna
Mechanizm NatJack opiera się na wpływaniu na stan mapowań połączeń utrzymywanych przez NAT oraz powiązane moduły connection tracking. Jeżeli atakujący znajduje się po stronie wewnętrznej urządzenia NAT, może w określonych warunkach doprowadzić do podmiany, usunięcia lub przejęcia wpisu należącego do innego hosta.
W wariancie dotyczącym TCP konsekwencją może być przejęcie aktywnej sesji. Otwiera to drogę do podszywania się pod ofiarę wobec zewnętrznego serwera, przechwytywania danych aplikacyjnych, wstrzykiwania własnych pakietów oraz przerywania długotrwałych połączeń.
Drugi scenariusz obejmuje UDP, zwłaszcza zapytania DNS. Jeśli napastnik zdoła zmanipulować wpis skojarzony z takim ruchem, prawidłowa odpowiedź DNS może trafić do niego zamiast do klienta. Następnie możliwe staje się dostarczenie ofierze spreparowanej odpowiedzi, co prowadzi do przejęcia procesu rozwiązywania nazw, przekierowania ruchu lub lokalnej odmowy usługi.
Kolejna technika polega na ujawnianiu informacji o mapowaniach portów i aktywnych wpisach NAT. Gdy implementacja wykorzystuje przewidywalny schemat przydziału portów efemerycznych albo pozwala wnioskować o stanie tablicy na podstawie przygotowanego ruchu sondującego, atakujący może odtworzyć zewnętrzny port ofiary, a czasem również powiązać go z konkretnym hostem wewnętrznym.
Ostatni praktyczny wariant to wyczerpanie tablicy połączeń poprzez wygenerowanie dużej liczby spreparowanych przepływów. W takiej sytuacji legalni użytkownicy mogą utracić możliwość ustanawiania nowych sesji, co bezpośrednio przekłada się na spadek dostępności usług.
Na poziomie konkretnych implementacji szczególną uwagę zwracają dwa identyfikatory CVE. CVE-2026-56181 dotyczy błędu walidacji pochodzenia w Windows Network Address Translation, który może umożliwiać spoofing z sieci sąsiedniej. Z kolei CVE-2026-63913 odnosi się do linuxowego Netfilter conntrack dla TCP, gdzie możliwe jest wymuszenie przejścia wpisu do stanu zamknięcia przy użyciu pakietu RST z nieprawidłowym numerem sekwencyjnym, bez właściwej weryfikacji kierunku ruchu.
Konsekwencje / ryzyko
Ryzyko związane z NatJack jest najwyższe w środowiskach wielodostępnych i wielotenantowych, gdzie systemy o różnym poziomie zaufania współdzielą jedną warstwę translacji. Dotyczy to przede wszystkim sieci korporacyjnych, klastrów kontenerowych, platform wirtualizacyjnych oraz segmentów chmurowych.
- przejęcie aktywnych sesji TCP,
- modyfikacja lub wstrzyknięcie danych do legalnych połączeń,
- fałszowanie odpowiedzi DNS i przekierowanie ofiar do kontrolowanych zasobów,
- ujawnienie informacji pomocnych w dalszej eskalacji ataku,
- degradacja dostępności przez wyczerpanie tablic NAT.
Szczególnie niebezpieczne są scenariusze, w których przejęty kontener, maszyna wirtualna lub host deweloperski współdzieli infrastrukturę NAT z systemami produkcyjnymi. Nawet jeśli brak jest doniesień o masowej eksploatacji, sam charakter problemu pokazuje, że NAT nie powinien być traktowany jako neutralny i bezpieczny z definicji element pośredniczący.
Rekomendacje
Organizacje powinny potraktować NatJack jako impuls do przeglądu architektury sieciowej, a nie wyłącznie jako pojedynczą podatność wymagającą aktualizacji. Ponieważ badacze wskazują na systemowy charakter zagrożenia, samo wdrożenie poprawek nie usuwa całej klasy ryzyka.
- zaktualizować systemy Windows i Linux do wersji zawierających poprawki dla ujawnionych CVE,
- ściśle rozdzielać zaufane i niezaufane obciążenia współdzielące NAT,
- unikać płaskich, domyślnych konfiguracji sieciowych w Dockerze, Kubernetesie i środowiskach wirtualnych,
- stosować szyfrowanie ruchu również wewnątrz organizacji,
- monitorować anomalie w sesjach TCP, nietypowe resety połączeń, zmiany mapowań i błędy DNS,
- ograniczać możliwość uruchamiania uprzywilejowanych kontenerów i maszyn wirtualnych,
- rozważyć wdrożenie mechanizmów ochrony przed spoofingiem tam, gdzie są dostępne,
- zweryfikować, czy urządzenia brzegowe, firewalle i usługi NAT dostawców chmurowych oferują dodatkowe zabezpieczenia przed manipulacją stanem połączeń.
Dobrą praktyką pozostaje również modelowanie zagrożeń dla ruchu typu east-west, a nie jedynie north-south. NatJack pokazuje bowiem, że skuteczny napastnik nie musi działać z zewnątrz organizacji, aby przejmować lub zakłócać komunikację przechodzącą przez NAT.
Podsumowanie
NatJack to ważny sygnał ostrzegawczy dla zespołów bezpieczeństwa i administratorów infrastruktury. Problem nie ogranicza się do jednego producenta ani pojedynczej wersji oprogramowania, lecz dotyczy samej logiki zaufania obecnej w wielu implementacjach NAT i connection tracking.
Najbardziej zagrożone pozostają środowiska współdzielone, w których napastnik może uzyskać pozycję po wewnętrznej stronie translacji. W praktyce obrona wymaga połączenia dwóch działań: szybkiego wdrożenia dostępnych poprawek oraz długofalowej przebudowy segmentacji, izolacji i granic zaufania w nowoczesnych środowiskach sieciowych.