Case study : The curious mr. x Section 4.2 Network Forensics TRACKING HACKERS THROUGH CYBERSPACE

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, 172.30.1.77, beginning at 2011-04-27 12: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: 192.168.30.0/24 DMZ: 10.30.30.0/24 The “Internet”: 172.30.1.0/24 [Note that for the purposes of this case study, we are treating the 172.30.1.0/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-1.5.8-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 (192.168.30.0/24 and 10.30.30.0/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 10.30.30.20 translates to the external address 172.30.1.231, and the internal IP address 192.168.30.101 translates to the external address 172.30.1.227. 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 – 170.30.1.77 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 2011-04-27 13:00:41.962 followed by a quick connection At 2011-04-27 13:01:00.133 a flow was created: 170.30.1.77 (attacker) – 172.30.1.231 (target).

Hypothesis so far Flow records indicate: Automated brute-force password-guessing attack on an SSH server Target: 172.30.1.231 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 10.30.30.20 = external 172.30.1.231 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 (172.30.1.77) to a victim server in the DMZ (10.30.30.20) 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 – 10.30.30.20 (aka 172.30.1.213) First noticeable difference in SSH connection from 172.30.1.77 to 10.30.30.20 04-27-11 13: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 10.30.30.20/80 is communicating to external 91.189.92.166/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 04-27-11 13:03:49, 10.30.30.20 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:14 10.30.30.20 sends TCP SYN packets to sequential IP addresses on 192.168.30.1/24 port 3389 Targeted port sweep Microsoft’s Remote Control Desktop Protocol Who responded?

Port 3389 Series of flows from the DMZ 10.30.30.20 to 192.168.30.101 Port 3389 (RDP) Spans 11 minutes Remember that during the same time frame there was also an SSH connection 172.30.1.77 (external) and 10.30.30.20 (DMZ victim)

The internal victim – 192.30.1.101 Filter traffic relating to 192.168.30.101 Internal port scanning traffic Port 3389 connection Direct connection from 192.168.30.101 to 172.30.1.77 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 192.168.30.101 (an internal system) to the external attacker

Back to the Cisco ASA flow Lets corroborate our evidence Remember: 192.168.30.101 is NAT-ed = 172.30.1.227 8 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 172.30.1.77 (attacker) against 172.30.1.231 (DMZ victim). The attacker likely found that port 22 (TCP) was open on the DMZ victim system. 12:52:38—172.30.1.77 begins likely brute-force password-guessing attack against an SSH server on DMZ victim 13:00:45—172.30.1.77 ends likely brute-force password-guessing attack 13:01:08—172.30.1.77 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: 192.168.30.30 and 192.168.30.90 13: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 192.168.30.30 and 192.168.30.90. 1,000 ports were targeted. The attacker found 192.168.30.90:22 (TCP), 192.168.30.30:22 (TCP), and 192.168.30.30:514 (TCP) open. 13:03:50—DMZ victim ends port scan of 192.168.30.30 and 192.168.30.90. 13:04:09—DMZ victim begins port sweep of internal network, 192.168.30.0/24, on port 3389. Three systems on the 192.168.30.0/24 network appeared to have TCP port 3389 open: 192.168.30.100, 192.168.30.101, and 192.168.30.102. 13:04:14—DMZ victim ends port sweep of internal network targeting port 3389. 13:04:32—DMZ victim begins a series of connections to 192.168.30.101 on port 3389 (TCP). This port is commonly associated with RDP, a remote connection protocol commonly used on Microsoft Windows systems. 13:05:33—192.168.30.101 begins outbound connections on port 21/TCP (FTP) to the attacker, 172.30.1.77. 13:07:03—192.168.30.101 conducts a particularly large outbound data transfer to 172.30.1.77, with a likely file size of 15,872 bytes. 13:15:55—Last flow record from 172.30.1.77 to DMZ victim (port 22/TCP). Connection still active. 13:15:55—Last flow record from DMZ victim to 192.168.30.101 (port 3389/TCP). Connection still active. 13:16:09—Flow captures end. PG 195

Theory of the case The attacker (172.30.1.77) conducted a port scan of the DMZ victim 172.30.1.231 (10.30.30.20). The attacker found that TCP port 22 (SSH) was exposed on the targeted DMZ victim 172.30.1.231. The attacker (172.30.1.77) conducted a brute-force password-guessing SSH attack on the DMZ victim, 172.30.1.231 (10.30.30.20). After approximately 8 minutes, this attack was successful. The attacker logged into the DMZ victim 172.30.1.231 (10.30.30.20) using SSH and conducted a port scan of the internal network. Two systems, 192.168.30.30 and 192.168.30.90, were responsive and had port 22/TCP open.

Theory continued From the DMZ victim 172.30.1.231 (10.30.30.20), the attacker also conducted a port sweep of the internal network for open port 3389 (RDP). Three systems had port 3389 open: 192.168.30.100, 192.168.30.101, and 92.168.30.102. The attacker, pivoting through the DMZ victim 172.30.1.231 (10.30.30.20), logged into 192.168.30.101 via RDP. On 192.168.30.101 (172.30.1.227), the attacker used FTP to connect outbound to 172.30.1.77. The attacker transferred a file from the internal system 192.168.30.101 (172.30.1.227) to the attacker’s system, 172.30.1.77.

Response to challenge questions Identify any compromised systems The DMZ, 10.30.30.20 Using brute-force ssh password-guessing attack An internal system, 192.168.30.101 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 10.30.30.0/24 and 192.168.30.0/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

Disclaimer: All information and data pulled directly from this book. Pages 184 - 196 Works Cited Davidoff, S., & Ham, J. (2012). Network Forensics Tracking Hackers Through Cyberspace. Boston: Prentice Hall.