When Google Sites Becomes the Phishing Page: Credential Harvest Behind a Proofpoint Disguise

A calendar deadline printed in the email body. A professional signature block with phone number and street address. A Proofpoint secure-message footer. The From line showing a regional health information exchange. Everything in the message is constructed to say: this is real, and you have a limited window to act.

The link goes to sites.google.com.

The Brand Stack That Makes the Lure Work

This attack stacks two trust signals that most employees recognize: a healthcare organization with a known-sender relationship with the recipient organization, and Proofpoint, the email-security platform whose secure-message portal format has become a recognizable template for legitimate confidential communications.

The body imitates the Proofpoint secure-message experience precisely: an organization name in the header, a single prominent "Click here" action, an explicit expiration timestamp, and a footer explaining that the message is encrypted. None of the visible elements are fabricated in the way most awareness training describes fabrication. There is no typo in the From address, no misspelled company name, no obviously broken link text. The branding is clean and the tone matches what a real HIPAA-adjacent notification would look like.

What the email does not contain is a destination that matches the brand. Proofpoint secure messages route through pphosted.com or proofpoint.com. This message routes to sites.google.com. That single mismatch is the entire detection surface available to a human recipient who looks carefully, or to a security tool that evaluates link destinations against expected domain relationships.

Why Google Sites Passes Where Other Attacker Infrastructure Would Not

Credential harvesting attacks that rely on attacker-registered domains face an increasingly difficult environment. New registrations are flagged by threat intelligence feeds, TLS certificate transparency logs surface fresh infrastructure quickly, and any domain without reputation history triggers elevated scrutiny in modern secure email gateways.

Google Sites eliminates all of that friction. The hosting domain is google.com. There is no registration history to query. Reputation scores for sites.google.com reflect the legitimate content that has been hosted there for years. A URL filter evaluating hxxps://sites[.]google[.]com/view/service-secure-document/home sees a google.com URL and has no signal to act on. The page itself may present a Microsoft credential prompt, which the attacker controls entirely, but the hosting infrastructure belongs to Google.

A secondary Google Sites URL, hxxps://sites[.]google[.]com/view/mtc-secure-message/home, was also present in the message, suggesting the attacker maintained parallel infrastructure for fallback delivery or A/B targeting. Both pages routed through a accounts.google.com/ServiceLogin intermediate when accessed by unauthenticated users, meaning the Google authentication flow itself could be misused as an additional legitimacy signal for a recipient who sees the accounts.google.com URL before reaching the harvest page.

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

The Relay Path and What It Tells Us About Detection

The message transited through a Zix secure-messaging relay before reaching the recipient organization. This is significant for two reasons. First, Zix is a legitimate healthcare-focused email security platform, and messages passing through Zix infrastructure carry an implicit association with regulated healthcare communication. Second, the relay chain produced a partial authentication breakdown at the final Microsoft Exchange hop: the ARC seal at the receiving tenant showed cv=fail, and the final-hop authentication results showed SPF, DKIM, and DMARC all failing.

The key nuance is that this failure pattern is common for forwarded or relay-processed mail. An earlier hop in the chain showed a clean SPF pass, DKIM pass, and DMARC pass for the sender domain, which is consistent with a message that authenticated at its origin and then had that authentication disrupted by the relay chain. The failure at the final hop is not definitive evidence of forgery; it is expected behavior when multiple gateways are in the path.

What it does mean for defenders is that the authentication result cannot be used as a clean pass to dismiss the message as low-risk. The ARC seal failure means the original authentication assertion cannot be independently verified at the final hop, which elevates the importance of content-layer and destination-layer analysis.

The Detection Gap This Attack Exploits

Phishing defenses anchored to domain reputation and authentication results cannot close this gap. Google Sites has excellent domain reputation. The authentication signals are ambiguous rather than clearly failing. The branding is professionally executed. The attacker has removed every signal that a rule-based or reputation-based filter would act on.

What remains is the structural mismatch between claimed sender (a health information exchange using Proofpoint) and actual link destination (Google Sites). Detecting that mismatch requires the detection layer to understand what destination a Proofpoint secure-message notification should produce, compare the actual destination against that expectation, and flag the divergence.

That is a behavioral and contextual judgment, not a signature match. Detecting email spoofing at the brand layer requires understanding what a legitimate Proofpoint notification looks like at the destination level, not just the sender level. The MITRE ATT&CK framework classifies this as Spearphishing Link (T1566.002). The Verizon DBIR 2026 identifies phishing as the leading initial access vector in breaches involving external actors. CISA guidance specifically calls out URL destination verification as a first-line defense, noting that attackers routinely exploit trusted third-party hosting to bypass gateway filters. The Microsoft Digital Defense Report 2024 identified a significant increase in adversarial use of legitimate cloud platforms for credential-harvest hosting.

For security teams, the operational takeaway is straightforward: train employees to verify link destinations against the expected domain for every security notification, regardless of how professionally the email is formatted. A Proofpoint notification that does not link to pphosted.com or proofpoint.com is not a Proofpoint notification.

---