Advanced network attacks: layer 2/3 from the inside

Most corporate networks are still hard on the outside and soft on the inside. Once you’re past the perimeter, usually through phishing or sometimes through physical access to a wall jack in a public part of the building, the internal traffic is largely unencrypted and the protocols carrying it trust each other in ways the firewall isn’t paying attention to. The techniques below are the layer-2 and layer-3 moves that turn a foothold into domain credentials, which is the transition most operators are trying to engineer once they’re inside.

IPv6 as a shadow network

#

IPv6 is enabled by default on every supported Windows version, and most internal networks are operationally IPv4 without actually disabling v6 on the endpoints. That creates a network the IT team isn’t watching, with hosts that will happily speak it the moment something on the wire offers them addresses.

mitm6 and ntlmrelayx

#

mitm6 (Dirk-jan Mollema’s tool, originally at Fox-IT, repo still at fox-it/mitm6; Mollema now runs Outsider Security) takes advantage of the fact that Windows prefers IPv6 over IPv4 when both are available. The attack runs a malicious DHCPv6 server on the local segment:

1. Listen for DHCPv6 SOLICIT packets from Windows clients.
2. Reply with an ADVERTISE that hands the client an IPv6 address and, critically, sets the attacker as the DNS server.
3. The client tries to resolve internal hostnames (file shares, WPAD, the proxy) against the attacker’s DNS.
4. The attacker answers with an address pointing back at itself.
5. The client authenticates with NTLM, and ntlmrelayx relays that authentication to whatever target the operator chose. Most commonly LDAP/LDAPS on a domain controller (to add a user or configure RBCD) or AD CS web enrollment (the ESC8 path, for a usable certificate).

# Window 1: run mitm6 against the target domain on the local interface
sudo mitm6 -d corp.local -i eth0

# Window 2: ntlmrelayx, targeting domain controller LDAPS
impacket-ntlmrelayx -6 -t ldaps://192.168.1.10 -wh "wpad.corp.local" -l loot/

A 2026 caveat that didn’t apply in 2023: Microsoft’s Server 2025 defaults enabled Extended Protection for Authentication (EPA) on HTTP-based authentication and turned on LDAP channel binding, both of which break a lot of relay paths that used to be reliable. Modern Windows 11 and Edge also increasingly ignore WPAD. The technique still works against environments that haven’t picked up those defaults, and a lot of environments haven’t. If ntlmrelayx is failing in a fully patched 2025-era estate, the mitigations are the reason, not the tool.

NAC bypass

#

Network Access Control sits between the wall jack and the rest of the network and decides whether to let whatever plugged in actually talk to anything. NAC products fall roughly into two categories that matter for bypass purposes: the older deployments that check a MAC address against a whitelist and call it done, and the modern profiling-aware appliances (Cisco ISE, Aruba ClearPass) that look at the whole device’s behavioral signature before deciding. The techniques below work cleanly against the first category and have to work harder, with varying success, against the second.

MAC spoofing against MAB

#

MAB (MAC Authentication Bypass) is the fallback authentication method most organizations use for devices that can’t do 802.1X: printers, IP phones, building automation, badge readers. The switch checks the device’s MAC against a whitelist and opens the port if it matches.

The naive attack: walk up to a VoIP phone, read the MAC off the sticker on the back, clone it onto your laptop, plug into a wall jack.

# Modern Linux (iproute2). ifconfig is deprecated and isn't installed
# by default on Debian/Ubuntu anymore.
sudo ip link set dev eth0 down
sudo ip link set dev eth0 address 00:11:22:33:44:55
sudo ip link set dev eth0 up

This works against unconfigured Cisco ISE and Aruba ClearPass deployments and against most homegrown RADIUS setups. Against modern, properly configured profiling-aware NAC it usually doesn’t, because ISE and ClearPass examine more than the MAC: DHCP options 55 and 60, CDP/LLDP advertisements, HTTP User-Agent strings, certificate posture. A laptop running Linux that claims to be a Polycom phone via MAC but doesn’t match a Polycom DHCP fingerprint trips a conflict and gets quarantined. To bypass modern NAC you have to match enough of the device’s full behavioral signature to avoid that conflict, which is meaningfully more work and gets noisier the further you stretch the impersonation.

Transparent bridging for persistence

#

When port security is strict and you need to maintain access without your own MAC ever appearing on the wire, the move is a transparent bridge between a legitimate workstation and the wall jack. Tools like the Hak5 LAN Turtle and the Pwn Plug, or a Raspberry Pi configured as a brctl bridge with the bridge MAC matching the upstream workstation, sit inline and forward all the host’s traffic while giving you a side channel for your own activity. The switch sees the legitimate workstation’s MAC as the only one on the port and the 802.1X supplicant on the workstation handles authentication for you.

This is the technique that survives most NAC products, because the NAC is watching the workstation it expects to be there doing what it always does. The workstation is on the segment, the 802.1X session is real, the traffic patterns match the baseline. The added traffic riding along on the bridge is in the same MAC’s stream, so unless the NAC is sampling endpoint telemetry from the workstation itself (which would require an agent installed on the workstation), there is nothing inconsistent for the NAC to flag.

VLAN hopping

#

VLAN segmentation is treated as a security boundary in most network designs, which is fair when the switch ports are hardened to be access ports and nothing else. When they aren’t, there are two attacks that still come up regularly on engagements.

Switch spoofing via DTP

#

Cisco’s Dynamic Trunking Protocol auto-negotiates a trunk link between switches. If the port you’re plugged into is configured as dynamic auto or dynamic desirable (which was the default on older Cisco gear, and which still shows up in environments where someone shipped a switch into production without tightening the per-port config), sending DTP frames claiming to be a switch convinces the port to negotiate a trunk. The attacker now sees traffic from every VLAN that crosses that trunk, not just the one assigned to the floor.

Configuring switchport mode access disables DTP and shuts this down. Note that switchport mode trunk alone doesn’t; DTP still runs unless you add switchport nonegotiate.

# yersinia is the standard tool here. Last meaningful update was years
# ago, but it still ships in Kali and still works against unhardened DTP.
sudo yersinia -G
# DTP -> Enable Trunk

Double tagging

#

The other VLAN-hopping technique works against the way some switches handle 802.1Q tags. Inject a frame with two stacked VLAN tags. The first (ingress) switch sees the outer tag matches its native VLAN, strips it, and forwards the frame over the trunk. The next switch sees the inner tag, treats the frame as native to that VLAN, and delivers it.

Requirements: the attacker’s port has to be in the same VLAN as the trunk’s native VLAN (often VLAN 1, which is why every hardening guide tells you to change the native VLAN to something nobody uses). The attack is unidirectional (return traffic can’t be re-encapsulated on the way back), so it’s only useful for one-way payloads like UDP exploits or fire-and-forget triggers.

HSRP / VRRP hijack

#

First Hop Redundancy Protocols let two routers share a virtual IP that endpoints use as the default gateway. HSRP (Cisco) and VRRP (open standard) both elect a primary based on advertised priority, and both can be hijacked by sending a superior advertisement onto the segment.

If the routers are configured without authentication, or with weak authentication an attacker can guess or capture, the technique is mechanical. Send an HSRP or VRRP advertisement with priority 255, become the active gateway, and the segment’s outbound traffic starts coming through your box. Everything downstream of that is the usual MITM playbook: selective traffic forwarding, credential harvesting from cleartext protocols, SSL stripping where the clients allow it.

Tool: Loki (Daniel Mende / Rene Graf / Enno Rey, ERNW)
Released at Black Hat USA 2010, still works against unauthenticated HSRP/VRRP.
yersinia covers the same ground if you're already running it.

The mitigation is HSRP/VRRP authentication with strong keys, ideally MD5 or stronger. Most environments either don’t enable it or use a default key from a 2008 deployment guide.

Why this still matters

#

The internal network is a noisy environment. There are at least half a dozen protocols (broadcast ARP, LLMNR and NBT-NS for name resolution, DHCPv4 and DHCPv6 for addressing, IPv6 router advertisements, WPAD for proxy discovery) running concurrently on most segments, mostly because nobody has gotten around to turning the unused ones off. Every one of the techniques in this post has had a specific mitigation available for over a decade. They still land in 2026 because the mitigation in question is one config knob in a switch or one default someone never changed. Modern NAC and the Server 2025 defaults have shrunk what’s available, but there is a long tail of networks still running on the configurations they shipped with in 2012, and those are the engagements where these techniques pay off.