topic Block Office documents containing macros in Email Security

Block Office documents containing macros

Evan M — Fri, 26 Feb 2016 12:07:22 GMT

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.

Hello Evan,

Mathew Huynh — Fri, 15 Jun 2018 15:02:12 GMT

Hello Evan,

I have created a filter with some other customers whom I worked with with a similar situation and we created a filter together to attempt this stop all macro enabled office files by dropping the email if any macro enabled office file is seen. It goes through the use of a Message filter (configured on the CLI).

[Note:] This is a filter I use on my lab environment for testing and deployed, there may be some other filter alternatives or better-written filters but at this stage this one has worked well and went through a few iterations to be what it is now.

[Note2:] This filter is to be deployed at your own discretion, this was written from myself and end users whom I worked with - this filter script is not a officially supported script, please modify it to your requirements.

You can use this filter:

MacroFilter: if (attachment-filename == "(?i)\\.(xls|doc|ppt|xlsx|docx|pptx)$") AND
((attachment-binary-contains("(?i)x-vba-macros")) OR ((attachment-binary-contains("(?i)vba")) AND
(attachment-binary-contains("(?i)versioncompatible32")))) {
                  log-entry("$MatchedContent");
  insert-header("X-Macro", "True");
              }

Then create a content filter to look for this header to quarantine the email.

GUI > Mail Policies > Incoming Content Filters > Add a new filter

Condition -> Other Header -> X-Macro -> Value Contains -> True

Action -> Quarantine to the policy quarantine

Optional Action (Please create the text resource GUI > Mail Policies > Text Resources -> Add a new notification template.)

Action 2 -> Notify -> Define the recipient of notification and choose the template.

Submit this content filter.

Deploy it into your Mail Policies where you want it to be used.

Commit changes.

Then monitor the Policy quarantine going forward.

This was tested against hundreds of macro enabled samples and worked to expectations of myself and the users who went forward to incorporate it.

The reason why i did not just stop it at the message filter with a drop, that is very aggressive and while there are -some- legitimate emails containing macros, it's best to review it.

Regards,

Matthew

I am using Cisco hosted

Evan M — Mon, 29 Feb 2016 14:40:59 GMT

I am using Cisco hosted IronPort and don't currently have CLI access. It doesn't seem like I'll be able to create this content filter through GUI, is that correct?

I believe I can request CLI access via the hosted service, so I may need to do that.

Correct - in order to use the

Robert Sherwin — Mon, 29 Feb 2016 14:58:20 GMT

Correct - in order to use the "attachment-binary-contains", this would be CLI and message filter only. This is not an option for content filters.

-Robert

Hi! i'am new to Ironport

matthias.muench — Tue, 15 Mar 2016 07:31:00 GMT

Hi! i'am new to Ironport (testing at the moment) and i found this thread a few days ago.

There are two problems, the first: it not looks into all potential macro-files (for example *.dotm) so i expanded the list of filenames.

the second: there also seems to be a problem with detecting macros, so i expanded the filterrule.

Finally it looks like it will do its job. Please expand the rule if you can find any other problems/issues, or correct me if i'am wrong 😉

MacroFilterNeu: 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)$") 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");
             }

-Matthias

Matthias, could you please

exMSW4319 — Tue, 15 Mar 2016 09:15:16 GMT

Matthias, could you please expand the first half of that condition?

I parse that as "if one of a series of document types or not a document".

Additionally, I've seen Word malware downloaders masquerade as RTF documents. Word cheerfully loads and runs them as Word documents.

Hi, to get it right:

matthias.muench — Tue, 15 Mar 2016 09:58:29 GMT

Hi, to get it right:

you want me to add *.rtf files to the filename-list like:

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");
             }

Thank you! tested, also works!

Hi Matthias. My comment over

exMSW4319 — Tue, 15 Mar 2016 11:02:18 GMT

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.

my main problem here is: i

matthias.muench — Tue, 15 Mar 2016 11:25:25 GMT

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

any ideas?

I'm presuming that the RTF

exMSW4319 — Tue, 15 Mar 2016 11:59:20 GMT

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.

as far as i can test it:

matthias.muench — Tue, 15 Mar 2016 12:57:59 GMT

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?

Hi, I tested it also. I

olaf.boettger — Tue, 15 Mar 2016 13:09:33 GMT

Hi, I tested it also. I thought the main problem is that the message filter is not "looking into" office attachments. It's simply performing a binary serch.

thats right, but all macro

matthias.muench — Tue, 15 Mar 2016 15:41:31 GMT

thats right, but all macro files i had my hands on have binary readable phrases like:

word/vbaData.xml

word/_rels/vbaProject.bin.rel

word/vbaProject.bin

...and so on...

so imho the ability to search for "vba" is at least better than nothing... but @cisco:i am looking forward to see a checkbox/filetype "makro" 😉

by the way i had a few false-positives today, seems to be more accurate to search for "/vba"

MacroFilterNeu: 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");
             }

So, I was digging through the

Ken Stieers — Tue, 15 Mar 2016 17:31:09 GMT

So, I was digging through the parenthesis party, and want to make sure of the logic...

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")))
     )
)

This first section before the first AND is almost always true... the only time its not true are "Documents" that aren't in the MS list... right?

After the AND, its looking for

"x-vba-macros"

(vba and versioncompatible32

or /vba and content type xml)

Did you mean to leave that slash on the second vba?

Hello Matthias,

Mathew Huynh — Tue, 15 Mar 2016 21:55:20 GMT

Hello Matthias,

Glad to see the filter was altered to your specifications to get it to work to your requirements.

However I must add, the reason why some of the formats were not there as I was testing with some other formats such as .docm which was a macro enabled document file (hence the m) but the binary matching was somewhat different, so i suppose the additional formats you looked into, the second OR clause would be for that one.

Regards,

Matthew

To this note as well;

Mathew Huynh — Tue, 15 Mar 2016 21:59:41 GMT

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

I'm working on the premise

exMSW4319 — Thu, 17 Mar 2016 11:25:22 GMT

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.

Thank you for this post and

Paul Cardelli — Tue, 22 Mar 2016 19:02:21 GMT

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?

Paul,

Ken Stieers — Tue, 22 Mar 2016 19:16:10 GMT

Paul,

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

Ken

I have been using a slightly

Paul Cardelli — Tue, 22 Mar 2016 19:33:28 GMT

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.