SEE BELOW FOR UPDATES
Original Post 16.10.2014:
Today, I was working with a nice PSS chap in Microsoft (Hi there Om Prakash Nath!)
We were both working on a problem we were having where transport rules in Microsoft Office 365 were not correctly blocking executable attachments within emails to our clients. This is something of a vital requirement nowadays with the likes of Cryptolocker, and ZIP attachments with SCR scripts and the like.
Bottom line of our problem is that two articles on the web that descibe how this SHOULD work, do not seem to work. In one case a client literally had all their mail blocked when using one method, attachment or not!
The first article we followed was this:
The second this:
Both ended up with all sorts of strangeness, including not working at all and also blocking EVERYTHING for some customers! Not cool at all.
I opened a case with Microsoft, and we worked through the problem. The only sure method we got working correctly was to use Powershell to connect to the tenant and then to run the following command:
REMOVED – SEE BELOW
After about 15 minutes, this worked without fail, including messages that had ZIP attachments with executable content within.
Hope it works for you too!
After more testing, I noticed that some executable attachments, including SCR files, in ZIP’s were still getting through even with the below instructions. I then checked and found that the Office 365 filtering only blocks the following executables, and checks more than just the extension (it checks to see that it is, in fact, an executable).
Below is a list of the extensions that the Office 365 Scanner (as of today) detects with my original command in this post below.
|.rar||Self-extracting archive file created with the WinRAR archiver|
|.dll||32-bit Windows executable file with dynamic link library extension|
|.exe||Self-extracting executable program file|
|.jar||Java archive file|
|exe||Un-installation executable file|
|.exe||Program shortcut file|
|.obj||Compiled source code file or 3D object file or sequence file|
|.exe||32-bit Windows executable file|
|.vxd||Microsoft Vizio XML drawing file|
|.os2||OS/2 operating system file|
|.w16||16-bit Windows executable file|
|.dos||Disk-operating system file|
|.com||European Institute for Computer Antivirus Research standard anti-virus test file|
|.pif||Windows program information file|
|.exe||Windows executable program file|
So, that explains why the SCR gets past the scanner. Its not on the list above…..
To fix this, we are going to need a second rule, and I will shortly post that here in a Powershell command as well! I promise to be back in 48 hours or so….
OK, back as promised. Man, the documentation sucks for this….
Here are the two commands, which you can enter in powershell (and add extensions as you see fit) in the following order…
This is the rule for blocking attachments that have executable content.
New-TransportRule -Name ‘Rule 2 – Block Executable Content MS Standard’ -Priority ‘0’ -Enabled $true -AttachmentHasExecutableContent $True -RejectMessageReasonText ‘Block Rule 2 – Sorry your mail was blocked because it contained executable content’ -StopRuleProcessing $true -SetAuditSeverity Low -SenderAddressLocation HeaderOrEnvelope
This is the rule for blocking attachments that the extension of the file matches whatever you wish below. Each extension should be in quotes, and separates with a comma…..
New-TransportRule -Name ‘Rule 1 – Block Attachments Rule – Extensions’ -Priority ‘0’ -Enabled $true -AttachmentExtensionMatchesWords ‘vbs’,’scr’ -RejectMessageReasonText ‘Block Rule 1 – Sorry your mail was blocked because it contained executable content.’ -StopRuleProcessing $true -SetAuditSeverity Low -SenderAddressLocation HeaderOrEnvelope
It is important to wait about 60 minutes before you absolutely say to yourself “this didn’t work”. The Office 365 filters take some time to kick in, remove themself and add themselves! Give it time, have a cup of coffee and come back and check!