Malware Traffic Analysis 3
Malware Traffic Analyses are a set of CTF challenges for analysing traffic and an excellent way of developing threat hunting using tools like Wireshark and Suricata. Here we do their third CTF challenge, analysing a PCAP from an infected machine. This can be downloaded from the Cyber Defenders page here.
What is the IP address of the Windows VM that gets infected?
To make the analysis more readable in Wireshark, I added columns Source Port, Destination Port and Host.
There are many ways to determine this; either by looking at the populous amounts of packets within endpoint statistics within wireshark and sorting by packets:
Or by seeing the endpoint DNS and DNS server which is queried to determine the endpoint IP from which the PCAPs were captured:
In both cases this is 192.168.137.62, but this doesn’t determine if the VM is infected. Alternatively using Brim and leveraging Suricata Alerts, we can determine the endpoints which have malicious traffic reaching them; in our case it is 192.168.137.62.
Alternatively, you could see that the question says ‘Windows VM’, go to Network Miner and from there search for hosts which are Windows Virtual Machines, where you’ll find the only one:
What is the Exploit kit (EK) name? (two words)
This can be seen using PacketTotal. Uploading the PCAP file, we can then have a look at the Alert Signatures within the Malicious Activity tab:
What is the FQDN that delivered the exploit kit?
If we look at the Exploit Kit detection in the above picture or from the Suricuta Detection in Q1, we can see that the IP associated is 22.214.171.124. We can then search for HTTP requests in Wireshark:
Here we see the host. Alternatively, you can see it in Network Miner under Hosts where it will automatically show the FQDN:
What is the redirect URL that points to the exploit kit landing page?
If we follow the HTTP stream one of the HTTP handshakes between 126.96.36.199 and 192.168.137.62, we can see the referrer parameter:
What is the FQDN of the compromised website?
For this one, if we look at the Statistics > HTTP Requests, we can sort by count and see that the top count is www.earsurgery.org
Which TCP stream shows the malware payload being delivered? Provide stream number
For this question, we must first determine which file was malicious delivered by qwe.mvdunalterableairreport.net. In order to do this, we must first export HTTP objects and download all the ones associated with the host:
After this, we can verify which ones are malicious in VirusTotal; there you will see four of the files are malicious. The one you’re intersted in is 680VBFhpBNBJOYXebSxgwLrtbh3g6JFUllqksWFSsGshhwsguyNL26MGul2oZ3b8
From validating this click on the packet where this has been downloaded back in HTTP objects — this will select the packet. Then follow TCP stream to find the number:
What is the IP address of the C&C server?
If we look at the list of Suricata detections from Brim:
If we look closer in PacketSniffer, we can see the reason is a SSL cert:
From here we can determine with the format of ***.***.**.** the likely IP is 188.8.131.52, given this is a Network Trojan.
Furthermore, if we look at suspicious activity within PacketSniffer, we can see that there is a self-signed certificate:
These are normally done in an attempt to sniff TLS/SSL traffic.
What is the expiration date of the SSL certificate?
For this one, if we look at the malicious activity alert and filter by the above IP, we see that it was at 04/12/2014 at two timestamps.
If we then navigate to SSL certificates and filter by the above IP, we get a list of certificates which can be downloaded.
If we download these and change them from .raw files to .cer, we can then open the file to get certificate information:
Here we see the expiration date is 24/11/2024, both certificates have the same expiration.
Question doesn’t exist so onto question 10….
The malicious domain served a ZIP archive. What is the name of the DLL file included in this archive?
If we look in Brim, we can find zip files associated with Ips with the following command:
Next, let’s go into VirusTotal and search by the MD5 hash.
Here you’ll see it’s a bundled zip file with a DLL file:
Alternatively, you can inspect in Packet Total and search for zips in transferred files:
Here you can download the zip, unzip it and find the DLL name.
Extract the malware payload, deobfuscate it, and remove the shellcode at the beginning. This should give you the actual payload (a DLL file) used for the infection. What’s the MD5 hash of the payload?
Based on the detection timeframe of the Angler Payload from the previous question, being at 18:27:30, we can actually determine which file is the specific malware payload which is being referred here.
We can also do this by downloading all of the files associated with qwe.mvdunalterableairreport.net again and uploading them to VirusTotal, either way the file is the Octet Stream file with name 680VBFhpBNBJOYXebSxgwLrtbh3g6JFUllqksWFSsGshhwsguyNL26MGul2oZ3b8.
If we open this in HxD Hex Editor we notice that the strings that repeat themselves are adR2b4nh.
If we then search for this online with Angler EK we see that it is a XOR string with key adR2b4nh. From looking here, we see that XOR ciphers can be decrypted by simply applying the XOR cipher again with the given key to remove the cipher.
If we then XOR it within CyberChef and save the file, we can then extract the file using binwalk. Switching to Kali here, we can see all the files contained in this file:
I then proceed to extract them:
As you can see the PE is called 591:
Uploading this file now back into VT, we see we have the overview that this is a DLL file and the MD5 hash is listed below:
What were the two protection methods enabled during the compilation of the PE file? (comma-separated)
If we navigate to PE Explorer to analyse our DLL from the previous question, there is a tab called Optional Header which provides information on the types of protection methods. I’ve explained what they all mean in the previous Malware Traffic Analysis challenge on my blog also.
SEH was in the previous CTF, with image isolation this time, known as Canary.
When was the DLL file compiled?
Going back to VT on details for the DLL, we can see that the compilation timestamp is below:
A Flash file was used in conjunction with the redirect URL. What URL was used to retrieve this flash file?
This one is pretty easy, open up export HTTP objects in Wireshark and look for flashfiles:
Click on the packet then open it to find the request URI from the HTTP request:
What is the CVE of the exploited vulnerability?
From the previous google of Angler EK adR2b4nh would land you on the Malware-Traffic-Analysis.net site where you’ll find the CVE:
What was the web browser version used by the infected host?
If we follow the TCP stream of infected VM seen above, 192.168.137.62, we get the user agents; Mozilla version 5 and MSIE version 9.
What is the DNS query that had the highest RTT?
To identify long RTT in Wireshark, ensure the Time column in Wireshark is configured to display the time since the previous displayed packet. Select View > Time Display Format > Seconds Since Previous Displayed Packet.
From here I filtered by DNS and followed this:
The answer should be dsms0mj1bbhn4.cloudfront.net but it is instead ssl.gstatic.com
What the name of the SSL certificate issuer that appeared the most? (one word)
This one was super easy, for this I used NetworkMiner, searched by .cer files and as you can see the majority were from Google.
And that wraps this up. As always, stay safe!