Wandering Thoughts archives

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 .rars that we could successfully examine had .exes 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.

AttachmentTypesFromZen2017-12 written at 00:52:18; Add Comment

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 .jars in .zips 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.

ZipfileSingleFileTypes-2017-12 written at 01:32:47; 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.