Presentation on theme: "Case study : The curious mr. x"— Presentation transcript:
1 Case study : The curious mr. x Section 4.2Network ForensicsTRACKING HACKERS THROUGH CYBERSPACE
2 The missionThe case: While a fugitive in Mexico, Mr. X remotely infiltrates the Arctic Nuclear Fusion Research Facility (ANFRF) lab network over the Internet. Sadly, Mr. X is not yet very stealthy.Meanwhile Unfortunately for Mr. X, the ANFRF network is instrumented to capture flow record data. Security staff notice port scanning from his external IP address, , beginning at :51:46 in the Cisco ASA flow record logs. His activities are discovered and analyzed by you!Challenge: You are the forensic investigator. Your mission is to:Identify any compromised systemsDetermine what the attacker found out about the network architectureEvaluate the risk of data exfiltrationSince the Arctic Nuclear Fusion Research Facility stores a lot of confidential information, management is highly concerned about the risk of data exfiltration. If you find suspicious traffic, provide an analysis of the risk that Secret Information was compromised. Be sure to carefully justify your conclusions.
3 The mission continuedNetwork: The Arctic Nuclear Fusion Research Facility network consists of three segments:Internal network: /24DMZ: /24The “Internet”: /24 [Note that for the purposes of this case study, we are treating the /24 subnet as “the Internet.” In real life, this is a reserved nonroutable IP address space.]Evidence: Security staff at ANFRF collect network flow data from a Cisco ASA switch/ firewall that connects all three subnets at the perimeter. The flow record data is exported in Cisco’s NetFlow v9 format to a collector running nfcapd. (Note that to collect data in Cisco’s proprietary NetFlow v9 format, a specific fork of the nfdump suite, nfdump NSEL, was used for collection and analysis.)In addition, the Cisco ASA is also configured with a SPAN port that monitors the Internal and DMZ subnets. There is an Argus listener connected to the SPAN port, which retains flow record data in Argus format from the two subnets ( /24 and /24).You are provided with two files containing data to analyze:cisco-asa-nfcapd.zip—A zip archive containing flow records from the perimeter Cisco ASA, stored by the nfdump collector utility (nfcapd) in 5-minute increments.argus-collector.ra—An Argus archive containing flow record data collected from the Internal and DMZ subnets via a SPAN port.
4 Important notesAs you will see in the flow record data, there is a time skew of approximately 8 seconds between the Cisco ASA and the Argus listener. In addition, be aware that Network Address Translation (NAT) is used on this network. The DMZ IP address translates to the external address , and the internal IP address translates to the external address Please note that the command output shown in the analysis had been modified to fit the page (in some cases, extraneous columns have been removed for brevity).
5 Analysis Cisco ASA flow: first steps Use nfdump to look for flows relating to the known attacker system –Notice source port stays the same.Common in port scanning
6 Looking for open ports Which ports did the attacker find open? Flows that were not DENIED by the firewall reached the target system and lead to a responseNotice port 22
7 External Attacker & port 22 Is there more port 22 traffic relating to the attacker?Use nfdump to filterNotice the series of connection attemptsByte size 3755Roughly every six secondsWhat does it mean?Port 22 = sshCommon target for brute-forceProcess is commonly automatedRegular intervalsSame small amount of dataNotice the byte change at :00: followed by a quick connectionAt :01: a flow was created: (attacker) – (target).
8 Hypothesis so far Flow records indicate: Automated brute-force password-guessing attack on an SSH serverTarget:Attack lasted about 8 minutesResult:Most likely successfulInformation used in hypothesisTimingPort numberData transfer size
9 Internal argus flow records Lets search for traffic relating to attackRemember internal NATed address = externalAlso remember the 8 second time skewCorrelating evidenceHelpful info:Use the ra man pageto identify statechanges
10 Port 22 Attacker initiated a connection three times Sent TCP SYN, received SYN ACK, sent RSTConnection was aborted by attacker before TCP handshake was completeMatches behavior of port scanner testingAttacker now knows port 22 is openNext we see several short connections every six secondsSent TCP SYN, received SYN ACK, handshake established, sent FIN, received FINSuccessful Layer 4TCP communication
11 Port 22 continuedFor more than 15 minutes the connection and subsequent data transfers continue
12 The pattern graphed Evidence supports the hypothesis “A graph of Argus flow record data from the attacker ( ) to a victim server in the DMZ ( ) on port 22. Notice the 8-minute automated brute-force password- guessing attack, followed by a short break, and then followed by a higher-bandwidth exchange of data (implying that the attack was probably successful).” Pg 189
13 The DMZ victim – (aka )First noticeable difference in SSH connection from to:01:08 (in the Argus flow record data)Size of data is a lot bigger than previous attempts, indicating a successful connectionOver a minute later we see a different connection, indicates a manual connectionNow /80 is communicating to external /80Notice that at 13:03:31 it begins to send TCP SYN to internal systems on port 80 and 443 and at 13:03:44 the IP dst addresses become sequential and incrementalPort sweepAlso notice that most systems did not respond
14 The dmz victim continued Which system did respond?Search records for packets sent from target system back to port scanner greater then zero
15 A change in behaviorAt :03:49, began sending SYN packets only to a range of ports on the two system that respondedPort scan
16 Open ports Sort and count the dst ports targeted Exactly 1000 ports numbers – NmapWhich ports were open?Filter for TCP SYN/ACK packets
17 Next step From 13:04:09 through 13:04:14 sends TCP SYN packets to sequential IP addresses on /24 port 3389Targeted port sweepMicrosoft’s Remote Control Desktop ProtocolWho responded?
18 Port 3389 Series of flows from the DMZ 10.30.30.20 to 192.168.30.101 Port 3389 (RDP)Spans 11 minutesRemember that during the same time frame there was also an SSH connection(external) and (DMZ victim)
19 The internal victim –Filter traffic relating toInternal port scanning trafficPort 3389 connectionDirect connection from to on TCP port 21 (FTP)
20 File transfer Protocol (FTP) Filter for FTP-related trafficDefault ports TCP 20/21Notice the 16,874 bytes of exported data from (an internal system) to the external attacker
21 Back to the Cisco ASA flow Lets corroborate our evidenceRemember:is NAT-ed =8 second time skewNotice the Layer 4 payload size is smaller then the Argus reportedTransfer included lower-layer frame and packet headers
22 timeline Notes: April 27, 2011 Times are adjusted to match Argus Educated guess based on evidence12:49:33—Flow captures begin.12:51:54—Port scanning begins from (attacker) against (DMZ victim). The attacker likely found that port 22 (TCP) was open on the DMZ victim system.12:52:38— begins likely brute-force password-guessing attack against an SSH server on DMZ victim13:00:45— ends likely brute-force password-guessing attack13:01:08— begins extended connection to SSH port on DMZ victim13:03:31—DMZ victim begins port sweep of internal and DMZ networks on TCP ports 80 and Two systems on the internal network responded: and13:03:49—DMZ victim ends port sweep of internal and DMZ networks on TCP ports 80 and 443
23 Timeline continued13:03:49—DMZ victim begins port scan of and ,000 ports were targeted. The attacker found :22 (TCP), :22 (TCP), and :514 (TCP) open.13:03:50—DMZ victim ends port scan of and13:04:09—DMZ victim begins port sweep of internal network, /24, on port Three systems on the /24 network appeared to have TCP port 3389 open: , , and13:04:14—DMZ victim ends port sweep of internal network targeting port 3389.13:04:32—DMZ victim begins a series of connections to on port 3389 (TCP). This port is commonly associated with RDP, a remote connection protocol commonly used on Microsoft Windows systems.13:05:33— begins outbound connections on port 21/TCP (FTP) to the attacker,13:07:03— conducts a particularly large outbound data transfer to , with a likely file size of 15,872 bytes.13:15:55—Last flow record from to DMZ victim (port 22/TCP). Connection still active.13:15:55—Last flow record from DMZ victim to (port 3389/TCP). Connection still active.13:16:09—Flow captures end.PG 195
24 Theory of the caseThe attacker ( ) conducted a port scan of the DMZ victim ( ).The attacker found that TCP port 22 (SSH) was exposed on the targeted DMZ victimThe attacker ( ) conducted a brute-force password-guessing SSH attack on the DMZ victim, ( ). After approximately 8 minutes, this attack was successful.The attacker logged into the DMZ victim ( ) using SSH and conducted a port scan of the internal network.Two systems, and , were responsive and had port 22/TCP open.
25 Theory continuedFrom the DMZ victim ( ), the attacker also conducted a port sweep of the internal network for open port 3389 (RDP).Three systems had port 3389 open: , , andThe attacker, pivoting through the DMZ victim ( ), logged into via RDP.On ( ), the attacker used FTP to connect outbound toThe attacker transferred a file from the internal system ( ) to the attacker’s system,
26 Response to challenge questions Identify any compromised systemsThe DMZ,Using brute-force ssh password-guessing attackAn internal system,RDP connection was madeNo apparent attack on the password
27 Response 2Determine what the attacker found out about the network architectureBased on port scanning activityFirewall rules allow TCP port 22 connections to the DMZThe ANFRF has at least two subnets/24 and /24DMZ has access to internal systems for TCP ports 22, 80, 443, 514 and 3389FTP traffic is allowed outbound from internal network
28 Response 3 Evaluate the risk of data exfiltration HIGH Flow records strongly indicate that an external FTP connection was made and a significant amount of data was transfered
29 Next step Containment/Eradication Change passwords Rebuild the compromised systemsTighten firewall rulesBlock outbound TCP connections on ports 20/21Restrict access to external SSHConsider using two-factor authentication
30 Additional evidence sources Central Logging ServerFirewall logsHDD of compromised systems
31 Disclaimer: All information and data pulled directly from this book. PagesWorks CitedDavidoff, S., & Ham, J. (2012). Network Forensics Tracking Hackers Through Cyberspace. Boston: Prentice Hall.
Your consent to our cookies if you continue to use this website.