Executive Summary
- A live smishing campaign delivered by SMS impersonates United States Postal Service (USPS) package delivery. The lure is not a hand-built knockoff. The kit serves USPS’s own production HTML, CSS, fonts, and images verbatim from the phishing host, complete with USPS’s live Google Analytics tag firing against USPS’s real marketing infrastructure.
- Underneath the deception the kit captures data in real time. It opens a WebSocket back to its origin and streams the victim’s card data keystroke-by-keystroke, runs a server-side BIN lookup on the card number, and pushes routing decisions (retry, PIN prompt, OTP prompt, kill-switch) back into the victim’s browser while they type. This was captured live, not inferred from source.
- The lure arrives as a single hostname. Censys passive DNS turned that one host into the whole operation. A single seed IP resolved to over a hundred lookalike subdomains, and across the confirmed cluster Censys recorded 682 unique lookalike hostnames (snapshot 2026-05-20), most of which no longer answer in live DNS but remain in Censys’s historical record.
- Pivoting on the kit’s HTTP banner hash carried the hunt from the USPS lure host onto a sibling running a second campaign from a Tencent prefix that impersonates UPS instead of USPS, on a Java/Spring Boot backend instead of the USPS kit’s Go backend. Both campaigns bake the operator’s own internal theme name,
us_post_ups, directly into their cookies. Same operator, two brands, one kit family. - The durable detection signals are structural, not cosmetic: the
/us_post_usps/asset path, thetheme_*_verify_us_post_upscookie family, thevalid_<14digits>_<32hex>token shape, and a banner hash that returns exactly the five UPS-themed (not USPS) hosts globally. Hostnames and IPs rotate weekly. These do not.
It Starts With a Text Message
You know the message. Everyone has gotten one. A package could not be delivered, there is an unpaid customs fee or a bad address, and here is a helpful link to fix it. This one pointed at:
https://usps.xupqnqz[.]one/uqjmw
Believe it or not, xupqnqz[.]one is not USPS (United States Postal Service). It is a six-character random string on a .one domain, prefixed with the comforting subdomain usps. That usps. label is the entire con. On a phone, with the real domain truncated in a narrow address bar, the leftmost thing the victim reads is “usps”. The kit operator is betting the rest never gets read.
Tap the link and you do not land on a fake mailbox right away. You hit a “Security Check” page that is a pixel-faithful clone of Cloudflare’s “Verify you are human” interstitial: the orange shield, the rounded checkbox, the Performance & security by Cloudflare footer. It even ships a twelve-language translation table and picks your language from navigator.language, so the lure speaks English, Spanish, Chinese, Arabic, and eight others without the operator lifting a finger.
This is the modern smishing pattern: wrap the scam in the most boring, most trusted interaction on the web. Nobody is suspicious of a Cloudflare check. We are all trained to click it and move on. That is exactly what the kit wants.
For the purposes of this post, though, the interesting move is not the lure. It is what happens when you take that one hostname to Censys and start pulling on the thread.
One Host, and What Censys Already Knew About It
The lure hostname resolves to `43.157.174.200`, a Tencent Cloud machine in 43.157.128.0/18, ASN 132203. A normal first step. The interesting step is the second one.
Follow Along in Censys
Censys does not just tell you what is running on 43.157.174.200 right now. It tells you every hostname it has ever seen resolve to that IP. Pull the host’s DNS view and the single SMS hostname explodes into roughly a hundred siblings, all variations on the same two themes:
usps.xupq*.one(the SMS lure’s exact shape, with a rotating four-to-six character tail)informed.deliwek*.shop(a nod to “Informed Delivery”, USPS’s real free mail-preview product)
That is the moment a single-link phishing report turns into an infrastructure hunt. The operator is not running one domain. They are running a domain factory, and one IP is hosting the whole catalog.
Following the DNS
This is the part of the investigation I want to dwell on, because it is the part that Censys makes almost unfairly easy and that you cannot reproduce with live DNS alone.
Active DNS answers one question: what does this name resolve to right now. Smishing operators have read that memo. The lure hostname in your text message is meant to live for hours, maybe a day, then go dark. Resolve it next week and you get nothing. The infrastructure looks like it evaporated.
It did not evaporate. It rotated. And Censys’s DNS resolutions data keeps the receipts.
Querying Censys’s resolutions API for the seven IPs that ultimately make up this cluster returns 682 unique hostnames as of the 2026-05-20 snapshot. The shape distribution is the operator’s whole playbook on one page:
| Hostname shape | Count | What it impersonates |
*.life (bare random apex) | 334 | the operator’s preferred disposable landing domain |
informed.deliwek*.shop | 250 | USPS Informed Delivery |
usps.xupq*.one | 78 | the USPS SMS lure pattern |
deliwek*.shop (bare) | 17 | USPS delivery theme |
xupq*.one (bare) | 3 | apex of the lure pattern |
Most of these names return nothing if you dig them today. They are spent. But they all sit in Censys’s history with first_seen and last_seen timestamps, which lets you reconstruct the rotation cadence and, more usefully, prove that a domain you just received in a fresh lure belongs to infrastructure that has been burning through names for weeks. The single host 43.157.174.200 alone accounts for 306 of those names. Two of its siblings carry another 197 and 202.
A defender who only has the live hostname sees one disposable domain. A defender with Censys sees the disposable-domain *generator* and every name it has emitted. That is the difference, and it is the whole reason this investigation got interesting instead of dead-ending at a 404.
What the Lure Actually Does
Before chasing the rest of the infrastructure, it is worth understanding what is waiting at the end of the link, because the kit’s mechanics are genuinely a step above the average phishing page.
Click the fake Cloudflare checkbox and the page makes a JSONP call to /eat?callback=jsonpCallback_<timestamp>, which hands back a token shaped like valid_20260521033009_cfe592644a1fdc56930624518ab3bcf7, that is, valid_<YYYYMMDDhhmmss>_<32-hex>. The endpoint also sets a gfsessionid cookie, the default cookie name of the Go GoFrame web framework. That cookie is our first tell about the backend stack. The “CAPTCHA” itself is theater: the callback parameter is never validated, so the gate’s only real job is to keep casual visitors and crawlers from deep-linking straight to the payload.
Token in hand, the page boots a Vue 3 single-page app (/assets/index-02f64fb4.js, a 444 KB Vite bundle) titled Welcome | USPS, and here is the design choice that makes this kit worth writing about. It does not draw a fake USPS page. It serves the visually compelling version, that to the victim appears to be a real one. Every template, stylesheet, font, and image is USPS’s genuine production asset, fetched straight off the phishing host under the path prefix /us_post_usps/. A single victim session pulls 66 distinct USPS-owned files, roughly 700 KB: USPS’s head.html, header.html, and footer.html, USPS’s Bootstrap CSS, two dozen navigation icons, the hero images, even six USPS-licensed Monotype web fonts.
Because the kit serves USPS’s real head.html verbatim, it also serves the live tags embedded in it: USPS’s Google Analytics 4 property G-CSLL4ZEK4L and a Google AdServices conversion beacon pointed at https://www.usps.com/. Every victim browser that touches this kit fires analytics hits into USPS’s own marketing pipeline. That is an odd and very useful artifact: USPS’s marketing team is, in principle, the one party on earth who can see this campaign’s traffic landing on their conversion dashboards from domains they do not own.
The /us_post_usps/ prefix is the cleanest detection seam in the whole kit. It exists nowhere on the real usps.com. Any browser fetching /us_post_usps/pages/head.html is, by definition, on the kit, no matter which throwaway hostname it arrived through.
Image: V1 USPS package lure rendered from USPS’s own templates
Now the part the victim never sees. As they fill in the form, the SPA opens a WebSocket to wss://<host>/ws?token=<UUIDv4> and streams what they type, character by character. We captured this live (279 WebSocket frames across seven sessions), not from reading the bundle. The capture shows the kit exfiltrating each stabilized keystroke as it lands:
{"event":"input_text","content":{"type":"input_card","key":"cardName","text":"Rob"},...}
{"event":"input_text","content":{"type":"input_card","key":"cardName","text":"Robert Bbase"},...}
{"event":"input_text","content":{"type":"input_card","key":"cardName","text":"Robert Base"},...}
{"event":"input_text","content":{"type":"input_card","key":"cardNumber","text":"4242424242424242"},...}
{"event":"input_text","content":{"type":"input_card","key":"cvv","text":"145"},...}Note the typo Robert Bbase and its correction both reach the operator. Every intermediate state of the card number, expiry, and CVV is captured before the victim ever clicks submit. A parallel HTTP POST to /<random>/api/input double-ships the same values, so an abandoned, half-typed card is still harvested.
When the form is finally submitted, the operator’s backend does something most kits do not bother with. It runs a server-side BIN lookup (to validate the format of the value to protect against bogus data) against the card number and pushes the enriched record back into the victim’s browser over the same socket:
{
"event": "result_type",
"content": {
"type": "reject",
"value": { "data": {
"cardData": {
"cardBIN": { "bin": 424242, "bank": "STRIPE PAYMENTS UK, LTD.",
"country": "UNITED KINGDOM", "schema": "VISA", "type": "CREDIT", "level": "CLASSIC" },
"cardName": "Robert Base", "cardNumber": "4242424242424242", "expires": "02/30", "cvv": "145"
},
"cardHistory": [ ... ]
}}
}
}Two things stand out. First, cardHistory is an array: the kit remembers every card the victim has tried in the session, which is exactly the data structure you build if you intend to trap a victim in a “your card was declined, try another” loop and skim a second and third card. Second, the data is streamed via websocket live. The periodic config the backend returns carries operator-controlled fields including a kill-switch (isBlock) that, when flipped, bounces the victim to the real www.usps.com, and two capture templates whose internal labels are in Chinese (PIN验证, “PIN verification”; 邮箱验证, “Email verification”) while every victim-facing string is in clean English. The operator works in one language and presents in another.
That dual-language config, captured straight out of the kit, is also the strongest in-artifact attribution signal we have. More on that below.
The Twin: A UPS Campaign Built on the Same Bones
Here is where the hunt paid off in a way I did not expect when I started with a single SMS link.
The seven hosts in this cluster did not come from DNS alone. DNS gave me the lookalike catalog on each known IP. To find the *other* IPs, I pivoted on what the kit looks like on the wire. The host’s HTTP service has a banner hash (http header hash), and one of those hashes turned out to be a near-perfect cluster boundary:
host.services.banner_hash_sha256="4fe8bec780537aa223406965415c1f85e83eec1f4e2181cf82e2a7b7516026e6" and host.services.protocol="HTTP"
That query returns exactly five hosts, globally. Not five thousand. Five. And they are spread across two different Tencent /18 prefixes (43.157.128.0/18 and 43.173.64.0/18), which is the tell that the operation is bigger than the prefix the lure lives on.
When I pulled those five hosts and visited them, they were not USPS. They were UPS.
The UPS variant (call it V2) wears a similar fake Cloudflare gate, but the machinery behind it is a different build:
- The gate is English-only, with no twelve-language table, but the HTML hard-codes
<html lang="zh-CN">:a Chinese locale stamped on an English page, a small slip that survived the re-skin. - Instead of the JSONP token, clicking through fires a redirect chain:
/__theme/runtime/entry/verifysets a cookie and 302s off-domain toxupqrnn[.]one/us?__theme_site_ticket=<32hex>, which chains through/__theme/runtime/site/passand lands on the UPS SPA. - Both hops in that chain set a cookie, and both cookie names, contain the literal string
us_post_ups: theme_entry_verify_us_post_ups and theme_site_verify_us_post_ups. That is the operator’s own internal name for the kit’s “theme”, leaked twice, in two independent endpoints. Neither name has any business existing on real UPS or USPS infrastructure, which makes either one a SIEM-grade indicator on its own. - The UPS SPA’s favicon still points at
/usps/images/logo_mobile.svg. The brand on screen says UPS; the favicon path says USPS. That is a fork artifact, left in place when the operator copied the USPS kit and re-themed it for UPS. - The backend is no longer Go. Request any path the kit does not route and you get Spring Boot’s stock JSON error, timestamp and all:
{"timestamp":"2026-05-21T05:33:43.670+08:00","status":404,"error":"Not Found","path":"/__theme/runtime/entry/verify"}
Image: V2 UPS lure, same kit family, different brand
The second campaign represents a sibling within the same kit lineage that mirrors the real-time exfiltration model, the Tencent hosting footprint, and the shared Caddy reverse proxy, yet it swaps the USPS costume for a UPS one across two distinct technical platforms, GoFrame and Spring Boot. It is the signature of a single operator managing parallel brands, where the infrastructure and code heritage are shared, even if the specific backend implementation is not.
Same Operator, Two Brands
Lining up the two variants side by side makes the shared parentage hard to miss, and gives defenders a clean V1-versus-V2 discriminator.
| V1 (USPS) | V2 (UPS) | |
| Backend | GoFrame (Go) | Spring Boot (Java) |
| Lure gate | 12-language fake Cloudflare | English fake Cloudflare, lang="zh-CN" |
| Token / handoff | /eat JSONP valid_<14>_<32hex> | /__theme/runtime/* 302 chain |
| Cookies | gfsessionid (GoFrame default) | theme_*_verify_us_post_ups |
| SPA title | Welcome | USPS | Welcome | UPS |
| Favicon | /us_post_usps/124.png | /usps/images/logo_mobile.svg (USPS-pathed) |
| Brand asset prefix | /us_post_usps/* (real USPS templates) | /usps/* |
| Port-80 banner hash | 8e5546c83d… | 4fe8bec780… (5 hosts globally) |
| Reverse proxy | Via: 1.1 Caddy | Via: 1.1 Caddy |
The seven confirmed hosts break down as two V1 USPS hosts and five V2 UPS hosts:
| IP | Prefix | Kit | Backend | Censys DNS names (2026-05-20) |
| `43.157.174.200` | 43.157.128.0/18 | V1 USPS | GoFrame | 306 |
| `43.157.158.108` | 43.157.128.0/18 | V1 USPS | GoFrame | 0 in snapshot* |
| `43.157.151.131` | 43.157.128.0/18 | V2 UPS | Spring Boot | 197 |
| `43.157.148.168` | 43.157.128.0/18 | V2 UPS | Spring Boot | 202 |
| `43.173.100.171` | 43.173.64.0/18 | V2 UPS | Spring Boot | 64 |
| `43.173.104.156` | 43.173.64.0/18 | V2 UPS | Spring Boot | 12 |
| `43.173.105.83` | 43.173.64.0/18 | V2 UPS | Spring Boot | 32 |
*43.157.158.108 showed no HTTP service and zero DNS names in the snapshot, only SSH on a different OpenSSH build than its siblings. A live probe against one of its usps.xupq*.one names returned Server: GoFrame HTTP Server with a valid JSONP token, confirming it as a second V1 USPS host whose web service simply was not in the cache at scan time.
A few infrastructure notes that shape how durable each pivot is:
- All six HTTP-serving hosts share one port-443 TLS banner hash and front everything with
Via: 1.1 Caddy. The shared TLS config is real, but on its own the TLS hash is far too common (over a million hits) to use globally; it only becomes useful ANDed with the Tencent ASN. - Six of the seven run the same OpenSSH 8.9p1 build, yet every host has a distinct SSH host key. Identical golden-image clones would share host keys. These do not, which means the operator provisions each VM individually. SSH host-key pivoting is therefore a dead end here, worth saying out loud so nobody wastes time on it.
- Nobody is patching. Every host carries the same stale SSH CVE set, regreSSHion (CVE-2024-6387) and friends, untouched. That is consistent with a spin-up, run-until-burned, abandon model. Potentially attributed to the vendored image of the hosting provider.
Where Is This Thing, Actually?
Geolocation on this cluster is a useful reminder that the obvious answer is usually wrong. The seven hosts give four different “locations” depending on which signal you trust:
| Signal | Says |
| ASN owner | Tencent (TENCENT-NET-AP, country code CN) |
Whois network name (43.157.128.0/18) | 6 COLLYER QUAY (Singapore CBD address) |
Whois network name (43.173.64.0/18) | ACEVILLE PTE.LTD. (Tencent’s Singapore entity) |
| Censys geo (43.157.x) | São Paulo, Brazil |
| Censys geo (43.173.x) | Santa Clara, California |
| Server-side clock (both kits) | +08:00 |
None of São Paulo, Santa Clara, Singapore, or Beijing is a reliable physical-server location. The realistic read is: VMs inside Tencent’s overseas cloud, billed to a Singapore entity, owned by a Chinese ASN, with geo-IP records that reflect intended customer regions rather than where the metal sits.
The one signal that shows up consistently is the +08:00 server clock, emitted independently by both backends (the Go kit’s token timestamp and the Spring Boot kit’s JSON error timestamp). That is the servers’ configured locale, Asia/Shanghai, and it is worth being precise about what it does and does not tell us. It is a property of the deployment, not a GPS pin on the operator. A Chinese-speaking operator working from anywhere can set their Linux boxes to CST.
On Attribution
I am going to be disciplined here, because this is where smishing writeups tend to over-reach.
Everything about this kit is consistent with the loosely-tracked Chinese-language smishing-as-a-service ecosystem often labeled “Smishing Triad”: the USPS and delivery-brand themes, the multilingual fake Cloudflare gate, the Tencent-on-Singapore-whois hosting, the dual-language operator config with Chinese internal labels and English victim copy, and the polished realtime card-skimming with server-side BIN enrichment. Those are real, in-artifact signals.
What I do not have is a shared TLS certificate, a shared backend IP, or a shared body hash tying this specific infrastructure to a previously published IOC list. So I am not asserting attribution to that cluster or to any named operator. The evidence supports “consistent with a known ecosystem,” and stops there.
Hunting It Yourself
The whole point of doing this in Censys is that you can reproduce and monitor it. Here are the pivots, ordered by how durable I expect them to be.
Strongest, the V2 banner hash (returns exactly the five UPS-themed hosts):
host.services.banner_hash_sha256="4fe8bec780537aa223406965415c1f85e83eec1f4e2181cf82e2a7b7516026e6" and host.services.protocol="HTTP"
Follow Along in Censys
Open the query host.services.banner_hash_sha256=”4fe8bec780537aa223406965415c1f85e83eec1f4e2181cf82e2a7b7516026e6″ and host.services.protocol=”HTTP” in Censys Platform
The V1 USPS banner hash (separates the GoFrame USPS hosts):
host.services.banner_hash_sha256="8e5546c83d764e1287b55cbe868a45344a6f0afa9782d798d03b2b7cfc53ec38" and host.services.protocol="HTTP"
JA4T transport fingerprints, scoped to the Tencent ASN so they stay tight (they survive application-layer re-skins that would flip the body or banner hash):
host.services.ja4tscan.fingerprint="65160_2-4-8-1-3_1424_7_1-2-4-8-16" and host.autonomous_system.asn=132203
host.services.ja4tscan.fingerprint="59136_2-4-8-1-3_1424_7_1-2-4-8-16" and host.autonomous_system.asn=132203The first matches the cluster hosts in 43.157.128.0/18; the second the hosts in 43.173.64.0/18.
And the move that started everything: take any one of these IPs (or a fresh lure hostname) and pull its DNS history in Censys. That is what turns a single disposable domain into the operator’s whole rotation.
For Defenders
Hostnames and IPs in this operation are disposable by design. Detections written against them go stale in days. Detections written against the kit’s structure should outlive several re-skins.
| Where | Indicator | Why it lasts |
| SMS gateway / URL inspection | substrings xupq, deliwek, xupqrnn, gwrpfjx in delivery-themed URLs | the operator’s domain-generation shapes |
| Proxy / EDR (paths) | /us_post_usps/, /__theme/runtime/site/pass, /__theme/runtime/entry/verify, /<random>/api/input | none of these exist on real USPS or UPS |
| Proxy / EDR (cookies) | theme_*_verify_us_post_ups, gfsessionid on a “USPS”/”UPS” host | the operator’s theme name; GoFrame’s default cookie |
| Body inspection | JSONP matching valid_d{14}_[0-9a-f]{32}; Spring Boot JSON 404 with +08:00 on a delivery-brand host | kit-specific shapes |
| Censys monitoring | the two banner hashes above; the ASN-scoped JA4T fingerprints | banner hash returns exactly the cluster; JA4T survives re-skins |
| Brand-side analytics | hits to USPS GA4 property G-CSLL4ZEK4L from any host other than www.usps.com | a seam only USPS’s own marketing team can see |
The Tencent prefixes 43.157.128.0/18 and 43.173.64.0/18 are also reasonable block-list candidates for most enterprises, since legitimate destinations on operator-occupied overseas cloud prefixes are rare.
Conclusion
The lesson I keep relearning is that the artifact in your messages inbox is the smallest part of the story. One USPS smishing text gave up one hostname. That hostname gave up one IP. And Censys’s view of that IP, especially its DNS history, unrolled an operation with hundreds of disposable lookalike domains, a real-time operator-piloted skimming kit that serves the genuine USPS website as its own bait, and an entire parallel UPS campaign built on the same kit and the same internal theme name.
What makes DNS so valuable here is that it is the one layer the operator cannot make disposable. They can burn a hostname in a day, rotate an IP, re-skin USPS into UPS, swap Go for Java. What they cannot do is un-resolve the names they have already used, because Censys already saw them. The cosmetic layer is cheap and changes constantly. The structure, the asset paths, the cookie theme name, the banner hash, and the DNS history, is where the operation actually lives, and it is where it can be tracked.
Indicators of Compromise
Cluster hosts (Tencent, ASN 132203)
43.157.174.200 V1 USPS (GoFrame) 43.157.128.0/18
43.157.158.108 V1 USPS (GoFrame) 43.157.128.0/18
43.157.151.131 V2 UPS (Spring) 43.157.128.0/18
43.157.148.168 V2 UPS (Spring) 43.157.128.0/18
43.173.100.171 V2 UPS (Spring) 43.173.64.0/18
43.173.104.156 V2 UPS (Spring) 43.173.64.0/18
43.173.105.83 V2 UPS (Spring) 43.173.64.0/18Lure / handoff hostnames
usps.xupqnqz[.]one V1 USPS lure
xupqnqz[.]one V1 apex
gwrpfjx[.]life V2 UPS lure
xupqrnn[.]one V2 cross-domain handoffHostname-generation shapes (hundreds of disposable instances)
usps.xupq*[.]one 78 observed
informed.deliwek*[.]shop 250 observed
*[.]life (random apex) 334 observed
deliwek*[.]shop 17 observedBanner hashes
4fe8bec780537aa223406965415c1f85e83eec1f4e2181cf82e2a7b7516026e6 V2 UPS (port 80, 5 hosts globally)
8e5546c83d764e1287b55cbe868a45344a6f0afa9782d798d03b2b7cfc53ec38 V1 USPS (port 80)
Cookies / paths / token shape
gfsessionid GoFrame default (V1)
theme_entry_verify_us_post_ups=1 V2 redirect chain
theme_site_verify_us_post_ups=1 V2 redirect chain
/us_post_usps/ V1 USPS-asset path prefix
/__theme/runtime/entry/verify V2 handoff
/__theme/runtime/site/pass V2 handoff
valid_<YYYYMMDDhhmmss>_<32-hex> V1 JSONP token shape
More Reading
- Resecurity, “‘Smishing Triad’ Targeted USPS and US Citizens for Data Theft” (Aug 2023), the original naming of the cluster. https://www.resecurity.com/blog/article/smishing-triad-targeted-usps-and-us-citizens-for-data-theft
- Brian Krebs, “Phishers Spoof USPS, 12 Other Nat’l Postal Services,” Krebs on Security (Oct 2023), an early account of the USPS-themed campaign and its reuse of USPS’s own Google Analytics tag. https://krebsonsecurity.com/2023/10/phishers-spoof-usps-12-other-natl-postal-services/
- Silent Push, “Smishing Triad: Chinese eCrime Group Targets 121+ Countries, Intros New Banking Phishing Kit” (Apr 2025), documents the Lighthouse kit and its real-time front-end-to-backend victim sync. https://www.silentpush.com/blog/smishing-triad/
- Palo Alto Networks Unit 42, “The Smishing Deluge: China-Based Campaign Flooding Global Text Messages.” https://unit42.paloaltonetworks.com/global-smishing-campaign/
- Google, “Fighting scams with legal and legislative action” (Nov 2025), Google’s civil action against the operators of the Lighthouse phishing-as-a-service kit. https://blog.google/company-news/outreach-and-initiatives/public-policy/legal-action-and-legislation-fight-scammers/
- Brian Krebs, “Google Sues to Disrupt Chinese SMS Phishing Triad,” Krebs on Security (Nov 2025), names “Wang Duo Yu” and “CoSmile” as the kit developers. https://krebsonsecurity.com/2025/11/google-sues-to-disrupt-chinese-sms-phishing-triad/
