Documentation

NAME

Wifiphisher - Automated phishing attacks against Wi-Fi networks

SYNOPSIS

wifiphisher [Options]

OPTIONS

This options summary is printed when Wifiphisher is run with no arguments. Advanced users may edit wifiphisher/constants.py for deeper configuration.

-h, --helpshow this help message and exit
-s SKIP, --skip SKIPSkip deauthing this MAC address. Example: -s 00:11:BB:33:44:AA
-jI JAMMINGINTERFACE, --jamminginterface JAMMINGINTERFACE Manually choose an interface that supports monitor mode for deauthenticating the victims. Example: -jI wlan1
-aI APINTERFACE, --apinterface APINTERFACE Manually choose an interface that supports AP mode for spawning an AP. Example: -aI wlan0
-t TIMEINTERVAL, --timeinterval TIMEINTERVAL Choose the time interval between DEAUTH packets being sent
-dP DEAUTHPACKETS, --deauthpackets DEAUTHPACKETS Choose the number of packets to send in each deauth burst. Default value is 1; 1 packet to the client and 1 packet to the AP. Send 2 deauth packets to the client and 2 deauth packets to the AP: -p 2
-d, --directedonlySkip the deauthentication packets to the broadcast address ofthe access points and only send them to client/AP pairs
-nJ, --nojammingSkip the deauthentication phase. When this option is used, only one wireless interface is required
-e ESSID, --essid ESSID Enter the ESSID of the rogue Access Point. This option will skip Access Point selection phase. Example: --essid 'Free WiFi'
-p PHISHINGSCENARIO, --phishingscenario PHISHINGSCENARIO Choose the phishing scenario to run.This option will skip the scenario selection phase. Example: -p firmware_upgrade
-pK PRESHAREDKEY, --presharedkey PRESHAREDKEY Add WPA/WPA2 protection on the rogue Access Point. Example: -pK s3cr3tp4ssw0rd

DESCRIPTION

Wifiphisher is a security tool that mounts automated phishing attacks against Wi-Fi networks in order to obtain credentials or infect the victims with malwares. It is a social engineering attack that can be used to obtain WPA/WPA2 secret passphrases and unlike other methods it does not include any brute forcing. It is an easy way for obtaining credentials from social networks or other third party login pages.

After achieving a man-in-the-middle position using the Evil Twin attack, Wifiphisher redirects all HTTP requests to an attacker-controlled phishing page.

From the victim's perspective, the attack makes use in three phases:

  1. Victim is being deauthenticated from her access point. Wifiphisher continuously jams all of the target access point's wifi devices within range by forging “Deauthenticate” or “Disassociate” packets to disrupt existing associations.
  2. Victim joins a rogue access point. Wifiphisher sniffs the area and copies the target access point's settings. It then creates a rogue wireless access point that is modeled by the target. It also sets up a NAT/DHCP server and forwards the right ports. Consequently, because of the jamming, clients will eventually start connecting to the rogue access point. After this phase, the victim is MiTMed.
  3. Victim is being served a realistic specially-customized phishing page. Wifiphisher employs a minimal web server that responds to HTTP & HTTPS requests. As soon as the victim requests a page from the Internet, wifiphisher will respond with a realistic fake page that asks for credentials or serves malwares. This page will be specifically crafted for the victim. For example, a router config-looking page will contain logos of the victim's vendor. The tool supports community-built templates for different phishing scenarios.

EXAMPLES

> wifiphisher -aI wlan0 -jI wlan4 -p firmware-upgrade

Use wlan0 for spawning the rogue Access Point and wlan4 for DoS attacks. Select the target network manually from the list and perform the "Firmware Upgrade" scenario.

Useful for manually selecting the wireless adapters. The "Firware Upgrade" scenario is an easy way for obtaining the PSK from a password-protected network.

> wifiphisher --essid CONFERENCE_WIFI -p plugin_update -pK s3cr3tp4ssw0rd

Automatically pick the right interfaces. Target the Wi-Fi with ESSID "CONFERENCE_WIFI" and perform the "Plugin Update" scenario. The Evil Twin will be password-protected with PSK "s3cr3tp4ssw0rd".

Useful against networks with disclosed PSKs (e.g. in conferences). The "Plugin Update" scenario provides an easy way for getting the victims to download malicious executables (e.g. malwares containing a reverse shell payload).

> wifiphisher --nojamming --essid "FREE WI-FI" -p oauth-login

Do not target any network. Simply spawn an open Wi-Fi network with ESSID "FREE WI-FI" and perform the "OAuth Login" scenario.

Useful against victims in public areas. The OAuth Login scenario provides a simple way for capturing credentials from social networks, like Facebook.

PHISHING SCENARIOS

Wifiphisher supports community-built templates for different phishing scenarios. Currently, the following phishing scenarios are in place:

Creating a custom phishing scenario

For specific target-oriented attacks, custom scenarios may be necessary. Creating a phishing scenario is easy and consists of two steps:

  1. Create the config.ini

    A config.ini file lies in template's root directory and its contents can be divided into two sections:

    1. info: This section defines the scenario's characteristics.
      • Name (mandatory): The name of the phishing scenario
      • Description (mandatory): A quick description (<50 words) of the scenario
      • PayloadPath (optional): If the phishing scenario pushes malwares to victims, users can insert the absolute path of the malicious executable here
    2. context: This section is optional and holds user-defined variables that may be later injected to the template.

      3. Example

      Here's an example of a config.ini file: 
      > # This is a comment
> [info]
> Name: ISP warning page
> Description: A warning page from victim's ISP asking for DSL credentials
>
> [context]
> victim_name: John Phisher
> victim_ISP: Interwebz
  2. Create the template files

    3. A template contains the static parts of the desired HTML output and may consist of several static HTML files, images, CSS or Javascript files. Dynamic languages (e.g. PHP) are not supported.

    Placeholders

    The HTML files may also contain some special syntax (think placeholders) describing how dynamic content will be inserted. The dynamic contect may originate from two sources:

    1. Beacon frames.

      2. Beacon frames contain all the information about the target network and can be used for information gathering. The main process gathers all the interesting information and passes them to the chosen template on the runtime.

      At the time of writing, the main process passes the following data:

      • target_ap_essid <str>: The ESSID of the target Access Point
      • target_ap_bssid <str>: The BSSID (MAC) address of the target Access Point
      • target_ap_channel <str<: The channel of the target Access Point
      • target_ap_vendor <str>: The vendor's name of the target Access Point
      • target_ap_logo_path <str>: The relative path of the target Access Point vendor's logo in the filesystem
      • APs_context <list>: A list containing dictionaries of the Access Points captured during the AP selection phase
      • AP <dict>: A dictionary holding the following information regarding an Access Point:
        • channel <str>: The channel of the Access Point
        • essid <str> The ESSID of the Access Point
        • bssid <str> The BSSID (MAC) address of the Access Point
        • vendor <str> The vendor's name of the Access Point

      Note that the above values may be 'None' accordingly. For example, all the target_* values will be None if there user did not target an Access Point (by using --essid option). The 'target_ap_logo_path' will be None if the logo of the specific vendor does not exist in the repository.

    2. config.ini file (described above).

      3. All the variables defined in the "Context" section may be used from within the template files. In case of naming conflicts, the variables from the configuration file will override those coming from the beacon frames.

    Logging credentials

    In order for wifiphisher to know which credentials to log, the values of the 'name' HTML attributes need to be prefixed with the 'wfphshr' string. During POST requests, wifiphisher will log all variables that are prefixed with this string.

    Example

    Here's a snippet from a template (index.html):

    In this example, 'victim_name' and 'ISP' variables come from config.ini, while 'target_ap_vendor' variable is from the beacon frames. Both "wphshr-username" and "wphshr-password" will be logged.