New Phishing Wave Exploits Google's Application Integration Service

3 min read Original article ↗

Table of contents

How It Works

The attack leverages Google's Application Integration infrastructure to send emails from `noreply-application-integration@google.com`. Because these messages originate from Google's own servers, they pass SPF, DKIM, and DMARC authentication — making them appear fully legitimate to both email gateways and recipients.

app_integration_workflow
Setting up the email sending workflow in Google's Application Integration service

To maximize credibility, attackers pair these authenticated emails with links pointing to Google-hosted domains like `storage.cloud.google.com`, `sites.google.com`; and `share.google` and use Google's recognizable email templates for their messages. The result is an email from Google, with links to Google, that passes all standard email authentication checks.

Likely Attack Objectives

To evade detection, attackers use multi-hop redirect chains that bounce through multiple legitimate services. A typical chain might look like this:

Google domain (e.g., share.google, sites.google.com)
→ Microsoft OAuth (login.microsoftonline.com)
→ Attacker-controlled page (e.g., AWS S3 bucket)

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.

Depending on the victim's role, the attack serves one of two purposes:

Credential Harvesting

For most victims, this is straightforward credential theft. The OAuth flow requests the scope https://management.core.windows.net//.default, but most targeted recipients don't have Azure management privileges. Instead, we believe the OAuth prompt serves as a mechanism to capture and validate credentials through Microsoft's legitimate login flow — even if the victim lacks Azure permissions, the attacker confirms the password is valid.

links_benefits_anonymized

For victims with cloud privileges, this becomes an OAuth consent attack (also known as "illicit consent grant"). 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.

Why This Bypasses Traditional Defenses

  • Legitimate login page: Credentials are entered on Microsoft's real site, not a fake
  • MFA doesn't help: The victim completes MFA themselves during authentication
  • Tokens persist: Access tokens last hours or days; refresh tokens extend access further
  • Multi-cloud obfuscation: Google, Microsoft, and AWS infrastructure in a single attack chain

Why It's Effective

This attack succeeds where traditional phishing fails:

  • Authentic sender domain: Emails come from @google.com, not a lookalike
  • Passes authentication: SPF, DKIM, and DMARC all validate successfully
  • Trusted link destinations: URLs point to legitimate Google domains
  • Familiar format: Notifications mirror real Google sharing alerts

For many security tools and users, these signals indicate a trustworthy message.

Put your email security to the test

Mitigation Recommendations

Security teams should consider the following:

  1. Flag or quarantine emails from `noreply-application-integration@google.com` for manual review
  2. Alert on suspicious patterns involving `sites.google.com` or `storage.cloud.google.com` links, especially when combined with urgent financial or security themes
  3. Update awareness training to include this specific attack vector — users should know that @google.com senders can still be malicious
  4. Monitor for indicators such as unexpected Application Integration notifications in environments that don't use this service.

Examples and References

Example screenshots

benefits_anonymized
Fake File Sharing notification

voicemail
Fake voicemail notification

References