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, --help show this help message and exit

-s SKIP, --skip SKIP Skip 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, --directedonly Skip the deauthentication packets to the broadcast
address ofthe access points and only send them to
client/AP pairs
-nJ, --nojamming Skip 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.

Wifiphisher achieves a man-in-the-middle position using the Evil Twin attack

and then redirects all HTTP requests to an attacker-controlled phishing website.
From the victim's perspective, the attack can be divided into three phases:

1. Victim is getting disconnected from her access point. Wifiphisher

continuously jams all of the target Access Point's Wi-Fi clients within range by
forging “Deauthenticate” 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 start connecting to
the rogue access point. After this phase, the victim is MiTMed.

3. Victim is being served a phishing page (e.g. a realistic router config-

looking 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
forces the victim to download an executable.

PHISHING SCENARIOS
Wifiphisher supports community-built templates for different phishing
scenarios, such as:

* Router configuration pages

* 3rd party login pages
* Captive portals
* Browser messages

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:

i) 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

ii) context: This section is optional and holds user-defined variables that may
be later injected to the template.

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

 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:

i) Beacon frames. 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 AP dictionaries of the Access Points
captured during the
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.

ii) The config.ini file (described above). 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):

> <p> Dear {{ victim_name }}, This is a message from {{ ISP }}.
> A problem was detected regarding your {{ target_ap_vendor }} router. </p>
> <p> Please write your credentials to re-connect over PPPOE/PPPOA.</p>
> <input type="text" name="wphshr-username"></input>
 > <input type="text" name="wphshr-password"></input>

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.