Google Sites phishing is phishing content hosted on Google Sites pages that imitate a trusted service, login screen, or document share. The attacker uses a legitimate hosting domain to gain trust, then collects credentials, MFA codes, or other secrets through a fake form or link, often bypassing simple domain-based filtering.
How Google Sites phishing works
google sites phishing uses a legitimate Google-hosted page to borrow trust from a familiar domain while presenting a fake login, document share, or support prompt. The hosting platform is not the compromise, the abuse is in how attackers use a reputable service to make a malicious page look routine.
This pattern is effective because many users treat a trusted platform as a trust signal in itself. Once the victim lands on the page, the attacker can capture passwords, MFA codes, session-recovery details, or other secrets through a spoofed form or link.
Why it is effective against filters and users
Hosted-on-trusted-site phishing often slips past simple domain reputation checks because the page lives on a legitimate service rather than an obviously suspicious domain. That makes the lure appear less risky to users, email gateways, and quick manual reviews.
The real weakness is not Google Sites itself, but the mismatch between platform reputation and page intent. A phishing page can still be malicious even when the URL is tied to a known provider, especially when the attacker clones a sign-in flow or document handoff closely enough to reduce hesitation.
What the attacker is trying to capture
The immediate goal is usually credential theft, but the impact often extends further. If the fake page captures MFA codes, browser session data, API tokens, or recovery information, the attacker may gain direct account access or a path to reset access later.
That matters because phishing is often the entry point to broader compromise. Once an account is taken over, the attacker can move into inboxes, document stores, SaaS consoles, or other systems that trust the stolen session or the credentials obtained from the lure.
How organisations should respond to this pattern
Defence starts with user education, but it should not stop there. Organisations should validate suspicious pages against the actual source, inspect the hosting context, and treat any request for credentials or codes on a shared-hosting page as untrusted until proven otherwise.
Detection also needs to look beyond domain reputation. Monitoring should focus on credential submission pages, brand impersonation, unusual redirects, and reporting of newly observed hosted pages that mimic login or document workflows. For broader phishing tactics and layered defences, see the Phishing Guide and the Social Engineering Guide.
When a campaign is tied to lookalike pages or hosted impersonation, response should include takedown coordination, user reporting, and blocking the specific URL or page pattern. The Brand Impersonation and Lookalike Domain Takedown Playbook is useful for incident handling, even when the abuse is hosted on a legitimate platform rather than a rogue domain.
Risk and Threat Considerations
Google Sites phishing is risky because it combines social engineering with a trusted hosting layer, which can reduce user suspicion and delay detection. The technique is especially effective when the page asks for credentials, MFA codes, or other authentication material that can be used immediately.
Failure mechanism: The attacker exploits platform trust and visual similarity to trick the victim into submitting secrets to a page that looks legitimate but is controlled by the attacker.
Impact: Successful capture can lead to account takeover, session abuse, mailbox access, SaaS compromise, and follow-on theft of data or additional credentials.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V6 — Authentication | Phishing pages target login and secret capture, which directly affects authentication assurance. |
| V7 — Session Management | Captured MFA codes or session material can be reused to hijack authenticated sessions. | |
| Recommendation — Require phishing-resistant authentication and validate that login flows cannot be impersonated by hosted lookalike pages. Bind sessions tightly and detect suspicious reuse so stolen credentials cannot easily become active sessions. | ||
| NIST SP 800-63 | Digital Identity Guidelines | The term centers on phishing-resistant identity assurance and authenticators that resist hosted impersonation. |
| Recommendation — Prefer phishing-resistant authenticators and reject workflows that rely on secrets a hosted lure can capture. | ||
| MITRE ATT&CK | T1566 — Phishing | This term is a direct phishing delivery pattern that ATT&CK defines as a credential and access acquisition technique. |
| Recommendation — Map hosted impersonation pages to phishing detections and hunt for credential harvesting infrastructure. | ||
| CIS Controls v8 | CIS-5 — Account Management | Credential theft from hosted phishing often succeeds because account access can be abused before accounts are reset. |
| Recommendation — Harden account handling so stolen credentials and recovery paths are rapidly contained after phishing. | ||
Practitioner Guidance
What to watch for: Treat any hosted page that asks for login details, MFA codes, or document access as suspicious unless the flow is expected and independently verified. Pages that imitate a familiar service, but are reached through an unexpected message or redirect, deserve special scrutiny.
Governance implication: Security teams should define who can verify, report, and request removal of impersonation pages, because hosted phishing often needs coordinated response across email, browser, abuse, and brand-protection channels. Clear ownership shortens the time between discovery and takedown.
Related resources from NHI Mgmt Group
- How should security teams reduce account takeover risk from phishing sites?
- Why do legitimate Google and Microsoft redirects make phishing harder to stop?
- How should security teams reduce consent phishing risk in Microsoft 365 and Google Workspace environments?
- How should security teams respond when attackers use phishing and infostealers to gain persistence in Google accounts?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org