Best Practices for Finding Executable Content

UPDATE (October 14, 2016): We now recommend using the Common Attachment Types Filter to block file types as opposed to using transport rules. Take a look at my updated post, Common Attachment Types Filter, for more information on this new filter.

This article may be common knowledge for some, but it is important to revisit and refresh ourselves on. You may be aware of what content EOP will flag as being executable, or you may not. In either case, I think this is an important topic so sit back, relax, and read on.

Transport Rules

One of our best practices is to create a transport rule which blocks executable content. This would look as follows.

The reason we suggest creating this rule is that it acts as a second line of defense for catching zero day malware. If a zero day attack is missed by the EOP malware filters but is being delivered in the form of an executable attachment, this rule will stop those messages from reaching your end users.

The beauty of this transport rule predicate is that it will also catch executable files that have had their extensions renamed. For example, if the file notavirus.exe is renamed to notavirus.txt and attached to an email, this transport rule will still fire.

If you instead created a transport rule with the predicate, Any attachment’s file extension matches…

This transport rule WOULD NOT fire if a file with a matching extension has its extension renamed. With this rule, if the executable notavirus.exe was renamed to notavirus.txt, this rule would not fire. This predicate should only be used to block extensions that do not fall under what we consider “executable content.”

What is considered an executable?

What EOP considers as executable is nicely documented on TechNet, however it is a little buried. The list of file types can be found on the TechNet page Using transport rules to inspect message attachments. Scroll to the bottom of this article and look for the table under the heading Supported executable file types for transport rule inspection.

To save you a click, the current list is as follows.

If your transport rule is set to look for Executable Content, the above file types will cause the rule to trigger even if their extension is renamed.

Last Words

I mentioned above that one of our best practices is to create a transport rule which will trigger on executable content. I would highly recommend this, along with other great best practices can be found on the TechNet page Best practices for configuring EOP. This page also lists other file extensions that you may wish to block through a transport rule that looks at an attachments extension (see the section Extension Blocking).

Resources

Using transport rules to inspect message attachments Best practices for configuring EOP

Comments

• Anonymous
  January 01, 2003
  Great post, thank you.
• Anonymous
  January 01, 2003
  Hi Fanta, that's correct. Zip files will always be scanned by our malware engine, but if no malware if found, they will be allowed past EOP (unless a transport rule stops them). If you would like to block ZIP files, you'll need to create a transport rules with the predicate "Any attachment --> file extension includes these words." You would then add "zip" to the list of words. You could then set the action of this transport rule to reject, or quarantine, or whatever you would like to happen to zip files.
• Anonymous
  January 01, 2003
  Hi Vivagar, this is possible when you select the predicate "Any attachment has executable content" in a transport rule. When this is selected, the transport rule will look inside a .zip file and if an executable file is found the rule will trigger.
• Anonymous
  February 05, 2015
  A .zip file can content legitimate data. I want a rule to inspect a .zip file and reject executable content. Is it posible?
  
• Anonymous
  March 30, 2015
  Hi,
  
  Since .zip extension is not in the list; may I conclude that are allowed with the transport rule?
• Anonymous
  August 11, 2015
  The comment has been removed
• Anonymous
  August 19, 2015
  Hi Dr. Why. Our transport rules do look inside zip files. Not only in the root, but also many levels deep if there are zip files within zip files. I just ran a quick test, and created a rule to trigger if an attachment contained the extension "bat." I sent a .bat file that was buried in three layers of zip files and the rule triggered as expected.
  
  The exception here, is if the zip file is password protected. In these cases, EOP can't break into the zip file to see what files reside inside.
  
  Something that may address part of your concern, is Common Attachment Blocking (CAB) that will be coming soon to EOP. See this post from today,http://blogs.technet.com/b/eopfieldnotes/archive/2015/08/19/common-attachment-blocking-cab-is-coming-to-eop.aspx.
• Anonymous
  March 02, 2017
  Hi,In all this information about blocking executable attachments, is there a way to know the name of the file that is block?Users always asked me "ok, th file is blocked, but what the name of this file?"I know that we can send a message to the recipient with some variables like %%From%%, %%Subject%%, %%MessageDate%%, etc.But do you know if it'S possible to have a vriable like : %%AttachementName%%???Thanks!
  • Anonymous
    March 14, 2017
    Hi Robert, if you have notifications turned on in your malware filter, the notification will include the file name that was caught. I just ran sent a message with an EXE from my test tenant, and my malware filter sent me the following notification email:Malware filter triggered on this message which was sent from an internal user.--- Additional Information ---:Subject: TestSender: andrew@contoso.onmicrosoft.comTime received: 3/14/2017 2:31:31 PMMessage ID:Detections found: Mail Flow Tester.exe exe
    • Anonymous
      March 30, 2017
      Sorry for the late reply.Thanks Andrew!
    • Anonymous
      January 05, 2018
      Quick follow-up question Andrew. Does the syntax of the "Detections found:" section always indicate why the attachment was removed after the name of the file that was removed? Like in your example :Detections found:Mail Flow Tester.exe exeThe exe just simply means it was blocked due to it's extension and detecting it was an executable and had executable related patterns in it?In my example, it had:Detections found: filename.docm docmSo because it was a word document with a macro it was blocked. Correct?Now it seems the malware engine also checks the contents of the file because when I just renamed a plain ol' text file to have a docm extension, it didn't get blocked. But when I saved a blank word doc as a docm, it DID get blocked again. Is that assumption correct? Thanks for the help!
      • Anonymous
        February 09, 2018
        Hi Perry, we do "true type" detection, meaning that even if you change the extension of a document, we will try and figure out what the real type is. You are correct in your assumptions in the "Detections found" section. That could certainly be more descriptive though and something I plan to discuss internally with the team. Take a look at https://technet.microsoft.com/en-us/library/jj919236(v=exchg.150).aspx. Under the section "Supported file types for mail flow rule content inspection," we list the file types that we can detect, even if the extension is changed.