Wandering Thoughts archives

2017-02-25

A single email message with quite a lot of different malware

This is the kind of thing where it's easier to show you the log messages first and discuss them later:

1chbMp-0007UF-Jw attachment application/msword; MIME file ext: .doc; zip exts: .rels .xml[3] none
1chbMp-0007UF-Jw attachment application/msword; MIME file ext: .doc; zip exts: .rels .xml[3] none
1chbMp-0007UF-Jw attachment application/msword; MIME file ext: .doc; zip exts: .bin .png .rels .xml[10] none
1chbMp-0007UF-Jw attachment application/msword; MIME file ext: .doc; zip exts: .eps .gif .rels .xml[10] none
1chbMp-0007UF-Jw attachment application/msword; MIME file ext: .doc
rejected 1chbMp-0007UF-Jw from 59.120.21.181/nie0461@gmail.com to <redacted>: identified virus: CXmail/OleDl-L2, Troj/20152545-E, Troj/DocDrop-RK
detail 1chbMp-0007UF-Jw Subject: [PMX:SPAM] [PMX:VIRUS] Urgent Order..

That one incoming email message had five different attachments and between them they had at least three different forms of malware. It's possible that all five attachments were bad but with some duplication of malware types, so the report we got only identified the unique malware, especially since the first two attachments have the exact same file extensions.

The origin IP address is in HINET (AS3462, hinet.net), which was a big source of issues back in the days when I actively tracked who was the source of issues. It's not currently listed in the Spamhaus ZEN, but it is on Barracuda's blocklist and psky.me (at their 'defer but don't reject' blocking level). Our logs say it HELO'd as 'mail.synclink.com.tw' and to be relaying the email from 85.114.138.127 (which is on the CBL, as well as psky.me at the 'reject during SMTP' level).

Troj/20152545-E is apparently normally a PostScript file, so I suspect that it was found in the .eps file in the fourth attachment. CXmail/OleDl-L2 is claimed to show up in 'OpenDocument' and Microsoft Office files (see also). Troj/DocDrop-RK is apparently normally seen in RTF files, so who knows where it lurks in this set of MIME attachments.

SingleEmailMuchMalware written at 18:26:47; Add Comment

2017-02-13

What file types we see inside singleton nested zipfiles in email

Earlier, I wrote about how email attachments of a single .zip inside another zip are suspicious. Given that the .doc malware using them has come back, today I feel like reporting on what file types we've seen in such cases over the past nine weeks.

(I'm picking nine weeks because we rotate this particular logfile once a week and it's thus easy to grep through just nine weeks worth.)

So here are the raw numbers:

  2292 inner zip exts: .js
  1261 inner zip exts: .doc
   606 inner zip exts: .lnk
   361 inner zip exts: .wsf
    15 inner zip exts: .jse
     5 inner zip exts: .exe
     1 inner zip exts: .txt
     1 inner zip exts: .scr

Of these 4542 emails, 3760 came from IP addresses that were listed in zen.spamhaus.org. In fact, here is the breakdown of how many of each different type were listed there:

  2051 inner zip exts: .js    (89%)
  1101 inner zip exts: .doc   (87%)
   386 inner zip exts: .lnk   (64%)
   214 inner zip exts: .wsf   (59%)
     4 inner zip exts: .jse   (27%)
     3 inner zip exts: .exe   (60%)
     1 inner zip exts: .scr  (100%)

The .jse extension is Javascript (.js) under another name. .wsf is a Windows Script File. .lnk files are Windows shortcuts, but get abused in malware as covered eg here (or the interesting live scam covered here). And .scr is a Windows screensaver, which can also contain all sorts of executable code.

There's nothing really surprising here; it's basically a greatest hits collection of ways to run your own code on reasonably modern Windows machines (apparently .bat and .com are now too old for most things). Since the .lnk files are not with other files, they're probably being used in the way mentioned here, where they run Powershell or some other capable tool with a bunch of command line arguments that pull down and run a nasty thing.

I don't know what to make of the variance in Zen listings between the various file extensions. I suspect that it has something to do with how big and broad a malware campaign is; if a campaign is prolific, its sending IPs are probably more likely to trip the detection for DNS blocklists. It seems at least reasonable that campaigns using .doc and .js malware are more prolific than the others; they certainly send us much more stuff.

NestedZipfileTypes-2017-02 written at 01:56:05; Add Comment

2017-02-09

Malware strains may go away sometimes, but they generally come back

I have a little confession. Last Tuesday I wrote about how we'd started rejecting .doc files in nested zipfiles. Although I didn't mention it in the entry, we did this because we'd seen them dominate our detected malware attempts over the weekend (with everything being identified by Sophos PureMessage as 'Mal/DrodZp-A'). Well, guess what? The moment we added that new rejection rule, all of those .docs in .zips in zipfiles vanished, with not one to be seen for our new rule to reject.

On the one hand, in theory this didn't matter; as I wrote, singleton nested zipfiles are suspicious in general and we had definitely not seen any legitimate cases of this sort of email. On the other hand, in practice we don't want to have rejection rules for everything we've seen once, because every rejection rule is a little bit of complexity added to our mail system and we want to keep the complexity down to only the things that are really worthwhile. With malware, there are always more things we could be looking for and rejecting on, so we have to draw the line somewhere; otherwise we could be playing whack-a-mole against obscure malware for months and building up a towering mass of complexity in the process. So it wasn't a good feeling to think that I might have written in a useless rejection rule and maybe I should go back in and take it out.

I won't say that I shouldn't have worried about it, but I can say that I don't have to any more. Starting on February 6th, whatever malware was sending this stuff our way came roaring back (well, roaring for our traffic volume); we had 30 rejections on the 6th, 59 on the 7th, and 38 on the 8th. Just over 93% of these were from IPs listed in the Spamhaus ZEN aggregate DNSBL, which suggests that we probably rejected a bunch more that were sent to people who had opted in to DNSBL based rejection (which happens at RCPT TO time, before we receive the message and start scanning MIME attachments). Whatever strain of malware is responsible for sending these things out may have temporarily turned its attention away from us for a while, but it's back now, at least for a while.

I suppose this really shouldn't surprise me. We've seen that MyDoom is still around and there's no particular reason why a malware attack vector should stop being used as long as it's even vaguely working. Spam (malware included) comes and goes based on where the sending attention is focused today, but it's very likely to come back sooner or later. And even if a particular strain of malware is wiped out totally (by taking over its command & control infrastructure or arresting the people behind it or the like), I expect that any respite is only temporary. Sooner or later someone will come along to pick up the pieces and revive the attack techniques and address lists for their own benefit, and we'll get hit again by something that looks very much like the same old thing.

MalwareComesBack written at 02:20:23; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.