Module 11: Attacking Captive Portals
Basic Functionality
Just explaining how a device detects a captive portal.
The Captive Portal Attack
Discovery
Discovery via Airodump-ng:
kali@kali:~$ sudo airodump-ng -w discovery --output-format pcap wlan0mon
CH 12 ][ Elapsed: 0 s ][ 2020-09-14 16:23
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
00:0E:08:FA:47:CD -51 3 2 0 6 195 WPA2 CCMP MGT MegaCorp One
00:0E:08:75:69:78 -70 2 0 0 1 130 OPN MegaCorp One Guest
00:0E:08:90:3A:5F -75 3 0 0 11 130 WPA2 CCMP PSK MegaCorp One Lab
BSSID STATION PWR Rate Lost Frames Notes Probes
00:0E:08:90:3A:5F E6:D9:CA:FE:B2:3C -45 0 - 0e 0 2
00:0E:08:90:3A:5F 05:E3:5C:E6:D9:A3 -68 0e-54 0 2
00:0E:08:90:3A:5F E6:EE:C0:FF:EE:84 -81 0 - 5e 487 6
00:0E:08:FA:47:CD 98:D5:96:6D:25:78 -37 0 - 1e 0 2
(not associated) A7:AD:4B:2B:5E:EF -54 0 - 1 3 9 Yugoslavia
00:0E:08:75:69:78 FE:5C:BE:EF:D4:3F -48 0 - 6 0 1Deauthenticating Clients:
Discovery via Airodump-ng, capturing the handshake:
Building the Captive Portal
To build our captive portal, we'll use apache and php scripts to save credentials the user enters. Starting off with installing Apache and PHP:
Downloading MegaCorp One index page and its resources. -r will download recursively, and -l2 will go two levels deep:
Creating the Captive Portal index.php page:
Copying the assets and old-site directories since they contain the CSS and the background image:
Creating the Captive Portal login check page:
Networking Setup
Configuring our wireless interface for networking:
Installing dnsmasq:
Configuring mco-dnsmaq.conf for DHCP:
Configuring mco-dnsmasq.conf to also spoof DNS:
When the EnableActiveProbing registry key in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet is set to "0", it will disable the check. If this happens, Windows will not detect our captive portal and the user won't be able to login.
Staring dnsmasq:
Confirming dnsmasq started via the syslog:
We can also use netstat to confirm it is listening on port 53 (TCP/UDP) for DNS, and on 67 (UDP) for DHCP:
Using nftables to forcefully redirect DNS to us:
Adding mod_rewrite and mod_alias rules to our /etc/apache2/sites-enabled/000-default.conf:
For the first four and last three of the above instructions, we'll need the redirect module. For the two in-between those, we need the alias module:
Chrome doesn't automatically check for captive portals on startup like Firefox. Typing a URL will trigger the captive portal, but with the above configuration, a search will fail. This may be because Chrome encodes the search and automatically prepends the search URL, which is HTTPS. With just HTTP in our Apache configuration, we will fail to connect to the website because the port isn't listening.
We can remedy this special case by making a HTTPS section in Apache. Note that doing so will break Firefox (and possibly other OS/software) if the victim clicks on the prompt to guide them to the captive portal. This is because of the self-signed certificate. It should work when the OS opens Firefox to log in. For these reasons, we only recommended this approach in an environment where only Chrome is used.
To do this, duplicate the whole VirtualHost section, changing the port from 80 to 443, the instances of http to https, and finally adding a SSL certificate:
Lastly, enable the ssl module:
Setting Up and Running the Rogue AP
Installing hostapd to run the AP:
Configuring the mco-hostapd.conf as an AP running 802.11n with the same SSID and channel as the AP we're targeting, but not using any encryption:
Running hsotapd in the background with -B:
Checking hostapd and udhcpd logs for connections:
Monitoring the Apache logs:
Viewing the passphrase provided as shown by the previous successful redirect back to the index page:
Additional Behaviors Surrounding Captive Portals
Redirects to captive portals aren't a guarantee.
Last updated