GBHackers

New NatJack NAT Attack Lets Hackers Hijack TCP Connections and DNS Responses


A newly disclosed attack class, NatJack, reveals significant weaknesses in the implementation of Network Address Translation (NAT) across modern network infrastructures.

This vulnerability allows attackers to hijack TCP connections, tamper with DNS responses, and disrupt traffic flow.

NatJack specifically targets the NAT state table, highlighting that traditional assumptions about cooperative network behavior are no longer applicable in today’s hostile, multi-tenant environments. As a result, NAT devices may become powerful pivot points rather than secure boundaries.

New NatJack NAT Attack

NatJack is a series of NAT table manipulation techniques that enable a malicious actor behind a NAT device to interfere with existing traffic flows. By carefully crafting spoofed packets, an attacker can alter or replace NAT mappings in real-time.

This manipulation can cause traffic meant for a victim’s connection to be redirected to an attacker-controlled endpoint. At the same time, the upstream server continues to view the connection as legitimate.

The attack family enables multiple outcomes:

  • TCP hijacking of existing connections (downstream and upstream spoofing)
  • UDP DNS hijacking, altering responses to redirect victims to malicious domains
  • Victim IP/port information disclosure, leaking external NAT port usage
  • Denial of service, by corrupting or tearing down NAT state for active flows

Additionally, these weaknesses enable interception and modification of UDP DNS responses. They can be exploited to disrupt or corrupt live sessions, resulting in denial-of-service conditions for targeted applications and services.

NatJack research emphasizes that NatJack is not a singular vendor issue but rather a systemic design flaw affecting a wide range of network devices, including routers, firewalls, hypervisors, virtual switches, and cloud networking services that use NAT.

So far, testing indicates that all evaluated NAT-capable devices, from consumer hardware to enterprise solutions and virtual platforms, are vulnerable to some or all variants of NatJack.

This includes container networking stacks such as Docker and Kubernetes bridges, as well as hypervisor NAT implementations.

Many of these platforms were designed with the assumption that internal tenants or workloads could be treated as mostly trustworthy, an assumption that is increasingly undermined in environments where compromised containers, VMs, or user devices coexist with sensitive services on the same NAT infrastructure.

For home users, consumer-grade routers are likely vulnerable at the implementation level; however, the actual risk is generally low. Exploitation typically requires an untrusted or compromised device already located behind the same router, with sufficient privileges to generate crafted packets.

TCP HIjacking – Source: Natjack

In contrast, enterprises, service providers, and cloud tenants face a much higher risk, as typical network architectures mix untrusted user endpoints, internet-facing services, and high-value internal systems behind shared routers, firewalls, NAT gateways, and load balancers.

In these environments, an attacker who gains access to any internal host or workload behind the NAT could leverage NatJack to interfere with traffic from more sensitive systems that share the same NAT device, even if they are on different subnets or VLANs.

Multiple vendors have started implementing partial mitigations. Microsoft has addressed a NatJack-related issue in its Windows NAT implementation affecting Hyper-V scenarios via CVE-2026-56181.

This update reduces the feasibility of downstream spoofing attacks in affected configurations. The Linux kernel’s Netfilter subsystem has been updated with patches under CVE-2026-63913 in Linux 7.1 and later, fixing a specific code flaw and adding mitigations that increase the complexity of manipulating NAT state.

However, these changes are not considered a complete solution. FreeBSD’s Packet Filter received hardening in version 15.0 via a patch inherited from OpenBSD, which significantly reduces the feasibility of both downstream and upstream spoofing in many deployments, while still leaving room for further improvements.

Cloud providers are also taking action. AWS has confirmed that its NAT Gateway and Network Load Balancer services have been reviewed and hardened to improve connection state validation, particularly TCP reset handling, and to extend port hold times to block the NAT flow manipulation patterns outlined in the research.

According to AWS, successful exploitation would require an attacker to control an EC2 instance within the same VPC as the target connection, and in some cases, access to a cooperating spoof-capable external server. However, the newly deployed changes are designed to neutralize these threats without requiring customer action.

The overall defensive guidance for organizations is to stop treating NAT as a security control, promptly apply vendor updates, review multi-tenant designs where untrusted and high-value workloads share NAT devices, and enhance segmentation at the router, firewall, and node levels to limit the impact of any compromised tenant.

Stop new phishing & malware before they compromise your business. Integrate live intel from 15K SOCs around the world



Source link