Hello Etienne, - Page 5

Evan M · ‎02-26-2016

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.

Mathew Huynh · ‎10-20-2016

Hello Etienne,

The most recent filter i've been deploying 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");

}

.

---

Using the content_types.xml can cause false positive usages overall

Regards,

Matthew

Mathew Huynh · ‎07-10-2016

Hello Guillaume,

if you could get us a sample of the email with attachment (if a TAC case is being opened) it will help us investigate this further if there is something causing filters to become inactive

Regards,

Matthew

REJR77 · ‎07-14-2016

Hi,

After investigation TAC found a bug: CSCva46798

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

The only warkaround at this time is to use the filter without the variable $MatchedContent

Regards

Romain

exMSW4319 · ‎07-14-2016

So it was trying to write too rich an object through to the log?

It's a relief for me, as we just use the filter to tag the mail with an insert-header action. Anything else happens later on.

The timing of this discovery is fortuitous, as I'd been thinking I should be doing more analysis by log file. Ta for the information.

Mathew Huynh · ‎07-14-2016

Hello Romain,

Thank you for the information.

I will need to edit the filter and remove the $MatchedContent rule until this is corrected.

Regards,

Matthew

T Mac · ‎09-30-2016

Thanks for alerting us to this problem. We also used the $MatchedContent variable, and while we haven't had an actual error logged, we have had matching messages "disappear".

We have a "Macro" quarantine configured on our CSA, and while the message appeared to be delivered there, it is not there. Can anyone tell us where the messages are likely to be hiding? It's extremely concerning that the log shows no final disposition of the message other than a false report.

Extract from mail log:

Sep 2016 18:35:55 (GMT +10:00)  Message 1309982 (421775 bytes) from rrp@v.xyz ready.  
30 Sep 2016 18:35:55 (GMT +10:00)  Message 1309982 contains attachment 'image001.gif'.  
30 Sep 2016 18:35:55 (GMT +10:00)  Message 1309982 contains attachment 'WC MONDAY 10 OCT 2016.xls'.  
30 Sep 2016 18:35:55 (GMT +10:00)  Message 1309982 Custom Log Entry: VBA, Versioncompatible32  
30 Sep 2016 18:35:55 (GMT +10:00)  Message 1309982 matched per-recipient policy DEFAULT for inbound mail policies.  
30 Sep 2016 18:35:57 (GMT +10:00)  Message 1309982 scanned by Anti-Spam engine: CASE. Interim verdict: Negative  
30 Sep 2016 18:35:57 (GMT +10:00)  Message 1309982 scanned by Anti-Spam engine CASE. Interim verdict: definitely negative.  
30 Sep 2016 18:35:57 (GMT +10:00)  Message 1309982 scanned by Anti-Spam engine: CASE. Final verdict: Negative  
30 Sep 2016 18:35:57 (GMT +10:00)  Message 1309982 scanned by Anti-Virus engine Sophos. Interim verdict: CLEAN  
30 Sep 2016 18:35:57 (GMT +10:00)  Message 1309982 scanned by Anti-Virus engine. Final verdict: Negative  
30 Sep 2016 18:35:57 (GMT +10:00)  Start message 1309983 on incoming connection (ICID 0).  
30 Sep 2016 18:35:57 (GMT +10:00)  A new message 1309983 was generated based on message 1309982 by notify filter Macros.  
30 Sep 2016 18:35:57 (GMT +10:00)  Message 1309983 enqueued on incoming connection (ICID 0) from MAILER-DAEMON@abc.xyz.  
30 Sep 2016 18:35:57 (GMT +10:00)  Message 1309983 on incoming connection (ICID 0) added recipient (n@abc.xyz).  
30 Sep 2016 18:35:57 (GMT +10:00)  Message 1309983 is not signed. No domain key profile matches MAILER-DAEMON@abc.xyz.  
30 Sep 2016 18:35:57 (GMT +10:00)  Message 1309983 successfully signed. DKIM abc matched MAILER-DAEMON@abc.xyz.  
30 Sep 2016 18:35:57 (GMT +10:00)  Message 1309983 (2660 bytes) from MAILER-DAEMON@abc.xyz ready.  
30 Sep 2016 18:35:57 (GMT +10:00)  Message 1309983 queued for delivery.  
30 Sep 2016 18:35:57 (GMT +10:00)  Message 1309982 scanned by Outbreak Filters. Verdict: Negative  
30 Sep 2016 18:35:57 (GMT +10:00)  Message 1309982 enqueued for transfer to centralized quarantine Macros (content filter Macros).  
30 Sep 2016 18:35:57 (GMT +10:00)  Message 1309982 queued for delivery.  
30 Sep 2016 18:35:57 (GMT +10:00)  SMTP delivery connection (DCID 796310) opened from Cisco IronPort interface xxx.xxx.xxx.xxx to IP address xxx.xxx.xxx.xxy on port 25.  
30 Sep 2016 18:35:57 (GMT +10:00)  (DCID 796310) Delivery started for message 1309983 to n@abc.xyz.  
30 Sep 2016 18:35:57 (GMT +10:00)  (DCID 796311) Delivery started for message 1309982 to n@abc.xyz to Centralized Policy Quarantines.  
30 Sep 2016 18:35:57 (GMT +10:00)  (DCID 796311) Delivery details: Message 1309982 sent to n@abc.xyz [('from', 'rpp <rpp@v.xyz>')] delivered to Centralized Policy Quarantine.  
30 Sep 2016 18:35:57 (GMT +10:00)  Message 1309982 to n@abc.xyz received remote SMTP response 'ok: Message 34817 accepted'.  
30 Sep 2016 18:36:00 (GMT +10:00)  (DCID 796310) Delivery details: Message 1309983 sent to n@abc.xyz [(\'from\', \'"IronPort Notifications" <MAILER-DAEMON@abc.xyz>\')]  
30 Sep 2016 18:36:00 (GMT +10:00)  Message 1309983 to n@abc.xyz received remote SMTP response '2.6.0 <6943bb$17v8v@mail1.bemta10.messagelabs.xyz> [InternalId=29589474] Queued mail for delivery'.

Mathew Huynh · ‎10-01-2016

Hello Tracy,

On the ESA are you able to check the host 'the.cpq.host' just to see if it is still sitting on the ESA if the centralized quarantine transfer did not completely go through.

From the mail_logs it is showing it was transferred successfully, so we may need to trace it on both sides as well.

Regards,

Matthew

T Mac · ‎10-03-2016

Thanks, Matthew - sorry for the delay replying - public holiday here.

There's nothing there for 'the.cpq.host' now, and think we checked it, and definitely "all" hosts at the time. We've gone past our three day SMTP retry time, so I don't know if we can find it now.

The message log still shows nothing new. We do have SMTP log of the ESA -> CSA transaction, and it also shows the message was received with no interruption.

Fri Sep 30 18:35:57 2016 Info: DCID 796311 >> EHLO smtpsrv10.aaa.com
Fri Sep 30 18:35:57 2016 Info: DCID 796311 << 250-mgr01.aaa.com
Fri Sep 30 18:35:57 2016 Info: DCID 796311 << 250-8BITMIME
Fri Sep 30 18:35:57 2016 Info: DCID 796311 << 250-SIZE 262144000
Fri Sep 30 18:35:57 2016 Info: DCID 796311 << 250-XGET
Fri Sep 30 18:35:57 2016 Info: DCID 796311 << 250-XPUT
Fri Sep 30 18:35:57 2016 Info: DCID 796311 << 250 XMETADATA
Fri Sep 30 18:35:57 2016 Info: DCID 796311 >> MAIL FROM:<rpp@v.xyz> SIZE=421775
Fri Sep 30 18:35:57 2016 Info: DCID 796311 << 250 sender <rpp@smtpsrv10.aaa.com> ok
Fri Sep 30 18:35:57 2016 Info: DCID 796311 >> RCPT TO:<abc@aaa.com>
Fri Sep 30 18:35:57 2016 Info: DCID 796311 << 250 recipient <abc@aaa.com> ok
Fri Sep 30 18:35:57 2016 Info: DCID 796311 >> XMETADATA 1564
Fri Sep 30 18:35:57 2016 Info: DCID 796311 << 354 go ahead
Fri Sep 30 18:35:57 2016 Info: DCID 796311 << 250 ok:  Thanks for the metadata.  Awaiting the message.
Fri Sep 30 18:35:57 2016 Info: DCID 796311 >> DATA
Fri Sep 30 18:35:57 2016 Info: DCID 796311 << 354 go ahead
Fri Sep 30 18:35:57 2016 Info: DCID 796311 << 250 ok:  Message 34817 accepted
Fri Sep 30 18:36:02 2016 Info: DCID 796311 >> QUIT
Fri Sep 30 18:36:02 2016 Info: DCID 796311 << 221 mgr01.aaa.com
Fri Sep 30 18:36:02 2016 Info: DCID 796311 close

To be honest, I'm still concerned messages can "disappear" even due to a bug or misconfiguration. If we saw a "drop" or "reject", I'd be happier. I don't know whether it's worth opening a support request, since I can't see a log that might help us in relation to a quarantine that isn't the EUQ.

Mathew Huynh · ‎10-04-2016

Hey Tracy,

This is the first i've ever heard of emails disappearing when it should be transferred to the quarantines.

I would strongly recommend opening a TAC case with us so we can assist you in tracing some of these emails to find out what has happened.

Possibly could have been transferred between quarantines, but we'll need more insight into this for you.

Regards,

Matthew

Paul Cardelli · ‎03-28-2016

I also recommend doing a Quarantine-Duplicate just before you strip the attachments, just incase you get a one off legitimate important document you need to recover.

You can still add a disclaimer text, and strip the attachment.

Emre.Koca · ‎04-03-2016

we use filter also, and it works great.
the trouble we have now is that we are also working internally with macros and receive legal macro files from our customer so we must configure exceptions.

is there a possibility to proof the file tag information / file attribute information of the macro?

we cannot proof the filename because it is changing every time.

Mathew Huynh · ‎04-03-2016

Hello Emre,

With this filter, we're unable to determine which attributes in a macro can be deemed as malicious ; thus this filter was generated with a disclaimer that it'll stop all macro enabled office type attachments.

In terms of exception lists however, i would suggest to:

1) Create a new incoming mail policy

2) Add the senders which should be exempted from the macro content filter and order it above your other ones.

3) Enable all the same services are your DEFAULT (or other policies) but on the content filters, enable all content filters required except the macro content filter so no macro filtering action will take place for these enders.

Regards,

Matthew

christoph.kaegi · ‎09-07-2016

Hi folks

I am testing a similar filter at the moment, which works to our expectations. However: How would we go about detecting office files within ZIPs?

The Book "eMail Security with Cisco IronPort" only tells that the ESA is capable of looking into archives but it doesn't go into detail how to build a message filter to detect office extensions inside ZIPs.

Kind regards

Chris

christoph.kaegi · ‎09-07-2016

Nevermind...

Found out, that the message filter discovers the files, regardless if they are plain attachments or inside ZIPs.

Chris

Mathew Huynh · ‎05-31-2016

Hello Everyone,

I just wanted to send another quick update to this thread.

I came into some samples to do some additional testing with and I have edited this filter that i initially shared.

This filter has a few minor edits only.

I would recommend before deploying this in full production, please understand the purpose of this filter and run some tests in a lab setup if you could.

However from my tests, it has not stopped any non-macro enabled document files as yet.

It will essentially also stop RTF's with macro enabled and also properly match some docx files which I had seen missed prior from testing.

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

I hope that this will help some other users with their own customized filters they have made branching off this.

From my testing results:

.doc enabled macros -> blocked

.docx enabled macros -> blocked

.rtf enabled macros -> blocked

Standard docx -> allowed

Standard doc -> allowed

standard RTF -> allowed

Regards,

Matthew

Block Office documents containing macros