A QR code is a leap of faith. You point a camera at a black-and-white square, trust that it resolves to where you expect, and act on whatever appears. A campaign analyzed by CYFIRMA in May 2026 turns that faith into a wallet takeover. Victims, recruited through Telegram, scan a QR code that resolves through Trust Wallet's own deep-link domain, land on a convincing "Send USDT" page, and tap a button that does not send anything. It grants an attacker contract an unlimited allowance over their USDT on BNB Smart Chain. From that moment the attacker can drain the balance at will, with no further interaction from the victim.
This sits alongside the search-ad drainer wave that defined May 2026, but it is meaner in two ways. First, it abuses a legitimate, trusted domain (link.trustwallet.com) as the redirect, so the link inspection most users perform sees a name they recognize. Second, the analyzed infrastructure carried the hallmarks of a Drainer-as-a-Service operation: a Telegram bot logging victim activity, affiliate-style userId tracking, and a reusable two-file payload. This is not a lone scammer. It is a productized kit being run by multiple operators.
The underlying weapon is the same ERC-20 approval abuse that powers most modern drainers. What this campaign demonstrates is how that primitive gets packaged, distributed, and disguised in 2026: through deep-link abuse, free static hosting, messaging-app distribution, and a fake transfer UI that converts a "send" into an "approve."
TL;DR
- A Drainer-as-a-Service campaign analyzed by CYFIRMA in May 2026 abuses Trust Wallet deep links and QR codes, distributed via Telegram, to drain USDT on BNB Smart Chain.
- The QR resolves through the trusted
link.trustwallet.com/open_urldeep-link handler to a phishing page hosted on Netlify, masquerading as a "Send USDT" interface. - The page triggers an ERC-20 approval granting
MaxUint256(unlimited) allowance to attacker contract0x76C77b171264e1a81baA63125D9627E70B43a169, not a transfer. - Target token: USDT on BNB Smart Chain (
0x55d398326f99059fF775485246999027B3197955). - The payload is a two-file kit (
config.jsfor attacker/Telegram parameters,main.jsfor the malicious transaction). A connected Telegram bot logged 52 transaction notifications;userIdtracking points to an affiliate model. - Phishing domains observed:
swift-wallat-usdt-send.netlify.appandsend-usdt-09-admin.netlify.app. - Monday-morning actions: never scan QR codes from untrusted Telegram sources, inspect approval transactions and reject unlimited allowances, audit and revoke token permissions, and segregate active-use wallets from storage.
What happened
CYFIRMA's research documents an active campaign that weaponizes Trust Wallet's deep-link feature. Trust Wallet, like many mobile wallets, registers a deep-link handler so links can open specific in-app actions. The legitimate handler lives at link.trustwallet.com. The attackers craft a deep link that uses this trusted domain as a launchpad and redirects the user to an attacker-controlled page:
https://link.trustwallet.com/open_url?coin_id=60&url=https://swift-wallat-usdt-send.netlify.app
The trick is the url= parameter. The visible, trusted domain is link.trustwallet.com. The destination it forwards to is a Netlify-hosted phishing site. A user who glances at the link sees the wallet's own domain and proceeds. The QR-code format makes inspection even less likely, because most people never expand a QR into its underlying URL before acting on it. These QR codes were distributed through Telegram channels, the same place victims were recruited.
The destination page presents a fake "Send USDT" interface. The victim believes they are about to transfer USDT. Instead, the page constructs and submits an ERC-20 approve transaction.
How the attack worked
The campaign's payload is modular and reusable, which is the tell of a kit rather than a one-off.
The two-file payload
CYFIRMA describes a two-file architecture:
config.jsholds attacker parameters and the Telegram bot credentials used for victim logging.main.jsexecutes the wallet interaction and encodes the malicious transaction.
Separating configuration from logic is exactly how you build something to be redeployed by many affiliates against many targets, each with their own bot and tracking ID. The presence of userId parameters in the infrastructure reinforces the Drainer-as-a-Service read: operators are tracked and presumably paid by attribution.
The malicious approval
The core action is an ERC-20 approval that grants MaxUint256, the maximum unsigned 256-bit integer, as the allowance to the attacker's contract. The following is an illustrative sketch of the call the fake "Send USDT" button actually triggers. It is not functional exploit code.
// ILLUSTRATIVE — what the fake "Send USDT" button submits
// Standard USDT (BEP-20) approve with an unlimited allowance
const MAX = ethers.constants.MaxUint256; // 2^256 - 1
await usdt.approve(
"0x76C77b171264e1a81baA63125D9627E70B43a169", // attacker contract
MAX // unlimited allowance
);
// No transfer occurs. The victim's "send" is an approval grant.
Once the allowance is granted, the attacker contract holds standing authority to call transferFrom and move the victim's USDT whenever it likes. The victim sees a confirmation that, in a typical wallet prompt, looks like a normal approval and walks away believing they sent funds.
The Telegram back end
The integrated Telegram bot in the analyzed infrastructure contained 52 transaction-related notifications, evidence of active, successful exploitation rather than a dormant kit. Telegram serves double duty here: distribution of the QR codes to victims and real-time logging of takeovers back to operators.
What detection looks like
Because the on-chain action is a legitimate approve, detection focuses on the link layer, the transaction semantics, and post-grant sweeps.
Link and device signals:
- A
link.trustwallet.com/open_urldeep link whoseurl=parameter points to a*.netlify.appor other free-hosting domain rather than an official property. - QR codes received over Telegram or other messaging apps that resolve to wallet deep links. Decode the QR and inspect the full URL before acting.
Transaction signals before signing:
- The method is
approvewhile the UI claims you are sending or transferring. - The allowance is
MaxUint256(unlimited) rather than a specific amount. - The spender is an address with no relationship to a known router or vault.
On-chain hunting for operators and analysts (illustrative):
# ILLUSTRATIVE — adapt to your analytics stack, BNB Smart Chain
# Unlimited USDT approvals to the known attacker spender
chain == "bsc"
AND token == 0x55d398326f99059fF775485246999027B3197955 # USDT
AND event == "Approval"
AND spender == 0x76C77b171264e1a81baA63125D9627E70B43a169
AND value == MaxUint256
# Subsequent transferFrom sweeps draining approved balances
event == "Transfer"
AND from IN (victims)
AND initiated_by == 0x76C77b171264e1a81baA63125D9627E70B43a169
Observed IOCs (verify before acting): phishing domains swift-wallat-usdt-send.netlify.app and send-usdt-09-admin.netlify.app; attacker contract 0x76C77b171264e1a81baA63125D9627E70B43a169; target token USDT 0x55d398326f99059fF775485246999027B3197955 on BNB Smart Chain.
What to do Monday morning
-
Never scan QR codes from untrusted sources. Treat any QR delivered over Telegram, DMs, or unsolicited messages as hostile, especially anything promising a transfer, airdrop, or "verification." Decode the QR and read the full destination URL before opening it.
-
Distrust deep links that redirect. A
link.trustwallet.com/open_url?...url=parameter pointing to free hosting (Netlify, Vercel, GitHub Pages) is a red flag regardless of the trusted domain in front of it. The trusted prefix is the bait. -
Read the transaction, not the button. If a "Send" or "Transfer" page produces an
approveprompt, stop. Confirm the method, the spender, and the amount in the wallet's own confirmation screen, which cannot be spoofed by the website. -
Reject unlimited allowances. Set a finite cap equal to what you intend to transact. Modern Trust Wallet and other wallets let you edit the spending cap at signing time.
-
Audit and revoke approvals. Use a BNB Chain token-approval checker (for example via BscScan's token-approval tool) to review every active allowance and revoke anything granted to an unknown spender, the attacker contract above included if you suspect exposure.
-
Segment wallets. Keep funds you are not actively transacting in a wallet that has never connected to a dApp or signed an approval. An unlimited allowance can only drain the balance held by the approving wallet.
Why this keeps happening
This campaign is a clinic in how three legitimate primitives compose into an attack.
Deep linking exists so wallets can offer smooth in-app flows from the web. Free static hosting exists so anyone can ship a site in minutes. The ERC-20 approval exists so dApps can move tokens on a user's behalf. Each is reasonable in isolation. Combined, they let an attacker borrow a wallet's trusted domain, stand up disposable infrastructure for free, and convert a victim's intent to "send" into a grant of open-ended spending authority, all in one tap.
The deeper issue is that the approval primitive externalizes risk onto users who cannot reasonably assess it. Reading a raw approve call, recognizing MaxUint256, and judging whether a spender address is trustworthy are tasks for a security engineer, not a retail holder scanning a QR code from a Telegram channel. Until wallets make unlimited approvals to unrecognized spenders loud and hard to do by accident, the Drainer-as-a-Service economy will keep packaging this primitive and renting it out. The 52 logged notifications in a single analyzed instance show the conversion rate is good enough to sustain the business.
The structural fix
The center of gravity for this threat is wallet UX and user behavior, and no supply-chain platform stops a person from scanning a malicious QR code. The honest intersection with Safeguard is the dApp and wallet-front-end build side. Drainer kits increasingly reach users through compromised or impersonated front-ends and through malicious dependencies pulled into wallet and dApp codebases, the same territory as supply-chain campaigns like TrapDoor. Safeguard's reachability analysis and SBOM coverage help wallet and DeFi teams verify exactly what ships in their official clients and front-ends and detect injected or tampered code that could turn a legitimate flow into an approval trap. The realistic claim is reduced blast radius and shorter detection time for front-end compromise, not prevention of a phishing site a team does not control.
What we know we don't know
- Total losses. CYFIRMA's analysis documents 52 logged transaction notifications in one observed instance, indicating active exploitation, but a verified aggregate dollar figure for the campaign is not public.
- Scale and operator count. The
userIdtracking implies multiple affiliates, but the number of operators, victims, and deployed phishing domains beyond those named is not fully enumerated. - Attribution. The campaign is identified by infrastructure and on-chain artifacts, not a named threat group.
- Kit lineage. Whether the two-file payload derives from a known, commercially sold drainer kit or is bespoke is not established in the analyzed material.
References
- CYFIRMA, "Silent Crypto Wallet Takeover: Unlimited USDT Approval Exploitation via Trust Wallet QR Code Phishing" — https://www.cyfirma.com/research/silent-crypto-wallet-takeover-unlimited-usdt-approval-exploitation-via-trust-wallet-qr-code-phishing/
- FinanceFeeds, "Trust Wallet Drainer Scam Hits BNB Users — How to Spot It Now" — https://financefeeds.com/trust-wallet-drainer-scam-hits-bnb-users-how-to-spot-it-now/
- Group-IB, "Crypto Wallet Drainers" knowledge hub — https://www.group-ib.com/resources/knowledge-hub/crypto-wallet-drainers/
- BleepingComputer, "Inside a Crypto Drainer: How to Spot it Before it Empties Your Wallet" — https://www.bleepingcomputer.com/news/security/inside-a-crypto-drainer-how-to-spot-it-before-it-empties-your-wallet/
Internal Safeguard resources: