The R18.22 delivery fee that sends card details to Telegram

The page asks for R18.22 to release a parcel. Pressing its payment button sends the card details straight to a Telegram chat. A waiting screen then claims to be connecting to a payment server, pauses for 28 seconds, and asks for an SMS code. That code goes to the same chat.

Sandfish followed this sequence automatically in a capture on 10th October 2026, using synthetic payment details and a synthetic code. The archived Telegram responses confirm that both messages were accepted. They also preserve the submitted content, allowing us to reconstruct exactly what the page collected without relying on its labels or promises.

The investigation led to a second deployment with almost identical pages but a different active recipient. Together, the captures show how a small delivery-fee lure becomes a two-stage collection system—and why following the interaction matters when deciding which parts of a phishing kit actually work.

A courier identity on a storage bucket

The landing page presents The Courier Guy, a South African courier brand. It shows the company's name and logo, a delivery illustration, and a checkout progress bar already at “Shipping fees”. The message says the parcel is ready and asks for payment to complete delivery within 24 hours.

The address belongs to a public Backblaze B2 bucket: f003.backblazeb2[.]com/file/tiackz/. Sandfish identifies the claimed brand from the page's title and text and flags its credential interface on an unrelated domain. The logo illustrates the impersonation; the recorded brand match in this case is text-based.

A separate capture of a short link records an HTTP 302 from uf1k29.s[.]gy/NYl7df/ to this same landing page. That supplies a delivery link, but the captures contain no original SMS or email. We cannot establish how recipients encountered it.

The hosting choice matters. The observed collection path consists of static pages and browser-side JavaScript calling Telegram. It does not need a payment-processing backend on the bucket. The age or reputation of the shared storage domain says little about who uploaded these particular files.

Following the payment beyond the first screen

Sandfish's interaction engine clicked “CONFIRM AND PROCEED TO PAYMENT”, filled the card form, submitted it, waited through the intermediate screen, and submitted the subsequent code form. The recorded run contains ten actions, two submissions, and fifteen page snapshots.

The navigation and interaction records establish this sequence. Times below are UTC on 10th October 2026.

The wait is part of the mechanism. The archived waiting page contains a fixed 28-second HTML refresh to code.html. It does not need a bank response to show the next prompt. The captured delay matches that configuration.

The later 1.html page contains another 28-second refresh, this time to sms.html. The interaction budget expired before that transition. We observed one code submission; the contents and behavior of the configured next page remain unknown.

This is where interaction adds evidence. The landing page alone shows a delivery-fee demand. Continuing through the flow exposes the payment fields, their destination, the delayed code request, and the second transmission. Each stage is preserved with its surrounding requests and page state.

Recovering what the browser sent

The card form declares a POST action to look.php. Reading that attribute alone would point the investigation at the wrong destination. Its JavaScript submit handler cancels the normal submission, reads the controls, and builds a Telegram message.

It sends that message with an HTTPS GET to the Telegram Bot API's sendMessage method. The bot credential sits in the request path; the destination chat and message sit in the query string. Three seconds after submission, a separate timer moves the browser to the waiting page. That transition is not conditional on a successful payment or even on Telegram's response.

The two recorded exchanges reveal the collection format:

Both requests received HTTP 200 responses containing ok: true. More decisively, each returned message has the requested destination chat and text matching the submitted content after Telegram's HTML formatting is removed. This confirms acceptance by Telegram, rather than merely an attempted send.

Here, exfiltrated-data recovery means reconstructing the synthetic data transmitted during the sandbox run. We recovered the field contents from the archived requests and matched them to the returned messages. We did not retrieve victim records or read an attacker's chat history. The actual values and bot credentials are omitted from this article.

The page also calls api.ipify.org and includes the returned address in both messages. That gives the recipient a common value with which to associate the card and code submissions. It does not demonstrate geographic blocking. Nor does Telegram acceptance establish that anyone read the messages, used the code, or charged a card.

The same pages, different recipients

Sandfish's similarity analysis surfaced an earlier capture that morning, at f004.backblazeb2[.]com/file/tiurap/. It shares exact document hashes, page structure, text, JavaScript fingerprints, and a favicon with the main case.

Direct comparison makes that relationship more concrete. The two landing documents are byte-for-byte identical. So are their first waiting pages. Their card-page source differs in only three lines: a space in the Telegram message heading, the bot token, and the recipient chat ID.

These are two deployments of a closely related implementation. The short-link capture reaches the second bucket and is counted as another route to that deployment, not a third deployment. Capture times establish when we observed the pages, not when they were uploaded.

There is a more subtle shared value. Both first waiting pages retain code naming a third chat, 6885382463, and the same additional bot credential. But those pages have no matching form. The preserved script errors show the handler failing when it tries to attach to that missing form; neither reviewed run records a send to this third destination.

That distinction changes the interpretation. The shared credential is a useful fingerprint of copied material, but it does not establish a shared active collection account. The observed card messages go to different recipients. One operator changing settings and different operators reusing the kit both remain plausible.

The similarity result also includes shared analytics identifiers. Copied pages can preserve those settings along with their appearance, so we treat them as supporting template evidence. The exact source comparison and observed collection destinations carry the relationship analysis. The evidence supports a kit family across two deployments; it does not establish a single campaign operator or its scale.

What the interaction reveals

The investigation connects several kinds of evidence. Brand identification establishes who the pages claim to represent. Interaction reaches the collection stages. Archived network exchanges recover what was sent and confirm Telegram's response. Similarity finds a related deployment, while source and behavioral review distinguish its working collectors from inherited, broken code.

Those distinctions are the useful result. A nominal payment endpoint is bypassed. A supposed payment-server wait is a fixed timer. A shared bot credential belongs to a handler that fails on the observed page. None of these conclusions follows from the first screenshot alone.

For an investigator, the output is a reproducible path from the lure to the recipient, with the limits of that path visible. The Sandfish case preserves the pages, actions, requests, and source needed to check it.

Indicators and method

Backblaze, Telegram, and ipify are service providers whose roles differ here. Their shared domains are not campaign-wide blocking indicators. Bot tokens and credential-bearing request URLs are deliberately excluded.

Research used persisted public evidence retrieved on 10th October 2026: three analysis records covering two bucket deployments and one redirect, the complete request lists for both bucket captures, all their page snapshots, the main action ledger, archived HTML, and the main capture's two Telegram responses. Both similarity queries returned one match at their default thresholds, without truncation. Exact chat-ID pivots returned the same three analysis records in total; this is a bounded view of Sandfish's visible corpus, not a census of the kit.

The main run used synthetic inputs. Its copied markup caused the cardholder-name field to receive a CVV-shaped value, and the issuer remained at its default selection. Collection still succeeded; that does not establish perfect field interpretation. The interaction stopped at its time limit after the second waiting page. The evaluation's “complete” status describes evaluation completeness, not exhaustion of every possible page.

Behavioral conclusions here come from the navigation, network records, source, and recorded script errors. The fourteen behavior events in this live capture are script errors, not a complete trace of page API calls. No new phishing forms were submitted during this research, and no messages were sent or private chats accessed. We found no evidence establishing a real payment, a bank-issued OTP, victim losses, or the operator's identity.