baseStriker: Office 365 Security Fails To Secure 100 Million Email Users

By Yoav Nathaniel, Customer Success Manager, Avanan

We recently uncovered what may be the largest security flaw in Office 365 since the service was created. Unlike similar attacks that could be learned and blocked, using this vulnerability hackers can completely bypass all of Microsoft’s security, including its advanced services – ATP, Safelinks, etc.

The name baseStriker refers to the method hackers use to take advantage of this vulnerability: splitting and disguising a malicious link using a tag called the <base> URL tag.

So far we have only seen hackers using this vulnerability to send phishing attacks, but but it is also capable of distributing ransomware, malware and other malicious content.

How a baseStriker Attack Works

The attack sends a malicious link, that would ordinarily be blocked by Microsoft, past their security filters by splitting the URL into two snippets of HTML: a base tag and a regular href tag. Here’s a short video showing how it works:

Traditional Phish: This html email would be blocked because the URL is known to be malicious.

When scanning this, Office 365 sees the malicious URL, performs a lookup against a list of known bad links, and blocks it. Office 365 Safelink, for customers that purchased ATP, also replaces the URL with a Safelink URL and prevents the end-user from going to the phishing site.

Phish using baseStriker method: This email, however, has the same malicious link presented to the end-user but is let through because the email filters are not handling the <base> HTML code correctly.

In this example, Office 365 only performs the lookup on the base domain, ignoring the relative URL in the rest of the body. Because only part of the URL is tested, it mistakenly appears to not exist in the malicious URL database and the email is let through. Furthermore, Safelinks does not replace the malicious link, and the user get the original malicious link, can click it to get right to the phishing page.

In a nutshell, this attack method is the email equivalent of a virus that blinds the immune system. So even if the attack is already known, Microsoft does not have a way to see it and lets it through.

Are you vulnerable?

We have tested the vulnerability on several configurations and found that anyone using Office 365 in any configuration is vulnerable. If you are using Gmail, you don’t have this issue. If you are protecting Office 365 with Mimecast you are secure. Proofpoint is also vulnerable – if you are using Proofpoint you also have this problem.

Here’s a summary of our findings:

I am using:  Am I Vulnerable to baseStriker?
Office 365  Yes – you are vulnerable
Office 365 with ATP and Safelinks  Yes – you are vulnerable
Office 365 with Proofpoint MTA  Yes – you are vulnerable
Office 365 with Mimecast MTA  No – you are safe
Gmail  No – you are safe
Gmail with Proofpoint MTA  We are still in testing and will be updated soon
Gmail with Mimecast MTA  No – you are safe
Other configurations not here?  Contact us if you want us to help you test it

What can you do?

As of the time of writing, there still is no fix so there’s no configuration you can make in your Office 365. We have notified Microsoft and Proofpoint and will update if we learn more.

Because this vulnerability is already known to hackers, an immediate first step would be to notify your end-users and reinforce the risk of phishing attacks.

We are recommending customers enable multi-factor authentication to make it harder to take over their account. This will not protect from malware and other types of phishing, but will help with credential harvesting.

Finally, for users of Gmail and Office 365, even if you are not vulnerable to this attack, we always recommend adding a layer of email security for malware, phishing, and account take-over to protect from the sophisticated attacks that the default security does not block. As this is not the first attack that has found a way past default security measures and it will not be the last.



  • 5/1/2018: Avanan identified attackers are leveraging a critical vulnerability in Microsoft Office 365 email service that allows them to completely bypass O365 built in security
  • 5/2/2018 11:00am: Avanan reported this issue to Microsoft
  • 5/2/2018 11:00am: Avanan tested Gmail and it does not suffer from this vulnerability
  • 5/2/2018 11:30am: Avanan tested Mimecast and Proofpoint.
    • Mimecast is fine.
    • Proofpoint has the same vulnerability. Therefore, if you use Proofpoint you are not secured. We informed Proofpoint at 11:44am EDT on May 2nd, 2018.

The “Ronald Reagan” Attack Allows Hackers to Bypass Gmail’s Anti-phishing Security

By Yoav Nathaniel, ‎Customer Success Manager, Avanan

Ronald Reagan phishing attack on G SuiteWe started tracking a new method hackers use to bypass Gmail’s SPF check for spear-phishing. The hackers send from an external server, the user sees an internal user (For example, your CEO) and Gmail’s SPF-check, designed to indicate the validity of the sender, shows “SPF-OK.”

Why are we calling this “The Ronald Reagan Attack”? Several of these attacks originated from, a website that offers a private email with the domain name of Ronald Reagan, the 40th president of the United States, encouraging its users to “be a cowboy.”

If you are a Gmail for Business customer and suffer from phishing attacks, you might find some comfort in knowing that the lives of Office 365 users are much worse. Maybe it’s because hackers target Office 365 more, maybe because Google does a better job in filtering phishing attacks, but the end result is that Gmail users get less phishing.

How The Ronald Reagan Attack Works
At the core of the attack is the fact that when Gmail’s anti-phishing layer scans the email for impersonation and performs an SPF check, it looks at one “sender” field in the email header but the sender name presented to the human receiver of the email in the Gmail web interface, is taken from another field in the email header.

There are two fields in the email header that play a role here:

1. X-Sender-Id: This is the field that Gmail uses in its SPF-check and and is used for spear phishing and impersonation analysis

2. From: This is the field that is actually presented to the Gmail user

The result is that the machine that tests for phishing finds this email completely legitimate and passes it to the recipient with no warning. But for the recipient, this shows up as an email from someone else, presumably someone in the organization that they know. The recipient has no practical way to find the actual value of the X-Sender-Id field.

Here’s an example of a real such attack and why it was effective (Numbers explained below):


(1) X-Sender-Id – This is the real sender. It is the most important part of the attack because in fact it is not spoofed. It is well aligned with the server that sent the email.

(2) The “Reply To” header is presented to the end-user but the actual reply goes to a field called “Return-Path” (Field 5 below). This is also spoofed – it uses the impersonated victim name in a domain that doesn’t exist (And indicates the usage of a mobile phone)

(3,4) Authentication-Results, Received-SPF and Arc-Authentication-Results: These are the fields that indicates the receiver’s (Gmail) calculated authenticity of the email. Note that in all tests, the email address from the X-Sender-ID is selected as the identity to test with (As indicated in the X-Auth-Id field) and that all tests pass successfully – the email is ‘authentic’

(5) Return Path: This field is what the mail server would use if the end-user chooses to reply to sender. The hackers spoofed the “Reply To” field with an address that is presented to the end-user but does not exist, however any actual reply from the recipient will be routed to the attacker.

(6) From: This is the actual attack – the email address of the impersonated sender. The field was used nowhere aside from when it is presented to the recipient!

What Is Google Doing About It?
A quick search in Google’s reporting system reveals that they don’t see SPF vulnerabilities as critical. Therefore, not prioritized to be fixed. If we hear differently, we will update this blog.

What Can I Do?
In many phishing attacks we described, we started by the regular ‘educate your users’, ‘suspect every email’, ‘look at the links’, etc. etc.  But this is one examples when the end-users can do nothing. Their email client shows an authentic email of an internal sender and there’s no warning in the email to indicate anything is wrong with it. In this case, you do need another layer of security on top of the default security from Google.