Borrowed Trust: Multi-Operator Abuse of Google Hosting

Across early 2026, at least eight unrelated scam operators hosted their phishing on Google-owned services to borrow the trust of Google's own domains. None of them shared sending infrastructure, victim pools, or pretexts. What tied them together was a single design choice: park the malicious artifact inside a path, object, bucket, form, or published script beneath a Google apex, and let domain reputation wave it through. Over a 90-day window we observed hundreds of thousands of email messages and hundreds of thousands of sponsored ads routing clicks through storage.googleapis[.]com, drive.google[.]com, sites.google[.]com, forms[.]gle, goo[.]gl, and their siblings. This report maps an abuse surface, not a single actor, and explains why that surface is so hard to price.

Key Takeaways

• At least eight unrelated operators abuse Google-owned hosting, sharing nothing beyond the trusted apex they all borrow.
• Domain reputation classifies at the host level, so a malicious artifact living in a path, object, bucket, form, or published script inherits Google's first-party trust and cannot be scored below the apex.
• No operator-registered domain exists to age, blocklist, or WHOIS-profile; takedown runs per-object against each provider, so the surface refills as fast as it is cleared.
• The dominant sending layer is a disposable-sender factory that burns roughly one throwaway envelope address per message, alongside a smaller named Yandex fleet and per-cluster gmail and outlook burner pools.
• Two automated-provisioning signatures stand out: an incrementing sites.google[.]com/view/fixxNNNN counter and 33-to-34-character content-storage-download.googleapis[.]com virtual-host burners.

Background

The reason this surface works is structural. Domain and URL reputation systems key on the registrable domain or host, and every apex in scope here (google[.]com, googleapis[.]com, web[.]app, firebaseapp[.]com, goo[.]gl, and the zapiermail[.]com relay) is Google-owned or Zapier-owned and legitimately high-reputation. No filter can blocklist those wholesale without breaking core services. On the shared hosts, the malicious content is a path, object, bucket, form, or published script, which sits below the granularity at which host-level reputation classifies. The scam content inherits the parent's trust score, and there is no dedicated attacker domain to register, age, or take down. Each cleanup removes one object while the trusted apex persists.

Several of the abused services deserve a plain-English note, because a reader should not have to guess why a Google URL shows up in a phishing report:

• Google Cloud Storage (storage.googleapis[.]com) exposes buckets and objects as URL path segments under one shared host. An attacker-uploaded HTML redirector inherits Google's host reputation, and because the malicious content is a path rather than a distinct host, per-bucket classification is effectively impossible. Public research from Paubox, GBHackers, and others has documented the redirect technique.
• Google Forms (forms[.]gle, backed by docs.google[.]com/forms) is a free form builder with TLS and Google branding by default, which makes it a cheap credential and data-harvest backend that rarely gets blocklisted. ESET, Sophos, and Malwarebytes have all written up the pattern.
• Google Sites (sites.google[.]com), Drive (drive.google[.]com), and Docs (docs.google[.]com) are free Google-hosted content services whose links pass domain-level filters on the strength of the Google host alone. Netskope Threat Labs has repeatedly documented Google Sites phishing and malware smuggling.
• Firebase Hosting and Auth (firebaseapp[.]com, web[.]app) and Google Apps Script (script.google[.]com) give developers free subdomains and publishable web apps on a Google domain with no browser warning. SecurityWeek, BleepingComputer, and Trustwave SpiderLabs have covered credential-capture and RAT delivery from these.
• goo[.]gl is Google's legacy shortener. New link creation stopped years ago, around 2018 to 2019, and the August 2025 milestone was a partial deactivation of links with no recent activity, not a full shutdown. Actively-used pre-existing short links still resolve, which is exactly what the relay-phishing cluster relies on.
• zapiermail[.]com is the domain Zapier uses for automation and transactional email. As a high-reputation relay it clears sender-reputation checks, and Zapier routes abuse reports to a dedicated phishing address.

Two of the pretexts also have well-documented public context. The callback-refund lure, a fake invoice or renewal notice carrying a phone number the victim is meant to call, is the subject of repeated FBI IC3 advisories: the "agent" on the line harvests banking data, requests remote access, and coerces a wire or prepaid-card "refund." The pig-butchering content drops map to the trust-development phase that the US Secret Service, TRM Labs, and Chainalysis describe, in which benign daily messages groom a target before any investment pitch appears.

Discovery and Infrastructure

We mapped the surface by profiling which Google-owned hosts carried meaningful scam volume, then clustering senders and click destinations beneath each one. The result was eight operator clusters that share the abuse surface and nothing else. The table below is the property map: what each host serves and the vertical it serves it for.

Google property (defanged)	Hosted artifact	Pretext / vertical
storage.googleapis[.]com	/<bucket>/<obf>.html#<hash> credential-phish landing (bucket is the artifact)	Rewards, gift-card, iPhone-giveaway, home-cash-offer, credit-score, class-action settlement
content-storage-download.googleapis[.]com	<33-34char>.content-storage-download.googleapis[.]com/... one-shot virtual host	Same credential-phish family, newer surface
drive.google[.]com	/file/d/<id>/view?usp=sharing PDF fake-invoice with a callback number	Callback-refund / pig-butchering onboarding
sites.google[.]com	/view/fixxNNNN provisioned subpages, incrementing counter	Adult / escort lure ring
docs.google[.]com + forms[.]gle	Forms backend and URL-in-subject content drops	Pig-butchering, data-harvest surveys, ebook lures
goo[.]gl	Surviving short links used as CTA	Relay-origin commission and email-validation phish
firebaseapp[.]com / web[.]app	<sub>.firebaseapp[.]com/__/auth/action	Overwhelmingly legitimate Firebase Auth; a small minority abused
script.google[.]com	Published Apps Script endpoints	Rare, high-signal edu-impersonation funnels

The sending layer splits cleanly by cluster. The largest cluster feeds storage.googleapis[.]com from a sprawl of disposable throwaway envelope domains, roughly one address per message. A smaller, named Yandex fleet of 20 burner addresses runs its own set of GCS buckets with brand-homoglyph display names. The sites.google[.]com adult-lure ring sends from gmail burners whose display name is the local part verbatim. The Drive callback-refund cluster uses one-shot gmail burners. The content-storage-download.googleapis[.]com surface pairs each virtual host with a one-shot outlook or hotmail composed-word burner. The relay cluster originates from just three no-reply.<6char>@zapiermail[.]com aliases.

Sending layer	Cluster(s)	Footprint
Disposable throwaway domains	GCS mass fleet, forms/docs harvest	Many thousands of one-shot addresses, ~1 per message
yandex[.]ru	Named GCS fleet	20 burner addresses, brand-homoglyph display names
gmail[.]com	fixxNNNN adult lure, Drive callback-refund, cross-property	Per-message burners; 3 genuine cross-property operators
outlook[.]com / hotmail[.]com	content-storage-download surface	Composed-word one-shot burners
zapiermail[.]com	Relay phish	3 no-reply.<6char>@ aliases

How It Works

The Google Cloud Storage chain is the highest-volume path. A burner sends a rewards or gift-card lure with a homoglyph brand display name, and the call to action points at storage.googleapis[.]com/<bucket>/<file>.html#<hash>. The bucket holds an HTML redirector, and the fragment after the # carries a base64 handle that personalizes the landing page. Because the URL host is a trusted Google apex and the bucket is only a path segment, domain reputation has nothing below the apex to price.

The Drive chain trades the redirector for a document. A one-shot gmail burner sends a subject built from invoice, purchase, or transaction language, and the call to action is a drive.google[.]com/file/d/<id>/view PDF. The PDF is a fake invoice naming a randomized buyer and a callback phone number, which moves the victim off email and onto a phone call where the refund social-engineering plays out.

The sites.google[.]com ring is the clearest example of automation. Every message lands on sites.google[.]com/view/fixxNNNN, where the four-digit suffix increments over time. Watching the counter climb is watching the operator provision new subpages on a schedule.

The cross-property cluster is the rarest and highest-signal pattern. Three operators rotate the same content drop across docs.google[.]com, forms[.]gle, and a surviving goo[.]gl short link, delivering identical daily-affirmation or ebook material as the grooming stage of a longer con. The relay cluster originates phishing from zapiermail[.]com aliases and hides the destination behind a goo[.]gl or t[.]ly short link.

Sample Lures

All recipient identifiers are redacted and every host is defanged. These are attacker-side artifacts only.

Google Cloud Storage credential-phish (Yandex fleet), a rewards lure with a homoglyph display name:

From: "Congratulations" <nananmayorchi@yandex[.]ru>
Subject: Congratulations [recipient name], You have won a FREE iPhone 17 Pro
CTA:  hxxps://storage.googleapis[.]com/hqyoqzatqthj/aemmfcylvxeo...html#[base64 recipient handle]

Drive callback-refund invoice, a fake-transaction pretext moving the victim to a phone call:

From: <countrybunnyhungconical@gmail[.]com>
Subject: Alert Report: Purchase Transaction Authenticated by [recipient name]
CTA:  hxxps://drive.google[.]com/file/d/[file-id]/view?usp=sharing
      (PDF invoice, randomized buyer name, callback phone number)

Google Sites adult-lure ring, showing the incrementing counter:

From: "kaylamichaelsm" <kaylamichaelsm@gmail[.]com>
Subject: Male Escort Job
CTA:  hxxps://sites.google[.]com/view/fixx4689

Cross-property pig-butchering content drop, the grooming-stage daily message:

From: <erickngwese873+cc@gmail[.]com>
Subject: Your Day Ahead [date]
CTA:  hxxps://forms[.]gle/[8-char]  (alt: hxxps://docs.google[.]com/forms/d/e/[FAIpQLS...]/viewform)

Zapier-relay phish behind a surviving short link:

From: "Linklinks" <no-reply.bvcq0n@zapiermail[.]com>
Subject: (BOOM!) VALIDATE Your Email To Access Account [BOMB!]
CTA:  hxxps://goo[.]gl/[short-code]

On Facebook, the same trust-laundering logic appears without quotable body text. Education-persona sponsored ads (for example a teacher-branded profile) run a Spanish "Enviar mensaje" call to action and route clicks to drive.google[.]com/file/d/<id>/view documents, using the Google host to slip past ad-review URL classification. SMS carried a negligible presence across these properties in the window.

Technical Analysis

Trust Laundering Below the Host Line

The unifying mechanic is that the abuse unit sits one level below where reputation can see. On GCS the abuse unit is a bucket, a path segment under storage.googleapis[.]com. On Forms it is a form ID under docs.google[.]com. On Drive it is a file ID. On Sites it is a /view/ subpage. On Apps Script it is a published deployment. Each of these renders as first-party Google content, with a valid Google TLS certificate and no browser warning, and each is invisible to a reputation engine that stops at the host. A recurring cosmetic trick amplifies the effect: hxxps://<random>@storage.googleapis[.]com/<bucket>/<file>.html uses the URL userinfo field so a human skims the <random> token as a subdomain of a trusted host.

GCS Bucket Naming Grammar

Buckets fall into three naming families. The split matters because the buckets are long-lived and shared while the senders are burned per message, so bucket grammar is one of the few durable fingerprints on this surface.

Family	Structure	Example buckets (defanged)
A. Keyboard-mash / random-string	No linguistic structure; rolled keys, repeated characters, hex-ish runs	hjhjjhhj10hj0hjjh..., rrrrrrrrrrrrrrrrr, vcxbiuouioui, sd6514s6589dsd, dqsdqdqsdq, bnfdddddddddddd, qd4q896dssddd
B. English-word / pseudo-word disguise	Readable, brandable-looking single or compound words	salmonnais, traditionall, bobalomaniaz, arsenalpart, legodream, selectoring, boxtelecom, marketlo, linkon, adsurf
C. Fixed-length base32-style	~15 to 20 lowercase alphanumeric	5mvtqhtox15dnaiw, 2io1upuza2hbewny, ztcmfltzkqyjneshxx, peztizeu8qsesffsgueit

The top buckets show a near one-to-one ratio of messages to distinct senders, which is the signature of one bucket serving a large disposable-sender pool. New buckets in both Family A and Family B kept appearing well past the initial mapping window, so the surface is replenished, not static.

The Disposable-Sender Factory

The dominant sending layer is not a named fleet. It is a throwaway-address factory that issues roughly one envelope domain per message and never reuses it. There is no registrable structure worth cohorting: the addresses are burned, not built. The TLD distribution has a clear shape, led by .us, then .com, followed by a long tail across .biz, .net, .uk, .id, .de, .me, .cl, and a scattering of .info, .org, .in, .live, .sbs, and .art. Display names lean on unicode homoglyphs and styling to fake brand strings (mathematical-alphanumeric PayPal and Fidelity variants, small-caps McAfee, enclosed-letter and emoji brand marks) alongside pretext tags like settlement, lawsuit-payment, and unclaimed-funds language.

Automated Provisioning Signatures

Two clusters leave machine-generated fingerprints. The sites.google[.]com adult-lure ring mints subpages on a monotonically incrementing counter, /view/fixxNNNN, and the suffix climbs by roughly 200 to 250 per month. The counter is the provisioning odometer, and it ran continuously across the full timeline.

Week	Distinct fixx subpages minted	Suffix range
2026-04-13	10	fixx4661 to fixx4693
2026-04-27	14	fixx4723 to fixx4756
2026-05-25	11	fixx4806 to fixx4849
2026-06-15	15	fixx4914 to fixx4980
2026-06-29	19	fixx5001 to fixx5113
2026-07-13	4	fixx5145 to fixx5156

The full observed range runs fixx4303 to fixx5156, roughly 625 subpages minted across the window and still climbing at the time of writing. The second signature is the content-storage-download.googleapis[.]com surface: each virtual host is a base32-style prefix, typically 33 to 34 characters (observed range 20 to 39), single-use, and paired to a one-shot composed-word freemail burner following a <name1><name2><4digits>@<freemail> grammar. The burner pool broadened from outlook[.]com alone to include hotmail[.]com and outlook[.]it as the surface scaled.

Callback-Refund and Cross-Property Content Drops

The Drive callback-refund kit shares a name-randomizer component across senders: the same buyer-name generator populates fake invoices behind drive.google[.]com/file/d/<id>/view PDFs, each carrying a callback number. The cross-property operators are the rarest signal on the whole surface. Only three senders used two or more Google properties with sustained activity, rotating docs.google[.]com, forms[.]gle, and goo[.]gl to deliver identical grooming content. Everything else is single-property, which makes the cross-property trio worth naming as high-value pivots rather than the dominant pattern.

Registration Cohorts: A Null Set by Design

The most telling infrastructure fact is what is absent. There is no operator-registered CTA or landing domain anywhere in scope, so the usual registrar and creation-date cohort analysis returns nothing. The entire hosting and CTA layer sits on Google-owned apexes plus the Zapier relay, all of which resolve to legitimate Google and Zapier registrations. The only non-Google apex we found (an aged affiliate click-tracker registered in 2017 through a mainstream registrar) is a shared traffic broker, not operator infrastructure, and the two educational domains in the data are compromised third-party Google Sites tenants, not operator registrations. The absence of a registration cohort is the point: trust is borrowed wholesale from Google, so there is nothing to fingerprint at the registrar level and nothing to blocklist at the domain level.

Detection Observations

The behavioral signals that separate this traffic from legitimate Google-hosted content are structural, not reputational. A defender keying on domain reputation gets no help here, because the malicious artifact lives below the host line. What does carry signal:

• The GCS shape storage.googleapis[.]com/<bucket>/<file>.html#<hash> combined with a freemail or throwaway sender is a strong pattern, especially when the fragment carries a base64 handle.
• A URL userinfo token in front of a trusted host, <random>@storage.googleapis[.]com, has no legitimate use in this context.
• sites.google[.]com/view/fixx[0-9]{4} is a single-operator fingerprint on its own.
• A drive.google[.]com/file/d/<id>/view link paired with an invoice, purchase, or transaction subject and a one-shot freemail sender is the callback-refund shape.
• A no-reply.<6char>@zapiermail[.]com alias whose only call to action is a shortener is anomalous for a transactional relay.
• Brand-homoglyph display names, roughly one throwaway sender per message, and 33-to-34-character content-storage-download.googleapis[.]com subhosts are all high-signal on their own.

One caution runs the other way. The majority of firebaseapp[.]com traffic is legitimate Firebase Auth mail from small SaaS operators, so presence of that host alone is a weak signal and should not be treated as inherently malicious.

Indicators of Compromise

The hosting and CTA layer of this campaign is entirely Google-owned or Zapier-owned, so there are no operator-registered domains, hosts, or URLs to publish. Publishing the Google apexes would be meaningless and harmful. The durable operator-controlled indicators are the burner sending addresses, a representative subset of which is below. All are defanged.

Senders

Value	Cluster	Notes
team.s.upp.ort@yandex[.]ru	GCS credential-phish	Named Yandex fleet, dotted-alias evasion
nananmayorchi@yandex[.]ru	GCS credential-phish	Homoglyph "Congratulations" display name
google.reward@yandex[.]ru	GCS credential-phish	Reward-lure alias
kaylamichaelsm@gmail[.]com	Sites adult lure	Display name equals local part
cheirjakson@gmail[.]com	Sites adult lure	fixxNNNN counter burner
shannonandrews2928@gmail[.]com	Sites adult lure	fixxNNNN counter burner
countrybunnyhungconical@gmail[.]com	Drive callback-refund	Fake-invoice PDF, callback number
tstydyfufuvuvivkboboblb445@gmail[.]com	Drive callback-refund	One-shot burner
costcofha@gmail[.]com	Drive callback-refund	Brand-token local part
erickngwese873+cc@gmail[.]com	Cross-property pig-butchering	docs + forms + goo[.]gl content drop
irmahowell7@gmail[.]com	Cross-property pig-butchering	docs + drive ebook lure
chuelements@gmail[.]com	Cross-property pig-butchering	Art-scam persona content drop
no-reply.bvcq0n@zapiermail[.]com	Zapier-relay phish	Operator-configured relay alias
no-reply.dajri9@zapiermail[.]com	Zapier-relay phish	Operator-configured relay alias
no-reply.bj912x@zapiermail[.]com	Zapier-relay phish	Operator-configured relay alias
...		(representative subset; 100+ verified-malicious sender addresses)

MITRE Fight Fraud Framework Mapping

The mapping aligns to the MITRE Center for Threat-Informed Defense Fight Fraud Framework (F3 v1.1, the MITRE Fight Fraud Framework (F3) at https://ctid.mitre.org/fraud). F3 reuses ATT&CK tactic and technique IDs (TA#### / T####) and adds fraud-native tactics (Positioning FA0001, Monetization FA0002) and fraud-specific F1xxx techniques. Trust laundering via reputable hosting has no dedicated technique in v1.1, so it maps most defensibly to Stealth plus Create Fake Materials.

Tactic	Technique	ID
Reconnaissance (TA0043)	Gather Customer Information	F1029
Resource Development (TA0042)	Create Fake Materials: Fake Website	F1020.002
Resource Development (TA0042)	Establish Accounts	T1585
Initial Access (TA0001)	Phishing	T1660
Stealth (TA0005)	Impersonate Official	F1032
Stealth (TA0005)	Impersonate Account Holder	F1031
Stealth (TA0005)	Email Spoofing	T1672
Initial Access (TA0001)	Account Takeover: Exposed Login Credential	F1006.002
Positioning (FA0001)	Account Manipulation: Change of Payment Details	F1005.006
Monetization (FA0002)	Convert to Cryptocurrency	F1018
Monetization (FA0002)	Electronic Funds Transfer: Wire Transfer	F1025.003

Conclusion

This surface is durable because it inverts the economics of takedown. The operators spend nothing on domains and inherit trust they did not build, while defenders and providers must clear artifacts one bucket, form, file, or subpage at a time. The strongest pivots are the ones the operators cannot outsource to Google: bucket naming grammar, the incrementing site counter, the fixed-length virtual-host burners, and the throwaway-sender cardinality. Watch the fixxNNNN odometer and the content-storage-download.googleapis[.]com subhost pool for scale-up, and treat any credential-capture chain that renders as first-party Google content as a reputation blind spot to be closed with content and behavioral signals, not domain scores.