14 min read
CloudShark developer and packet guru Tom Peterson gives us another example from malware-traffic-analysis.net to learn how to best use CloudShark and our Threat Assessment add-on to get to the root of malicious activity. Let’s join him now for his latest exercise.
The 2017-11-21 malware traffic analysis exercise is a bit different than the past two I’ve dug into. This exercise is simply 6 PCAPs and our task is to just figure out what’s happening in each one. I’ve had a lot of fun diving real deep in the last two exercise but with 6 PCAPs I won’t be able to dive in quite as deep to each of these.
For this exercise I started out with the threat assessment to try and figure out what these threats meant and what was happening in the capture. The proof is in the packets so by doing a little research and comparing this with these pcaps I tried to get a quicker idea of what happened in each capture.
Here is a link to the threat assessment on CloudShark:
https://www.cloudshark.org/analysis/b443a3756d2a/threats_vectors
Infected machine
First glance at threat assessment and I’m thinking that the user went to a site that uses the RIG Exploit Kit to deliver some sort of malware named Ramnit. The infected machine now appears to be checking in with what I’m guessing are CnC servers.
Looking at the HTML in the HTTP traffic between this machine and 188.225.38.247. Shows us some gnarly looking javascript embedded in the HTML with the <script> tag. I’m tempted to try and deobfuscate this and really dive in but with 5 PCAPs still left to analyze I’ll assume this was malicious and keep following what this client sent on the network. I’m guessing thats what is responsible for the flash file the browser later downloads from this same server and a quick submission to VirusTotal confirms that this file set off quite a few alerts!
Those URLs also look really suspicious. It reminds me of the gates that I read about in this blog post describing the parts of an exploit kit:
“These additional servers are called “gates” because they act as a gate to the EK. Sometimes, this means the gate will only allow Windows hosts to connect with an EK server. If you are using a Macbook or Linux host, the gate examines the user-agent string in the HTTP headers, and it will not forward you to the EK landing page.”
Coincidentally the author of this post is Brad Duncan who puts together these very exercises! I’m not certain but those URLs look like the have URL arguments encoded in base-64. When I have some more time I’ll take a close look at that blog and see if I can learn more about how this exploit kit delivers it’s malware.
So it looks like the RIG Exploit kit was responsible for delivering this malware. Now what does this malware do? Looks like it’s called Ramnit based on our threat assessment.
Since we’ve only got two IP addresses here let’s take a look back at the packets. Looks like it’s over TCP port 443 but it doesn’t look like normal TLS traffic to me. A follow stream on one of these makes it look like encrypted data.
The technical information from Microsoft on this says that it creates a backdoor and connects to a remote server which looks just like whats happening in this capture! It looks like the RIG Exploit kit delivered this Ramnit malware and now this machine is compromised and phoning back home!
Here is a link to the threat assessment on CloudShark:
https://www.cloudshark.org/analysis/a7cfce5eb1e5/threats_vectors
Looks like we’ve got an EXE download over HTTP right off the bat to investigate!
Looking at the HTTP and SSL traffic it looks like the user searched for mail.yahoo.com then went and checked their e-mail. Guessing they got some malspam and were tricked into running a malicious EXE.
It looks like we might not have captured everything from these EXE downloads. If we had then we would see the HTTP responses as well that were reassembled from all of the TCP packets in the responses.
The follow stream though does show us the strings MZ and This program cannot be run in DOS mode. The MZ comes from the name Mike Zbikowski, one of the developers of MS-DOS. Wikipedia has some more information about this file format and the magic number MZ that indicates this is an EXE file.
Since these didn’t get reassembled I won’t be able to download them and submit them to VirusTotal or reverse.it to analyze the EXEs. Looks like we’ll have to go back to the packets to see what that software might have done!
Well, this TCP stream that triggered a Loki Bot Checkin looks a bit familiar. The HTTP stream here doesn’t actually show us the data that the client sent along with it’s HTTP request. Maybe this is more of a coincidence but it seems like it could be done on purpose to help the malware avoid detection.
In that TCP stream W.I.N.-.D.5.2.4.3.B looks a bit too similar to the host name of the infected machine to be a coincidence though. We also see, h.e.n.r.y...j.o.h.n.s.o.n being sent. Good thing we quickly looked at the DHCP traffic from our infected host and recorded this information right off the bat.
I remember running into Loki Bot malware in a previous exercise. There was actually a python script that will read a PCAP and spit out the data sent back to the CnC server. With this we can get an even deeper look into what happened quickly:
"Compromised Host/User Description": {
"64bit OS": false,
"Built-In Admin": false,
"Domain Hostname": "WIN-D5243B",
"Hostname": "WIN-D5243B",
"Local Admin": true,
"Operating System": "Windows 7 Workstation",
"Screen Resolution": "1280x720",
"User Name": "henry.johnson"
},
"Malware Artifacts/IOCs": {
"Binary ID": "ckav.ru",
"Loki-Bot Version": 1.8,
"Mutex": "4FEB8C9C72387571BAB0DD6F",
"Potential Hidden File [Hash Database]": "%APPDATA%\\C72387\\7571BA.hdb",
"Potential Hidden File [Keylogger Database]": "%APPDATA%\\C72387\\7571BA.kdb",
"Potential Hidden File [Lock File]": "%APPDATA%\\C72387\\7571BA.lck",
"Potential Hidden File [Malware Exe]": "%APPDATA%\\C72387\\7571BA.exe",
"Unique Key": "Satcl",
"User-Agent String": "Mozilla/4.08 (Charon; Inferno)"
},
"Network": {
"Data Transmission Time": "2017-11-20T19:14:00.524227",
"Destination Host": "tcoolonline.mobi",
"Destination IP": "185.118.166.155",
"Destination Port": 80,
"First Transmission": false,
"HTTP Method": "POST",
"HTTP URI": "/wp-admin/css/colors/blue/Panel/five/fre.php",
"Source IP": "10.192.1.157",
"Source Port": 49291,
"Traffic Purpose": "Exfiltrate Application/Credential Data"
}
"Malware Artifacts/IOCs": {
"Binary ID": "ckav.ru",
"Loki-Bot Version": 1.8,
"Mutex": "4FEB8C9C72387571BAB0DD6F",
"User-Agent String": "Mozilla/4.08 (Charon; Inferno)"
},
"Network": {
"Data Transmission Time": "2017-11-20T19:14:01.413147",
"Destination Host": "tcoolonline.mobi",
"Destination IP": "185.118.166.155",
"Destination Port": 80,
"HTTP Method": "POST",
"HTTP URI": "/wp-admin/css/colors/blue/Panel/five/fre.php",
"Source IP": "10.192.1.157",
"Source Port": 49292,
"Traffic Purpose": "Get C2 Commands"
}
One stream that says the purpose is to Exfiltrate Application/Credential Data is exactly the stream we were looking at! Doing these exercises is starting to pay off when we run into something similar to what we’ve seen before!
This user probably got a malspam e-mail and we can go try and figure out which e-mail it was with the user. That it turn infected the machine and turned it into a part of a Loki botnet. Now it’s sending data back and waiting for commands from a remote server that has this machine under its control.
Here is a link to the threat assessment on CloudShark:
https://www.cloudshark.org/analysis/45160c3c0809/threats_vectors
Well in the treat assessment first we see some DNS queries to a .tk domain then HTTP requests to a .tk domain.
Finally we see a threat for a Microsoft Tech Support Scam. In this case it looks like the user went to some site infected with software that sends the user to a fake page telling the user that their computer is infected with malware. The instructions on these pages usually seem to tell the user to call a number.
We can look at what the user was doing right before they queried a .tk domain to see what site might have sent them there. To do this I opened the DNS Analysis tool to look at what addresses were resolved. Then clicked on the first .tk query which will bring us back to the packets with a filter expression highlighting these packets.
Next I added || http to the filter expression to see if we can find what traffic sent our user to this site. That made it pretty obvious who sent the users browser there. Check it out the annotations to see what I found for this one!
Here is a link to the threat assessment on CloudShark:
https://www.cloudshark.org/analysis/8ce9916365a5/threats_vectors
The threats that got triggered in threat assessment seem a lot less specific and don’t seem to mention any specific types of malware. There is a threat where an HTTP server sent a file it indicated was a image but in fact it was an EXE that could contain malware.
That seems like a good way to keep an EXE out of a log file or to sneak it past a firewall maybe but not enough to hide it from the rules we use for threat assessment provided by proofpoint!
I’m not really sure what WS/JS Downloader is but it looks like that caused an EXE download after trying a few hosts and then some DNS queries to a .onion proxy. Not sure yet what that means but it doesn’t sound like safeware!
Threat assessment gave us a great place to start investigating this network traffic but we’ll have to dig a little deeper into the packets to figure out exactly whats going on. I imagine this happens often with new malware that doesn’t have rules yet that can detect threats and tie them to specific instances of malware.
After eliminating the threat endpoints that didn’t respond to the WS/JS Downloader threats I’m left with one host and some DNS queries.
Let’s start with HTTP traffic to and from that host flagged as a threat. All I’m seeing here is what appears to be two requests but no responses. Threat assessment wouldn’t flag that as an EXE download so we must be having some trouble reassembling HTTP traffic again! Since CloudShark supports per-capture preferences I can turn this off on this capture file to see if that makes a difference.
The same capture with HTTP reassembly off show us a bit of a different picture. There is a response but there were quite a few packets we didn’t capture. Since these packets are not in the capture file there is no way to reassemble the file sent as a response. We won’t be able to send a partial file to VirusTotal or reverse.it so we’ll have to keep investigating the packets this machine sent to get an idea of what happened.
Once again the follow stream shows us that same MZ string. We can also see Content-Type: image/png in the HTTP headers which is the server indicating that the file is an image even though it is not.
So now we know that an EXE got downloaded and I’d have to guess that this contained some malware. The other traffc flagged as a threat was DNS queries to a .onion proxy. Sounds like the TOR network. Using the DNS Resolved Hosts tool I found where onion.link resolved and clicked that row to get a filter expression for all the traffic sent there. It is all encrypted traffic so I added < em class="code">|| (frame.number > 12606 ) to see what the client did after.
Here we see the client going to coinurl.com which claims to be anonymous keyword-based contextual advertising for Bitcoins based on a Google search. Sounds like it could be ransomware telling the user to deposit Bitcoins to decrypt their files?
From here we have quite a collection of possible things to research to see if anyone else has run into this before. We could search for the host the client downloaded the malware from, connexion-zen.com and from there I found this write-up which has this host as an Indicator of Compromise. This write-up says that it is in face ransomware. Specifically NemucodAES and that the decryption instructions are hosted on connexion-zen.com - GET /counter [followed by long string of characters] which sounds exactly like what we see in our PCAP. It also looks like there might be a decrypter for this ransomware that might help recover these files.
Another search for that onion host the client connected to though brought me to this write-up. These both sound a lot like what we are seeing in our PCAP. It also turns out that the author of both of these is Brad who puts together these exercises! Being able to research what we saw in this capture and finding some publicly released analysis was invaluable for this one. It goes to show how important this information can be. I can’t imagine I would have been able to name this ransomware from just the packets this time and certainly not this quickly!
Here is a link to the threat assessment on CloudShark:
https://www.cloudshark.org/analysis/ef600c984799/threats_vectors
That first threat sounds familiar. I think I’ve run into something relating to Chrome Fonts before where a page loads and shows the UTF-8 replacement character (�) so that it looks like there is a missing font. Then a pop-up appears telling the user to download and install a font but this is really a malicious EXE. A quick look at that TCP stream once again shows us the MZ magic number so this “font” is really an EXE file.
This stream also tells us what site sent the user to download this font in the HTTP header Referer: http://www.accutech.net/. Adding || frame contains liceobelgrano to the filter expression for this stream shows us the DNS request to resolve this name and also packet number 78. Inside that HTTP stream we can find the following text:
The web page you are trying to load is displayed incorrectly, as it uses the "HoeflerText" font. To fix the error and display the text, you have to update the "Chrome Font Pack"
Followed by a link to http://www.liceobelgrano.edu.ar/goto3.php.
It looks like the user went to try and install a font to view this page and instead downloaded and ran malware!
After that we see a threat for W32/Backdoor.Ratenjay C2 Domain Detected (printscreens .info in TLS SNI) which a quick search indicates that it is a Trojan that opens a back door on the machine.
Finally the last HTTP stream flagged a threat pretty clearly shows that this machine is sending CnC traffic indicating that it is now a part of a botnet! It looks like it’s actually using commecial software designed as a support tool. This traffic isn’t even encrypted so we can see this traffic and learn more about how this machine is infected and what it would allow an attacker to do. For now though it’s enough to know it is infected and I only have one left now!
Here is a link to the threat assessment on CloudShark:
https://www.cloudshark.org/analysis/ba16d0fb1045/threats_vectors
In this threat assessment we see the machine downloading an EXE over HTTP and that was also flagged as a Terse Named Filename EXE Download. Looks like thats because the filename for this was r.exe. Looking at this stream we are missing some packets from the download of this EXE again so we won’t be able to export the file. To try and find why the client would download this I made a filter for that stream, DNS queries for that server, and packets showing what server the client connected to. That shows a lot of connections to messaging.office.com so I’m guessing it was a malicious spam e-mail that instructed the user to download this.
Next we see a Feodo Tracker Reported CnC Server threat. Reading the external references this rule is actually generated from a daily list of know CnC servers that has been made available to the public! I was actually able to look up the one in our pcap which tells us that the server is still online and even that it is running version E of this Feodo trojan called Heodo. Here is a brief description of what it might be capable of.
Phew! That was quite a lot of malware! Throughout this was I was glad to see some practice paying off when I ran into things I’ve seen before. It also made me think about how being able to research and read other peoples analysis helped. Being able to use publicly available resources like the InfoSec Diary Blog, write-ups from Brad, and malware trackers like abuse.ch seems fundamental to this analysis. I also noticed a lot more issues where we couldn’t download the malware from the packet capture due to missing captures. That was a great resource in previous exercises so shows how important it can be to have a reliable packet capture setup to ensure every single packet is captured.
Want articles like this delivered right to your inbox?
No spam, just good networking
