Living Off Google: Firebase Auth Abuse in a Reward-Phishing Operation

From mid-May through late June 2026, one operator ran a $50-reward credential-phishing operation hosted entirely on Google infrastructure. Every lure was delivered by Google's own mail servers, every click landed on a Google-owned domain with a valid Google TLS certificate, and every message passed SPF, DKIM, and DMARC because it was genuine Google-originated mail. The operator never registered a sending domain and never stood up a web server. Instead they provisioned a fresh Google Firebase project roughly once a day, let Google send the phishing email, and parked one credential-harvest page in a public Google Cloud Storage bucket. The result is a campaign that authenticates cleanly and inherits the reputation of the platform it abuses.

Key Takeaways

• A single operator ran a "$50 welcome reward" credential-phishing operation for about six weeks entirely on Google infrastructure, delivering hundreds of reward-themed messages that all authenticated cleanly against SPF, DKIM, and DMARC.
• One rail abused Firebase Authentication's passwordless email sign-in link, which makes Google itself send the phishing email; the link's continueUrl parameter then bounced victims to an off-platform credential page. We found no prior public writeup of this specific delivery-plus-redirect abuse.
• The durable correlator is the destination, not the sender: one Google Cloud Storage credential-harvest object held constant across a sender-prefix change, a delivery-mechanism change, and two bucket migrations.
• The operator burned roughly one fresh Firebase project per day across more than 50 project hosts, so each sending host was effectively single-use and never accrued reputation.
• A late-June pivot dropped Google senders for self-registered random-string apex domains configured to pass SPF, DKIM, and DMARC, the operation's first self-owned and therefore independently blockable sending infrastructure.

Background

The operation surfaced as a cluster of reward-themed lures whose senders all resolved to firebaseapp[.]com project subdomains, with click destinations split between firebaseapp[.]com and storage.googleapis[.]com. Those are all Google properties, which is exactly why the cluster is worth documenting: it is a case study in "living off Google," where an attacker sources trust from a platform rather than building it.

Three Google surfaces do the work here, and each has a history of phishing abuse on its own.

Firebase Hosting gives every project an automatic <projectid>.firebaseapp[.]com subdomain, served over Google's CDN with a valid, auto-issued TLS certificate. Attackers like it because a landing page there inherits Google's parent-domain reputation and a trusted certificate, so the domain-age and certificate heuristics that normally flag freshly registered phishing infrastructure return benign. Spinning up a new project, and therefore a new subdomain, is free and near-instant. Vendors including Check Point and eSentire have documented Firebase Hosting abuse for credential phishing and malware delivery.

Google Cloud Storage lets anyone create a bucket and mark an object publicly readable. A public HTML object is then reachable at storage.googleapis[.]com/<bucket>/<object>.html and renders in the browser. Attackers host the actual credential-harvest page here because the URL sits on a high-reputation Google apex with a valid Google certificate, so URL-reputation and category filters that would block a bare attacker domain wave it through. Trustwave SpiderLabs described this "phishing in a bucket" pattern on Firebase Storage as far back as 2020, and researchers at Certfa Lab and others have tracked the Cloud Storage variant since.

Firebase Authentication is the piece that makes this campaign more than a hosting story, and it is covered in the technical analysis below.

Discovery and Infrastructure

The cluster was mapped by pivoting across sender addresses and click destinations rather than trusting any single field. The operator's mail lands under two different registered domains depending on the rail: firebaseapp[.]com for the sign-in-link rail and googleapis[.]com for the direct-storage rail. A pivot keyed only to the host in the lure would have under-counted the operation by half. Correlating sender address, click host, click domain, and the resolved landing URL together exposed both rails and bound them to one operator.

Three delivery rails emerged, all funneling to the same credential-harvest backend on Google Cloud Storage.

Rail	Sender pattern	Delivery mechanism	Landing object
A	payment@<projectid>.firebaseapp[.]com	Direct link to a Cloud Storage object	storage.googleapis[.]com/{freecachoffers,static-assets-v1}/e4e7f24a14bd43fb[.]html
B	noreply@<projectid>.firebaseapp[.]com	Firebase passwordless-auth action link	storage.googleapis[.]com/static-assets-v1/e4e7f24a14bd43fb[.]html
C	alert-NN@<18-random-char>[.]com	Direct link from an operator-owned apex	storage.googleapis[.]com/uniforcesma/sefdaa[.]html

Rails A and B ran on Google-provisioned senders that cannot be blocklisted without blocking Google's own Firebase relay. Rail C, which appeared on 2026-06-22, is different: the operator registered its own apex domains and configured mail authentication on them, so those two domains are the campaign's first assets a defender can flag directly.

The operator's footprint across the run is substantial for a single actor. More than 50 distinct Firebase project hosts appeared in the corpus (about 30 as observed senders and another 21 seen only as Cloud infrastructure), all consistent with a provisioning cadence of roughly one new project per day. Two operator-owned apex domains carried Rail C. The whole operation converged on just three Cloud Storage landing objects, and two of those share a single object name across different buckets. Across the run it delivered hundreds of reward-themed messages.

How It Works

A victim receives a reward-themed email. On the earliest rail the subject reads Verify your email for 50$ Reward Distribution or Reset your password for 50$ Reward Distribution. The message carries a link straight to a Cloud Storage object, with the victim's email address appended as a URL fragment so the credential form arrives pre-populated.

On the June rail the pretext shifts to a sign-in framing. The subject becomes Sign in to get $50 welcome reward requested at <UTC timestamp>, and the message is a genuine Firebase Authentication sign-in email that Google delivered on the operator's behalf. The link is a real Google action URL on the project's own subdomain. When the victim clicks, Firebase processes the action and then redirects to the continueUrl value, which the operator set to the same Cloud Storage credential page. The Google-branded auth email and the Google action URL do the trust-building; the credential theft happens one redirect later, off-platform.

The late-June rail keeps the sign-in subject verbatim but drops Google as the sender. It arrives from alert-NN@<random-string>[.]com, an operator-registered apex with SPF, DKIM, and DMARC configured to pass, and links directly to a fresh Cloud Storage object. Same lure, same backend family, different sending infrastructure.

Sample Lures

All samples are attacker-side content only. Recipient identifiers have been redacted and all domains and URLs defanged.

Rail A, direct-to-storage (mid-May):

From: payment@freecashearn-267986-i0.firebaseapp[.]com
Subject: Reset your password for 50$ Reward Distribution

Link: hxxps[:]//storage.googleapis[.]com/static-assets-v1/e4e7f24a14bd43fb[.]html#[recipient email]

Rail B, Firebase passwordless-auth sign-in link (mid-June):

From: noreply@fctm-441649-5d.firebaseapp[.]com
Subject: Sign in to get $50 welcome reward requested at 2026 June 16 01:31 UTC

Link: hxxps[:]//fctm-441649-5d.firebaseapp[.]com/__/auth/action?apiKey=...&mode=signIn
      &oobCode=...&continueUrl=hxxps[:]//storage.googleapis[.]com/static-assets-v1/
      e4e7f24a14bd43fb[.]html#[recipient email]&lang=en

Rail C, operator-owned authenticated apex (late June):

From: alert-80@h9rlebyelatbfp29bw[.]com
Subject: Sign in to get $50 welcome reward requested at <UTC timestamp>

Link: hxxps[:]//storage.googleapis[.]com/uniforcesma/sefdaa[.]html#[recipient email]

Technical Analysis

Firebase Authentication as a Mail Cannon

The most interesting rail weaponizes a legitimate developer feature. Firebase Authentication offers a passwordless flow in which a developer calls sendSignInLinkToEmail(email, actionCodeSettings) and Google sends the sign-in email from its own infrastructure. The link points at the project's default action handler:

hxxps[:]//<projectid>.firebaseapp[.]com/__/auth/action?mode=signIn&oobCode=<code>&continueUrl=<url>

The continueUrl value is the destination Firebase bounces the user to after processing the action, and it accepts an arbitrary off-platform address. The operator registers a Firebase project, calls the sign-in-link API against a target list, and lets Google deliver a real, fully authenticated auth email. Because continueUrl points at an attacker-chosen page, the "sign-in" funnels the victim to the Cloud Storage credential form while the initiating email carries Google's sender identity. Firebase's own documentation warns developers not to reflect user-controlled data through these action links, but the redirect behavior is by design. We found no dedicated public writeup of this precise abuse: an attacker using Google's own auth mailer to deliver an authenticated phishing email that redirects off-platform through continueUrl. Treat it as an emerging delivery pattern, not a settled one.

Project-Burn Provisioning and the Naming Grammar

The operator provisions Firebase projects on a fixed, machine-generated grammar. Project IDs follow <theme-prefix>-<6 digits>-<2 chars>, for example fctm-441649-5d, after an earlier generation that used an 8-character random suffix such as freeearn-0uynvjdp. The theme prefixes draw from a small free-cash lexicon and contracted over the run as the operator streamlined naming.

Window	Suffix generation	Theme prefixes in use	Example project host
2026-05-13 to 05-24	8-char random	freeearn, freecash, frcash	freeearn-0uynvjdp.firebaseapp[.]com
2026-05-25 to 06-01	-NNNNNN-xx numeric plus 2 chars	freefrcasshh, fcteam, freecashtm, frcashop, freecashearn	fcteam-692717-ha.firebaseapp[.]com
2026-06-02 to 06-22	-NNNNNN-xx numeric plus 2 chars	contracted to fctm, fc4, fcteam (with a freecash bridge)	fctm-441649-5d.firebaseapp[.]com
2026-06-22 to 06-23	random-consonant apex, off-Firebase	not applicable	h9rlebyelatbfp29bw[.]com

One fresh project per day means each sending host is single-use, which defeats per-project takedown and stops any host from accruing the reputation history that would eventually flag it.

Registration Cohorts: Purpose-Built Senders, Aged Hosts

The registration data draws a clean line between the infrastructure the operator built and the platform it borrowed. The operator's own Rail C apexes were registered on consecutive days and went operational the same day, with WHOIS fully scrubbed and no aging window whatsoever. The Google properties they ride on are 14 to 21 years old and registered to Google.

Entity	Role	Registered / created	WHOIS	Notes
h9rlebyelatbfp29bw[.]com	Rail C sender apex	2026-06-22 (live same day)	scrubbed	Operator-owned, no brand token, independently blockable
1fjkldsauasejvqovg[.]com	Rail C sender apex	2026-06-23 (live same day)	scrubbed	Operator-owned, no brand token, independently blockable
firebaseapp[.]com	Firebase project host parent	2012	Google LLC	Shared Google hosting, never flag the apex
googleapis[.]com	Cloud Storage parent	2005	Google LLC	Shared Google hosting, never flag the apex

Same-day registration, scrubbed WHOIS, an 18-character random-consonant label with no brand token, and immediate operational use is a tight, repeatable fingerprint for the operator's self-owned rail.

One Backend, Three Rails: The Cross-Cluster Pivots

Three signals bind the rails to a single operator despite the changing senders.

The strongest is the Cloud Storage object itself. The object e4e7f24a14bd43fb[.]html appears verbatim across Rails A and B and survived a sender-prefix evolution, a delivery-mechanism change from direct link to Firebase auth redirect, and a bucket migration from freecachoffers to static-assets-v1. Fingerprinting the destination catches what disposable senders hide.

The second is the subject line. Sign in to get $50 welcome reward requested at <UTC timestamp> is carried identically by Rail B (Google relay) and Rail C (operator apexes), and the two rails overlap on 2026-06-22. That shared string is what folds the operator-owned rail into the same operation.

The third is behavioral repetition. The freecachoffers to static-assets-v1 migration on Rails A and B is repeated by Rail C's move to a fresh uniforcesma/sefdaa[.]html object. The operator sheds landing-page reputation the same way on each rail, holding the lure and the object family constant while rotating everything disposable around them.

Escalation Over Time

The operation escalated in three steps. It opened with daily Firebase-project burn on a payment@ direct-to-storage rail. It then moved to Firebase-auth indirection on a noreply@ rail that hid the storage destination behind a legitimate Google action URL. It finished by pivoting to operator-owned, fully authenticated apex domains, the first self-owned sending infrastructure in the campaign. Throughout, Cloud Storage object and bucket migrations shed reputation while the object hash and reward subject held constant.

Detection Observations

The signals that separate this traffic from legitimate Google mail are behavioral, not reputational.

Email authentication is not a trust signal here. Mail on all three rails passes SPF, DKIM, and DMARC, because two rails are genuinely Google-originated and the third rides operator apexes configured to authenticate. A "pass" verdict says nothing about intent when the sender is a throwaway project or a same-day random-string domain.

A credential form served from a bare storage.googleapis[.]com/<bucket>/<object>.html path is anomalous for any real brand, which serves its login on its own domain. So is a Firebase /__/auth/action link whose continueUrl points off-platform to a storage object rather than back into the app. Reward and welcome-bonus lure semantics arriving from a firebaseapp[.]com project sender are a further mismatch.

The most durable signals sit at the destination and the pretext rather than the sender. A shared landing-object name reused across senders, and a verbatim reward subject reused across rails, both survive the operator's daily rotation. On the operator-owned rail, a freshly registered random-consonant apex sending the same reward subject to the same storage backend is a high-confidence cluster on its own.

Indicators of Compromise

All indicators are defanged. The operator's Firebase project hosts and Google-relay sender addresses sit on shared Google infrastructure and are addressed at the host and behavioral level rather than published as third-party-blockable indicators. The values below are the operator-owned, independently blockable assets plus the shared credential-harvest objects.

Senders

Value	Role	Notes
alert-80@h9rlebyelatbfp29bw[.]com	Sender	Rail C, operator-owned authenticated apex
alert-40@1fjkldsauasejvqovg[.]com	Sender	Rail C, operator-owned authenticated apex

Domains

Value	Role	Notes
h9rlebyelatbfp29bw[.]com	Sender apex	Registered 2026-06-22, WHOIS scrubbed
1fjkldsauasejvqovg[.]com	Sender apex	Registered 2026-06-23, WHOIS scrubbed

URLs

Value	Role	Notes
hxxps[:]//storage.googleapis[.]com/static-assets-v1/e4e7f24a14bd43fb[.]html	Landing	Primary credential-harvest object, Rails A and B
hxxps[:]//storage.googleapis[.]com/freecachoffers/e4e7f24a14bd43fb[.]html	Landing	Earlier bucket, same object
hxxps[:]//storage.googleapis[.]com/uniforcesma/sefdaa[.]html	Landing	Rail C credential-harvest object

MITRE Fight Fraud Framework Mapping

The mapping aligns to the MITRE Center for Threat-Informed Defense Fight Fraud Framework (F3). The framework's per-technique numeric identifiers are best confirmed against the live interactive matrix, so this table maps observed behavior to F3 tactics and technique names.

Tactic	Observed behavior	Observed behavior
Resource Development	Stage infrastructure (accounts, domains, cloud storage)	Daily Firebase projects, Cloud Storage buckets, and same-day-registered apex domains
Initial Access	Phishing (email)	Reward-themed lures, including Google-originated Firebase auth mail
Stealth	Trusted-infrastructure abuse and brand impersonation	Google-hosted pages, authenticated mail, and a continueUrl redirect to blend into legitimate traffic
Positioning	Credential harvesting	Cloud Storage credential form capturing account credentials
Monetization	Account takeover	Downstream conversion of stolen credentials

Conclusion

This operator kept a phishing operation running for about six weeks without owning any of the infrastructure that reputation systems watch, then added a self-owned rail only when it improved delivery. The lesson for defenders is that authentication and hosting reputation are the wrong place to look when the adversary is renting both from Google. The stable signals are the destination object, the pretext string, and the shape of the sending host, and those are the pivots worth building on. A separately tracked operator has already reused the same Firebase passwordless-auth delivery technique under a different lure, so expect the pattern to spread beyond any single actor's infrastructure.