For today’s post, I wanted to get back into some malicious traffic analysis. I created a quick script to randomize traffic analysis examples, and was provided the link to the Malware-Traffic-Analysis.net exercise on April 16, 2016. You can find more information about the challenge here.
The challenge asks the following questions of us:
- The user’s first and last name
- The host name of the user’s Windows computer
- The MAC address of the user’s Windows computer
- A summary of what happened
Fairly straight forward! To answer these, we are provided a PCAP and the Snort and Suricata alerts generated by this output.
There’s a whole lot of badness in our traffic alerts, all of which point to only a handful of places to look within the PCAP. Here’s a few key alerts:
Note that there is a caveat that the timing may be off due to how the exercise was constructed.
Despite the large number of alerts, there are actually only two suspicious external IPs:
As with every MTA exercise, we begin by profiling our subject host. Once again, I can find a lot of information from our DHCP packets:
Here’s a screenshot of a data from an Inform packet:
Let’s start to pull together some information about our target system:
- IP Address: 172.16.155.149
- System Name: Manny-PC
- MAC Address: 00:24:e8:83:a5:69
We don’t have user information just yet, but this might come to us as we continue to analyze. Let’s start digging into our alerts.
Let’s begin with our first IP:
Notice our malicious traffic doesn’t actually start until frame 7995. This cut down about 50% of the traffic. Again, we’re making our lives easier by removing background noise and focusing on the potential leads. I can also easily discern that it looks like HTTP traffic to/from this IP address. Let me add another filter and see what we have at play here. I’m going to drop in the filter
ip.addr==184.108.40.206 && http.host.
Now we’re down to only 39 frames, and I can start to identify the HTTP traffic better. It looks like the malicious traffic was hosted at
billinggoldspal[.]com, and the parent folder for files served was
/cola/153b7ff4a55eb44e549bcd88c8c11368/index/web. These may be useful indicators that I can take to my perimeter or proxy logs and look for other infected hosts.
Here’s the first alert I’m going to filter on:
Wireshark filter to find this quickly:
ip.addr==220.127.116.11 && http.host && tcp.port==49273
The first entry looks like a POST method, and the others are mostly CSS sheets and images. Let’s examine the content of the POST:
Well, shucks. Looks like Manny’s information got stolen and passed in cleartext. Let’s add that to our indicators:
- Username: email@example.com (this providing first and last name)
- Password: onecooldude
From our Referer data, it looks as though the page that sent this data was index.php (see above). Let’s take a look at the HTML for that page:
Sure enough, we’ve got a form that submits to Taz.php, via POST, and collects username and password. The text placeholders make it look like a PayPal site. Without the images, here’s a rendering of the HTML of index.php:
So, in summary, it looks like:
- Manny got phished, and was directed to the website
billinggoldspal[.]comand asked to enter his PayPal information. Once that information was captured, he was redirected to a second page, confirm.html,
That page looks like:
So after stealing his credentials, the site was likely looking to steal some financial information from him as well. Poor Manny!
Let’s see if we can figure out what tripped Suricata:
Until tomorrow, Happy Forensicating!