Upatre/Dyre malspam - Subject: eFax message from "unknown"

Published: 2015-05-20. Last Updated: 2015-05-20 02:47:20 UTC
by Brad Duncan (Version: 1)
5 comment(s)

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:

  • Date/Time: 2015-05-19 from from 12:00 AM to 5:47 AM CST
  • Number of messages: 20
  • Sender (spoofed): sent@efax-mail.co.uk
  • Subject: eFax message from "unknown" - [random number] page(s)
  • Attachment: Fax_ewew_43434.zip

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:

  • 2015-05-19 15:16:12 UTC - 166.78.246.145 port 80 - icanhazip.com - GET /
  • 2015-05-19 15:16:13 UTC - 91.211.17.201 port 13410 - SYN packet to server, no response
  • 2015-05-19 15:16:16 UTC - 80.233.179.250 port 443 - two SYN packets to server, no response
  • 2015-05-19 15:16:58 UTC - 85.67.42.40 port 443 - two SYN packets to server, no response
  • 2015-05-19 15:17:40 UTC - 188.127.129.48 port 443 - SSL traffic - approx 510 KB sent from server to infected host
  • 2015-05-19 15:17:56 UTC - 217.10.68.152 port 3478 - UDP STUN traffic to: stun.sipgate.net
  • 2015-05-19 15:17:58 UTC - 62.122.69.132 port 443 - SSL traffic - approx 256 KB sent from server to infected host
  • 2015-05-19 15:18:40 UTC - 91.211.17.201 port 13409  - SYN packet to server, no response

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.


Shown above: An example of Upatre-style HTTP GET requests from my previous ISC Diary on Upatre/Dyre


Shown above: Attempted TCP connections to the same IP address now reset (RST) by the server

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:

  • C:\Users\username\AppData\Local\PwTwUwWTWcqBhWG.exe (Dyre)
  • C:\Users\username\AppData\Local\ne9bzef6m8.dll
  • C:\Users\username\AppData\Local\Temp\~TP95D5.tmp (encrypted or otherwise obfuscated)
  • C:\Users\username\AppData\Local\Temp\Jinhoteb.exe (where Upatre copied itself after it was run)

Some Windows registry changes for persistence:

  • Key name: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
  • Key name: HKEY_USERS\S-1-5-21-52162474-342682794-3533990878-1000\Software\Microsoft\Windows\CurrentVersion\Run
  • Value name: GoogleUpdate
  • Value type: REG_SZ
  • Value data: C:\Users\username\AppData\Local\PwTwUwWTWcqBhWG.exe

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.

---
Brad Duncan, Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

References:

[1] https://isc.sans.edu/diary/UpatreDyre+the+daily+grind+of+botnetbased+malspam/19657
[2] https://major.io/icanhazip-com-faq

Keywords:
5 comment(s)

Comments

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,

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.
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.
That server may have been taken off line or differently-configured, maybe? I don't know why the RST packets happened in this case.
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.

Diary Archives