Full Packet Friday: Malware Traffic Analysis

For today’s post, I’ll be taking a look at the Malware Traffic Analysis exercise that was posted on January 28, 2017. Just in time to get back to network forensics! As always, a huge thanks to Brad over at MTA for providing these challenges to work through.

The Questions

BASIC QUESTIONS:

  • What is the MAC address of the infected Windows computer?
  • What is the IP address of the infected Windows computer?
  • What is the host name of the infected Windows computer?
  • What type of malware was the computer infected with?

ADVANCED QUESTIONS:

  • What exploit kit was used to infect the user’s computer?
  • What compromised website kicked off the infection chain of events?

MORE ADVANCED QUESTIONS:

  • Which campaign(s) used the exploit kit noted in the pcap?
  • What are the indicators of compromise (IOCs) from the pcap?

Answers can be found at the end of the post.

The Alerts

Screenshot of alerts after running PCAP through Security Onion

Based on experience and understanding of what the alerts are showing me, I can already extract a few items:

  • 172.16.4.193 is most likely my infected host’s IP address.
  • My first alert indicated that an evil redirector was located at the IP address 104.28.18.74 — this may not be a bad IP address, but it’s definitely on my list to check out.
  • I have a list of potentially-malicious IPs to dig into: 194.87.234.129, 90.2.1.0, and 198.105.121.50.
  • The infection that took place was Cerber ransomware, via a RIG Exploit Kit.

Analysis

Screenshot of DHCP traffic from Wireshark

Here’s a screenshot of data from one of the Inform packets:

Screenshot of DHCP Inform packet from Wireshark

With this, I can start to profile my victim host:

  • IP Address: 172.16.4.193
  • System Name: Stewie-PC (this is a Family Guy-themed challenge)
  • MAC Address: 5c:26:0a:02:a8:e4

IP Address: 194.87.234.129

Screenshot of Wireshark traffic filtered on IP address 194.87.234.129

This IP alone consumes approximately 24% of the PCAP, so there’s too much traffic to capture in one screenshot. However, I can pull a few things from the initial packets:

  • This IP address is associated with the domain tyu[.]benme[.]com.
  • My Snort alert identified traffic occurring over port 80, and the filtered packets confirm the traffic was HTTP traffic.

Following the first HTTP stream for this IP address, the first thing I can see is the GET request as well as the Referer, www[.]homeimprovement[.]com:

Screenshot of the HTTP GET request from tcp.stream 45

The first page requested has some browser data collection built-in, which then sends an ugly POST request. Even more ugly though, is the obfuscated-as-crap script that comes back. Here’s a snippet:

Screenshot showing POST request followed by heavily-obfuscated JavaScript

This script goes on for a while, until finally we see Shockwave/Flash cross the wire:

Screenshot showing GET request followed by an application/x-shockwave-flash content-type

Leaning back on our Snort alerts, we can see that this IP address was responsible for the Exploit Kit landing page, which is contained within the screenshots above. Also, according to the alerts, it appears that this was a RIG exploit kit.

IP Address: 90.2.1.0

Screenshot of Wireshark filtered on IP address 90.2.1.0

There’s only two packets, and the datagram for each contains illegible text. Let’s dig into the snort rule to determine what tripped this wire:

alert udp $HOME_NET any -> $EXTERNAL_NET 6892 (msg:"ET TROJAN Ransomware/Cerber Checkin M3 (15)"; dsize:25; content:"e"; nocase; depth:1; pcre:"/^[a-f0-9]{24}$/Ri"; threshold: type both, track by_src, count 1, seconds 60; reference:md5,42c677d6d8f42acd8736c4b8c75ce505; reference:md5,7f6290c02465625828cfce6a8014c34a; reference:md5,d8b2d2a5f6da2872e147011d2ea85d71; classtype:trojan-activity; sid:2023626; rev:1;)

It appears the destination port of 6892 and the string itself caused issue, which makes sense given the content. I wasn’t happy with only two checkins over this period of time, so I did a quick filter to see if there was other UDP traffic over that port :

udp.port == 6892

Sure enough, there were more checkins:

Screenshot of Wireshark filtered on udp.port 6892

All in all, the following IP ranges and ports should be blocked or monitored:

  • 90.2.1.0–90.2.1.31 (port 6892)
  • 90.3.1.0–90.3.1.31 (port 6892)
  • 91.239.24.0–91.239.25.255 (port 6892)

IP Address: 198.105.121.50

Screenshot of Wireshark filtered on IP address 198.105.121.50 and http.request

Even without knowing anything about the “.top” domain, I’m already suspicious of this traffic. The correlated Snort alert is also concerned, seeing as it’s simply a request to a “.top” domain that tripped it:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET INFO HTTP Request to a *.top domain"; flow:to_server,established; content:".top"; nocase; fast_pattern; http_header; content:"|0d 0a|"; http_header; within:8; pcre:"/^Host\x3a[^\r\n]+?\.top(\x3a\d{1,5})?\r$/Hmi"; threshold:type limit, track by_src, count 1, seconds 30; reference:url,www.symantec.com/connect/blogs/shady-tld-research-gdn-and-our-2016-wrap; reference:url,www.spamhaus.org/statistics/tlds/; classtype:bad-unknown; sid:2023882; rev:1;)

Nonetheless, I dig into the HTTP to try and figure out what this page is. It’s only a matter of a few seconds of scrolling before I come across:

Screenshot of tcp.stream 65 from the challenge network traffic

This page is the Cerber Decryptor page, which was most likely displayed after the ransomware had done its thing on the victim system.

One Last Thing

The Starting Point: The Referer

Screenshot of Wireshark filtered on the IP address 104.28.18.74 and http.request

We saw earlier that our landing page domain was tyu[.]benme[.]com. Armed with this, let’s see if I can find the redirect in the original page. We barely needed to scroll to find this little iFrame hanging out:

Screenshot of iFrame that redirected to an exploit kit landing page

I also noticed at the very beginning of this HTTP stream the Referer to the Referer, which lead the user to the compromised site:

Screenshot of Wireshark showing the Referer as bing.com

It looks like the user was searching for the phrase “home improvement remodeling your kitchen” on Bing.com, which really started this whole fiasco.

Admittedly, the finding above was not the first finding I had from this page. The first thing that piqued my interest was the following snippet, Javascript sourced from a Venezuelan domain:

Screenshot of JavaScript tag loading a script from Venezuela

Now, Venezuela is not bad by itself, however I know this page is compromised in some way. I put this to side after finding the benme[.]com iFrame. Now, let’s look into what this script may be:

Screenshot from Wireshark of tcp.stream 43, showing a second suspicious iFrame

Hah! Well, what do you know, a second iFrame that also points to tyu[.]benme[.]com. I’m not sure what’s going on over at that site, they’re serving up malware for days! It looks like there were potentially two campaigns active on this page.

I had to do a bit more research to pinpoint this one. I started by performing a Whois lookup on the Venezuelan domain, which led me to the following:

Screenshot of Name Servers for VisionUrbana[.]com[.]ve

Using these name servers as search terms, I was able to find a plethora of articles that talked about the Afraidgate campaign. Here’s a few sample posts for reading:

Having two confirmed campaigns was good, but identifying distinct traffic would be tough. Especially when they’re both pointing to the same landing page. Reading through the Afraidgate posts, I noticed that the malware calls out to various PHP pages, and always seems to reference the parameters “g” and “k”, in alphabetical order. So, I set about looking for this callback traffic in Wireshark:

http.request.full_uri contains php and http.request.full_uri contains “?g”

Only two packets were returned (I actually could’ve just filtered on php, given this sample set of traffic):

Screenshot of Wireshark filtered on HTTP request URI containing php and the text ?g

Sure enough, digging into the domain spotsbill[.]com comes full-circle, and I find this article about Afraidgate and RIG exploit kit. There’s tons out there, but I found enough to confirm the campaign.

Answers to the Questions

BASIC QUESTIONS:

  • What is the MAC address of the infected Windows computer? 5c:26:0a:02:a8:e4
  • What is the IP address of the infected Windows computer? 172.16.4.193
  • What is the host name of the infected Windows computer? Stewie-PC
  • What type of malware was the computer infected with? Ransomware

ADVANCED QUESTIONS:

  • What exploit kit was used to infect the user’s computer? RIG Exploit Kit
  • What compromised website kicked off the infection chain of events? www[.]homeimprovement[.]com

MORE ADVANCED QUESTIONS:

  • Which campaign(s) used the exploit kit noted in the pcap?

This answer was a tough one to answer, primarily because I’m not too familiar with who-is-using-what off the top of my head. However, I did some research through Brad’s blog posts, and found this post from 2017–02–06, which contains an iFrame similar to the one in this exercise used by pseudoDarkleech. That group also likes to use the RIG exploit kit.

I documented uncovering the second campaign, Afraidgate, in the analysis section above.

  • What are the indicators of compromise (IOCs) from the pcap?

IP Addresses:
104.28.18.74 (belongs to the compromised site homeimprovement[.]com)
139.59.160.143 (port 80)
194.87.234.129 (port 80)
90.2.1.0–90.2.1.31 (port 6892)
90.3.1.0–90.3.1.31 (port 6892)
91.239.24.0–91.239.25.255 (port 6892)
198.105.121.50 (port 80)
5.188.223.104 (port 80)

Host Names:
retrotip[.]visionurbana[.]com[.]ve
tyu[.]benme[.]com
p27dokhpz2n7nvgr[.]1jw2lx[.]top
spotsbill[.]com (I later found out that this particular callback was related to Godzilla Loader, which Afraidgate uses)

Until tomorrow Happy Forensicating!

Be selective with your battles.