<summary><strong>Learn AWS hacking from zero to hero with</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
It can perform Evil Twin, KARMA, and Known Beacons attacks and then use a phishing template to manage to obtain the network real password or capture social network credentials.
```bash
git clone https://github.com/wifiphisher/wifiphisher.git # Download the latest revision
cd wifiphisher # Switch to tool's directory
sudo python setup.py install # Install any dependencies
This tool automates **WPS/WEP/WPA-PSK** attacks. It will automatically:
* Set the interface in monitor mode
* Scan for possible networks - And let you select the victim(s)
* If WEP - Launch WEP attacks
* If WPA-PSK
* If WPS: Pixie dust attack and the bruteforce attack (be careful the brute-force attack could take a long time). Notice that it doesn't try null PIN or database/generated PINs.
* Try to capture the PMKID from the AP to crack it
* Try to deauthenticate clients of the AP to capture a handshake
* If PMKID or Handshake, try to bruteforce using top5000 passwords.
**Deauthentication** attacks, a prevalent method in Wi-Fi hacking, involve forging "management" frames to **forcefully disconnect devices from a network**. These unencrypted packets deceive clients into believing they are from the legitimate network, enabling attackers to collect WPA handshakes for cracking purposes or to persistently disrupt network connections. This tactic, alarming in its simplicity, is widely used and has significant implications for network security.
* 1 is the number of deauths to send (you can send multiple if you wish); 0 means send them continuously
* \-a 00:14:6C:7E:40:80 is the MAC address of the access point
* \-c 00:0F:B5:34:30:30 is the MAC address of the client to deauthenticate; if this is omitted then broadcast deauthentication is sent (not always work)
**Disassociation packets**, similar to deauthentication packets, are a type of management frame used in Wi-Fi networks. These packets serve to sever the connection between a device (such as a laptop or smartphone) and an access point (AP). The primary distinction between disassociation and deauthentication lies in their usage scenarios. While an AP emits **deauthentication packets to remove rogue devices explicitly from the network, disassociation packets are typically sent when the AP is undergoing a shutdown**, restart, or relocating, thereby necessitating the disconnection of all connected nodes.
# -b victim_client_mac.txt contains the MAC address of the device to eliminate
# -e WifiName is the name of the wifi
# -B BSSID is the BSSID of the AP
# Notice that these and other parameters aare optional, you could give onli the ESSID and md4k will automatically search for it, wait for finding clients and deauthenticate them
Sending authentication frames to all accessible Access Points (APs) within range can overload these APs, especially when numerous clients are involved. This intense traffic can lead to system instability, causing some APs to freeze or even reset.
Probing Access Points (APs) checks if a SSID is properly revealed and confirms the AP's range. This technique, coupled with **bruteforcing hidden SSIDs** with or without a wordlist, helps in identifying and accessing concealed networks.
Sending random or duplicate packets to different QoS queues can trigger Michael Countermeasures on **TKIP APs**, leading to a one-minute AP shutdown. This method is an efficient **DoS** (Denial of Service) attack tactic.
Flooding an AP with **EAPOL Start frames** creates **fake sessions**, overwhelming the AP and blocking legitimate clients. Alternatively, injecting **fake EAPOL Logoff messages** forcibly disconnects clients, both methods effectively disrupt network service.
Cross-connecting clients to multiple WDS nodes or fake rogue APs can manipulate Intrusion Detection and Prevention Systems, creating confusion and potential system abuse.
WPS (Wi-Fi Protected Setup) simplifies the process of connecting devices to a router, enhancing the setup speed and ease for networks encrypted with **WPA** or **WPA2** Personal. It is ineffective for the easily compromised WEP security. WPS employs an 8-digit PIN, validated in two halves, making it susceptible to brute-force attacks due to its limited number of combinations (11,000 possibilities).
* **Reaver** has been designed to be a robust and practical attack against WPS, and has been tested against a wide variety of access points and WPS implementations.
* **Bully** is a **new implementation** of the WPS brute force attack, written in C. It has several advantages over the original reaver code: fewer dependencies, improved memory and cpu performance, correct handling of endianness, and a more robust set of options.
The attack exploits the **WPS PIN's vulnerability**, particularly its exposure of the first four digits and the last digit's role as a checksum, easing the brute-force attack. However, defenses against brute-force attacks, like **blocking MAC addresses** of aggressive attackers, demand **MAC address rotation** to continue the attack.
1.**Pre-discovered PINs**: Utilize a database of known PINs linked to specific manufacturers known to use uniform WPS PINs. This database correlates the first three octets of MAC-addresses with likely PINs for these manufacturers.
2.**PIN Generation Algorithms**: Leverage algorithms like ComputePIN and EasyBox, which calculate WPS PINs based on the AP's MAC-address. The Arcadyan algorithm additionally requires a device ID, adding a layer to the PIN generation process.
**Dominique Bongard** discovered a flaw in some Access Points (APs) concerning the creation of secret codes, known as **nonces** (**E-S1** and **E-S2**). If these nonces can be figured out, cracking the AP's WPS PIN becomes easy. The AP reveals the PIN within a special code (hash) to prove it's legitimate and not a fake (rogue) AP. These nonces are essentially the "keys" to unlocking the "safe" that holds the WPS PIN. More on this can be found [here](https://forums.kali.org/showthread.php?24286-WPS-Pixie-Dust-Attack-\(Offline-WPS-Attack\)).
In simple terms, the issue is that some APs did not use random enough keys for encrypting the PIN during the connection process. This makes the PIN vulnerable to being guessed from outside the network (offline brute force attack).
If you don't want to switch the device into monitor mode, or `reaver` and `bully` have some problem, you can try [OneShot-C](https://github.com/nikita-yfh/OneShot-C).
This tools can performs Pixie Dust attack without having to switch to monitor mode.
Some poorly designed systems even let a **Null PIN** (an empty or nonexistent PIN) grant access, which is quite unusual. The tool **Reaver** is capable of testing for this vulnerability, unlike **Bully**.
* 11 and 12 will **recollect the PINs related to the selected AP from available databases** and **generate** possible **PINs** using: ComputePIN, EasyBox and optionally Arcadyan (recommended, why not?)
So broken and unused nowdays. Just know that _**airgeddon**_ have a WEP option called "All-in-One" to attack this kind of protection. More tools offer similar options.
In 2018, **hashcat** [revealed](https://hashcat.net/forum/thread-7717.html) a new attack method, unique because it only needs **one single packet** and doesn't require any clients to be connected to the target AP—just interaction between the attacker and the AP.
Many modern routers add an **optional field** to the **first EAPOL** frame during association, known as `Robust Security Network`. This includes the `PMKID`.
Given that the "PMK Name" is constant, we know the BSSID of the AP and the station, and the `PMK` is identical to the one from a full 4-way handshake, **hashcat** can use this information to crack the PSK and recover the passphrase!
Please note the format of a correct hash contains **4 parts**, like: `4017733ca8db33a1479196c2415173beb808d7b83cfaa4a6a9a5aae7566f6461666f6e65436f6e6e6563743034383131343838`
If yours **only** contains **3 parts**, then, it is **invalid** (the PMKID capture wasn't valid).
Note that `hcxdumptool`**also capture handshakes** (something like this will appear: **`MP:M1M2 RC:63258 EAPOLTIME:17091`**). You could **transform** the **handshakes** to **hashcat**/**john** format using `cap2hccapx`
_I have noticed that some handshakes captured with this tool couldn't be cracked even knowing the correct password. I would recommend to capture handshakes also via traditional way if possible, or capture several of them using this tool._
An attack on **WPA/WPA2** networks can be executed by capturing a **handshake** and attempting to **crack** the password **offline**. This process involves monitoring the communication of a specific network and **BSSID** on a particular **channel**. Here's a streamlined guide:
1. Identify the **BSSID**, **channel**, and a **connected client** of the target network.
2. Use `airodump-ng` to monitor the network traffic on the specified channel and BSSID, hoping to capture a handshake. The command will look like this:
3. To increase the chance of capturing a handshake, momentarily disconnect the client from the network to force a re-authentication. This can be done using the `aireplay-ng` command, which sends deauthentication packets to the client:
In **enterprise WiFi setups, you'll encounter various authentication methods**, each providing different security levels and management features. When you use tools like `airodump-ng` to inspect network traffic, you might notice identifiers for these authentication types. Some common methods include:
- This method supports hardware tokens and one-time passwords within EAP-PEAP. Unlike MSCHAPv2, it doesn't use a peer challenge and sends passwords in plaintext to the access point, posing a risk for downgrade attacks.
2.**EAP-MD5 (Message Digest 5)**:
- Involves sending the MD5 hash of the password from the client. It's **not recommended** due to vulnerability to dictionary attacks, lack of server authentication, and inability to generate session-specific WEP keys.
3.**EAP-TLS (Transport Layer Security)**:
- Utilizes both client-side and server-side certificates for authentication and can dynamically generate user-based and session-based WEP keys for securing communications.
4.**EAP-TTLS (Tunneled Transport Layer Security)**:
- Provides mutual authentication through an encrypted tunnel, along with a method to derive dynamic, per-user, per-session WEP keys. It requires only server-side certificates, with clients using credentials.
- Functions similarly to EAP by creating a TLS tunnel for protected communication. It allows the use of weaker authentication protocols on top of EAP due to the protection offered by the tunnel.
* **PEAP-MSCHAPv2**: Often referred to as PEAP, it combines the vulnerable MSCHAPv2 challenge/response mechanism with a protective TLS tunnel.
* **PEAP-EAP-TLS (or PEAP-TLS)**: Similar to EAP-TLS but initiates a TLS tunnel before exchanging certificates, offering an additional layer of security.
You can find more information about these authentication methods [here ](https://en.wikipedia.org/wiki/Extensible\_Authentication\_Protocol)and [here](https://www.intel.com/content/www/us/en/support/articles/000006999/network-and-i-o/wireless-networking.html).
Reading [https://tools.ietf.org/html/rfc3748#page-27](https://tools.ietf.org/html/rfc3748#page-27) it looks like if you are using **EAP** the **"Identity"** **messages** must be **supported**, and the **username** is going to be sent in **clear** in the **"Response Identity"** messages.
Even using one of the most secure of authentication methods: **PEAP-EAP-TLS**, it is possible to **capture the username sent in the EAP protocol**. To do so, **capture a authentication communication** (start `airodump-ng` inside a channel and `wireshark` in the same interface) and filter the packets by`eapol`.\
Inside the "**Response, Identity**" packet, the **username** of the client will appear.
Identity hiding is supported by both EAP-PEAP and EAP-TTLS. In the context of a WiFi network, an EAP-Identity request is typically initiated by the access point (AP) during the association process. To ensure the protection of user anonymity, the response from the EAP client on the user's device contains only the essential information required for the initial RADIUS server to process the request. This concept is illustrated through the following scenarios:
- In this scenario, all users employ the pseudonymous "anonymous" as their user identifier. The initial RADIUS server functions as either an EAP-PEAP or EAP-TTLS server, responsible for managing the server-side of the PEAP or TTLS protocol. The inner (protected) authentication method is then either handled locally or delegated to a remote (home) RADIUS server.
- In this situation, users from different realms conceal their identities while indicating their respective realms. This allows the initial RADIUS server to proxy the EAP-PEAP or EAP-TTLS requests to RADIUS servers in their home realms, which act as the PEAP or TTLS server. The initial RADIUS server operates solely as a RADIUS relay node.
- Alternatively, the initial RADIUS server may function as the EAP-PEAP or EAP-TTLS server and either handle the protected authentication method or forward it to another server. This option facilitates the configuration of distinct policies for various realms.
In EAP-PEAP, once the TLS tunnel is established between the PEAP server and the PEAP client, the PEAP server initiates an EAP-Identity request and transmits it through the TLS tunnel. The client responds to this second EAP-Identity request by sending an EAP-Identity response containing the user's true identity through the encrypted tunnel. This approach effectively prevents the revelation of the user's actual identity to anyone eavesdropping on the 802.11 traffic.
EAP-TTLS follows a slightly different procedure. With EAP-TTLS, the client typically authenticates using PAP or CHAP, secured by the TLS tunnel. In this case, the client includes a User-Name attribute and either a Password or CHAP-Password attribute in the initial TLS message sent after tunnel establishment.
Regardless of the protocol chosen, the PEAP/TTLS server obtains knowledge of the user's true identity after the TLS tunnel has been established. The true identity can be represented as user@realm or simply user. If the PEAP/TTLS server is also responsible for authenticating the user, it now possesses the user's identity and proceeds with the authentication method protected by the TLS tunnel. Alternatively, the PEAP/TTLS server may forward a new RADIUS request to the user's home RADIUS server. This new RADIUS request omits the PEAP or TTLS protocol layer. In cases where the protected authentication method is EAP, the inner EAP messages are transmitted to the home RADIUS server without the EAP-PEAP or EAP-TTLS wrapper. The User-Name attribute of the outgoing RADIUS message contains the user's true identity, replacing the anonymous User-Name from the incoming RADIUS request. When the protected authentication method is PAP or CHAP (supported only by TTLS), the User-Name and other authentication attributes extracted from the TLS payload are substituted in the outgoing RADIUS message, displacing the anonymous User-Name and TTLS EAP-Message attributes found in the incoming RADIUS request.
For more info check [https://www.interlinknetworks.com/app\_notes/eap-peap.htm](https://www.interlinknetworks.com/app\_notes/eap-peap.htm)
If the client is expected to use a **username and password** (notice that **EAP-TLS won't be valid** in this case), then you could try to get a **list** a **usernames** (see next part) and **passwords** and try to **bruteforce** the access using [**air-hammer**](https://github.com/Wh1t3Rh1n0/air-hammer)**.**
- The 802.11 protocol defines how a station joins an Extended Service Set (ESS) but does not specify the criteria for selecting an ESS or an access point (AP) within it.
- Stations can roam between APs sharing the same ESSID, maintaining connectivity across a building or area.
- The protocol requires station authentication to the ESS but does not mandate AP authentication to the station.
- Stations store the ESSID of every wireless network they connect to in their Preferred Network List (PNL), along with network-specific configuration details.
- The PNL is used to automatically connect to known networks, improving the user's experience by streamlining the connection process.
- APs periodically broadcast beacon frames, announcing their presence and features, including the AP's ESSID unless broadcasting is disabled.
- During passive scanning, stations listen for beacon frames. If a beacon's ESSID matches an entry in the station's PNL, the station may automatically connect to that AP.
- Knowledge of a device's PNL allows for potential exploitation by mimicking a known network's ESSID, tricking the device into connecting to a rogue AP.
- Active probing involves stations sending probe requests to discover nearby APs and their characteristics.
- Directed probe requests target a specific ESSID, helping detect if a particular network is within range, even if it's a hidden network.
- Broadcast probe requests have a null SSID field and are sent to all nearby APs, letting the station check for any preferred network without disclosing its PNL contents.
Before explaining how to perform more complex attacks it's going to be explained **how** to just **create** an **AP** and **redirect** it's **traffic** to an interface connected **to** the **Internet**.
An evil twin attack exploits the way WiFi clients recognize networks, primarily relying on the network name (ESSID) without requiring the base station (access point) to authenticate itself to the client. Key points include:
- **Difficulty in Differentiation**: Devices struggle to distinguish between legitimate and rogue access points when they share the same ESSID and encryption type. Real-world networks often use multiple access points with the same ESSID to extend coverage seamlessly.
- **Client Roaming and Connection Manipulation**: The 802.11 protocol allows devices to roam between access points within the same ESS. Attackers can exploit this by luring a device to disconnect from its current base station and connect to a rogue one. This can be achieved by offering a stronger signal or disrupting the connection to the legitimate access point through methods like deauthentication packets or jamming.
- **Challenges in Execution**: Successfully executing an evil twin attack in environments with multiple, well-placed access points can be challenging. Deauthenticating a single legitimate access point often results in the device connecting to another legitimate access point unless the attacker can deauthenticate all nearby access points or strategically place the rogue access point.
You could also create an Evil Twin using **eaphammer** (notice that to create evil twins with eaphammer the interface **should NOT be** in **monitor** mode):
Please, notice that by default if an ESSID in the PNL is saved as WPA protected, the device won't connect automatically to an Open evil Twin. You can try to DoS the real AP and hope that the user will connect manually to your Open evil twin, or you could DoS the real AP an use a WPA Evil Twin to capture the handshake (using this method you won't be able to let the victim connect to you as you don't know the PSK, but you can capture the handshake and try to crack it).
You can create an **Evil Twin using WPA/2** and if the devices have configured to connect to that SSID with WPA/2, they are going to try to connect. Anyway, **to complete the 4-way-handshake** you also need to **know** the **password** that the client is going to use. If you **don't know** it, the **connection won't be completed**.
`hostapd-wpe` needs a **configuration** file to work. To **automate** the generation if these configurations you could use [https://github.com/WJDigby/apd\_launchpad](https://github.com/WJDigby/apd\_launchpad) (download the python file inside _/etc/hostapd-wpe/_)
By default, EAPHammer purposes this authentication methods (notice GTC as the first one to try to obtain plaintext passwords and then the use of more robust auth methods):
This is the default methodology to avoid long connection times. However, you can also specify to server the authentication methods from weakest to strongest:
*`--negotiate gtc-downgrade` to use highly efficient GTC downgrade implementation (plaintext passwords)
*`--negotiate manual --phase-1-methods PEAP,TTLS --phase-2-methods MSCHAPV2,GTC,TTLS-PAP` to specify manually the methods offered (offering the same auth methods in the same order as the organisation the attack will be much more difficult to detect).
`Airgeddon` can use previously generated certificated to offer EAP authentication to WPA/WPA2-Enterprise networks. The fake network will downgrade the connection protocol to EAP-MD5 so it will be able to **capture the user and the MD5 of the password**. Later, the attacker can try to crack the password.\
`Airggedon` offers you the possibility of a **continuous Evil Twin attack (noisy)** or **only create the Evil Attack until someone connects (smooth).**
Inside the **configuration** of _hostapd-wpe_**comment** the line that contains _**dh\_file**_ (from `dh_file=/etc/hostapd-wpe/certs/dh` to `#dh_file=/etc/hostapd-wpe/certs/dh`)\
This will make `hostapd-wpe` to **exchange keys using RSA** instead of DH, so you will be able to **decrypt** the traffic later **knowing the servers private key**.
Now start the **Evil Twin** using **`hostapd-wpe`** with that modified configuration as usual. Also, start **`wireshark`** in the **interface** which is performing the Evil Twin attack.
Now or later (when you have already captured some authentication intents) you can add the private RSA key to wireshark in: `Edit --> Preferences --> Protocols --> TLS --> (RSA keys list) Edit...`
Add a new entry and fill the form with this values: **IP address = any** -- **Port = 0** -- **Protocol = data** -- **Key File** (**select your key file**, to avoid problems select a key file **without being password protected**).
- The rogue AP will ignore probe requests from devices on the blacklist, effectively making the rogue AP invisible to those specific devices.
3.**SSID-based Whitelist**:
- The rogue AP will respond to probe requests only for specific ESSIDs listed, making it invisible to devices whose Preferred Network Lists (PNLs) do not contain those ESSIDs.
4.**SSID-based Blacklist**:
- The rogue AP will not respond to probe requests for the specific ESSIDs on the blacklist, making it invisible to devices seeking those particular networks.
This method allows an **attacker to create a malicious access point (AP) that responds to all probe requests** from devices seeking to connect to networks. This technique **tricks devices into connecting to an attacker's AP** by mimicking the networks the devices are searching for. Once a device sends a connection request to this rogue AP, it completes the connection, leading the device to mistakenly connect to the attacker's network.
Then, **devices started to ignore unsolicited network responses**, reducing the effectiveness of the original karma attack. However, a new method, known as the **MANA attack**, was introduced by Ian de Villiers and Dominic White. This method involves the rogue AP **capturing the Preferred Network Lists (PNL) from devices by responding to their broadcast probe requests** with network names (SSIDs) previously solicited by the devices. This sophisticated attack bypasses the protections against the original karma attack by exploiting the way devices remember and prioritize known networks.
The MANA attack operates by monitoring both directed and broadcast probe requests from devices. For directed requests, it records the device's MAC address and the requested network name, adding this information to a list. When a broadcast request is received, the AP responds with information matching any of the networks on the device's list, enticing the device to connect to the rogue AP.
A **Loud MANA attack** is an advanced strategy for when devices do not use directed probing or when their Preferred Network Lists (PNL) are unknown to the attacker. It operates on the principle that **devices in the same area are likely to share some network names in their PNLs**. Instead of responding selectively, this attack broadcasts probe responses for every network name (ESSID) found in the combined PNLs of all observed devices. This broad approach increases the chance of a device recognizing a familiar network and attempting to connect to the rogue Access Point (AP).
When the **Loud MANA attack** may not suffice, the **Known Beacon attack** presents another approach. This method **brute-forces the connection process by simulating an AP that responds to any network name, cycling through a list of potential ESSIDs** derived from a wordlist. This simulates the presence of numerous networks, hoping to match an ESSID within the victim's PNL, prompting a connection attempt to the fabricated AP. The attack can be amplified by combining it with the `--loud` option for a more aggressive attempt to ensnare devices.
Eaphammer implemented this attack as a MANA attack where all the ESSIDs inside a list are charged (you could also combine this with `--loud` to create a Loud MANA + Known beacons attack):
The **Known Beacon Burst attack** involves **rapid-fire broadcasting of beacon frames for each ESSID listed in a file**. This creates a dense environment of fake networks, greatly enhancing the likelihood of devices connecting to the rogue AP, especially when combined with a MANA attack. This technique leverages speed and volume to overwhelm devices' network selection mechanisms.
**Wi-Fi Direct** is a protocol enabling devices to link directly with each other using Wi-Fi without the need for a traditional wireless access point. This capability is integrated into various Internet of Things (IoT) devices, such as printers and televisions, facilitating direct device-to-device communication. A notable feature of Wi-Fi Direct is that one device takes on the role of an access point, known as the group owner, to manage the connection.
Security for Wi-Fi Direct connections is established through **Wi-Fi Protected Setup (WPS)**, which supports several methods for secure pairing, including:
These methods, particularly PIN entry, are susceptible to the same vulnerabilities as WPS in traditional Wi-Fi networks, making them targets for similar attack vectors.
**EvilDirect Hijacking** is an attack specific to Wi-Fi Direct. It mirrors the concept of an Evil Twin attack but targets Wi-Fi Direct connections. In this scenario, an attacker impersonates a legitimate group owner with the aim of deceiving devices into connecting to a malicious entity. This method can be executed using tools like `airbase-ng` by specifying the channel, ESSID, and MAC address of the impersonated device:
TODO: Take a look to [https://github.com/wifiphisher/wifiphisher](https://github.com/wifiphisher/wifiphisher) (login con facebook e imitacionde WPA en captive portals)
<summary><strong>Learn AWS hacking from zero to hero with</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
