Anatomy of a TRON wallet drainer-as-a-service

01 — The Email. That Déjà Vu Feeling.

It was an ordinary morning. I opened the info@paolocostanzo.it inbox — aka the place where everything arrives that nobody should send there — and between newsletters I don't remember subscribing to and partnership offers from companies that look like they were invented by a drunk GPT, there it was.

// The email in all its glory
From: Approval Checker <gytuvegicife@karunalayamattingal.com>
To:   Info <info@paolocostanzo.it>
Reply-To: Approval Checker <gytuvegicife@karunalayamattingal.com>
Subject: Important Security Alert!

Important Security Alert!

We have detected a suspicious approval on your wallet
that may allow funds to be withdrawn without your consent.

To protect your funds, please use our service:
[ Secure My Wallet ]  ← link to drainer

Your security is our top priority.

'Approval Checker'. The sender's domain: karunalayamattingal.com — which to the naked eye could pass for a Kerala village name, but is almost certainly a compromised or purpose-registered domain. Reply-to matches the from address. The mailbox name is a pseudo-random string (gytuvegicife). Sender's OPSEC score: 2/10. OPSEC score of people who fall for it anyway: unfortunately much higher.

The link didn't point directly to the phishing site. It went through a Google redirect first — one of those lovely google.com/url?q=... that help bypass the lazier antispam filters. The final destination, obfuscated with creative capitalization to evade pattern-matching blacklists:

// The redirect chain
https://www.google.com/url?
  q=hTTps://trxoNlinEgooD.Com/    ← mixed case evasion
  &sa=D&sntz=1&usg=ANbL-n7a6y...

// Real destination:
https://trxonlinegood.com/

// me on Easter 2026. Literally.

02 — The Site and the Public Config. Someone Left the Door Open.

trxonlinegood.com presents itself as a generic 'wallet security verification' service. Clean interface — almost professional. Big button: Connect Wallet. Below it, various reassurances about your security. Classic fake AML template: 'Risk Score', 'AML Verification', terminology that sounds official to anyone who doesn't know the space.

The first thing I do with any suspicious site is look at the network traffic. The frontend fetches a JavaScript payload directly from a different domain: trxworks.sbs. This is the C2 — Command & Control. The bundle is served from /static/tron/bundle.js, 319KB, with zero authentication.

But the real surprise was /modal-config/public. An endpoint that — as the name says — is public. It feeds the frontend with the wallet connection modal config. And it contains everything:

// GET trxworks.sbs/modal-config/public
// Required headers: Valid Referer (the landing page domain)
// Auth: none. Nada. Zero.
{
  "hostname": "trxonlinegood.com",
  "wallet_configs": [
    {"wallet": "trust",         "enabled": true},
    {"wallet": "bitget",        "enabled": true},
    {"wallet": "bybit",         "enabled": true},
    {"wallet": "tronlink",      "enabled": true},
    {"wallet": "okx",           "enabled": true},
    {"wallet": "ledger",        "enabled": true},
    {"wallet": "walletconnect", "enabled": true}
  ],
  "modal_texts": {
    "server_loading":    "Waiting for server response...",
    "connecting_wallet": "Waiting for wallet connection...",
    "waiting_transaction_confirmation": "Please sign the transaction in your wallet...",
    "transaction_rejected": "Please sign the transaction in your wallet to continue.",
    // ^ if the victim refuses, the text invites them to sign AGAIN
    "insufficient_gas":     "Your wallet does not have enough TRX.",
    "insufficient_balance": "Your wallet does not have enough TRX to pay for the fee."
  },
  "modal_theme": "light"
}

Seven wallets supported simultaneously. WalletConnect for universal coverage. Ledger — yes, even hardware wallets. Customizable text for every stage of the scam, including the message that shows when the victim rejects the transaction: 'Please sign the transaction in your wallet to continue.' So polite. So persistent. So professional.

Proof: Wallet Configuration Bot Screenshot

Here's the screenshot of the Telegram bot panel for wallet configuration — the exact same list as the JSON. All enabled:

EXHIBIT A — Screenshot from the Telegram management bot. 7 wallets. All green. All active.

This JSON is the calling card: we're not looking at some sloppy script. We're looking at a product.

03 — Bundle.js Reverse Engineering. The Drainer's Heart.

The file bundle.js (319KB, minified) is the drainer payload. The first line of code reveals everything:

// Line 1 of bundle.js — before minification
!function(t,e){
  "object"==typeof exports&&"object"==typeof module
    ? module.exports = e()
    : "function"==typeof define&&define.amd
      ? define([],e)
      : "object"==typeof exports
        ? exports.NcAffiliateDrainer = e()
        : t.NcAffiliateDrainer = e()
}(this, () => ...

// The module name is literally "NcAffiliateDrainer".
// Not "WalletSecurityChecker". Not "AMLValidator".
// NcAffiliateDrainer. In the code. In production.
// OPSEC: score unchanged at 2/10.

Static Analysis of the Bundle

From analyzing strings and references in the minified code, I extracted 282 references to wallets and critical functions. The breakdown:

Hardcoded URLs in the Bundle

34 URLs extracted from the code. The most relevant:

// C2 URL — the heart
https://trxworks.sbs

// Wallet deeplinks — open the app directly
https://app.bybit.com/inapp?by_dp=${encodeURIComponent(...)}
https://gateio.onelink.me/DmA6/web3?dapp_url=...
https://www.tronlink.org/
https://www.ledger.com/
https://okx.com

// WalletConnect Explorer API
https://explorer-api.walletconnect.com

// Fonts used in modal (Manrope + Inter)
https://fonts.googleapis.com/css2?family=Manrope:wght@400;700&family=Inter...

// Telegram (for callbacks/notifications)
https://t.me

04 — The AML Builder Payload. JWE, increaseApproval, and uint256.MAX.

Now we enter the technical core of the scam. The C2 has an endpoint /aml-builder/{addr}/build that, given the victim’s wallet address, generates the malicious payload. What comes back from the server isn’t cleartext JSON — it’s a JWE (JSON Web Encryption):

// JWE header — the transaction is encrypted
{
  "alg": "dir",      // Direct Key Agreement — no key exchange
  "enc": "A128GCM"   // AES-128 in Galois/Counter Mode
}

// The JWE payload has 5 parts separated by '.'
// header.encrypted_key.iv.ciphertext.tag
// With alg:dir, encrypted_key is empty (shared symmetric key)
// This means: the frontend and C2 share an AES-128 key.
// The malicious transaction travels encrypted end-to-end.

// Why JWE? To avoid payload inspection by:
//   - WAF / IDS analyzing traffic
//   - Browser security extensions
//   - Researchers like me (they tried)

But the JWE also contains the raw transaction in cleartext (needed by the frontend for submission). And that’s where everything is visible:

// Raw transaction — decoded from "transaction" field
{
  "txID": "78f86a71a278f864...87712a663",
  "raw_data": {
    "contract": [{
      "type": "TriggerSmartContract",
      "parameter": {
        "value": {
          "owner_address":    "41a614f803b6fd78...",  // victim
          "contract_address": "41a614f803b6fd78...",  // USDT TRC20 contract
          "data": "d73dd623000000000000000000000000dc5c6bdb788264b97927fc19510e313d3f8483bcffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff"
        }
      }
    }],
    "fee_limit": 12189320   // 12.19 TRX
  }
}

// Decoding the "data" field:
//
// Function selector: d73dd623
//   → increaseApproval(address spender, uint256 addedValue)
//   NOT approve(). It’s increaseApproval().
//   Difference: approve() OVERWRITES. increaseApproval() ADDS.
//   If the victim already has an active approval, this INCREMENTS it.
//
// Parameter 1 (spender):
//   dc5c6bdb788264b97927fc19510e313d3f8483bc
//   → TW4NNonQHJBBCRSyQrcfzHfrLwSzMumDXp (Base58)
//   → THE OPERATOR'S WALLET.
//
// Parameter 2 (amount):
//   0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
//   → uint256.MAX = 2^256 - 1
//   → UNLIMITED APPROVAL. FOREVER.

The choice of increaseApproval() over the more common approve() is a significant technical detail. If the victim had already granted an approval (possibly legitimate) to that address, approve() would have overwritten it — potentially with a lower value. increaseApproval() adds to the existing value. With uint256.MAX, the result is the same — but it reveals a level of sophistication you wouldn’t expect from someone who names their module "NcAffiliateDrainer".

05 — The C2 Infrastructure. Endpoint Mapping and Locked Doors.

The C2 backend lives on trxworks.sbs. Cloudflare in front. OpenResty (Nginx-based) in back. We mapped 9 endpoints:

The Failed Tests (And What They Taught Us)

We tried. Oh, did we try.

// Attempt 1: POST /operator/me (wrong method)
HTTP/2 405 Method Not Allowed
allow: GET
// → Endpoint exists, accepts GET, but requires Bearer token.

// Attempt 2: GET /operator/me (no token)
HTTP/2 401
// → Confirmed: endpoint active, protected by Bearer auth.
// → Likely JWT, given the response pattern.

// Attempt 3: GET /docs (API documentation)
HTTP/2 401 Authorization Required
server: openresty
// → HTTP Basic auth. Docs exist — OpenAPI/Swagger.
// → The kit is mature enough to have documented APIs.
// → We don't have the credentials. Yet.

// Attempt 4: GET /operator/wallets
HTTP/2 403
// → 403 Forbidden, not 401. Subtle but important difference:
// → the server recognized the request but refused it.
// → Could mean there's an additional authorization layer
// → beyond the token (roles? IP whitelist?).

The picture: a well-structured REST API, with separation between public endpoints (for phishing frontends), semi-public endpoints (for modal config with referer check), and private endpoints (for operators, with Bearer + maybe RBAC). The 405 on POST /operator/me tells us there’s also an HTTP method validation system — this isn’t an API hacked together over a weekend.

06 — Telegram. We Walked Into Their Living Room.

The organization — which we’ll call CriptoCarina S.r.l. in Italian and WalletVacuumers International™ in English — manages its affiliates through a network of public Telegram channels. Public. As if they were running a legitimate SaaS. Dumping the channels was trivial — Telethon, one session, and a few lines of Python. Then ExifTool on photos for metadata, Obsidian to organize the graph of entity relationships, and BBOT for automated OSINT pipeline on the entire infrastructure.

// Telegram Network of CriptoCarina S.r.l. / WalletVacuumers International™

📢 Info (EN)   → DevLog, announcements, updates (English)
📢 Info (RU)   → Parallel DevLog in Russian
💰 Payments   → Payment proofs to affiliates (with screenshots)
🎨 Designs    → Ready-to-use landing page templates

// Channel IDs and bot names: [REDACTED for this publication]
// We will hand them over to authorities with the rest of the material.

🤖 Bot gestione:    @[REDACTED]_bot       → Affiliate panel via Telegram
🆘 Bot supporto:    @[REDACTED]_support   → Helpdesk (yes, they have one)
🔔 Bot notifiche:   @[REDACTED]_alerts    → Alerts when a wallet is drained
💬 Gruppo privato:   link su invito        → Internal affiliate chat

The DevLog: Startup-Paced Updates

The Info ENG and Info RUS channels contain a detailed DevLog of released features. The complete timeline:

// me reading a criminal org's devlogs. On Easter.

07 — The Template Catalog. 12+ Landing Pages Ready to Deploy.

The Designs channel is the product catalog of CriptoCarina S.r.l. Each template has an ID for bot installation, a bilingual description (Russian + English), and professional design. Here’s the complete list:

Every template is installable via Telegram bot with a single command. The affiliate picks the theme, customizes the domain, and the landing page is live in minutes. Some templates — like Invoice — even support generating personalized URLs with affiliate parameters: dominio.com/?bestaffiliate=NC.

And the evidence? Here it is. All 13 template screenshots, also archived by PhishDestroy in their ScamIntelLogs:

Category: Fake AML Verification

ByBitAML — "Official Bybit AML Verification"

TrustAML — "Checking wallets for dirty money"

AML_BOT — "AML Check" with fake Trust Score

Category: Fake Airdrop / Distribution

TronDROP — "THE BIGGEST TRON AIRDROP"

TetherDROP — "THE BIGGEST USDT AIRDROP"

USDT_DROP — "1,000,000 USDT Distribution" at 42%

Category: Fake Exchange / Swap

AlgoSwap — "AlgoFlow: Powered by algorithm"

trx-swap — Fake USDT↔TRX exchange

Category: Fake Invoice / Payment Gateway

RedotInvoice — "1000 USDT" with countdown

trust-invoice — 100 USDT, "Receive" button

cryptomus-invoice — 815 USDT via Cryptomus

Category: Fake Crypto Card / Wallet Service

trust-crypto-card — "Create Your Cryptocurrency Card"

Variant: "Generate USDT Receipts from Trust Wallet"

08 — The Social Engineering Playbooks. The Thief's Manual.

This is the content that made me decide to write the article despite the delay. In Telegram channels and linked Telegraph pages, the author @[REDACTED] (alias "NC") published three complete social engineering guides. They’re operational manuals with ready-to-use conversational scripts teaching affiliates how to scam people. I’m sharing them — summarized and translated — because understanding the techniques is the only way to defend against them.

Playbook 1: "AML Direction" — The AML Vector

Target: anyone managing cryptocurrency. Vector: impersonating an intermediary requiring mandatory "AML verification" before completing a transaction.

// Conversational script — translated from Russian
// Organization glossary:
//   "Worker" (Worker)  = the scammer affiliate
//   "Mammoth" (Mammoth) = the victim
//   "Drainer" (Drainer) = the technical kit
//   "Link" (Link)      = the fake landing page

SCENARIO 1: P2P Guarantor (il più veloce)
"Sono disposto a fare da garante, ma solo se entrambe le parti
 confermano la pulizia dei fondi. Ecco il servizio, mandate i
 report e iniziamo."

SCENARIO 2: Vendita auto/tech (assegno alto)
"Il prezzo è basso perché accetto solo USDT. Siccome sono
 un'entità giuridica, ho bisogno di conferma che la tua
 cripto non provenga da mixer. Fai un check, mandami lo
 screen con 'Low Risk'."

SCENARIO 3: "Aiuto con il freeze" (prede in panico)
"Ho avuto lo stesso problema. Il mio wallet aveva una
 'coda' dal darknet. C'è un servizio speciale che fa
 un'analisi profonda e 'scollega' le transazioni sporche."

// Golden rule: "If the customer doubts, tell them:
// 'No problem, security first. If you don't want
// to verify cleanliness, I'll find another buyer.'
// This triggers fear of losing the deal.

Playbook 2: "INVOICE Direction" — The Invoice Method

This is the most insidious. The affiliate doesn’t ask for money from the victim — they offer money. The trick: a fake invoice that looks like an incoming payment. The victim thinks they’re receiving, but connecting their wallet signs the approval delegation.

// Target: Kick.com streamers, Telegram freelancers

SCENARIO 1: Kick.com — Finto manager casino
"Ehi! Bella presentazione. Il nostro casino cerca nuovi streamer.
 Scrivimi su TG, parliamo della collaborazione.
 [in privato] Ti offriamo $5.000/settimana + saldo per le live.
 La company paga il primo anticipo. Ecco il link al nostro
 gateway di pagamento Heleket. Devi solo confermare la ricezione."

SCENARIO 2: Telegram — Finto acquirente
[Variante A — "Manager":]
 "Il pagamento arriva dalla company via il nostro gateway.
 Ecco il check, ritira i soldi."
[Variante B — "Compratore normale":]
 [manda screenshot finto errore TrustWallet]
 "Strano, il wallet si è bloccato. Ti creo un invoice
 tramite l'exchanger, così arriva sicuro."

// Handling objections:
// "Why not a direct transfer?"
// → "Corporate standard. I route budgets through accounting.
//    We have a Cryptomus partnership, all payments
//    go through their checks for reporting.

Playbook 3: "TRC20 Permit/Approve for Beginners" — The Pyramid Method

Published March 26, 2026 — the most recent. Target: victims of financial pyramids. The affiliate contacts people who have already lost money in crypto pyramids and offers to "recover funds" without upfront payment.

// The complete flow — 5 steps

STEP 1: Trovare le vittime
// Search in themed chats, comments, forums of people
// who have lost money in financial pyramids.
"Posso recuperare i tuoi fondi. Senza anticipo."

STEP 2: Far creare un wallet Trust nuovo e "pulito"
"Il wallet deve essere pulito, senza altri asset,
 così non rischi nulla."
// In reality: needs to be empty so the victim doesn't panic
// seeing 0$ balance. It gets drained AFTER they deposit.

STEP 3: Far firmare l'approve
// In the dApp, the transaction text shows:
"Caso n. 000-228, prelievo dal conto personale di 101.337 USDT
 (TRC20), ai sensi del punto 5.2 delle regole di prelievo e
 rimborso. Sul vostro wallet deve essere presente almeno il 10%
 della somma da ricevere. Una volta soddisfatta la condizione,
 l'accredito avverrà automaticamente."

STEP 4: Convincere a depositare il "10%"
"I fondi sono già stati disposti (guarda lo status).
 Il sistema attende il deposito del tuo 10% di riserva
 per completare l'accredito dei 100k USDT."
// The victim deposits. The drainer empties everything immediately.
// The victim is already someone who lost money.
// They're robbing them a second time.

STEP 5: Risultato psicologico
// The victim believes: "They're returning 100k via TrustWallet.
// I don't send money to anyone — just need 10% on MY
// personal wallet. Then I get 110k total.
// → Deposits. → Drainer empties. → Done.

09 — The Operator's Wallet and the Blockchain.

From the AML builder payload we extracted the operator wallet address — the spender in the increaseApproval():

// Operator wallet — decoded from "data" parameter
Hex:     dc5c6bdb788264b97927fc19510e313d3f8483bc
Base58:  TW4NNonQHJBBCRSyQrcfzHfrLwSzMumDXp
Network: TRON (TRC20)

// Data from Tronscan at dump time (07 Apr 2026):
Transazioni totali: 1.297
Stato: ATTIVO

// Transaction patterns:
// - Small amounts IN from multiple wallets (victims)
// - Larger amounts OUT to collection wallets
// - Last 50 tx: mix of TRX and TRC20 (USDT)
// - Active account delegations → confirms drainer mechanism

1,297 transactions. Wallet active at dump time. The last transaction includes an account delegation to a collection wallet (TKQAZ6i6GSmfNYdpmv3s4MqqqSc9KNWv5b), type contractType:0 — confirming the pattern of stolen fund consolidation.

10 — How Much They Stole.

The payments published in the Payments channel are just the tip of the iceberg. They represent only the affiliate share (80%) of documented and published drains:

On-chain proof? Here are all 6 documented payments from the Payments channel — with Tronscan screenshots also archived by PhishDestroy:

$1,501 USDT — 08 Jan 2026
CONFIRMED

$3,258 USDT — 09 Jan 2026
CONFIRMED

$2,105 USDT — 10 Jan 2026
CONFIRMED

$3,705 USDT — 13 Jan 2026
CONFIRMED · highest recorded

$2,550 USDT — 23 Jan 2026
CONFIRMED

$843 USDT — 28 Jan 2026
CONFIRMED · last visible

// victims checking their balance after 'verifying' their wallet

11 — PhishDestroy Confirms: One of the Most Active Networks.

At some point during the investigation I found a report by PhishDestroy.io — published February 19, 2026, weeks before us. The title: 'Crypto Drainer Toolkit: Inside the Angel Drainer Resellers Targeting Your Wallet'.

PhishDestroy's article classifies CriptoCarina S.r.l. / WalletVacuumers International™ as one of the most active drainer networks in circulation, part of a broader Angel Drainer reseller ecosystem. The report includes a 9-step attack chain, structured IOCs, and a technical comparison with competing kits. Our work confirms and expands on their conclusions with additional data: the social engineering playbooks, the bundle.js reverse engineering, the JWE analysis, and the complete DevLog timeline.

But the most important part: PhishDestroy also published a complete evidence archive on GitHub.

// PhishDestroy ScamIntelLogs — public evidence archive
// github.com/phishdestroy/ScamIntelLogs/tree/main/nicecrypto

Struttura dell'archivio:
├── NC Designs/       // 13 screenshot template landing pages
│   └── photos/       // 26 files (13 full + 13 thumb)
├── NC Info ENG/      // English channel export
│   ├── result.json   // Structured messages
│   ├── messages.html // HTML render
│   └── photos/       // 5 images
├── NC Info RUS/      // Russian channel export
│   ├── result.json
│   ├── messages.html
│   └── photos/       // 8 images
├── NC Payments/      // Affiliate payment proofs
│   ├── result.json
│   └── photos/       // 6 Tronscan screenshots
├── guide/            // Complete GitBook export
│   ├── index.html
│   ├── 1/            // Bot settings
│   └── 2/            // Operational manuals
├── iocs.json         // Structured IOCs (JSON)
├── index.html        // Interactive evidence browser
└── README.md

// Total: 32 photos, 4 JSON exports, complete documentation
// Everything public, everything verifiable, everything archived.

PhishDestroy's iocs.json file includes structured data confirming our findings:

// From: github.com/phishdestroy/ScamIntelLogs/nicecrypto/iocs.json
{
  "name": "[REDACTED] Drainer",
  "type": "Crypto Wallet Drainer",
  "network": "TRON",
  "status": "Active",
  "first_seen": "2025-12-22",
  "last_activity": "2026-01-28",
  "affiliate_share": "up to 80%",
  "features": [
    "TRON network drainer",
    "Telegram bot control panel",
    "WalletConnect integration",
    "Modal window customization",
    "Auto-withdraw on approval",
    "Balance monitoring",
    "Custom landing pages"
  ],
  "planned_networks": ["SOL", "EVM", "TON"]
}
// Every single field matches what we found
// in our independent analysis. Same network,
// same dates, same features, same roadmap.

12 — What We'll Do. Sequel Guaranteed.

This is where I stopped. Not because the investigation was over — far from it. But because it was Easter, I was already weeks behind on publication, and the Easter cake was becoming an archaeological artifact. A half-written article is worth more than a complete investigation that never gets published. What's coming in Part II:

• Formal takedown of active landing pages — notification to registrars, CDN (Cloudflare), and hosting providers.
• Report to authorities — structured IOCs via Faraday, Telegram dumps, blockchain analysis, mapped endpoints, social engineering playbooks as evidence.
• Token cracking — Hashcat on JWT (if HS256), John The Ripper on dump hashes, Hydra and Medusa for operator panel brute force, CeWL for custom wordlist from wiki, Haiti for hash identification, RsaCtfTool on JWE component.
• IDOR exploitation — Burp Intruder on /operator/wallets/{id}, affiliate wallet enumeration, wallet swapping. The finale.
• Post-exploitation — CrackMapExec for lateral movement, Metasploit for CVEs on nginx/1.29.4 or FastAPI, Volatility for memory dump and key extraction.
• Complete blockchain tracking — from the 1,297 operator wallet transactions to the full consolidation chain.
• Forum intelligence — threads on WWH, LOLZ, BHF are still there. Not for much longer.

Conclusions. Or: How I Lost Easter and Found a Criminal Org Instead.

The email that started it all had the subject: 'Important Security Alert!'. The sender called themselves 'Approval Checker' from a domain that looks like a Kerala carpet shop. It was one of the most basic phishing emails I've ever received. And instead of eating Easter lunch like a normal human being, I burned my entire holiday on it. Behind it was an organization with:

• A 319KB JavaScript payload exported as NcAffiliateDrainer
• JWE encryption (AES-128-GCM) to hide malicious transactions
• The increaseApproval() function with uint256.MAX — unlimited and permanent approval
• 12+ ready-to-use landing page templates with Telegram deployment bot
• 3 detailed social engineering playbooks, including one targeting pyramid scheme victims
• Weekly DevLogs and a product roadmap (SOL, EVM, TON coming soon)
• Presence on 5 darkweb forums with escrow deposits
• Documented payments to 6+ affiliates for ~$13,960 estimated total
• An operator wallet with 1,297 still-active transactions

All of it launched December 22, 2025 and still operational today, April 7, 2026. My Easter vacation? Sacrificed. The Easter cake? Untouched. The chocolate eggs? Missing in action. But at least I have the Telegram dumps.

The lesson, as always in this field: basic phishing doesn’t mean stupid. It’s just the surface. Underneath there’s often surprisingly professional infrastructure, an amount of stolen money that makes your stomach turn, and real people losing their savings — sometimes for the second time.

'The most dangerous phishing isn't the one that looks sophisticated. It's the one you open during Easter vacation thinking it'll take five minutes.'

// Part II coming. With the takedown. With real names. With everything.