One Facebook Message Exposed a $100M Crypto Fraud Network. Here’s How

It started with a Facebook message from someone I’d never met.

“Helen Moran”, no mutual friends, no profile picture worth trusting, no reason to exist in my inbox. The message was short and felt like an accident, the kind of thing you might forward to the wrong person:

USDT Balance: 3,804,650.74
Lucas, your account balance has been deposited.
Account: qqq226 / Password: sss247
Login: https://btczio.com
Please keep this safe.

I wasn’t Lucas. She wasn’t talking to me. And that balance, three point eight million dollars in USDT, was never real.

But the domain was. And that’s where this gets interesting.

Step 1, I Just Googled the Domain. Then It Got Weird.

My first instinct was the same as anyone’s: what even is btczio.com? I didn’t click the link, never do that, but I did want to know what I was looking at before I touched anything.

First stop was VirusTotal. Before doing anything else, you check reputation. Drop the domain in, see if any of the 90+ security vendors have already flagged it.

Zero detections. Clean across every engine. That’s not reassuring, it means this domain is fresh enough that the security industry hasn’t caught up yet. New infrastructure is the most dangerous kind, because all the automated defences are blind to it. The absence of flags was itself a flag.

So I dropped it into URLscan.io, a free tool that visits websites on your behalf inside a sandbox and takes screenshots, records all the HTTP requests, and shows you exactly what the page does without you ever loading it yourself.

The page looked like a cryptocurrency exchange. Clean mobile-first interface, price tickers, a login/register button. Slick enough that if you received those credentials in a message from someone you trusted, you might actually try them.

I also threw it into Any.run, an interactive malware sandbox that lets you browse the site in a real browser environment and watch every network connection it makes in real time.

That’s where the first clue fell out. The Any.run network capture showed the site making API calls to a backend. A contact form or support popup contained an email address embedded in the page source:

ethtrx033@gmail.com

An operator contact. The scammer’s email. I now had three seeds: a domain, a Gmail address, and a set of fake credentials.

Time to find out who was actually running this thing.

Step 2, The Domain Told Me Everything Before I Even Asked

The fastest thing you can do with an unfamiliar domain is look up its DNS records. Not just the IP address, everything. The nameservers, the mail configuration, the SOA record, all of it. Every one of those fields is a choice the operator made, and choices leave fingerprints.

dig btczio.com A +short

The IP came back as 35.197.129.159. That's Google Cloud Platform, GCP, us-east1. Fine, lots of legitimate sites use GCP. But then I noticed the TTL.

One second.

Not sixty seconds. Not three hundred. One. A normal website uses a TTL of 300 to 3600 seconds. One second means the domain operator is changing the IP address faster than any blocklist on Earth can keep up. By the time a security vendor updates their database, the record has already rotated. This technique has a name: fast-flux DNS, and it’s almost exclusively used by people who don’t want to be found.

This was no longer just a fake website. This was deliberate evasion infrastructure.

dig btczio.com NS +short

The nameservers were ns1.julydns.com and ns2.julydns.com. I'd never heard of julydns.com. Most people haven't. It's not a real DNS hosting company, it's a purpose-built piece of infrastructure that exists specifically to manage DNS zones for scam domains. I had just found the first layer of the network below the surface.

Step 3, Pull One Thread, Find a Wardrobe

I looked up julydns.com the same way I'd looked up btczio.com. DNS records are public. Anyone can read them. The question is just whether you know what you're looking for.

Three things jumped out immediately.

First, the IP hosting julydns.com, 47.76.214.40, was Alibaba Cloud. Not GCP anymore. Aliyun. China's dominant cloud provider. The scam domain lived on American servers. The infrastructure running the domain was in China.

Second, the MX record, the mail server for julydns.com, pointed to mail.chaicp.com. An MX record tells you where email for a domain gets delivered. The fact that julydns.com had one at all was interesting; DNS providers don't usually send email. The fact that it pointed to an entirely different domain, chaicp.com, meant that domain was also part of this operation.

Third, the SPF record listed two IP addresses for authorized mail sending: 120.55.40.103 and 47.242.196.125. Both Alibaba Cloud. Both China-registered. The entire email infrastructure was Chinese.

But then I looked at something most people skip.

dig btczio.com SOA +short

The SOA hostmaster field, an administrative contact embedded in every DNS zone, read master.jmdns.com. Not master.julydns.com. A completely different domain: jmdns.com. This was the management layer sitting behind julydns.com. The control panel for the control panel.

I kept pulling.

Step 4, The Backend That Runs Everything

chaicp.com looked like a legitimate CRM platform if you only checked the surface. But when I did a subdomain sweep, checking whether api.chaicp.com, admin.chaicp.com, panel.chaicp.com etc. actually existed, something unexpected happened.

Every single one of them resolved. And every single one pointed to the same place:

agent.juming.com.

juming.com (聚名) is a Chinese SaaS platform, a Scam-as-a-Service engine. Every fake exchange in this network is just a branded skin on top of juming.com's backend. The operator buys the kit, registers their domain (btczio.com, cionusdt.com, whatever), and juming.com handles everything behind the scenes: fake trade execution, fake balance management, victim data collection, operator admin panel. Multiple scam franchisees, one backend.

I also found something that could directly identify the operator’s Google account. Buried in juming.com's TXT records was a Google Search Console verification token:

google-site-verification=8uyoo15qyNDwLa-mDSddbiVtovxL1DgPoQVuICowvIc

Search that exact string on Google. Whatever domains come back are registered to the same account.

At this point I took what I had to FOFA, a Chinese internet intelligence platform, similar to Shodan but with significantly better coverage of Alibaba Cloud and Chinese domestic infrastructure. I searched for cname="agent.juming.com", looking for any other domains across the internet that CNAME to the same backend.

The results confirmed this wasn’t one operator running one campaign. Multiple deployments, different domain sets, all routing through the same juming.com engine. Different brands, different fake exchange names, one shared backend. This is what a franchise looks like.

Step 5, The Second Cluster. 80 Domains.

While mapping the first cluster, I ran a reverse-IP lookup on a second IP that kept showing up in associated DNS records. The result stopped me. (ViewDNS.info)

34.150.85.92 was hosting 80 domains. All fake exchanges. All on the same server. The naming patterns were systematic:

• Fake Binance: binanusdt.com, binalusdt.com, binvvusdt.com, binttusdt.com...
• Fake Bybit: bybssusdt.com, bybkkusdt.com, byb-n.com...
• Fake BTC exchanges: btcaac.com, btcaae.com, btcaai.com...

This wasn’t a single scammer with a single fake site. This was a production-scale typosquatting factory. Someone was running dozens of simultaneous fake exchanges, each one impersonating a real platform, all pointing at the same GCP server.

The WHOIS for the anchor domain, cionusdt.com, was brief but confirming. Registrant Country: CN. Updated three days before I received that Facebook message. Registered via Gname.com Pte. Ltd., a Singapore-registered, Chinese-operated low-cost registrar with a reputation for minimal abuse enforcement.

Step 6, The Second DNS Provider Had Its Own Secret

The second cluster used a completely different DNS provider from the first: share-dns.com and share-dns.net. Not julydns.com. A separate operation, different Cloudflare nameserver pair, different account, different infrastructure. Two independent custom scam DNS networks, both running in parallel.

The first thing I noticed was that share-dns.net has no A record for its root domain. Type dig share-dns.net and you get nothing, just a SOA authority response. It exists purely as a nameserver. It doesn't want to be visited. It doesn't want to be found.

Then I checked where their mail server lived:

dig mail.share-dns.net

And then the SPF record for share-dns.net:

dig share-dns.net TXT

That -all at the end of the SPF record is the interesting part. Most legitimate services use ~all (soft fail) or list multiple IP ranges. This one has exactly one authorized IP and a hard -all, meaning any email that doesn't come from 35.215.163.95 is to be explicitly rejected. No fallbacks. No third-party mail services. One IP, locked down tight.

The operator set up a dedicated, isolated mail server inside Google Cloud specifically for this DNS provider, completely separate from the fake exchange hosting, separate from the juming.com backend, its own contained piece of infrastructure. Most scam operations route through shared mail services or just use Gmail. This operator built their own.

That’s not laziness. That’s compartmentalization. Someone who understands that if one piece of the infrastructure gets flagged and taken down, the rest keeps running.

The numbered nameserver variants made the same point. a1.share-dns.com through a8.share-dns.com are all pre-registered and all resolve to the same Cloudflare anycast IP. Eight nameserver slots, ready to go, waiting to be handed out to eight batches of domains. This DNS provider wasn't built for one campaign. It was built for scale.

Step 7, The Third Cluster. Fresh Deployment.

A third GCP IP, 35.247.183.138, Singapore region, was hosting another cluster of 17+ domains, all registered in April 2026. I pointed nmap at port 443 with service detection and two scripts, ssl-cert to read the TLS certificate, and http-headers to capture the full HTTP response headers:

nmap -sV --script ssl-cert,http-headers -p 443 35.247.183.138

Two things jumped out immediately.

First, buried in the HTTP headers:

Set-Cookie: PHPSESSID=374d63fc89d4a1cd7f7827421229cf1e; secure; HttpOnly

PHPSESSID is a PHP session cookie. That one line told me the backend wasn't Node.js or Go or anything modern, it was PHP. nginx was the front door taking HTTPS connections, but everything behind it was PHP-FPM handling the API. This is classic Chinese exchange kit architecture, nginx as reverse proxy, PHP doing the actual work.

Then the SSL certificate block:

ssl-cert: Subject: commonName=api.coiusdt.com
Subject Alternative Name: DNS:api.coiusdt.com
Issuer: commonName=R13/organizationName=Let's Encrypt
Not valid before: 2026-04-05T05:10:44
Not valid after:  2026-07-04T05:10:43

This is the default vhost certificate, the cert nginx serves when it receives a request for a hostname it doesn’t recognise. The fact that it says api.coiusdt.com and not bybbn.com or any of the 17 frontend domains means coiusdt.com is the real identity of this server. The one the operator actually built the infrastructure around, before layering all the fake exchange brand names on top as frontends.

Also worth noting: the cert was issued April 5 and expires July 4, a standard 90-day Let’s Encrypt certificate, meaning the operator is running automated cert renewal, almost certainly via certbot or BT-Panel’s built-in Let’s Encrypt integration. This cluster went live on exactly the same date the SOA serial timestamps pointed to.

One more thing in those headers that’s easy to miss:

Access-Control-Allow-Headers: ... userid

That userid field is a non-standard custom header, not part of any HTTP spec. The PHP API expects it alongside the session token to identify which user is making a request. It's a fingerprint unique to this exchange kit. Any server on the internet returning this header in a CORS preflight response is almost certainly running the same platform.

I took that header to Netlas, which indexes HTTP response data across its internet-wide scans. Searching for servers returning this specific userid header combination alongside PHPSESSID would surface any other global deployments of this same PHP kit, regardless of what domain name or brand they were hiding behind.

Then I ran openssl with the right SNI flag, and the TLS certificate handed me seven new domains for free.

Step 8, One openssl Command. Seven New Targets.

echo | openssl s_client -connect 35.247.183.138:443 \
  -servername bybbn.com 2>/dev/null \
  | openssl x509 -noout -text | grep -A5 "Subject Alternative"

Let’s Encrypt issues multi-domain certificates. When an operator registers a batch of domains in a single certbot call, all those domains get bundled into one cert’s Subject Alternative Name list. Pull the cert, read the SAN, you get the entire batch.

From one command, seven previously unknown domains: bincusdt.com, binnusdt.com, bybkh.com, fs-wbwx.com, gis-tds.com, pp-aybz.com, y-bwsr.com. All on the same server. All part of the same operator's Wave 1 deployment on April 5.

The natural follow-up question is: what did they deploy before this? Certificate Transparency logs are public, every cert ever issued by Let’s Encrypt or any major CA gets written to an append-only public log permanently. crt.sh indexes all of it.

I searched %.coiusdt.com and %.cionusdt.com.

Every subdomain the operator had ever requested a cert for came back, including ones that no longer existed in DNS. Retired infrastructure. Previous deployments. Subdomains that had been spun up and taken down before this campaign started. The cert logs remember everything even when the DNS records are gone.

I also took the SHA-1 fingerprint from the nmap output (942c15a039072c37b1b578dadb7d2ba876c292b1) to Censys and searched for other hosts presenting certificates from the same issuer chain and key pattern.

If the operator had migrated servers recently, the old host might still be serving the same cert.

Step 9, Inside the Fake Exchange

I did a simple curl request, using the --resolve flag to point bybbn.com at the known IP without touching real DNS, and read the HTML source of the actual page.

curl -sk --resolve 'bybbn.com:443:35.247.183.138' https://bybbn.com/

The site was a Vue.js single-page application, a professionally built web app serving a fake cryptocurrency exchange interface. Clean UI, real-time price tickers, trading charts. Indistinguishable from the real thing if you don’t know what to look for.

But one line in the HTML gave everything away:

<script>
  window.wss = 'wss://chat.cionusdt.com/'
</script>

Every single fake exchange domain in Cluster C, all 25+ of them, has this exact line hardcoded into the HTML. They all connect to the same WebSocket server: chat.cionusdt.com on the second cluster (34.150.85.92).

This is the scammer’s real-time control channel. One operator, sitting at one chat panel, can simultaneously manage hundreds of victims across dozens of fake exchange frontends. When a victim types into the “customer support” chat, that message goes to chat.cionusdt.com. The scammer responds as "support agent," denies the withdrawal, demands the next VIP payment.

One server. Hundreds of victims. One person orchestrating it all.

Step 10, The Source Code Confessed Everything

I had captured a complete mirror of btczio.com, 35 files including the full JavaScript source. Inside were two complete bundles: one from April 14 and one from April 24. Ten days apart.

I ran a targeted extraction on both files looking for the API backend URL. The difference was immediate:

The operator had migrated their entire backend ten days before the attack reached this inbox. The old backend, api.nixmss.com, resolves to 35.197.129.159: the same IP as btczio.com itself. A previously unknown domain, predating this campaign. And the new one, api.coiusdt.com, is what the live site was running on when I found it.

nixmss.com is a new IOC that nobody was tracking.

Then I found the name.

Step 11, They Named It

Deep in the main JavaScript bundle, a single constant. The platform’s internal configuration:

const l0 = {title: "Redwood Trus", lang: "zh"}

Redwood Trus. That’s what they call it. The fake exchange brand name, hardcoded in source. The truncation, “Trus” instead of “Trust”, isn’t a typo. It’s deliberate. Exact-match brand protection searches, fraud detection systems, and Google Safe Browsing all use string matching. “Redwood Trust” would hit filters. “Redwood Trus” slides past them.

The lang:"zh" next to it, combined with Chinese-language developer console logs throughout the code (连接正常, 开启心跳, 出现错误, "Connection normal", "Heartbeat started", "Error occurred"), confirms what the infrastructure already suggested: built by Chinese developers, for Chinese-operated fraud.

What We Started With. What We Found.

Three indicators. A domain, an email, an IP address. Forty-seven confirmed IOCs later:

Active scam domains100+GCP servers3 (US, Singapore)Chinese backend IPs7 (Alibaba Cloud)Custom scam DNS providers2 (julydns.com, share-dns.com/net)SaaS fraud platformjuming.comFake Binance domains26+Fake Bybit domains10+Languages targeted15+Max VIP deposit demanded100,000 USDT

This is what industrialized fraud looks like in 2026. Not one person with a fake website. A franchised network, a Chinese SaaS backend rented by multiple operators, deployed across three GCP regions, DNS-proxied through two custom nameserver networks, targeting victims in fifteen languages simultaneously. The fake exchange you see is the smallest part of the operation. The infrastructure running it is enormous.

What You Can Do

If you received a message like the one that started this investigation:

• Do not visit the domain. Use URLscan.io or Any.run if you need to investigate it safely.
• Check VirusTotal first. Even a clean result tells you something, fresh infrastructure means recent deployment.
• Block and report the sender. The Facebook account is part of the operation.
• Do not enter any personal information. Any data you submit goes directly to the scammer.

If you’ve already been targeted and lost money, report to IC3.gov (FBI’s Internet Crime Complaint Center). The scale of this operation, over a hundred domains, three cloud clusters, a dedicated SaaS backend, means it has definitely victimized people beyond a single inbox.

The full IOC list, DNS records, certificate fingerprints, and hunting queries are documented in the companion technical report.