The importance of ongoing dialog

Published: 2016-03-24. Last Updated: 2016-03-24 02:40:17 UTC
by Brad Duncan (Version: 1)
10 comment(s)

Introduction

I recently transitioned into a new role at Palo Alto Networks Unit 42.  Since then, I've published a couple of blog posts describing recent developments in ongoing campaigns [1, 2].  Those are examples of "ongoing dialog" for known threats.  But like most people, I get excited about new malware.  Many reporters tend to focus on new campaigns, exploits, malware, and vulnerabilities.  Any why not?  They usually make a more interesting story.  However, we should also keep track of ongoing campaigns.  It's often news-worthy to announce something is still happening.

The importance of a continuing discussion

Continuing discussion--an ongoing dialog--of security matters is important.

But even security professionals are sometimes jaded, especially by the constant waves of malicious spam (malspam) that hit our mail filters.  For example, many of us know about the continuing malspam used to distribute Locky ransomware.  It was first discovered last month [3, 4, 5].  But after you've seen Locky on a near-daily basis, and you've implemented protective measures, the threat loses its impact.

That's good.  That's also the desired outcome.  But what happens after we've done our due diligence?  What happens when the threat is no longer new, but it's still profitable for the criminals behind it?  The majority of people (those not in security) tend to forget about it.

That also assumes the average person knows about specific issues like Locky ransomware.  Locky must compete for media attention with many other threats.  Information about any specific threat can easily get lost in the constant stream of issues we read about.

For Locky, this can happen, despite near-daily reporting by some sources of Locky-related malspam [6, 7, 8].  For example, on Wednesday 2016-03-23, the ISC received the following notification through our contact page:

  

We've been getting quite a file attachments with .zip files that contain javascript files.  The email messages originate from a number of different countries and the sending IP address has only a single recipient.  (This is based on an IP search in the Google Apps mail report.)

I'm submitting these because I've never seen this pattern before and I would be interested in an evaluation by those who can un-obfuscate the js.

The tar file contains 3 examples:
AAA1136807105.js
JXC1634405726.js
QXB8619121131.js

thanks,
[redacted]

FILE UPLOAD. Original File Name: javascript-malware.tar

  

That sounds like botnet-based malspam.  But what was the payload?  I extracted one of the .js files from the archive, ran it on a Windows host in my lab, and found the following traffic:


Shown above:  Traffic after running one of the .js files on a Windows host.

The infected Windows host looked like what I've seen before with Locky.  Someone had also seen the HTTP GET request for 762trg22e2.exe associated with Locky [9].  I replied to the person who notified us.  Another ISC handler, Didier Stevens, noted the obfuscation in those .js files looks like what he'd posted in a previous diary.


Shown above:  A previous example of a Windows host infected with Locky.

Final words

This is a good example, I think, of why we should keep discussing ongoing threats.

It's always fun to investigate these notifications.  As ISC handlers, we take great satisfaction in assisting others on security-related issues.  Hopefully, today's diary raises awareness about this particular flavor of botnet-based malspam.  It's a threat seen on a daily basis, whether you realize it or not.

Have you run across Locky ransomware?  Have you found any indicators of compromise (IOCs) that haven't been posted publicly?  Are there any stories about Locky you'd like to share?  If so, please leave a comment.  Let's keep the dialog going.

---
Brad Duncan
brad [at] malware-traffic-analysis.net

References:

[1] http://researchcenter.paloaltonetworks.com/2016/03/locky-ransomware-installed-through-nuclear-ek/
[2] http://researchcenter.paloaltonetworks.com/2016/03/unit42-campaign-evolution-darkleech-to-pseudo-darkleech-and-beyond/
[3] http://researchcenter.paloaltonetworks.com/2016/02/locky-new-ransomware-mimics-dridex-style-distribution/
[4] http://www.proofpoint.com/us/threat-insight/post/Dridex-Actors-Get-In-the-Ransomware-Game-With-Locky
[5] https://labsblog.f-secure.com/2016/02/22/locky-clearly-bad-behavior/
[6] https://techhelplist.com/component/tags/tag/275-locky
[7] http://blog.dynamoo.com/search/label/Locky
[8] https://myonlinesecurity.co.uk/tag/locky/
[9] https://blog.cyveillance.com/widespread-malspam-campaign-delivering-locky-ransomware/

Keywords:
10 comment(s)

Comments

We saw this today. Fortunately it was a sophisticated client with good backups.
Just for the record this just sailed through my fully updated PA-500 a few minutes ago in my test lab.
I have seen about 7 emails in last couple weeks with subject "Unsuccessful WU transaction # 58225386" "payment receipt" "contract ID 26790 has been terminated" "Your booking #82455015 is confirmed" "Insufficient Funds Transaction ID:66552026" "Incoming Transaction Declined ID: 95939242"

These emails have an attachment ZIP file with names corresponding to the subject ("Download see it ##.zip" "Download operation ##.zip" etc.).

I have not submitted for analysis, but can reasonably assume these ZIPs are evil.
My Locky experience. A friend clicked on zip attachment, subject related to piano invoice. Locky started showing up in documents in the profile. I had her turn off computer. I booted into safe mode, ran malware bytes and cleaned system (a few files and registry entries). I determined there was no recent backup. I had read that one possible recovery to ransomware was to check for deleted files to recover those that had been deleted after encryption occurred. My result did not show this to be the case. I checked shadow copies and found the last shadow copy was available and used it to restore files that had been encrypted. I also set them up with regular backup program. Not sure if Locky didn't run properly and delete shadow copies, if that is normal process or if turning off prevented shadow copy deletion. In any event, we were happy shadow copies were there.
[quote=comment#36759]I have not submitted for analysis, but can reasonably assume these ZIPs are evil.[/quote]

Indeed... That's a typical pattern for botnet-based malspam. Thanks for the comment!
Thanks for the story, HCM!
Here's another random correlation that proves your point about sharing info- the IP address that showed up in the POST requests (46.8.44.39) rang a bell. I had looked up some proxy hosts mentioned in a Brian Krebs article on the Joker's Stash card dump market (krebsonsecurity.com/2016/03/carders-park-piles-of-cash-at-jokers-stash/), and two of them map to IPs in the same zone:

spawn-mind-arrest.com = 46.8.44.116

valve-another-process.org = 46.8.44.116

See the article for details. Not a good neighborhood:

whois -h whois.ripe.net 46.8.44.0/23
Had a machine with locky today, similar email zip attachment a file called qPFIPalQKop.exe was run from the users appdata local temp folder followed by a exe within the IE temp folder. MS security essentials did detect it and removed the exe but the damage had been done.
[quote=comment#36775]Had a machine with locky today, similar email zip attachment a file called qPFIPalQKop.exe was run from the users appdata local temp folder followed by a exe within the IE temp folder.[/quote]
Spread the word: NO (l)user needs to execute anything from their %APPDATA%, their %TEMP% folders, their browsers cache, their whole %USERPROFILE%, or any other location they can write too!
Setup SAFER alias software restriction policies and deny execution there: see http://home.arcor.de/skanthak/SAFER.html as well as http://www.mechbgon.com/srp/index.html
Or get Microsoft's advice: https://technet.microsoft.com/en-us/library/bb457006.aspx

[quote=comment#36775]MS security essentials did detect it and removed the exe but the damage had been done.[/quote]
NO anti-something provides protection against unknown or just new malware, they "work" (really: fail) just like russian roulette. Privilege separation and restrictive system configuration but provide proper protection!
Fully agree policies are the way to go, this was a non corp friend of a friends machine.

Diary Archives