Where email authentication is totally great at stopping phishing – springboard attacks (and filling in the gaps)
As I was saying in my other blog post about email authentication, and how it struggles to stop random IT phishing attacks, there is a type of attack that it is great at stopping - springboard attacks.
What do I mean by a springboard attack?
I use the term in the context of "Business Email Compromise" (BEC). A traditional BEC is where a phisher spoofs your domain, usually a high-ranking executive, and sends email to another high ranking executive or perhaps someone in the Finance or HR departments. The phisher tries to trick the receiver into surrendering sensitive like tax forms, or wire money to an account which is controlled by the phisher. I renamed this to "Exact-Domain" spear phishing because the attacker is spoofing your exact-domain.
A springboard attack is a variant of the Exact-Domain attack; rather than impersonating your own domain, they are spoofing a domain that doesn't belong to you but with whom you do business with.
So, suppose that you are the president of Woodgrove Bank and you are talking to one of your vendors, Fabrikam. Fabrikam provides outsourced payroll services, which is common in the enterprise environment. If a phisher reasonably can guess that there is a relationship between the two companies, and even figures out a way to guess which two people would be talking to each other, then they can impersonate one of the two companies. The phisher may impersonate Woodgrove Bank, send a message to Fabrikam, and trick Fabrikam into taking some action.
For example:
This looks like a BEC, but because the domains are different, I call this a springboard attack:
- Guy Incognito is the president of Woodgrove Bank, and you can see his exact-domain woodgrovebank.com is being spoofed. His email address may or may not be what you see in the picture above, but many people (most?) wouldn't notice, and if you were viewing this on a mobile device, you wouldn't see the email at all. It looks like a regular contact. The phisher got the name of the CEO by browsing the web, getting information off of LinkedIn, etc.
. - The domain woodgrovebank.com has weak authentication records, that is, it doesn't have a DMARC record, and its SPF record (if it has one) is only a soft fail, ~all. Some domains don't publish SPF records at all. That's uncommon in the consumer email space (i.e., trying to send to outlook.com or gmail.com) but reasonably common in the enterprise space.
. - Both of these recipient domains are Office 365 customers. That's not important to this attack, but it is information that can be used later on in the filtering pipeline (which I'll discuss below).
.
BEC is hard to detect with content filtering because the content is so normal-looking, and frequently is grammatically correct as the above example shows. It also comes from IP addresses with neutral or even good reputation. Even though the sending domain is spoofed, the SMTP MAIL FROM may be a spammer's own random domain that passes SPF (though it may not), and because woodgrovebank.com does not have a DMARC record, it cannot be detected as a spoof using regular email authentication techniques.
Thus, woodgrovebank.com has been used as a "springboard" by the phisher to get inside Fabrikam. Just like in regular BEC, a finance person may go ahead and execute a payment if it came from the spoofed CEO, in the case above the finance person may forward the message along to the finance person to send payment to the above account. And what's worse, the email from Fabrikam's CEO (in this case, Joey Joe-Joe Jr. Shabadoo) to the finance or HR department would not be spoofed, it would be an internal message. Joey Joe-Joe Jr. was fooled by the original spear phish, but there would be no way to determine that after he started forwarding it internally within Fabrikam, unless someone got suspicious and asked for the original email and inspected it.
.
Fixing springboard attacks with email authentication
The straightforward fix for springboard attacks is with email authentication. The attack above is an actual attack we saw in the past month with the names changed to fictional brands. However, this is what DMARC was designed to protect right from the beginning - preventing your own brand from being spoofed. Large domains like Paypal or Twitter used to get spoofed all the time by phishers, and their users, who sign up to those services using free email accounts, would keep falling for attacks and losing sums of money, or get hacked and send out more spam.
To stop that, the email industry came up with DMARC. DMARC has its shortcomings, but it does stop spoofing. It works for traditional phishing (spoofing large brands like Paypal), exact-domain spear phishing (CEO-to-CFO where the sending and receiving domain is the same), and exact-domain springboard attacks (CEO-to-CFO where the sender and receiver are different organizations).
So, when I recommend DMARC as a fix to stop your domain from getting spoofed sending "from" you to you, I recommend it not only to protect your own organization, but also to protect others who do business with you. While you may be able to inventory all of your senders and create rules to allow or block various spoofers, others have a much hard time doing this. By publishing no or weak authentication records, you are making it easier for phishers to impersonate you and get inside others' organizations.
.
.
How Office 365 sees the problem
Note: As of this writing, Nov 28, 2016, this protection is under development. I write this blog post to reveal how we're thinking about the problem, it won't necessarily use these techniques because there may be better ways to do it. This is more my own view of how things can be done (even though there's a chance they will be done this way); I write this blog post before the feature is fully deployed because it's important to discuss spear phishing and its variants.
The reason why we came out with our own antispoofing solution (https://aka.ms/AntispoofingInOffice365) is because while DMARC is great, it still suffers from the problem that it is hard to set up. That's we protect your domain with Exact-Domain spear phishing protection.
The next step in this is to address the problem above - I said in #3 that both domains are Office 365 customers. Given that we already inventory who sends as your domain to yourself, it makes sense to extend that logic for customer-to-customer mail, too. Thus, Office 365 can apply similar logic for stopping spoofing if the sending and receiving domains are Office 365 customers.
Thus, even if you don't publish SPF, DKIM, or DMARC (which you should), Office 365 can still make a best-guess as to whether or not the sender is authorized to send on your behalf. You could call it "implicit DMARC" - what would happen if the domain did publish a DMARC record, and didn't come from a source we don't trust?
When detecting an exact-domain springboard attack, we would mark up the message similar to how we mark it up for exact-domain spear phish:
Looking at the message headers would reveal why we think a message is spoofing.
As with Exact-Domain spoofing, inventorying your own SPF, DKIM, and DMARC makes this work better. But if you don't publish it, we'll try to figure out if the source is legitimately or illegitimately spoofing you, if the destination if another customer of ours.
This only works for when the destination is an Office 365 customer, and the MX record points at Exchange Online Protection. If the recipient is not protected by Office 365, your domain can still be used in a springboard attack.
.
.
Closing thoughts
So, as you can see, we're working on protecting your domain from different variants of spear phishing. The industry preaches SPF, DKIM, and DMARC (which I do, too) but we also understand that not every domain has that protection. But we still need to stop spoofing.
We're aware of the problem, and we're working hard on solving it.
I still have a couple of blog posts to write on other variants of Business Email Compromise spear phishing.
Previous: Where email authentication is not so great at stopping phishing – random IT phishing scams