Cybersecurity researchers have disclosed details of a phishing campaign that involves the attackers impersonating legitimate Google-generated messages by abusing Google Cloud’s Application Integration service to distribute emails.
The activity, Check Point said, takes advantage of the trust associated with Google Cloud infrastructure to send the messages from a legitimate email address (“noreply-application-integration@google[.]com”) so that they can bypass traditional email security filters and have a better chance of landing in users’ inboxes.
“The emails mimic routine enterprise notifications such as voicemail alerts and file access or permission requests, making them appear normal and trustworthy to recipients,” the cybersecurity company said.
Attackers have been observed sending 9,394 phishing emails targeting approximately 3,200 customers over a 14-day period observed in December 2025, with the affected organizations located in the U.S., Asia-Pacific, Europe, Canada, and Latin America.
At the heart of the campaign is the abuse of Application Integration’s “Send Email” task, which allows users to send custom email notifications from an integration. Google notes in its support documentation that only a maximum of 30 recipients can be added to the task.
The fact that these emails can be configured to be sent to any arbitrary email addresses demonstrates the threat actor’s ability to misuse a legitimate automation capability to their advantage and send emails from Google-owned domains, effectively bypassing DMARC and SPF checks.
“To further increase trust, the emails closely followed Google notification style and structure, including familiar formatting and language,” Check Point said. “The lures commonly referenced voicemail messages or claims that the recipient had been granted access to a shared file or document, such as access to a ‘Q4’ file, prompting recipients to click embedded links and take immediate action.”
The attack chain is a multi-stage redirection flow that commences when an email recipient clicks on a link hosted on storage.cloud.google[.]com, another trusted Google Cloud service. The effort is seen as another effort to lower user suspicion and give it a veneer of legitimacy.
The link then redirects the user to content served from googleusercontent[.]com, presenting them with a fake CAPTCHA or image-based verification that acts as a barrier by blocking automated scanners and security tools from scrutinizing the attack infrastructure, while allowing real users to pass through.
Once the validation phase is complete, the user is taken to a fake Microsoft login page that’s hosted on a non-Microsoft domain, ultimately stealing any credentials entered by the victims.
In response to the findings, Google has blocked the phishing efforts that abuse the email notification feature within Google Cloud Application Integration, adding that it’s taking more steps to prevent further misuse.
Check Point’s analysis has revealed that the campaign has primarily targeted manufacturing, technology, financial, professional services, and retail sectors, although other industry verticals, including media, education, healthcare, energy, government, travel, and transportation, have been singled out.
“These sectors commonly rely on automated notifications, shared documents, and permission-based workflows, making Google-branded alerts especially convincing,” it added. “This campaign highlights how attackers can misuse legitimate cloud automation and workflow features to distribute phishing at scale without traditional spoofing.”
‘
Update
Both xorlab and Ravenmail have disclosed details of the credential harvesting campaign, with the former noting that the attacks are also being used to carry out OAuth consent phishing, as well as host the fake login pages on Amazon Web Services (AWS) S3 buckets.
“The attackers trick victims into granting a malicious Azure AD application access to their cloud resources – gaining access to Azure subscriptions, VMs, storage, and databases via delegated permissions that persist through access and refresh tokens,” xorlab said.
“Each hop uses trusted infrastructure – Google, Microsoft, AWS – making the attack difficult to detect or block at any single point. Regardless of the entry point, victims eventually land on the Microsoft 365 login page, revealing the attackers’ primary target: M365 credentials.”
