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.
| Type of file | Native extension |
| Self-extracting archive file created with the WinRAR archiver. | .rar |
| 32-bit Windows executable file with a dynamic link library extension. | .dll |
| Self-extracting executable program file. | .exe |
| Java archive file. | .jar |
| Uninstallation executable file. | .exe |
| Program shortcut file. | .exe |
| Compiled source code file or 3-D object file or sequence file. | .obj |
| 32-bit Windows executable file. | .exe |
| Microsoft Visio XML drawing file. | .vxd |
| OS/2 operating system file | .os2 |
| 16-bit Windows executable file. | .w16 |
| Disk-operating system file. | .dos |
| European Institute for Computer Antivirus Research standard antivirus test file. | .com |
| Windows program information file. | .pif |
| Windows executable program file. | .exe |
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.
- Anonymous
- Anonymous
- Anonymous