2017-12-19
Attachment types that we see in email from Zen-listed IP addresses
As part of yesterday's entry, I broke down what percent of various sorts of attachments we received came from IPs listed in zen.spamhaus.org. Today I'm going to basically invert the question and ask instead what sort of attachment types we get sent from Zen-listed IPs. As before, I'm going to be using the past nine weeks and a bit of logs, because our weekly log rotation makes it easy to do that.
(Because our attachment type logging comes after our RCPT TO
time
rejections, this is all based on email to people who don't reject
all email from Zen-listed IPs.)
First up we have a collection of attachment types without MIME file names (and thus without MIME file extensions). For these I have to rely on the declared MIME types and sniffed file type information, and they break down like this:
102 [Word XML] 13 application/msword 11 image/jpeg 10 message/rfc822 10 application/xml [either Word or Excel] 6 [Excel XML] 1 image/gif
Possibly this means that I should recurse inside message/rfc822 MIME parts. Some of these were file attachments; others I believe were the sole component of the email message.
Of attachments with MIME file names, the type breakdown is:
1032 .doc 623 .docx 576 .html 545 .htm 308 .pdf 253 .zip 248 .xlsx 170 .xls 109 .jar 90 .jpg 83 .aspx 61 .7z 48 .ace 26 .r11 22 .xz 20 .gz 19 .tar 15 .r00 .png 14 .gif 11 .rar 10 .pdf.gz 6 .iso .arj 4 .pdf.z 3 .txt .jpeg .chm 1 .rtf .r01 .ppsx .lzh .bat
On the one hand, this is a broad assortment with a long tail. On
the other hand, there's some very popular attachment types, especially
Microsoft Word documents. I suspect that if I ground through our
logs to cross-correlate them, I'd discover that a lot of these were
seen as malware. Based on past discoveries, the
.html
and .htm
are likely phish spam, perhaps with some malware
mixed in.
(All of the .rar
s that we could successfully examine had .exe
s
in them and got rejected on that basis.)
Those .zip archives break down as containing:
114 .exe 86 .zip 26 .jar 25 .vbs 1 ".lnk .txt" 1 .com
We rejected all the ZIP archives with .exe
or .vbs
payloads.
The inner .zip files are:
84 .doc 1 .scr 1 .js
It turns out that we rejected all of these. The .scr
and .js
files got rejected by a generic 'in-zip' case, which is perfectly
happy to match nested zips as well as plain zips. The doubly nested
.doc
files have been rejected for some time.
(It turns out that the few nested ZIPs in yesterday's entry that weren't from Zen-listed IPs
must have all been .doc
files.)
PS: That I keep having to check what we're actually rejecting suggests that our attachment type rejection rules are now sufficiently complicated that I should actually write them down, instead of leaving them sort of implicitly documented in the Exim configuration and then trying to remember them (it turns out that I got at least one case wrong in yesterday's entry). Possibly this will cause us to regularize some of them. Probably we won't drop any.
2017-12-18
What file types we see inside ZIP archives with only a single file in email
Earlier this year, I wrote about how email attachments of a single .zip inside another zip were suspicious, and then did a file type breakdown for them. Malware is ever-mutating so nested ZIP archives have gone out of style by now, but instead we're seeing a not insignificant amount of attachments that are ZIP archives with only a single file in them. Today I want to do a breakdown of those file types that we've seen over the past nine weeks or so.
So here are the raw numbers; for some types I've added the percent that were received from IPs listed in zen.spamhaus.org at the time:
434 .exe (26%) 91 .zip (94%) 86 .jar (30%) 43 .vbs (58%) 13 .bat (0%) 6 .com (17%, ie 1) 3 .wsf .pdf 2 .scr .py .js 1 .xls .rkt .rar .pot .jse .hta .eml .docx .csv
(Overall, about 36% of these messages were from IPs listed in zen.spamhaus.org at the time.)
Some of these we reject immediately these days, such as the .exe
and .wsf
cases. Others we probably should, like .js
, .com
,
.vbs
, and .bat
(which we already reject as top-level attachments).
The single nested .zip
cases break down like this:
89 inner zip exts: .doc 1 inner zip exts: .scr 1 inner zip exts: .js
It's somewhat interesting to me that in all cases, there's only a
single file inside the inner zip. Because of past events, we also reject the doubly nested .doc
files. We'll also reject the doubly-nested .js
attachment (because
it's a .js
inside a ZIP archive, even a nested one), but not the
.scr
one.
Unfortunately, what stands out in this list is the nested .jar
files. Partly this is because these days Sophos PureMessage is
identifying all of them as malware, for example CXmail/JarZip-A
(which we saw in an epic case) and also
Mal/DrodZp-A.
Not a single one is making it through all of our anti-spam and
anti-virus filtering to reach our users as presumed legitimate
email.
(It's possible that this identification by Sophos is generic and means very little more than 'a single .jar file inside a .zip with some vague additional threat markers'. This doesn't matter in practice, since the net effect is the same.)
PS: As you might suspect, this entry came about because I noticed
that .jar
s in .zip
s were being rejected as malware and then
decided to go look at the numbers to see if we should be rejecting
them immediately. My current answer is that we probably should be,
along with some other rejections, although there are arguments
against this reaction.