New Red Team Networking Techniques for Initial Access and Evasion

New Red Team Networking Techniques for Initial Access and Evasion

Speaker: Su Hao Tung, Red Team Threat Researcher, Trend Micro

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=terPgwzk3dc

Reading Time: ~8 minutes

Type: Briefing

TL;DR

Su Hao Tung of Trend Micro demonstrates how attackers can exploit IP spoofing, stateless tunneling protocols (GRE, VXLAN), and misconfigured routing protocols (OSPF) to gain initial access to corporate intranets while creating deliberate breaks in the attack chain that defeat conventional incident response. By forging packet source addresses and hijacking unencrypted tunnels, red teamers can reach internal services without leaving a traceable lateral movement path — and, in the worst cases, compromise an entire Active Directory domain.

Introduction

Most corporate security teams rely on network logs to reconstruct attack chains: trace from the compromised target back to the previous hop, find the initial access point, and shut down the path. That model breaks down when source IP addresses cannot be trusted. In this first Black Hat USA presentation from Trend Micro's Su Hao Tung, the research begins from an unusual IT incident — an internal LDAP server receiving a login attempt from a public IP — and expands into a systematic examination of how stateless, unencrypted network tunnels expose enterprise environments to spoofing, hijacking, and full domain compromise.

The techniques span three categories: WAN-level IP spoofing that erases lateral movement trails, GRE tunnel abuse for initial access from the public internet, and VXLAN tunnel hijacking that opens a path not only to intranet access but to routing protocol manipulation capable of redirecting domain controller traffic to an attacker's machine.

IP Spoofing as an Incident Response Disruptor

▶ Watch: IP Spoofing for Initial Access (02:00)

In a conventional lateral movement scenario, each compromised machine uses its actual IP address to target the next system, creating a log trail that IR teams can walk backward to identify the initial foothold. When IP spoofing enters the picture, that trail disappears. An attacker who has compromised one internal device — say, 10.x.x.3 — can tunnel commands to it from a public C2 server while having the device forward packets whose source IP is an arbitrary public address, such as 9.9.9.9. The target server (10.x.x.2) sees a public IP attacking it, and the IR team investigating that alarm finds no connection to the actually compromised machine.

▶ Watch: Spoofing Technique Walkthrough (06:00)

Tung identifies two NAT abuse techniques that enable this even when ISPs filter private source addresses. The first abuses NAT passthrough (H.323-style): sending a specially crafted packet to the public IP triggers the router to create a temporary destination NAT entry mapping a public port directly to an internal service. The web server's logs then show the connection originating from a public IP rather than the private pivot machine. The second technique abuses source NAT by spoofing a TCP SYN packet from the next target's IP and port as the source, sending it to the attacker's C2 — the router's SNAT mechanism then creates an entry that allows the attacker to reach the internal service through the router's public IP. In both cases, the internal web server's logs show a public source address, creating a deliberate breakpoint in the forensic chain.

Commercial SSL VPNs and open-source solutions like WireGuard and OpenVPN can serve as the C2 tunnel medium, and at internet exchange points where multiple networks share a layer-2 fabric, attackers can set private subnets as next hops directly toward a victim company's router.

GRE Tunnel Abuse: Finding and Hijacking Existing Infrastructure

▶ Watch: GRE Tunnel Discovery and Exploitation (14:02)

GRE (Generic Routing Encapsulation) is a stateless, unencrypted layer-3 tunneling protocol still widely deployed in enterprise environments — including by cloud providers such as Cloudflare Magic Transit and AWS Transit Gateway. Threat groups have also abused it: Security Week reported that Salt Typhoon used GRE tunnels to exfiltrate traffic from compromised devices.

Because GRE is stateless, it performs no source IP verification. An attacker can forge a GRE packet claiming to originate from a known peer of the victim router. If the inner packet contains a DNS request sourced from a public IP and destined for a private intranet address, the victim router will unpack the GRE header and forward the inner packet into its own intranet according to its routing table. The internal server responds to the public IP across the internet — giving the attacker a bidirectional channel into the intranet without ever owning a device on that network.

The research includes a custom GRE scanner posted to GitHub. Discovery begins with OSINT: searching for Netflow dashboards (such as Aqueduct) and filtering for GRE traffic to identify both tunnel endpoints. The scanner then brute-forces the peer IP by encoding candidate addresses into the ICMP identifier and sequence fields of inner packets (covering all 2^32 possible IPv4 addresses), and listening for ICMP replies that confirm a match. Once the peer is identified, the attacker can send arbitrary traffic into the intranet by impersonating that peer.

VXLAN: The Nightmare Default Configuration

▶ Watch: VXLAN Hijacking (22:02)

VXLAN encapsulates layer-2 Ethernet frames inside layer-4 UDP packets, making it popular for multi-site datacenter connectivity. The critical vulnerability is in the Linux kernel's default "learning mode": when learning is enabled, the kernel accepts VXLAN packets from any source IP, not just configured peers, and adds the sender's MAC-to-IP mapping to its Forwarding Database (FDB). An attacker at 9.9.9.9 can send a VXLAN packet with a broadcast MAC address (FF:FF:FF:FF:FF:FF) and cause the victim's kernel to forward all subsequent broadcasts — including ARP requests — to the attacker's IP. This is not a bug in the traditional sense; it is documented Linux kernel behavior, but it is enabled by default and was not configurable off until recently (and remains on by default today).

Tung built a VXLAN scanner that exploits this behavior to enumerate exposed endpoints. By sending VXLAN packets with different VNI values and default ports (4789 and 8472 — VNIs typically below 100) containing inner NDP (Neighbor Discovery Protocol) messages with broadcast source and destination MACs, the scanner triggers replies from matching configurations. The scanner then has everything needed to hijack the tunnel: victim IP, port, and VNI. No knowledge of the configured peer IP or the internal subnet is required.

A global scan using VNI=1 and default ports found over 900 VXLAN endpoints responding to the scanner, with over 4,000 IPs inside exposed VXLAN subnets — including some public IPs susceptible to IP hijacking. Encrypting the outer tunnel does not fully protect against this: VXLAN still processes traffic on its own interface even inside an encrypted wrapper, preserving the learning-mode vulnerability.

Routing Protocol Abuse: From Tunnel Hijack to Domain Compromise

▶ Watch: OSPF Hijacking and Domain Compromise (32:03)

The consequences of VXLAN hijacking extend well beyond intranet access. Many enterprise VXLAN deployments run dynamic routing protocols — BGP or OSPF — across the tunnels to exchange routes between sites. Once an attacker has injected themselves into the VXLAN fabric, they can participate in these routing protocols and announce more-specific routes (/32) for high-value IPs such as domain controllers or ESXi/vSphere hosts. Other routers in the network, following longest-prefix-match routing, will prefer these /32 routes over existing /24 entries and redirect traffic for those services to the attacker.

The impact table from the research is stark: if the hijacked IP belongs to a domain controller and NTLM relay conditions are met (SMB signing disabled, or AD CS ESC8 present), the result is full domain compromise. If the hijacked IP belongs to a vSphere or Proxmox host whose TLS certificate is self-signed or expired, users may not notice the certificate change and the attacker can capture credentials or serve malicious responses.

A standalone bonus finding: misconfigured OSPF (without authentication) encountered during real red team engagements allows direct OSPF neighbor establishment from the attacker's position. Spotting OSPF Hello packets in a tcpdump capture is the trigger — an attacker can then inject arbitrary routes, including a /32 for the domain controller.

Notable Quotes

"The IR team could only see a public IP attacking their domain controller. Thus, the previous compromised machine would not be caught even if the alarm was triggered."

— Su Hao Tung, 06:00

"After looking at the Linux manual, you will see that it is a feature and not a bug. But at least it's not secure, and it's turned on by default."

— Su Hao Tung, 22:02

"We found that more than 900 VXLAN endpoints responded to our scanner. Additionally, there are 4,000 IPs inside the VXLAN subnet — some of these are public IPs, which means we can potentially hijack public IPs."

— Su Hao Tung, 28:03

"Hijacking this service IP can lead to account takeovers, denial of service during service hijacking, or even full domain compromise."

— Su Hao Tung, 32:03

Key Takeaways

• Audit unencrypted tunnels immediately. GRE, IP/IP, SIT, GRE TAP, and VXLAN are all stateless and unauthenticated by default. Any public-facing system running these protocols is potentially exploitable from the internet.
• Harden firewall egress rules. Firewalls should filter outbound intranet traffic — particularly SYN-ACK packets — and check for IP spoofing within the intranet perimeter.
• Disable VXLAN learning mode. Set nolearning on VXLAN interfaces and restrict VXLAN traffic to known peers. Audit all VXLAN deployments for VNI=1 and default port exposure.
• Restrict OSPF to router-to-router links only. OSPF must not be enabled on unnecessary interfaces. Monitor routing tables for unexpected prefix changes and enforce a minimum accepted prefix size (e.g., /24).
• For red teamers: Use source IP spoofing during high-risk lateral movement to evade log-based detection, scan for exposed VXLAN and GRE endpoints via OSINT and active scanning, and look for OSPF Hello messages as indicators of injectable routing infrastructure.

Slides PDF: Not available for this session.