Contact Form

Name

Email *

Message *

Tips for an Information Security Analyst/Pentester career - Episode 7: Wireshark basics (part 2b: hands-on)

Introduction

In this post, we're gonna continue our forensic analysis of a network capture through Wireshark.

This time I decided to use My mac directly instead of virtual machines, because commands seem to work much better.

I was actually able to have output from some commands, unlike Kali.

I used a sort of cheat sheet, a list of commands I want to show you. I'm sorry but comments are in Italian.
We're gonna use the same capture file as before, but this time we'll be delving much more into our analysis.

  • Encrypted beacon frames

We're going to use the following command: tcpdump -nne -r  /Users/mattia/Desktop/gunman1-01.cap 'wlan[0]=0x80'

In the above command, wlan[0]=0x80 represent the beacon frame type. 
The command returns the number of encrypted beacon frames in our capture file. Beacon frames are transmitted periodically to announce the presence of a wireless LAN. They are transmitted by the access point (AP) in an infrastructure basic service set (BSS). In IBSS network, beacon generation is distributed among the stations.

We see we got a bunch of encrypted beacon frames. We can isolate the ones we want by using grep to find the frames related to LoneGunman.

We find only one frame.


  • Number of stations associated with the rogue access point:
tcpdump -nne -r /Users/mattia/Desktop/gunman1-01.cap 'wlan[0]=0x80 and wlan[26:2]= 0x0000'| awk '{print $3}' | sort | uniq -c | sort -nr


We didn't have luck with this command because the capture file results to be truncated.


  • Number of nearby stations:
tshark -nn -r /Users/mattia/Desktop/gunman1-01.cap -Y '((wlan.fc.type_subtype==0x20) && (wlan.fc.protected==1)) && (wlan.bssid==00:0D:88:B6:F7:1E)'  | wc -l 

In this command, wlan.fc.type_subtype==0x20 represents data management frame, wlan.fc.protected==1 indicates encryption is enabled on the WAP.










So we find 66 nearby stations and 66 frames were exchanged between out rogue access point and other devices.
  • Number of aggregated frames sent out by each MAC address:

tshark -nn -r /Users/mattia/Desktop/gunman1-01.cap -Y '((wlan.fc.type_subtype==0x20) && (wlan.fc.protected==1) && (wlan.bssid==00:0D:88:B6:F7:1E)' -T fields -e wlan.sa | sort | uniq -c | sort -nr

We can break down those 66 frames with this command. 51 out of 66 frames were transmitted by the rogue access point (around 77% of overall traffic)


  • Destination addresses for frames:

tshark -nn -r /Users/mattia/Desktop/gunman1-01.cap -Y '((wlan.fc.type_subtype==0x20) && (wlan.fc.protected==1)) && (wlan.bssid==00:0D:88:B6:F7:1E)' -T fields -e wlan.da | sort | uniq -c | sort -nr

We can break down the frames based on destination MAC address and we find out that most frames (59 out of 66, about 89%) were sent to the broadcast MAC address.


  • Frames breakdown for both source and destination MAC address:

tshark -nn -r /Users/mattia/Desktop/gunman1-01.cap -Y '((wlan.fc.type_subtype==0x20) && (wlan.fc.protected==1)) && (wlan.bssid==00:0D:88:B6:F7:1E)' -T fields -e wlan.sa -e wlan.da | sort | uniq -c | sort -nr

That tells us 50 frames out of 66 (around 75%) were sent by the rogue access point to the broadcast MAC address. 

The other station exchanged around 13% of traffic (9 frames) with the broadcast MAC address, as well. 

This appears to be an anomaly in our network traffic and we'll analyze it much closer.


  • Number of aggregated frames transmitted by each MAC address:

tshark -nn -r /Users/mattia/Desktop/gunman1-01.cap -Y '(wlan.fc.type==2) && (wlan.bssid==00:0D:88:B6:F7:1E) && (wlan.bssid==00:0D:88:B6:F7:1E)' -T fields  -e wlan.da | sort | uniq -c | sort -nr

This confirms again 59 frames were exchanged between the rogue access point and the broadcast MAC address.



I already stated this is something suspicious. In fact, a plausible reason for it to occur could be an ARP request from clients.

However, the number of such requests appears to be abnormally high, compared with other stations. A more plausible explanation for such a behavior could be an attack on the wireless network.

More specifically, as the WAP supports WEP, it's totally possible that a WEP cracking attack was in progress. 

Such attack is performed by sending out many 802.11 data frames, in order for the attacker to trigger other stations on the network to respond. One of the best ways to do that is to replay ARP requests.

In this type of attack the attacker listens for data frames sent to the broadcast MAC address, primarily ARP requests, and replays to them thereby speeding up the WEP-cracking attack. At the time, I was in fact able to break the WEP encryption.

We can also have statistics for type of traffic.

  • Number of association requests frames:

tshark -nn -r /Users/mattia/Desktop/gunman1-01.cap -Y '(wlan.fc.type==0) && (wlan.bssid==00:0D:88:B6:F7:1E) && (wlan.bssid==00:0D:88:B6:F7:1E)' -T fields  -e wlan.da | sort | uniq -c | sort -nr


  • Number of association response frames: 
tshark -nn -r /Users/mattia/Desktop/gunman1-01.cap -Y '(wlan.fc.type==1) && (wlan.bssid==00:0D:88:B6:F7:1E) && (wlan.bssid==00:0D:88:B6:F7:1E)' -T fields  -e wlan.da | sort | uniq -c | sort -nr

Only 1 frame was returned as association response.


Wrap-up

We were able to delve much more into our traffic capture with Wireshark, tshark and tcpdump.

And actually tshark maybe allows a little more flexibility than Wireshark.

Wireshark can also be used for hacking and pentesting, other then for forensics purposes, but we'll maybe analyze it in another post.

It's a tool that can be used for good or bad, depending on who uses it.

External sources: 

Comments

Related Posts Plugin for WordPress, Blogger...