Check Point’s Harmony Email research team disclosed a phishing campaign built on a premise that should worry anyone who treats authentication as proof of safety: the messages were not spoofed at all. They were sent by Google’s own infrastructure, from a genuine Google address, using a legitimate Google Cloud feature exactly as it was designed to be used. Over roughly two weeks, attackers pushed 9,394 phishing emails at about 3,200 targeted organizations across the United States, Europe, Canada, Asia-Pacific, and Latin America, and every one of them cleared SPF, DKIM, DMARC, and Microsoft’s CompAuth checks without friction.
A Feature, Not a Flaw
The abuse path ran through Google Cloud’s Application Integration service, specifically its “Send Email” task, a tool built for legitimate workflow automation: system notifications, alerts, routine internal messaging. Attackers configured that task to fire at arbitrary external recipients, and every message it sent carried the return address [email protected]. That address belongs to Google. It is hosted on Google’s mail infrastructure, signed with Google’s own DKIM key, and sent from IP ranges Google’s SPF record explicitly authorizes. There was no domain to forge, because no domain needed forging.
The lures were built to match the sender: notifications about a new voicemail, a shared document awaiting access approval, a permissions request on a file. Ordinary, low-friction, exactly the kind of message a Google Workspace user gets several times a week and clicks without a second thought. The link inside led to a credential-harvesting page built to capture Microsoft 365 logins, a detail that made the campaign a genuinely cross-platform operation: Google’s mail infrastructure delivering the lure, Microsoft’s ecosystem as the actual target.
Why Every Authentication Layer Said Yes
DMARC checks whether the domain in the From header authorized the sending infrastructure that delivered the message. Here, the From header said google.com, and google.com’s own servers did the sending. SPF passed because the originating IP was on Google’s authorized list, because it was Google’s IP. DKIM passed because the signature was generated with Google’s real private key, inside Google’s real signing infrastructure. Alignment passed because there was no mismatch anywhere in the chain to catch. Microsoft’s CompAuth, layered on top for organizations using Microsoft 365, reached the same conclusion for the same reason: nothing about the message’s technical provenance was fraudulent.
This is a distinct failure mode from lookalike domains or compromised third-party mailboxes, patterns that have both shown up in recent campaigns. Those attacks exploit a gap between what a domain claims and what actually sent the mail. This one closes that gap entirely by using infrastructure the attacker was never supposed to have write access to in the first place, a legitimate automation feature repurposed as a mail relay for anyone who could configure it.
The Broader Pattern This Fits
Security researchers have flagged a growing category of campaigns that route phishing through the notification systems of major cloud platforms rather than around them. A calendar invite, a shared-drive alert, a task-completion email, a voicemail notice: all of these are automated messages that platforms send on a user’s behalf, and all of them inherit that platform’s full authentication trust. When an attacker finds a way to trigger one of those automated sends toward a target of their choosing, they get delivery infrastructure that no amount of DMARC enforcement on the victim’s own domain does anything to stop, because the victim’s domain was never involved.
Google has since restricted the abuse path in Application Integration and stated it is taking further steps to prevent similar misuse. That closes this specific hole. It does not close the category. Any cloud platform with a “send a notification to an arbitrary address” feature is a candidate for the same trick, and there are a lot of cloud platforms with exactly that feature.
What This Means for Your Program
Do not let “authenticated” substitute for “verified” in your triage process. A message passing SPF, DKIM, and DMARC from a major platform’s own domain tells you the platform’s infrastructure sent it. It tells you nothing about whether a human at that platform, or an attacker who found an unlocked automation feature, decided who it went to.
Train users on notification-style lures specifically. Voicemail alerts, document-access requests, and permission notifications are effective precisely because they mimic routine platform noise. A short internal reminder that these message types can carry credential-harvesting links, even from real platform domains, closes a gap authentication cannot.
Push credential capture pages toward phishing-resistant authentication. A Microsoft 365 tenant protected by FIDO2 security keys or platform passkeys is far harder to compromise through a harvested password page than one relying on password-plus-push MFA, which remains vulnerable to prompt fatigue even when the initial lure succeeds.
Report abuse of platform automation features when you spot it, and expect more of it. This campaign exploited Google’s infrastructure this time. The underlying technique, legitimate automation repurposed as a phishing relay, is portable to any vendor with a similar send-on-behalf-of feature, and your own detection rules should assume it will show up elsewhere.
Keep DMARC enforced regardless. This campaign does not weaken the case for enforcement on your own domain. It demonstrates a separate risk category entirely, one that lives inside the platforms you already trust rather than in the gap DMARC was built to close.
The Takeaway
Nothing about this campaign required breaking DMARC, spoofing a domain, or compromising a mailbox. It required finding a legitimate feature that would send mail on Google’s behalf to whoever the attacker specified, and pointing it at 3,200 targets. Every technical signal a receiving server can check came back exactly as designed, because nothing about those signals was ever false. Authentication answers one question precisely: did the claimed domain’s infrastructure send this. It was never built to answer whether that infrastructure was being used the way its owner intended.
Excello Mail gives you continuous visibility into your DMARC enforcement and every source authorized to send under your domain, so you can spot abuse fast and keep your own authentication posture airtight, even as attackers find new infrastructure to exploit elsewhere. Sign up for free to Excello Mail and see exactly who is sending as you, all the time.