The Outsider Part 1 Pulling One Thread On A 1 9 Billion Phishing Machine

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.

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.

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.

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.

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.

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 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.

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:

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.

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.

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.

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.

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.

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

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.

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

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.

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

HTML title and platform string, via FOFA. Because the kit reused the impersonated platform's branding in its page title, a 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.

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.

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.

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 phishing logic shipped as a heavily obfuscated main.js , complete with string-array rotation.

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.

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.

It then opened a WebSocket connection at the path /webSocket/QT/ : wss:// /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 explicitly describing this as WebSocket management, backend command polling, and main-thread communication.

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 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.

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

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

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.

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 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:

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

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.

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:

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.

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.

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