Fake authentication

The fake authentication attack allows you to perform the two types of WEP authentication (Open System and Shared Key) plus associate with the access point (AP). This is only useful when you need an associated MAC address in various aireplay-ng attacks and there is currently no associated client. It should be noted that the fake authentication attack does NOT generate any ARP packets. Fake authentication cannot be used to authenticate/associate with WPA/WPA2 Access Points.

 aireplay-ng -1 0 -e teddy -a 00:14:6C:7E:40:80 -h 00:09:5B:EC:EE:F2 -y sharedkeyxor ath0

Where:

• -1 means fake authentication
• 0 reassociation timing in seconds
• -e teddy is the wireless network name
• -a 00:14:6C:7E:40:80 is the access point MAC address
• -h 00:09:5B:EC:EE:F2 is our card MAC address
• -y sharedkeyxor is the name of file containing the PRGA xor bits. This is only used for shared key authentication. Open system authentication, which is typical, does not require this.
• ath0 is the wireless interface name

Or another variation for picky access points:

aireplay-ng -1 6000 -o 1 -q 10 -e teddy -a 00:14:6C:7E:40:80 -h 00:09:5B:EC:EE:F2 ath0

Where:

• 6000 - Reauthenticate very 6000 seconds. The long period also causes keep alive packets to be sent.
• -o 1 - Send only one set of packets at a time. Default is multiple and this confuses some APs.
• -q 10 - Send keep alive packets every 10 seconds.

The lack of association with the access point is the single biggest reason why injection fails.

To associate with an access point, use fake authentication:

aireplay-ng -1 0 -e teddy -a 00:14:6C:7E:40:80 -h 00:09:5B:EC:EE:F2 ath0

Where:

• -1 means fake authentication
• 0 reassociation timing in seconds
• -e teddy is the wireless network name
• -a 00:14:6C:7E:40:80 is the access point MAC address
• -h 00:09:5B:EC:EE:F2 is our card MAC address
• ath0 is the wireless interface name

Success looks like:

18:18:20  Sending Authentication Request
18:18:20  Authentication successful
18:18:20  Sending Association Request
18:18:20  Association successful :-)

Or another variation for picky access points:

aireplay-ng -1 6000 -o 1 -q 10 -e teddy -a 00:14:6C:7E:40:80 -h 00:09:5B:EC:EE:F2 ath0

Where:

• 6000 - Reauthenticate very 6000 seconds. The long period also causes keep alive packets to be sent.
• -o 1 - Send only one set of packets at a time. Default is multiple and this confuses some APs.
• -q 10 - Send keep alive packets every 10 seconds.

Success looks like:

18:22:32  Sending Authentication Request
18:22:32  Authentication successful
18:22:32  Sending Association Request
18:22:32  Association successful :-)
18:22:42  Sending keep-alive packet
18:22:52  Sending keep-alive packet
# and so on.

Here is an example of a shared key authentication. It does assume you have a PRGA xor file. See the How to do shared key fake authentication tutorial for more details.

 aireplay-ng -1 0  -e teddy -y sharedkey-04-00-14-6C-7E-40-80.xor -a 00:14:6C:7E:40:80 -h 00:09:5B:EC:EE:F2 ath0

Where:

• -1 means fake authentication
• 0 means only authenticate once
• -e teddy is the SSID of the network
• -y sharedkey-04-00-14-6C-7E-40-80.xor is the name of file containing the PRGA xor bits
• -a 00:14:6C:7E:40:80 is the access point MAC address
• -h 00:09:5B:EC:EE:F2
• ath0 is the interface name

Here is an example of a successful shared key authentication:

 11:44:55  Sending Authentication Request
 11:44:55  AP rejects open-system authentication
 Part1: Authentication
 Code 0 - Authentication SUCCESSFUL :)
 Part2: Association
 Code 0 - Association SUCCESSFUL :)

If you receive the messages above, you are good to go forward with the standard injection techniques.

It is good practice to set your card's MAC address to the one you specify via the “-h” parameter if they are different. Having them the same, ensures that wireless “ACK”s are sent by your card. This means subsequent attacks work smoothly.

Detailed instructions on changing the card MAC address can be found in the FAQ: How do I change my card's MAC address ?.

Troubleshooting Tip: A normal MAC address looks like this: 00:09:5B:EC:EE:F2. It is composed of six octets. The first half (00:09:5B) of each MAC address is known as the Organizationally Unique Identifier (OUI). Simply put, it is the card manufacturer. The second half (EC:EE:F2) is known as the extension identifier and is unique to each network card within the specific OUI. Many access points will ignore MAC addresses with invalid OUIs. So make sure you use a valid OUI code code when you make up MAC addresses. Otherwise, your packets may be ignored by the Access Point. The current list of OUIs may be found here.

With patched madwifi-old CVS 2005-08-14, it's possible to inject packets while in Managed mode (the WEP key itself doesn't matter, as long as the AP accepts Open-System authentication). So, instead of running attack 1, you may just associate and inject / monitor through the athXraw interface:

ifconfig ath0 down hw ether 00:11:22:33:44:55
iwconfig ath0 mode Managed essid 'the ssid' key AAAAAAAAAA
ifconfig ath0 up

sysctl -w dev.ath0.rawdev=1
ifconfig ath0raw up
airodump-ng ath0raw out 6

Then you can run attack 3 or 4 (aireplay-ng will automatically replace ath0 with ath0raw below):

aireplay-ng -3 -h 00:11:22:33:44:55 -b 00:13:10:30:24:9C ath0

aireplay-ng -4 -h 00:10:20:30:40:50 -f 1 ath0

When troubleshooting failed fake authentications, it can be helpful to do a packet capture and compare it to successful ones. As well, simply reviewing this packet captures with WireShark can be very educational.

Here are packet captures of the two types of authentication - open and shared key:

• wep.open.system.authentication.cap
• wep.shared.key.authentication.cap

Here is an example of what a failed authentication looks like:

8:28:02  Sending Authentication Request
18:28:02  Authentication successful
18:28:02  Sending Association Request
18:28:02  Association successful :-)
18:28:02  Got a deauthentication packet!
18:28:05  Sending Authentication Request
18:28:05  Authentication successful
18:28:05  Sending Association Request
18:28:10  Sending Authentication Request
18:28:10  Authentication successful
18:28:10  Sending Association Request

Notice the “Got a deauthentication packet” and the continuous retries above. Do not proceed with other attacks until you have the fake authentication running correctly.

Another way to identify a failed fake authentication is to run tcpdump and look at the packets. Start another session while you are injecting and…

Run: “tcpdump -n -e -s0 -vvv -i ath0”

Here is a typical tcpdump error message you are looking for:

11:04:34.360700 314us BSSID:00:14:6c:7e:40:80 DA:00:0f:b5:46:11:19 SA:00:14:6c:7e:40:80 DeAuthentication: Class 3 frame received from nonassociated station

Notice that the access point (00:14:6c:7e:40:80) is telling the source (00:0f:b5:46:11:19) you are not associated. Meaning, the AP will not process or accept the injected packets.

If you want to select only the DeAuth packets with tcpdump then you can use: “tcpdump -n -e -s0 -vvv -i ath0 | grep DeAuth”. You may need to tweak the phrase “DeAuth” to pick out the exact packets you want.

See the next sections for possible solutions.

Sometimes you periodically get disassociation events. Some access points require to reassociate every 30 seconds, otherwise the fake client is considered disconnected. In this case, setup the periodic re-association delay:

aireplay-ng -1 30 -e 'the ssid' -a 00:13:10:30:24:9C -h 00:11:22:33:44:55 ath0

You receive the following error message when trying to do fake authentication with aireplay-ng:

 15:46:53  Sending Authentication Request
 15:46:53  AP rejects open-system authentication
 Please specify a PRGA-file (-y).

See the How to do shared key fake authentication tutorial.

If fake authentication is never successful (aireplay-ng keeps sending authentication requests) then MAC address filtering may be in place. This is where the access point will only accept connections from specific MAC addresses. In this case you will need to obtain a valid MAC address by observation using airodump-ng. Do not do a fake authentication for a specific MAC address if the client is active on the AP. See the MAC access control troubleshooting tip here

When you enter the command, the system freezes or a line is printed with “Waiting for beacon frame” and then no further activity occurs.

There are many possible root causes of this problem:

• The wireless card is set to a channel which is different then the AP. Solution: Use iwconfig and confirm the card is set to the same channel as the AP.
• The card is scanning channels. Solution: Start airodump-ng with the “-c” or “–channel” parameter and set it to the same channel as the AP.
• The ESSID is wrong. Solution: Enter the correct value. If if contains spaces or special characters then enclose it in quotes. For the complete details, see this FAQ entry.
• The BSSID is wrong. Solution: Enter the correct value.
• You are too far away from the AP and are not receiving any beacons. Solution: You can use tcpdump and/or airodump-ng to confirm you are in fact receiving beacons for the AP. If not, move closer.
• You are not receiving beacons for the AP: Solution: Use “tcpdump -n -vvv -e -s0 -i <interface name>” to confirm you are receiving beacons. Assuming you have dealt with with potential problems above, it could be the drivers or you have not put the card into monitor mode.

For all of the above, running airodump-ng and the related text file should provide all the information you require identify and correct the problem.

Airodump-ng does not show the ESSID! How do I do fake authentication since this is a required parameter?

Answer: You need to patient. When a client associates with the AP, then airodump-ng will obtain and display the ESSID. If you are impatient then deauthenticate a client to get the ESSID immediately.

You get something similar to this:

 Sending Authentication Request
 Authentication successful
 Sending Association Request
 Association successful
 Denied (Code 1) is WPA in use?

You cannot use fake authentication with a WPA/WPA Access Point. It may only be used with WEP Access Points.

You cannot use fake authentication with an Open AP. Open meaning there is no WEP encryption enabled. There is no WEP key to crack!

First, ensure the AP you are trying to connect to is WEP. You cannot do fake authentication to a WPA/WPA2 network.

The most likely reason to get this error message is when the ESSID specified with “-e” does not EXACTLY match the real ESSID. Capitalization, spaces, special characters and so on must match exactly. See this FAQ entry FAQ entry for instructions on how to handle unusual ESSIDs.

You receive an error messages referencing a code number. This Management Frames description is an excellent description of the various error codes you may receive. Just look for the number relating to the authentication or association phase when you received the error.

Also make sure that:

• You are physically close enough to the access point. You can confirm that you can communicate with the specific AP by following these instructions.
• Make sure you are using a real MAC address (see discussion above)
• The wireless card driver is properly patched and installed. Use the injection test to confirm your card can inject.
• The card is configured on the same channel as the AP. Use “iwconfig” to confirm.
• The BSSID and ESSID (-a / -e options) are correct.
• If Prism2, make sure the firmware was updated.

See also: General aireplay-ng troubleshooting