Network Forensics TRACKING HACKERS THROUGH CYBERSPACE Case study hackme inc The mission The Case September 17th 2010 Inter0ptic is on the lam and is pinned down The area is crawling ID: 305464
Download Presentation The PPT/PDF document "Section 5.2" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Section 5.2Network ForensicsTRACKING HACKERS THROUGH CYBERSPACE
Case study :
hackme
,
inc.Slide2
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!Slide3
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:
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.
Pg. 236Slide4
Inspecting the wap
Filter on Beacon frames using
Wireshark
Or
tcpdumpSlide5
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 WAPsSlide6
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
238Slide7
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.”Slide8
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 BPFWhich are protected59274 framesAll frames are protectedSlide9
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 timesSlide10
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 BSSIDRemember WAP provides access to wireless distribution service and act as a stationCommon to see different MAC addresses for different servicesProbably the same device, from now on we will assume that it isSlide11
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
S
tation 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!Slide12
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 WAPSlide13
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 MACARP requestHowever the volume seems to high to be ARPOther reason WEP cracking attackSlide14
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 framesSlide15
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 caseSlide16
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:Slide17
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 seconds09:59:42 to 10:00:50Such a large, unexplained proportion of network activity should be cause for concernSample size is relatively small so there might be a benign explanationSlide18
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
DHCPARPRemote admin access via HTTP or HTTPSSlide19
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 interfaceMost data frames were sent to Joe’s station as is expectedMany were sent to the unknown workstation de:ad:be:ef:13:37Slide20
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 MACResult: traffic occurred at the end of the packet captureSlide21
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 endsSlide22
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 dstShow a breakdown of the number of management frames by senderIt is normal for the WAP to send out more management framesNot normal for the WAP to send out more by two orders of magnitudeSlide23
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’sSlide24
Management subtypes
1
st
column – number of matching frames
2
nd
column – management frame subtype
3rd column –
dst MAC addressWhat does it mean?Most were sent to unknown MAC and were subtype 10Disassociation – in other words “get lost”Also many were subtype 12 - DeauthenticationThe WAP was telling everyone to get lostSlide25
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 secondsSlide26
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:57Slide27
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 WAPInitiated authentication/association negotiationSlide28
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 RequestsSlide29
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:07Timestamp for last Authentication Request (type 0 subtype11) from 1c:4b:d6:69:cd:07Slide30
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
messages09:59:42—The station “1c:4b:d6:69:cd:07” begins broadcasting an even larger flood of data frames09:59:42 to 10:00:47—The WAP appears to send 12,076 Disassociation messages to 1c:4b:d6:69:cd:0710:00:47—The station “1c:4b:d6:69:cd:07” stops sending Authentication and Association Requests10: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 frame10:03:35—Packet
capture
endsSlide31
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 daySlide32
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 averageSlide33
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 timelineSlide34
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:551c:4b:d6:69:cd:07de:ad:be:ef:13:37Slide35
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 attackde:ad:be:ef:13:37 successfully associated with WAPCan we determine if a bad actor successfully executed an attack?Lets investigate further…Slide36
Successful WEP attack?
Use
aircrack-ng
to try to recover WEP key from packet capture
Mostly likely given the evidence the attack was
successful!Slide37
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 keySlide38
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 STANotice:
Authorization headerIndicatesde:ad:be:ef:13:37 attempted to authenticate using HTTP Basic Access AuthenticationSlide39
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!Slide40
Works CitedDavidoff, S., & Ham, J. (2012). Network Forensics Tracking Hackers Through Cyberspace.
Boston: Prentice Hall
.
Disclaimer: All information and data pulled directly from this book.
Pages 236 - 255