This is a guest post from Reid Huyssen, IT Director at the Sheet Metal Workers National Benefit Fund, which manages $5B on behalf of ~100,000 beneficiaries.
For the past 9 years, I’ve led the network and security programs for many small to medium-sized companies. At my most recent gig, as the IT Director of a medium-sized financial institution, one of the questions I get asked the most is: how do you cut down the amount of spoofed email and spam landing in your employee inboxes?
In a perfect world, every administrator would have enough money in their budget for all the email security products they need. Everyone would get a robust email security appliance from a market leader. In a perfect world, it would not cost tens of thousands of dollars.
In the world we live in, there are far more small to medium-sized businesses than large enterprises, and budgets are sized accordingly. The directive for many administrators after budget season is “do more with what you have” and “it will need to work for another year”.
With that spirit in mind – doing more with less and extending the use of your current toolset – I’ll be discussing two basic ways any email-enabled organization can protect against and prevent malicious spam and phishing from being delivered to and from their domains. The first is the configuration of SPF, DKIM and DMARC, and the second is how I’ve implemented custom mail flow rules to identify, filter, quarantine, and mark-up suspicious emails before they land in my employee inboxes. I’ll discuss some of my favorite use cases of mail flow rules, such as identifying sender display name spoofing for anyone in my organization.
Using DNS: The importance of SPF, DKIM and DMARC
SPF (Sender Policy Framework)
SPF allows a domain to publish a list of email server addresses which are used to send mail. If a system receives a message from an IP or hostname not listed in the sender domain’s DNS record, the message is assigned a high SCL (Spam Confidence Level) and likely delivered to the quarantine or the recipient’s Junk folder.
DKIM (Domain Keys Identified Mail)
DKIM ensures that messages are not modified while in transit between sender and recipient systems and that the messages truly came from the sender domain. This is done cryptographically by encrypting the headers, the body, or both, and advertising a public key in DNS. Any modification to the header or body would result in an invalid signature, thus indicating modification of the email content.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
DMARC prevents spoofing the “header from” address by testing that the “header from” domain name matches the “envelope from” domain name found in an SPF check. DMARC also matches the “header from” domain name with the “d= domain name” in the DKIM signature check. DMARC provides an additional authentication layer to, and relies on, SPF and DKIM. DMARC also specifies policies which define how the recipient should treat emails that fail authentication checks.
Layman’s explanation
Instead of getting into how to implement these records, or how they work on a technical level, you can think of it like this:
SPF is the bouncer holding a guest list at the door to a private party – if your credentials are not on the list, you are not getting in. DKIM is the wax seal on the outside of an envelope, stamped with an intricate pattern that only you can recognize, and that cannot be faked – if the pattern looks wrong the envelope is not opened. DMARC is the instructions you give out detailing what to do if a message does not pass SPF and DKIM checks. There are three instruction options: do nothing, quarantine the message, or reject the message outright.
DMARC takes some time and is best implemented in phases. Once you have the record in place, you will start receiving reports from other domains with an XML file containing a list of IP addresses they have received email from that claim to be from your domain. In this phase, you review the reports to identify IP addresses routing mail from your organization. After a few weeks, you should have a good idea of what IP addresses are legitimately sending email from your organization so you can adjust the DMARC record accordingly. The next phases involve making the DMARC policy stricter, instructing receiving mail servers on how to treat maligned messages, i.e. to quarantine them to spam folders, or to drop them without delivery.
These records are tricky to tune correctly when you are first implementing them. The process differs across email providers. You can use third-party tools like DMARCian or MXToolbox and the paid subscription services they offer to get started.
Using Mail Flow Rules
Mail flow rules are an incredibly powerful tool at your disposal - at no additional cost to you. I rely on them heavily in our Office 365 environment to filter common phishing emails directly to quarantine or to a queue for approval before delivery. Below I’ve detailed some of my favorite and most useful mail flow rules, from using keywords and regexes to inserting inline HTML for spoofed display names.
The pictures and code snippets below are for an Office 365 environment, but can be replicated for other mail providers.
Rule 1: Reject or redirect email with “<insert phrase here>” to IT for approval
Example 1
Recently there was a massive spike in spam and phishing with the pattern “Aw:” in the subject line. “Aw:” is short for the German word “Antwort” and is used in German mail clients the same way “Re:” for “Reply” is used in English.
To combat the problem, I created a mail flow rule that redirected any email message with “Aw:” in the subject line to me for moderated approval before delivery. My organization does not have any business in German-speaking countries, so any email with “Aw:” in the subject line is likely malicious.
The rule has since expanded to include any somewhat unique phrases from phishing campaigns. If you can identify patterns in language from a malicious email or a phishing campaign, you can reject the messages or redirect them for approval.
Example 2
“Docusign” or “eFax”. This obviously works best for organizations that do not use these services. The Docusign breach in 2017 led to a lot of malicious spam and was a dangerous time for Docusign users.
Rule 2: Reject or redirect email with the regex pattern matching a Bitcoin wallet address to IT for approval
Some malicious emails extort users for money claiming to have compromising information or video. Most extortion phishing emails request payment with cryptocurrency - usually Bitcoin. Unless your organization uses Bitcoin wallet addresses, it is safe to say that any email containing one is suspicious or malicious.
The regex pattern to match any Bitcoin address is:
^[13][a-km-zA-HJ-NP-Z1-9]{25,34}$
Rule 3: Reject or redirect any email with your organization’s domain name, but coming from outside the organization
If the message is from your domain and isn’t coming from your regular mail delivery IPs or hosts, something could be phishy.
Rule 4: Prepend an HTML banner warning if an incoming email sender’s display name matches the display name of someone in the organization
You may have seen “EXTERNAL MESSAGE” or “EXTERNAL” added at the top of in-line email replies. Some organizations add the banner for all messages sent from outside the organization. I think this desensitizes users since it’s an alert that is seen too often; users stop paying attention and stop seeing the banner. A short phrase like “EXTERNAL” is also easily missed and confusing for under-trained users.
Warnings like the below will take up a larger portion of the screen and are more likely to be noticed, while providing instructions on how to proceed. They are also only displayed when necessary - not on every email.
Unfortunately, this rule creates false positives for people with common names and for people who send email between their personal and work email accounts.
Creating and updating this rule manually would be a pain. Below is part of the script I use to collect user display names and update the mail flow rule accordingly. If you've never used Powershell to manage your Office365 environment, check out this getting started guide and how to connect to Exchange Online via PS.
#Variables for rule name and the HTML banner to mark up matching messages
$ruleName = "External Senders matching Internal Display Names"
$ruleHTML = <insert HTML for banner warning here>
#Variables for checking if the rule already exists, and getting all employee names
$rule = Get-TransportRule | Where-Object {$_.Identity -contains $ruleName}
$displayNames = (Get-Mailbox -ResultSize Unlimited).DisplayName
#if the rule doesn't exist, create it
if (!$rule)
{
Write-Host "Rule not found, creating..." -ForegroundColor Green
New-TransportRule -Name $ruleName -Priority 0 -FromScope "NotInOrganization" -ApplyHtmlDisclaimerLocation "Prepend" -HeaderMatchesMessageHeader From -HeaderMatchesPatterns $displayNames -ApplyHtmlDisclaimerText $ruleHtml
}else
{
#if the rule does exist, update the rule with current employee displaynames
Write-Host "Rule found, updating rule with current employee list..." -ForegroundColor Green
Set-TransportRule -Identity $ruleName -Priority 0 -FromScope "NotInOrganization" -ApplyHtmlDisclaimerLocation "Prepend" -HeaderMatchesMessageHeader From -HeaderMatchesPatterns $displayNames -ApplyHtmlDisclaimerText $ruleHtml
}
Rule 5: Redirect emails with attachment file extensions matching <ws, ps1, msi, reg, vb…> to IT for approval
Aside from disabling macros in Office documents at the Group Policy level, macro-enabled attachments can also be blocked using mail flow rules.
Rule 6: Reject email sent outside the organization of an auto-forward message type received from inside the organization
This is a rule to prevent data exfiltration, protect against insider threat, and backstop a potential internal business email compromise.
Rule 7: Reject any emails with <Cyrillic> letters
Blocking international character sets or encoding is a sure way to reduce spam. Malicious emails also sometimes substitute international Unicode characters as homoglyphs – letters or characters that look similar but are not the same.
Rule 8: Reject any email from or containing links with domain suffixes other than <com, org, net>
If your organization does no business internationally, this rule can be expanded to reject any email originating from outside whatever country where your organization is based.
A list of TLDs (top level domains), including country-code domains, can be referenced at the IANA Root Zone Database.
Tying DNS and mail flow rules together, you might consider creating another layer of protection by adding some TLDs to your internal DNS as zones, redirecting to a black hole (0.0.0.0) or a web server showing a page with an explanation as to why the site is blocked.
Caveats
One of the issues with DNS email security is that many organizations do not implement it or have implemented it incorrectly. These solutions become more reliable as more organizations use them. According to a report from Agari in December 2018, only half of the Fortune 500 use DMARC. Technically, an email DNS security strategy protects other domains from malicious email purporting to be from your domain. Implementing it does not actually block phishing or spam in your environment. If you have SPF, DKIM and DMARC configured correctly, a malicious email may still be delivered if it comes from a domain without these three records. The idea here is to practice good organizational internet hygiene. Be a good neighbor in the cyberhood.
Implement all three records because they build on each other. SPF is the sliding chain lock, DKIM is the deadbolt, and DMARC is the alarm system. You should not feel safe with using only one. The more houses on the block with all three, the safer the street is.
If you are using a cloud email service such as Office 365, DNS email security is generally easier to configure, but leads to additional concerns. For example, if you have SPF configured on an Office 365 domain, any domain on Office 365 can spoof email to be from your domain or organization and it will PASS the SPF check. This is because the SPF record must include a hostname shared by ALL the email delivery servers hosted in the Microsoft cloud.
The point is that DNS security is a confusing and divisive beast. There are constantly changing standards and competing schools of thought for how to authenticate or validate records. For example, MTA-STS is a new mechanism for SMTP relays that can be used to define how your organization handles TLS-secured connections. The SMTP standard does not require encryption, but you can leverage MTA-STS to refuse delivery from a host that does not offer TLS with a trusted certificate. Proponents of DNSSEC (Domain Name Security Extensions, not to be confused with the concept of DNS security) would argue against using MTA-STS with a certificate authority for validation and instead argue for using DANE TLSA DNS certificates. For every article in defense of DNSSEC, there is also one opposed – citing downsides such as its computational expensiveness to deploy, constantly weakening 1024-bit key cryptography, increased centralization, and a reliance on a government-controlled DNS.
Summary
Everyone needs a DNS security strategy for email. Implementing SPF only is not enough. Implementing SPF, DKIM, and DMARC together should be the absolute minimum. If an expensive edge product is on your wish list, you can still do your best to block with the tools you already have.
No cyber defense strategy is 100% secure, and none of these methods will eliminate impersonation, spoofing, phishing, and spam. Your goal should be to increase the cost of an attack enough to make your organization an unattractive target. There will always be holes in any component of a strategy you implement, so multiple layers are needed. Get creative with mail flow rules; find identifiable and unique patterns in phishing campaigns and block them. As an admin, it is up to you to find the balance between ease of administration, convenience, and security that meets your organization’s specific needs and helps you sleep better at night.
