Skip to content
HackIndex logo

HackIndex

Detecting Captive Portal Bypass Opportunities

3 min read Mar 17, 2026

Captive portals intercept HTTP traffic and redirect unauthenticated clients to a login page before granting network access. The enforcement mechanism is almost always based on MAC address or IP address whitelisting combined with firewall rules. These controls have well-known weaknesses that allow bypass without valid credentials. Identifying which bypass technique applies requires probing the portal's enforcement logic before attempting access.

Connect to the Network and Observe the Portal

Connect to the target open or captive-portal-protected network without credentials:

┌──(kali㉿kali)-[~]
└─$ nmcli dev wifi connect "TargetSSID"

After connecting, check what IP address and DNS server were assigned:

┌──(kali㉿kali)-[~]
└─$ ip addr show wlan0
┌──(kali㉿kali)-[~]
└─$ ip route show
┌──(kali㉿kali)-[~]
└─$ cat /etc/resolv.conf

Test DNS Bypass

Many captive portals allow DNS queries before authentication to enable the redirect mechanism. If DNS is unrestricted, DNS tunnelling may be possible. Test whether external DNS resolves:

┌──(kali㉿kali)-[~]
└─$ nslookup google.com 8.8.8.8

If an external DNS server responds successfully, the firewall is not blocking outbound UDP port 53. This enables DNS tunnelling through tools like iodine to encapsulate IP traffic inside DNS queries. Test whether the portal's own DNS server resolves external names too:

┌──(kali㉿kali)-[~]
└─$ nslookup google.com $(cat /etc/resolv.conf | grep nameserver | awk '{print $2}' | head -1)

Test ICMP and UDP Bypass

Some portal implementations only filter TCP traffic and leave ICMP and UDP unrestricted. Test connectivity:

┌──(kali㉿kali)-[~]
└─$ ping -c 4 8.8.8.8

If ICMP reaches external hosts, the portal only filters TCP. An ICMP tunnel or UDP-based VPN may provide full bypass.

Test MAC Address Spoofing Bypass

Captive portals that track authenticated sessions by MAC address are vulnerable to spoofing the MAC of an already-authenticated client. Passively observe authenticated clients on the network:

┌──(kali㉿kali)-[~]
└─$ airodump-ng --bssid $BSSID --channel $CH wlan0mon

Identify a client that is actively transmitting data frames — this indicates they have already authenticated through the portal. Spoof their MAC address on your interface:

┌──(kali㉿kali)-[~]
└─$ ip link set wlan0 down
┌──(kali㉿kali)-[~]
└─$ ip link set wlan0 address CC:DD:EE:FF:AA:BB
┌──(kali㉿kali)-[~]
└─$ ip link set wlan0 up

Reconnect to the network with the spoofed MAC and test whether internet access is granted without going through the portal. If the portal uses IP-based session tracking rather than MAC-based, this technique will not work — the IP address assigned by DHCP will be new and unrecognised.

Test HTTPS and Allowed Domains

Some portals whitelist specific domains such as payment processors or social login providers before authentication. Try accessing common whitelisted destinations directly:

┌──(kali㉿kali)-[~]
└─$ curl -sk https://www.apple.com | head -5
┌──(kali㉿kali)-[~]
└─$ curl -sk https://www.google.com | head -5

A successful HTTPS response from a whitelisted domain confirms the firewall allows direct HTTPS to at least some destinations before authentication. This may enable HTTPS tunnelling via tools like httptunnel if the whitelist is broad enough.

Document the Finding

Record which bypass vectors are open: unrestricted DNS, ICMP reachability, UDP bypass, or MAC-based session tracking. Each confirmed bypass method maps to a specific tunnelling or spoofing technique in the exploitation phase. A portal that blocks all of these with strict per-session IP enforcement and HTTPS-only access is significantly harder to bypass without valid credentials.

References