Summary
Drainer-as-a-service kits (Inferno, Pink, Angel) industrialized crypto phishing, stealing roughly $295M from over 324,000 victims in 2023 and $494M from 332,000 victims in 2024 per Scam Sniffer; Inferno alone took nearly $88M from 137,000 victims before its November 2023 shutdown, with operators keeping a 20% cut of every theft and handing affiliates ready-made phishing scripts spoofing 100+ brands. The kit serves a malicious dApp front-end that injects a JavaScript drainer; it enumerates the connected wallet's most valuable tokens and NFTs, then sequences signature prompts whose intent the wallet cannot meaningfully render: an EIP-2612/Permit2 permit, an unlimited ERC-20 approve, or setApprovalForAll. Because the wallet shows an opaque EIP-712 hash or a generic approval, the victim clicks sign or confirm; the drainer relays the resulting signature or on-chain approval and immediately calls transferFrom or safeTransferFrom from a backend to sweep assets to attacker wallets, splitting proceeds with the kit operator. The affiliate model means thousands of low-skill actors run identical, optimized drainer logic at scale.
How to avoid it in your code
- Wallets must integrate transaction-simulation and threat scanning (Blockaid, Wallet Guard, ScamSniffer) to flag known drainer signatures and contracts before the user signs.
- Builders should decode and human-readably display every approval, Permit, and setApprovalForAll request, never raw hashes or generic confirm dialogs.
- Users should connect only to bookmarked dApp URLs, distrust airdrop/mint links from social media, and never blind-sign on a fresh unverified contract.
- Users should use a hardware wallet that renders full calldata and periodically revoke stale approvals via revoke.cash.
- dApps should request least-privilege exact-amount approvals and scope token connections, reducing what a malicious clone can extract.
References
- https://www.theblock.co/post/270105/crypto-phishing-attacks-2023
- https://drops.scamsniffer.io/scam-sniffer-2024-web3-phishing-attacks-wallet-drainers-drain-494-million/
- https://www.group-ib.com/blog/inferno-drainer/
- https://www.bleepingcomputer.com/news/security/cryptocurrency-wallet-drainers-stole-494-million-in-2024/
Related vulnerabilities
All Web3 →- HIGHWEB3-APPROVAL-PHISHING-2023
On-chain approval phishing remains a core drainer technique within the hundreds of millions stolen annually (Scam Sniffer attributed $295M in 2023 and $494M in 2024 to wallet drainers), abusing the standard ERC-20 approve and ERC-721/1155 setApprovalForAll authorization model. A malicious dApp prompts the victim to send a real on-chain transaction calling approve(spender, type(uint256).max) for a token, or setApprovalForAll(operator, true) (selector 0xa22cb465) for an NFT collection, designating the attacker contract as spender or operator. Wallets historically rendered these as a generic approve with no amount or as an unreadable contract interaction, so the victim confirms a high-value, broad authorization without understanding its scope. Once the allowance or operator flag is set, the attacker's contract calls transferFrom or safeTransferFrom at any later time to drain every token or NFT covered, with no further victim interaction. The approval persists indefinitely until revoked, so victims who signed months earlier remain exploitable.
- CRITICALWEB3-BLIND-SIGNING-2024
Blind signing, approving a payload the wallet cannot decode, is the final step behind the largest multisig drains: Radiant Capital lost about $50M in October 2024 and Bybit about $1.5B in February 2025, both via hardware-wallet signers approving transactions whose true effect their devices could not render. In the Radiant attack, malware showed legitimate-looking transaction data in the Gnosis Safe front-end while the hardware wallets actually received and signed a Safe execTransaction whose inner operation was a delegatecall to an attacker contract; that delegatecall executed in the Safe's own storage context and overwrote the implementation/owner state, handing control to the attacker. Because a hardware wallet's small display can only show a four-byte selector and raw hex, signers cannot parse a nested execTransaction or distinguish a benign call from a delegatecall that rewrites storage slot zero. The same root cause applies to legacy eth_sign, which signs an arbitrary 32-byte hash with no context, letting a phishing site obtain a signature reusable as a transaction authorization. The signer sees one intent and authorizes a different one.
- CRITICALWEB3-PERMIT-PHISHING-2024
Gasless permit signatures are now the dominant phishing vector: Scam Sniffer found Permit-type signatures accounted for 56.7% of 2024 wallet-drainer attacks within $494M of total losses, with cases like an October 13, 2024 Permit2 phish that drained roughly $1.39M of PEPE, MSTR and APU from one victim. EIP-2612 adds a permit(owner, spender, value, nonce, deadline, v, r, s) function so an owner signs an off-chain EIP-712 Permit struct that sets an ERC-20 allowance; the standard explicitly allows any address to submit it on-chain. The phishing dApp prompts that off-chain signature with the attacker as spender and value set to the full balance or type(uint256).max; the victim never sends a transaction or pays gas, and the wallet often shows an opaque typed-data blob. The attacker then submits permit() to register the allowance and immediately calls transferFrom to sweep the tokens. Uniswap's Permit2 generalizes this to every ERC-20: a single PermitSingle/PermitTransferFrom signature authorizes the attacker as spender, and because Permit2 defaults to the entire balance, one careless signature empties the wallet.
- HIGHWEB3-ADDRESS-POISONING-2024
Address poisoning exploits the human habit of verifying only the first and last few characters of a wallet address; on May 3, 2024 a whale lost roughly $68M in WBTC after copying a poisoned look-alike address, the single largest recorded case. Attackers brute-force a vanity address whose leading and trailing characters match an address the victim recently transacted with, then seed it into the victim's history. They do this cheaply by emitting a Transfer event the victim did not authorize: a zero-value ERC-20 transferFrom, or a fake-token contract that emits Transfer logs, so the look-alike address appears in the wallet's recent-activity list at essentially gas-only cost (the $68M poisoning transaction carried 0 ETH value and about $0.65 gas). Later, the victim copies the recipient from their own transaction history, pastes the attacker's near-identical address, and sends funds directly to it. No signature exploit is involved; the attack is pure UI deception of the wallet's transaction-history display.
- CRITICALWEB3-BEANSTALK-2022
On April 17, 2022, the Beanstalk stablecoin protocol was drained of about $182 million in a governance attack amplified by a flash loan, netting the attacker roughly $80 million after repaying the loan. The attacker borrowed about $1 billion across Aave and other venues (350M DAI, 500M USDC, 150M USDT plus BEAN and LUSD), deposited it into Curve to mint roughly 795M BEAN3CRV-f and 59M BEANLUSD-f LP tokens, and supplied them to Beanstalk's Silo to instantly hold a supermajority (over 78%, above the two-thirds threshold) of STALK governance power. Beanstalk's emergencyCommit path let a proposal pass once 24 hours had elapsed and a two-thirds vote existed; the attacker had pre-submitted a malicious BIP (BIP-18) whose init contract transferred the protocol's funds, then executed emergencyCommit in a single transaction. The core flaw was that voting power could be acquired flash-loan-instantly with no time-lock against single-block voting. Funds were laundered through Tornado Cash and never recovered; the attacker remains anonymous.
- CRITICALWEB3-POLY-NETWORK-2021
On August 10, 2021, an attacker exploited Poly Network's cross-chain contracts to steal about $611 million across Ethereum, BSC, and Polygon, the largest DeFi theft at the time. No keeper private keys were stolen; instead the attacker abused an access-control flaw. The EthCrossChainManager contract's verifyHeaderAndExecuteTx dispatched cross-chain calls through _executeCrossChainTx, which made an arbitrary contract call with no allowlist on target or method. The EthCrossChainData contract, which stores the bridge keeper public keys, was owned by the Manager, and its putCurEpochConPubKeyBytes setter was onlyOwner. Because Solidity derives a function selector from the first four bytes of a keccak256 hash, the attacker brute-forced the method string f1121318093, whose selector collides with putCurEpochConPubKeyBytes (0x41973cd9), and had the Manager call it as owner, replacing the entire keeper set with their own key and signing arbitrary withdrawals. The attacker, framing it as a white-hat demonstration, returned nearly all funds over about 15 days, with only about $33 million in USDT (frozen by Tether) initially outstanding.