How To Create An Attack Timeline: Hancitor Malware Part 2
Updated: Aug 24
In Part 1 of this blog series, we analyzed TCP network traffic exchanged between a compromised Windows machine and several malicious destinations and began building an attack timeline following the Mandiant's Attack Lifecycle.
The last part of this blog series aims to complete the attack timeline, develop a list of indicators of compromise to establish attribution, and answer the questions posed at the start of the investigation:
The attack vector leading to initial system access
The malware variant resulting in the system's infection
The post-compromise actions taken by the attackers
We will continue analyzing the network packet capture file obtained from www.malware-traffic-analysis.net (here), focusing on the DNS exchanges between the victim machine and a DNS server.
The TCP traffic analysis performed in Part 1 of this blog series produced findings indicative of possible malware infection of a Windows machine, resulting in command and control. The suspected victim machine downloaded and presumably installed three unusual files (two .bin and one .exe) from 18.104.22.168, immediately after connecting and sending some data (via HTTP POST) to a PHP website or script hosted on 22.214.171.124. The machine then established a presumed command and control channel to 126.96.36.199 over TCP 8080. Our attack timeline up to this point includes the following:
UDP Analysis: Initial Access
After exhausting the TCP network traffic analysis, we focused on the UDP connections, particularly DNS exchanges between our suspected victim machine and an internal DNS server. We observed the actions that led to the alleged victim machine establishing a C&C channel by filtering the timeline (TS) column for values less than or equal to 1612800013 and sorting the TS column in descending order.
We observed a DNS request (DNS request ID 65148 on column G) from the suspected victim machine at timestamp 1612800011 and again at 1612800012 for an interesting domain named roanokemortgages[.]com, followed by the DNS server responding to the request with 188.8.131.52, the IP address from where the victim machine downloaded the three unusual files.
Our attack timeline now includes the following:
We then searched for the other two potentially malicious IP addresses found in the TCP traffic analysis by applying a filter on column J for values equal to 184.108.40.206 or 220.127.116.11, resulting on a single match for 18.104.22.168 with DNS request ID 40446.
We then proceeded to look for values matching the DNS request ID 40446 in column G, resulting in several DNS requests for a domain named satursed[.]com, the first one at timestamp 1612800007.
Our updated attack timeline now looks like this:
With all the information we have collected so far, we can begin building our list of indicators of compromise to help attribute this attack. The list of indicators of compromise includes IP addresses, domains, and files, as follows:
We next observed the actions that led to the first DNS request at timestamp 1612800007 for the suspected malicious satursed[.]com by filtering the timeline (TS) column for values less than or equal to 1612800007. We noticed that the alleged victim machine sent a DNS request for login.microsoftonline.com at 1612800002, which could indicate that the individual using the machine at the time of infection:
Accessed a Microsoft email account, or
Accessed a Microsoft application, such as Microsoft Word online
At this point, we suspected that initial access had been through a phishing email.
Our attack timeline now included the initial access:
Scrolling down the UDP file, we noticed another unusual DNS request at timestamp 1612799952 for tonmatdoaminh[.]com, resolving to 45.124.85[.]55.
We switched back to the TCP network traffic file and filtered the destination IP column for values matching 45.124.85[.]55, resulting in the first connection to 45.124.85[.]55 recorded at timestamp 1612799952. We also observed two HTTP GET requests for 45.124.85[.]55/ uninviting.php recorded at 1612799952 and 1612799953.
Our updated attack timeline now includes the following:
Our updated list of indicators of compromise now includes the newest findings:
UDP Analysis: Command and Control
The next step in the analysis included observing the actions that followed command and control. The suspected victim machine established the first presumed C&C channel to 22.214.171.124 over TCP 8080 at timestamp 1612800013. We switched back to the UDP network traffic file and filtered the timestamp column (TS) for values greater than or equal to 1612800013. We also filtered column H for values matching requests for DNS A records only (A?).
Starting at TS 1612800014, we noticed a DNS request (ID 60462) for another unusual domain, sweyblidian[.]com.
We then filtered column G for values matching the DNS request ID for sweyblidian.com, 60462, revealing IP address 185.100.65[.]29.
Our updated attack timeline and IoC list now include the following:
TCP Analysis: Complete Mission
We then switched back to the TCP network traffic file to learn more about 185.100.65[.]29. We filtered the destination IP address column (dst.ip) for values matching 185.100.65[.]29 and summarized all unique connections by searching for TCP SYNs in the TCP.FLAGS column. The result included two separate TCP connections from our suspected victim machine to 185.100.65[.]29 at 1612800017 and 1612800021.
We suspected that sweyblidian.com was used as an exfiltration destination following C&C. We analyzed the packet sizes for connections to sweyblidian.com (185.100.65[.]29) and noticed that most of these were 1,460 bytes, which is the maximum packet size for TCP connections. It is hard to tell without additional information, but this could be indicative of data exfiltration.
Our completed attack timeline now looks like this:
Threat Intelligence Completes the Analysis
By now, we had enough information to answer two of the questions posed at the beginning of the blog, including the attack vector and post-compromise actions. However, we were still unable to attribute the attack to a particular campaign or threat actor group.
Our next step consisted in using Gigasheet's enrichment capabilities through VirusTotal's API. We switched to the TCP network traffic file and enriched the destination IP address column (dst.ip).
We observed that VirusTotal returned a match for several IP addresses. We then browsed to VirusTotal and searched for one of the suspected malicious domains, roanoakemorgages.com, revealing an interesting Pastebin site.
Within the Pastebin site, we found many IoCs we had collected during our investigation.
With this information, we were now able to answer the following questions:
What was the attack vector?
Microsoft Office file with malicious macros delivered via email
Can this attack be attributed to any group or malware?
Hancitor malware, AKA Chanitor
What happened after the machine was infected?
We cannot confirm the type of data exfiltrated during the attack, but based on FireEye’s report, different versions of Hancitor malware were designed to steal credentials and autocomplete Intelliforms data