Hi. This is the CEO. Send me a million dollars
How to prevent fake internal emails using DMARC and G Suite Gmail Compliance Rules
One of the most popular scam techniques in the business world is sending emails posing as internal employees (i.e. the CEO or a member of accounting) and requesting a transfer of money or the opening of an attached file. This type of scam and others like it have been growing exponentially the past few years.
The FBI estimates that $2.3 billion was lost on such scams from October 2013 to February 2016 and that from January 2015 to April 2016 they have seen a 270% increase in identified victims and exposed losses. (Krebs On Security) These numbers suggest that email security is an ongoing issue for many companies.
How easy is it to send fake email?
Incredibly easy. Commonly phishers will send an email and fake the from header and/or envelope sender header so that it says it’s from your domain. Usually, the emails are not intended to require a back and forth dialog because the original email either has a malicious attachment or link, which if executed, will achieve their objective. Alternatively, the email may contain all of the instructions that their victim may need, such as the account number which they would like all of your company’s assets wired to.
The name that the fake email is from is usually a real person at your company or a generic name like accounting@alphasights.com. If the phishing email does require a back and forth exchange, the phisher will usually set the reply-to / return-path header to an email address they can receive replies at. This will not be overtly noticeable until the recipient clicks reply and the To field populates with the actual email address that the phisher can receive email at.
There are many free services that allow you to test your susceptibility to fake email delivery. One such tool is https://anonymousemail.me/
After implementing the steps outlined below, fake emails that pretend to be internally sent from within your company should never see the light of day.
What is a company supposed to do with scammers constantly knocking at our doors?
Below are some steps your company can take to ensure it is leveraging modern day email authentication frameworks. *DISCLAIMER*: By no means is this an exhaustive source of everything you could possibly do, but it should give you pretty solid defense against fake internal phishing emails.
Here at AlphaSights, we use G Suite, formerly Google Apps, to host our email. While Google Mail is generally pretty good at blocking spam, it is not able to automatically block fake internal emails out of the box because it doesn’t know what other mail servers, such as MailChimp or Salesforce, are legitimately allowed to send email on behalf of your domain. Ensuring this requires having a proper DMARC record in place.
What is DMARC?
Domain-based Message Authentication, Reporting and Conformance (DMARC), specified in RFC 7489, is a DNS TXT record you can use to tell mail servers what to do with email from your domain that does not pass authentication under either SPF or DKIM. It has the advantage of leveraging both of these pre-existing standards in unison, instead of relying on one or the other.
Wait, what is SPF and DKIM?
SPF and DKIM are two authentication frameworks, also defined in a DNS TXT record, which DMARC relies on in order to determine if an email is properly authenticated.
Sender Policy Framework (SPF)
SPF is a DNS TXT record based authentication framework from circa 2006 that is used to define what IP addresses or hostnames are authorized to send email on behalf of your domain.
The intricacies of SPF are beyond the scope of this post, but I will go over some of the basics. When a receiving mail server gets an email from your domain, it can make a DNS lookup to retrieve your domain’s SPF text record and then check if the mail server that originated the mail belongs to the authorized list of mail servers you have specified in your SPF record. If the sending server is not in the list, it fails SPF authentication.
In your SPF record, you specify a policy for the receiving server to use when it determines that SPF authentication has failed. The policy options are none, soft fail, and hard fail. Originally, it was contemplated that you would try and get to a point where you could confidently impose a hard fail policy, meaning that the receiving server should reject any email from your domain that does not pass SPF authentication.
With DMARC, it is considered a better practice to properly set up your SPF record but leave it as soft fail and instead rely on the DMARC policy to determine what action should be taken.
An example SPF record is a DNS text record like
name: alphasights.com and a value of v=spf1 mx ip4:8.8.8.8 ~all. This record roughly translates to soft fail any email from @alphasights.com that was not sent by server 8.8.8.8.
Google provides easy to follow instructions for making an SPF record that authorizes G Suite to send emails on your behalf.
Also, MX Toolbox has a great tool for analyzing published SPF records.
Domain Keys Identified Mail (DKIM)
DKIM, currently defined in RFC 6376, is a DNS TXT record entry that allows you to prove to a receiving mail server that the email was sent by an authorized mail server and that certain headers, including the from header, were not modified in transit.
DKIM uses public key cryptography to allow the sending mail server to sign parts of the email’s header, including the from field, with a private key and insert the result into the header as a DKIM-Signature field. A corresponding public key is published in a DNS text record. Receiving mail servers can use this public key to decrypt the signature. After decrypting the signature, the mail server can verify that the email was sent by a mail server with the corresponding private key and that the from field in the header was not modified.
Google Apps makes it really easy to setup DKIM for your emails.
DMARC — Putting it all together
DMARC is a 3rd framework that is also based on a DNS TXT record. It creates a unifying policy between DKIM and SPF by instructing a receiving mail server on how to interpret the aggregate result of both SPF and DKIM.
If an email passes either SPF or DKIM then it has passed DMARC. If neither pass then it fails. Like SPF, the policy you define in your DMARC record tells receiving mail servers what they should do when neither SPF nor DKIM pass on an email. The options are “none”, “quarantine”, and “reject”.
DMARC also has additional benefits such as allowing you to specify an email that should receive reports from recipient mail servers outlining how they perceived emails purporting to be from your domain. For example, everyday major mail providers like Microsoft, Yahoo, and Google, email us reports that let us know the percentage of emails they got that said they were from @alphasights.com and what percentage of those passed SPF, DKIM and ultimately DMARC. This gives you great insight into the degree to which others are sending fake emails purporting to be from your domain to parties other than yourself.
DMARCIAN provides a great tool for aggregating and analyzing these xml reports (paid but offers free trial).
G Suite also has instructions for setting up DMARC.
When setting up DMARC you will want to start with a “none” policy and analyze the reports you get back before moving to a stricter policy such as quarantine.
Using DMARC to Block Fake Internal Emails and the Problem with G Suite and DMARC reject Policies
A DMARC quarantine policy is the equivalent of recommending to the receiving mail server that they send the email to the recipient’s spam while a reject policy is the equivalent of recommending they bounce the email.
G Suite’s Gmail now fully honors a DMARC policy of reject and will reject an email that fails DMARC with a reject policy. Annoyingly, G Suite does not provide any record in the admin email reports about emails it rejects based on a DMARC reject policy.
However, a great trick with G Suite is that using two Compliance Rules, you can setup a DMARC policy of quarantine for your own domain publicly but apply a stricter reject like policy for inbound emails to your own domain that purport to be from your domain. The emails will go to an Admin Quarantine (no relation to a DMARC quarantine policy) where admins can review the trapped email to gauge the volume and type of fake internal emails targeting their organization as well as release any legitimate emails. This technique also has the benefit that the end user will never be able to inadvertently find the email in spam and believe it is a real email.
For G Suite customers, I would recommend implementing a DMARC policy in this manner first before moving to a DMARC reject policy.
Configuring G Suite Gmail Compliance Rules
Using two Compliance Rules, you can set all inbound email that fail DMARC to go to an Admin Quarantine. Unlike the DMARC quarantine policy, which should cause a receiving mail server to deliver the failed message to spam, an email that is directed to a G Suite Admin Quarantine never reaches the end user unless an Admin releases it from the quarantine.
Navigate to:
And create a new Content Compliance Rule.
The first rule covers the envelope sender and the second will cover the sender header.
Envelope Sender:
The original sender that was reported during the SMTP communication request. It can be different from the sender reported in the Sender header. It often, but not always, matches the address found in the “Return-path” header.
Sender Header:
The sender’s email address as reported in the “From” header. It can be different than the sender reported in the Envelope sender.
Envelope Sender Rule:
Sender header rule:
The end result allows you to quickly move to a very strict policy for “internal” emails without having to set such a strict policy publicly in your DMARC record that would be applied to emails sent to recipients outside of your company. In fact, you can implement this while using a public DMARC policy of none. This ensures you can maintain a high deliverability rate to external recipients while you tweak your DKIM and SPF settings if you are just getting started. Additionally, the Admin Quarantine gives you tremendous insight into the fake internal email phishing attacks being carried out against your company.
Final Thoughts
While this should give you extremely good mitigation against fake internal emails, there are many other types of phishing attacks to worry about. For example, another common tactic is to fake the email from a similarly spelled domain that isn’t actually real or even controlled by the phisher but uses the name / username of a real person at your organization. ie edward@alphsights.com
In such a scenario, there will either be no authentication settings to fail or the phisher will have set it up so that authentication settings are valid on the similarly spelled domain, and the email will likely deliver to the end user. You can combat this by making compliance rules to specifically send the similarly spelled domains to a G Suite Admin Quarantine, regardless of authentication passing.
Another common tactic is to send the fake email so that it is “from” a well known company or government agency. In such cases you are at the mercy of the company being faked to have made the effort to setup SPF, DKIM, and DMARC so that Gmail can automatically reject or quarantine the email.
The best way to combat phishing emails across the board is through end user training. https://www.knowbe4.com/ (paid) provides a great learning resource that your end users can go through as well as a toolset which you can use to spot check your users and see which ones click on links in fake emails you send using their service. Be warned though that if you make contact with knowbe4 sales team, they will relentlessly follow up with you unless you explicitly ask them not to.
Lastly, there will always be some weird cases where legitimate emails get caught by your DMARC policy. Keep an eye on the reports you get back via DMARC as well as your own Admin Quarantine. These problems typically involve forwarded emails. The most common is when an external person forwards an email back to one of your users instead of using reply.
This happens because some email providers do not rewrite the from headers when forwarding an email which means that as it comes back to your domain as an inbound email, it still appears as if it is purporting to be from your domain even though it is not actually being sent by one of your authorized mail servers. It is also possible for a forwarding mail server to modify the message such that the DKIM signature is no longer valid.
If forwarding problems repeatedly cause certain inbound mail to go to the Admin Quarantine, you can add exceptions to the G Suite compliance rules that you made that match on other reliable parts of the header unique to that recurring situation which will help streamline delivery of legitimate inbound emails. Obviously this is not the cleanest solution and it only helps with mail inbound to you. You may still have problems with outbound mail and external users forwarding your email to other external users.
If external parties forwarding your mail to other external parties is a big problem, you can either leave your DMARC policy at quarantine so that it should at least end up in the end recipient’s spam or change the policy to none, which will still allow you to use the G Suite compliance rules to protect yourself from fake internal inbound emails. Fortunately, there is a new specification on the horizon called Authenticated Received Chain http://arc-spec.org/ that is specifically designed to alleviate the problems caused by forwarded messages and authentication.
If you enjoyed the article and have a keen interest in working on modern stacks utilizing Rails and Ember, we are hiring.
