Block Office documents containing macros

[Evan M]

Is there any way to block office document types that contain macro's in this?  The most recent cryptolocker variant (Locky) contains macro's which makes it more challenging to intercept.  Blocking all office document attachments entirely isn't considered to be very business friendly.

[exMSW4319]

Hi Matthias. My comment over RTF was more of an observation to the forum that RTF can be exploited in this fashion so should probably be included, if the attachment-binary-contains rule is not tricked by the obfuscation.

I was more interested in the reasoning behind the second part of the opening clause of that condition. If I read it correctly, you want your appliance to run some quite expensive checks on any attachment that is not a document.

Regarding the types to include in the opening filename condition, I was thinking that all of the published macro-bearing suffixes could be in an Else branch or separate filter that inserts the X-Macro header without further condition.

[matthias.muench]

my main problem here is: i dont have any "bad"-RTF-Files to take a closer look...

any ideas?

[exMSW4319]

I'm presuming that the RTF obfuscation is nothing more sophisticated than renaming a DOC as RTF. The recipient's class then says "load RTF using Word", and Word simply opens the RTF as a Word document rather than squawking about a bad conversion. Macro support is all ready to go, and I've seen Troj/DocDl (Sophos) variants with the usual picture inside telling recipients they'll have to turn macros on in order to see the document and explaining how to do it.

[matthias.muench]

as far as i can test it:

i renamed a existing "word-with-macro" file to rtf and sent trough the appliance --> filtered. so i would say the renaming thing should be done. Any other approach?

[Mathew Huynh]

To this note as well;

When you rename a doc or docx containing a macro to RTF or to another filename, the binary information within it may not be 'complete' in the sense that it's of the true exploited document as it would retain the original binary information after the rename. So it may capture your renamed files, but if someone exploited an RTF with macros or different file by creating it and source is RTF and not a renamed doc/docx you may get a different result.

If actual samples are available that can be analyzed, then additional conditions can be added to match them I would say.

Regards,

Matthew

[exMSW4319]

I'm working on the premise that true RTF attachments aren't dangerous beyond the "click URL to win" attack, dressed up in whatever social engineering will be effective.

Yes, defences that are analysing for Word threats and aren't misled by the renaming should still spot the danger.

I'm watching developments downthread with considerable interest, as so far the code is only catching simple forms of the original DOC threat for us.

[Paul Cardelli]

Thank you for this post and those that followed. I have been catching several viral Macro Attachments that would have otherwise been just simply retrospect with AMP. Now it seems like we are catching and then releasing a very few false positives.

I was wondering if anyone is sending notifications to the sender or receiver, to let them know their message may be delayed due to a Macro detected in the attachment? 

[Mathew Huynh]

Hello Paul,

I've worked with several companies where they needed that requirement and we did use it.

We informed the end recipient that their email with $Subject is delayed due to Macro filter matching and to contact the administrator if the email is urgent for release.

There has been very very little false positive matching with the filter i deployed; the only times when FP occurs is some vendors are required to send documents with macros, this is when the flexibility of the mail policies and content filters comes into play so a custom 'skip_macro" type policy is used where the senders who sends macros are able to skip the content filter.

Very little production or CPU impact with notify.

Regards,

Matthew

[Paul Cardelli]

The only issue I have with notifying the user, is that if the message turns out to be viral or spam the recipient will not get the message they are notified about, and they might contact me to find out why.

From the number of messages I have seen this is still a small percentage of messages. I do see value especially if it could be urgent. I would like to train users to be more cautious about opening attachments that could contain macros.

I was thinking adding something similar to the following at the top of the e-mail body for messages with detected Macros, so that if they are released, end users would understand the risk they are taking if opening an attachment from an untrusted sender.

**************WARNING******************

The attachment in this message may contain a Macro. These are a common way for attackers to try and bypass anti-virus and email filtering. Only open such attachments that you are expecting from a trusted source. When in doubt verify with the trusted source, or the Helpdesk.

********************************************* 

[Mathew Huynh]

Hello Paul,

This would be to add a 'header' and use the Text Resource > Disclaimer text
Then adding this to the emails via the content filter:

Content filter to : Add Disclaimer -> Header -> Select that disclaimer created
It will insert this at the top of the email for users.

Regards,

Matthew

[Ken Stieers]

Paul,

Which code are you using, Matthew's or Mathias'?

Ken

[Paul Cardelli]

I have been using  a slightly modified version of Mathias. Not sure what it is doing for performance. It has not captured a to many false positives, but like I said before I do see some retrospects from AMP ending up in my Macro Quarantine. Which tells me I'm probably stopping them from hitting the users inbox at some level.

I have also been more aggressive on type of attachments as well such as scripts and .js files which has cut down on McAfee endpoint detections on malicious artifacts that sometime make it through filters.

[matthias.muench]

whats your Filter? can you add it here?

i had no false-positives for days now, but if you found other match-cases i would be very interested into.

[Paul Cardelli]

The false positive files it is hit are .zip files containing a folder with a 3D graphics files with the extension .tgmlcomponentArchive

Below is the filter I'm using:

MacroFilter: if ((attachment-filename ==
"(?i)\\.(xls|xlsx|xlt|xla|xltx|xlsm|xltm|xlam|xlsb|doc|dot|docx|dotx|dotm|docm|ppt|pot|pps|ppa|pptx|potx|ppsx|ppam|pptm|potm|ppsm|rtf)$") OR
(attachment-filetype != "Document")) AND
((attachment-binary-contains("(?i)x-vba-macros")) OR
(((attachment-binary-contains("(?i)vba")) AND
(attachment-binary-contains("(?i)versioncompatible32"))) OR
((attachment-binary-contains("(?i)/vba")) AND
(attachment-binary-contains("(?i)[Content_Types].xml"))))) {
                 log-entry("$MatchedContent");
                 insert-header("X-Macro", "True");
             }

[Mathew Huynh]

Hello Matthias,

The filter i deployed is the general one at the start of this thread.

The false positives are where the customer I was working with, he receives a lot of excel documents where macros are enabled for their invoicing and inventory; so these got caught and we had to add a macro bypass policy where this filter was not deployed (content filter) for stopping.

Regards,
Matthew