New MIME multipart technique to avoid SEG detection

I hate to write and English isn’t my native language, but still I decided that I’m going to put some effort into this blog. I plan to work as a CISSP course instructor part-time for a while and one of the goals of this blog would be to give my audience some idea on what typical information security work is, what incident response is, some thoughts on security certifications, careers in the industry, etc. If you are reading this you are most likely aware of recent high-profile breaches and of increased demand for security professionals and probably looking to “break into security” yourself, or already there, but still looking for tips on how to make a better version of yourself in this competitive area. So I plan to fill this blog with some information that could be helpful in gauging if you are really up to this.

So the first post in English here would be about how phishing emails bypass some of the most sophisticated security controls of modern Secure Email Gateways (SEGs) and end up in users mailboxes. In general, it’s pretty hard or even nearly impossible to penetrate well configured enterprise-level front-end email security solutions, but still it happens, because of poor security budgeting or vendors dragging behind, lack of proper configuration. Even if everything is in place and properly configured, it sometimes happens because of the bad guys being very creative.


2016 so far has been a year of soaring phishing trends according to multiple observers, this particular graph is coming from Kaspersky Labs. In addition to increased volumes of phishing emails, I see the bad guys using a somewhat new approach to bypassing secure email gateways (SEGs). Their ultimate task is to get phishing emails delivered to users’ mailboxes without getting detected by any of the security controls we set up on our front-end email servers. More often than I would like they manage to do that. Here I want to dissect a certain technique that lets the bad guys pierce through SEGs and deliver malicious attachments to users.

There are multiple anti-spam techniques that deal with how email gets processed by SEGs, but only a few of them deal with attachments. Analyzing attachments is of critical importance as a malicious email may pass all other security controls (such as reverse DNS lookups, DNS-BL, SPF, Bayesian analysis, etc) just because it could be sent on behalf of a legitimate user whose computer was compromised. Email can even be signed by a valid digital signature of your colleague, but still be malicious as your colleague’s PC could be infected with malware sending multiple emails on user’s behalf. Considering that ~90% of penetrations these days happen because of phishing, this picture may look really grim.

Three main security controls to combat phishing emails with malicious attachments that I use in my work are:

  • manual rules to strip emails from attachments that contain files with following extensions:Js,Scr,Exe,Jse,Msi,Vbs,Vbe,Wsf,Wsh,Ocx,Cmd,Bat,Ps1,jar. Sane people don’t exchange emails with these files attached while the malefactors love them;
  • anti-virus solution that analyses attachments for known malware signatures on an SEG;
  • a sandboxing solution that processes selected file types on virtual machines to perform their dynamic analysis and watch for certain indicators (such as downloading executables and running them from %userprofile%) to determine if the attachment being analyzed is malicious or not.

Now, let’s say that an email with a malicious attachment has a .zip extension, containing a word document with a macro. You can’t really block it on your SEG as you would end up in a false positive hell as too many regular folks send zipped documents to each other, therefore your manual rules are of no use here.

What happens when such an email gets processed by an anti-virus and a sandboxing solution? Here are the screenshots, see yourself.

Here is one of the leaders in SEG segment according to Gartner’s magic quadrant:


Pay attention that “Attachment Names” field is empty. It means that no attachment is detected. Also, note that the anti-spam engine thinks that this email is spammy a little, but the score of 36 is very low and it won’t be enough to prevent it from getting delivered in majority of installations.

Just for reference, here’s how it looks like when my SEG manages to detect an attachment. I was lucky to catch this as I had a few different types of approaches used by the crooks during the same phishing campaign:


Note that there’s a file name in “Attachment names” field and also note, that this email wasn’t continued because it didn’t pass two of the tests, the anti-virus engine and the Bayesian anti-spam engine also flagged it as 100% spam.

So in this case it was crucial to detect the attachment, without such detection this SEG wasn’t able to properly process the first email against the rules dealing with attachments, while it was able to detect the attachment and properly discard it in the second email case.

And here’s what happens when a malformed email gets processed by a sandboxing solution I operate, which is, again, among the leaders in their category:


As you can see the sandboxing appliance can’t catch it as well, thus, making it possible for the bad guys to deliver emails with malicious attachment right to users mailboxes bypassing some of the most sophisticated controls.

The sandboxing solution still managed to detect that these emails had attachments but failed to detect that these attachments were malicious. Most likely this happened because the sandboxing solution checks for archives integrity and this archive failed the integrity check and thus wasn’t analyzed.

I think so because when I tried to extract the malicious file from the archive, rearchive it and send it through the sandboxing appliance for processing it returned an alert on malicious attachment. The sandboxing appliance would detect it as malicious if it processed it, but it didn’t and most likely it is because the attached archive didn’t pass the integrity check.

The attachment itself here was a zipped slightly obfuscated JScript, going out to the hard-coded web-site, downloading a PE executable somewhere into a %userprofile% and launching it. Typically I get W97M/Downloader or JScript downloader dropping Dridex and Locky. But it doesn’t matter as attachments can be different. What matters here is how message is formatted and how MIME headers are used. Let’s take a closer look…

Pretty much every email with attachment out there has a Content-Type header, here’s an example:


Note that Content-Type header has a “multipart” value and a required “boundary” parameter. The value of this parameter is used to split the message into multiple parts and treat them separately. Multiparts can be nested with smaller multiparts residing inside of shell multiparts. This particular one has a nested multipart that contains the attachment:

hidden-attachment-beginning hidden-attachment-ending

Here you see the beginning and the ending of this nested multipart structure. Note that the bad guys did not specify required “boundary” parameter and, therefore, any MIME parser wouldn’t be able to reassemble this attachment properly. Also note that the bad guys specified unknown boundary marks at the end of the message, but these parts are empty.

A base64-encoded part of the message is a typical well-formed zip archive. When I copied this content and decoded it manually I got a .zip with a malicious .js file (or .doc file) inside. The zip passed zip integrity checks. But when MS Outlook (I used MS Outlook 2010 14.0.7166.5000, 32-bit) reassembles the attachment it gets it slightly wrong as it adds a few bytes to the end of the zip archive because it assumes that it’s a multi-part zip that needs to be glued together. The resulting archive is always broken and can’t pass the integrity check because of these few bytes at the end. But it doesn’t matter as Windows Explorer and the latest 7-zip can open it (7-zip opens with a warning though) and let the user launch a malicious .js or .doc file.

This malformed MIME multipart structure causes the SEG to miss the attachment completely. The SEG treats such an email as an email without an attachment. The sandbox appliance recognizes the attachment as it can be seen on one of the screenshots above, but it can’t process it as most likely it reassembles it improperly and the resulting archive doesn’t pass integrity checks.

P.S. And a note on how to fix this. Unfortunately, it’s not something you could do yourself, unless you are the vendor of these solutions. What they should do here is to change their MIME parsing logic with respect to what was described above and make sure that these malformed emails don’t get through detection mechanisms unnoticed.

Leave a Reply

Your email address will not be published. Required fields are marked *