Tips to prevent Zero-Day Malware with EOP

I have recently seen a lot of zero-day malware attacks and interestingly, these attacks aren’t even trying to be covert. In these cases, the malware is attached to an email in the form of an executable file and the recipient is asked to run the attachment. Being in the technology works, people like you and me don’t fall for this, but a lot of less technical users do and execute the attachment.

In this article we’ll explore proactive actions that can help prevent zero-day malware from landing in in your employee’s mailboxes.

EOP, and Executables, and Malware, Oh my

Out of the box, EOP does not block executable files. EOP will scan executable files and delete them if malware is detected, but will not block them if the malware scan is clean. This behavior can be both good and bad. From a developers point of view, this allows me to send my programs and cool applications to my co-workers. On the bad side, this will allow zero-day malware to come through email in the form of an attached executable file.

Before we look at the proactive actions, I’d like to touch quickly on the malware filter in Exchange Online Protection. EOP scans messages with three different malware engines that get updated hourly with new definitions. Even mail that has been safe listed by a Transport Rule or IP Connection Filter are still subject to malware scanning, there is no way to turn it off. If any one of the engines makes a match, the default behavior is that EOP will delete the entire message and not notify anyone. Notifications can be enabled for malware detections in the Malware Filter settings in the portal.

For more information on our malware protection in EOP see Anti-malware protection FAQ.

Two Rules in EOP

As part of our Best Practices for Configuring EOP, there are two transport rules that we recommend creating to help prevent zero-day malware from making its way to your users. These rules can be found under the section Set anti-malware options, but I’m going to cover them in more depth here.

Rule 1 – Block Executable Files

The first recommended rule blocks executable content. This rule could be scoped further to only match inbound mail, or to add exceptions from trusted senders, but the screenshot here is a full out block no matter who the sender is.

The predicate Any attachment has executable content is quite powerful for the following reasons.

• It will detect executable content even if the file extension has been changed to something like .txt
• It can detect executable content in compressed files, even if multiple layers exist (ex. Executable is in a zip, which is in a zip, which is in a zip). EOP cannot dig into password protected compressed files, so some customers will setup another rule to block password protected attachments.
  

The following types of executable files are what this predicate (Any attachment has executable content) can detect.

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

This list can be found on the page Using transport rules to inspect message attachments under the section Supported file types for transport rule content inspection.

Rule 2 – Block Dangerous File Extensions

Not all malware comes in the form executable files and so we also recommend the following extensions be blocked.

ade, adp, ani, bas, bat, chm, cmd, com, cpl, crt, hlp, ht, hta, inf, ins, isp, job, js, jse, lnk, mda, mdb, mde, mdz, msc, msi, msp, mst, pcd, reg, scr, sct, shs, url, vb, vbe, vbs, wsc, wsf, wsh.

This would look as follows in a transport rule.

Submitting malware and non-malware back to Microsoft for analysis

If you have received malware that is not being detected by EOP, or have a clean file that is being detected as malware, you can submit those files to Microsoft for analysis through the Malware Protection Center.

Advanced Threat Protection

We recently introduced Advanced Threat Protection, which is a new service that complements Exchange Online Protection. One feature of ATP that can increase detection rates on zero-day malware is called Safe Attachments.

When Safe Attachments has been enabled, EOP will delay the delivery of messages that match the policy for anywhere between 5 and 30 minutes. During this time, EOP will detonate the message attachments in a virtual sandbox and look for malicious behavior like system and registry access. If the behavior is deemed malicious, the attachment and message will be marked as malware.

This is only one of the many features that Advanced Threat Protection brings to the table. ATP was first announced a few months ago and made available for purchase earlier this week on June 1. More information on this service can be found at the above link in this section.

High level flow diagram of ATP

 

Example of Sneaky Malware

To close off, I wanted to share an example of zero-day malware from a case that I recently worked. The attacker spoofed this customer’s domain and sent a message to a large number of internal employees. The message contained a subject line like “Internal Company Communications” and contained a single zip file.

The message asked the recipients to look at the document in the attached compressed file. The zip file contained an executable file, and the sneaky part was that the icon used for the executable file was the same icon that Adobe PDF files use.

Here’s a screenshot of the executable once it was extracted from the compressed file.

If a user hides file extensions in Windows (which I believe is the default setting), they would see the above and would not see the .EXE extension. Looking at the properties we can see the file type.

This customer had many users run the above attachment and had to clean up the damage done by this malware.

Final Thoughts

Being in the tech field most of us don’t fear zero-day malware because we know not to run attachments, however a lot of normal users don’t have this same inclination. The more we can do to prevent zero-day malware, the better protected our networks are. At a minimum, I recommend creating the above two transport rules in your EOP environment. For even more protection, check out the new Advanced Threat Protection service that compliments Exchange Online Protection.

Resources

Anti-malware protection FAQ
Configure Anti-Malware Policies
Using transport rules to inspect message attachments
Submitting malware and non-malware to Microsoft for analysis
Advanced threat protection for safe attachments and safe links
Support Hot Topics - Reducing the threat of zero-day malware

Comments

• Anonymous
  June 10, 2015
  thanks
  
• Anonymous
  June 16, 2015
  Andrew in your explanation of the Malware engine and the fact that it would get delete even if allowed by Transport, this is great to know as I often get confused on the path of the message and what gets examined and or captured where.
  My question is where can I report on how many messages are deleted? I've tried the online reports and Mail Protection for Office2013 reporting along with programing the Malware filter to send me a notification for each inbound message it deletes. But, where can I report on this? Thanks - David
• Anonymous
  June 17, 2015
  We have had lots of zero day virii come through to our Exchange Online mailboxes recently
• Anonymous
  June 26, 2015
  The comment has been removed
• Anonymous
  December 21, 2015
  The comment has been removed