The Outsider, Part 2: Putting a Price on a Phishing Machine

By Tapetum Labs

In Part 1 we pulled on a single thread, one phishing SMS, and followed it through a thousand typosquatted domains and a Cloudflare curtain to the hidden Tencent-hosted backend of The Outsider (局外人), the Phishing-as-a-Service platform the FBI and Google publicly dismantled in June 2026. Along the way we found an API, getSyncSettings, that leak its own operation: campaign settings, BIN blacklists, operator nicknames, and a live list of victim IPs tagged 完成支付, "completed payment."

In Part 1, we promised four things, and Part 2 delivers all four: we turn the leak into an independent victim count and a revenue estimate, then hold our numbers up against the FBI's. We watch the developer notice the leak, bolt on encryption to hide it, and fail, we walk through the operator's own panel, the live "fraudster-in-the-loop" console, the Cloudflare auto-TLS and one-click cloud deploy that confirm our Part 1 infrastructure findings from the inside, and we map the criminal assembly line, the resellers, spammers, data brokers, and launderers, around the machine.

A note on sourcing and responsible disclosure. Every finding below is derived from open-source intelligence and our own technical analysis. No non-public material is referenced. Infrastructure indicators are defanged and victim data is redacted or aggregated, we publish counts and methods, never individuals. Operator and developer handles are reproduced only as the pseudonymous identifiers that appear in the platform's own public-facing artifacts, nothing here asserts any private individual's real-world identity. The matter is the subject of active law-enforcement action and civil litigation (Google LLC v. Does 1–25, No. 1:26-cv-04982 (filed June 12, 2026)), and alleged conduct remains alleged.

The leak, at scale

We left Part 1 after observing a single getSyncSettings response. Recall the shape of it from Part 1: alongside the behavioural switches and the BIN blacklist, the ip_blacklist field carries a map of victim IP addresses to status strings, and the value 完成支付 ("completed payment") marks the visitors who had already handed over their cards. We also noticed in some cases two other values, 手动拉黑 ("manually block") and 自动封禁的爬虫 ("automatically blocked web crawlers").

The kit keeps this list for an operational reason we will come back to. For an analyst, it is a per-domain ledger of who got robbed.

The trick is where those ledgers end up. Every time a researcher, a sandbox, or a user submits an Outsider phishing URL to URLScan, the scan faithfully records the page's network traffic, including the call to getSyncSettings and its full response body. The platform's own confession was therefore being archived, domain by domain, in a public dataset, every single time anyone looked at one of its sites.

So we collected all of it. A short crawler walks URLScan for every scan whose traffic contains a getSyncSettings call, pulls each response body, parses the ip_blacklist, and registers one row per victim IP, with the domain, the operator (update_by), the timestamp, the payment status, and the BIN blacklist in force at the time.

Over a roughly five-month window, the earliest records land 8 September 2025, the latest 28 January 2026, that crawl returned 123,638 victim-IP rows across 1,017 unique phishing domains. That is the raw material. Now we count.

Why the platform records its own victims (and hands us a counter)

It is worth pausing on why ip_blacklist exists at all, because the answer is what makes it a reliable victim counter rather than noise.

Once a victim has completed the flow and surrendered their card, the operators have no further use for them, and a strong interest in never showing that person the page again. One likely hypothesis is that a returning victim who sees the scam a second time might realise what happened, screenshot it, or report the site to their bank, the brand, or the authorities, shortening the domain's useful life. So the platform marks each completed victim. It writes their IP into ip_blacklist with the status 完成支付 ("completed payment"), building a per-domain ledger of everyone judged to have paid.

One important clarification, because we checked the client code rather than assuming. This ip_blacklist does not seem to be enforced in the browser. We traced every consumer of the settings object in the kit's client script, and the only blacklisting it acts on is card-based (card_blacklist, card_whitelist, and BIN filtering). There is no visitor-IP comparison and no branch that blocks or redirects a returning victim by IP. So the list is best understood as a server-side or panel-side operational record of completed victims, rather than an active filter we watched fire. That distinction matters for honesty, and it does not weaken the numbers: we are counting the operators' own record of who paid, not inferring victims ourselves.

Assuming the record does drive suppression somewhere server-side, it would be a double-edged choice, because burning an IP for a domain also silences every future victim behind the same residential or carrier-grade NAT address on that domain. If so, the operators accept that collateral loss, and it is one more reason the platform leans on thousands of disposable domains: each list is domain-specific, so any damage from over-blocking is contained to a single throwaway domain rather than the operation as a whole.

Either way, the useful point stands. The blacklist is an operational record the platform must keep to run its own workflow, and each 完成支付 entry is a real visitor the operators themselves judged to have paid.

Two honest caveats carry into the estimate. First, the ledger keys on IP, which introduces some noise at the margins. The clearest case runs toward over-counting: a victim determined enough to hand over their card may retry across two addresses, for instance dropping from WiFi to cellular, and land in the list twice. It cuts the other way too, since one address can hide more than one person. Neither error dominates at population scale, and we treat the raw count as an approximation rather than a headcount. Second, and more important for the method, the blacklist is domain-specific. Each campaign domain keeps its own list, so a unique observed victim is one IP on one domain, and deduplication has to happen on the domain and IP pair, never the IP alone.

Counting the victims

With that settled, the estimate falls out in five steps:

1. Harvest. Every getSyncSettings response URLScan captured over the five-month window → 123,638 victim-IP records tagged "completed payment."
2. Deduplicate on domain-IP pairs. Because each domain keeps its own blacklist, the cleanest unit is one IP on one domain → 61,049 unique victims actually observed. The number is not a perfect headcount: retries across networks can over-count, while shared IPs can under-count. At this scale, we use it as a practical proxy.
3. Correct for coverage. URLScan has not seen every Outsider domains, only the ones somebody happened to scan. Cross-referencing our passive-DNS enumeration of the typosquat families against the domains present in URLScan, we estimate URLScan covers on the order of 25% of the domains we identified.
4. Extrapolate. Applying that coverage factor (×4): 4 × 61,049 ≈ 244,000 victims across the domains we mapped, over five months.
5. Sanity-check the direction. That figure sits comfortably below what law enforcement later attributed to the full operation, exactly where an independent, partial-visibility estimate should land.

A few words on confidence, because we would rather state the weaknesses than have you find them. This is a floor-leaning estimate of a moving target. The 25% coverage factor is the single largest source of uncertainty, and our typosquat enumeration is itself a subset of all Outsider activity, we tracked specific naming families, not all licensed platform's entire output. Read the number as "this is the scale the platform's own leaked telemetry implies for the slice we could see". It is deliberately conservative, and it is built from the machine's records, not our guesswork.

The victim never had to reach "submit"

In Part 1 we showed the captured card and identity data leaving the victim's browser in an addCvv POST. But the persistent WebSocket we flagged there, the one ws-worker.js keeps open to the operator panel, shows that addCvv is where the theft is confirmed, not where it begins. Throughout the flow, the kit streams its live form object to the operator over that socket, so the data is gone well before the victim ever reaches the payment step. addCvv is the receipt, but the WebSocket is the robbery.

We can see this directly in captured traffic. Below is a live cvvData message the page pushed over its WebSocket while the victim was already sitting on the card-entry page (current_page: c_pay.html), and every card field is still empty:

{"type":"cvvData","data":{
  "fullname":"<redacted>", "country":"US", "city":"<redacted>",
  "address1":"<redacted>", "email":"<redacted>", "phoneNumber":"<redacted>",
  "cvv_cardnumber":"", "cvv_cvv":"", "cvv_expiry":"",
  "current_page":"c_pay.html", "release_code":"info_submit",
  "client_timestamp": 1769269578917 }}

In this example, the victim's full name, address, email and phone are already in the operator's hands, streamed before a single digit of card data was entered. So a visitor who enters their details and then closes the tab or gets cold feet at the last second has already been reported. And because the socket is a live feed into the "fraudster-in-the-loop" console, an operator is watching sessions populate in real time and can push the next screen on cue. The last-second hesitation that would save the target of an ordinary phishing form saves no one here.

Inferring revenue

Turning victims into revenue needs one external input: what a stolen card is worth.

Using a conservative OSINT-derived resale range of USD 10–30 per card, depending on issuer, balance, freshness, and completeness and applying that range to ~244,000 victims over the five-month window we obtain:

• Low estimate: 244,000 × $10 ≈ USD 2.4M
• High estimate: 244,000 × $30 ≈ USD 7.3M

Annualised, that implies a platform capable of producing millions to potentially tens of millions of dollars in stolen-data value per year.

We would like to be clear, this prices the stolen data, not the operators' realised profit as monetisation is variable, bigger payments can succeed, but cards can also die, mules take a cut, laundering has overhead. And it reflects only the slice of The Outsider we could see. It is a defensible order of magnitude, not an audited P&L. But it is built from the platform's own records, and that is the point: the machine told us how many people it robbed, the market told us the magnitude.

The developer noticed, and failed

At some point during our collection window, the developer clearly realised the API was bleeding metadata. The fix they shipped is a small masterclass in how not to do it.

Instead of removing the sensitive fields, or, better, never returning victim IPs to the browser in the first place, they left the leak in place and simply encrypted the response body client-side (yes you read that correctly, client-side) via ws-worker.js. The victim IPs, the operator handles, the BIN lists, all still travel to the client on every request. They are merely wrapped.

This is security theatre (almost absolute cinema), and it fails for the most basic reason there is: if the browser can decrypt it, so can we. Everything needed to decrypt has to be present client-side, and it was. The "encrypted" response is just a blob with the key material bolted onto the front: the first 32 bytes are the AES key, the next 16 are the counter (IV), and the rest is AES-CTR ciphertext.

That makes recovery a five-minute job in Python or even via CyberChef:

# CyberChef: Recipe on how to decrypt The Outsider's "hardened" getSyncSettings response

## Step 1: recover the key (first 32 bytes)
Take bytes: start 0, length 32
To Hex

--> Save as KEY_HEX

## Step 2: recover the IV (next 16 bytes)
Take bytes: start 32, length 16
To Hex

--> Save as IV_HEX

## Step 3: decrypt the payload (everything after byte 48)
Take bytes: start 48, length <end>
AES Decrypt
    Key:   KEY_HEX (Hex)
    IV:    IV_HEX (Hex)
    Mode:  CTR
    Input: Raw

Out the other side comes the same ip_blacklist, bin_blacklist, and operator metadata as before. The fix cost the developer real effort and bought them nothing. A platform that hides its origin behind Cloudflare, obfuscates its JavaScript, blocks bots, and then ships the decryption key sitting right next to the ciphertext. The exact OPSEC failure we were looking for.

Interestingly, Google's complaint notes the developer likely hardens The Outsider specifically to stop rival criminals from stealing the code.

Inside the operator panel

The Telegram material referenced in the rest of this post comes from public operator-facing channels and bots associated with The Outsider ecosystem. We list the channel references at the end for transparency.

Until now everything has been reconstructed from the outside, traffic, responses, infrastructure. The operator panel lets us check those inferences against the platform's own interface, which the developer named as 后台同步管理系统, "Backend Synchronized Management System."

The navigation maps cleanly onto the kit's functions and the page artifacts we were able to recover from messages and videos in the Telegram channel.

As mentioned in Part 1, the first evidence of this new version of The Outsider appeared around August 2025. In the developer's own words, in a "New Source Code Preview" posted on 17 July 2025, the platform was in its "final wrap-up stage," pitched as "zero-code customization, perfect for complete beginners." That launch window matches our first sighting and Google's complaint, which dates the release to July 2025.

One line stands out: "The e-commerce Shopify payment plugin is also being developed in parallel." Our read is that Shopify gave the operators a real merchant surface to test fake checkouts against and to run stolen cards through a legitimate-looking storefront. Google's action confirms the angle, the FBI seized a Shopify storefront the enterprise used to test its kits. A parallel possibility, though not something the complaint asserts, is cash-out: a controlled storefront lets operators push stolen cards through a legitimate-looking merchant and collect the proceeds as ordinary sales.

Templates, building blocks, and "bring your own AI"

Outsider ships campaigns two ways: built-in templates, pre-cloned brand sites, 290+ of them by Google's count, filterable by region and country, and a custom-template builder that assembles a page from drag-in blocks (card entry, 2FA, PIN, address capture, etc.).

In its Telegram channel, the developer was suggesting the operators to grab the target site's markup with a browser extension named SingleFile, then paste it through an AI model to clean it up. Google's complaint documents the same technique. The use of AI in this case is clear but it only generates and customizes page templates. It does not run the backend.

Notably, this puts The Outsider a step behind some rivals. Competing platforms in the same ecosystem, such as Darcula, have moved AI-assisted template generation inside the panel.

The fraudster-in-the-loop console

The single most important screen is the live 同步控制 ("synchronization control") view. This is the human heart of the operation, the "fraudster-in-the-loop" console.

As a victim moves through the flow, an operator watches in real time and decides what happens next: show the verification code, resend it, force the next step, or mark the session complete. That is the human end of the WebSocket channel we found in Part 1 (wss://…/webSocket/QT/, driven by ws-worker.js). It is also how the platform defeats MFA: when the victim enters a code, the operator relays it to the real bank site in real time to trigger a legitimate 3D Secure challenge, then harvests the victim's response, beating the very control meant to stop this. As we will see later in this post, the actors likely only need to pass 3D Secure once to register the stolen card in a soft wallet, after which future payments may no longer trigger the same 3D secure challenge.

In this update version of The Outsider, the developer added an option to exfiltrate captured cards straight to a Telegram bot, alongside the panel, meeting operators where their community already lives. (An earlier version pushed loot to Telegram directly from the victim's browser, which is how some of it "leaked" into public space in the first place.)

Seeing the settings from the operator side

Until this point, we had only seen Outsider’s configuration from the phishing page outward: leaked getSyncSettings API responses client-side. The operator panel closes that loop. These screens show the same configuration from the other side, where the fraudster decides how the flow behaves before those choices are serialised and pushed to the phishing page.

The above screen is the platform’s sync settings page. It controls both the victim experience and the operator workflow: device access rules for Android, iOS, desktop, bots/crawlers, and other mobile devices, maximum visit counts, backend behaviour such as forced redirects. Interestingly, there is several voice settings suggesting that operators could setup a "Fraud Operations Center", ringing every time a victim landed on a specific page or reached a specific step. As suspected, the behaviour we saw client-side, is configurable from the panel.

The second screen is the card submission configuration. It exposes the exact fields we had been parsing from getSyncSettings: switches to reject debit or credit cards, an optional Luhn validation check, and free text boxes for BIN blacklists and whitelists, one issuer prefix per line. Seeing Luhn算法校验 as a simple on or off control confirms that card validation is operator chosen, not always enforced.

It also explains one oddity in the data. The BIN 422222 appeared blacklisted almost everywhere, but the panel shows it directly in the grey placeholder text beside 411111 and 433333. That makes it unlikely to be a real targeting decision. More likely, operators inherited the value from the default template or copied the example into live configurations. The BIN list is still useful signal, but this one value is probably just noise introduced by the product itself.

Notably, we do not see an IP blacklist control on these screens. That matches what we found in the client code: completed payment records appear to be maintained as a background ledger, not exposed as a simple operator facing filter.

Configuration that confirms Part 1

Three screens close the loop on our Part 1 infrastructure findings.

The Cloudflare integration with automatic TLS confirms, from within The Outsider, the exact front-door we dissected: Cloudflare reverse-proxy fronting with automatic certificate issuance, SSL terminated at the edge, and bulk domain add.

And the one-click auto-deployment feature launches a complete Outsider backend on Tencent cloud, with Redis, Docker, MySQL and Nginx provisioned automatically.

A last, satisfying confirmation: the page-flow filenames we recovered client-side in Part 1 (a_login.html, b_info.html, c_pay.html, d_2fa.html, d_sms.html, f_pin.html) are the platform's own naming convention, visible directly in the panel's template structure. What we inferred from the outside is exactly what the operators see on the inside.

The economics of access

The Outsider is not sold in dark web whispers. It is packaged as a self service product.

The Telegram bot screenshot below shows @OutsiderCodeBot issuing an activation code, install URL and default backend password (123456 😅) after deducting $102.40 for 30 days of access. That price likely reflects an early launch or demo transaction, not the later pricing described in Google’s complaint. By the time of the complaint, Outsider licences were listed at $88 per week or $200 per month, suggesting prices may have increased as the platform matured.

Google’s complaint states that members purchased more than 250 Outsider licences between August 2025 and March 2026. Even at the lowest listed price, that puts licence revenue in the tens of thousands of dollars before renewals, hosting, support or adjacent services. So in short, low access cost for operators, recurring revenue for developers, and a platform designed to turn each licence into hundreds of phishing sites.

The economy around the machine

The Outsider sits at the centre of a specialised criminal economy, coordinated largely in the open Telegram channel dedicated to The Outsider operators, where every function the platform does not perform is advertised by someone who does. Google’s complaint formalises this economy into five broad groups. The Telegram channels we dissected show those same groups breaking down into more specialised services: list developers, operators, data brokers, Spammers and SMS providers, account suppliers, phone providers and cash out crews. The roles that surround the kit are clear.

Developers build and sell the phishing kit. The Outsider is one of several competing platforms in this space, such as Lighthouse and Darcula, that operators can pick from.

Operators licence the kit and run campaigns. Many have little technical skill, the panel and the community are what make that possible.

Data brokers supply target phone number lists curated by region/country and, crucially, by device type: iPhones reachable over iMessage versus Android devices reachable over RCS. Google names one such broker in their complaint.

Spammers and SMS providers own the delivery: farms of iPhones for iMessage, Android for RCS, plus SIM banks and modems to send at volume. One Telegram ad puts it plainly: “experienced guy doing Apple SMS push, if you need it, come to me.”

Account fraud specialists mass produce the fake Apple and Google accounts those farms burn through.

SIM and physical phone providers keep the farms supplied with hardware.

Money launderers and cash out crews sit at the end of the chain, turning stolen payment access into money. In this ecosystem, that can include mobile-wallet provisioning, tap-to-pay purchases, physical POS terminals, gift-card conversion, mule accounts and fake merchant activity. The Telegram images specifically support the mobile-wallet and POS/tap-to-pay side of that model.

The picture above, advertised in the operator Telegram channel, is consistent with the model where actors likely pass 3D Secure once in The Outsider, to add stolen cards to a soft wallet, then use the wallet for later transactions that may not trigger the same challenge again.

Taken together, the pictures collected from the public Telegram channels show the assembly line around The Outsider: phone farms for delivery, target lists for reach, devices for scale, and cash-out services for monetisation. We treat those posts as ecosystem evidence, useful for showing advertised roles and capabilities, not proof that every advertised service was used in every Outsider campaign. Still, they highlight the core point: a person with little technical ability can licence the kit, buy each missing capability from a specialist, and run a campaign end to end. That division of labour is what turns a phishing kit into an industry.

Our numbers, and theirs

We built our estimate from the bottom up, unaware of the FBI operation. When the public figures appeared, the fit was reassuring, but the numbers need to stay separate.

The FBI attributed roughly $1.9 billion in losses and 3.87 million stolen credit cards to the wider operation since July 2023. Google’s complaint describes a narrower, more recent slice: 1.59 million malicious URLs over six months, a peak of 62,993 new phishing pages in one day, 100,000+ victims, and an earlier version that stole 36,000 cards across 95 countries.

Our own bottom-up estimate, around 244,000 victims and USD 2.4M-7.3M for the slice we could see over five months, lands below the full-operation totals and in the same broad range as the window described in Google’s complaint. Two methods, opposite directions, same Phishing-as-a-Service.

What this series showed

Across two posts we started from a single text message and ended with a criminal platform that is measured, priced, named, and mapped, built entirely from open sources and the platform's own mistakes.

The tapetum lucidum exists to catch low light to helps the eye make sense of shapes in the dark. That is how this investigation worked. One small signal, one loose thread, followed until The Outsider came into view.

Appendix: Observed infrastructure and channels

Primary domain:
- outsider-code[.]cc

Telegram channels and bots:
- Main developer diary channel: @sinkintopd
- Operator discussion group: @sinkintojl
- Appeals and feature suggestions: @sinkinto01
- Source-code self-service purchase bot: @OutsiderCodeBot
- Tencent server purchase bot: @OutsiderServerBot

Private Telegram invite:
- t[.]me/+9jgACGdtHyg4ZTRl

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.

Follow along: x.com/tapetumlabs · linkedin.com/company/tapetumlabs