Google Sites Phishing: How Attackers Abuse Trusted Infrastructure

Threat actors no longer need to register a convincing lookalike domain or defeat HTTPS warnings to deliver malware, when they can use sites.google.com instead. This is a documented attack pattern PhishFort has tracked over recent months: highly targeted social engineering campaigns that exploit the implicit trust users place in Google-hosted URLs to deliver infostealers, crypto wallet drainers, and Account Takeover (ATO) modules — all from infrastructure Google provides for free.

How the Attack Works: The Google Workspace Invite Scam

The attack chain is deceptively simple. Its power comes entirely from the Google brand doing the heavy lifting on trust.

Step 1: The approach

A threat actor operating under an alias (we’ve seen handles like @Rich_Generous_VC on X) contacts a target to schedule a business call, interview, or investment conversation. The pretext is tailored. These are not spray-and-pray phishing emails.

Step 2: The pivot

Immediately before the scheduled call, the actor insists the target join their “Google Workspace” to proceed. The link lands on sites.google.com/view/workspace-connection/invite a similar path. The URL is SSL-certified, hosted on a Google subdomain, and passes every standard web filter without complaint.

Step 3: The inversion

Here is where the social engineering diverges from standard phishing. Instead of asking the victim to log in with their own credentials, the attacker provides their own email address and a unique “join code.” The victim is instructed to enter these supplied credentials into the fake portal.

Step 4: Payload delivery

The moment the victim interacts with the portal, the trap executes. Depending on the variant, the payload includes a combination of: a credential-harvesting infostealer, a crypto wallet drainer targeting browser-stored seed phrases and session tokens, and an ATO module designed to propagate access across connected accounts.

The inversion of credential flow (attacker-supplied, not victim-supplied) is deliberate. It bypasses the mental model most users apply when evaluating phishing risk: I didn’t enter my password, so I’m safe. They’re not.

Caught in the Act: What the Chat Log Reveals

The most operationally useful signal in a recent case PhishFort reviewed came not from the malware sample but from a chat log between the attacker and an intended victim who was smart enough to open the link inside a virtual machine.

The attacker, operating as “Liam” with the domain quantametrics[.]co, provided his email and a bogus join code (k9p2...) with instructions to use them on his Google Sites page. When the victim reported the link wasn’t functioning, the attacker’s immediate response was: Is it a VM?

Malware operators despise sandbox environments because modern infostealers include VM detection routines. If the payload identifies a virtualized environment, it either refuses to execute or generates no useful data for the operator. The attacker asking about VMs before asking about the link itself confirms: he knew the payload was there, he knew it was VM-sensitive, and he panicked when execution failed. This was not a technically sophisticated operator. The sophistication was in the social engineering pretext, not the malware. This makes detection and disruption entirely achievable if the platform cooperates.

Why This Works: The LOTL Advantage on Google Infrastructure

Living off the Land (LOTL) as a technique originated in endpoint tradecraft — attackers using legitimate OS binaries (PowerShell, WMI, certutil) to execute malicious actions without dropping detectable payloads. The principle has migrated to phishing infrastructure.

📖 Go deeper on this topic: Living off the Land Attack Phishing

By hosting attack pages on sites.google.com, threat actors gain:

Standard phishing detection relies heavily on domain age, registrar reputation, and certificate issuance patterns. A sites.google.com URL has none of those signals. It was registered in 1997. It has a perfect reputation. It has an EV-equivalent trust posture in most enterprise environments. This is a gap in the platform’s abuse enforcement, not the defender’s toolkit.

The DPRK Copycat Attribution Question

The TTPs observed in this campaign pattern — fabricated VC or recruiter personas, pre-call platform pivots, crypto-focused payload objectives — overlap significantly with documented DPRK-affiliated threat actor behavior, particularly clusters associated with IT worker fraud and Lazarus Group-adjacent operations.

The critical distinction: these are likely copycat actors, not state-sponsored operators themselves. Groups that study and replicate DPRK tradecraft have proliferated over the past 18 months, particularly in targeting Web3 professionals and crypto holders. The social engineering scripts, the persona construction on X and LinkedIn, and the payload objectives (wallet drainage, not espionage) are consistent with financially motivated imitators rather than state intelligence collection.

Attribution affects response strategy. Against genuine DPRK actors, takedown velocity matters less because infrastructure rotation is near-instantaneous and state-backed. Against copycat financially motivated actors, takedown velocity matters enormously — these operators reuse infrastructure, rely on longer-duration personas, and are far more exposed to disruption once a campaign is identified.

What Google Can and Should Do

This is not a novel capability request. Google already has:

• Real-time content scanning across Google Sites at creation time
• ML-based abuse detection in Gmail and Drive that flags malicious content
• Legal precedent: Google recently announced legal action against fraudsters abusing Gemini and other Google products

The same detection logic applied to Drive malware should apply to Sites pages impersonating Workspace login flows. The signal pattern is not subtle: a Sites page with credential input fields, a Google Workspace visual template, and no verified organizational owner is a detectable configuration.

Google has stated publicly that infrastructure abuse is in scope for its enforcement actions. Sites-hosted phishing portals should be an obvious inclusion. Until enforcement catches up, the attack surface remains open.

How to Protect Yourself and Your Organization

Platform accountability aside, the practical mitigation set is clear.

Control your own meeting infrastructure. If someone insists you join their platform via a link they control, that is a social engineering flag. Set up meetings through channels you own.

Never use attacker-supplied credentials. If someone asks you to log into any portal using their email address and a “special code,” stop. This is not a legitimate workflow that exists anywhere in enterprise software. It is a scam, without exception.

Don’t trust the Google brand on the URL alone. sites.google.com/view/anything is user-generated content. Anyone can create a site there in three minutes. The google.com domain tells you nothing about the page content.

Use a sandbox for unverified links. As the chat log above demonstrates, opening suspicious links in a Virtual Machine frustrates payload execution and protects your primary environment. Browser-based sandboxes (ANY.RUN, Browserling) work for quick triage when a full VM setup isn’t practical.

Monitor for platform impersonation. If your organization’s brand, product name, or executive names are being used in fabricated “workspace invite” pretexts, you need visibility into that before your customers and partners become victims. That’s a brand monitoring problem, not just a security awareness problem.

FAQ

For organizations seeing their brand used in Google Sites impersonation campaigns, PhishFort’s phishing takedown services cover hosted-platform abuse, including sites.google.com pages.