Principal findings

At least a dozen similar messages were received by the owner of this website. Two examples, delivered on July 21 and July 22, 2026, were preserved with their Internet headers and analyzed. The messages used slightly different capitalization, emoji, Firebase project names, API keys, tenant identifiers, and one-time codes. Despite those changes, both sign-in links named the same Google Cloud Storage bucket and the same HTML object as their continuation destination.

The two examined messages

The message’s social-engineering elements

The email uses a modest $50 reward rather than an implausibly enormous prize. That can make the offer feel more believable. Money and gift emoji draw attention in a crowded inbox, while the standard Firebase language—“We received a request to sign in”—gives the message the appearance of a routine security transaction. The reassuring statement that an unrequested link can be ignored is part of Firebase’s normal template, and may further reduce suspicion.

The recipient did not request a sign-in and had no known relationship with an application named “Get $50 welcome rewards Here.” Repetition from multiple unrelated project identifiers eliminates an innocent one-time typographical error as a convincing explanation.

How this technique works

Firebase is Google’s application-development platform. Among its legitimate features is passwordless sign-in by email link. A normal developer asks a user to enter an email address, calls Firebase’s sign-in-link function, and relies on Firebase to send a one-time link. Clicking the link proves that the person has access to the mailbox and allows the application to finish signing that person in.

Google’s documentation confirms that the application supplies an ActionCodeSettings object containing a continuation URL. The project must authorize the continuation domain in its Firebase configuration. When a custom link domain is not used, a default project address such as PROJECT_ID.firebaseapp.com can appear in the email.

1. An unknown operator creates or controls a Firebase/Identity Platform project and gives it a promotional name.
2. The operator enables email-link authentication and configures an authorized continuation destination.
3. The operator or an automated script submits harvested email addresses to the project’s sign-in process.
4. Firebase generates a genuine one-time code and sends a standard, Google-signed email to each address.
5. The message passes common sender-authentication checks because Google really did transmit it.
6. If the recipient follows the link, Firebase processes the sign-in action and the browser is directed toward the project-selected continuation page.

This is best described as service abuse, not as a compromise of Google’s mail servers. The legitimate platform performs exactly the function requested by a project operator; the abuse lies in the deceptive project identity, unsolicited authentication request, reward lure, bulk targeting, and suspicious continuation destination.

Deconstructing the sign-in link

The complete live links are intentionally not reproduced. They contained one-time authentication codes and should never be republished as clickable links. Their structure, however, is highly informative:

https://[PROJECT].firebaseapp[.]com/__/auth/action
    ?apiKey=[PROJECT API KEY REDACTED]
    &mode=signIn
    &oobCode=[ONE-TIME CODE REDACTED]
    &continueUrl=https://storage.googleapis[.]com/
        designs-88s2/0549098246584dbb.html
        %23[ENCODED RECIPIENT ADDRESS]
    &lang=en
    &tenantId=[TENANT IDENTIFIER]

/__/auth/action

A Firebase Hosting authentication-action handler. Its presence is consistent with a real Firebase email action rather than a visually similar fake Firebase address.

apiKey

Identifies the Google/Firebase project when calling its client-facing services. A Firebase web API key is generally not treated as a password by itself; access should be controlled through Firebase security rules, authorized domains, API restrictions, quotas, and project configuration. It is still useful evidence because the two specimens use different project keys.

mode=signIn

Identifies this as an email-link sign-in action, not merely an advertising hyperlink.

oobCode

The out-of-band, one-time action code. It is sensitive while valid and has been withheld from this webpage.

continueUrl

The destination or application state used after the Firebase action is handled. Google’s Identity Platform documentation explicitly defines this field as the URL used to continue after the user clicks the emailed link.

tenantId

Identifies an Identity Platform tenant. The two different tenant values reinforce that the messages were generated through separately configured project contexts.

Why the encoded number sign matters

Each continuation URL ends with %23, the percent-encoded form of #, followed by a doubly encoded version of the recipient’s email address. After decoding, the conceptual destination is:

https://storage.googleapis[.]com/designs-88s2/
0549098246584dbb.html#[recipient-email-address]

The portion following # is a URL fragment. Browsers ordinarily do not transmit the fragment to the web server in the HTTP request, but JavaScript running in the page can read it through window.location.hash. Thus, a single hosted HTML file could receive a per-recipient identifier without placing that identifier in the normal server request path. This is a technical capability and not, by itself, proof of credential theft; in this unsolicited campaign, however, the personalization mechanism is an important indicator.

The shared Google Cloud Storage object

The most powerful connection between the two examined emails is not the generic Firebase wording. It is the identical bucket name, object name, and recipient-fragment pattern. Separate project subdomains and tenant IDs both point toward designs-88s2/0549098246584dbb.html. This strongly suggests common control, shared campaign tooling, or a shared downstream operator.

The object was not opened during this investigation. Doing so could notify the operator, trigger additional redirections, expose the researcher to active content, or produce a page that changes according to time, browser, IP address, or the fragment value. Therefore this article does not claim to have observed the final page requesting a password, payment, survey answers, or personal information. The safest defensible conclusion is that the continuation target is suspicious, campaign-linked, and unnecessary for any reward the recipient requested—because no reward was requested.

Internet-header authentication analysis

DKIM: pass

IONOS reported dkim=pass header.i=@firebaseapp.com for both messages. DomainKeys Identified Mail uses a cryptographic signature to show that signed portions of the message were authorized by the signing domain and were not altered after signing. In this case, it is strong evidence that Firebase/Google generated and signed the messages.

DKIM does not answer the question “Is the advertised reward honest?” It answers a narrower question: “Did a system authorized to sign for this domain sign this message?” A dishonest customer of a legitimate sending platform can still induce that platform to send an authenticated message.

SPF: pass

Sender Policy Framework compares the envelope sender with the transmitting IP address and the domain’s authorization rules. IONOS recorded SPF passes using the respective project addresses as the SMTP envelope senders. That supports the same conclusion: Google’s infrastructure was authorized to transmit the mail.

DMARC: none

dmarc=none should not be misread as “DMARC failed.” It normally means that the receiving system did not apply an enforceable DMARC policy for the applicable From domain, or that no published policy produced a pass/fail enforcement result. In any event, SPF and DKIM already show that the messages are platform-generated.

IP reverse verification: pass

IONOS’s iprev=pass result means the sending IP’s reverse and forward DNS relationship was acceptable. The observed IPs resolve within Google’s mail infrastructure. Again, that validates the relay—not the unknown project operator.

X-Spam-Flag: NO

The receiving filter did not classify either message as spam. This illustrates why authenticated-service abuse is effective: reputable infrastructure, standard templates, valid TLS transport, working reverse DNS, and valid DKIM signatures can outweigh suspicious wording in automated scoring.

The long UI-InboundReport value

The large opaque value added by IONOS is an internal filtering/reporting artifact. It is not a hidden copy of the attacker’s IP address and cannot responsibly be decoded into a location or identity using public information.

Mail route and IP-address geography

A mail route is reconstructed by reading the Received fields from the bottom upward. Only infrastructure named in those fields should be treated as an observed SMTP hop. Geographic results for data-center and anycast addresses are approximate; they may represent an operator’s registration, a routing location, or a geolocation vendor’s estimate rather than the physical machine.

Email 1 route: July 22, 2026

Google recorded its SMTP handling at 10:27:38 a.m. Pacific Daylight Time (-0700), equivalent to 17:27:38 UTC. IONOS recorded receipt at 19:27:38 Central European Summer Time (+0200), also equivalent to 17:27:38 UTC. The displayed time zones reflect server configuration and do not prove the sender’s personal location.

Email 2 route: July 21, 2026

Google recorded handling at 12:19:23 p.m. Pacific Daylight Time, equivalent to 19:19:23 UTC. IONOS recorded receipt at 21:19:23 Central European Summer Time, also equivalent to 19:19:23 UTC. The near-identical timestamps indicate rapid, direct transport from Google to IONOS.

Why the X-Received line is not another geographic hop

Each message contains an X-Received field beginning with an address-like value under 2002:a05:.... This is a Google-generated internal trace identifier associated with message processing. It should not be presented as a separate public SMTP relay or geolocated as the attacker. The ordinary Received fields contain the defensible externally observed route.

Corroborating reports from other recipients

Public complaint records confirm that the exact “Sign in to get $50 welcome rewards Here” lure was not limited to this recipient and did not begin with the two July messages examined here.

The June complaint was formally categorized by the reporting party as a phishing email. The July 17 complaint was also categorized as phishing and remained listed as unresolved when reviewed. These complaint labels are reports by third parties, not court findings or independent malware-laboratory verdicts. Their evidentiary value comes from the exact subject wording, dates, project rotation, and matching Google relay infrastructure.

The June complaint page’s automated analyzer says its observed Google IP was “not allowed” to send for firebaseapp.com. That conflicts with the recipient-side authentication result preserved here, which explicitly records spf=pass for that same IP and a project-specific Firebase envelope sender. The receiving server’s contemporaneous SPF result is the more relevant evidence for this delivered message. Third-party automated complaint analyzers can mishandle subdomains, current-versus-historical DNS, or envelope-domain details.

What the evidence proves—and what it does not

Recommended response and reporting

If the link was not clicked

Delete or retain the message as evidence, but do not use its sign-in link. An unclicked email-link request does not, by itself, prove that the mailbox was compromised. Someone needs only to know or guess an email address to cause many passwordless-login systems to send a link.

If the link was clicked

Close the page. Do not provide credentials, card details, survey information, telephone numbers, or identity information. Review the browser’s download history and remove any unexpected download without opening it. If credentials were entered, change the password by independently navigating to the real service, terminate unfamiliar sessions, and enable multifactor authentication. If payment information was supplied, contact the card issuer using the number printed on the card.

Preserve useful evidence

• Save the original message as an .eml or .msg file.
• Preserve the complete Internet headers.
• Record the displayed subject and project subdomain.
• Copy the link for reporting only if this can be done without opening it; keep it in a plain-text evidence file and do not publish the live one-time code.
• Record the receipt date, time, and whether the link was clicked.

Where to report it

• Report suspected Google Cloud Platform abuse . Google states that this form covers services including Cloud Storage.
• Report a phishing page to Google Safe Browsing .
• Use the email provider’s “Report phishing” command so the provider receives the original message and headers.
• Forward phishing messages to reportphishing@apwg.org, the reporting address published by the Anti-Phishing Working Group.
• Report consumer fraud to the Federal Trade Commission.

Reports should include the project subdomain, the de-obfuscated storage.googleapis.com destination, the bucket and object names, message headers, and receipt time. Google—not the recipient—has the best opportunity to connect the Firebase project owner, API requests, billing or registration data, and source logs.

Sources and further reading

• Google Firebase, Authenticate with Firebase Using Email Link in JavaScript . Explains email-link sign-in, authorized continuation domains, ActionCodeSettings, and default Firebase Hosting link domains.
• Google Cloud Identity Platform, accounts.sendOobCode reference . Defines EMAIL_SIGNIN, continueUrl, tenantId, and project/link-domain fields.
• Google, Report suspected abuse on Google Cloud Platform .
• Spam.org, June 13, 2026 Firebase “$50 welcome rewards” complaint .
• Spam.org, July 17, 2026 Firebase “$50 welcome rewards” complaint .
• IPinfo, IONOS receiving server 74.208.5.21 . Identifies AS8560, IONOS, and a measurement-supported Kansas City location.
• Cybersecurity and Infrastructure Security Agency, Recognize and Report Phishing .
• Federal Trade Commission, How to Recognize and Avoid Phishing Scams .