First, most enterprise email systems are going to be monitoring and protecting email accounts based on their own rules and using their own technologies, either detecting evil through signature matching, behavioral characteristics, AI, machine learning, or any of a host of buzz words. However, the level of this protection will depend on your subscription level. If you use Microsoft 365 and you are on an A1 or E1 license, you won't have the same level of protection that you do with an E5 license - and you'll have almost no visibility into your protection. The mail flow rules below are some samples of tools we use to fill in gaps, catch the phish that make it through, or proactively protect our users.
Since Phishing is a prime attack vector for malware and ransomware to make it into your network, som simple mail policies, configured either in your mail service or a third party tool like ManagedMethods, can help stop an attack from gaining a foothold. Depending on your environment and user base, this is infinitely customizable, but some examples would be:
<aside> 📝 Sample 1: If the message has an attachment with a file extension that matches one of these values:
'sldm' or 'ppsm' or 'ppam' or 'potm' or 'pptm' or 'xll' or 'xlam' or 'xla' or 'sltm' or 'xlsm' or 'docm' or 'dotm' ,
Then deliver the message but notify the recipient with the following message: "CAUTION: Do not open these types of files from people you do not know. They may contain macros with malicious code."
This policy is going to notify users of potentially dangerous messages. The extensions in this policy are executable files, scripts, and document formats with enabled macros. If there's a legitimate need for your userbase to send these files via email, this is a fine policy to attach them to. Of course, I've only run into teachers working with macros less than a handful of times in the last 15 years, so it may be good practice and more secure to add some or all of those extensions to a policy like sample 2 below.
</aside>
<aside> 📝 *Sample 2: If the message has an attachment with a file extension that matches one of these values:
'exe' or 'bat' or 'msi' or 'pif' or 'wsh' or 'wsf' or 'wsc' or 'vbs' or 'vbe' or 'vb' or 'url' or 'shs' or 'sct' or 'scr' or 'reg' or 'pcd' or 'mst' or 'msp' or 'msc' or 'mdz' or 'mde' or 'mdb' or 'mda' or 'lnk' or 'jse' or 'js' or 'job' or 'isp' or 'ins' or 'inf' or 'hta' or 'ht' or 'hlp' or 'crt' or 'cpl' or 'com' or 'cmd' or 'chm' or 'bas' or 'ani' or 'adp' or 'ade'
Then reject the message and include the explanation "This email contains an attachment with an unallowed file type (extension).*
</aside>
Managing mail flow rules like the ones above are a good, wide net, but to be totally effective you would need a full time staff constantly searching for new bad file extensions and adding them to the flow. You'd also have to get really paranoid and deny legitimate files types like PDFs and Office documents. This is where it's handy to give users a big, bold reminder to be paranoid about what they receive in the mail by added a warning header to any emails received from outside our mail system. This has been the single most effective tool we've implemented to cut down on happy clickers and make users more mindful of phishing emails. And it took less than 20 minutes to implement.
In our case, we use an email header similar to the message below:
This email originated from outside of our organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
When we first implemented, however, we used the message as a footer in a small font size, so it had almost no impact. Eventually, we changed it to look more like this:
You could also take the concept of headers and file extension monitoring a step further and combine them. For example, to drive home the importance of sample 1 above, you could additionally create a header that says something like: "CAUTION: Do not open these types of files from people you do not know. They may contain macros with malicious code."
Headers like these can be created with simple mail flow rules like the one below:
If the messages comes from outside the organization, prepend the message disclaimer:
CAUTION: This email originated from outside of our organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Some of the sneakiest attackes we've seen have resulted from users whose account credentials were compromised, but they didn't know it. In these cases, the attacker compromises the account and immediately sets up persistence by creating a mailbox rule to auto-forward all of a user's new emails to an external account managed by the attacker. We've had users who've known their account was compromised due to fraudulent charges, and experienced persistent recurrence even after changing their passwords multiple times. In those cases, this was almost always the case. Some have had quite elegant rules set up. In more than one case, we encountered administrators, bookkeepers, or finance employees who has been breached and had personal mailbox rules set up like the message below: