Attackers have successfully impersonated Google in a phishing campaign, sending emails that appear authentic by cleverly reusing legitimate email security signatures. Security company EasyDMARC detailed how attackers exploit the DomainKeys Identified Mail (DKIM) standard using a replay technique. The campaign uses fake subpoena notices to pressure users into potentially compromising their Google accounts.
Exploiting OAuth and DKIM for Deception
The core of the deception involves manipulating Google’s own systems, specifically its OAuth application framework, to generate DKIM-signed emails containing the attacker’s malicious content. As explained by researchers and confirmed through EasyDMARC’s reproduction efforts, the attackers created a Google OAuth app and embedded their phishing message – the fake legal alert – directly into the app’s name field.
When permissions were granted to this app (potentially using an attacker-controlled account on a domain registered via Namecheap and verified with Google Workspace), Google automatically generated a standard security notification email. This notification, sent from the legitimate [email protected] address, included the attacker-crafted text from the app name and was correctly signed using Google’s DKIM signature (`d=accounts.google.com`), using a specific key identifier (selector `s=`).
This legitimately signed notification became the weapon. The attackers captured this email, ensuring the signed headers and body content remained unaltered. DKIM is designed to verify that specific parts of an email haven’t been tampered with since being signed by the sender’s domain. Its verification relies on a public key published in the sender domain’s DNS, corresponding to the private key used for signing.
Bypassing Authentication via Relay and Replay
The attackers then resent this captured, signed email using unrelated third-party mail infrastructure. Analysis suggested systems including Microsoft’s Outlook.com and Namecheap’s PrivateEmail forwarding service were used to relay the message to final targets.
EasyDMARC successfully reproduced this by setting up forwarding rules in Namecheap PrivateEmail, which allowed customizing the `From:` header while relaying the original Google email. The crucial element is that the original, valid Google DKIM signature traveled along with the replayed message through these relays.
Receiving mail systems, including Gmail, perform DKIM checks. Because the replayed message contained an untouched, valid signature from `accounts.google.com`, it passed this verification. This successful DKIM pass, being aligned with the `From:` address domain, subsequently allowed the email to pass Domain-based Message Authentication, Reporting, and Conformance (DMARC) checks.
DMARC policies, which help prevent spoofing, often rely on aligned DKIM or SPF passing. The DKIM replay technique works, as noted by Security Boulevard, because the protocol validates the signed message content itself, not necessarily the path the email took. Thus, the spoofed email landed in target inboxes appearing fully authenticated.
Google Sites Adds Layer of Legitimacy
The final step of the attack directed users clicking the email link to a webpage built using Google Sites. This free website tool enabled the attackers to host their credential harvesting form under a `google.com` URL, adding a deceptive layer of legitimacy. While not an official Google login or support page, the familiar domain likely reduced user caution.
EasyDMARC emphasized in its analysis, “just because the domain looks legitimate doesn’t mean the content is.” This tactic mirrors other recent phishing campaigns, like the Q1 2025 surge in attacks using malicious SVG files, which abuse legitimate file types to evade security filters.
Google’s Response and Wider Context
When the vulnerability related to injecting text via OAuth app names was initially reported, Bleeping Computer says Google’s first response indicated the process was “working as intended.”
However, amid public reporting and the clear security implications, the company shifted its stance. Google confirmed to Newsweek it was aware of the campaign, attributed to a threat actor named “Rockfoils,” had been deploying mitigations, and was developing a fix for the specific OAuth vector exploited.
This wasn’t the first example of DKIM replay being used against a major service; Bleeping Computer also referenced a similar method targeting PayPal users in March 2025 by abusing its gift address feature.
While DKIM itself has mechanisms like timestamps (`t=`) and expiration dates (`x=`) intended to limit the lifespan of a signature, their universal implementation and enforcement across diverse email systems remain inconsistent. This attack specifically highlighted how integrated application functions could be manipulated to generate signed emails containing attacker-controlled content.
Genuine legal processes like subpoenas follow strict protocols and aren’t usually something that arrives from [email protected]. Users receiving unexpected emails demanding credentials or sensitive actions should verify the request through separate, known communication channels, regardless of apparent email authentication success.
