Upatre/Dyre - the daily grind of botnet-based malspam

Published: 2015-05-05. Last Updated: 2017-01-17 03:15:03 UTC
by Brad Duncan (Version: 1)
3 comment(s)

Malicious spam (malspam) delivering Upatre/Dyre has been an ongoing issue for quite some time.  Many organizations have posted articles about this malware.  I've read good information on Dyre last year [1, 2] and this year [3]. 

Upatre is the malware downloader that retrieves Dyre (Dyreza), an information stealer described as a "Zeus-like banking Trojan" [4].  Earlier this year, EmergingThreats reported Upatre and Dyre are under constant development [5], while SecureWorks told us banking botnets continue to deliver this malspam despite previous takedowns [6].

Botnets sending waves of malspam with Upatre as zip file attachments are a near-daily occurrence.  Most organizations won't see these emails, because the messages are almost always blocked by spam filters.

Because security researchers find Upatre/Dyre malspam nearly every day, it's a bit tiresome to write about, and we sometimes gloss over the information when it comes our way.  After all, the malspam is being blocked, right?

Nonetheless, we should continue to document some waves of Upatre/Dyre malspam to see if anything is changing or evolving.

Here's one wave we found after searching through our blocked spam filters at Rackspace within the past 24 hours:

  • Start date/time:  2015-05-04 13:48 UTC
  • End date/time:  2015-05-04 16:40 UTC
  • Timespan:  2 hours and 52 minutes
  • Number of emails:  212

We searched for subject lines starting with the word "Holded" and found 31 different subjects:

  • Holded account alert 
  • Holded account caution 
  • Holded account message 
  • Holded account notification 
  • Holded account report 
  • Holded account warning 
  • Holded bank operation alert 
  • Holded bank operation caution 
  • Holded bank operation message 
  • Holded bank operation notification 
  • Holded bank operation report 
  • Holded bank operation warning 
  • Holded operation alert 
  • Holded operation caution 
  • Holded operation message 
  • Holded operation notification 
  • Holded operation report 
  • Holded operation warning 
  • Holded payment alert 
  • Holded payment caution 
  • Holded payment message 
  • Holded payment notification 
  • Holded payment report 
  • Holded payment warning 
  • Holded transaction alert 
  • Holded transaction caution 
  • Holded transaction message 
  • Holded transaction notification 
  • Holded transaction report 
  • Holded transaction warning

The 212 messages had different attachments.  Here's a small sampling of the different file names:

  • abrogation_warning_information.zip
  • block_alert_data.zip
  • block_alert_document.zip
  • block_alert_report.zip
  • block_message_data.zip
  • block_message_statement.zip
  • cancelation_notification_data.zip
  • cancelation_notification_details.zip
  • invalidation_notification_details.zip
  • invalidation_notification_document.zip
  • nullfication_alert_report.zip
  • nullfication_message_information.zip
  • rejection_message_data.zip
  • rejection_notification_details.zip
  • rejection_warning_details.zip
  • rejection_warning_report.zip

Emails sent by this botnet came from different IP addresses before they hit our mail servers.  Senders and message ID headers were all spoofed.  Each of the email headers show the same Google IP address spoofed as the previous sender.  In the images below, the source IP address--right before the message hit our email servers--is outlined in red.  The spoofed Google IP address is highlighted in blue.  The only true items are the IP addresses before these emails hit our mail servers.  Everything else is cannot be verified and can be considered fake.

This wave sent dozens of different attachment names with hundreds of different file hashes.  I took a random sample and infected a host to generate some traffic.  This Dyre malware is VM-aware, so I had to use a physical host for the infection traffic.  It shows the usual Upatre URLs, Dyre SSL certs and STUN traffic we've seen beffore with Upatre/Dyre.


Shown above: Filtered Wireshark display of the pcap showing the infection traffic.


Shown above: EmergingThreats-based Snort events on the infection traffic using Security Onion.

Of note, icanhazip.com is a service run by one of my fellow Rackspace employees [7].  By itself, it's not malicious.  icanhazip.com is merely a free service that reports your host's IP address.  Unfortunately, malware authors use this and similar services to check an infected computer's IP address.  Because of that, you'll often find alerts that report any traffic to these domains as an indicator of compromise (IOC).

The Upatre HTTP GET requests didn't return anything.  Apparently, the follow-up Dyre malware was downloaded over one of the SSL connections.  Here's what I grabbed off the infected host:

Dyre first saved to:  C:\Users\username\AppData\Local\Temp\vwlsrAgtqYXVcRW.exe
Dyre was then moved to:  C:\Windows\vwlsrAgtqYXVcRW.exe

Registry keys for persistence:

Key name: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\googleupdate
Key name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\googleupdate
Value name: ImagePath
Value type: REG_EXPAND_SZ
Value data: C:\Windows\vwlsrAgtqYXVcRW.exe

A pcap of the infection traffic is available at:

http://malware-traffic-analysis.net/2015/05/04/2015-05-04-upatre-dyre-traffic.pcap.zip

A zip file of the associated Upatre/Dyre sample is available at:

http://malware-traffic-analysis.net/2015/05/04/2015-05-04-upatre-dyre-malware-sample.zip

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

It's a daily grind reviewing this information, and most security professionals have higher priority issues to deal with.  However, if we don't periodically review these waves of Upatre/Dyre, our front-line analysts and other security personnel might not recognize the traffic and may miss the IOCs.

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

References:

[1] https://www.us-cert.gov/ncas/alerts/TA14-300A
[2] http://www.secureworks.com/cyber-threat-intelligence/threats/dyre-banking-trojan/
[3] http://securityintelligence.com/dyre-wolf/
[4] http://www.networkworld.com/article/2878966/microsoft-subnet/dyre-banking-trojan-tweaked-to-spread-upatre-malware-via-microsoft-outlook.html
[5] http://www.emergingthreats.net/about-us/blog/dyre-upatre-constant-development
[6] http://www.secureworks.com/cyber-threat-intelligence/threats/banking-botnets-persist-despite-takedowns/
[7] https://major.io/icanhazip-com-faq

Keywords:
3 comment(s)

Comments

This is not an IOC but an IOCS: indicator of complete stupidity, and PEBKAC as well!

1. writing to %SystemRoot% or [HKEY_LOCAL_MACHINE] needs administrative privileges.
Whoever uses an administrator account for her daily work is an complete idiot.

2. execution of both the dropper/downloader as well as the payload can simply be inhibited with SAFER alias software restriction policies or Applocker.
I suggest that you read this blog and see that Upatre is capable of silently elevating itself to admin with NO user interaction whatsoever
http://lupwa.org/bleen/2015/02/08/upatre-downloader-malware-using-appcompat-for-automatic-uac-elevation/
There is an update to partially solve this and force a UAC prompt but Microsoft in their wisdom have made it an optional update and not critical or recommended update.
http://lupwa.org/bleen/2015/05/01/microsoft-patches-appcompat-uac-bypass-vulnerability/
Only dimwits consider UAC as security boundary.
Fortunately its developers are not THAT stupid:
https://support.microsoft.com/en-us/kb/2526083
https://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx
https://technet.microsoft.com/en-us/magazine/2009.07.uac.aspx
https://technet.microsoft.com/en-us/magazine/2007.09.securitywatch.aspx

JFTR: bypassing UAC needs to run a program in the first place.

Diary Archives