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.

[donald dobbins]

CP'd from notepad:

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

Error:

Invalid Filter: MacroFilter('egg/varsub.py _do_sub|456', "<type 'exceptions.UnicodeDecodeError'>", "'ascii' codec can't decode byte 0x87 in position 1: ordinal not in range(128)", '[egg/filters.py process|10277] [egg/filters.py apply|5226] [egg/varsub.py varsub|573] [egg/varsub.py _do_sub|456]')

Version: 9.7.0-125

[Mathew Huynh]

Hello Donald,

I found your TAC case with Yvonne, you're in good hands on that case as this filter could possibly be a newer issue not yet seen.

I deployed the filter on a 9.7.1 lab device with no issue.

The only thing I can think of from this error is there is something within a sample email which had a code within the attachment that triggered and knocked the filter out of order thus seeing this error on the preceptive (content scanning) filters.

Regards,
Matthew

[Guillaume BARBEROT]

Hi all

one of our customer also reported the filter is deactivating when some email attachment is scanned

i feel it could be the same kind of issue

i don't have final statement and if he decides to open a tac case or not

feedbacks from peeople who opened a tac case would be appreciated !

thanks everybody for sharing your filters and feedbacks on this topic

guillaume

[exMSW4319]

Never seen a filter go off-line like that myself. Currently on Asyncos 8.5.6-106 and considering going forward.

I may be missing something here. Why are some folks throwing expensive attachment-binary-contains tests at modern Office ~m suffix files when the whole point of the M is denote that they contain a macro? Equally, why do I sometimes see the same tests applied to Office ~x suffix files which can't contain macros? Is there an issue with the Office Compatibility Pack that means that those dependent on it have to be wary of these formats? For those of us who have happily moved on from that stage, it would be good to confirm that ~m means macro and ~x means macro-free.

Matthew, I did read that Sophos article on macros and it didn't appear to contain anything to indicate that the file formats did other than what would be expected of them.

[Mathew Huynh]

Hello,

You are correct, on 03 office files it needs to be with the 'm' naming to indicate macro to allow it to open.

The docx was previously added there from the first variant of the filter when we saw large office files and a customer was concerned on docx as well.

However having the 3 extra filenames being checked will have little to no impact on the filter itself, but removing it should be safe to do so.

Regards,

Matthew

[hunglam210]

Hi Mathew, Could this bug deactivate the filter and cause macro contents to get through?  I saw an influx of malicious macro docm attachments today (that was eventually caught by Outbreak_0024531) making it through to our users where this filter was catching these before.  

I removed the $matchedcontent entry and have the following filter now.  Is there any modifications i can make that would've caught this outbreak or do you think it was that bug?

MacroFilter: if attachment-filename ==
"(?i)\\.(dat|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)$" {
if attachment-binary-contains("(?i)vba") {
if attachment-binary-contains("(?i)versioncompatible32") {
insert-header("X-Macro", "True");
}}}

[Mathew Huynh]

Hey Hung,

Yes It was noted on later releases i believe that the log-entry action could cause the filter to get deactivated, i believe this bug was just filed very recently after some users noted this behaviour.

Regards,

Matthew

[hunglam210]

No other modifications to the filter needed?

Thanks for confirming the bug.

[Mathew Huynh]

Hello Hung,

Not to my tests on the filter since discovery of the bug.

my current filter is:

MacroFilter: if ((attachment-filename =="(?i)\\.rtf") AND (attachment-binary-contains("(?i)vbaproject.bin"))) OR (attachment-filename =="\\.(docm|pptm|xlsm)") OR ((attachment-filename == "(?i)\\.(xls|doc|ppt)$") AND

((attachment-binary-contains("(?i)word/vbaProject.bin")) OR ((attachment-binary-contains("(?i)vba")) AND

(attachment-binary-contains("(?i)versioncompatible32")))))

              {

                  insert-header("X-Macro", "True");

              }

.

Regards, Matthew

[hunglam210]

I will test out your improved filter.

Thanks for the speedy response.  

[Guillaume BARBEROT]

Hi all forum users,

sorry for late reply

here is the status regarding message filter deactivation :

=> a Tac case was opened, here is the reply from TAC (senior tac)

[...]Escalation engineer made a code review and could determine the root cause for the application fault: The reason is a problem with the $Matched Content variable substitution in the log-entry() action of the corresponding filter. For your reference, please find it enlisted below:

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

             }

The issue may occur, when multiple matches are being logged and shall be interpreted as ascii, but there is a high byte (above 128) in one of the matches. Escalation engineering could reproduce the issue and filed a new bug as CSCva46798 with title "Matched content variable can cause an exception and invalidate a filter“. For your reference, please find an overview in our Bug Search Toolkit below:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCva46798

Our development team will go ahead and review the new bug. In order to track the progress and be informed once a fix is available, I’d recommend you to save the bug in the bug search toolkit. With this, you subscribe to the Cisco Notification Service, and will receive an automatic notification once there are any news available.

Until a fix is available, the only workaround would be to avoid using the $MatchedContent variable in the message filter action. You could still keep a log-entry to document in the mail_logs that this message filter matched, but without the action variable $MatchedContent.

Apologies for any inconvenience this issue may cause. But I hope the provided information helped!

--

Hi

Hope it helps people here as this thread also helped me !

regards,

Guillaume

----

Rate if usefull !

[dkorell]

I like this much cleaner version than some of the originals I was using. I had no idea that office extensions with an "x" in them couldn't be saved with macros. I also like the idea of catching all office documents with an "m" whether they have macros or not.

[Evan M]

Mathew,

Wondering if you can comment in this version of the filter, which is posted in this thread elsewhere:

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)$") 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")))))
 {
  insert-header("X-Macro", "True");
 }

In particular, these two items:

1) Less specific on vba related matches, opting to just use (?i)vba to catch any reference of vba, not a specific matches in your filter

2) Includes this check: (attachment-binary-contains("(?i)[Content_Types].xml"))

What are you feelings on those differences?

[Mathew Huynh]

Hey Evan,

To be perfectly honest, I believe that vba alone is more than sufficient, the other rules with it is just in an effort to avoid false positive matching.

I would not add [content_types].xml as many .docx (or the later office extensions) even without macros will contain this, I believe someone prior posted that it caused a few FP with this condition checking on it.

Just vba alone would suffice, or using vbaProject.bin

Additionally, i opted against the extreme amount of filenames as I have not yet seen variants of malware in them, but if they are affecting your setup then you can add them - but i cannot be certain they contain the same binary info.

I hope this helps.

Regards,

Matthew

[Etienne Brodard]

Hello Mathew,

Does this filter is the most recent of you ? I hesitate to use it. Currently, we use the following : 

if
//at least one must return true
((attachment-filename == "(?i)\\.(docm|dotm|potm|ppam|ppsm|pptm|sldm|vsdm|vssm|vstm|xlam|xlsm|xltm)$") OR (attachment-filetype != "Document"))

//and at least of of these above
AND ((attachment-binary-contains("(?i)x-vba-macros")) OR //this one
(
((attachment-binary-contains("(?i)vba")) AND (attachment-binary-contains("(?i)versioncompatible32"))) //this one (2 conditions)
OR
((attachment-binary-contains("(?i)vba")) AND (attachment-binary-contains("(?i)[Content_Types].xml"))) //this one (2 conditions)
)
)
{
insert-header("X-Macro", "True");
}

But we have a lot of false positive. thank