Introduction Yesterday on 2015-05-19, I attended a meeting from my local chapter of the Information Systems Security Association (ISSA). During the meeting, one of the speakers discussed different levels of incident response by Security Operations Center (SOC) personnel. For non-targeted issues like botnet-based malicious spam (malspam) infecting a Windows host, you probably won't waste valuable time investigating every little detail. In most cases, you'll probably start the process to re-image the infected computer and move on. Other suspicious events await, and they might reveal a more serious, targeted threat. However, we still recover information about these malspam campaigns. Traffic patterns evolve, and changes should be documented. Today's example of malspam Searching through my employer's blocked spam filters, I found the following Upatre/Dyre wave of malspam:
As shown in the above image, these messages were tailored for the recipients. You'll also notice some of the recipient email addresses contain random characters and numbers. Nothing new here. It's just one of the many waves of malspam our filters block every day. I reported a similar wave earlier this month [1]. Let's look at the malware. The attachment is a typical example of Upatre, much like we've seen before. Let's see what this malware does in a controlled environment. Indicators of compromise (IOC) I ran the malware on a physical host and generated the following traffic:
In my last post about Upatre/Dyre, we saw Upatre-style HTTP GET requests to 91.211.17.201 but no HTTP response from the server [1]. That's been the case for quite some time now. However, in this example, the infected host attempted a TCP connection to 91.211.17.201, but the connection was reset after the initial SYN packet, and an HTTP GET request was never sent.
How can we tell this is Upatre? The malware checks for an IP address, and header lines in the associated HTTP GET request fit the pattern for Upatre. As I've mentioned before, icanhazip.com is a service run by one of my fellow Rackspace employees [2]. By itself, it's not malicious. Unfortunately, malware authors use this and similar services to check an infected computer's IP address. What alerts trigger on this traffic? See the image below for Emerging Threats-based Snort events on the infection traffic using Security Onion. Related files on the infected host include:
Some Windows registry changes for persistence:
A pcap of the infection traffic is available at: A zip file of the associated Upatre/Dyre malware is available at: The zip file is password-protected with the standard password. If you don't know it, email admin@malware-traffic-analysis.net and ask. Final words This was yet another wave of Upatre/Dyre malspam. No real surprises, but it's always interesting to note the small changes from these campaigns. --- References: [1] https://isc.sans.edu/diary/UpatreDyre+the+daily+grind+of+botnetbased+malspam/19657 |
Brad 433 Posts ISC Handler May 20th 2015 |
Thread locked Subscribe |
May 20th 2015 7 years ago |
I recall a few months back upatre uses a really special user-agent Mazilla when it goes to icanhazip.com; which makes the traffic really easy to detect. I have analyze a PCAP recently and it seems to have remove this user-agent, but I can't confirm this information as I did not have enough time to work on more samples. Can you confirm with me that upatre still use the user agent Mazilla?
Reference: http://comments.gmane.org/gmane.comp.security.ids.snort.emerging-sigs/22692 |
Mostropi 27 Posts |
Quote |
May 20th 2015 6 years ago |
Mostropi,
I didn't see Malzilla in that particular user agent for Upatre (see the image from the diary entry). I haven't seen Upatre use Malzilla as a user agent in the past month or so at least. I haven't been tracking it that closely, though, so its hard to say when it switched to what we're seeing now. |
Brad 433 Posts ISC Handler |
Quote |
May 20th 2015 6 years ago |
Yeah, seems like the Mazilla thing has been removed; I havent look at this sample traffic, is any reason why the RST was sent back by the server? Haven't seen any malware traffic that does this.
|
Mostropi 27 Posts |
Quote |
May 20th 2015 6 years ago |
That server may have been taken off line or differently-configured, maybe? I don't know why the RST packets happened in this case.
|
Brad 433 Posts ISC Handler |
Quote |
May 20th 2015 6 years ago |
Im guessing it had been probably been taken off too; but hesitated and was thinking that you may have found something else; thanks for the confirmation.
|
Mostropi 27 Posts |
Quote |
May 20th 2015 6 years ago |
Sign Up for Free or Log In to start participating in the conversation!