We 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 receives the email from 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 reagan.com, 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, or maybe because Google does a better job in filtering phishing attacks, but the end result is that Gmail users receive less phishing attempts.
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 infrastructure, 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: The field that Gmail uses in its SPF-check and and is used for spear phishing and impersonation analysis
2. From: 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 indicate 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 (indicated in the X-Auth-Id field) and that all tests pass successfully: in this sense, 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. Any actual reply from the recipient, however, would 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 search in Google's reporting system reveals that they don't see SPF vulnerabilities as critical. We assume that this issue is not prioritized to be fixed. If we hear differently, we will update this blog.
What Can I do?
This is an example of phishing where the end-users can do nothing to prevent an attack. 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.
Contact Sales 
