Phishing Campaign Abuses Google Sites and OAuth to Steal Gmail Credentials

Executive Summary

‍

A newly identified phishing campaign exploits trusted Google infrastructure—including Google Sites and OAuth 2.0—to enhance the credibility and delivery success of credential-harvesting emails targeting Gmail users. Threat actors are leveraging Google’s domain reputation to bypass email security filters and increase user trust. Notably, the use of DKIM-signed replayed emails, OAuth consent screen abuse, and Google Sites-hosted fake login pages enables attackers to convincingly impersonate legitimate Google services.

Doppel Senior Sales Engineer Caroline Lane and Detections Team Lead Aarsh Jawa compiled this summary based on the team's findings.

Doppel expects this method to gain traction in the near to mid-term (3-6 months) among cybercriminal groups due to its low barrier to entry and high success rate. Key trends to monitor include:

• Wider adoption of DKIM replay techniques to legitimize spoofed email headers.
• Increased abuse of legitimate cloud services (Google, Microsoft, Dropbox) for phishing infrastructure.
• Targeted campaigns against high-value Gmail users (e.g., executives, developers, administrators).
• Evolution into multi-stage attacks, incorporating additional malware delivery or business email compromise (BEC) elements post-credential capture.

‍

Intelligence Summary

‍

Doppel is aware of a recent phishing campaign that weaponizes Google Sites, Gmail, and Google Cloud Project OAuth to trick users into handing over their credentials. The attacker creates a fake Legal Investigations Support case dashboard and mimics official Gmail alerts, all hosted under trusted Google infrastructure - making it extremely convincing.

The attacker executed a DKIM replay attack by capturing a legitimate, DKIM-signed email originally sent from no-reply@accounts.google.com. Instead of modifying the content - which would invalidate the DKIM signature - the attacker redistributed the exact email to multiple recipients while preserving the original headers and cryptographic signature.

Because the DKIM signature remained intact and verifiable against google.com, most receiving mail servers treated the email as authentic and trusted. This allowed the spoofed message to bypass common security checks and land directly in the user's inbox.

By combining DKIM replay with social engineering and abuse of Google’s trusted infrastructure (e.g., Google Sites, Drive, and OAuth apps), the attacker was able to bypass common spam filters and build credibility with unsuspecting users.

‍

‍

Technical Details

‍

Step-by-Step Attack Breakdown

‍

1. Phishing Email Disguised as Google Legal Notice

‍

‍

The user receives an email from what appears to be Google:

From: Google <no-reply@accounts.google.com>

Subject: Security alert

Date: Thu, 21 Apr 2025

The content claims that a subpoena has been received from law enforcement requiring extraction of Google Account content:

Google Support Ref #: [34-0000961821]

Google Support Case: hxxps[://]sites[.]google[.]com/u/0/d/1ObcQPBUKzBJNIQPSSNVogsiJ1F28fbpi/preview?pli=1&amp;authuser=0

‍

The URL appears to be a legitimate Google Sites link, and the message mimics Google’s tone and design.

‍

2. Fake Google Support Dashboard on Google Sites

‍

‍

The provided link opens a Google Sites page that looks like an official Google Support dashboard. It contains:

• A legal case reference number
• Options to “Upload additional documents” or “View case”

Clicking either option refreshes the page but prompts the user to sign in again, even though they’re already signed in.

In the publishing configuration of the malicious Google Site, the attacker checks the option labeled “Request public search engines to not display my site.” This setting explicitly instructs search engines not to index the site, ensuring that it doesn’t appear in search results.

By doing so, the attacker keeps the phishing page accessible only to direct recipients of the link, making it harder to discover through open-source threat hunting or automated indexing tools - effectively reducing the chance of takedown or early detection.

‍

‍

3. Fake Google Sign-In Prompt (Credential Theft)

‍

‍

Users are tricked into entering credentials on a fake sign-in page hosted within the legitimate sites.google.com domain, without being redirected to accounts.google.com.

This credential input field is not a real Google login, but HTML and JavaScript that sends credentials directly to the attacker.

After the credentials are shared on this page it shows this error page by Google Drive:

Legitimate Google sign-in prompts automatically recognize the account a user is currently logged into and do not ask for your credentials again (see example below). Any prompt that requires a user to re-enter your login details while already authenticated should be treated as suspicious.

‍

‍

How the Attack is Set Up Using Google Cloud:

‍

1. Create a New Project in Google Cloud Console:

The attacker begins by setting up a new project in Google Cloud Console.

‍

2. Enable the Google Drive API:

‍They then enable Google Drive API - not necessarily to access user files, but to make the app appear legitimate and bypass some basic security heuristics.

‍

3. Configure the OAuth Consent Screen

‍

‍

In the OAuth consent screen configuration, they attacker chooses:

• External User Type
• App Name: Set to “Google LLC has received a subpoena ….” (exactly as shown in the phishing site)
• Support email, developer contact, and other fields are filled in with throwaway or spoofed addresses.
  
  

4. Create OAuth Client ID:

‍
The attacker then creates a web application OAuth Client ID and configures the redirect URI to point back to the same sites.google.com/.../preview page. This creates a misleading flow that appears like a legitimate Google authentication step, though it actually just resubmits to their phishing backend.

‍

‍

Doppel Recommendations

‍

Short-Term Mitigations

‍

• User Awareness: Distribute targeted alerts and training materials to all users, especially high-risk groups, outlining the current phishing campaign indicators (e.g., OAuth consent prompts requesting access to Gmail).
• Report & Block: Instruct users to report suspicious Google-related emails and block access to known malicious URLs via DNS filtering and secure web gateways.
• OAuth App Restrictions: Enforce OAuth 2.0 application access controls via Google Workspace admin settings. Only allow trusted apps to access sensitive scopes (e.g., Gmail, Drive).

‍

Technical Controls

‍

• Email Security Enhancements:
  
  • Enable and enforce DMARC with “reject” policy to reduce spoofing.
  • Monitor for unusual DKIM signatures, especially from Google-owned domains not typically seen sending internal messages.
    
    
• Threat Hunting:
  
  • Search logs for unexpected logins or third-party OAuth tokens granted to suspicious applications.
  • Look for referrers from Google Sites domains combined with Gmail logins in traffic logs.

‍

Strategic Defenses

‍

• Zero Trust Posture: Limit access to internal services even for users with legitimate credentials by enforcing behavioral and contextual risk analysis.
• Regular App Reviews: Implement a quarterly review of third-party app access within your organization's Google Workspace or personal accounts.

‍

Indicators of Compromise (IOCs)

‍

• hxxps[://]sites[.]google[.]com/u/0/d/1ObcQPBUKzBJNIQPSSNVogsiJ1F28fbpi/preview?pli=1&amp;authuser=0
• OAuth app names mimicking:
  Google Legal Investigations Support
• Emails from:
  no-reply@accounts.google.com
  
  

‍