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).


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

Comments (12)

  1. 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.

  2. 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.

  3. vivalencia says:

    A .zip file can content legitimate data. I want a rule to inspect a .zip file and reject executable content. Is it posible?

  4. Fanta says:


    Since .zip extension is not in the list; may I conclude that are allowed with the transport rule?

  5. Dr.Why says:

    Hey Andrew – there are a number of common executable extensions that Microsoft does not scan for or consider "Executable Content". These extensions include .cmd, .bat, .js, .jse and .scr. These extensions are commonly used to distribute the notorious cryptolocker
    virus and other related ransom-ware and malware. While these extensions can be blocked manually with a rule, they cannot be blocked if they reside inside a zip file, which is how they are commonly distributed. There is currently no way that I know of (nor
    does MS O365 Support) to block these extensions if they are included inside a zip file. While it is possible to create a rule that will block the content of a zip file, that rule does not look at the file name, but only the contents of the file within. Gmail
    blocks these extensions when they are inside a zip file, why doesn't Microsoft? This seems like a big oversight on Microsoft's part.

  6. 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,

  7. Robert says:


    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%%???


    1. 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: Test

      Time received: 3/14/2017 2:31:31 PM
      Message ID:
      Detections found:
      Mail Flow Tester.exe exe

      1. Robert says:

        Sorry for the late reply.

        Thanks Andrew!

      2. Perry Newman says:

        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 exe

        The 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 docm

        So 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!

        1. 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 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.

Skip to main content