NewsCSO Online

    NatJack exploits put NAT security assumptions to the test at Black Hat

    Share
    For decades, Network Address Translation (NAT) has been the default way IP addresses are provided inside larger networks, as a means to deal with the challenges of IPv4 address availability. The basic premise behind NAT is that private addresses stay private, but that assumption might not be entirely accurate anymore (if it ever really was). At Black Hat USA 2026 , researcher Malcolm Stagg , an independent researcher and Synack Red Team member, disclosed NatJack, an attack class that manipulates the NAT connection tracking table. An attacker sharing a NAT boundary with a victim can hijack active connections, poison DNS responses, and force denial of service , without the IP spoofing or broadcast domain access older Layer 2 attacks required. Thirteen vendors were notified, and testing covered 32 products and configurations across 95 reports. Every tested implementation was vulnerable to some or all of the NatJack techniques. Stagg didn’t intentionally set out to find flaws in NAT, but he found them. “I kind of ran into this attack entirely by accident,” Stagg told Network World . “I noticed that I was sometimes getting responses that didn’t correspond to the packets that I was sending. That told me that there is some sort of corruption happening inside the NAT table.” What breaks in the NAT trust model NAT was never built as a security control. It emerged in the early 1990s as a stopgap for IPv4 address exhaustion , letting multiple devices share one public IP address under an assumption of trust between peers. “I think it basically goes back to under-specification in some of the RFCs that just allow behaviors based on the assumption that you’re in a network where the peers are trusted,” Stagg said. NAT has been hacked before. Security researcher Samy Kamkar disclosed NAT Pinning at DEF CON 18 and Black Hat in 2010, an early technique for manipulating NAT port behavior. He returned to the problem a decade later with NAT Slipstreaming, disclosed in 2020 and expanded with Armis researchers in 2021, which abused Application Level Gateway (ALG) connection tracking and required a victim to visit a malicious website. Those flaws have all been patched. NatJack is different. It manipulates the NAT table directly, needs no ALG, and requires no victim action beyond an active connection through the same NAT. The flaw does not stop at Layer 2. VLAN segmentation and switch port isolation do not help, since the attack targets shared NAT infrastructure at Layer 3 and Layer 4 rather than the local broadcast domain. The flaw was confirmed across Windows, Linux, and macOS despite no shared NAT codebase, pointing to a shared design assumption rather than an isolated bug. Four attack techniques, one shared weakness NatJack covers four distinct techniques, all built on the same weakness in how NAT tables track connections. TCP connection hijacking. An attacker forces a victim’s connection into a closed state using spoofed packets, then replaces the resulting table entry with one pointing to the attacker. The RFC 1337 TIME-WAIT Assassination mechanism Stagg identified lets this happen in a handful of packets rather than a standard connection timeout. DNS response poisoning. The technique intercepts and alters UDP DNS responses passing through the NAT, redirecting a victim’s lookups without their knowledge. Denial of service. An attacker exhausts the NAT table itself, breaking connectivity for every device sharing that NAT. Connection port identification. An attacker determines which port a NAT has assigned to an active connection, information that can support the other three techniques. Disclosure and a mixed vendor response Stagg responsibly disclosed the flaw, though vendor reaction has varied widely, from formal patches to outright rejection. The Linux kernel security team initially dismissed the report, going so far as to call the report- totally bogus. Stagg said the response caught him off guard. “I was pretty surprised by that,” Stagg said. “Getting that response was a little bit unexpected, and a little discouraging.” The kernel was eventually patched at Microsoft’s request to support Azure Kubernetes Service, resulting in CVE-2026-63913. Microsoft’s own Windows NAT vulnerability, affecting Hyper-V, was assigned CVE-2026-56181. Other vendors declined to classify the findings as vulnerabilities. “These reports are design-level NAT limitations rather than security vulnerabilities,” Cisco PSIRT said. “There are documented mitigations for the Cisco Secure Firewall and Cisco IOS XE products which would prevent most, if not all of these issues.” Apple took a similar position. “We’ve determined the behavior reflects a known limitation of the transport layer rather than a vulnerability,” Apple Product Security said. “Modern security models assume the local network may be hostile. This is why we continue to rely on end to end encryption, such as TLS.” Stagg noted that while encryption blunts the worst outcomes of NatJack, it does not eliminate the risk. “Encryption is a great help here because an attacker can still hijack a connection, but if they do, they can’t send or receive any data over that connection unencrypted,” Stagg said. “An attacker can still target and remove any of those connections.” Detection and mitigation Even without full patches available, there are steps that network professionals can take to limit risk. Stagg suggests the following: Monitor for compromise indicators. Watch for a full or near-full NAT table, floods of TCP or UDP packets across a wide port range, the same IP address appearing at two physical locations, and anomalous SYN or RST packet sequences. Enable source IP protection. Turn on protections such as IP Source Guard to block spoofed packets at the router or firewall. Segment untrusted traffic. Place untrusted users on a separate subnet or VLAN, and cap connections per client at roughly under 10,000. Disable loose connection modes. Turn off loose connection tracking, port preservation, and endpoint-independent mapping where supported. Restrict container network access. Disable network access for untrusted containers and Kubernetes workloads, avoid running as root, and drop default capabilities. Isolate cloud workloads. Keep untrusted and trusted workloads off the same NAT gateway, and use dedicated IPs for serverless workloads. “One of the attack variations does still work in cases where the attacker and victim are located in different subnets,” Stagg said. Stagg said the underlying lesson of NatJack extends beyond any single patch. “A lot of networks are vulnerable to this, and you can’t always rely on the Layer 2 isolations that are in place,” Stagg said. “When you’re relying on historical design choices, those threat models might not be the same now as they were back then. It’s important to look at those design assumptions and see if there are any updates that might be necessary based on the new threat models.

    Affected vendors and products

    More on NatJack

    Other news entries

    Source: https://www.csoonline.com/article/4206299/natjack-exploits-put-nat-security-assumptions-to-the-test-at-black-hat-2.html

    ID