When Google Is the Phishing Infrastructure: Authenticated Credential Harvesting via Search Console

SPF passed. DKIM passed. DMARC passed. Every link pointed to a Google-owned domain. The sending IP belonged to Google. The DKIM signature was cryptographically valid for google.com. And every link scanner that evaluated the embedded URLs returned a clean verdict.

This is what modern credential phishing looks like when attackers weaponize the platforms your organization already trusts.

We flagged a campaign delivering Google Search Console notifications through Google's own authenticated mailing infrastructure. The emails prompted recipients to sign in via accounts.google.com to review site performance data. The technique is elegant in its simplicity: there is nothing to detect at the infrastructure layer because the infrastructure is real.

Fully Authenticated Delivery from Google's Mailing Pipeline

The email arrived from sc-noreply@google[.]com with a Return-Path pointing to scoutcamp.bounces.google[.]com. It was transmitted from Google's mail servers at IPv6 address 2607:f8b0:4864:20::f47 and carried a valid google.com DKIM signature using the 20251104 selector.

The authentication results tell the story:

• SPF: Pass for scoutcamp.bounces.google[.]com
• DKIM: Pass, signature verified for google.com
• DMARC: Pass, action=none

The Received headers confirm the message traversed Google's outbound mail infrastructure before entering the recipient's Microsoft 365 environment via protection.outlook.com. Microsoft's own Forefront antispam filters assigned an SCL of 1 (low spam confidence) and categorized the message as NONE, meaning no threat detected.

This is not a case of a spoofed sender or a lookalike domain. The email was sent by Google, from Google, signed by Google.

Every Link Leads to Google. That's the Problem.

The message body, written in Hebrew, prompted the recipient to review search performance data for their organization's domain. It included multiple call-to-action buttons linking to Google Search Console pages:

• Direct links to search.google[.]com/search-console/ endpoints
• Sign-in flows through accounts.google[.]com/ServiceLogin with continue= parameters routing to Search Console
• c[.]gle shortlinks resolving to Google Search Console and support pages

Every single link in the email resolved to a Google-owned domain. Link scanners evaluated the destinations and returned clean verdicts with screenshots confirming legitimate Google pages.

This is the core of the technique. Attackers abuse trusted infrastructure not by injecting malicious payloads into legitimate services, but by using the legitimate services themselves as the credential capture mechanism. The accounts.google[.]com/ServiceLogin endpoint is a real Google sign-in page. When a recipient clicks through and authenticates, the attacker gains access through OAuth consent abuse, session hijacking, or by having pre-registered the target domain in Search Console using a compromised or synthetic Google account.

See Your Risk: Calculate how many threats your SEG is missing

Why Gateways Cannot Catch This

The campaign maps to several MITRE ATT&CK techniques:

• T1566.002 (Phishing: Spearphishing Link): Email contains links designed to harvest credentials through a legitimate sign-in flow.
• T1078 (Valid Accounts): The end goal is capturing valid Google credentials to gain persistent access to organizational resources.
• T1598.003 (Phishing for Information: Spearphishing Link): The campaign specifically targets users with access to Google Search Console, indicating reconnaissance of the organization's web infrastructure team.

Traditional email security gateways evaluate three categories of evidence: sender reputation, content analysis, and link inspection. This campaign defeats all three.

Sender reputation is perfect because the sender IS Google. Content analysis sees a standard Google notification template with no malicious payloads, suspicious attachments, or social engineering language outside the expected notification format. Link inspection returns clean verdicts because every URL resolves to a Google-owned domain serving legitimate Google pages.

The 2024 Verizon DBIR found that credential theft remains the primary objective in over 40% of breaches, and the FBI IC3 2024 report documented $2.9 billion in losses from BEC and credential compromise. Platform-based phishing like this campaign represents the next evolution: attacks that are technically legitimate at every layer the gateway can inspect.

The Microsoft Digital Defense Report 2024 noted that threat actors increasingly leverage trusted cloud services as attack infrastructure, specifically because authentication-based defenses cannot distinguish between legitimate and malicious use of the same platform.

How Community Intelligence Broke the Pattern

What flagged this campaign was not infrastructure analysis. It was pattern recognition across thousands of similar incidents reported by the IRONSCALES community of 35,000+ security professionals.

Community intelligence identified that this exact message template, including its formatting, link structure, and call-to-action pattern, matched previously confirmed credential phishing campaigns. The Adaptive AI correlated behavioral signals: the message arrived unsolicited, requested authentication to a high-value service, and matched a distribution pattern consistent with bulk phishing rather than targeted administrative notifications.

The confidence assessment reflected the inherent difficulty: 75%, acknowledging that the same template is used for both legitimate Google notifications and their weaponized counterparts. The distinction between the two cannot be made at the email layer alone. It requires understanding whether the recipient expects this notification, whether the sign-in flow has been tampered with, and whether the Search Console property was registered by a legitimate administrator or an attacker.

Defending Against Trusted Platform Abuse

This class of attack requires a fundamentally different detection approach than traditional email security.

Do not trust authentication results as proof of legitimacy. SPF, DKIM, and DMARC verify that an email was sent by the claimed infrastructure. They do not verify that the infrastructure was used for legitimate purposes. Any email security strategy that treats passing authentication as a green light will miss platform-based phishing entirely.

Audit Google Search Console access for your domains. If your organization uses Search Console, verify that all registered properties and users are authorized. Attackers who register your domain in their Search Console account can trigger legitimate Google notifications to your team, creating a pretext for credential capture.

Treat unsolicited sign-in prompts as high-risk regardless of the domain. Train security teams and end users to navigate directly to services rather than clicking authentication links in email notifications, even when those links point to the correct domain. The CISA phishing guidance recommends this as a baseline practice.

Deploy behavioral detection that evaluates patterns beyond individual email attributes. Community threat intelligence and AI-driven pattern matching caught what infrastructure analysis could not. The Gartner Market Guide for Email Security emphasizes that organizations need detection capabilities that go beyond sender and content analysis to include behavioral and community-based signals.

When the phishing infrastructure is Google itself, the only defense is one that does not rely on infrastructure trust.