Cybersecurity researchers have revealed details of a phishing campaign in which attackers misused Google Cloud’s Application Integration service to deliver emails impersonating legitimate Google-generated messages.
Check Point said the activity leverages the trust associated with Google Cloud infrastructure to send messages from legitimate email addresses (“noreply-application-integration@google[.]com”) so they can bypass traditional email security filters and have a better chance of landing in users’ inboxes.
“The emails mimic regular enterprise notifications such as voicemail alerts and file access or permission requests, making them appear normal and trustworthy to recipients,” the cybersecurity company said.
The attackers were observed sending 9,394 phishing emails targeting approximately 3,200 customers over a 14-day period observed in December 2025, which included affected organizations located in the US, Asia-Pacific, Europe, Canada, and Latin America.
At the center of the campaign is the abuse of the “send email” function of application integrations, which allows users to send custom email notifications from an integration. Google notes in its support document that only a maximum of 30 recipients can be added to a task.
The fact that these emails can be configured to send to any arbitrary email address demonstrates the threat actor’s ability to abuse legitimate automation capabilities 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. “Lease typically refers to voicemail messages or claims that the recipient was granted access to a shared file or document, such as access to a ‘Q4’ file, to induce recipients to click on the embedded link and take immediate action.”
The attack chain is a multi-step redirection flow that begins when an email recipient clicks on a link hosted on storage.cloud.google.[.]com, another trusted Google Cloud service. This effort is seen as another attempt to reduce user skepticism and give it a cloak of legitimacy.
The link then redirects the user to the provided content from googleusercontent[.]com, presents them with a fake CAPTCHA or image-based verification that acts as a barrier by preventing automated scanners and security tools from examining the attack infrastructure, while allowing genuine users to pass through.
Once the verification step is completed, the user is taken to a fake Microsoft login page that is hosted on a non-Microsoft domain, ultimately stealing any credentials the victims entered.
In response to the findings, Google has blocked phishing attempts that abuse the email notification feature within Google Cloud application integration, and said it is taking further steps to prevent further abuse.
Check Point’s analysis showed that the campaign primarily targeted the manufacturing, technology, financial, professional services and retail sectors, although other industry verticals were singled out, including media, education, healthcare, energy, government, travel and transportation.
“These areas typically rely on automated notifications, shared documents, and permission-based workflows, making Google-branded alerts particularly reliable,” it says. “This campaign highlights how attackers can abuse legitimate cloud automation and workflow features to deliver phishing at scale without traditional spoofing.”
,
update
Both Zorlab and RavenMail have revealed details of the credential harvesting campaign, with the former mentioning that the attacks are also being used to carry out OAuth consent phishing, as well as hosting fake login pages on an Amazon Web Services (AWS) S3 bucket.
“Attackers trick victims into granting a malicious Azure AD application access to their cloud resources – gaining access to Azure subscriptions, VMs, storage, and databases through specified permissions, which are persisted through access and refresh tokens,” Xorlab said.
“Each hop uses trusted infrastructure – Google, Microsoft, AWS – making it difficult to detect or prevent an attack at any one point. Regardless of the entry point, victims ultimately reach the Microsoft 365 login page, revealing the attackers’ primary target: M365 credentials.”
