Slipping Past The Guards

There has been a spate of maldocs arriving in user’s inboxes of late, and as the law of averages dictates; someone is going to open one. And one opened maldoc is one too many.

After all the dust has settled: servers taken offline, breadcrumbs followed, logs reviewed and all that IR rigamarole, the real work begins.

Just what is this new fangled maldoc? Why are the detection rates so poor? Why didn’t defense A, B or C prevent this from reaching the user’s desktop?

Down To Brass Tacks

When it comes to a strange Microsoft document, my go-to process is to get a copy over to my FreeBSD workstation where I can dig a bit.

Usually I will just throw oletools at the problem to get a feel for what is going on. Running olevba3 returned the following:

WARNING  msoffcrypto failed to interpret file aP702834.doc or determine whether it is encrypted: Unsupported file format

So I dig deeper:

$ file aP702834.doc 
aP702834.doc: MIME entity, Non-ISO extended-ASCII text, with CRLF line terminators

Ah-ha, that’s different. What I expected was more like:

$ file efax_document_001295.doc 
efax_document_001295.doc: Composite Document File V2 Document, Little Endian, Os: Windows, Version 6.2, Code page: 1252, Author: Windows User, Comments: 436 277 493  436, Template: Normal.dotm, Last Saved By: Windows User, Revision Number: 3, Name of Creating Application: Microsoft Office Word, Create Time/Date: Thu Dec  5 10:15:00 2019, Last Saved Time/Date: Thu Dec  5 10:16:00 2019, Number of Pages: 4, Number of Words: 43655, Number of Characters: 248835, Security: 0

Now I have an MS document, that’s not very Word-like. Something a little more texty. Great, got plenty of tools for that.

$ head aP702834.doc 
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_01D70A5B.97AB0BF0"

This document is a Single File Web Page, also known as a Web Archive file.  If you are seeing this message, your browser or editor doesn't support Web Archive files.  Please download a browser that supports Web Archive.

------=_NextPart_01D70A5B.97AB0BF0
Content-Location: file:///C:/7119E694/aP702834.htm
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="windows-1252"

At this point I fell down a rabbithole of trying to distill any useful bits out of the file that I could use to build a yara rule. I was hoping to be able to then use a ClamAV Milter to stop these cold at the smtp gateway. That however, proved to be time consuming and fruitless and I would be better off just to submit samples to Unnamed Vendor in hopes that they improve their detections in this regard.

What I surmise however is that the BadGuys™ are generating an mht file and renaming it .doc and sending that out. It’s still got badness baked into it, so I’m surprised it’s getting past all the AV folks, but props to the BadGuys™ as they’ve done it again and if you can’t respect your adversary, who can you respect?

Hash it Out

I have a number of samples from the past week or so if you want to check them out in VirusTotal here are the SHA1 hashes:

SHA1 (EV857877.doc) = d8fefbe4240174b1bbcd15319e1472ff6efe7c5d

SHA1 (aP702834.doc) = 67fb25ad90205c46fbb9072210c5fbadb0acbf8a

SHA1 (px838890.doc) = 26a160ce47ab8a624e630689411245f580cec5f7

As of right now, detection rates are still pretty low.

I’ve also added an event in my local MISP instance, so I can share the love. Not running MISP you say? You really should check it out.

Cheers!