Mail Flow Rules for Phishing, Ransomware, and Malware
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, behavioural 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.
File Extensions
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:
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.
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).
Email Headers or Footers
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.
Prevent Autoforwarding to External Domains
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:
Depending on your mail service, it may be as easy as checking a box that says "Don't allow users to forward emails outside of the organization." If not, a mail flow rule like should do the job:
If the sender is located inside the organization and the message type is "Auto Forward," reject the message.
You can also add exceptions - if you want users to be able to forward internally, add an exception to the rule:
If the sender is located inside the organization and the message type is "Auto Forward," reject the message except if the recipient domain is @yourdomain.com
There are probably also some service accounts or SMTP relays set up in your organization that may have a legitimate need for autoforwarding. Like a firewall, it's best to explicitly refuse auto forwarding and then manually adding exceptions.
Deny-list Phishing Addresses - Receiving
Almost every day, we receive very generic but targeted phishing attempts. Our school directories are published publicly online, and there are frequent attempts by attackers where they send individual emails to all staff members at a school, and create a gmail account with a generic but unsophisticated spoofed address. For example, if the principal of the school is Barry Allen, and Barry's email address is barry.allen@k12sample.org, the email header from attacker emails may look like the samples below:
On one hand, the most obvious solution is to not publish organizational emails publicly on the web. All security is a trade-off, however, and this risk is usually acceptable to school stakeholders due to the inconvenience of parents trying to quickly find a way to contact their student's teacher having to log in to an LMS or parent communication tool.
One of the ways we help mitigate these attacks is through a pair of mail flow rules:
For the first rule, we create on rule that is a blanket "Deny List - Incoming Messages from Known Phising Addresses." While this is often whack-a-mole, manually inputting addresses as they're reported, we have noticed some patterns in addresses that we feel comfortable enough in blocking. For example, in the sample above, we would add barry.allen.k12sample.org@gmail.com, but also any email that contains k12sample.org@gmail.com as part of the address. In a few cases, where specific principals are heavily targeted, we've asked for what their personal email address is, and then pre-emptively block similar addresses that are not theirs. For example, if Barry Allen's personal gmail is barryallen@gmail.com, and his account has been persistently targeted, we'd block some form of any email that starts with barryallen, with an exception for barryallen@gmail.com.
This rule may look something like:
If sender address includes: [list of addresses], delete the message.
In our case, I like to see how persistent these addresses are, so my mailflow rule is
If sender address includes: [list of addresses], redirect the message to security@mydomain.com.
Deny-list Phishing Addresses - Sending
For the second rule, we duplicate the previous rule, except make it a blanket "Deny List - Outoing Messages to Known Phishing Addresses." While this is an extra step to an already tedious task, it prevents any attempts made prior to the rule from being successful. While there's a really low success rate of these attacks among educated users, I've found a lot of people like to respond back to these emails to say "STOP EMAILING ME" or "Nice try!" or they may pretend to fall for the trick to get a laugh. However, doing so lets the attacker know that they've reached an account that is actively checked and monitored by a real person who can be manipulated into responding. I feel strongly that I don't want my users to respond to this emails, so I'll go an additional step and use a third-party solution, ManagedMethods, that connects to our mail system through an API and will let me search all of my users' mailboxes for emails that meet specific critera, and I'll delete the messages from mailboxes en masse to help prevent responses.
Deny-List Phish IPs
Similar to maintaining a deny-list of phishing addresses, we maintain a deny list of known phishing addresses. While this is a category that's pretty likely to be picked up by your mail service, from time to time we come across lists of known malicious IPs. This usually comes through response to an incident where a suspicious file has made it through to an end user, and we need to investigate it's behavior. This tool will be explained more fully elsewhere, but the site any.run is one of my favorite tools to use. When we get a suspicious file, I log in to Any Run, and it will quickly spin up a Windows 7 virtual environment where I can load a a file or enter a URL, and it will spin up and execute or open the file. In addition to being able to watch what happens on the screen, it logs processes and actions in real time. More importantly, when you conclude the test, it gives you an easy to decipher report outlining any suspicious behaviors or activites, including screenshots from the test, processes, registry events, file activity, network activity, network connections, DNS requests, and potential threats detected. As part of the DNS and network sections, it lists all IPs the session connected to, and rates them as either "whitelisted" (safe), "unknown," "suspicious," or "malicious." In the course of running tests on Any Run, we immediately Deny List any IP that is listed as suspicious or malicious in our firewall, content filter, and email system. Additionally, the folks in our department will often casually come across articles on Twitter, Reddit, etc. that list malicious IPs as part of reports or articles. In short - any where we hear rumors of bad addresses, we manually block connections.
Append 'Possible Spam or Phishing Attempt'
Finally, in a manner similar to our external email headers, we stay on the lookout for spammy, phishy emails coming through our mailboxes. Whenever we see one that has distinctive wording, or if we see phrases come up that are unnatural and likely from a malicious source, we have a mailflow rule that will append the words "Possible Spam" to the front of the email's subject line in the recipients mailbox. This just gives them one more reminder to think critically about anything in their mailbox.
If the message contains these words [manually entered list] in the subject or body, prepend the subject with POSSIBLE SPAM/PHISH