How to Decrypt WPA2-PSK using Wireshark

First of all, we need to install Wireshark. later, Need to know which network do you want to decrypt. gather the information like SSID, Password & Channel of that particular Network.
Follow below steps to know , how to decrypt WPA2/PSK.

Note : Better to have Linux machine with us. Like we have to use iwconfig to configure  our interface to monitor mode.

 I am using 5GHz & therefore get 802.11a summary here (If you want sniff 2.4GHz, then you can issue command with 802.11b)

(4402-3) >show ap config 802.11a summary
AP Name                SubBand RadioMAC            Status     Channel   PwLvl   SlotId 
--------------------   ------- ------------------  --------   -------   ------  ------ 
LAP1                      -    64:a0:e7:af:47:40   ENABLED    36        1       1

Simply what you have to do is take a “wireless packet capture” on CH 36 as my AP operate in that channel. I have used BackTrack with USB adapter to take this packet capture. It is just simple 2-3 line configuration required to set up a USB adapter as monitor interface for Wireshark.

root@bt:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:21:9b:62:d0:4a  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:21 Memory:fe9e0000-fea00000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:66 errors:0 dropped:0 overruns:0 frame:0
          TX packets:66 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4665 (4.6 KB)  TX bytes:4665 (4.6 KB)

root@bt:~# ifconfig wlan2 up
root@bt:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:21:9b:62:d0:4a  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:21 Memory:fe9e0000-fea00000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:66 errors:0 dropped:0 overruns:0 frame:0
          TX packets:66 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4665 (4.6 KB)  TX bytes:4665 (4.6 KB)

wlan2     Link encap:Ethernet  HWaddr 00:20:a6:ca:6b:b4  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

root@bt:~# iwconfig wlan2 channel 36
root@bt:~# iwconfig
wlan2     IEEE 802.11abgn  ESSID:off/any  
          Mode:Managed  Frequency:5.18 GHz  Access Point: Not-Associated   
          Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          
lo        no wireless extensions.

eth0      no wireless extensions.

root@bt:~# airmon-ng start wlan2
Found 1 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!

PID    Name
1158    dhclient3
Interface    Chipset        Driver

wlan2        Atheros AR9170    carl9170 - [phy2]
                (monitor mode enabled on mon0)

Once you do this you can open wireshark application & select the interface named “mon0” for wireless packet capturing.

Here is my packet capture (WPA2-PSK-Final) You can open this in Wireshark to test this out by yourself. Now if you analyze this you would see “4-way handshake (EAPOL-Messages 1 to 4)” messages exchanged after Open Authentication phase finished (Auth Request, Auth Response, Association Request, Association Response). Once 4-way handshake is completed, both client & AP having required key for data encryption. So that point onwards all your data frames (not management frames, null frames) are encrypted using CCMP/AES.As you can see below, data frames are encrypted & you cannot see what traffic it is. I have taken frame 103 for example.Before we go & decrypt these messages, it is very important to understand that you have to properly capture  “4-way handshake messages” in your sniffer in order to decrypt using Wireshark. If you are not capture M1-M4 messages successfully, Wireshark will not be able to derive all the keys to decrypt rest of that data. Here is one example where all the frames have not been captured properly in 4-way handshake process (This happened when I was using same USB adapter with Fluke WiFi Analyzer)Now you have to go to “Edit -> Preferences -> Protocol -> IEEE 802.11” & need to “Enable Decryption” checkbox. Then click on Edit “Decryption Keys” section & add your PSK by click “New“.  You have to select Key-type as “WPA-pwd” when you enter the PSK in plaintext.

If you enter the 256bit encrypted key then you have to select Key-type as “wpa-psk“.If you want to get the 256bit key (PSK) from your passphrase, you can use this page. It use the following formula to do this conversion

PSK=PBKDF2(PassPhrase, SSID,SSIDLength,4096,256)

Here is 256bit PSK derived from above

I have used simple plaintext password (ie wpa-pwd key type) in below. You can simply enter the plaintext password only (without SSID name).In this case wireshark try to use last seen SSID, It is always good practice to use <password:SSID>.

I have used my configured PSK “Cisco123Cisco123” & specify my SSID as “TEST1“. Refer this document for more details of this settings.

Then you need to hit “Apply”

As you can see below, now you will able to see the traffic inside these data frames. Here is the same frame (103) which you saw earlier in encrypted format, but now wireshark able to decrypt it.Now if you look further you will see the client is getting IP through DHCP (DORA–Discover, Offer, Request, ACK) & then register to a CME (SKINNYprotocol) & then establish a voice call (RTP) details. Now you can analyses these packets in detail

This trick may be useful to you when you do wireless troubleshooting on your PSK networks. 

802.11 Frames explanation

Introduction

802.11 frames : A starter guide to learning wireless sniffer traces

Frame types

All lines in italic and smaller characters refer to Contention-Free systems and are never implemented in 99% of the wireless devices, so of little importance.

Type value	Type description	Subtype value	Subtype description	Wireshark display filter
00	Management	0000	Association Request	wlan.fc.type_subtype == 0x00
00	Management	0001	Association Response	wlan.fc.type_subtype == 0x01
00	Management	0010	Reassociation Request	wlan.fc.type_subtype == 0x02
00	Management	0011	Reassociation Response	wlan.fc.type_subtype == 0x03
00	Management	0100	Probe Request	wlan.fc.type_subtype == 0x04
00	Management	0101	Probe Response	wlan.fc.type_subtype == 0x05
00	Management	0110-0111	Reserved
00	Management	1000	Beacon	wlan.fc.type_subtype == 0x08
00	Management	1001	ATIM	wlan.fc.type_subtype == 0x09
00	Management	1010	Disassociation	wlan.fc.type_subtype == 0x0A
00	Management	1011	Authentication	wlan.fc.type_subtype == 0x0B
00	Management	1100	Deauthentication	wlan.fc.type_subtype == 0x0C
00	Management	1101	Action	wlan.fc.type_subtype == 0x0D
00	Management	1110-1111	Reserved

Type value	Type description	Subtype value	Subtype description		Wireshark display filter
01	Control	0000-0111	Reserved
01	Control	1000	Block Ack Request	wlan.fc.type_subtype == 0x18
01	Control	1001	Block Ack	wlan.fc.type_subtype == 0x19
01	Control	1010	PS-Poll	wlan.fc.type_subtype == 0x1A
01	Control	1011	RTS	wlan.fc.type_subtype == 0x1B
01	Control	1100	CTS	wlan.fc.type_subtype == 0x1C
01	Control	1101	ACK	wlan.fc.type_subtype == 0x1D
01	Control	1110	CF-end	wlan.fc.type_subtype == 0x1E
01	Control	1111	CF-end + CF-ack	wlan.fc.type_subtype == 0x1F

Type value	Type description	Subtype value	Subtype description		Wireshark display filter
10	Data	0000	Data	wlan.fc.type_subtype == 0x20
10	Data	0001	Data + CF-ack	wlan.fc.type_subtype == 0x21
10	Data	0010	Data + CF-poll	wlan.fc.type_subtype == 0x22
10	Data	0011	Data +CF-ack +CF-poll	wlan.fc.type_subtype == 0x23
10	Data	0100	Null	wlan.fc.type_subtype == 0x24
10	Data	0101	CF-ack	wlan.fc.type_subtype == 0x25
10	Data	0110	CF-poll	wlan.fc.type_subtype == 0x26
10	Data	0111	CF-ack +CF-poll	wlan.fc.type_subtype == 0x27
10	Data	1000	QoS data	wlan.fc.type_subtype == 0x28
10	Data	1001	QoS data + CF-ack	wlan.fc.type_subtype == 0x29
10	Data	1010	QoS data + CF-poll	wlan.fc.type_subtype == 0x2A
10	Data	1011	QoS data + CF-ack + CF-poll	wlan.fc.type_subtype == 0x2B
10	Data	1100	QoS Null	wlan.fc.type_subtype == 0x2C
10	Data	1101	Reserved	wlan.fc.type_subtype == 0x2D
10	Data	1110	QoS + CF-poll (no data)	wlan.fc.type_subtype == 0x2E
10	Data	1111	Qos + CF-ack (no data)	wlan.fc.type_subtype == 0x2F
11	Reserved	0000-1111	Reserved

Small words about each types

-Association request is sent by a station to associate to a BSS.

-Association response is sent in response to an association request

-Reassociation request is sent by a station changing association to another AP in the same ESS (so roaming between APs, or reassociating with the same AP)

-Reassociation response is the response to the reassociation request

-Probe request is sent by a station in order to “scan” for an SSID

-Probe response is sent by each BSS participating to that SSID

-Beacon is a periodic frame sent by the AP (or stations in case of IBSS) and giving information about the BSS

-ATIM is the traffic indication map for IBSS (in a BSS, the TIM is included in the beacon)

-Disassociation is sent to terminate the association of a station

-Authentication is the frame used to perform the 802.11 authentication (and not any other type of authentication)

-Deauthentication is the frame terminating the authentication of a station.

-Action is a frame meant for sending information elements to other stations (when sending in a beacon is not possible/best)

-PS-Poll is the Power-save poll frame polling for buffered frames after a wake-up from a station

-RTS is the request-to-send frame

-CTS is the clear-to-send frame (often response to RTS)

-ACK is the acknowledge frame sent to confirm receipt of a frame.

-Data frame is the basic frame containing data

-Null frame is a frame meant to contain no data but flag information

-QoS data is the QoS version of the data frame

-QoS null is the QoS version of the null frame

Here is what a general frame looks like. We will show what the frame control field contains and then explain the addresses fields.

Here is the frame control field detailed:

1.1 Protocol version field: 2 bits field that is currently set to 0 in 2007 revision of the standard. It will be incremented whenever a new revision of the standard comes out and shows fundamental incompatibility with previous versions.

1.2 and 1.3 Type and Subtype fields: Type is 2 bit long and Subtype is 4 bits long. The type indicates whether the frame is control, management or data and the subtype defines the frame more precisely. For values, please refer the to chunk “frame types”.

1.4 and 1.5 To DS and From DS: The following table show the meaning of these fields combinations.

To DS and From DS   values	Meaning
To DS=0, From DS=0	A frame sent between two stations not being APs in a BSS   or IBSS. It is also the case for all management and control frames (directly   sent to the AP and not the DS)
To DS=0, From DS=1	A frame sent by a station for an AP (destined to the DS)
To DS=1, From DS=0	A frame exiting the DS for a station.
To DS=1,From DS=1	Only frame using all four addresses fields. Seen in   Wireless DS (mesh, repeater, …) where an AP sends a frame to another AP, it   is exiting the DS and destined to the DS at the same time in that situation.

What’s the point of these DS fields? They are useful to identify the addresses fields (see later here) and they can also help in tricky situations. For example, you see on both wired and wireless side a WLCCP frame with STA being the source and broadcast destination. It could be the station sending it or the AP but as it is broadcast, it appears on both sides and you don’t know. The DS fields will tell you the truth here.

1.6 More fragments: Bit set as 1 when more fragments are to follow. See in other chunk.

1.7 Retry: This bit is set as 1 when the frame is a retransmission of an earlier frame.

1.8 Power management field: Set as 1 when station will to sleep and 0 when station will stay awake. See in other chunk.

1.9 More Data: Used in power save mode to indicate to the station that more frames are buffered on the AP. See in other chunk.

1.10 Protected Frame: This bit is set as 1 with data frames and “authentication” management frames to indicate that the body of the frame can only be read if decrypted. This field used to be called “WEP encrypted” in earlier revisions.

1.11 Order field: This bit is set as 1 with non-QoS frames where the order of frames must be kept.

That’s it for the control field. Let’s review the general frame format again and explain the addresses fields:

2. Duration/ID: This field is an ID in PS-Poll mode, it then contains the Association ID of the station. In Qos and non-Qos frames, it has a duration meaning different in these two cases. It can basically be considered as the duration necessary to send the frame and the ACK. It helps other stations to wait for the right amount of time before checking the medium again.

3. The 4 addresses field can have different meanings as well. Here are the meanings :

Destination Address (DA) : Final recipient of the frame

Source Address (SA) : Original source of the frame

Receiver Address (RA) : Immediate receiver of the frame.

Transmitter Address (TA) : Immediate sender of the frame.

-ToDS=0,FromDS=0 situation. The frame is sent by a station to another station. The transmitter is the original source and the receiver is the end destination. So :

Address 1=RA/DA (identical)

Address 2=TA/SA (identical)

Address 3=BSSID

Address 4=n/a

-ToDS=0,FromDS=1 situation. The frame is being forwarded by an AP typically. In this case, the AP is the transmitter but not the original source. So :

Address 1=RA/DA (identical = end station)

Address 2=TA/BSSID (transmitter is the AP, it is also the BSSID by the way)

Address 3=SA (original station sending the frame)

Address 4=n/a

-ToDS=1,FromDS=0 situation. The frame is being sent from a station to the DS. Here the receiver will be typically the AP which is maybe not the final destination. So:

Address 1=RA/BSSID (receiver is the AP which is the BSSID)

Address 2=TA/SA (original station sending)

Address 3=DA (end station)

Address 4=n/a

-ToDS=1,FromDS=1 situation. The frame is sent from an AP to another. So the first AP is the transmitter but not the original source. The second AP is the receiver but not the destination.

Address 1=RA (end AP)

Address 2=TA (first AP)

Address 3= DA (end station)

Address 4=SA (original station)

4. Sequence control field: This field contains a 4 bit fragment number and 12 bit sequence number that helps in reconstituting multi-fragments frame as well as eliminate duplicate and mis-ordered frames.

5. Frame Check Sequence : CRC at the end of the frame to check its integrity. It is a basic check that can be seconded by another frame integrity check field depending on encryptions used.

With this document, you will find some sniffer traces attached. They are examples of DS bit set or not set in real scenarios. You will find below some comments about each traces.

If you wonder where to check the DS bits, go in the 802.11 header, frame control and then the flag bits.

0-0.pcap: This trace shows a series of frames containing 0 in both DS bits. This reflects a situation where a station (intel mac address) is joining an ESS (Airespace Mac addr). The frames are sent from the station directly to the access point and are not intended to the DS since the station didn’t join yet. Same goes for the other way, when the AP is sending a frame, the frame goes to a station and does not come from the DS but the AP itself. So all frames shown have 0 in “from DS” and “to DS”.

Another good examples are the RTS/CTS frames, those frames are directed from a station to another and to intended to the DS.

1-0.pcap: This trace is just moments after the previous trace in time. The station is going through the EAPOL exchange. There we can see that the frames sent by the station are “to the DS” and the frames sent back to the station are “from the DS”. All Data frames follow this logic (mostly) of being “to DS” when sent by the station and “from DS” when sent by the AP.

1-1.pcap: A first look at this trace would let you think that we are seeing a retransmission. However, a look at the DS bits shows you that the first frame is sent by the client. The second by an AP to the client. And most important, the third is from an AP to another AP. This is then a “repeater AP” situation! And nothing to do with a retransmission because of packet loss …