Presentation on theme: "Section 4.2 Network Forensics TRACKING HACKERS THROUGH CYBERSPACE CASE STUDY : THE CURIOUS MR. X."— Presentation transcript:
Section 4.2 Network Forensics TRACKING HACKERS THROUGH CYBERSPACE CASE STUDY : THE CURIOUS MR. X
THE MISSION The 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 systems Determine what the attacker found out about the network architecture Evaluate the risk of data exfiltration Since 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.
THE MISSION CONTINUED Network: The Arctic Nuclear Fusion Research Facility network consists of three segments: Internal network: /24 DMZ: /24 The “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.
IMPORTANT NOTES As 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).
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
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 response Notice port 22
EXTERNAL ATTACKER & PORT 22 Is there more port 22 traffic relating to the attacker? Use nfdump to filter Notice the series of connection attempts Byte size 3755 Roughly every six seconds What does it mean? Port 22 = ssh Common target for brute-force Process is commonly automated Regular intervals Same small amount of data Notice the byte change at :00: followed by a quick connection At :01: a flow was created: (attacker) – (target).
HYPOTHESIS SO FAR Flow records indicate: Automated brute-force password-guessing attack on an SSH server Target: Attack lasted about 8 minutes Result: Most likely successful Information used in hypothesis Timing Port number Data transfer size
INTERNAL ARGUS FLOW RECORDS Lets search for traffic relating to attack Remember internal NATed address = external Also remember the 8 second time skew Correlating evidence Helpful info: Use the ra man page to identify state changes
PORT 22 Attacker initiated a connection three times Sent TCP SYN, received SYN ACK, sent RST Connection was aborted by attacker before TCP handshake was complete Matches behavior of port scanner testing Attacker now knows port 22 is open Next we see several short connections every six seconds Sent TCP SYN, received SYN ACK, handshake established, sent FIN, received FIN Successful Layer 4 TCP communication
PORT 22 CONTINUED For more than 15 minutes the connection and subsequent data transfers continue
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
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 connection Over a minute later we see a different connection, indicates a manual connection Now /80 is communicating to external /80 Notice 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 incremental Port sweep Also notice that most systems did not respond
THE DMZ VICTIM CONTINUED Which system did respond? Search records for packets sent from target system back to port scanner greater then zero
A CHANGE IN BEHAVIOR At :03:49, began sending SYN packets only to a range of ports on the two system that responded Port scan
OPEN PORTS Sort and count the dst ports targeted Exactly 1000 ports numbers – Nmap Which ports were open? Filter for TCP SYN/ACK packets
NEXT STEP From 13:04:09 through 13:04: sends TCP SYN packets to sequential IP addresses on /24 port 3389 Targeted port sweep Microsoft’s Remote Control Desktop Protocol Who responded?
PORT 3389 Series of flows from the DMZ to Port 3389 (RDP) Spans 11 minutes Remember that during the same time frame there was also an SSH connection (external) and (DMZ victim)
THE INTERNAL VICTIM – Filter traffic relating to Internal port scanning traffic Port 3389 connection Direct connection from to on TCP port 21 (FTP)
FILE TRANSFER PROTOCOL (FTP) Filter for FTP-related traffic Default ports TCP 20/21 Notice the 16,874 bytes of exported data from (an internal system) to the external attacker
BACK TO THE CISCO ASA FLOW Lets corroborate our evidence Remember: is NAT-ed = second time skew Notice the Layer 4 payload size is smaller then the Argus reported Transfer included lower-layer frame and packet headers
TIMELINE Notes: April 27, 2011 Times are adjusted to match Argus Educated guess based on evidence 12: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 victim 13:00:45— ends likely brute-force password-guessing attack 13:01:08— begins extended connection to SSH port on DMZ victim 13:03:31—DMZ victim begins port sweep of internal and DMZ networks on TCP ports 80 and 443. Two systems on the internal network responded: and :03:49—DMZ victim ends port sweep of internal and DMZ networks on TCP ports 80 and 443
TIMELINE CONTINUED 13: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 and :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: , , and :04:14—DMZ victim ends port sweep of internal network targeting port :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, :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
THEORY OF THE CASE The attacker ( ) conducted a port scan of the DMZ victim ( ). The attacker found that TCP port 22 (SSH) was exposed on the targeted DMZ victim The 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.
THEORY CONTINUED From 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: , , and The attacker, pivoting through the DMZ victim ( ), logged into via RDP. On ( ), the attacker used FTP to connect outbound to The attacker transferred a file from the internal system ( ) to the attacker’s system,
RESPONSE TO CHALLENGE QUESTIONS Identify any compromised systems The DMZ, Using brute-force ssh password-guessing attack An internal system, RDP connection was made No apparent attack on the password
RESPONSE 2 Determine what the attacker found out about the network architecture Based on port scanning activity Firewall rules allow TCP port 22 connections to the DMZ The ANFRF has at least two subnets /24 and /24 DMZ has access to internal systems for TCP ports 22, 80, 443, 514 and 3389 FTP traffic is allowed outbound from internal network
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
NEXT STEP Containment/Eradication Change passwords Rebuild the compromised systems Tighten firewall rules Block outbound TCP connections on ports 20/21 Restrict access to external SSH Consider using two-factor authentication
ADDITIONAL EVIDENCE SOURCES Central Logging Server Firewall logs HDD of compromised systems
Works Cited Davidoff, S., & Ham, J. (2012). Network Forensics Tracking Hackers Through Cyberspace. Boston: Prentice Hall. Disclaimer: All information and data pulled directly from this book. Pages