Anatomy of a Malware distribution campaign

Published: 2014-01-19
Last Updated: 2014-01-19 18:41:43 UTC
by Rick Wanner (Version: 1)
8 comment(s)

Starting about 10 days or so ago, a Spam campaign began targeting Pacific Gas and Energy (PG&E), a large U.S. energy provider. PG&E has been aware of this campaign for about a week, and has informed its customers.

This is yet another Spam run targetting the customers of U.S. energy companies that has been going on for several months.  I was able to get  two samples of this run to disect. This is not a campaign targetted directly at known PG&E customers  One of the emails came to an account which I only use as a garbage collector. I have not used the account in about ten years and nobody would legitimately send me email on that account. The second sample came from an ISC handler in Australia.  Neither of us are anywhere near PG&E's service area. 

It wasn't long ago that you could identify Spam by the quality of the English, but these emails look quite professional and the English is good.  The only real issue in the email being formatting of some of the currency figures.

The header  revealed that it was sent from user using IP, most likely a compromised webmail account.   Both the from and the reply-to fields are set to, an email address that bounces.   The IP, the domain and the domain all map to City Telecom Broadband in Kyrgyzstan (country code KG).

These sorts of runs usually have one of two purposes; credential theft, or malware distribution. In this case the goal of this particular campaign seems to be malware distribution. The "click here" link in the two samples point to different places  

  • hxxp://

  • hxxp://

Both of these links are now down, but when they were alive they both served up which contained a Windows executable.

The Antivirus on my test machines were not triggered by this file and Virustotal has a 5/48 detection rate indicating this is most likely a Trojan Dropper:

I get 500 or so Spam and Phishing messages every day.  Fortunately the majority of them are caught in the excellent filters I have in place. This email passed those filters and if I was a PG&E customer would probably look legitimate enough to at least make me look at it twice before disregarding it as Spam.  But how many less tech-savvy PG&E customers got caught by this?  It is clear that modern anti-virus is dying as a front line defense against such attacks.  Is there a technology in the development pipe today that is going to step up and help protect the average user?

-- Rick Wanner - rwanner at isc dot sans dot org - - Twitter:namedeplume (Protected)

Keywords: malware
8 comment(s)


Been getting a lot of these with our spam filter.
Have suggested this before... all web browsers should check on download completion; that way, you get the benefit of all AV products and not just the one you've chosen. Sure, with zero-day, it's not going to hit - but as the samples get collected, and vendors come online, you get an earlier bite at the detection cherry...

Test Result
TXT Record A Valid TXT Record was not found More Info
SPF Record A Valid SPF Record was not found More Info

Does the better a spam mail get, mean it is less likely that errors or indicators can be used for detection?

How much emphasis should we place on SPF, DMARC and DKIM?
>> the English is good.

> Payment(s) Recieved [sic] Since Last Statement

Back to elementary school --> "I before E except after C".

Why Do Some People Insist On Capitalizing The First Letter Of Every Word ? :-)
Maybe, e.e. cummings had it right -- no capitals at all. :-)
This would be a fine way to drive off the net or to change to a fee-based setup. What you're describing could probably be considered abuse of My understanding is it's not meant to be used as a replacement for running your own anti-virus tool/s on users' desktops, just so that admins like us can quickly take one executable 'n see what all of the biggest anti-virus vendors say about it.
[quote=comment#29291]Does the better a spam mail get, mean it is less likely that errors or indicators can be used for detection?

How much emphasis should we place on SPF, DMARC and DKIM?[/quote]

Absolutely - the better the phish is, the less it looks like phish/spam, so the less effective phish/spam filters will be.

IMHO, SPF causes more problems than it solves, though I like DKIM. But it'll be a long, long time before we can just reject email without a valid DKIM signature (or SPF) so it's not a silver bullet either.

For now we're better off educating users (a .exe file inside of a .zip file sent via email is almost never something good - grin). And running as many NIDS as we can afford (snort, PaloAlto Firewalls, FireEye, etc). From my own experience, they're all best suited at detecting different things at different stages in the malware life cycle. For instance, at work it's not at all unlikely to see the FireEye or PAFWs detect malware download, followed thereafter by a snort alert for the malware downloading a 2nd stage binary, followed by other snort alerts as the 2nd stage then phones home or starts to scan things inside the firewalls. And it's not unusual for a laptop infected while off the company network be detected by snort (seems to be better at detecting "bad behavior") but not the PAFWs or FireEyes. (shrug) Doesn't mean one is "better" than the others - they're just "different" and complementary, in my opinion.

Lastly, the days of monitoring only ingress/egress traffic with whatever NIDS solution/s you use are over. Monitoring *all* WAN traffic is a bare minimum and monitoring at least select LAN traffic (say, all traffic to/from server or dmz VLANs) is truly necessary too...
Here in Germany it currently are not faked energy companies bills, but mostly faked bills of internet providers (vodafone, german telekom...). The pattern is the very same.

Two of my users fell into this trap and infected their computers. But without big success. Since the use of the Internet Explorer is prohibited in our company (old tradition since the 'glorious days' of IE6), we have a faked proxy setting, distributed via Active Directory, which efficiently prevented those trojans to communicate with their Bot-masters.

Nevertheless, we isolated and wiped both computers (users are strictly encouraged not to save any critical data on their local harddisks). But to prevent further users to fall into the same trap, I added a little script to Dansguardian on our proxy server. This script simply lists the contents of any zipped or gzipped or rar'ed... file, which a user tries to download, reads the output and checks for common executables extensions. And, if an executable is found, blocks the file from download, Works like a charme!

Only in the rare case, that a user has to legitimately download a file with this pattern (once a year or so), he must call IT department.

Diary Archives