Bluekit PhaaS: The White-Label Supply Chain the Newswire Missed

DISCLAIMER: This research was conducted entirely through passive and open sources, with one narrowly scoped exception. OSINT collection used WHOIS, certificate transparency logs, public DNS, SPF records, internet-wide banner scanning platform data, publicly served web resources, and public threat intelligence feeds. The Bluekit Tor hidden service was probed only with unauthenticated HTTP requests against URLs the operator published in their own public Telegram channel, with no modification of data, no disruption of service, and no interaction beyond what an ordinary browser would perform. JavaScript chunk analysis was performed on files served publicly from that hidden service with no authentication required. SnagX infrastructure was identified through passive DNS enumeration and SPF record analysis only. Despite the vulnerabilities documented on the SnagX production server, no exploitation was conducted or attempted. This post is published as a threat intelligence disclosure in the public interest to assist defenders and inform takedown efforts.

---

TL;DR: Bluekit is not just another Phishing-as-a-Service platform. It is a multi-tenant white-label PhaaS engine, and buried inside a JavaScript bundle we pulled from its Tor hidden service is the configuration for a second brand, SnagX, a Chinese-market reseller charging 2.8x Bluekit's prices to a completely separate operator base. The Bluekit operator ("petrushka") has maintained near-perfect infrastructure anonymity since day one. The SnagX operator has not. This post documents how we found SnagX's real origin IPs, what lives on those servers, and what defenders need to block before the pending snagx[.]cc launch completes that supply chain.

---

Contents

1. Background, the April newswire and what it missed
2. Threat actor profile, petrushka
3. Infrastructure analysis, Bluekit
4. The SnagX discovery
5. Methodology and passive reconnaissance notes
6. Kit capabilities, what operators are buying
7. Telegram channel intelligence
8. Technical architecture
9. Active Tor reconnaissance
10. Market context and competitive positioning
11. MITRE ATT&CK mapping
12. Detection and defender guidance
13. Timeline
14. IOC table

---

1. Background, the April Newswire and What It Missed

When Bluekit launched publicly on 2026-03-23 across BreachForums, CrackingX, and LeakForum simultaneously, it generated the usual cycle of threat intelligence coverage. Varonis published their findings on 2026-04-29. BleepingComputer, SecurityWeek, HackRead, SC Media, and TechRadar followed. The coverage was accurate on what the kit does: AiTM session cookie theft, Evilginx under the hood, Telegram exfiltration, 40+ brand templates, voice cloning, bulk SMS, MFA bypass. Good work, worth reading.

What none of those pieces had time to find, because this kind of infrastructure archaeology takes days, not hours, was the supply chain sitting underneath. Bluekit is not a single PhaaS storefront operated by one actor. It is a white-label multi-tenant PhaaS engine. And embedded in its own JavaScript bundle, served passively from its own Tor hidden service, is the configuration for a second operator brand called SnagX, targeting the Chinese-speaking criminal marketplace at a substantial markup.

This post covers what we found between 2026-05-03 and 2026-05-09: the JS bundle analysis that revealed the SnagX brand configs, the SPF pivot that exposed SnagX's real production server (with 27 CVEs on it), the actor OPSEC slips that link petrushka's three forum accounts cryptographically, and what the pending snagx[.]cc launch means for defenders.

If you are a threat hunter or blue team practitioner, the detection guidance section is what you are here for. But the infrastructure story is worth reading end to end, it illustrates a passive-only methodology that works even against disciplined operators.

---

2. Threat Actor Profile, petrushka

The Handles

The operator goes by petrushka on BreachForums and LeakForum, and petrushkablue on BitcoinTalk and CrackingX. Every forum account associated with this operator was registered in April 2026. Zero prior reputation, zero vouches, no transaction history, the profile of either a true newcomer or an experienced actor who burned their old identity and started fresh.

The handle itself is a tell. Petrushka is the central character of Russian puppet theater, a trickster figure, chaotic, hard to pin down, plays all sides. That is not a coincidence, that is a cultural reference chosen deliberately by someone familiar enough with Russian folklore to think it is funny. We will come back to why this matters for the actor maturity assessment.

The Forum Footprint

The launch day (2026-04-21) deserves attention for its choreography alone:

• BitcoinTalk: Topic 5580858, posted 07:52 UTC. Account UID 3754492 was registered the same day at 07:44 UTC, eight minutes before the first post, and was never used again.
• BreachForums: UID 672756, first post 15:09 UTC.
• CrackingX: Thread /threads/72780/, approximately 15:45 UTC.
• LeakForum: Same day.

Four platforms, one day, one operator, with the BitcoinTalk account appearing to be a throwaway specifically for the announcement, registered and abandoned within hours. That is logistics planning, not spontaneous posting.

OPSEC Slip #1, The Session ID

Forum sessions are normally invisible to other users. On CrackingX, petrushka inadvertently included their session token in a post on thread /threads/72780/. The ID in question:

053214a694ac2b7e410dcf3b14ed8e0157f1d82718ca4ff71088db81e5c9b57817

The same session ID was subsequently confirmed across BreachForums, LeakForum, and CrackingX. This is not circumstantial, this is cryptographic proof that a single individual controls all three accounts. Whether this matters for attribution depends on what else gets tied to it over time, for now it is useful for law enforcement analysts who pull forum logs during a seizure.

OPSEC Slip #2, Two Jabber Addresses, Two Servers

Petrushka published different XMPP contact addresses across different forums:

• petrushka[at]exploit[.]im, listed on CrackingX and BreachForums
• petrushka[at]jabber[.]fr, listed on LeakForum

exploit[.]im is a notable choice: it is a self-hosted XMPP server tied to the Russian-speaking cybercrime ecosystem, hosted on infrastructure that routinely ignores abuse complaints. The jabber[.]fr address is more generic. The discrepancy might be intentional compartmentalization, or it might be laziness, but using two different XMPP identities across different forums is itself a correlation point.

Actor Maturity Assessment

All four accounts are brand new. The kit quality is not. Hold those two facts together.

The indicators pointing to an experienced actor operating under a fresh identity:

1. Infrastructure hygiene from day zero. Cloudflare Tunnel was in use before the first public post. There was no "learning period" where the origin server was briefly exposed. Someone who knew exactly what they were doing set this up before they announced anything.
2. Automated TLS deployment. Wildcard Let's Encrypt certificates were issued on the day of domain registration, across multiple domains. This is tooling, not manual setup.
3. Dynamic wallet generation. Per-customer Monero and ETH address generation is not a feature a beginner reaches for. It requires either building or integrating a crypto payment library, and it is specifically designed to defeat blockchain surveillance.
4. Multi-tenant white-label architecture. The SnagX integration, hostname-based brand switching baked into the JS bundle, is not something you add to a first project. It implies the operator expected to have resellers before the platform launched.
5. The handle. "Petrushka" as a deliberate cultural marker is someone performing a persona, not just picking a username.

The kit claims Dominican Republic jurisdiction and servers in the DR. Given the Russian cultural markers, REGRU-SU registrar choice for the primary production domain, and the exploit[.]im XMPP preference, that jurisdiction claim is almost certainly misdirection. We assess moderate-to-high confidence that petrushka operates from within or has strong ties to the Russian-speaking cybercrime community.

The YouTube Persona, "wegweg"

Two days after registering bluekit[.]su, a YouTube channel appeared under the handle @user-sl1vg9ku3q (auto-generated, no vanity URL) with channel ID UCyNljAtkwAVKmBcm8EGVBaw. The channel name is "wegweg."

It uploaded two videos.

Dashboard walkthrough, full operator panel tour, shared in forum posts as proof-of-concept (YouTube ID 1svs8r2WBco, unlisted):

Google Sites phishing integration tutorial, how to embed Bluekit's Gmail template inside a sites.google.com/view/ page for a legitimate-looking Google domain lure (YouTube ID rkvKL-g09JE, unlisted; Telegram Post #42, 629 views, 34 forwards, most-forwarded post on the channel):

DarkWebInformer connected this channel to petrushka's Telegram presence. The unlisted status matters: these are not public marketing videos, they are meant to be shared directly with potential customers via forum links.

---

3. Infrastructure Analysis, Bluekit

Domain Footprint

Every Bluekit domain routes through the same Cloudflare account, identifiable by the shared nameserver pair fish.ns.cloudflare.com / osmar.ns.cloudflare.com.

The .pk and .cc registrations on the same day (2026-03-23) suggest these were bought as a pair, one for production, one as a backup. bluekit[.]ws was registered on 2026-04-28, the same day NICENIC killed .cc. The actor published the new domain in their Telegram channel thirty-three minutes after the suspension notice. Thirty-three minutes. They were watching their abuse inbox in real time and had the contingency domain pre-selected.

The platform favicon (retrieved from bluekit[.]ws via Bitwarden icon cache) is a stable cross-domain fingerprint:

SHA256 hashes: 8b675a0f... (ico), 5eb82072... (svg). MurmurHash3 values usable in Shodan/Censys: -1181573582 (ico), -1678519318 (svg).

TLS Intelligence

Every Bluekit certificate is a wildcard (*.domain.tld) issued by Let's Encrypt (E7/E8 intermediates), deployed on the day of domain registration. No gaps, no manual issuance. This is automated tooling.

One certificate detail stands out: a second TLS cert was issued for bluekit[.]pk on 2026-04-16, with validity extended through 2027. The actor was planning to operate that domain for at least a year. Two weeks later, Cloudflare blocked it. Infrastructure plans rarely survive contact with abuse teams.

The WHOIS registrant on bluekit[.]cc listed country: AU, state: MO. Australia does not have a state called MO. Missouri does, but Missouri is in the US. This is almost certainly falsified registration data, which is mundane for this ecosystem, but worth noting for anyone building a legal attribution chain.

Why We Couldn't Find the Origin IP

The short version: we couldn't, and that is by design.

Every origin IP discovery technique we attempted came up empty:

• Historical DNS: No pre-Cloudflare records exist. CF was in place before the first URLScan appearance.
• ACME challenges: DNS-01 wildcard certs mean there was never an HTTP-01 challenge token exposed on a known path.
• IPv6: All AAAA records resolve to Cloudflare anycast space.
• SPF/MX records: None exist. The mail infrastructure is completely hidden.
• Shodan/Censys: Only Cloudflare anycast IPs returned.
• nginx ETag pivoting: The 404 ETag "b11cvpkueto" from the onion service has not yet been indexed on any non-CF server.
• Header analysis from the onion: Deliberately minimal (more on this in the Tor section).

The conclusion is that cloudflared is in use, the operator's server opens an outbound tunnel to Cloudflare, with no inbound ports exposed. The origin server is invisible to anyone who does not already have the tunnel credentials. This is the correct way to hide infrastructure, and petrushka has been doing it since day one.

One speculative signal: scan.mass.report logged a 21.3-second time-to-first-byte for bluekit[.]cc through Cloudflare's Toronto PoP. That is anomalously slow for a CF-proxied site. It is weakly consistent with the claimed Dominican Republic jurisdiction, long tunnel latency can indicate geographic distance, but network load and PoP selection make this too noisy to stake an attribution claim on.

The Bluekit origin stays dark. The SnagX operator is a different story entirely.

---

4. The SnagX Discovery

Finding #1, Brand Switching in the JS Bundle

When we pulled the JS chunks from the Tor hidden service (methodology in the next section), one file stood out: 0ga04m0ate156.js, 20,332 bytes. Inside it was a useConfig() function that should not exist in a single-brand application:

function useConfig() {
  const hostname = window.location.hostname;
  const brandMap = { "snagx": snagxConfig };
  for (const key of Object.keys(brandMap)) {
    if (hostname.includes(key)) return brandMap[key];
  }
  return bluekitDefaultConfig;
}

This is hostname-based brand switching. When the application is accessed from a hostname containing "snagx", it serves an entirely different brand configuration. When accessed from any other hostname, it falls back to the Bluekit defaults. The same codebase, two storefronts.

Both configurations were hardcoded in the same bundle.

Bluekit default config:

{
  name: "bluekit",
  telegramBotUsername: "bluekit_official_bot",
  subscriptionPrices: { 7: "90.00", 14: "170.00", 30: "350.00" },
  subscriptionNotifyChatId: "-5223277724"
}

SnagX white-label config:

{
  name: "SnagX",
  telegramBotUsername: "snagx_official_bot",
  telegramLink: "https://t.me/SnagXnews",
  subscriptionPrices: { 7: "249.00", 14: "449.00", 30: "799.00" },
  subscriptionNotifyChatId: "-5175727718"
}

The subscriptionNotifyChatId values are the Telegram channel IDs where victim credentials land after a successful phish. Each brand routes stolen sessions to a separate operator. That is the architecture of a reseller program, not a single-actor operation.

The pricing disparity is worth noting: SnagX charges $249/$449/$799 for 7/14/30 days against Bluekit's $90/$170/$350. That is a 2.77x markup. Whatever SnagX's operator is pitching to their customers, exclusive features, Chinese-language support, closer customer service, they are extracting significant margin on top of Bluekit's fees.

Finding #2, The SnagX Operator

The Telegram channel @snagx_news (Telegram Channel ID: 3836331347) describes itself in Chinese: "反向代理中间人解决方案", "Reverse proxy AiTM solution." The primary operator handle is @nm9333 (Telegram ID: 8,406,946,345, Telegram Premium subscriber). The market is Chinese-speaking criminal operators.

SnagX predates Bluekit's public channel. A direct comparison of Telegram channel IDs reveals a counter-intuitive sequence: @snagx_news (ID 3,836,331,347) has a lower channel ID than @bluekit_news (ID 3,894,423,737), meaning SnagX's Telegram channel was created before the primary Bluekit news channel. The SnagX bots and operator accounts follow the same pattern, @snagx_official_bot (ID 8,569,769,696) predates @bluekit_official_bot (ID 8,621,028,539), and @nm9333 (ID 8,406,946,345) predates the @bluekit_support account (ID 8,799,626,929).

This ordering revises the reseller narrative significantly. nm9333 is not a downstream customer who purchased a white-label license after the fact. The SnagX infrastructure, the channel, the bot, the operator account, was set up in parallel with or before the primary Bluekit infrastructure. nm9333 is most accurately described as a co-founding partner with pre-arranged Chinese-market rights, not a reseller who signed up post-launch.

The domain snagx[.]cc was registered on 2026-04-13 through Gname.com (Singapore), with registrant data pointing to Hong Kong/China. Its WHOIS record was updated on 2026-05-06 and currently resolves to NXDOMAIN, consistent with final pre-launch configuration. nm9333's bio explicitly lists https://snagx.cc/ as the official website, confirming it is the intended operator panel domain.

A GitHub user named snagx (ID 190288407) exists with zero public repositories. Namespace reservation, nothing more, but it is the kind of forward planning that shows operational intent.

Finding #3, The SPF Pivot

Here is where the infrastructure discipline gap between the two operators becomes stark.

Petrushka has no SPF records on any Bluekit domain. None. The mail infrastructure is completely dark.

SnagX's operator published their entire sending infrastructure in a public DNS record. A lookup on snagx[.]co returned:

v=spf1 ip4:92.204.255.237 ip4:188.138.39.199 +a +mx +ip4:134.119.212.155 ~all

SPF records exist specifically so receiving mail servers can verify that a sending IP is authorized. They are public by design, the entire email authentication system depends on anyone being able to look them up. Using this for threat intelligence is not exploitation, it is reading a sign that was posted in public.

That one DNS record handed us four SnagX sending IPs.

The SnagX Server Profile

The PTR record for 92.204.255.237 resolves to brato.dnshfe.com. Both origin IPs use HFE Internet's custom nameservers (ns1.dnshfe.com / ns2.dnshfe.com). Co-hosted at the same IP cluster: cipherbitz[.]com and n8n.cipherbitz[.]com, an N8N workflow automation instance. The N8N instance is interesting context: N8N is commonly used for automated pipeline orchestration, and its presence on the same host as a PhaaS operator's backend is worth noting.

The vulnerability profile on 92.204.255.237 is, to put it charitably, not great. PHP 7.2.34 reached end-of-life in November 2020, it has been unsupported for over five years. Passive intelligence shows 27 CVEs against this server, including five from 2026 alone. Exposed ports include MySQL/MariaDB on 3306, FTP on 21, and the full cPanel/WHM management stack (ports 2082, 2083, 2086, 2087, 2095, 2096). Shodan has tagged this host with eol-product, open-dir, database, and starttls.

We did not exploit any of these vulnerabilities, and we are not going to describe which 2026 CVEs are most interesting here, abuse teams and law enforcement can make that call. The point is that the SnagX operator's production infrastructure is significantly more exposed than their Bluekit upstream's, which is a meaningful gap in the supply chain's overall security posture.

Architecture Clarification

One important nuance: snagx[.]co runs Laravel + Vite, not Next.js + Turbopack. Bluekit runs Next.js + Turbopack. These are different stacks.

The most coherent interpretation is that snagx[.]co (Laravel) is the SnagX marketing and billing layer, the storefront where Chinese-speaking operators sign up and manage subscriptions. The actual phishing panel, when a customer logs in, will be served via Bluekit's infrastructure using the hostname-switching mechanism in the JS bundle. The pending snagx[.]cc domain is likely where that operator panel will live, served by Bluekit's engine with the SnagX brand config.

So the architecture is roughly: SnagX billing (Laravel/snagx.co) → Bluekit panel engine (Next.js/snagx.cc, once live) → victim credential channels (separate Telegram chat ID per brand). Three layers, two operators, one engine.

---

5. Methodology and Passive Reconnaissance Notes

All Bluekit Tor hidden service path probing was passive HTTP observation only, no modification of data, no disruption of service, no credential theft, no interaction beyond what an unauthenticated browser would do visiting publicly advertised URLs. The onion address was published by the actor in their public Telegram channel.

SnagX infrastructure was identified entirely through passive DNS enumeration and SPF record analysis, two techniques that require zero interaction with target systems and are standard practice in email deliverability and threat intelligence workflows. Despite the 27 CVEs on the SnagX production server, no exploitation was conducted or attempted.

JS chunk analysis was performed on files served publicly from the Tor hidden service with no authentication required.

---

6. Kit Capabilities, What Operators Are Buying

The Template Library, 40+ Brands and Counting

At launch in late March 2026, Bluekit shipped with: Apple/iCloud, Gmail, GitHub, Twitter/X, Amazon US, Ledger, Trezor, CoinSpot, KuCoin, Binance, ProtonMail, Zoho, Hotmail, Facebook, Yahoo, Zara, and IONOS.

Post-launch additions accelerated quickly: a Gmail passkey variant, Google Sites integration, Airbnb, Booking.com, Booking Partner, Amazon Japan, Atlantic Bank, pairs.lv, Walmart, LastPass, Evernote, BNC Bank Enterprise, Facebook (mobile), Amazon (auto-password-change), OneDrive, and Outlook 2. The cadence of additions, roughly two to three templates per major Telegram post, suggests active development is ongoing.

AiTM and MFA Bypass

The core technical capability is Adversary-in-the-Middle via Evilginx. In practical terms: a victim visits a phishing URL, the kit proxies the real login page to them, and the victim authenticates against their actual account, but Bluekit intercepts the session cookie after authentication completes. This bypasses time-based one-time passwords (TOTP) and, more concerningly, FIDO hardware keys, because the session is stolen after the authentication ceremony has already succeeded. The phishing page is the real login page, seen through a proxy that is recording everything.

The 2FA bypass module uses geolocation and browser/User-Agent spoofing to make the replayed session look plausible to the target service's fraud detection.

Post #14 published a side-by-side comparison of the Coinbase template versus the real Coinbase site (53s clip, retrieved from Telegram):

Post #25 demonstrated the FULL-PROXY ZARA shop clone (62s clip):

The intro demo video from Post #10 is the most-viewed piece of content on the channel at 874 views (93s):

P2P Page Rendering, The Anti-IR Feature

Post #40, published 2026-04-21 at 18:03 UTC, announced: "The main connection is no longer visible in DevTools in any browser."

This is a deliberate anti-incident-response technique. The primary C2 channel was redesigned to route outside the browser's standard request pipeline, not visible in the Network tab. The most probable implementation is WebRTC, which establishes peer-to-peer data channels that standard browser developer tools do not surface by default. For incident responders doing live triage, this means you will not see the C2 traffic by opening DevTools on a compromised browser session. You need network-level visibility, endpoint detection with network flow capture, or out-of-band packet capture. Browser-only analysis will miss it.

Google Sites Abuse

Posts #42 and #43 (2026-04-23) and the YouTube tutorial at rkvKL-g09JE document how Bluekit templates can be embedded inside Google Sites pages at sites.google.com/view/[anything]. The resulting phishing link has google.com in its URL. A significant fraction of email security filters allow-list google.com outright, and most non-technical users have no reason to be suspicious of a link to a Google domain. This technique merits a specific detection rule (see Detection Guidance).

Voice Cloning

A built-in voice cloning module is listed in the kit's feature set. This integrates with what is almost certainly a TOAD (Telephone-Oriented Attack Delivery) workflow, phish the session, then call the victim with a synthetic voice clone of their bank, IT helpdesk, or whoever is most plausible given the template used. We do not have technical details on the voice cloning implementation from our passive reconnaissance.

Bulk SMS

Beta feature, added with Post #33 (2026-04-09): batch SMS up to 500 numbers per run, with support for 13 different telecoms and custom Sender ID. Custom Sender ID is the capability that allows operators to spoof an arbitrary business name or number in the SMS "From" field. Combined with the phishing templates, this is the SMS smishing delivery layer.

AI Assistant Integration

The kit ships with an "abliterated" Llama model as default, an uncensored local model that will assist with phishing content without the standard safety restrictions. GPT-4.1, Claude Sonnet 4, Gemini, and DeepSeek are listed as optional replacements. The AI assistant appears to support template customization and victim interaction, the voice cloning module presumably uses whichever model is configured.

The @whitehorseBHW SMTP Supply Chain

Post #36 (2026-04-12) recommended @whitehorseBHW as the preferred SMTP vendor, explicitly by name, in a public Telegram channel. On Telegram, the handle is @whitehorsebhw; on BHW (BlackHatWorld) forums, the account "thewhitehorse" has been active since November 2022 with 799 posts.

This is a pre-integrated supply chain relationship. When multiple Bluekit operators use the same recommended SMTP vendor, a high-volume abuse complaint or law enforcement action against @whitehorseBHW would degrade a significant portion of Bluekit's active customer base simultaneously. For threat hunters: SMTP headers from phishing emails delivered through this supply chain may carry infrastructure fingerprints attributable to this single vendor.

Launch Browser, Session Persistence Without Fingerprint Risk

Post #18 (2026-03-31) introduced a "Launch Browser (BETA)" feature described in Post #19 (58s demo):

"This feature lets you open a Mammoth session in a pop-up browser using the same logged-in session, so you don't need to worry about fingerprinting, session mismatches or matching IPs. The pop-up shares the same session and network context where Mammoth is already logged in."

The feature solves a practical problem for phishing operators: stolen session cookies often cannot be replayed from a different IP without triggering fraud detection. By popping a browser that shares the intercepted network context, the operator sidesteps this entirely, the session replay looks like the victim's own connection.

FULL-PROXY, Full-Site Mimic and Fake Shop Infrastructure

Post #22 (2026-04-04) introduced a "FULL-PROXY" template category, demonstrated with the ZARA shop clone above:

"Added a new category of sites FULL-PROXY which allows you to fully mimic pages (for example: Nike or Zalando) and capture any desired information even at checkout. You can set up fully automated fake shops and get all user credentials. It reproduces the entire page and its functionality: product browsing, cart operations, checkout flow, and other interactive elements."

This extends the platform beyond credential phishing into full e-commerce fraud infrastructure. A fake ZARA or Nike storefront can capture payment card data, shipping addresses, and account credentials, not just login sessions. Combined with the Bulk SMS smishing module, operators can run end-to-end: SMS lure → fake checkout → payment card exfiltration.

Google Safe Browsing Evasion, Perceptual Hash Bypass

Post #14 (2026-03-27) documents a specific technique embedded in every template by default:

"By default, the colors are shifted by 2% in hue, and the entire page has a 1-pixel offset to avoid being quickly flagged by Google Safe Browsing. You can configure all of this in the site settings."

Google Safe Browsing's visual similarity detection compares rendered pages against known-legitimate sites using perceptual hashing. A 2% hue shift and 1-pixel spatial offset are below human perception thresholds but outside the tolerance window of simple image comparison algorithms. The configurable nature of this setting means operators can tune it per-target. Detection approaches based on rendered-page visual similarity need to account for this class of perturbation.

Gmail Account Persistence, Hardcoded Recovery Credential

Post #30 (2026-04-07) added an automatic post-compromise persistence mechanism for Gmail:

"Added option that allow you to automatically change password and generate backup codes after success hit from Gmail... The password is always changed to: blueKIT123#! and its DISABLED by default - you have to turn it on if you want to test."

The hardcoded string blueKIT123#! is a direct detection indicator. Any Google account where this becomes the password after an AiTM session was likely compromised by a Bluekit operator using this feature. Incident responders investigating suspected Gmail AiTM compromises should check whether this password was set during the attack window.

Pricing Model

Post #50 (2026-04-29) announced a price increase post-maintenance. SnagX charges $249/$449/$799 for the same periods, suggesting Bluekit's post-maintenance pricing could move anywhere in that range.

Accepted payment: Monero (primary), BTC, LTC, TRX, USDT-TRC20, USDC, ETH, SOL. Per-customer dynamic wallet generation on all chains, no static address to monitor on-chain.

---

7. Telegram Channel Intelligence

The bluekit_news channel (514 subscribers as of 2026-05-11) is petrushka's primary customer communication channel. Its 50-post public history is a remarkably candid operational record, each changelog entry documents new capabilities in the operator's own words, and the sequence reveals both the development pace and specific anti-detection decisions that would not surface anywhere else.

The CIS Carveout, Geopolitical Framing

Post #13 (2026-03-27) addressed the question of targeting restrictions directly:

"Geo policy: We do NOT operate in any CIS countries. it's illegal of the rules to target any entities with close ties to Russia. As a result, we have implemented a default blacklist that blocks all users from CIS countries. It can be disabled only for testing purposes. We have also removed the option to purchase .ru domains through our control panel."

This is a standard constraint in the Russian-speaking cybercrime ecosystem, an explicit prohibition on CIS targeting that functions as both plausible deniability and a deterrent against Russian law enforcement interest. The operator noted the .ru domain removal was reactive: "This option was available solely because we had simply listed all the TLDs that our provider allows us to sell." The CIS block appears to have been implemented after customer questions in the first two days of operation.

Anti-Detection Engineering, The 2% Hue Shift

Post #14 (2026-03-27) reveals a specific technical decision about template appearance, published alongside a side-by-side comparison video of their Coinbase template versus the real site (the same clip embedded earlier in this post):

"By default, the colors are shifted by 2% in hue, and the entire page has a 1-pixel offset to avoid being quickly flagged by Google Safe Browsing. You can configure all of this in the site settings."

This is a documented countermeasure against perceptual hash-based phishing detection. The parameters, 2% hue, 1-pixel offset, are calibrated to be invisible to humans while exceeding the tolerance of image comparison algorithms used by safe browsing services. Configurable per-site means operators can dial it up or down based on target detection sensitivity.

P2P Renderer, Posts #39 and #40

Post #39 (2026-04-18) was a two-day preview:

"Today/tomorrow may experience some minor issues with page rendering. We are rewriting a significant part of the renderer to P2P to improve responsiveness and latency."

Post #40 (2026-04-21, 18:03 UTC) confirmed the deployment:

"We completely rewrote our page rendering; it now uses P2P technology, so the main connection to our server is no longer visible in DevTools in any browser. It should work smoother on mobile devices with mobile internet and also older device like iPhone 6S. On WIFI and PC there shouldn't be any difference. The quality gonna be improved in next days."

The explicit statement that "the main connection to our server is no longer visible in DevTools" is a deliberate design goal, not a side effect. The operator treats IR tooling visibility as a threat to their platform and engineered around it. Note also the specific device reference, iPhone 6S runs iOS 15 at maximum, released 2015. The operator is optimizing for the oldest possible victim device fleet.

The Reseller Program, Post #38

Post #38 (2026-04-17) buried the white-label program launch in a routine changelog:

"System that allow to be our reseller with custom domain && prices, so please reach us if you want to. We're looking to expand into different markets."

The SnagX configuration was already compiled into the JS bundle at this point, meaning at least one reseller (SnagX) was integrated before the public reseller launch announcement. The phrase "expand into different markets" is the tell: SnagX's Chinese-market angle was planned, not accidental.

The NICENIC Suspension, Post #44 Verbatim

Post #44 (2026-04-28) published the full abuse report that killed bluekit[.]cc, a remarkable operational transparency move that serves simultaneously as customer communication and as marketing ("we stay up even when hit"):

"One of our domains: bluekit.cc hosted on NICENIC has been suspended (they literally told in report that do not have any serious proof about that but due to shitty ICANN rules our domain got banned anyway)"

The abuse report text, published verbatim by petrushka:

"The site bluekit.cc is associated with phishing kit services, as indicated by its title and content. Although no direct credential harvesting mechanisms were observed, the site's nature and the presence of dynamic scripts suggest potential for abuse. The domain is newly registered and hosted on Cloudflare, which raises concerns about its intent. It is recommended to monitor this domain closely for any changes in behavior or content."

Automated Risk Score: 53/100

Full evidence package: https://scan.mass.report/scan/28fa1692-be1f-442a-82d8-c975d6e39102

The NICENIC response, also published verbatim:

"Dear Valued Customer, Thank you for your attention to this matter. We would like to inform you that NiceNIC has received a DNS abuse report concerning your domain name from a complainant. After a thorough review, the reported activity has been confirmed as falling within the scope of DNS abuse, with sufficient evidence supporting the claim. As a result, the domain has been suspended in full compliance with Section 3.18 of the Registrar Accreditation Agreement and relevant ICANN regulations."

Thirty-three minutes after the suspension notice, bluekit[.]ws was registered (Post #49). The actor was watching their inbox in real time with a contingency domain pre-selected.

Operator Behavior, View and Forward Analytics

The Telegram API exposes view and forward counts per message, which function as a signal for which capabilities operators find most valuable. Below are the top-forwarded posts in @bluekit_news (46 of 50 messages have metrics):

Post #42 (the Google Sites phishing integration tutorial, also uploaded to YouTube as rkvKL-g09JE) is the single most-forwarded piece of content, despite being the fifth-most viewed. Operators are actively sharing the Google Sites technique. This is the TTP they find most worth distributing to peers. The template list and pricing posts being heavily forwarded indicate the service is actively recruited for, not just self-purchased.

@snagx_news by contrast: 6 to 8 views per post, zero forwards across all 12 posts, consistent with an early-stage channel with no real audience yet at time of observation.

Captcha Evasion, Actual Screenshots (Posts #34, #35, #46 to #48)

The kit ships multiple custom captcha styles configurable per phishing site. Screenshots from the Telegram channel posts confirm the visual designs.

Cloudflare + reCAPTCHA variants (Post #34, Post #35):

Extended captcha styles, Amazon, Microsoft, custom, Apple, reCAPTCHA-centered (Posts #46 to #48):

The captcha is displayed before the Mammoth AiTM session starts, functioning as an additional antibot layer. The per-brand styling (an "Apple" captcha appearance on an iCloud phish, an "Amazon" style on an Amazon phish) makes the pre-authentication step look native to the target brand.

SnagX Chinese-Language Channel (@snagx_news)

The @snagx_news channel (Telegram Channel ID: 3,836,331,347) first posted 2026-04-11. Its 12 public posts are a bilingual Chinese/English mirror of Bluekit's changelogs, lagging 4 to 17 days behind the English originals. Channel description: "反向代理中间人解决方案", "Reverse proxy AiTM solution."

Contact handle: @nm9333 (Telegram ID 8,406,946,345, Premium account). Operator bio: "Please feel free to contact and remember to check news channel: t.me/SnagXnews Official Website: https://snagx.cc/"

The channel ID ordering finding (covered in detail in the SnagX Discovery section above) establishes that @snagx_news was created before @bluekit_news. This is direct Telegram API evidence that SnagX's presence on the platform predates the primary Bluekit channel, consistent with nm9333 being a co-founding partner rather than a post-launch reseller.

One claim in Post #6 stands out:

"We have completely rewritten the source code and resolved all previously encountered issues. / 我们已经重新改写了源码，并解决了之前遇到的所有问题。"

This is inconsistent with what we observed in the Bluekit JS bundle, the SnagX brand configuration is embedded directly inside Bluekit's 0ga04m0ate156.js. If SnagX had genuinely rewritten the source code, their config would not appear as a hostname-switching variant in Bluekit's bundle. The "rewrite" language is marketing copy, possibly referencing a prior iteration of the kit that nm9333 was involved with before the Bluekit brand launched publicly.

---

8. Technical Architecture

Stack

The platform is built on Next.js with the App Router and Turbopack as the bundler, the same stack you would use to build a legitimate SaaS product. Server-Side Rendering means authentication logic runs server-side, which is part of why the maintenance-mode frontend does not expose the backend state. Authentication uses Next.js Server Actions (hash-based), deployable as standard Node.js. The almost certain deployment pattern is Docker + cloudflared tunnel.

The Turbopack build string turbopack-0bpd7yo0yk13c is the current build fingerprint. An earlier build string (turbopack-2a3b40d8e0f279b5) was present from 2026-03-29 to 2026-03-31, documenting a code change in that window.

Login Validation (from Zod schemas in 0ga04m0ate156.js)

These are the constraints validated client-side (and presumably server-side) for operator account creation:

• Username: /^[a-z0-9]{3,32}$/, 3 to 32 characters, lowercase alphanumeric only
• Password: 8 to 256 characters, minimum one uppercase letter
• Email: Standard format via z.email()

Password Hashing

From the FAQ extracted via the onion /faq path: Argon2id. That is the correct modern choice, memory-hard, resistant to GPU cracking. Ironically, the operator built better credential security into their illegal kit than many legitimate web applications ship. They also collect IP addresses and User-Agent strings from operators for their own antibot/security logging, which is its own kind of irony.

Build IDs for Cross-Domain Correlation

These fingerprints allow defenders to correlate Bluekit deployments across domains, even when operator-facing branding differs:

H_xCnvta7KGWEGUJM1Dq5         Build ID, bluekit[.]ws (current)
24IfYrxE8LODNqUSeenM6          Build ID, onion service (observed 2026-05-08)
turbopack-0bpd7yo0yk13c        Turbopack string, current build
turbopack-2a3b40d8e0f279b5     Turbopack string, old build (March 2026)

The two different build IDs on bluekit[.]ws and the onion service suggest either two separate deployments or an active mid-migration rebuild, consistent with the "awaiting a server delivery" maintenance announcement.

---

9. Active Tor Reconnaissance

Setup and Scope

On 2026-05-08, we conducted an active path probe of the Bluekit Tor hidden service using Kali Linux in Docker with a Tor SOCKS5 proxy. The onion address:

bluekitsmi6sd5mjurh3l7n7oeizbedoe2hw2lsljtb5nbxiul6hzkqd[.]onion

was first announced in Telegram Post #27 on 2026-04-04 at 20:53 UTC.

HTTP Headers

The response headers from the onion were minimal:

Server: nginx
Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate

No nginx version. No X-Forwarded-For. No CF-Ray. No internal IP addresses. The actor knows exactly which headers leak origin information, and they have stripped them. The headers on the onion look like they were written by someone who has read an nginx hardening guide recently.

Path Probe Results

The /admin 404 is mildly interesting, it means either the admin panel is at a non-standard path, or it is only accessible from specific source addresses, or it does not exist as a separate route (admin functionality folded into the operator dashboard with role-based access control). The API endpoint 404s confirm Next.js App Router, the auth APIs are handled through Server Actions, not traditional REST endpoints.

We attempted to bypass maintenance mode by varying the User-Agent header (curl default, Firefox UA, Googlebot UA, and an empty UA). All returned the maintenance page. The bypass is not User-Agent-based.

The Maintenance Page

The full maintenance message, verbatim:

"We are under maintenance. We are awaiting a server delivery. Also many changes relating to how our main systems work. Improvements will be huge, many problems will be solved. Time compensation will be granted to all subscribers. Should be back within few days, hard to tell exact time. Join our news channel for more informations. https://t.me/bluekit_news"

"Awaiting a server delivery" is corroborated by Post #50's announcement of "new infrastructure / new server." The timing of the maintenance, coinciding with the Varonis publication, the Cloudflare blocks, and the NICENIC suspension, raises the question of whether this is a genuine infrastructure migration or a deliberate cooling-off period after the first major wave of public attention. Probably both.

Authentication is Live

The most operationally relevant finding from the onion probe: despite the maintenance banner, the authentication backend is processing requests. We confirmed this via a Server Action probe:

POST /auth/login
Next-Action: 40bed2bb34f212262b71d0e0a61eb8bb8459595e52

Response → HTTP 200: {"success":false,"error":"Invalid credentials"}

The server is validating credentials and returning meaningful error responses. This is not a static maintenance page, the application is running, authentication is live, and active subscribers can likely still access their sessions. The maintenance is cosmetic from a backend perspective.

---

10. Market Context and Competitive Positioning

Timing the Market Entry

Bluekit's forum launch on 2026-04-21 came less than a month after Tycoon2FA was disrupted in March 2026, an operation that seized 330 domains and removed the dominant AiTM PhaaS from active operation. In the CrackingX thread, petrushka explicitly positioned Bluekit against "Evilginx Pro resellers like Tycoon2FA or EvilProxy." This is a deliberate market entry into a gap.

The current market leader in the post-Tycoon period is Mamba 2FA. Bluekit is positioning itself as the technically superior alternative, the feature set (voice cloning, P2P rendering, domain automation, multi-tenant architecture) is more advanced than what Tycoon offered at its peak.

ATHR, A Parallel Entry

ATHR is a separate AI-powered vishing and TOAD platform that went public the same month (Abnormal Security published on 2026-04-16). The infrastructure is distinct, different Cloudflare nameserver pair (kristin/yichun vs fish/osmar), the athr[.]cc domain created in 2021, a different operator entirely. These are not the same actor.

They are, however, functionally complementary. A Bluekit operator who steals a session can pivot to ATHR for an account-takeover confirmation call: "This is your bank's fraud department, we noticed unusual activity on your account...", with a voice clone of whoever is most convincing. Two separate operators, likely aware of each other, both filling the void Tycoon left. The market timing of two capable tools arriving simultaneously is worth noting, even if there is no shared infrastructure to document.

---

11. MITRE ATT&CK Mapping

These mappings reflect only techniques with observed evidence from this investigation, not capabilities claimed in marketing material.

---

12. Detection and Defender Guidance

Highest-Priority Detections

1. The Next.js Server Action hash

The login Server Action hash 40bed2bb34f212262b71d0e0a61eb8bb8459595e52 is a stable fingerprint across all Bluekit deployments. Network-level detection:

http.request.headers["Next-Action"] == "40bed2bb34f212262b71d0e0a61eb8bb8459595e52"

Any outbound POST with this header value is a connection to a Bluekit login endpoint, regardless of the domain it is hitting.

2. Cloudflare Turnstile sitekey

The sitekey 0x4AAAAAABDaGKKSGLylJZFA appears in the HTML of every Bluekit login page. Detection via proxy logs or endpoint HTTP inspection:

http.response.body contains "0x4AAAAAABDaGKKSGLylJZFA"

3. Turbopack build string

http.response.body contains "turbopack-0bpd7yo0yk13c"

This fingerprints the current Bluekit build in served JavaScript.

4. Favicon hashes

If your security stack ingests favicon hashes (Shodan, Censys, or endpoint tooling that computes mmh3):

favicon.mmh3 == -1181573582   # favicon.ico
favicon.mmh3 == -1678519318   # favicon.svg

5. Google Sites phishing campaign detection

Alert on sites.google.com/view/ links in inbound email that redirect to external credential capture pages. The link itself being a google.com domain does not make it safe, evaluate the final destination after redirect.

6. Tor hidden service indicator

bluekitsmi6sd5mjurh3l7n7oeizbedoe2hw2lsljtb5nbxiul6hzkqd[.]onion

Block at DNS/proxy for any clients attempting to resolve .onion addresses through proxy infrastructure.

7. SnagX origin IPs, block at perimeter

The following IPs are SnagX's real origin servers, not Cloudflare anycast. They are appropriate candidates for perimeter blocking:

• 92.204.255.237 (snagx[.]co production)
• 134.119.212.155 (staging[.]snagx[.]co)
• 64.70.19.203 (snagx[.]ws)
• 188.138.39.199 (SnagX SMTP relay)

8. Telegram exfiltration channels

If your DLP or proxy logs Telegram API traffic, the credential exfiltration chat IDs are:

• -5223277724, Bluekit operator credential channel
• -5175727718, SnagX operator credential channel

These appear in Telegram Bot API calls to api.telegram.org.

9. WebRTC C2 monitoring

The P2P rendering feature (Post #40) was specifically designed to hide C2 traffic from browser DevTools. Standard browser-level analysis will miss it. For investigations involving suspected Bluekit victim machines, capture at the network level (endpoint EDR with network telemetry, or out-of-band PCAP) rather than relying on browser inspector tooling.

10. Hardcoded Gmail post-compromise password

If investigating a suspected Gmail AiTM compromise, check whether the account password was changed to blueKIT123#! during the attack window. Bluekit's Post #30 auto-password-change feature sets exactly this string when the operator enables the option. A Google Workspace audit log showing a password change to this value is a direct Bluekit attribution indicator.

11. Google Safe Browsing visual evasion, detection tuning

Bluekit applies a 2% hue shift and 1-pixel spatial offset to every template by default (Post #14). Detection approaches that rely on pixel-exact perceptual hashing of phishing pages will miss Bluekit clones. Tune your safe browsing detection to allow for ±3% hue tolerance and ±2px spatial tolerance in the comparison algorithm.

For Abuse / Takedown Teams

• SnagX hosting: AS29066 velia.net / HFE Internet, Strasbourg. Abuse contact through velia.net. The production server (92.204.255.237) has 27 CVEs and is running EOL PHP, report to both the ASN abuse team and the hosting provider.
• Bluekit domains: bluekit[.]su (REGRU-SU), bluekit[.]ws (Key-Systems). Cloudflare has already actioned .pk and .cc. .su under REGRU is notoriously slow to respond to abuse; .ws under Key-Systems is more responsive.
• SnagX domain pending: snagx[.]cc registered through Gname.com (Singapore). File preemptive abuse reports before the domain goes live.
• YouTube: Channel UCyNljAtkwAVKmBcm8EGVBaw hosts two unlisted tutorial videos (1svs8r2WBco, rkvKL-g09JE). Report to YouTube Trust & Safety.
• Telegram channels: t[.]me/bluekit_news, t[.]me/SnagXnews. Report through Telegram's abuse channels.

---

13. Timeline

2024-07-22   updates.bluekit.io appears on URLScan - kit in active development
2026-03-23   bluekit[.]pk + bluekit[.]cc registered; day-zero wildcard TLS issued
2026-03-25   bluekit[.]su registered; YouTube "wegweg" channel created
2026-03-29   bluekit[.]su first URLScan appearance (old build: turbopack-2a3b40d8e0f279b5)
2026-04-02   ledger[.]bluekit[.]pk confirmed active (Ledger hardware wallet lure)
2026-04-04   Tor hidden service announced publicly in Telegram (Post #27, 20:53 UTC)
2026-04-09   Bulk SMS sender added (Post #33)
2026-04-11   SnagX Chinese-language Telegram channel (@snagx_news) launches - 13 days after Bluekit
2026-04-12   @whitehorseBHW SMTP vendor recommended in Telegram (Post #36)
2026-04-13   snagx[.]cc registered via Gname.com Singapore - SnagX domain acquisition
2026-04-16   Second TLS cert issued for bluekit[.]pk, validity through 2027
2026-04-17   Reseller program launched (Post #38); Airbnb, Booking templates added
2026-04-21   petrushka joins underground forums simultaneously:
               - BitcoinTalk 07:52 UTC (UID 3754492, registered 07:44 UTC, abandoned same day)
               - BreachForums 15:09 UTC (UID 672756)
               - CrackingX ~15:45 UTC
               - LeakForum same day
2026-04-21   P2P renderer deployed - "main connection no longer visible in DevTools" (Post #40, 18:03 UTC)
2026-04-22   bluekit[.]cc first URLScan; new build deployed (turbopack-0bpd7yo0yk13c)
2026-04-23   LastPass, Evernote, BNC Enterprise templates + Google Sites tutorial (Posts #41-43)
2026-04-28   NICENIC suspends bluekit[.]cc; actor publishes suspension notice verbatim to Telegram
2026-04-28   bluekit[.]ws registered 33 minutes after .cc suspension (Post #49)
2026-04-29   Varonis publishes research; petrushka announces maintenance + price increase (Post #50)
2026-04-30   Cloudflare blocks bluekit[.]pk + bluekit[.]cc (16:50Z)
2026-05-03   This investigation begins
2026-05-06   snagx[.]cc WHOIS updated - deployment imminent
2026-05-08   Active onion path probe; 4 JS chunks downloaded
             SnagX brand config + Bluekit default config extracted from 0ga04m0ate156.js
             SnagX origin IPs identified via SPF pivot: 92.204.255.237, 134.119.212.155
             Actor OPSEC slips documented: Session ID cross-forum, two Jabber addresses

---

14. IOC Table

Note on IP classification: IPs listed under Bluekit are Cloudflare anycast addresses, they are shared infrastructure serving millions of sites and are not appropriate for perimeter blocking. IPs listed under SnagX are real origin servers identified through passive SPF record analysis and are appropriate block candidates.

Bluekit Domains

SnagX Domains

SnagX Real Origin IPs (NOT Cloudflare, appropriate for perimeter blocking)

Bluekit IPs (Cloudflare Anycast, NOT origin IPs, NOT for blocking)

188.114.96.3       Cloudflare anycast
188.114.97.3       Cloudflare anycast
188.114.96.12      Cloudflare anycast
172.67.192.165     Cloudflare anycast
172.67.180.211     Cloudflare anycast
172.67.186.119     Cloudflare anycast
104.21.11.210      Cloudflare anycast
104.21.91.223      Cloudflare anycast
104.21.1.33        Cloudflare anycast
172.67.147.28      Cloudflare anycast
104.21.79.189      Cloudflare anycast
2606:4700:3035::6815:4fbd   Cloudflare anycast (IPv6)

Tor

Telegram

Actor / Forum Identifiers

Code Fingerprints

---

Full infrastructure map, complete IOC list, and abuse report targets available on request. Abuse reports filed: velia.net / HFE Internet (SnagX origin IPs), Cloudflare (all Bluekit domains), REGRU (bluekit[.]su), Key-Systems (bluekit[.]ws), Gname.com (snagx[.]cc, preemptive), YouTube Trust & Safety (channel UCyNljAtkwAVKmBcm8EGVBaw), Telegram (bluekit_news, SnagXnews).

#ThreatIntelligence #PhishingAsAService #PhaaS #Bluekit #SnagX #AiTM #Evilginx #OSINT #ThreatHunting #DFIR #IncidentResponse #InfoSec #SupplyChainSecurity #CyberSecurity #MicrosoftSecurity #PhishingAwareness