In modern network architecture, we often assume that perimeter defences are robust enough to keep internal traffic secure. However, vulnerabilities inherent in the trust mechanisms of fundamental network protocols reveal that unencrypted tunnels can become fatal backdoors in enterprise intranets.

Research that I presented at Black Hat USA 2025 titled 'From Spoofing to Tunnelling' demonstrates how attackers can leverage IP spoofing combined with common tunnelling protocols - specifically Generic Routing Encapsulation (GRE) and Virtual Extensible LAN (VXLAN) - to infiltrate intranets without initial access credentials.

This research shifts IP spoofing from a simple Distributed Denial of Service (DDoS) mechanism to a stealthy infiltration tool for Red Teams. In this blog post, we'll dissect the three core architectural vulnerabilities highlighted in my research.

Intranet IP spoofing

Traditional lateral movement leaves a clear trail of connection logs on compromised hosts, allowing Incident Response (IR) teams to trace the attack path back to 'patient zero'. My research introduces a technique using 'Intranet IP Spoofing' to create a forensic 'breakpoint', making the attack source nearly impossible to trace via standard Layer 3 logs.

The 'ghost' attack unfolds in three movements.

1. The routing bypass: The internal router, seeing a packet destined for a valid internal host, forwards it. Crucially, when the target replies, it sends the response to the spoofed Source IP (), bypassing the internal router.
2. Direct evasion: The response packet routes directly out to the public Internet through the company's gateway, bypassing the compromised host entirely for the return path. The attacker receives the response directly.

This creates a 'ghost' in the intranet. Network logs on the victim server show connections coming from random public IPs rather than an internal private IP, leading IR teams to suspect external brute force attempts rather than an active internal compromise. If defenders block the attacker's IP, the attacker simply rotates to a new public IP.

To counter Internet Service Providers (ISPs) that drop packets with private source IPs, the research details methods that trigger Source Network Address translation (NAT) to force the router to open a temporary Destination NAT, maintaining bidirectional communication. For instance, triggering the H.323 NAT helper or sending TCP SYN packets can be used to bypass ISP filters.

GRE spoofing initial access: Scanning for invisible tunnels

Can an attacker penetrate an intranet without any internal foothold? The research confirms that widely used, unencrypted GRE tunnels serve as open doors if exposed to the Internet.

The primary challenge is locating the tunnel endpoints. I developed a novel scanning technique using Internet Control Message Protocol (ICMP) encapsulation:

• The attacker sends forged GRE packets to a target router.
• Inside the GRE payload, the attacker encapsulates an ICMP Echo Request.
• The attacker cycles through potential GRE Peer IPs (the internal IP addresses of the tunnel endpoints), encoding these guesses into the ICMP Identifier or Sequence fields.
• If the guess is correct, the victim router decapsulates the packet, processes the ICMP request, and sends a reply. The attacker decodes the reply to confirm the tunnel's existence and its peer IP.

Once the Peer IP is known, the attacker can forge GRE packets from the public Internet that look like they originated from the trusted tunnel peer. This allows the attacker to inject malicious traffic (such as DNS requests or HTTP commands) directly into the intranet. The victim router, trusting the GRE encapsulation, forwards the malicious packets to internal servers, effectively bridging the air gap without a compromised host.

A VXLAN nightmare

VXLAN is a standard for extending Layer 2 networks over Layer 3 infrastructure, common in data centres and Software-Defined Wide Area Network (SD-WANs). My research takes advantage of a default configuration flaw in Linux kernels and MikroTik RouterOS that leads to a security nightmare: The Learning Mode vulnerability.

By default, the VXLAN interface on Linux enables Learning Mode. This means if the interface receives a valid VXLAN packet, with a correct virtual network interface (VNI) and port, it automatically adds the Source IP and MAC address to its Forwarding Database (FDB).

The attack methodology works like this:

1. FDB poisoning: An attacker sends a spoofed VXLAN packet to the target router, setting the inner Source MAC to the broadcast address ().
2. Traffic redirection: The router updates its FDB, believing the attacker's IP is the destination for broadcast traffic. Consequently, when the router needs to send a broadcast packet, like an Address Resolution Protocol (ARP) or Neighbor Discovery Protocol (NDP) request, it replicates the packet and tunnels it directly to the attacker.
3. Topology leakage: By capturing these redirected ARP and NDP packets, the attacker can map the entire internal network topology.

A stark warning

This research serves as a stark warning against the 'implicit trust' found in legacy tunnelling protocols. To secure these architectures, network operations teams must:

• Discontinue unencrypted tunnels: Replace plaintext GRE and VXLAN with encrypted alternatives like IPSec or WireGuard.
• Enforce strict firewalling: Implement Unicast Reverse Path Forwarding (uRPF) to block IP spoofing and filter outbound traffic for abnormal packets, such as unexpected SYN-ACKs from internal ranges.
• Harden routing protocols: Restrict Open Shortest Path First (OSPF) and Border Gateway Protocol (BGP) peering to specific interfaces and monitor for unauthorized route announcements.

Check out the whitepaper I wrote and my presentation slides for a more comprehensive description of this attack vector.

Shu-Hao Tung is a cybersecurity specialist from Taiwan, currently based in Vancouver. He has over four years of penetration testing experience and has presented his research at premier security conferences, including Black Hat USA, DEF CON, and HITCON.

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.