The Outsider, Part 1: Pulling One Thread on a $1.9 Billion Phishing Machine

How one phishing SMS led us to Outsider, the China-based phishing-as-a-service platform the FBI and Google just dismantled. A technical teardown by Tapetum Labs.

Share
The Outsider, Part 1: Pulling One Thread on a $1.9 Billion Phishing Machine

By Tapetum Labs

Hello, and why this exists

Tapetum Labs is a security research outfit. The name is a deliberate choice. The tapetum lucidum is the reflective layer behind the eyes of nocturnal predators, the thing that lets them see in the dark and produces that eyeshine when a beam of light catches them. That is the idea behind Tapetum Labs: making the things that operate in the dark visible, through the lens of a nocturnal hunter.

We wanted our first public research to be representative of how we work. Start from something small and real, stay rigorous, follow the signals wherever they lead, and let the evidence speak for itself. This investigation fit perfectly.

Thanks for being here. Let’s get into it.


Executive summary

This is the first post of a two-part series on a phishing-as-a-service platform tracked as “The Outsider.” In Part 1, we start from a single smishing message and follow it through typosquatted domains, Cloudflare-fronted infrastructure, and a chatty backend API until the hidden machinery of a large phishing operation comes into view.

Working only from open sources and our own technical analysis, we mapped roughly a thousand typosquatted domains in one naming family, peeled back a Cloudflare reverse-proxy layer to identify a small cluster of Tencent-hosted origin servers running GoFrame behind Caddy, and reverse-engineered the kit’s client-side code and backend API.

The platform’s own API exposed more than it should have. A configuration endpoint, getSyncSettings, leaked campaign settings, issuer/BIN blacklists, operator nicknames, and a running list of victim IP addresses tagged as completed payment. The client-side code also revealed a real-time, human-operated “fraudster-in-the-loop” design, with a Web Worker maintaining a persistent WebSocket channel. Built-in validators for national identifiers across at least a dozen countries further showed that the platform was designed for a global victim base, not a single region.

The story lands with a public takedown. In June 2026, the FBI and Google announced the dismantling of the same operation, publicly named “Outsider Enterprise,” through Operation “Ghost Hook.” Public reporting linked the operation to more than 9,000 phishing sites, roughly 3.87 million stolen credit cards, and an estimated 1.9 billion US dollars in losses since July 2023.

Part 2 measures the machine from its own leaked telemetry: estimating victim count and revenue, defeating the developer’s attempt to hide that telemetry, and walking through the operator panel and criminal ecosystem that kept the platform running.


A note on sourcing and responsible disclosure: every finding in this series is derived from open-source intelligence and our own technical analysis. No non-public material is referenced. Infrastructure indicators are defanged. Victim data is redacted. Operator handles are retained only as pseudonymous identifiers exactly as they appear in the platform’s own public-facing artifacts, and nothing here asserts the real-world identity of any individual. The matter is now the subject of an active law enforcement action and ongoing civil litigation; references to that action are drawn from public reporting, and alleged conduct remains alleged.

The thread: one smishing message

The starting point was a large-scale SMS phishing (smishing) campaign aimed at mobile users. The lures impersonated trusted brands, including national postal services, road-toll and payment platforms, and major mobile carriers such as T-Mobile and AT&T. We observed lure campaigns targeting more than 30 countries, including the USA, Great Britain, France, Germany, Italy, the UAE, Qatar, Saudi Arabia, while the FBI mentioned more than 50 countries.

Each message carried the usual urgency hook: a parcel that could not be delivered, an unpaid toll, a small fee owed, and a link to a lookalike site (typosquatting). The operation was global. Each single campaign impersonated a specific brand, the platform behind them, however, was unique and hosting several campaigns associated to different brands and countries.

The smishing lure

Looking at submissions on URLScan, we noticed several filenames that were common throughout all campaigns: vue.js, main.js, common.js, axios.js, ws-worker.js, addClick and getSyncSettings among others.

Unique HTTP Transactions for The Outsider

We used the more unique and promising getSyncSettings to pivot on, and we pulled the thread on this resource in URLScan, which gave us the first temporal anchor.

Over 9000 results in URLScan for getSyncSettings, highlighting the different brands being impersonated

The earliest fingerprints of the specific variant we were chasing appear around August 2025, which lined up with a fresh launch of the kit we would later identify as "The Outsider." The FBI however mentioned tracking activity since at least July 2023, which likely corresponds to a previous version of the PhaaS.

At this stage we had hundreds of domains and dozens of brands being impersonated, from which we could roughly infer some of the targeted countries. The interesting question was never whether these were all malicious, because they obviously were. The question was what stood behind it. So we started pulling.

Typosquatted domains and the redirect layer

The first thing the thread unspooled into was volume. A single brand campaign would reveal a large amount of typosquatted lookalikes, programmatically crafted. A representative sample looked like this:

t-mobile.xesmzg[.]top   t-mobile.xsqipd[.]top   t-mobile.yjlnef[.]top
t-mobile.vyfawb[.]top   t-mobile.qjvkel[.]top   t-mobile.xpmyuv[.]top
t-mobile.ysbjco[.]top   t-mobile.ufwkpl[.]top   t-mobile.wlovkz[.]top
t-mobile.yctzgq[.]top   t-mobile.xatmpj[.]top   t-mobile.ymthcb[.]top
t-mobile.yirnjw[.]top   t-mobile.ktipyw[.]top   t-mobile.mzwfxy[.]top
t-mobile.vdkxht[.]top   t-mobile.vqmfph[.]top   t-mobile.jscalo[.]top
t-mobile.yfwldj[.]top   t-mobile.vpxsby[.]top   t-mobile.ogylkq[.]top

Examples of T-Mobile lookalike

We focused on one particular brand and collected on the order of a thousand of these for a single campaign. Small permutations of letters, and a rotation across cheap TLDs such as .com and .cc. Remember the Pyramid-of-Pain, and how "easy" it is for threat actors to swap domains? This is that principle in its purest form. Domains are burned as fast as they are blocked, so the PhaaS is built to handle and manage hundreds of them, while everything behind the domain stays constant.

Examples of impersonated phishing pages

What linked these domains together was not registration data, but shared behaviour. The same client-side code, the same multi-step flow, the same backend API calls, and the same handful of origin servers once you got past the front door. Which brings us to the front door.

Cloudflare fronting, and the pivot to the real backend

Every one of these domains resolved to Cloudflare. In our single campaign dataset the overwhelming majority of unique IPs sat in AS13335 (Cloudflare, Inc.), more than 400 of them, versus a single-digit handful in two other ASNs. That ratio is the tell. Cloudflare was being used as a reverse-proxy curtain. It hides the origin IP, absorbs takedown pressure, and gives every disposable domain trusted TLS at the edge without the operator lifting a finger. Resolving the domains gets you Cloudflare and nothing else.

So the question became, what is the true origin?

The leverage came from the small non-Cloudflare cluster. Those hosts weren't proxied through Cloudflare, whether by mistake or necessity, and that gap was all we needed. A handful of IPs lived in AS132203 ("Tencent Building, Kejizhongyi Avenue"), and one of them in AS45102 ("Alibaba (US) Technology Co., Ltd."). These were doing real work. Leveraging Validin and Virustotal for passive DNS, we could confirm that these IPs represented the core of the threat actor's infrastructure.

Validin DNS resolution results for 43.160.244[.]84 showing some UAE brands impersonation
Virustotal DNS resolutions results for 43.160.244[.]84

One of them, 43.165.133[.]137, resolved 236 domains related to one single brand located in the UAE that we focused on. Others carried 137, 57, 102, 40, 22, and 12. When a single IP is the answer for hundreds of supposedly different phishing domains, that is not coincidence, it is the backend.

ASN repartition for the 400+ IP addresses identified in a single brand campaign

But did we uncover the entire infrastructure supporting this campaign? Very likely no, so to identify siblings, we pivoted on three independent signals.

Pivot on HTTP Headers and Title

HTTP headers fingerprinting via Shodan. One of the server was running a relatively unique stack: a GoFrame HTTP Server, a Go web framework popular with Chinese developers, sitting behind the well-known reverse proxy Caddy, which advertises itself with a Via: 1.1 Caddy header and handles automatic Let's Encrypt TLS certificates.

HTTP/1.1 302 Found
Content-Type: text/plain; charset=utf-8
Date: <redacted> GMT
Location: <redacted>
Server: GoFrame HTTP Server
Trace-Id: <redacted>
Via: 1.1 Caddy
Transfer-Encoding: chunked

We used that combination to build a Shodan query scoped to the Tencent org:

"Server: GoFrame HTTP Server" "Via: 1.1 Caddy" org:"Tencent cloud computing (Beijing) Co. Ltd."

This surfaced 7 additional live servers returning the tell-tale 302 with the same GoFrame and Caddy headers. A second origin variant, 43.156.234[.]103, was using nginx/1.24.0 (Ubuntu) with a specific Permissions-Policy header.

HTTP/1.1 200 OK 
Server: nginx/1.24.0 (Ubuntu) 
Date: <redacted> GMT 
Content-Type: text/html
Last-Modified: <redacted> GMT 
Transfer-Encoding: chunked
Connection: keep-alive
ETag: <redacted> 
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), midi=(), camera=()
Content-Encoding: gzip"

This gave us another Shodan fingerprint for the same Tencent org, which allowed us to identify 9 new unique servers related to our campaign:

"Server: nginx/1.24.0 (Ubuntu)" "Permissions-Policy: geolocation=(), midi=(), camera=()" org:"Tencent cloud computing (Beijing) Co. Ltd."

HTML title and platform string, via FOFA. Because the kit reused the impersonated platform's branding in its page title, a search on that title string pulled back origins independently of DNS, including IPs we had already flagged, cloudflare-fronted domains, in addition to the original legitimate website. The only thing remaining was to filter out Cloudflare results. A simple, yet satisfying FOFA query, which would give us 2 new unique servers.

title=" T-Mobile Tuesdays - Get Free Stuff &amp; Great Deals | T-Mobile "

Example of FOFA HTML Title query for a T-Mobile campaign

FOFA results for T-Mobile campaign HTML Title

Finally, by leveraging Validin, VirusTotal and URLScan, we were able to collect additional brand-related domains as well as other campaigns. While Validin and Virustotal are known tools to gather passive DNS, URLScan is another great resource to uncover campaign.

URLScan results for IP Address 47.251.0[.]95 identified earlier via FOFA and Validin

Different methods, all converging on the same handful of Tencent-hosted origins. The Cloudflare curtain was up. We had found what it was hiding. Hold onto it, because in Part 2 the operator panel's own configuration screen confirms, in the developer's words, exactly this setup.

This hunt led us to uncover 900+ domains related to the same Brand and hosted on 14 unique origin IP addresses. A couple more were related but likely served as staging or testing environments. Could we have identify more? Very likely yes, there is still more to uncover and still live servers at the time of writing this post, even after the recent operation from Google and the FBI, Ghost Hook.

Client-side and API teardown

We could have stopped there and that would have already been great. But gladly, we turned to what the kit actually does in the browser, and this is where the operation started leaking.

As mentioned before, the client-side behaviour was similar in all the samples we analysed, except a few "updates" from the developer here and there (more on this in Part 2).

The client-side flow

The phishing logic shipped as a heavily obfuscated main.js, complete with string-array rotation.

Obfuscated main.js

This file is the client-side controller of the phishing kit, a Vue.js single-page app that opens a persistent WebSocket to the operator panel and swaps the visible page in the victim's browser on live command from a human on the other end. We assess with high confidence that it was packed with obfuscator.io, because the file opens with the tell tale shape of that tool's output: one giant array of short base64 looking strings, a small function that returns it, and a self invoking loop that shifts the array around until a numeric check passes. Beautifying the file already exposes the endpoint paths, page filenames, and Vue data model in plaintext, and resolving the string array turns the rest into readable code.

Beautified main.js already reveals some of the structure and logic

The page names themselves would sometimes read like a script, depending on how the operator would name them: a_login.html, b_info.html (personal and address details), c_pay.html (card entry), d_2fa.html and d_sms.html (two-factor and SMS one-time-code capture), f_pin.html (card PIN), etc. The sequence is designed to harvest everything needed to use the card and the identity behind it.

The script fingerprinted the victim's geolocation up front, calling 4 third-party IP geolocation services (ipinfo.io, ipapi.co, ip-api.com, and httpbin.org) so a single blocked provider would not break targeting.

JSON response for the call to ipinfo.io

It then opened a WebSocket connection at the path /webSocket/QT/: wss://<typosquatted_domain>/webSocket/QT/JWRCVV-1769269381113-hkwkuf1u71j-ovc91awq9p/khkjsahfjkwhakjlsdwdddddd88. The kit includes a dedicated Worker named "ws-worker.js" implementing the WebSocket communication layer. It receives init, send, stop, and reconnect commands from the main thread, maintains a WebSocket connection with 10-second heartbeats, and retries abnormal disconnects every 500 ms. It also runs a separate 1-second polling loop against a victim/session-specific URL to retrieve backend instructions and forward them to the page as instruction messages. The resource contains Chinese comments explicitly describing this as WebSocket management, backend command polling, and main-thread communication.

/**
 * 统一通信 Worker
 * 
 * 职责:
 * 1. WebSocket 连接管理(建立、心跳、断线重连)
 * 2. 轮询定时器(每秒获取后台指令)
 * 3. 通过 postMessage 与主线程双向通信
 * 
 * 优势:
 * - Worker 线程不受 iOS Safari 的 setInterval 节流影响
 * - 统一管理所有通信,避免多处重复代码
 * - 主页面和 iframe 通过统一的消息协议通信
 */

Header comment section of ws-worker.js

Combined with the observed operator panel (see Part 2), where sessions are assigned nicknames in a ticket-like workflow, which we could call a “fraudster-in-the-loop” phishing model. The code provides a continuous communication channel, while the panel appears to organize live victim sessions for operator to watch live victim's interaction and push next screen on demand.

The captured data itself is exfiltrated via addCvv POST request. Credit cards information was the main target in all the cases we analysed, however the schema itself reveals other identity-related fields that could be captured depending on the operator use case, such as First and Last Name, Country and Address, Email and Phone Number, Gender, Social Security Number, Date of Birth, License, Medical and Passport number, License, Medical and Passport image, and so on.

Snapshot of the addCvv request json schema

It also tracks current_page, online_status, the controlling template (belong_to_template), and a per-victim session ID.

Here, Verizon and AT&T rewards templates, alongside a generic "post" template likely mimicking a postal service

At this stage, the various comments in code resources and status reply strings from the API, all Chinese, would indicate a Chinese-speaking developer.

"card_submission_type":"同步卡提交" | "Synchronization card submitted"
"msg":"CVV数据更新成功" | "CVV data update successful"
"device":"电脑 - Linux - Firefox" | "Computer - Linux - Firefox"

Chinese strings extract with translation from addCvv response

One last interesting API "leak" from the addCvv response was the operator nickname. As said each victim's session is listed in the operator panel as a ticket that can be assigned. In some cases the API response would reveal the operator via the field pinned_by.

Combined with another API response getSyncSettings, which we will explore later in this post, we were able to retrieve the nicknames of several operators associated with the same campaign. The list below shows the operator nicknames observed for a single campaign we were tracking.

xioayan888    woaini3      houge888     xinyu1
AA9999        xiaoyan888   AA333333     wangzi999
dayan123      xinzai888    min333       wudi333
system        xy11111      admin        zxc153
ho666         cc           laohei888    aa1111
zhaoyun       lvjiano1     xx11111      liangshifu
kuaile02      F444444      jian666      sw11111
aa2222        zz1111       222222       zxc153153
hao222        F000000      hang888      Lei000
woaini6       xiaobai123   linye        dafanqie001
gold          laoban       baojian

While nicknames alone do not identify the individuals behind the activity, they show that the operation was not handled by a single person. Instead, the panel appears to support multiple operators working in parallel, with victim sessions organized and assigned in a way that resembles a ticketing workflow. This gives a useful glimpse into the scale and coordination of the phishing operation.

The leak doesn't stop there and we will now dive into the most interesting API endpoint, getSyncSettings.

The API that would not stop talking

The pages pulled their, per-victim, configuration from a backend endpoint named getSyncSettings under an /api/open/ path. The responses are where the operation's OPSEC fell apart.

A single getSyncSettings response, lightly trimmed and with victim IPs redacted, looked like this:

{
  "status": "success",
  "code": 200,
  "data": {
    "id": "1",
    "two_card_switch": "1",
    "bin_blacklist": "457119,457123,457122,457106,457104,457896,457153",
    "luhn_check": "0",
    "voice_reminder": "1",
    "region_blacklist":"",
    "max_number_of_visits": "50",
    "bin_db_check":"1",
    "bin_api_check":"0",
    "ip_blacklist": "{\"<victim-ip>\": \"\\u5b8c\\u6210\\u652f\\u4ed8\", ... }",
    "android_blocked":"0",
    "ios_blocked":"0",
    "mobile_blocked":"0",
    "desktop_blocked":"0",
    "bot_blocked":"1",
    "update_time": "2026-01-24T23:20:35",
    "update_by": "system"
  },
  "msg": "获取同步设置成功"
}

Read that again, because almost every field is a gift to an analyst.

  • bin_blacklist contains a live custom blacklist of Bank Identification Number (BIN), straight from the server. Different BIN blacklists were identified, exposing per-campaign targeting preferences.
  • update_by seems to be the operator nickname that last touched the victim's session or campaign's config. As previously mentioned this field in addition to the pinned_by from addCvv helped collect nicknames of some of the operators.
  • msg is in Chinese (获取同步设置成功, "get sync settings successful"), one of several language artifacts pointing at the developer's origin, an attribution thread we develop further in Part 2.
  • Many behavioural switches (bot_blocked, android_blocked, max_number_of_visits, voice_reminder, two_card_switch, etc.) highlight the kit's own anti-analysis, data-validation and social-engineering features that will later be confirmed with screenshot of the campaign configuration panel.
  • ip_blacklist is a list of victim IP addresses mapped to a status string! The strings are Unicode characters which correspond to the Chinese value 完成支付. This translates to the status string "completed payment". The backend is telling on its own victims, marking which visitors already paid so they are not shown the flow again. This single field is the thread we pull in Part 2 to count victims.
CyberChef recipe converting Unicode strings from the ip_blacklist field

A PhaaS that hides its origin behind Cloudflare, obfuscates its JavaScript, filters out low-quality data, and blocks bots, and then serves up its operators' nicknames, its victims lists, and a live breakdown of paying victims to anyone reading the API responses. That contradiction is the heart of this research.

The thread reaches the headlines: this is Outsider Enterprise

While we were mapping this platform from a single SMS, the rest of the story arrived in the news. In June 2026, the FBI and Google announced the takedown of "Outsider Enterprise", the same China-based, Telegram-coordinated phishing-as-a-service (PhaaS) operation whose infrastructure we had been dissecting. The public figures match the picture our technical work had been building from the inside:

  • more than 9,000 fake websites and over a million associated URLs
  • roughly 3.87 million credit cards stolen
  • an estimated $1.9 billion in losses since July 2023
  • victims across the US and at least 54 other countries

The takedown, Operation Ghost Hook, part of the wider Operation Riptide, with Google and Lumen's Black Lotus Labs, also seized the platform's admin domains, a Shopify storefront used to test kits, and roughly $100,000 in cryptocurrency, and rerouted thousands of seized US phishing domains to an FBI splash page. Carriers AT&T, T-Mobile, and Verizon are now filtering the lures.

Everything above was derived independently, from open sources alone, and that convergence is the point. The Cloudflare-fronted domains, the Tencent origins running GoFrame behind Caddy, the leaky getSyncSettings API, the dozen-country ID validators, and the operator handles are the ground-level mechanics behind those headline numbers. The headlines give you the scale, we just showed you how the machine was built and how it gave itself away.

What's next

In Part 2 we will:

  • harvest every getSyncSettings responses publicly available and turn the leaked victim IPs into an independent estimate of scale and revenue over a five-month window, then hold our numbers up against the FBI's
  • show how the developer eventually noticed the leak, bolted on client-side encryption to hide the metadata, and failed, and how we recovered the plaintext
  • tour the operator panel itself: templates, the live "fraudster-in-the-loop" console, Telegram-bot exfiltration, the Cloudflare auto-TLS configuration that confirms our Part 1 infrastructure findings, and one-click auto-deployment onto Tencent and Alibaba cloud
  • and lay out the ecosystem: the specialized roles, resellers, and channels that build, sell, and monetize an industrial phishing machine

Part 1 showed that this is Outsider Enterprise. Part 2 shows how a single OPSEC failure let us put a price tag on the whole operation.

Tapetum Labs publishes technical research on the infrastructure, malware samples and adversary toolkits. If you are a defender, a security team, or a fellow researcher and want to compare notes, we would like to hear from you.

Appendix

A reproducible pivot cheat sheet

For other researchers, the queries that did the work, ready to adapt:

# URLScan: every page that called the leaky config endpoint
filename:"getSyncSettings"
filename:"getSyncSettings" AND page.domain:<brandname>.*

# Shodan: the two origin fingerprints. "asn" is another field that should be leveraged
"Server: GoFrame HTTP Server" "Via: 1.1 Caddy" org:"Tencent cloud computing (Beijing) Co. Ltd."
"Server: nginx/1.24.0 (Ubuntu)" "Permissions-Policy: geolocation=(), midi=(), camera=()" org:"Tencent cloud computing (Beijing) Co. Ltd."

# Validin: pivot on the cloned platform title via host pairs
" T-Mobile Tuesdays - Get Free Stuff &amp; Great Deals | T-Mobile "

# FOFA: pivot on the cloned platform title
title=" T-Mobile Tuesdays - Get Free Stuff &amp; Great Deals | T-Mobile "

# VirusTotal: passive DNS / relations on a confirmed origin
https://www.virustotal.com/gui/ip-address/<origin-ip>/relations

Indicators of Compromise

IP ASN Assessed Environment
43.160.252.105 132203 (Tencent Building, Kejizhongyi Avenue) Prod (12 domains hosted)
43.160.206.90 132203 (Tencent Building, Kejizhongyi Avenue) Prod (22 domains hosted)
43.156.234.103 132203 (Tencent Building, Kejizhongyi Avenue) Prod (22 domains hosted)
43.165.133.137 132203 (Tencent Building, Kejizhongyi Avenue) Prod (236 domains hosted)
43.160.249.131 132203 (Tencent Building, Kejizhongyi Avenue) Prod (102 domains hosted)
43.160.248.36 132203 (Tencent Building, Kejizhongyi Avenue) Prod (137 domains hosted)
43.160.202.101 132203 (Tencent Building, Kejizhongyi Avenue) Prod (57 domains hosted)
43.160.244.84 132203 (Tencent Building, Kejizhongyi Avenue) Prod (40 domains hosted)
43.162.113.132 132203 (Tencent Building, Kejizhongyi Avenue) No assessment
43.162.108.157 132203 (Tencent Building, Kejizhongyi Avenue) Prod (111 domains hosted)
43.162.124.181 132203 (Tencent Building, Kejizhongyi Avenue) Prod (64 domains hosted)
43.160.206.15 132203 (Tencent Building, Kejizhongyi Avenue) No assessment
43.165.62.107 132203 (Tencent Building, Kejizhongyi Avenue) Staging/Dev
43.133.43.138 132203 (Tencent Building, Kejizhongyi Avenue) Staging/Dev
84.32.44.235 142036 (Hosteons Pte. Ltd.) Staging/Dev
47.251.0.95 45102 (Alibaba US Technology Co., Ltd.) Prod (50 domains hosted)
47.245.139.243 45102 (Alibaba US Technology Co., Ltd.) Staging/Dev