Google Exploit Bypasses DKIM Protections to Deliver Realistic Alerts

A security researcher has uncovered a high-impact phishing campaign exploiting multiple vulnerabilities in Google's infrastructure, enabling attackers to send alarmingly realistic emails from legitimate Google domains.

The campaign, initially dismissed by Google as “working as intended,” combines weaknesses in Google Sites and OAuth notifications to craft phishing messages that bypass standard security checks and appear entirely genuine to recipients.

The disclosure came from Nick Johnson, core developer of the Ethereum Name Service (ENS), who was personally targeted by the phishing scheme. Johnson shared a detailed breakdown of the attack on April 16, 2025, in a 20-part thread that has since drawn significant attention. The exploit leverages Google's email signing (DKIM) and its legacy Sites service to create the illusion of a legitimate Google alert, ultimately aiming to steal user credentials through a deceptive login page.

The phishing attempt began with a seemingly authentic security alert email from no-reply@google.com. Because it was DKIM-signed by accounts.google.com, the email passed all authentication checks and appeared in Gmail as a trusted message — threaded alongside legitimate Google alerts. The message linked to a fake support portal hosted on sites.google.com, a Google-owned domain that lends instant credibility. The cloned portal mimicked Google's design and prompted victims to “upload documents” or “view case files,” actions that redirected to a phishing login page crafted to steal credentials.

This tactic exploits two key weaknesses:

1. Google Sites Abuse: Attackers used the legacy Google Sites platform, which allows user-generated content to be hosted on google.com subdomains. Sites supports arbitrary scripts and embeds, allowing phishing pages to convincingly imitate Google's own UI. Crucially, the platform lacks straightforward abuse reporting mechanisms, making takedown efforts slower.
2. DKIM Replay via OAuth Alerts: The attackers registered a domain and created a Google account with the name me@domain. They then built an OAuth app with its name field filled entirely with a phishing message followed by whitespace and a misleading label like “Google Legal Support.” Granting this app access to the me@… account triggered an official Google security alert, signed with a valid DKIM key. Since DKIM doesn't authenticate the SMTP envelope, forwarding this alert to victims retained its cryptographic authenticity.

The Gmail interface, seeing the sender as “me,” displayed the email as being sent to “me” as well — a common Gmail convention when showing mail sent to the logged-in user — further concealing red flags.

This clever abuse of trusted infrastructure effectively weaponizes Google's own security alerts. Johnson reported the issue to Google, but the company initially dismissed it as non-exploitable. However, following increased public scrutiny and a technical analysis by security firm EasyDMARC, Google has since reconsidered and committed to fixing the OAuth abuse vector. Suggested mitigations include altering how user-generated content appears in security alerts, such as prefixing messages with system-generated text and using more descriptive subject lines.

Google Sites, however, remains vulnerable. The platform, which pre-dates modern security best practices, continues to allow script injection and deceptive interfaces. Johnson advocated for Google to disable scripting and embeds entirely on Sites or at least restrict them for public-facing content.

Even if a message appears to come from a trusted domain, users should verify that login pages are hosted on accounts.google.com, not sites.google.com or any other subdomain. Also, look for inconsistencies in the “mailed-by” or “from” headers. If a message claims to be from Google but was mailed by another domain (e.g., privateemail.com), treat it as suspicious.