This is Part 2 of our series on using transport rules as a security tool. Each article will be linked in the table below as they are published:
Spam / Phishing Campaigns
In our previous post, we set up a mailbox so we could copy potential spam or phishing attacks that are making it past our current filter rules. After a few hours, you should have had some data that you could start looking at to get an idea of the types of things your end users are seeing (maybe like the image below). This will help us create rules to begin filtering out what we can, and hopefully we’ll see patterns or key words that can help us do better. Since attackers are always changing their tools, we will need to monitor and evolve our rule sets to address the current methods that we are seeing.
Before we dive into setting up rules, it is important to understand how these campaigns operate. Most people reading this will understand what spam and phishing are, ideas on how to identify them, and sometimes even why the tactics they use are effective (right timing, sense of urgency, etc.). What isn’t as widely understood is how they get created and how they end up in our mailbox. A large portion of these messages are actually sent by kits that are either purchased or rented. While everyone makes a big deal about the markets on the dark web, you can actually purchase these services for very little money by simply joining some Facebook groups… The tools are extremely simple, have built in templates, and are easily configurable so that the attacker can load in custom lists. Some of these can even automate deployment of HTTPS encrypted websites hosted out of Azure blobs to give a sense of legitimacy. These kits or services make it so that an attacker needs little to no technical expertise to pull of these attacks.
Transport rule goodness
I highly recommend giving your transport rules ID numbers (like ID01, ID02, etc.) or something easy to map to folders in the shared mailbox. There are some basic transport rules that you really should consider such as blocking of auto-forwarded messages, quarantine from hostile anonymous email systems, and maybe even a rule to block social media or other services you want to prevent employees from being able to sign up for using their district email. As much as I hate them, I also have rules to prepend banners to messages to let users know an email was external, spoofed our domain, etc.
In my setup, we use several types of rules, ones based on specific words, one that uses regex, one that uses headers, etc. For each of these types of rules, I have 3 separate rules that I use as stages – audit, quarantine, delete. This means the rules quickly add up, so naming them well is very important. This list may give a general idea to go off of:
ID003: Delete – Keywords
ID004: Delete – Regex
ID005: Delete – From header
ID006: Delete – Authentication results header
ID007: Quarantine – Keywords
ID008: Quarantine – Regex
ID009: Quarantine – From header
ID010: Quarantine – Authentication results header
ID011: BCC – Keywords
ID012: BCC – Regex
ID013: BCC – From header
ID014: BCC – Authentication results header
For the delete and quarantine rules, I set them to generate an incident report and have it sent to the shared mailbox. For the BCC rules, I set a message header property (X-TransportRuleID) to the ID number for that rule and then BCC it to the shared mailbox. In the shared mailbox, I have created a folder per each transport rule, and then I set up an Inbox rule for each transport rule to sort the emails into the appropriate folders. For the delete and quarantine rules, the ID numbers are in the body of the message, so it is easy to sort. For the BCC’d messages, the Inbox rules have to look at the header property we set.
We could also do similar things for DLP type content as well as anything else you might need to monitor such as users emailing passwords or other sensitive information. Just keep in mind that we could be exposing confidential information into this mailbox, so plan accordingly!