CASE STUDY : HACKME, INC.
Section 5.2
Network Forensics
TRACKING HACKERS THROUGH CYBERSPACE
THE MISSION
The Case: September 17th, 2010: Inter0ptic is on the lam and is pinned down. The area is
crawling with cops, and so he must stay put. But he also desperately needs to be able to get a
message out to Ann and Mr. X. Lucky for him, he detects a wireless access point (WAP) in the
building next door that he might be able to use. But it is using encryption, and there are no
other opportunities available. What is Inter0ptic to do?
Meanwhile . . . Next door, Joe is a sysadmin at HackMe, Inc. He runs the technical
infrastructure for a small company, including a WAP that is used pretty much exclusively by
him. He’s trying to use it now, and has discovered that he’s begun to get dropped. He
captures some traffic, but he really has no idea how to interpret it. Suddenly he discovers he
can’t even login to administer his WAP at all!
THE MISSION CONTINUED
The Challenge: You are the forensic investigator. Your team got a tip that Inter0ptic might be hunkered
down in the area. Can you figure out what’s going on and track the attacker’s activities?
The following questions will help guide your investigation:
•
Pg. 236
•
What are the BSSID and SSID of the WAP of interest?
•
Is the WAP of interest using encryption?
•
What stations are interacting with the WAP and/or other stations on the WLAN?
•
Are there patterns of activity that seem anomalous?
•
How are they anomalous: Consistent with malfunction? Consistent with maliciousness?
•
Can we identify any potentially bad actors?
•
Can we determine if a bad actor successfully executed an attack?
Evidence: Joe has provided you with a packet capture (wlan.pcap) and permission to inspect it in
any way you need to either solve his problem, catch Inter0ptic, or both. He also helpfully tells you
that his own system’s MAC address is 00:11:22:33:44:55, and reiterates that no one else should be
using his WAP.
INSPECTING THE WAP
•
Filter on Beacon frames using Wireshark
•
Or tcpdump
WAP-ANNOUNCING MANAGEMENT FRAMES
•
Filter to display only Beacon and Probe Response frames
• Ess is set to 1
• IBSS is set to 0
• List BSSIDs of know WAPs
TAKE INVENTORY OF STATIONS OF WLAN
•
Inspect earlier Beacon frame more closely
•
“A screenshot of Wireshark used with a display filter that tests for frames that emanate
from WAPs. The display filter used is “((wlan.fc.type subtype == 0x08 || wlan.fc.type
subtype == 0x05) && (wlan mgt.fixed.capabilities.ess == 1) && (wlan
mgt.fixed.capabilities.ibss == 0)).”” Pg 238
CLOSER LOOK CONTINUED
•
“An 802.11 management frame with subtype 0x8 (a
Beacon frame). The BSSID (00:23:69:61:00:d0) is
highlighted.”
•
“An 802.11 management frame with subtype 0x8 (a
Beacon frame). The SSID parameter set is shown,
with the tag interpretation (“Ment0rNet”)
highlighted.”
•
“An 802.11 management frame with subtype 0x8 (a
Beacon frame). The field containing “Current
Channel” (channel 2) is highlighted.”
WLAN ENCRYPTION
•
Is WLAN using encryption? Yes
• Notice the Protected bit is set to 1
•
Using tcpdump count total frames
• 59274 frames
•
Use TCPdump and BPF
• Which are protected
• 59274 frames
• All frames are protected
ASSOCIATED STATIONS
•
Using Wireshark
• Filter Association Response
• Successful associations (2-byte status code) – wow there are a lot!
• Use tcpdump to further filter
• Joe connected four times and an unknown connected 64 times
QUICK AND DIRTY STATISTICS
•
People in the neighborhood
•
Tshark is an excellent tool for statistics
•
Start with a known result - the number of protected data frames in the capture
•
Show the aggregated count of the number of encrypted data frames from each MAC
address
•
Unknown station sent roughly three times the data that Joe did
•
Notice “00:23:69:61:00:ce” only last octet differs from BSSID
• Remember WAP provides access to wireless distribution service and act as a station
• Common to see different MAC addresses for different services
• Probably the same device, from now on we will assume that it is
QUICK AND DIRTY CONTINUED
•
Look at the comparative count of frame destination addresses
• Approximately 42,837 encrypted data frames went to ff:ff:ff:ff:ff:ff
• Almost the same as frames sent from 1c:4b:d6:69:cd:07
• Station 00:23:69:61:00:ce (likely WAPs STA interface) received 14,076
• Roughly the same as Joe’s station - 00:11:22:33:44:55
•
This is probably not coincidence!
SRC AND DST
•
Look at source and destination to prove the quick and dirty theory
•
The mystery station (1c:4b:d6:69:cd:07) sent all 42.816 frames
•
Most of the remaining frames sent between Joe’s station and the WAPs presumed STA
interface
•
Notice the other odd station, de:ad:be:ef:13:37, also communicated with the WAP
PERSPECTIVE
•
59,274 data frames went sent as follows:
• 72% were sent from an unknown station (1c:4b:d6:69:cd:07) to the broadcast
address (ff:ff:ff:ff:ff:ff)
• 25% were transmitted between Joe’s station (00:11:22:33:44:55) and the WAP
(00:23:69:61:00:ce)
• 2% were transmitted between an unknown station (de:ad:be:ef:13:37) and the WAP
(00:23:69:61:00:ce)
•
Legitimate reason to send to broadcast MAC
• ARP request
• However the volume seems to high to be ARP
•
Other reason
• WEP cracking attack
ARP REPLAY ATTACK
•
WEP attack depends on the volume of unique IVs exposed
• ARP is the perfect venue for this
• Causes other stations to send timely responses
• If all packets are encrypted, and attacker does not know the key, which traffic gets
replayed? Why?
• All data sent to the broadcast MAC address
• More then likely it is an ARP request
• Causes other stations to generate unique IV frames
PATTERN AND TIME FRAMES
•
Look for unusual patterns
• Wireshark capinfos shows duration of packet capture
• Note:
• This forensic workstation’s time zone was MDT (GMT-6)
• Human readable dates will be shown in MDT for the remainder of the case
PATTERN AND TIME FRAME CONTINUED
•
Granular timestamp
•
Total duration of packet capture
• 414 seconds (6.9 minutes)
•
Joe’s station (11:22:33:44:55:66) sent:
CONTINUES AGAIN
•
Unknown station 1c:4b:d6:69:cd:07 sent 42,816 data frames to broadcast
•
Broadcast traffic from 1c:4b:d6:69:cd:07 lasted less than 69 seconds
• 09:59:42 to 10:00:50
•
Such a large, unexplained proportion of network activity should be cause for concern
• Sample size is relatively small so there might be a benign explanation
ANOTHER INTERESTING PATTERN
•
Distribution of communication partners with 00:23:69:61:00:ce (the WAP’s STA interface)
• Layer 3+ services provided
• Ask Joe or inspect it for yourself
• Possibilities
• DHCP
• ARP
• Remote admin access via HTTP or HTTPS
PATTERNS CONTINUED
•
There are data frames coming from:
• WAPs BSSID
• STA MAC addresses
•
Look at frames sent by the WAP BSSID
• Notice Joe’s station received more data frames than the other stations
•
Look at frames sent by the WAP STA interface
• Most data frames were sent to Joe’s station as is expected
• Many were sent to the unknown workstation de:ad:be:ef:13:37
INVESTIGATE UNKNOWN MAC
•
Look at distribution of dst MAC addresses originating from de:ad:be:ef:13:37
•
Most of the frames were sent to WAP STA interface
•
How does this fit into our timeline?
• Use tshark to find start and end times of traffic originating from the known MAC
• Result: traffic occurred at the end of the packet capture
TIMELINE SO FAR…
•
09:56:41—Packet capture begins
•
09:59:42 to 10:00:51—1c:4b:d6:69:cd:07 broadcasted large volumes of data frames
•
10:02:14 to 10:03:33—de:ad:be:ef:13:37 sent small volume of data frames to the WAP’s
STA interface (00:23:69:61:00:ce)
•
10:03:35—Packet capture ends
CLOSER LOOK AT MANAGEMENT FRAMES
•
Look at management frames specific to BSSID of interest
• Wireshark’s display filter “(wlan.fc.type == 0) && (wlan.bssid ==
00:23:69:61:00:d0).”
•
Frequency by src and dst
• Show a breakdown of the number of management frames by sender
• It is normal for the WAP to send out more management frames
• Not normal for the WAP to send out more by two orders of magnitude
WAPs OUTBOUND
•
WAPs outbound management frames from the BSSID interface
• Sort them by dst address
• Majority going to the unknown MAC
• 20 times more than were went to Joe’s
MANAGEMENT SUBTYPES
•
1st column – number of matching frames
•
2nd column – management frame subtype
•
3rd column – dst MAC address
•
What does it mean?
•
Most were sent to unknown MAC and were subtype 10
• Disassociation – in other words “get lost”
•
Also many were subtype 12 - Deauthentication
• The WAP was telling everyone to get lost
TIMING OF “GET LOST” FRAMES
•
Start by testing the filter
• Match all subtype 10 sent from WAPs BSSID interface to unknown station
• Should equal 12,076
• Filter worked!
• Use same filter to establish time boundaries at the head and tail
• The WAP told the unknown MAC, 1c:4b:d6:69:cd:07, to Disassociate 12,076 in 65
seconds
TIMING CONTINUED
•
Look at the timing of subtype 12 frames
•
The WAP broadcast 2454 Deauthentication messages in the same time
• 09:59:03 to 10:00:57
PARTIAL EXPLANATION
•
802.11 does not include mechanism for verifying authenticity of sender
• Can be spoofed
• DOS attack
• Attacker broadcast Disassociation and Deauthentication to disrupt the network
• Joe’s station likely thought these were really from the WAP
• Initiated authentication/association negotiation
POSSIBLE BAD ACTOR
•
Hypothesize that 1c:4b:d6:69:cd:07 is a suspicious actor
•
Record all activities coming from this station
•
Update timeline
• 42,816 data frames
• 77 authentication Requests
• 69 Association Requests
BAD ACTOR CONTINUED
•
Timestamp for first Association Request (type 0 subtype 0) from 1c:4b:d6:69:cd:07
•
Timestamp for last Association Request (type 0 subtype 0) from 1c:4b:d6:69:cd:07
•
Timestamp for first Authentication Request (type 0 subtype11) from 1c:4b:d6:69:cd:07
•
Timestamp for last Authentication Request (type 0 subtype11) from 1c:4b:d6:69:cd:07
TIMELINE
•
09:56:41—Packet capture begins
•
09:58:52—Station “1c:4b:d6:69:cd:07” begins sending both Authentication and Association
Requests, essentially simultaneously, at a rate exceeding one per second
•
09:59:03—The WAP appears to begin broadcasting a larger flood of Deauthentication
messages
•
09:59:42—The station “1c:4b:d6:69:cd:07” begins broadcasting an even larger flood of data
frames
•
09:59:42 to 10:00:47—The WAP appears to send 12,076 Disassociation messages to
1c:4b:d6:69:cd:07
•
10:00:47—The station “1c:4b:d6:69:cd:07” stops sending Authentication and Association
Requests
•
10:00:51—The station “1c:4b:d6:69:cd:07” stops sending broadcasted data frames
•
10:00:58—The WAP’s apparent Deauthentication broadcasts stop
•
10:02:14—Station “de:ad:be:ef:13:37” sends first data frame to the WAP’s STA interface
•
10:03:33—Station “de:ad:be:ef:13:37” sends last captured data frame
•
10:03:35—Packet capture ends
THEORY
•
Joe says the station with MAC address 1c:4b:d6:69:cd:07 is an unknown network intruder
•
Evidence suggests that this intruder may be an attacker
•
Hypothesis says large volume of broadcast frames are ARP requests
• WEP cracking attack
• Get supporting evidence
• Generation of large number of IVs will be evident on work stations
•
Fact
• Packet capture began 09:56:41.085810 and ended at 10:03:34.662764 on
September 17, 2010.
• The station 1c:4b:d6:69:cd:07 began sending broadcasted data frames
09:59:42.220425 and ending at 10:00:50.972590 on the same day
STIMULUS AND RESPONSE
•
Before flood of data frames began – 694 unique IVs in 181.134615 s = 3.831405 average
•
During the flood – 13,657 unique IVs in 68.752165 s = 198.641017 average
•
After the flood – 1240 unique IVs in 163.690174 s = 7.575287 average
WEP CRACKING ATTACK
•
Given evidence
• Reasonable that station 1c:4b:d6:69:cd:07 engaged in an attack on the WAP
• Beginning 09:58:51
• Lasting a few minutes at most
• Must test theory
•
Corollation
• MAC address de:ad:be:ef:13:37 was able to authenticate most likely
• How are de:ad:be:ef:13:37 and 1c:4b:d6:69:cd:07 related?
• Strongly implied that they are by the timeline
RESPONSE TO CHALLENGE QUESTIONS
•
What are the BSSID and SSID of the WAP of interest?
• BSSID: 00:23:69:61:00:d0
• SSID: Ment0rNet
•
Is the WAP of interest using encryption?
• Yes, every single data frame inspected was encrypted.
•
What stations are interacting with the WAP and/or other stations on the WLAN? There
were three stations that we could easily detect based on an analysis of management
frame activity:
• 0:11:22:33:44:55
• 1c:4b:d6:69:cd:07
• de:ad:be:ef:13:37
CHALLENGE QUESTIONS CONTINUED
•
Are there patterns of activity that seem anomalous?
• Flood of data frames from unknown station, coincides with spike in unique IVs
•
How are they anomalous: Consistent with malfunction? Consistent with maliciousness?
• Consistent with WEP cracking attack
•
Can we identify any potentially bad actors?
• 1c:4b:d6:69:cd:07 likely launched a WEP cracking attack
• de:ad:be:ef:13:37 successfully associated with WAP
•
Can we determine if a bad actor successfully executed an attack?
• Lets investigate further…
SUCCESSFUL WEP ATTACK?
•
Use aircrack-ng to try to recover WEP key from packet capture
•
Mostly likely given the evidence the attack was successful!
NEXT STEP
•
Notify Joe that his network has most likely been compromised
• WEP key probably needs to be changed
•
Prove that WEP was indeed compromised
• Use airdecap-ng to decode an encrypted frame using discovered WEB key
NEXT STEP CONTINUED
•
Inspect the decrypted content with Wireshark
•
Reconstructed stream
• de:ad:be:ef:13:37 (192.168.1.109) and 00:23:69:61:00:ce (192.168.1.1) WAPs STA
• Notice:
• Authorization header
• Indicates
• de:ad:be:ef:13:37
attempted to authenticate
using HTTP Basic Access
Authentication
CONCLUSION
•
Our theory is most likely correct
•
The network password was admin
•
Something adverse was done to the network
•
What?
• That’s up to you to solve!
Disclaimer: All information and data pulled directly from this book.
Pages 236 - 255
Works Cited
Davidoff, S., & Ham, J. (2012). Network Forensics Tracking Hackers Through Cyberspace.
Boston: Prentice Hall.