How To Create An Attack Timeline: Hancitor Malware Part 1

In this two-part blog series we'll demonstrate how to establish an attack timeline of some older Hancitor Malware, which has recently been updated to leverage Cobalt Strike. We'll show you how to perform forensic analysis of network traffic exchanged between a compromised Windows machine and several malicious destinations, and produce a list of indicators of compromise (IoC) that will help to establish attribution. If you don't have a Gigasheet account, you can sign up here.

The network traffic analyzed in this blog was obtained from a data analysis exercise posted on www.malware-traffic-analysis.net and included a packet capture (PCAP) file and an associated alerts file generated by Security Onion. While the author of the malware-traffic-analysis.net exercise proposes using both files to identify the incident's root cause, we only used the PCAP file to illustrate that, with the right tool (ahem Gigasheet), one can arrive at a defensible conclusion even in the absence of relevant security alerts.

To set a structure around analysis, we mapped the attack timeline to Mandiant's Attack Lifecycle stages. By the end of this blog series, we will establish:

1. The attack vector leading to initial system access
2. The malware variant resulting in the system's infection
3. The post-compromise actions taken by the attackers

Data Preparation

We began the analysis by reading the PCAP file with tcpdump, splitting TCP from UDP traffic using tcpdump filters, and saving each protocol into separate text files. We then used a text editor to convert each text file into CSV by finding and replacing spaces with commas. We ended up with two files, which we uploaded to Gigasheet:

• File 1: tcptraffic.csv, containing TCP connections
• File 2: udptraffic.csv, including UDP connections

TCP Analysis: Traffic Composition

Knowing where to start looking could be challenging if you don't have indicators of compromise, such as a timestamp or IP address, to guide the analysis. It usually helps to start by understanding the general traffic composition, such as the number of connections, unique IP addresses, ports, and protocols, and observe any evident issues or patterns that could help steer the investigation.

We first identified all the unique TCP connections by filtering the TCP.FLAGS column for values containing SYN flags, or [S], and grouping by source IP address (SRC.IP column), resulting in 545 unique TCP sessions initiated by a single machine with IP address 10.2.8.101. This machine became our suspected victim and the center of our investigation.

Next, we grouped the file by destination port (DST.PORT column) to identify all unique ports, resulting in 9 different values, of which 8080, 443, 80 had the highest number of hits.

Lastly, we grouped the file by destination IP address (DST.IP column) to summarize the destinations, resulting in 35 unique destination IP addresses, 2 of which were internal, including 10.2.8.1 and 10.2.8.2.

Next, we filtered out any connections containing IP addresses 10.2.8.1 or 10.2.8.2 from the source or destination IP address columns because we had already determined that only one machine (10.2.8.101) initiated TCP connections, making 10.2.8.1 and .2 irrelevant at this stage of the analysis.

TCP Analysis: Compromise & Command and Control

We then proceeded to analyze traffic over port 80 to try to discover how the machine became infected. We determined that most (if not all) of the traffic over port 80 was HTTP because the values in columns U and V included the HTTP request methods (e.g., GET, POST) and the requested URL. Filtering column U for values equal to GET returned all HTTP GET requests originating from the suspected victim machine, resulting in HTTP GET requests sent from our suspected victim over ports 80 and 8080.

Next, we grouped the file by URL (column V), expanded port group 80, and quickly observed three unusual files requested by the suspected victim machine from the same destination, 8.208.10.147, including:

• /0801.bin
• /0801s.bin
• /6lhjgfdghj.exe

After finding the first unusual activity, we began building the attack timeline:

We then analyzed port group 8080 and discovered two unique URLs, one of which was requested 251 times:

• /ca
• /6Aov

We expanded the first URL group (/ca) and observed the first HTTP GET request for /ca immediately after the machine had downloaded and presumably installed the .exe and .bin files.

We then grouped by destination IP address to identify all destinations that the suspected victim machine communicated with over port 8080, resulting on a single destination IP address, 192.211.20.238. We also observed that all HTTP GET request for 192.211.20.238/ca were 390 bytes, indicating a possible command and control channel.

Let’s review our timeline of attack so far:

So far, we know that a possible command and control channel was established between the suspected victim machine and 198.211.10.238, following the presumable installation of three unusual files from 8.208.10.147. However, we still do not know when, why, or how those three files were dropped on the machine.

To discover when the suspected victim machine initiated the TCP connection to 8.208.10.147, we filtered the destination IP address column (dst.ip) for values equal to 8.208.10.147 and the TCP.FLAGS column for values equal to [S] (or TCP SYN).

We observed that the connection to 8.208.10.147 was initiated at TS 1612800012, before the machine downloaded the three unusual files. Our attack timeline now looked like this:

We then returned to the presumed TCP 8080 command and control traffic to identify the first connection to 198.211.10.238 (suspected C&C server). Similarly, we filtered the destination IP address column (dst.ip) for values equal to 198.211.10.238 and the TCP.FLAGS column for values equal to [S] (or TCP SYN), resulting in the first C&C connection established at TS 1612800013.

Our updated timeline now looked like this:

TCP Analysis: Initial Access

Next, we attempted to discover the actions leading to the machine infection and C&C. We went back to the beginning of the capture before the suspected victim machine downloaded the three unusual files from 8.208.10.147 (or TS 1612800012). We applied a filter to the timestamp (TS) column to display all connections before TS 1612800012 originating from our suspected victim machine, 10.2.8.101.

We observed that right before the suspected victim machine connected to 8.208.10.147, it communicated with 52.170.57.27 over 443. Unfortunately, traffic over port 443 appeared to be TLS and did not provide much information.

We then analyzed HTTP traffic before the suspected victim machine downloaded the three unusual files. We filtered the destination port column (dst.port) for values equal to 80 or 8080 to display all HTTP connections.

Right before its compromise (TS 1612800012), we observed that the suspected machine connected to many IP addresses over port 80.  

We then grouped the connections by HTTP request type (column U), resulting in one POST to 213.5.229.12/8/forum.php established at TS 1612800011.

Our timeline of attack now looked like this:

Conclusion

The network traffic analysis produced findings indicative of possible malware infection of a Windows machine, resulting in command and control. We know so far that the suspected victim machine downloaded and presumably installed three unusual files (two .bin and one .exe) from 8.208.10.147, immediately after connecting and posting some data to a PHP website or script on 213.5.229.12. The machine then established a presumed command and control channel to 198.211.10.238 over TCP 8080.

Stay tuned for Part 2 of this blog, where we conclude the analysis and answer the three questions posed at the beginning of the investigation.

‍