Malware Traffic Analysis Exercise | Burnincandle | IcedID Malware
Welcome! Today I will be going over another malware traffic analysis exercise from https://www.malware-traffic-analysis.net/ which I recently completed. This one is called Burnincandle. This post will include an executive summary, details of the infected host, indicators of compromise (IOC’s), and a technical summary where I will explain how I did my analysis and what indicators I based my conclusions off of.
Executive Summary
At approximately 2058 UTC on 21 March 2022, a Windows host used by “patrick.zimmerman” was infected with IcedID malware. After initial infection, a cobalt strike command and control (C2) beacon was established on the victim.
Infected Host Details
- IP address: 10.0.19.14
- MAC address: 00:60:52:b7:33:0f
- Hostname: DESKTOP-5QS3D5D
- Username: patrick.zimmerman
Indicators of Compromise (IOC’s)
Network traffic associated with initial IcedID infection:
- HTTP GET request — 188.166.154.118:80 — oceriesfornot.top
- HTTPS traffic — 157.245.142.66:443 — antnosience.com, otectagain.top
- HTTPS traffic — 91.193.16.181:443 — seaskysafe.com, dilimoretast.com
- HTTPS traffic — 160.153.32.99:443 — suncoastpinball.com
Network traffic associated with file sharing:
- HTTPS traffic — 185.47.40.36:443 — filebin.net
- HTTPS traffic — 87.238.33.7:443, 87.238.33.8:443 — situla.bitbit.net
Network traffic associated with cobalt strike command and control (C2):
- HTTPS traffic — 23.227.198.203:757 — bupdater.com
Technical Analysis
The very first thing I do when completing these exercises is look at the suricata IDS/IPS alerts in my security onion console in order to get an idea of what I’m dealing with, as well as decide how I want to direct my analysis.
Based on the alerts present, I’m hypothesizing that the first two alerts “ET MALWARE Win32/IcedID Request Cookie”, and “ET INFO HTTP Request to a *.top domain” are probably alerting on the same HTTP request. This is based on the fact that both of them only alerted once. Since we’re talking about an “IcedID request cookie”, the victim is probably only going to make one HTTP GET request to the malicious domain where the IcedID malware is originating from, hence the single instance for both alerts. But lets not spend too much time on theoreticals.
Digging into the IcedID request cookie alert, I see an HTTP GET request with some odd looking data in the cookie parameter.
I did some research to learn more about this, and came across an article (https://sysopfb.github.io/malware,/icedid/2020/04/28/IcedIDs-updated-photoloader.html), which describes the meaning of each value within the cookie parameter. In short, this cookie is used to store encoded data about the victim host, including the hostname, username, windows version, etc. So I had clear evidence now that the threat actor was able to enumerate some information about the victim host, but I also found the first IOC, as the oceriesfornot.top domain and IP are identified as being malicious.
I also confirmed that my suspicions of the “IcedID request cookie” alert and the “HTTP request to *.top domain” alert were both triggered from the same traffic, the GET request sent to oceriesfornot.top.
Immediately following the “IcedID request cookie” alert, the victim IP is observed establishing an HTTPS connection with the domain antnosience.com at IP address 157.245.142.66, which is also identified as being malicious in virustotal. This gives me my second IOC.
At this point, I decided that I needed to pivot off and open up networkminer to see if any interesting file information can be extracted from the pcap.
Networkminer turned my attention to a file called “index.gzip”. The gzip suffix indicates that the file is compressed using the gzip tool. Compressing malicious documents is a common tactic used by attackers in an attempt to avoid detection by AV, IDS, IPS, etc., so this seemed interesting to me. Now that I had this information, I went into wireshark and found the TCP stream where the index.gzip file was sent over the network. In TCP stream 0, I found that the original, uncompressed file’s name is Copper.txt. At least that’s what I thought…
Now that I had found this gzip file, I did some research relating to IcedID and gzip files. Very quickly, I realized that there was far more to this infection than I had realized at this point. Essentially, the “Copper.txt” string is just a facade. In fact, there isn’t really a file here at all, all of this data is basically just encrypted IcedID configuration. Once decrypted, the malware drops a file named license.dat into a folder specified by the malware configuration, within the current user’s Appdata\Roaming directory. It also drops the IcedID main loader into the Appdata\Local\ directory. This main loader is then used to load the IcedID payload (inside license.dat) into memory and run it. You can read much more about how this all works in this article from binarydefense.com (https://www.binarydefense.com/icedid-gziploader-analysis/).
Now that I had essentially nailed down the source of the infection, I needed to turn my attention back towards generating IOC’s. Looking back in wireshark, I noticed that there was a large number of TLS handshakes occurring between the victim IP and external IP’s, and that the source port numbers from the victim IP were being rotated through very quickly. Making so many new connections in such short timespans is definitely unusual. I also remembered seeing an IDS/IPS alert for “OpenSSL Demo CA — Internet Widgits Pty”, indicating that some type of weirdness was happening with SSL/TLS certificates generated by OpenSSL. This alert is triggered because these Internet Widgits TLS certificates are self-signed and should not be trusted.
From here, I filtered for these Internet Widgits TLS certificates in networkminer to find the rest of the malicious IP’s and domains associated with this IcedID malware infection.
The victim IP was also observed making multiple odd new TLS connections with the suncoastpinball.com domain at 160.153.32.99:443, giving me another IOC. This domain’s SSL certificate is not self-signed however, it’s a godaddy certificate.
Continuing to comb through networkminer and wireshark, I was not seeing any additional activity related to the self-signed Internet Widgits TLS certificates. I decided to filter for DNS traffic in wireshark, as DNS traffic can reveal what domains and IP addresses threat actors are using to conduct their malicious activities. With this filter applied, I noticed that the victim IP made three DNS requests for interesting sounding domains in a relatively short timespan.
The filebin.net and situla.bitbit.net domains are both file sharing sites, and the following connections to both domains were fairly short lived, less than 10 seconds each. This could be possible data exfiltration, or it could be the malware reaching out to retrieve additional resources to drop onto the victim, but that is unclear right now. If I had the TLS private key from the victim, I could decrypt this traffic in wireshark and learn a lot more about what is actually being sent over the network, but for this exercise, I do not have the victim private key.
In the image above, there is also a third domain being queried, bupdater.com. Filtering for this domain’s IP address in wireshark reveals a very interesting pattern.
There are numerous, often short lived, TLS connections occurring between the victim IP and the bupdater.com IP. Something else interesting to note in the image above is the TCP acknowledgement numbers at the end of each connection. At the end of many (but not all) of the connections, the acknowledgement number is 3718, or some value very close to that. This is interesting because it indicates that only a fixed amount of TCP data is being sent over the network in these connections. In other words, this looks like C2 heartbeat activity where the victim is establishing a connection to the C2 server and sending out periodic pings with specified data lengths, in our case 3717 bytes. The victim is then checking for any instructions supplied by the attacker. If there are instructions, the victim will retrieve them and carry them out.
In this case, the bupdater.com domain and IP address are also identified as malicious, and even specifically identified by the community as a cobalt strike C2 server. I was then able to conclude that the threat actor used the initial access provided by the IcedID infection to establish cobalt strike C2 on the victim. At this point, in a real investigation, it would probably be most useful to do some endpoint forensics to generate additional host-based IOC’s like file hashes.
Conclusion
This was a great exercise to learn more about IcedID malware. I was a little bit familiar with IcedID before this exercise, but I am definitely much more aware now of how the malware operates and what artifacts it produces. I also learned a new pattern to look for in pcap files to possibly identify C2 traffic. I will be continuing to experiment with observing patterns in the TCP acknowledgement number, and see if this is something that I can use more often to identify C2 traffic.
Thank you for visiting my blog! If you enjoyed this post, please give me a follow and share this post!
From Infosec Writeups: A lot is coming up in the Infosec every day that it’s hard to keep up with. Join our weekly newsletter to get all the latest Infosec trends in the form of 5 articles, 4 Threads, 3 videos, 2 Github Repos and tools, and 1 job alert for FREE!
