How wallet drainers work: the approvals and signatures that empty accounts

Wallet drainers work by harvesting reusable authorization from a victim’s wallet, then using that permission to move tokens, NFTs, and sometimes native coins without asking again. The chain enforces those signed approvals and typed-data permits as valid instructions, so the theft often reads like normal DeFi activity rather than a “hack.”

Key Takeaways

• A wallet drainer usually succeeds without a seed phrase by getting the victim to sign an ERC-20 approval, an NFT operator approval, or a permit-style typed-data signature.
• The scam is typically two-stage: permission capture first, then an automated sweep immediately or later using functions like transferFrom or setApprovalForAll.
• Signature phishing is often more dangerous than it looks because typed-data signatures can be turned into on-chain approvals after the fact.
• Drainers frequently route through legitimate DEX routers so the on-chain trace resembles a normal swap, which delays detection and response.

Wallet drainers and approval phishing basics

The core trick is simple: the attacker doesn’t need to break wallet cryptography if the victim can be convinced to authorize the attacker as a spender. That is why a wallet drainer sits inside the normal DeFi user experience, not outside it. The victim connects a wallet, sees a familiar prompt, and signs something that looks routine. The blockchain then does what it is designed to do, which is enforce authorization exactly as signed.

This is why approval phishing is the right mental model. The attacker is not “logging in” as the victim. The attacker is obtaining a permission the protocol recognizes, then using it like a standing credit line. FinanceFeeds’ Trust Wallet drainer campaign write-up is explicit that these flows can empty wallets “the second a user clicks approve,” and that the mechanics mirror legitimate DeFi usage rather than malware or an exploit.

A useful distinction for readers coming from Web2 security is that a wallet can be “compromised” in the sense of being drainable without the private key ever leaving the device. CryptoAdventure frames it as consent: the user signs, the chain validates, the attacker transfers. That is also why “I use a hardware wallet” is not a complete defense. FinanceFeeds notes hardware wallets reduce private-key theft risk, but they do not prevent user-approved drains if the user signs the wrong approval.

This explainer sits inside the broader topic of crypto wallet scams and how to avoid them because the defense is mostly permission hygiene, not antivirus.

The connect-and-approve attack flow

The highest-probability drainer path is a distribution problem first and a smart contract problem second. FinanceFeeds describes a five-step playbook tied to India’s national cybercrime advisory TAU/ADV/013: impersonation DM on Telegram, Discord, or X, a cloned site, a wallet connection prompt via WalletConnect or an in-wallet browser, a single approval, then an automated sweep. Blockaid’s teardown adds another distribution vector that matters for traders who move fast: front-end hijacking, where a legitimate site’s UI is replaced with a malicious version.

End-to-end, the flow is usually:

1. Lure the user to a lookalike domain or hijacked front end. The lure is often “verify,” “claim,” or “airdrop,” and it is designed to create urgency. 2. Force the wallet connection early. Blockaid observed a page where any button triggered the connect dialog, which is a common behavioral tell. 3. Collect wallet context. Blockaid shows the drainer communicating with command-and-control infrastructure and using JSON-RPC reads like eth_call to learn what assets and nonce state it can target. 4. Harvest the permission. This is the moment the victim thinks they are doing something harmless, like approving a token for a swap, or “signing a message.” 5. Execute the sweep. FinanceFeeds describes “sweeps everything in seconds,” and Coca emphasizes that the drain can be delayed, which is how victims get confused about what action caused the loss.

The “drainer as a service” angle matters because it explains why these flows look templated. Coca describes drainers as kits sold to scammers, and that packaging is why the same UX patterns repeat across chains and wallets.

Permissions drainers abuse on-chain

ERC-20 allowances are the workhorse. A normal dApp asks for approval so it can move tokens on the user’s behalf during a swap or deposit. A crypto drainer asks for the same approval, but points the spender at an attacker-controlled contract or address and often pushes an unlimited cap. Once that approval exists, the attacker can come back later and move tokens using transferFrom without any new prompt to the victim. FinanceFeeds and Coca both call out unlimited approvals as the lever that makes this scalable.

The delayed-drain pattern is where people misdiagnose what happened. Coca describes the sequence where a user approves today, sees no immediate movement, then tops up the wallet later and gets drained within seconds because the standing approval was already in place. That is why the right way to read an approval is not “did money leave right now,” but “who did I just authorize to pull money later.”

NFTs have their own version of the same trap. FinanceFeeds and Coca both point to setApprovalForAll, which grants an operator the ability to move all NFTs in a collection for that wallet. Users often treat this as a one-off step to list or mint. For a drainer, it is a master key for that collection.

Two practical implications fall out of this:

1. The attacker’s edge is persistence. A single approval can remain valid until revoked. 2. The victim’s edge is reversibility of permissions. FinanceFeeds and Coca both point to tools like Revoke.cash and Etherscan’s token approval checker to review and revoke allowances and operator approvals.

This is also where the term wallet drainer explained should land: it is not a magic contract that “breaks” wallets. It is automation that abuses the exact permission rails DeFi relies on.

Signature-based drainers and permit traps

The most expensive pop-ups are often the ones that don’t look like transactions. Blockaid’s 2024-10-13 teardown shows a drainer using eth_signTypedData_v4 to capture an EIP-712 typed-data signature that encodes an EIP-2612 permit. The drainer first gathered nonce and token metadata via eth_call, then prompted the victim to sign structured data that authorized a spender for a very large value. The key point is that the signature is off-chain at the moment the victim signs it, but it can be submitted on-chain later through the token’s permit function.

That is signature phishing in its cleanest form. The victim thinks “I didn’t send a transaction.” The attacker thinks “I just got an approval I can execute when I want.” Coca flags permit and Permit2-style signature risks as part of modern drainer kits, and CryptoAdventure groups these as signature-based drainers distinct from classic on-chain approval drainers.

Blockaid also observed wallet_switchEthereumChain in the same flow, forcing a switch to Arbitrum One even though the page posed as a BNB Chain airdrop. That chain-switch request is not cosmetic. It is a way to target the network where the victim actually holds assets.

Two consequences matter for users:

1. Typed-data signatures can be harder to reason about than an on-chain approval prompt because they present as “signing a message.” Blockaid argues most wallets cannot simulate these off-chain signatures the way they can simulate on-chain transactions. 2. The attacker can separate permission capture from execution. That timing flexibility is why drainers can wait for low-fee moments or for the wallet to be topped up.

This is also why blind signing is a recurring failure mode. If the wallet UI does not clearly show what the typed data authorizes, the user is effectively signing in the dark.

Why drains look like normal activity

A drainer operator wants the chain to look boring. Blockaid shows a native-asset drain routed through a legitimate SushiSwap Router contract, calling swapETHForExactTokens, rather than a direct ETH transfer to an attacker address. The point is not that SushiSwap is compromised. The point is that routing through a widely used router makes the transaction resemble routine swapping behavior.

FinanceFeeds makes the same observation from the victim’s perspective: Darktrace tracked a variant that drained $470,000 from a single victim in two minutes, and the on-chain transaction “looks no different from a routine Uniswap swap.” That is the camouflage layer. If the theft reads like a swap, casual observers and even some automated heuristics lose time.

This is where the thesis bites: authorization is the product. Once the attacker has a valid allowance, operator approval, or permit signature, the blockchain will faithfully execute it later, fast, and in a way that can be routed through legitimate contracts.

For traders and power users, the operational takeaway is that “spotting the theft on-chain” is a weak defense. By the time a swap-like drain is visible, the assets are already moved and often already swapped into more liquid tokens. The higher-signal moment is earlier, at the permission boundary: unexpected chain-switch prompts, repeated connect dialogs, and a site that pushes approvals before it does anything useful.

How to reduce drainer risk

Defense is mostly about reducing how much authority any single click can grant, and reducing how much value sits behind that authority. FinanceFeeds recommends starting with the wallet’s own “Connected Sites” or “Permissions” panel to revoke anything not actively used, then checking token approvals with Revoke.cash. Coca frames revocation as a routine, not an emergency, because the drain can be delayed.

A clean workflow looks like this:

1. Separate roles across wallets. Keep a “vault” wallet that never connects to dApps, and a spending or burner wallet for mints, airdrops, and new protocols. Coca explicitly recommends this structure to limit blast radius. 2. Treat every approval or signature as a standing credit line. If the prompt shows unlimited, assume the spender can pull the full balance later unless the dApp offers a tighter limit. 3. Watch for UX red flags that correlate with drainers. Blockaid’s example includes relentless connect prompts and a wallet_switchEthereumChain request that contradicts the site’s stated chain. 4. Audit and revoke on a schedule. FinanceFeeds and Coca both point to Revoke.cash and Etherscan’s token approval checker for reviewing allowances and revoking them. 5. If targeted, act on permissions first. Disconnect connected sites, revoke approvals and NFT operator permissions, and move remaining funds to a fresh address. FinanceFeeds emphasizes that the drainer does not exploit Trust Wallet itself, and the same risk applies across hot wallets like MetaMask and Phantom.

This is the part of crypto wallet scams and how to avoid them that actually holds up under pressure: assume the spending wallet will eventually sign something dumb, and design the system so that mistake is survivable.

The Take

I’ve watched too many people frame a drainer as a “hack” and then waste the first hour hunting for malware while the real problem sits on-chain as a permission they granted. The expensive mental shift is treating approvals and typed-data signatures like opening a standing credit line. Once that line exists, the attacker doesn’t need to ask again. They just show up later with transferFrom or an operator transfer and the chain enforces it.

The failure mode that keeps repeating is blind signing dressed up as a harmless click. Blockaid’s 2024-10-13 teardown is the clean example: eth_signTypedData_v4 harvests a permit, then the drain can be routed through a real router so it reads like a normal swap. Hardware wallets keep keys safe, but they don’t save judgment. Permission hygiene does.

Sources

• FinanceFeeds
• Blockaid
• Coca
• CryptoAdventure