1 / 40

Case study : hackme , inc.

Case study : hackme , inc. Section 5.2 Network Forensics TRACKING HACKERS THROUGH CYBERSPACE. The mission.

december
Télécharger la présentation

Case study : hackme , inc.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Case study : hackme, inc. Section 5.2 Network Forensics TRACKING HACKERS THROUGH CYBERSPACE

  2. 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!

  3. 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. 236

  4. Inspecting the wap • Filter on Beacon frames using Wireshark • Or tcpdump

  5. 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

  6. 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) && (wlanmgt.fixed.capabilities.ess == 1) && (wlanmgt.fixed.capabilities.ibss == 0)).”” Pg 238

  7. 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.”

  8. 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

  9. 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

  10. 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

  11. 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!

  12. 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

  13. 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

  14. 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

  15. Pattern and time frames • Look for unusual patterns • Wiresharkcapinfos 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

  16. 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:

  17. 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

  18. 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

  19. 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

  20. 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

  21. 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

  22. 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

  23. 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

  24. 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

  25. 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

  26. 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

  27. 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

  28. 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

  29. 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

  30. 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

  31. 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

  32. 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

  33. 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

  34. 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

  35. 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…

  36. Successful WEP attack? • Use aircrack-ng to try to recover WEP key from packet capture • Mostly likely given the evidence the attack was successful!

  37. 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

  38. 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

  39. 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!

  40. 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.

More Related