Phish Watch · No. 1 · 25 Aug – 24 Sep 2026

Real websites delivered one in six of the lures we trapped

Thirty days of one inbox's spam folder. Half the malicious mail passed DMARC, most of it because it came through other people's mailboxes, websites and marketing accounts. Most of the rest linked to pages on Google Cloud Storage. Some carried a phone number where the link used to be.

By Josh Jenkins, Vorant · 25 September 2026 · corrected 10 October 2026

Every message below was already caught: Gmail filed all of it as spam. So this isn't a list of what beat a filter. It shows what is being sent right now, how it's built, and which of the usual defences it's built to walk past. Of the 50 malicious messages, 26 passed DMARC. None of those 26 was spoofing anybody. Each came from a domain that really was allowed to send it, and in 20 cases that domain belonged, or appears to belong, to someone other than the attacker: a mailbox provider (nine messages from Gmail accounts and one from an internet provider's mailbox), a real website, a real organisation's marketing account, or a real organisation's own mail system.

1Real websites delivered one lure in six

Nine messages were auto-replies from legitimate websites: three Japanese contact forms, three WordPress sites (in Latvian, Hebrew and Persian), the Mailchimp lists of two shops (a bike-parts dealer and an online retailer) and a boat-lift maker. Each one politely confirmed an enquiry, a new account or a newsletter signup. And each one carried a fake-transfer lure, almost all of them crypto, because the attacker had typed the lure into the form's name or username field:

Username: www[.]transfer406[.]pages[.]dev - BTC TRANSFER 93789 USDC
August 29, 2026 7:34 AM Action Pending - 1.0903 BTC Deposit Delayed. Confirm Here

The site sends that text straight back to the "applicant", in this case our trap address, as its own mail, through its own server or its mailing-list provider. Four of the nine passed DMARC as the site itself. None of the nine sites is compromised. They are relays, and their only mistake is echoing a stranger's input to a stranger's address. The payloads were numbered Cloudflare Pages sites (transfer403, transfer406, transfer409, future5000), a Telegraph page and one standalone domain. Most of these lures are written without https://, so a link scanner that only looks for URLs never sees them.

If you run a website: don't repeat user-supplied names or messages in auto-replies, and put your contact and signup forms behind a challenge. If you defend a mailbox: a crypto amount or a pages.dev hostname inside a "thanks for contacting us" email is a near-certain sign of form relay.

2One redirect token, eleven cloud buckets

Nineteen lures linked to HTML files on storage.googleapis.com, which inherit Google's reputation. Eleven of those buckets appear to belong to one operator: every link carries the same tracking token, 1626b9s, either in plain text or hex-encoded as .2e.31.36.32.36.62.39.73. in the URL fragment. Over four weeks that one operator sent 12 messages from 12 throwaway sender domains and 11 IP addresses. None of those messages had a DMARC result. The offers had nothing in common: online-casino chips, GLP-1 weight-loss drugs, a fake $7,000 payment, a fake Cash App deposit, and adult content. This isn't a phishing crew with a brand. It's a spam traffic broker selling clicks to whoever pays.

Using Google Cloud Storage as a spam redirector is well documented. malwr-analysis mapped a similar multi-scam hub in March, on different buckets. We haven't seen this token published before.

Domains, IP addresses and buckets are all disposable here. The URL shape isn't, which makes it the durable indicator:

storage\.googleapis\.com/[^/]+/[^/]+\.html#/.*(1626b9s|2e\.31\.36\.32\.36\.62\.39\.73)

Hunt for it: search mail logs and proxy logs for that pattern. More broadly, legitimate business mail rarely links to a .html file on storage.googleapis.com that has a #/redirect.html fragment. That combination is worth alerting on no matter which token it carries.

3The callback lures had no link to scan

Seven messages wanted a phone call, not a click. Four came from ordinary Gmail accounts and announced a Norton renewal charge of $459.99 to $690.99, with a number to call to dispute it. They contained no link and no attachment, just a number. Three more imitated a Robinhood "new sign-in from Russia (or India, or Vietnam), here's your one-time code" alert that ends with "Don't recognize this sign-in? Call Account Security" and a toll-free number. They were sent through bulk-mail platforms: two through Salesforce Marketing Cloud and one through SendGrid. The only clickable links in them run through the sending organisations' own click-tracking addresses, so a scanner sees a legitimate company's domain. One of the Salesforce accounts sends as the marketing subdomain of a real medical-device manufacturer, and passed DMARC because it is genuinely allowed to send as that company. The other two sending domains also look like real organisations' own: they were registered in 2020 and 2016, and one of the messages carries its company's name and street address in the footer. The campaign itself isn't new. Robinhood-themed callback scams with fake codes have been reported since spring (Trend Micro, CyberPress). What we add is the sending route: established companies' own marketing accounts, whose reputation carries the lure past filters.

For awareness training: a fake one-time code makes the scam more convincing. It primes the victim to read a code aloud once they're on the phone. For filtering: the only indicator in these messages is the number, so the numbers are listed below.

4Four "RewardHub" domains, one address block

A "your $15 cash back is ready" lure from a made-up rewards brand arrived four times, each from a different domain (suzinew, viprumors, nahenet, vipgamesonline). All four passed DMARC, because the operator configured authentication properly. All four were sent from 103.129.44.0/22. Every claim link has the same shape: /c/ followed by a 10-character code. A sender-reputation system that scores one domain at a time sees four clean newcomers. Scored by network block, it's one sender.

5Not one real attachment

None of the 50 malicious messages carried a file with anything in it. One, a life-insurance lure, carried two parts declared as PDFs that held nothing but line breaks and spaces (2 and 8 bytes). Everything else was a link, a phone number, or a lure hidden in text. That fits a consumer-facing inbox, and it's a reminder that attachment sandboxing covers only one delivery route. The business lures that do use attachments (invoices, password-protected archives, HTML smuggling) are what our next set of traps is built to catch; see Method and limits below.

The month in numbers

52% passed DMARC, 4% failed it, and 44% got no DMARC result at all, which usually means the sending domain publishes no policy. A quarter set a Reply-To address on a different domain from the sender. About two-thirds of the lures that carried a link pointed it at a legitimate platform: Google Cloud Storage (19) or Cloudflare Pages (6).

Indicators

Defanged, and taken only from mail judged malicious. Relay websites, the bulk-mail sending domains behind the callback lures, two government mail domains, a company's own mail domain and Google's own mail servers are deliberately left out: they belong, or appear to belong, to victims or to infrastructure, not to attackers.

Download: CSV · STIX 2.1 bundle (not defanged, for direct import into your tools; released as TLP:CLEAR, free to use)

Detection pattern (finding 2)

storage\.googleapis\.com/[^/]+/[^/]+\.html#/.*(1626b9s|2e\.31\.36\.32\.36\.62\.39\.73)

Method and limits

The trap is the spam folder of one long-lived personal inbox, read without modifying it. Each message is broken down into headers, the receiving server's authentication verdicts, every link and every attachment. Nothing is visited or opened. The recipient's name and address are removed before anything is stored. Each message was then labelled by a model and every malicious verdict was reviewed by hand. That review corrected 16 labels, mostly form relays and callback scams the model had misread. A second review in October, which also re-read the mail labelled as marketing, found three more malicious messages; the figures on this page include them (see the correction).

This is a sample of one inbox, so read these results as a snapshot, not as trends. The mix leans towards consumer scams, because that's what a personal address attracts. The next issues add trap addresses on a business domain, which draws the invoice, payroll and document-share lures companies actually face. Percentages here describe this trap and nothing wider.

Correction, 10 October 2026. A second review of the 294 messages found three malicious ones that had been counted as marketing: a ninth website-form relay, a life-insurance lure carrying two blank files, and a loan lure sent from a Gmail account. The count of malicious messages rose from 47 to 50 and the figures that depend on it were updated throughout. Nine relays in 50 is 18%, up from 17%: still about one in six, so the headline stands. Two messages first counted as sent from an attacker's own domain came from a government domain and from a real company's mail domain, and are now counted that way. The first version said each relay site sent the lure with its own SPF, DKIM and DMARC; only four of the nine passed DMARC as the site itself, and that passage now says so. The summary under the headline no longer names Google Cloud Storage as a reason mail passed DMARC: none of the mail that linked there had a DMARC result. We also withdrew two indicators, avalian[.]online and newbook[.]cloud: both are long-established domains that appear to belong to real organisations whose bulk-mail accounts were abused, like the medical-device maker's, so by this page's own rule they do not belong in a blocklist. If you imported the earlier indicator files, remove those two entries. One sending address was added: 185[.]14[.]29[.]115, the sender of the life-insurance lure.