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.
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.
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.