Microsoft365 has two type filter mechanisms, one in Microsoft365 Defender and the other in the exchange mail flow rules. We tested their individual and combined capabilities and were eventually able to send unauthorized file types to the end user.
The Microsoft 365 Type filter provides significant protection against known malware variants, however hackers are increasingly finding new gaps and methods to bypass its native security.
Microsoft365 blocks several file types by default. If you go to Microsoft 365 defender admin center and navigate to “Policies & rules” > “Threat policies” > “Anti-malware” you will see the default policy which is always on:
Open the policy and click on “Edit protection settings”. On the top of the window you will see the Attachment filter:
Clicking on the “Customize file types” link will open the list of files an administrator can block with the attachment filter. A partial view of the list:
Using the web interface, admins are limited to selecting file types from the list. Additional file types can be added to the block list by using the Set-OwaMailboxPolicy powershell cmdlet. As seen above, the policy does not allow exe files. Let’s test it.
For the tests we will be using the windows calculator executable. The mailbox is configured with the above block list, and “Safe Attachments” initially disabled.
Sending the executable as a plain attachment will obviously be blocked, so it was decided to read up a bit on how to bypass the Microsoft 365 type filter. Microsoft shared a post on how to send and receive blocked files (here as well). Among the recommendations:
- Rename the file.
- Using a compression utility, such as WinZip, creates a compressed archive file that has a different file name extension.
The executable file has been renamed to calc.doc
Although recommended by Microsoft as a way to bypass their own filters, it doesn’t work. The attachment was blocked:
Moving on to the second method. I compressed the file into a zip archive:
It worked. The message was received with the zipped executable:
Surely it isn’t this easy to bypass the Microsoft type filter. We tried with a few other executables, and they all passed. Then the same test was performed with mimikatz and it was indeed detected
Why are zipped executables getting delivered but zipped mimikatz isn’t? It seems that the type filter doesn’t work on archived files, but malware scanner does. Lets enable “Safe attachments”, perhaps the detonation process will reach the file in the archive and compare it against the type filter.
Safe Attachments
We went back to the Microsoft 365 defender admin center and navigated to “Policies & rules” > “Threat policies” > “Safe attachments”. And activated it in “Dynamic Delivery” mode.
Immediately after sending the message, the following was received:
Safe attachments is now scanning the file.
The attachment is another email message:
Trying to open the attachment in this message throws an error:
After about three minutes, ATP finished the scan and replaced the placeholder with the zipped calculator executable.
Enabling safe attachments did not cause the type filter to be enforced on the zip archive.
Mail flow Rule
There is an option to block executable content using Exchange mail flow rules. A rule was created to block any executable content for the user:
Apparently mail flow rules are more capable than the anti-malware attachment filter. The mail flow rule has blocked the zipped executable:
Typically, you would not be expecting to find the capability in the Exchange mail flow settings, but it works. An example of this can be seen another step further and embed it in a Microsoft Word document:
The Word document was blocked as well:
We then tried to compress the exe in a rar archive and was blocked as well:
It seems that the executable content filter used by the Exchange mail flow rules is much more capable than the anti-malware attachment filter. As previously mentioned, the anti-malware filter is limited to the types in the list or requires external powershell intervention. What about the Exchange mail flow executable filter? As mentioned here it only supports the following types: exe, dll, vxd, os2, w16, dos, com, pif. Even though it can detect the file if it is embedded or nested, it only finds the above types.
To bypass the filter, I encoded our executable into a batch file:
The script creates the executable from the embedded data and runs it. Batch scripts aren’t allowed by the anti-malware attachment filter, to bypass it I zipped the script. Script delivered:
Added an additional mail flow rule to block bat files:
Resending the bat script in the zip returned the same result, file was delivered to the inbox:
Simply inserting the executable into a zip archive was enough to bypass the anti-malware type filter and a single format jump allowed to bypass the Exchange mail flow rule filter.
Even though we were able to bypass the Microsoft type filters, the way we did it, lowers the likelihood of such an attack succeeding in the real world. An executable attachment requires a single click (I.e it requires the user to click and run the executable). The method we used to bypass the type filters requires more user engagement (two clicks, one to open the archive and another to run the script in the archive) and involves a script dropping a file and running it. The likelihood of such an attack being executed in the real world is significantly smaller than that of a single click exploit and most endpoint security solutions will not allow scripts to drop files and run them.
What does this mean for organizations?
Most employees in an organization have no business justification to receive executable files via email. Blocking executables altogether as email attachments closes this potential vector completely, instead of relying on the anti-malware scanner and detonation detection capabilities.
Instead of blocking all the executables (which aren’t needed) we need to rely on detection engines which inherently have false negatives.
If tomorrow a new variant of executable malware that can evade the anti-malware scanner (no signature yet) and detonation (with some evasion tactics) will be introduced to the world, all the attackers need to do is to add it to a zip archive to be able to deliver it to Microsoft365 mailboxes. A block list that is adjusted to the business needs of the organization and employees, can minimize the attack surface dramatically without harming productivity.
What if there are employees that need to receive executables to do their job? Create a separate policy for them, block executables for the entire organization except them. Knowing that executables can possibly arrive to their inboxes, take the necessary precautions and add specific security layers to these specific users.
FileWall’s Granular Type Filter – Empowering Microsoft 365 Security
The FileWall file type filter allows the Microsoft 365 system admin to define which file types are permitted to enter the organization and which should be blocked. This minimizes the attack surface the organization is exposing via email by eliminating the threat vectors available in certain file types.
The type filter has three main controls:
- On/Off – enabling or disabling the filter functionality on all file types.
- Work mode (Whitelist/Blacklist)- the ability to create pre-set lists of permitted/non-permitted file types for specific users within the organization
- Default settings – suggested default policy by FileWall which includes 204 file types categorized as dangerous, (this includes executable files (exe), windows batch files (bat) and windows links (lnk) and others.
Microsoft type filter only allows the admin to block (blacklist) file types from a list of 86 types. FileWall supports thousands of file types and extensions.
FileWall leverages CDR technology to find embedded and nested files, and applies the type filter settings on them
Set the FileWall type filter to Allow all files except for executables:
FileWall can work even if Safe Attachments is enabled. After safe attachments finishes processing the message, FileWall will start working. Because FileWall enforces the type filter on embedded files the archive was blocked:
Admins can get detailed information in the admin portal about the block reason:
Even if we take the archive and embed it in another document:
The type filter will be recursively enforced on all nested file and the document will be blocked:
What about our batch script example? Adding “bat” files to the black list will cause them to be blocked by the type filter. Even if they are nested or embedded in other files.
