Black Hat Reveals NatJack Exploits in NAT Security
Black Hat - NatJack Exploits Test NAT Security Assumptions 🚀
At Black Hat USA 2026, researcher Malcolm Stagg, an independent researcher and member of the Synack Red Team, disclosed the NatJack attack class, which exposes a significant design flaw in decades of network infrastructure. This attack manipulates the NAT connection tracking table, allowing an attacker sharing a NAT boundary with a victim to hijack active connections, poison DNS responses, and force denial of service, all without the need for IP spoofing or broadcast domain access required by older Layer 2 attacks.
Thirteen vendors were notified, and testing covered 32 products and configurations across 95 reports. Alarmingly, every tested implementation was found vulnerable to some or all of the NatJack techniques.
Key Insights:
- NAT was never designed as a security control; it emerged in the early 1990s as a workaround for IPv4 address exhaustion, enabling multiple devices to share one public IP address.
- Stagg emphasized that the flaw stems from under-specification in some RFCs, which assume that peers in a network are trusted.
- NatJack directly manipulates the NAT table, requiring no Application Layer Gateway (ALG) and no action from the victim beyond maintaining an active connection through the same NAT.
Attack Techniques:
NatJack encompasses four distinct techniques:
- TCP connection hijacking (leveraging RFC 1337 TIME-WAIT Assassination)
- DNS response poisoning
- Denial of service (by exhausting the NAT table)
- Connection port identification
Stagg responsibly disclosed these vulnerabilities, but vendor reactions have varied. The Linux kernel was patched, resulting in CVE-2026-63913, while Microsoft’s Windows NAT vulnerability affecting Hyper-V was assigned CVE-2026-56181. Some vendors, like Cisco and Apple, have downplayed these findings as design-level limitations rather than security vulnerabilities.
Mitigation Strategies:
Even without full patches, network professionals can take proactive steps to limit risk:
- Monitor for indicators of compromise, such as a full NAT table or unusual SYN/RST packet sequences.
- Enable source IP protection like IP Source Guard to block spoofed packets.
- Segment untrusted traffic, disable loose connection modes, restrict container network access, and isolate cloud workloads by keeping untrusted and trusted workloads off the same NAT gateway.
Stagg concluded, “A lot of networks are vulnerable to this, and you can’t always rely on the Layer 2 isolations that are in place.” It’s crucial to reassess historical design assumptions and determine if updates are necessary based on new threat models.
For further details, read the complete article here: Read full article