Threat analysis: Google Sites phishing that fools password managers via sites.google.com
Threat analysis of a Google Sites phishing kit reported by @VincentBounce: spoofed Google ‘app password / security alert’ mail, landing on sites.google.com/view/delete-new-app with CAPTCHA theatre, credential forms that trigger password-manager autofill, and mailed-by fwd.privateemail.com instead of Google bounce hosts. Includes IOCs and defender checklist.
A public incident report from researcher Vincent Bounce (@VincentBounce, 1 October 2026) documents a high-quality Google-themed phishing chain that abuses legitimate Google Sites hosting, spoofed “Security alert / App password created” email framing, a CAPTCHA interstitial, and password-manager autofill conditioned on the trusted sites.google.com apex. The lure claimed third-party access had been created for an unknown Gmail user and pushed victims toward a credential harvest hosted under google.com infrastructure, not a lookalike domain.
This analysis treats the thread as an open-source incident report. Indicators below are for detection and awareness; do not visit live phishing paths from production browsers.
Attack narrative (observed)
1. Delivery: Victim receives a Gmail-looking “Security alert” stating an app password was created / third-party access was generated for an unknown @gmail user. Display From: Google <no-reply@accounts.google.com>. Gmail UI may show no obvious phishing banner.
2. Primary CTA: Link points to https://sites.google.com/view/delete-new-app (also observed with ?pli=1&authuser=0). A secondary legitimate-looking link to https://myaccount.google.com/notifications may appear to reinforce trust.
3. Credibility theatre: Landing page presents as google.com “Performing security verification” with a reCAPTCHA / “I’m not a robot” challenge (Ray ID visible in screenshots), mimicking bot checks used on real Google properties.
4. Credential capture: After the check, a Google-styled “Sign in with your Google Account” form is served on sites.google.com, not a redirect to accounts.google.com.
5. Password-manager assist: Because the victim has (or had) a legitimate sites.google.com / Google Sites credential saved, managers such as 1Password offer autofill on the phishing page. That is the critical UX failure: same-registrable-domain trust for a content-hosting product colliding with an authentication UX that should only live on accounts.google.com.
6. Suspected next step: Thread replies note 2FA / passkey challenges may follow; reporter stopped before submitting credentials. A later screenshot shows a “Verifying it’s you… Complete sign-in using your passkey” style prompt, treat as part of the social-engineering continuum even if not fully completed in the report.
Why this is dangerous
- Trust inheritance: Hosting on sites.google.com puts the phishing page on a real Google TLS certificate and a google.com-owned hostname users are trained to trust.
- Autofill collision: Password managers that match on sites.google.com (or broad google.com rules) will happily fill Google credentials into an attacker-controlled Sites page.
- Mail authenticity theatre: Display From and signed-by can look Google-adjacent while mailed-by reveals third-party relay infrastructure.
- Low friction for “Mrs. Smith”: Subtle CTA layout differences (plain link vs Google’s large blue button) and mailed-by hostnames are weak signals for non-experts.
Key indicators of compromise (IOCs)
Indicator | Role / Significance |
|---|---|
sites.google.com/view/delete-new-app | Phishing / credential-harvest path |
sites.google.com/view/delete-new-app?pli=1&authuser=0 | Same phishing path with Google Sites query parameters |
fwd.privateemail.com | Suspect mailed-by infrastructure, contrasted with legitimate Google bounce infrastructure |
Display From: no-reply@accounts.google.com + Mailed-by: fwd.privateemail.com | Spoofed Google security-alert pattern |
identity-reachout.bounces.google.com | Legitimate Google mailed-by infrastructure example for comparison |
gaia.bounces.google.com | Legitimate Google mailed-by infrastructure example for comparison |
Detection tip: In mail gateways and SOC playbooks, correlate Google-branded security alerts where mailed-by is not in Google’s known bounce/mailer set AND any click landing on sites.google.com/view/* authentication-looking pages.
Defender / user checklist
- Never enter Google account passwords on sites.google.com. Legitimate re-auth and OAuth live on accounts.google.com (and related Google identity endpoints), not Sites pages.
- Before acting on “app password / third-party access” alerts, open myaccount.google.com/security from a bookmark or typed URL, do not use in-mail links.
- Inspect Gmail “Show original” / message details: mailed-by and signed-by. Treat fwd.privateemail.com (and similar third-party relays) as high risk for Google-branded security mail.
- Password-manager hygiene: Prefer exact-domain matching for accounts.google.com; avoid saving primary Google passwords against sites.google.com; disable autofill on untrusted Google Sites paths.
- Assume CAPTCHA on a Sites URL is theatrical, not proof of authenticity.
- If credentials were entered: revoke sessions, change password from a known-good device, review third-party access and app passwords, enable / verify 2FA or passkeys, and report to Google phishing reporting channels.
Threat-analyst assessment
This is not novel malware. It is high-quality abuse of platform trust: Google Sites as a free, cert-valid phishing host + email spoofing that survives casual visual inspection + password-manager same-site autofill. Severity for credential compromise is high if the victim completes the flow; detection depends on mailed-by scrutiny and a hard rule that Google login never happens on Sites.
Organizations should add Sites-hosted Google lookalike login pages to URL filtering and user training, and treat “app password created” lure kits as an active theme.
Written by: OSINT Researchers, Ministry of Cyber Affairs