This report details an active QR code–based crypto drainer campaign targeting Trust Wallet users via Telegram distribution channels. The attack abuses Trust Wallet’s deep link mechanism to redirect victims to attacker-controlled phishing domains hosted on Netlify, masquerading as legitimate USDT transfer interfaces.
Instead of performing a token transfer, the phishing flow covertly triggers an ERC-20 approve() transaction, granting unlimited token allowance to an attacker-controlled contract on BNB Smart Chain. This enables persistent access, allowing attackers to drain funds from victim wallets without further interaction.
The campaign utilizes a modular drainer architecture, with config.js handling attacker-controlled parameters and main.js executing wallet interactions and transaction logic. Integrated Telegram bot infrastructure acts as a real-time exfiltration channel, with analysis confirming at least 52 transaction-related notifications, indicating active exploitation. The inclusion of tracking parameters suggests a broader Drainer-as-a-Service ecosystem.
Multiple phishing domains following similar naming patterns highlight scalable and repeatable deployment. The attack relies entirely on social engineering and user-authorized transactions, making it highly effective despite the absence of any underlying wallet vulnerability.
Overall, the campaign represents a high-risk, ongoing threat enabling large-scale theft of USDT assets through deceptive workflows, low-cost blockchain operations, and automated attacker monitoring.
Key Highlights
The campaign leverages QR code poisoning distributed through Telegram channels. Attackers embed malicious QR codes within manipulated screenshots of legitimate Trust Wallet interfaces. When scanned, the QR code initiates a deep link traversal:
https://link.trustwallet.com/open_url?coin_id=60&url=https[:]//swift-wallat-usdt-send[.]netlify[.]app
This URI structure exploits Trust Wallet’s internal deep link handler (link.trustwallet.com/open_url) to force the mobile application to open an attacker-controlled domain. The coin_id=60 parameter corresponds to Ethereum in Trust Wallet’s internal enumeration, though the actual phishing page immediately pivots to BNB Smart Chain upon execution. This technique bypasses standard phishing detection by routing through a trusted intermediary, lending false legitimacy to the subsequent request.
Once the QR code is scanned, the user is redirected to a “Send USDT” interface that closely imitates the design and workflow of Trust Wallet. The page requests a recipient address and transfer amount, reinforcing the appearance of a legitimate token transfer operation.
This interface is non-functional from a transfer perspective. Instead of executing a token transfer, the underlying logic initiates a wallet connection followed by an approve() transaction. This subtle shift in behavior is not apparent to the user, as the UI flow is deliberately structured to resemble a standard transfer process, effectively masking the approval mechanism.
A key indicator of compromise is visible in the browser address bar, where the domain swift-wallat-usdt-send.netlify.app is displayed. Despite this discrepancy, the near-identical visual presentation and expected interaction flow often prevent users from recognizing the phishing nature of the page.
Following interaction with the phishing interface, the Trust Wallet prompts the user to approve a request that appears consistent with standard dApp behavior. Technically, this action corresponds to an approve() call, not a token transfer, but the wallet UI presents it as a routine authorization step, significantly lowering user suspicion.
The transaction carries no token value and incurs only minimal gas fees, as it grants permission rather than moving assets. Threat actors intentionally operate on BNB Smart Chain due to its low transaction costs, enabling large-scale exploitation without introducing noticeable financial friction. The negligible fee profile further reinforces the perception of legitimacy.
By aligning the interaction with expected Web3 workflows and removing cost-based friction points, the attacker ensures that the approval process blends seamlessly into normal wallet activity while covertly granting unrestricted token access.
Once the transaction is confirmed, the approval is recorded on-chain and becomes visible within the Approval section of the Trust Wallet.
At this stage, the wallet shows that USDT has been granted “Unlimited” allowance to the contract address 0x76C77b171264e1a81baA63125D9627E70B43a169. Although the interface flags this with a “Medium Risk” warning and highlights the risks of unlimited approvals, these indicators are often ignored after the user has already trusted the preceding workflow.
This approval effectively hands persistent spending authority to the attacker-controlled contract, allowing it to invoke transferFrom() against the victim’s wallet without requiring any further interaction or confirmation.
Since the permission remains active until manually revoked, both current and future USDT balances are exposed. This enables the attacker to drain funds immediately or at a later time through automated or manual execution.
When the drainer is executed against a browser-based instance of Trust Wallet, the underlying behavior remains unchanged, but the interaction is exposed through more explicit permission prompts.
The phishing domain swift-wallat-usdt-send.netlify.app first triggers a network switch request, forcing the user onto BNB Smart Chain. This is required because both the USDT contract and the attacker-controlled spender contract are deployed on this chain. The wallet displays a standard confirmation dialog, which appears routine since many legitimate dApps request network changes, allowing this step to blend into expected usage patterns.
After the network switch, the wallet prompts the user to grant connection permissions. The request for “write access” corresponds to the ability to initiate blockchain transactions via the wallet. Although the message indicates that the dApp is requesting access again, this reflects the wallet’s security model rather than any visible malicious behavior, making it unlikely to raise suspicion.
Once access is granted, the dApp can invoke eth_sendTransaction, which is later used to submit the encoded approve() call. The separation between connection approval and transaction execution allows the attacker to first establish trust, then perform the actual exploitation step.
While browser-based wallets expose more granular permission states compared to in-app browsers, these prompts still align with normal Web3 interaction patterns. As a result, the attack proceeds without disruption, ultimately leading the user to authorize an unlimited token allowance while perceiving the process as a routine network and connectivity operation.
Inspection of network traffic from swift-wallat-usdt-send.netlify.app shows the payload is delivered in two components:
GET /config.js
GET /main.js
config.js contains attacker-controlled parameters such as contract addresses and Telegram infrastructure, while main.js implements the execution logic, including wallet interaction, approval encoding, and transaction submission.
CONFIGURATION & CONTROL PLANE:
The configuration block represents the control plane of the drainer, exposing both the on-chain execution target and the off-chain coordination infrastructure. Unlike generic phishing setups, this implementation tightly couples smart contract interaction with real-time exfiltration channels, indicating a semi-automated draining pipeline.
At the contract interaction level, the variable CONTRACT_ADDRESS is the primary sink for token approvals. Although labeled as an escrow contract, its role is functionally equivalent to a spender address in the ERC-20 approval model. Any approval granted to this address enables it to invoke transferFrom(address owner, address recipient, uint256 amount) on the USDT contract (0x55d398326f99059fF775485246999027B3197955). This effectively delegates spending authority over the victim’s balance to the attacker-controlled contract. The presence of a separate COMPANY_WALLET_ADDRESS introduces a semantic mismatch between UI representation and actual transaction parameters, but it is never referenced in the approval execution path, confirming its role as a non-functional decoy.
The Telegram notification function acts as an exfiltration endpoint embedded directly into the client workflow. Once a transaction hash is obtained, the function constructs a structured message containing the victim’s wallet address, transaction hash, timestamp, and an optional userId extracted from URL parameters. The presence of this userId parameter indicates affiliate tracking, suggesting that the drainer is part of a distributed campaign where multiple operators or traffic sources are credited per victim. The inline keyboard linking to BscScan further confirms that the attacker expects to monitor transactions in real time, not batch-process them later. This creates a near-zero latency feedback loop between victim authorization and attacker awareness.
Parallel to this, the notification bar system (showNotification) functions as a UI abstraction layer that overrides native wallet feedback. Instead of relying on wallet-confirmed transaction states, the script injects its own success or error messages with controlled styling and timing. The critical detail lies in the invocation showNotification(“”, “success”), where an empty message is still rendered as a green success state. This effectively decouples perceived success from actual transaction semantics, allowing the attacker to present a successful outcome regardless of what the wallet displayed or what the transaction actually represents.
The “Max” button handler introduces a reconnaissance step prior to exploitation. By instantiating an ethers.js contract instance of the USDT token on BNB Smart Chain (0x55d398326f99059fF775485246999027B3197955), the script performs two read-only calls: decimals() and balanceOf(walletAddress). The returned balance is then formatted and injected into the UI input field. Technically, this step has no impact on the approval transaction itself; it is purely informational. However, it creates a false binding between the displayed amount and the upcoming transaction, even though the actual approval later ignores this value entirely. This separation between UI state and transaction payload is a key deception primitive.
Network enforcement is handled through direct RPC calls to wallet_switchEthereumChain and wallet_addEthereumChain, forcing the user onto chain ID 0x38 (BNB Smart Chain). This constraint is essential because the hardcoded USDT contract and attacker-controlled contract both exist on this network. The logic ensures that if the wallet is not already configured for BSC, it attempts to add it dynamically. Failure paths are explicitly handled with user-facing error notifications, preventing execution on unsupported networks and maintaining consistency in the attack environment.
The approval setup phase defines the ABI interface for ERC-20 interactions, specifically the approve and decimals functions. The use of ethers.utils.Interface allows the script to manually encode calldata without relying on higher-level contract abstractions. This approach is important because the transaction is ultimately sent using eth_sendTransaction, which only requires raw fields like the recipient address (to) and the encoded data (data), not higher-level contract methods. The escrowAddress variable, sourced from the configuration, is injected as the spender parameter, making it the recipient of delegated token control.
Transaction encoding reveals the core exploit. Although the script attempts to fetch token decimals via a low-level eth_call, the result is operationally irrelevant because the approval amount is hardcoded to ethers.constants.MaxUint256. This value, equal to 2²⁵⁶−1, represents the maximum possible allowance in the ERC-20 standard. By encoding approve(escrowAddress, MaxUint256), the script grants unrestricted spending rights to the attacker-controlled contract. The preliminary decimals fetch serves only to make the code appear legitimate or reusable; it does not influence the final payload.
Execution is performed through eth_sendTransaction, where the victim’s wallet signs a transaction targeting the USDT contract with the crafted calldata. The absence of any ETH/BNB value (value: “0x0”) reinforces that this is a pure approval operation, not a transfer. Immediately after submission, the script triggers the deceptive success notification and proceeds to invoke the Telegram exfiltration function. This sequencing ensures that the attacker is notified as soon as the transaction is broadcast, not necessarily confirmed, enabling proactive draining strategies.
Error handling is selectively implemented to maintain user trust. The script parses error messages returned by the wallet provider and maps them to generic notifications, such as “Transaction cancelled” or “Insufficient USDT balance.” Notably, there is no branch that exposes the true nature of the transaction (i.e., granting unlimited allowance). All failure states are normalized into benign, expected user errors, preventing suspicion.
Analysis of the Telegram bot token shows 52 transaction-related notifications, indicating active use as a real-time exfiltration channel for victim activity. The automated message flow confirms integration with a phishing/drainer script, enabling attackers to monitor wallet interactions without manual involvement.
Additionally, another phishing URL (https[:]//send-usdt-09-admin[.]Netlify[.]app) was identified. Its naming pattern and hosting on Netlify suggest it is part of the same scalable, cloned phishing infrastructure targeting USDT wallet users.
The examined Telegram advertisement explicitly promotes a “crypto draining project” capable of compromising wallets through QR-based interaction, highlighting the increasing commoditization of Web3-targeted fraud. The messaging claims that an attacker can gain full access to a victim’s wallet after inducing them to scan a QR code and perform a seemingly benign transaction via Trust Wallet. While framed as a direct wallet compromise, the underlying technique does not involve exploitation of the wallet itself. Instead, it relies on social engineering to coerce the victim into authorizing a malicious transaction, typically an unlimited token approval against a legitimate asset contract, such as Tether (USDT) on the BNB Smart Chain.
Once this approval is granted, an attacker-controlled smart contract is able to transfer funds from the victim’s wallet at a later stage without further interaction. The reference to “QR-based hacking” is therefore misleading and serves primarily as a lure, with the QR code functioning as a delivery mechanism that redirects victims to a malicious decentralized application. The inclusion of Telegram contact details for purchase or demonstration further indicates that this capability is being marketed as a service, consistent with the broader Drainer-as-a-Service ecosystem. This model lowers the barrier to entry for threat actors by providing prebuilt infrastructure, phishing templates, and real-time victim monitoring, enabling large-scale financial theft operations without requiring advanced technical expertise.
This campaign demonstrates a highly effective blend of social engineering and blockchain-native abuse, targeting Trust Wallet users through trusted interaction flows rather than technical exploitation. By leveraging QR code delivery, deep link redirection, and convincing phishing interfaces, the attacker successfully manipulates victims into authorizing malicious transactions under the guise of routine wallet activity.
At its core, the attack exploits the ERC-20 approval mechanism, granting unlimited token access on BNB Smart Chain. This enables persistent and silent fund draining, where a seemingly harmless action can result in complete wallet compromise. The integration of Telegram-based real-time monitoring and scalable phishing infrastructure further highlights the maturity and operational efficiency of the campaign.
Overall, this activity reflects the growing evolution of Drainer-as-a-Service ecosystems, where prebuilt tools, automation, and low-cost blockchain operations are lowering the barrier for large-scale financial theft. The findings reinforce that the primary risk lies not in wallet vulnerabilities but in user-authorized interactions, making awareness, verification, and approval hygiene critical to defense.
| Type | Indicator | Description |
| URL | https://swift-wallat-usdt-send.netlify.app | Phishing URL hosting malicious USDT transfer interface |
| URL | https://send-usdt-09-admin.netlify.app | Phishing URL hosting malicious USDT transfer interface |
| Deep Link | https://link.trustwallet.com/open_url?coin_id=60&url=https://swift-wallat-usdt-send.netlify.app | Malicious deep link abusing Trust Wallet redirection |
| Attacker Contract | 0x76C77b171264e1a81baA63125D9627E70B43a169 | Malicious spender contract receiving unlimited approval |
rule Crypto_Drainer_TrustWallet_QR_Approval
{
meta:
description = “Detects Trust Wallet QR-based crypto drainer with specific URLs and malicious spender contract.”
author = “Cyfirma Research”
date = “2026-04-11”
threat_family = “Crypto Drainer”
reference = “QR + Deep Link + USDT Approval Abuse”
strings:
// URLs
$url_1 = “https://swift-wallat-usdt-send.netlify.app” nocase
$url_2 = “https://send-usdt-09-admin.netlify.app” nocase
$deep_link = “link.trustwallet.com/open_url?coin_id=60&url=” nocase
// Malicious spender contract
$malicious_contract = “0x76C77b171264e1a81baA63125D9627E70B43a169” nocase
condition:
any of them
}
