Anatomy of a Malware distribution campaign
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 nf@www1.nsalt.net using IP 212.2.230.181, most likely a compromised webmail account. Both the from and the reply-to fields are set to do_not_reply@nf.kg, an email address that bounces. The 212.2.230.181 IP, the nf.kg domain and the nsalt.net 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://s-dream1.com/message/e2y+KAkbElUyJZk38F2gvCp7boiEKa2PSdYRj+YOvLI=/pge
-
hxxp://paskamp.nl/message/hbu8N3ny7oAVfvBZrZWLSrkYv2kTbwArk3+Tspbd2Cg=/pge
Both of these links are now down, but when they were alive they both served up PGE_FullStatement_San_Francisco_94118.zip 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 - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)
Comments
Anonymous
Jan 19th 2014
1 decade ago
Anonymous
Jan 20th 2014
1 decade ago
Anonymous
Jan 20th 2014
1 decade ago
spf:pgecurrents.com
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?
Anonymous
Jan 20th 2014
1 decade ago
> 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. :-)
Anonymous
Jan 20th 2014
1 decade ago
Anonymous
Jan 20th 2014
1 decade ago
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...
Anonymous
Jan 20th 2014
1 decade ago
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.
Anonymous
Jan 21st 2014
1 decade ago