NatJack Attacks: Defending Against NAT Table Manipulation, TCP Session Hijacking, and DNS Spoofing

At Black Hat USA 2026, security researcher Malcolm Stagg disclosed NatJack — a new class of attacks that manipulates Network Address Translation (NAT) connection state to achieve outcomes defenders have historically assumed required on-path interception or endpoint compromise. According to the research, NatJack enables an attacker to:

Hijack active TCP sessions traversing a NAT device
Spoof DNS responses to NAT'd clients, redirecting them to attacker-controlled infrastructure
Expose mapped ports that administrators believed were internal-only
Exhaust NAT translation tables, causing denial of service for every host behind the device

Critically, the research found vulnerable behavior across independently developed implementations — including Windows — which tells us this is not a single-vendor bug with a single patch. This is a protocol-behavior class of weakness in how NAT state is created, matched, and expired. If you operate Windows-based NAT (WinNAT, ICS, RRAS, Hyper-V NAT, WSL2 networking), Linux netfilter/conntrack, or commercial firewall/NAT appliances, you should assume exposure until your vendor publishes guidance.

No CVE identifiers have been published with the initial disclosure, and as of this writing there is no confirmed in-the-wild exploitation — but the attack primitives are reliable enough, and the presentation is public enough, that detection engineering and hardening should start now, not after the first campaign.

Why Defenders Should Care

NAT is a silent trust boundary in nearly every environment we defend. SOC playbooks routinely treat "the traffic came from our NAT'd internal host" as a scoping shortcut. NatJack breaks that assumption in three ways that matter operationally:

Session integrity is no longer guaranteed by the NAT device. An attacker who can predict or influence NAT state can inject into or take over an established TCP session — think hijacked administrative sessions, poisoned software update channels, or intercepted API traffic.
DNS spoofing through NAT manipulation defeats resolver hardening done at the host alone. If forged responses arrive appearing to come from your legitimate resolver, endpoint DNS controls that only validate the query path (not response authenticity, e.g., no DNSSEC/DoH) will accept them.
NAT table exhaustion is a low-and-slow availability kill. Filling a conntrack table silently drops new flows for every host behind the device — and most monitoring stacks don't alert on translation table utilization until the outage is already user-visible.

Technical Analysis

Affected Platforms

Per the disclosure, vulnerable behavior was identified across independently developed NAT implementations, with Windows explicitly named. Given how NAT is implemented across the industry (stateful connection tracking keyed on 5-tuple, with varying strictness around sequence number validation, port prediction, and timeout handling), defenders should treat the following as potentially in scope pending vendor confirmation:

Windows NAT components: WinNAT (vmswitch/Hyper-V and WSL2 NAT), Internet Connection Sharing, RRAS NAT, and static mappings created via New-NetNatStaticMapping or netsh interface portproxy
Linux netfilter/conntrack (iptables/nftables masquerade and DNAT), where behavior is heavily influenced by sysctl tunables like net.netfilter.nf_conntrack_tcp_loose
Embedded and SOHO NAT in routers, firewalls, and carrier-grade NAT (CGNAT) — historically the weakest on strict TCP state validation

How the Attack Works (Defender's View)

NatJack is not a memory-corruption exploit — it is state manipulation of the NAT translation table. The attack chain, generalized:

Reconnaissance of NAT behavior: The attacker probes how the target NAT device allocates external ports, how predictable its port/sequence mapping is, and how strictly it validates inbound packets against existing translation entries. Loosely-validating implementations accept packets that merely look like they belong to an established mapping.
State injection or prediction: By crafting packets that match (or collide with) an existing or predictable NAT entry, the attacker causes the NAT device to forward attacker-controlled traffic to an internal host as if it were part of a legitimate session. For TCP, this enables session hijacking/injection; for UDP-based DNS, it enables spoofed responses that beat the legitimate resolver's answer.
Port exposure: Manipulated or guessed mappings can cause the NAT device to forward unsolicited external traffic to internal ports the administrator never intended to publish — effectively turning a prediction weakness into an unauthorized port forward.
Table exhaustion: By forcing the NAT device to create vast numbers of translation entries (trivially done with randomized source ports/IPs), the attacker exhausts the finite conntrack table. New legitimate connections fail silently.

The exploitation requirements are modest: no authentication, no endpoint foothold, and in many scenarios only the ability to send crafted packets to the NAT device's external interface (or to induce an internal host to make outbound connections the attacker can observe, e.g., via an attacker-controlled website).

Exploitation Status

Public research: Yes — presented at Black Hat USA 2026 with demonstrated attacks.
CVEs: None published at time of writing.
Confirmed in-the-wild exploitation: Not yet reported.
CISA KEV: Not listed (no CVE assigned).

Treat this as pre-weaponization disclosure — the window where detection and hardening are cheap. That window closes fast once tooling based on the talk circulates.

Detection & Response

NatJack operates at the network/NAT layer, so detection leans on firewall/NAT telemetry, DNS response validation, and connection-table monitoring. The detections below focus on four observable behaviors: unauthorized NAT configuration changes (pre-positioning or post-exploitation persistence), DNS responses from non-approved resolvers, NAT/conntrack table exhaustion patterns, and anomalous inbound flows to ports that were never explicitly published.

Sigma Rules

YAML

---
title: Unauthorized NAT Static Mapping or Port Proxy Creation on Windows
id: 3f8a2c71-9b4e-4d12-a7c6-5e1f0b9d8a34
status: experimental
description: Detects creation of NAT static mappings or netsh portproxy rules on Windows hosts. NatJack-style attacks and attacker persistence can leverage unauthorized port mappings to expose internal services; legitimate mappings are rare and change-controlled.
references:
  - https://thehackernews.com/2026/08/new-natjack-attacks-hijack-tcp-sessions.html
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.defense_evasion
  - attack.command_and_control
  - attack.t1090
logsource:
  category: process_creation
  product: windows
detection:
  selection_netnat:
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - 'New-NetNatStaticMapping'
      - 'Add-NetNatStaticMapping'
      - 'New-NetNat '
  selection_netsh:
    Image|endswith: '\netsh.exe'
    CommandLine|contains:
      - 'portproxy'
      - 'addrule'
  condition: selection_netnat or selection_netsh
falsepositives:
  - Hyper-V, WSL2, Docker Desktop, and container networking setup legitimately create NAT objects and mappings
  - Authorized network administration during change windows
level: high
---
title: DNS Response Received From Non-Approved Resolver
id: 7c2e9f14-3a8b-4d65-b1e9-0f4c6a2d7b51
status: experimental
description: Detects DNS responses arriving from source addresses outside the organization's approved resolver set. NatJack DNS spoofing delivers forged responses that may originate from unexpected sources or race the legitimate resolver; any response from a non-approved resolver is high-signal in environments with enforced DNS egress.
references:
  - https://thehackernews.com/2026/08/new-natjack-attacks-hijack-tcp-sessions.html
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.command_and_control
  - attack.credential_access
  - attack.t1071.004
logsource:
  category: firewall
  product: generic
detection:
  selection:
    DestinationPort: 53
    Direction: inbound
  filter_approved_resolvers:
    SourceIp:
      - '10.0.0.53'       # replace with approved internal resolvers
      - '10.0.1.53'       # replace with approved internal resolvers
  condition: selection and not filter_approved_resolvers
falsepositives:
  - Misconfigured hosts with hardcoded public resolvers (which should itself be remediated)
  - ISP-level transparent DNS interception on unmanaged egress
level: medium
---
title: NAT or Conntrack Table Exhaustion Indicator on Linux Gateway
id: a1d4e7c2-6f09-4b38-9c52-8e3b1d6f4a07
status: experimental
description: Detects signs of conntrack table pressure on Linux NAT gateways - kernel drops logged by nf_conntrack (table full, dropping packet). Matches the NatJack table-exhaustion denial-of-service technique and general conntrack exhaustion conditions.
references:
  - https://thehackernews.com/2026/08/new-natjack-attacks-hijack-tcp-sessions.html
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.impact
  - attack.t1498
logsource:
  product: linux
  service: kern
detection:
  selection:
    - 'nf_conntrack: table full, dropping packet'
    - 'conntrack: table full'
falsepositives:
  - Legitimate connection surges on undersized gateways - still actionable as capacity signal
level: high

Tuning note: The DNS resolver rule must be customized with your actual approved resolver IPs before deployment. In environments without enforced DNS egress, deploy it in audit mode first — the output doubles as a misconfiguration inventory.

KQL Hunting — Microsoft Sentinel / Defender

The following queries assume firewall/NAT logs are ingested via CEF/Syslog (CommonSecurityLog) and endpoint telemetry via Defender (DeviceNetworkEvents, DeviceProcessEvents).

KQL — Microsoft Sentinel / Defender

// Query 1: Hunt DNS responses arriving from non-approved resolvers (NATJack DNS spoof indicator)
let ApprovedResolvers = dynamic(["10.0.0.53", "10.0.1.53"]); // replace with your resolver IPs
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DestinationPort == 53
| where not(SourceIP in~ (ApprovedResolvers))
| summarize ResponseCount = count(), DistinctClients = dcount(DestinationIP) by SourceIP, DeviceVendor, DeviceProduct
| where ResponseCount > 20
| sort by ResponseCount desc;

// Query 2: NAT table exhaustion pattern - surge in unique source ports/flows to gateway external interface
CommonSecurityLog
| where TimeGenerated > ago(1h)
| where DeviceAction in ("deny", "drop", "Discard")
| summarize DroppedFlows = count(), UniqueSrcPorts = dcount(SourcePort), UniqueSrcIPs = dcount(SourceIP) by DestinationIP, bin(TimeGenerated, 5m)
| where DroppedFlows > 5000 or UniqueSrcPorts > 30000
| sort by TimeGenerated desc;

// Query 3: Endpoint view - processes creating NAT mappings or portproxy rules (Windows)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where (FileName =~ "netsh.exe" and ProcessCommandLine has_any ("portproxy", "addrule"))
   or (FileName =~ "powershell.exe" and ProcessCommandLine has_any ("New-NetNatStaticMapping", "Add-NetNatStaticMapping"))
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by TimeGenerated desc;

// Query 4: Established sessions with anomalous remote endpoints on NAT'd hosts - possible session hijack follow-on
DeviceNetworkEvents
| where TimeGenerated > ago(24h)
| where ActionType == "ConnectionSuccess"
| where RemoteIP !startswith "10." and RemoteIP !startswith "192.168." and RemoteIP !startswith "172.16."
| summarize ConnCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by DeviceName, LocalPort, RemoteIP, RemotePort, InitiatingProcessFileName
| where ConnCount > 100 and LocalPort between (30000 .. 65000)
| sort by ConnCount desc;

Velociraptor VQL

Use this artifact to audit Windows hosts for existing NAT/portproxy mappings (both attacker-created and shadow-IT) and to snapshot established sessions for anomaly review:

VQL — Velociraptor

-- Audit Windows NAT static mappings, portproxy rules, and suspicious established sessions
-- Detects unauthorized port exposure relevant to NatJack-style NAT manipulation

LET mappings <= SELECT * FROM execve(
   argv=["powershell.exe", "-NoProfile", "-Command",
         "Get-NetNatStaticMapping | Format-List *; Write-Output '---PORTPROXY---'; netsh interface portproxy show all"]
)

LET sessions <= SELECT Pid, Name, LocalAddr, LocalPort, RemoteAddr, RemotePort, State
FROM netstat()
WHERE State =~ 'ESTABLISHED'
  AND RemoteAddr =~ '^[0-9]'
  AND NOT RemoteAddr =~ '^(10\\.|192\\.168\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.|127\\.)'
  AND LocalPort > 30000

SELECT * FROM mappings
UNION ALL
SELECT Pid AS Stdout_Line, Name, LocalAddr, LocalPort, RemoteAddr, RemotePort, State, NULL AS Extra FROM sessions

For fleet-wide hunting, deploy the mapping-audit portion as a hunt and diff results against your known-good baseline (WSL2/Docker defaults, Hyper-V vNIC NAT, documented admin mappings). Any static mapping that isn't in your CMDB is an incident until proven otherwise.

Remediation & Hardening Script

Windows: audit and reduce the NAT attack surface; Linux gateway: tighten conntrack TCP state validation and add exhaustion safeguards.

PowerShell

# NatJack Defense: Windows NAT attack-surface audit and hardening
# Run elevated on Windows hosts functioning as NAT (Hyper-V host, ICS, RRAS, container hosts)

Write-Output "=== Enumerating NAT objects ==="
Get-NetNat | Format-Table Name, InternalIPInterfaceAddressPrefix, ExternalIPInterfaceAddressPrefix -AutoSize

Write-Output "=== Enumerating static NAT mappings (investigate any entry not in your CMDB) ==="
Get-NetNatStaticMapping | Format-Table NatName, Protocol, ExternalIPAddress, ExternalPort, InternalIPAddress, InternalPort -AutoSize

Write-Output "=== Enumerating netsh portproxy rules ==="
netsh interface portproxy show all

# Remove an unauthorized static mapping (example - validate before executing)
# Remove-NetNatStaticMapping -StaticMappingID <ID> -Confirm:$false

# Remove an unauthorized portproxy rule (example)
# netsh interface portproxy delete v4tov4 listenport=8080 listenaddress=0.0.0.0

Write-Output "=== Checking ICS service state (should be disabled if not required) ==="
$ics = Get-Service -Name SharedAccess -ErrorAction SilentlyContinue
if ($ics.Status -eq 'Running' -and $ics.StartType -ne 'Disabled') {
    Write-Warning "Internet Connection Sharing is running. Disable if not explicitly required:"
    Write-Output "  Stop-Service SharedAccess; Set-Service SharedAccess -StartupType Disabled"
}

Write-Output "=== Auditing recent NAT-related command execution (last 7 days) ==="
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=(Get-Date).AddDays(-7)} -ErrorAction SilentlyContinue |
  Where-Object { $_.Message -match 'portproxy|NetNatStaticMapping|New-NetNat' } |
  Select-Object TimeCreated, @{n='Command';e={($_.Message -split "`n") -match 'Process Command Line'}} |
  Format-List

Bash / Shell

#!/bin/bash
# NatJack Defense: Linux NAT gateway hardening (netfilter/conntrack)
# Apply to iptables/nftables NAT gateways. Test in staging - strict mode can affect asymmetric routing.

echo "=== Current conntrack utilization ==="
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

echo "=== Applying strict TCP connection tracking (rejects out-of-window packets - core NatJack countermeasure) ==="
sysctl -w net.netfilter.nf_conntrack_tcp_loose=0

# Enable TCP sequence/ACK timestamp sanity checks where available
echo "=== Enabling strict TCP be-liberal OFF and timestamps check ==="
sysctl -w net.netfilter.nf_conntrack_tcp_be_liberal=0 2>/dev/null || echo "knob not present on this kernel"

# Size conntrack table appropriately and shorten timeouts to blunt exhaustion
echo "=== Raising conntrack ceiling and tightening timeouts ==="
sysctl -w net.netfilter.nf_conntrack_max=1048576
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=7200
sysctl -w net.netfilter.nf_conntrack_udp_timeout=60
sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=120

# Persist across reboot
cat > /etc/sysctl.d/99-natjack-hardening.conf <<'EOF'
net.netfilter.nf_conntrack_tcp_loose = 0
net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_tcp_timeout_established = 7200
net.netfilter.nf_conntrack_udp_timeout = 60
net.netfilter.nf_conntrack_udp_timeout_stream = 120
EOF

echo "=== Rate-limiting new inbound connections to blunt table exhaustion (adjust interface) ==="
iptables -A INPUT -i eth0 -p tcp --syn -m conntrack --ctstate NEW -m limit --limit 200/second --limit-burst 400 -j ACCEPT

# Only accept inbound packets matching existing conntrack entries on the external interface
echo "=== Enforcing conntrack state match on inbound external traffic ==="
iptables -A INPUT -i eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth0 -m conntrack --ctstate INVALID -j DROP

echo "=== Adding conntrack utilization logging for SOC monitoring ==="
(conntrack -E 2>/dev/null | logger -t conntrack-event &) || echo "conntrack-tools not installed: apt/yum install conntrack"

echo "Done. Validate application flows after enabling strict mode - asymmetric routes may drop."

Remediation & Strategic Mitigations

Until vendors publish NatJack-specific guidance and patches, prioritize these layered controls:

Immediate (this week):

Inventory every device performing NAT in your environment — including the ones nobody thinks about: Hyper-V hosts, WSL2/Docker developer workstations, RRAS servers, ICS-enabled machines, and SOHO gear in remote offices. You cannot defend a translation table you don't know exists.
Enforce strict TCP state validation on Linux netfilter gateways (nf_conntrack_tcp_loose=0 per the script above). This is the single highest-impact hardening step against loose-state NAT injection. For commercial firewalls, engage your vendor now and ask explicitly whether their NAT implementation validates TCP sequence windows against translation state.
Deploy DNS response authenticity controls: Enforce DNS over HTTPS/TLS to approved resolvers, enable DNSSEC validation where upstream supports it, and block outbound port 53 from all endpoints except sanctioned resolvers. A forged response that can't validate is a dead forged response.
Baseline and alert on conntrack/NAT table utilization. Add utilization thresholds (e.g., alert at 70%, page at 85%) and forward nf_conntrack: table full kernel events to your SIEM — the Sigma rule and KQL above operationalize this.

Short-term (30 days): 5. Audit and remove all undocumented static NAT mappings and portproxy rules. Treat any unexplained mapping as an incident. 6. Segment NAT'd networks so that a hijacked session or exposed port behind a shared NAT cannot reach crown-jewel systems. East-west controls absorb the blast radius that NAT-layer attacks create. 7. Apply Windows updates promptly as Microsoft publishes guidance — Windows is explicitly named as affected, and a security update addressing NAT state handling should be expected through normal channels. Subscribe to the Microsoft Security Response Center advisories and your firewall vendor's PSIRT feed.

Monitoring posture going forward:

Track unauthorized NAT configuration changes as a high-fidelity detection (rare, high-signal event).
Watch for DNS response races and duplicate responses for the same transaction ID in Zeek/Suricata if you run network sensors — forged responses often arrive alongside or ahead of legitimate ones.
Include NAT-device telemetry in your IR scoping templates: if a session hijack is suspected, the translation table state and change history are forensic evidence.

NatJack is a reminder that the network plumbing we treat as infrastructure is itself an attack surface with exploitable state. The organizations that harden conntrack behavior, lock down DNS egress, and inventory their NAT estate this quarter will be the ones reading about the first NatJack campaign instead of responding to it.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub