In a rather clever attack, hackers leveraged a weakness that allowed them to send a fake email that seemed delivered from Google’s systems, passing all verifications but pointing to a fraudulent page that collected logins.

The attacker leveraged Google’s infrastructure to trick recipients into accessing a legitimate-looking “support portal” that asks for Google account credentials.

The fraudulent message appeared to come from “no-reply@google.com” and passed the DomainKeys Identified Mail (DKIM) authentication method but the real sender was different.

Fake email with Google’s DKIM stamp

Nick Johnson, the lead developer of the Ethereum Name Service (ENS), received a security alert that seemed to be from Google, informing him of a subpoena from a law enforcement authority asking for his Google Account content.

Almost everything looked legitimate and Google even placed it with other legitimate security alerts, which would likely trick less technical users that don’t know where to look for the signs of fraud.

However, Johnson’s keen eye spotted that the fake support portal in the email was hosted on sites.google.com – Google’s free web-building platform, which raised suspicion.

Being on a Google domain, the chances of the recipient to realize they are being targeted are lower.

Johnson says the fake support portal was “an exact duplicate of the real thing” and “the only hint it’s a phish is that it’s hosted on sites.google.com instead of accounts.google.com.”

The developer believes that the purpose of the fraudulent site was to collect credentials to compromise the recipient’s account.

The fake portal is easy to explain in the scam but the clever part is delivering a message that appears to have passed Google’s DKIM verification in what is called a DKIM replay phishing attack.

A closer look at the email details reveals that the mailed-by header shows a different address than Google’s no-reply and the recipient is a me@ address at a domain made to look like it’s managed by Google.

Nevertheless, the message was signed and delivered by Google.

Johnson put the clues together and discovered the fraudster’s tricks.

“First, they register a domain and create a Google account for me@domain’. The domain isn’t that important but it helps if [sic] looks like some kind of infra. The choice of ‘me’ for the username is clever,” the developer explains.

The attacker then created a Google OAuth app and used for its name the entire phishing message. At one point, the message contained a lot of whitespace to make it look like it ended and to separate it from Google’s notification about having access to the attacker’s me@domain email address.

When the attacker granted their OAuth app access to their email address in Google Workspace, Google automatically sent a security alert to that inbox.

“Since Google generated the email, it’s signed with a valid DKIM key and passes all the checks,” Johnson says, adding that the last step was to forward the security alert to victims.

The weakness in Google’s systems is that DKIM checks only the message and the headers, without the envelope. Thus, the fake email passes signature validation and appears legitimate in the recipient’s inbox.

Furthermore, by naming the fraudulent address me@, Gmail will show the message as if it was delivered to the victim’s email address.

EasyDMARC, an email authentication company, also detailed the DKIM replay phishing attack Johnson described and provided technical explanations for each step.

PayPal option abused in the same way

A similar trick has been tried on other platforms than Google. In March, a campaign targeting PayPal users relied on the same method, where fraudulent messages originated from the financial company’s mail servers and passed DKIM security checks.

BleepingComputer’s tests revealed that the attacker used the “gift address” option to link a new email to their PayPal account.

There are two fields when adding a new address and the attacker filled one with an email and pasted the phishing message into the second.

PayPal automatically sends a confirmation to the attacker’s address, which forwards it to a mailing list that relays it to all the potential victims in the group.

BleepingComputer reached out to PayPal about the issue but never received a response.

Johnson also submitted a bug report to Google and the company’s initial reply was that the process was working as intended.

However, Google later reconsidered the issue, recognizing it as a risk to its users, and is currently working to fix the OAuth weakness.