In Dec 2025, more than 3000 organizations (primarily manufacturing) were targeted by attackers sending phishing mails mails from '[email protected]'. 

For years, enterprise email security has relied on a foundational assumption:

If an email comes from a trusted platform and passes authentication, it’s safe.

That assumption is now actively being exploited.

Attackers are increasingly abusing Google’s own applications and cloud infrastructure to deliver phishing emails that look legitimate, authenticate cleanly, and evade traditional security controls. These attacks do not rely on spoofed domains or compromised mail servers. Instead, they operate inside trusted systems, using legitimate Google workflows as the delivery mechanism.

This blog breaks down how these attacks work, why most email security tools fail to stop them, and how RavenMail detected and blocked a real-world Google-based phishing campaign that passed every conventional check.

The Shift: From Spoofing Google to Operating Inside Google

Modern phishing campaigns are no longer built around deception at the infrastructure layer. Instead of faking Google, attackers are leveraging Google.

Recent threat research has documented multiple campaigns where adversaries abused the following services:

Phishing Mail Abuse of Google Products

​

In each case, emails were sent from legitimate Google infrastructure, passed SPF, DKIM, and DMARC, and used trusted Google-hosted URLs as payloads. This fundamentally breaks the trust model that most email security platforms rely on.

Industry investigations have shown that attackers deliberately choose Google services because they inherit:

  • High sender reputation
  • Near-universal allowlisting
  • User familiarity and trust

Security researchers have repeatedly observed that these campaigns bypass both secure email gateways and native email protections because there is nothing technically “wrong” with the message delivery itself.

Dec 2025: Google Tasks Notification Based Attack

The email claimed to be an internal task requesting employee verification and urged recipients to click “View task” or “Mark complete.” All calls to action redirected users to a page hosted on Google Cloud Storage and the mail impersonated Google Tasks product.

Google Tasks Phishing

How the Attack Worked

Attackers sent phishing emails directly from Google’s own sending infrastructure, passing - SPF, DKIM, DMARC and CompAuth​

There was no spoofing, no lookalike domain, no malformed headers.

The email originated from a valid Google address:

From an infrastructure standpoint, the email was clean.

From a security standpoint, it wasn't.

The message abused Google Tasks branding to impersonate an internal “All Employees Task,” urging recipients to complete an employee verification form.

1. Abuse of Trusted SaaS Identity

The attacker leveraged Google’s application integration framework to send emails that inherit Google’s sender reputation and delivery trust.

This mirrors broader industry observations where attackers exploit trusted SaaS platforms to bypass email gateways, as documented by Check Point and others.

2. High-Fidelity Brand Impersonation

The email replicated:​

  • Google Tasks UI
  • Legitimate Google footer and branding
  • Familiar CTA buttons like “View task” and “Mark complete”

Visually and structurally, it matched real Google notifications almost perfectly.

3. Malicious Payload Hosted on Google Cloud

Instead of attaching files or linking to suspicious domains, the CTA redirected users to a Google Cloud Storage URL:

<https://storage.cloud.google.com/.../loading.html>

This is a critical shift.

The payload lived on a trusted Google-owned domain, making URL reputation-based detection ineffective.

The analysis clearly states that legitimate Google Tasks workflows never use Cloud Storage URLs for task actions—a subtle but decisive contextual mismatch

4. Psychological Triggers

The message relied on:​

  • Authority framing (“All Employees Task”)
  • Urgency (“High priority”, fixed due time)
  • Minimal explanation to encourage immediate action

Why Traditional Email Security Misses This

Most email security platforms still anchor detection around:

  • Sender reputation
  • Domain trust
  • Authentication results
  • Known malicious URLs or attachments

In this case:

  • The sender was Google
  • Authentication passed
  • The domain was trusted
  • There were no attachments

From a traditional lens, there was nothing to block.

This exact pattern has been reported in multiple independent investigations, including campaigns abusing Google Cloud automation and application integration services to evade detection.

How RavenMail Stopped the Attack

RavenMail flagged and blocked this email despite its legitimate infrastructure because RavenMail does not equate trust with safety.

1. Contextual Mismatch Detection

RavenMail analyzed the intent and context of the email:​

  • Google Tasks being used for HR verification is anomalous
  • Internal employee actions should originate from corporate domains
  • External sender banners contradicted the “internal task” narrative

This mismatch alone elevated risk.

2. Payload Context, Not Domain Reputation

Instead of asking “Is this a trusted domain?”, RavenMail asked:

  • Does this workflow make sense?
  • Is this URL consistent with legitimate Google Tasks behavior?
  • Is Cloud Storage a valid endpoint for this action?

The answer was no.

3. Intent-Centric Classification

RavenMail classified the email as interaction-driven, not informational—an indicator strongly correlated with credential harvesting attempts.

Understanding Phishing Using Google Infra

Abuse of Google Cloud Application Integration

Recent threat research has revealed that attackers are exploiting Google Cloud’s Application Integration service to send phishing emails through legitimate Google infrastructure. Because these emails are sent from real Google domains  they pass critical email authentication checks that most security tools rely on.

In one observed campaign:

  • More than 9,000 phishing emails were sent to roughly 3,200 businesses over two weeks.
  • The messages mimicked legitimate enterprise notifications such as voicemail alerts or file access requests.
  • Initial clicks landed on trusted Google Cloud URLs before redirecting users to credential-harvesting pages.

This is abuse, not compromise - Google’s systems weren’t breached. Instead, threat actors manipulated workflow automation services meant to streamline business processes.

Cloud Hosting as a Phishing Relay

Attackers are also hosting phishing pages and multi-stage redirectors on Google Cloud Storage (GCS) - a fully trusted, HTTPS-served domain space. Because many URL reputation systems treat cloud provider domains as benign, these links frequently evade detection.

Separately, other campaigns have exploited Google platforms like Google Classroom and Google Forms to distribute phishing content at massive scale and avoid security filters that block unknown or low-reputation domains.

Mail send workflows from Application Integration Service (Credit: XoR Labs)

Not an Isolated Incident: The AppSheet Connection

The Google Tasks campaign is part of a broader pattern.

Earlier, RavenMail documented a phishing campaign abusing Google AppSheet, Google’s no-code application platform. In that attack:

  • Emails originated from legitimate Google systems
  • Authentication checks passed
  • Phishing lures were embedded in real AppSheet workflows
  • Victims were redirected to credential-harvesting pages

The full analysis is available here:

https://ravenmail.io/blog/appsheet-phishing-scam

Across both campaigns : AppSheet and Google Tasks, the underlying tactic is identical: Attackers are abusing trusted SaaS workflows to deliver phishing without spoofing or malware.

Each campaign looks different on the surface.

The detection challenge is the same.

This Is Not a Google Problem. It’s an Industry Shift.

Google is not uniquely vulnerable here.

What we are seeing is a broader trend:

  • Attackers abusing trusted platforms (Salesforce, Amazon SES)
  • Security controls optimized for yesterday’s threat model
  • Phishing evolving into workflow and identity abuse

As long as defenses rely primarily on static trust signals, attackers will continue to hide inside legitimate systems.

References & Credits