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.

[matthias.muench]

@mathew Huynh

is there a way to push a feature-request? is something like a "detect-macro"-switch allready planned? i think this is getting more and more essential...

[Mathew Huynh]

Hello Matthias,

There was an enhancement request put forward on this request, however there has not been many customers pushing for this feature and it's currently still open but pending for further information and review.

The enhancement ID is : CSCuu40961

Regards,

Matthew

[matthias.muench]

ok i found the site:https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuu40961/?referring_site=bugquickviewredir

is that correct?

what can we/i do to push more for this feature? I dont see any way on the bug-site?

I think locky has shown that this is a big threat what is not covered by any filter on the ESA.

At least on McAfee Mail-Solutions the have a checkbox to handle all Macros as Threat...

[Mathew Huynh]

Hello Matthias,

To push the feature for development in the upcoming AsyncOS; you would need to reach your Cisco Account Manager to work with you to generate a business case to push to our product team for further assessment.

At this stage we're working with Sophos as well for these types of malware variants.

Regards,

Matthew

[Evan M]

When I provided your filter to IronPort Hosted support, they suggested a modified version as follows:

if (sendergroup != "RELAYLIST|SMA"){
if (attachment-filename == "(?i)\\.(xls|doc|ppt|xlsx|docx|pptx)$"){
if (attachment-binary-contains("(?i)vba")){
if (attachment-binary-contains("(?i)versioncompatible32")))){
log-entry("$MatchedContent");
insert-header("X-OfficeMacro", "True");
}}}}

Adding the sendergroup filter is optional in general, but if inherently trust some of your sendergroups, it was suggested to exclude them from the load associated with this check.

The re-working to nested IF's was indicated to be much better for performance over the original syntax as it would reduce how many messages are checked right off the bat.

Lastly, it was pointed out that the regex used on "(?i)x-vba-macros" and "(?i)vba" is redundant.  Because no string start (^) or end ($) specifiers are used, "(?i)vba" will also cover "(?i)x-vba-macros"

What is your opinion on these changes?  They could also be applied to the expanded filters provided by others in this thread.

[Paul Cardelli]

This looks good, I like the ability to add a trusted sender group to the filter. Better then a dictionary as we can document the sender in the comments. I prefer the nested If statements as it matches a couple other filters I have.

I'll test this out and let you know what I find. I would recommend expanding the extensions to include some of the obvious office macro extensions. 

you had a couple extra )) here is the one I'm using with the changes also using my own sendergroup for exclusion.

MacroFilter: if (sendergroup != "SENDERGROUPFROMHAT"){
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)$"){
    if (attachment-binary-contains("(?i)vba")){
    if (attachment-binary-contains("(?i)versioncompatible32")){ log-entry("$MatchedContent"); insert-header("X-Macro", "True"); }}}}

[Evan M]

I was planning to expand it out to include the changes you and Mathias added, just hadn't gotten to re-working it use.   Was quick and easy to copy/paste what support sent me back as I was just wanting to ask for general feedback on doing it this way, since both came from Cisco employees.

To be honest, I'm not clear on the use of (attachment-filetype != "Document") check and (attachment-binary-contains("(?i)[Content_Types].xml) so am interested in an explanation on those.

The check on attachment-binary-contains("(?i)/vba") should also be redundant as well, as the wider regex of used in (attachment-binary-contains("(?I)vba") should cover that one as well.

[Mathew Huynh]

Hey Paul and Evan,

Yep the (?i)vba should cover a lot of circumstances in looking at those values.

The reason why I excluded the sendergroup rule in the filter was on my very first iteration of this filter, it was originally using sendergroups, then came the requirement of 1-2 recipients in a different sender group also needed to be exempted, then it added the complexity of more mail-from or rcpt-to nested rules inside it and became too expensive for a filter.

Also as the message filter is simply 'flagging' the emails with the header, the sendergroup rules isn't entirely necessary since the action to take on such flagged emails are defined through policies and content filters which will give way to a lot more flexibility in the matching.

Using sendergroups and more within the filter will work if your filter is actually taking action as well, rather than just flagging -- atleast from when I worked this over with other users in their prod environment.

Finally the SMA sendergroup should not be required, as SMA's connecting to the ESA should never go through the workqueue unless there is some quirky mail routing for the ESA to recognise it as a normal external email rather than an SMA connection.

Regards,

Matthew

[matthias.muench]

Hi Evan,

i added the (attachment-binary-contains("(?i)[Content_Types].xml) for all new Office Formats (docx, dotx, xlsx...)  because all of them have "Content_Types.xml" in it.

And i chanched "vba" to "/vba" to reduce false-positives.

[hunglam210]

Is it possible to strip the attachment instead of quarantining the entire email?  If so, how would you write it in the message filter?

I've tried testing the content filter but it's not working as intended when setting action to strip attachment greater than 1 byte if the "X-MACRO" is found in headers.  It's stripping everything ignoring the header condition.

Thanks

[Mathew Huynh]

Hello Hung,

I would use the message filter for flagging rather than taking any actions, as when you need to be more flexible with matching, making everything work with just a message filter can be quite difficult.

However the way I would deploy it is.

Message filter stands as is, where it flags emails where attachments contains macros.

Content filter will run a condition of:

If Header -> X-Macro -> Value: True

Action

Strip attachment by filename .doc

Strip Attachment by filename .docx 

And so on.

So essentially you strip all the document files within the email if there was a macro flag within the email (we won't be able to tell which attachment it may be if there are multiple attachments).

Regards,

Matthew

[pmjoleary]

Hi,

I have been using your message filter fine for the last few days, but last night I received the following alert and since then the filter has stop working. 

The Warning message is:

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

This is a copy of the filter.

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]

Hey Paul,

It looks like a very specific code within the email body structure pushed this filter to be invalidated.

You can re-enable it by going to

CLI > Filters > list > 

Locate the number of the filter

Use "Set"
and set it as active again

Press enter 2x

Commit changes, press enter.

Regards,

Matthew

[donald dobbins]

Hello, I am using this filter and get this error and the filter stops working.  Following these steps unfortunately doesn't work for me as the filter still shows as active, but it is just invalid.  Aside from deleting and re-adding the filter (which is what we have had to do) is there anything we can do to avoid this error? Thanks.

[Mathew Huynh]

Hello Ddobbin,

Possibly some of the syntax was changed due to different language encoding when copy and pasting on different language keyboard options.

Can i ask if you could share the filter you're pasting and errors seen? I'll try to correct it for you.

Regards,

Matthew