Google Cloud phishing bypasses email filters

Summarize with:



How can attackers trick 3,200 organizations into surrendering Microsoft 365 credentials using legitimate Google Cloud infrastructure? Attackers exploit the Application Integration service’s email task to impersonate Google notifications. The campaign reaches inboxes because emails originate from trusted Google domains, bypassing email security filters entirely. Victims see familiar notification styles about voicemail access or document sharing. Clicking embedded links triggers a multi-stage attack: fake CAPTCHA validation blocks security scanners, then fake Microsoft login pages harvest credentials. Check Point researchers detected 9,394 phishing emails targeting organizations across U.S., Asia-Pacific, Europe, Canada, and Latin America during December 2025. The campaign reveals how cloud automation features become attack vectors when defenders focus only on traditional spoofing techniques.

Campaign Details: Abuse of Trusted Infrastructure

Threat actors weaponized Google Cloud’s Application Integration service—a legitimate automation platform—to distribute phishing emails at scale. The “Send Email” task function allows users to send custom notifications from integrations. Attackers configured this task to send emails impersonating Google’s [email protected] account.

The emails avoided traditional security filters because they originated from actual Google infrastructure. This bypass was critical: DMARC and SPF authentication checks passed validation since the messages used genuine Google domains. Email security solutions designed to catch spoofed messages failed because nothing was technically spoofed.

Attack Targeting and Reach

Check Point identified 9,394 phishing emails sent over 14 days in December 2025. Roughly 3,200 customer organizations received attacks. Affected sectors included manufacturing, technology, financial services, professional services, and retail. Secondary targets included media, education, healthcare, energy, government, travel, and transportation industries.

Geographic distribution spanned five continents. Organizations in the United States, Asia-Pacific region, Europe, Canada, and Latin America all faced exposure. This geographic diversity suggests attackers prioritized scale over targeting specific nations or sectors.

Email Content and Social Engineering

Phishing messages mimicked routine enterprise notifications. Common lures included:

  • Voicemail access alerts claiming new messages awaited
  • File access notifications for shared documents or “Q4” project files
  • Permission grant requests requiring immediate action
  • Generic workflow or account notification templates

The emails closely followed Google’s notification formatting and language patterns. Recipients familiar with legitimate Google notifications would see nothing obviously suspicious. Urgency language compelled victims to click without deliberation.

Why This Matters: Cloud Automation as Attack Surface

This campaign shifts focus from traditional endpoint compromise to cloud service abuse. Organizations invested in email security that blocks spoofed messages discovered their defenses bypassed entirely. The attack succeeded because it used legitimate cloud infrastructure rather than attempting to forge email headers.

Operational Impact

Successful credential theft enables rapid lateral movement. Attackers who gained Microsoft 365 access could:

  • Access cloud storage and sensitive documents
  • Pivot to Azure subscriptions and virtual machines
  • Steal additional credentials from OAuth integrations
  • Maintain persistence through created service accounts

Once inside Azure Active Directory, attackers obtained delegated permissions persisting through access and refresh tokens. This created backdoor access lasting weeks or months beyond initial compromise.

Strategic Shift in Attack Methodology

This campaign represents an evolution in cloud-native phishing. Rather than compromising infrastructure, attackers leveraged existing automation capabilities. The approach required no infrastructure investment, no domain registration, and minimal detection risk. Defenders must now treat cloud automation features as potential attack vectors, not just efficiency tools.

The campaign also demonstrates attackers’ understanding of cloud security gaps. Organizations securing email gateways and endpoint tools often neglect cloud application audit logging. Even when breaches occurred, detecting unauthorized Application Integration tasks could take days or weeks.

How the Attack Works: Multi-Stage Redirect Chain

Step 1: Malicious Email Delivery

Attackers sent emails from a legitimate Google Cloud email account. Email security systems validated sender authentication because messages originated from actual Google infrastructure. Recipients saw familiar formatting and urgent language encouraging immediate action on voicemail messages or shared files.

Step 2: Initial Link Redirect via Google Cloud Storage

Embedded links pointed to storage.cloud.google.com—another trusted Google service. Recipients clicked links expecting file access or voicemail playback. This first hop added legitimacy and bypassed URL reputation filters. Security scanners often trust Google Cloud storage domains, reducing detection likelihood.

Step 3: CAPTCHA Validation Barrier

The first redirect led to content served from googleusercontent.com, presenting a fake CAPTCHA or image-based verification page. This step served two purposes:

  • Blocked automated security scanners from accessing downstream attack pages
  • Appeared legitimate to users familiar with CAPTCHA verification

Automated tools attempting to analyze phishing infrastructure would fail at this barrier. Real users, however, proceeded after completing verification.

Step 4: Credential Harvesting on Fake Login Page

After CAPTCHA validation, victims reached a fake Microsoft 365 login page hosted on a non-Microsoft domain. Users entered credentials expecting normal authentication. Attackers captured usernames and passwords in real-time for immediate use.

The four-hop redirection chain maximized legitimacy while minimizing detection. Each hop used trusted infrastructure: Google’s email system, Google Cloud Storage, Google’s user content domain, and finally an attacker-controlled server. Breaking any single link appeared unsafe to users, encouraging credential entry on fake pages.

Context: Why Cloud Automation Features Lack Security Controls

Google Cloud Application Integration allows users to automate workflows and send notifications without technical barriers. The platform intentionally reduces friction for legitimate business users. This design decision created an abuse vector because the same “ease of use” meant attackers could configure malicious tasks with minimal expertise.

Organizations using legitimate notification workflows provided cover for attackers. Defenders observing Application Integration activity in logs could not easily distinguish legitimate uses from malicious ones. An administrator might see thousands of email tasks across multiple departments monthly.

DMARC and SPF Bypass Mechanics

Traditional email authentication (DMARC, SPF, DKIM) validates sender identity based on domain ownership. Google owns the [email protected] domain, so authentication checks passed. Spoofing detection relies on checking if message senders match domain configuration. Since Google legitimately sends these emails, the authentication passed completely.

Email security vendors design filters to catch unauthorized actors impersonating company domains. A banking customer receiving emails from “[email protected]” triggers warnings. But emails from “[email protected]” pass all automated checks because Google does send legitimate noreply emails constantly.

Secondary Attack Vector: OAuth Consent Abuse

Security researchers noted attackers also used OAuth consent phishing in coordinated attacks. Victims who clicked links encountered pages asking permission to grant a malicious Azure Active Directory application access to their accounts. Users unknowingly authorized applications with dangerous permissions. This approach created persistence without ever needing stolen passwords initially, though credential harvesting remained the primary method observed.

The abuse of Application Integration represents a broader pattern where cloud platforms emphasize automation and ease-of-use over security controls. Organizations providing default access to cloud automation services without audit logging or approval workflows face compounded risk.

Sources and Defensive Guidance

Original Disclosure: Check Point Research published comprehensive analysis on January 2, 2026, detailing the phishing campaign infrastructure and techniques. The report included YARA detection rules and infrastructure indicators.

Secondary Research: Security firms xorlab and Ravenmail independently confirmed the campaign and provided additional technical details about OAuth consent phishing variations and AWS S3 hosting for fake login pages.

Google’s Response: Google blocked the malicious Application Integration tasks immediately after notification. The company stated it’s implementing additional controls to prevent similar abuse but has not published specific technical safeguards publicly.

Defensive Recommendations

Organizations can reduce exposure through these measures:

  • Enable advanced email authentication (DMARC, SPF, DKIM) with strict enforcement policies blocking non-authenticated mail
  • Implement URL rewriting in email gateways to break redirect chains and verify final destination domains
  • Monitor Application Integration audit logs for unusual task creation, especially email tasks sending to external addresses
  • Restrict Application Integration permissions to authorized administrators only
  • Conduct user training emphasizing verification of file access notifications through direct application interfaces, not email links
  • Deploy conditional access policies in Azure AD requiring multi-factor authentication for unusual sign-in patterns
  • Enable OAuth consent blocking for risky applications and require admin approval before users grant permissions

This campaign underscores that credential theft remains foundational to modern attacks. Defenders must shift focus from blocking spoofing to detecting abuse of legitimate services organizations depend on daily.