The attacker does not need your private key. They need one signature, produced by you, on a message you did not read. Everything else in a wallet-drainer operation exists to get you to that moment: the hijacked project account that posts the link, the pixel-perfect copy of the mint page, the wallet-connect prompt that looks like every other wallet-connect prompt, and the hex blob your wallet asks you to approve. Once the signature exists, your tokens move in a transaction you never sent, from an address you never saw, and the chain will record that you authorised it.

This is now an industry with a supply chain. Drainer kits are written by one group, rented to many, and deployed by operators whose only skill is acquiring traffic. The tooling has tracked every improvement in wallet security and found the next signature type to abuse.

We wrote this for protocol and NFT teams whose users are the targets and whose brand is the lure, and for security teams asked to assess how exposed a community is.

How a drainer works

A drainer operation is a chain of four links, and every link is replaceable without changing the others.

The lure

The victim must arrive at a page under the attacker's control, believing it belongs to someone they trust. Lures are a traffic-acquisition problem: a post from a project's compromised X account announcing a surprise airdrop, a pinned message from a Discord admin whose session token was stolen, a sponsored search result above the real site, a reply under a legitimate announcement with a lookalike domain. The common thread is urgency and borrowed authority. The lure almost never asks for a seed phrase, because it does not need one.

The fake dApp

The destination is a clone of the real front-end, often fetched from the real site and modified, served on a domain that differs by a character or a top-level domain. Kits are configurable per campaign, and the page loads a legitimate wallet-connection library so that the connection step behaves exactly as users expect.

Wallet connect

Connecting a wallet reveals the address. The kit then queries balances across every supported chain, ranks the victim's holdings by value and liquidity, and decides what to ask for first. The victim is presented with whichever request captures the most value in a single signature; this ranking logic is where kits compete.

The malicious signature

The page now presents a wallet prompt. It may be a transaction, in which case the victim pays gas and the wallet can simulate it. Increasingly it is an off-chain signature, which costs nothing, produces no on-chain event until the attacker uses it, and is harder for wallets to explain. The victim signs, and a separate address submits the transaction that moves the assets, usually within seconds.

The signatures that get abused

Each signature type was designed for a legitimate purpose. Drainers use them for that purpose, pointed at the wrong counterparty.

approve and setApprovalForAll

The oldest pattern. An ERC-20 approve for an unlimited amount, or an ERC-721 setApprovalForAll to the attacker's contract, lets the attacker call transferFrom whenever they choose. The approval is an on-chain transaction, so wallets can decode it and most now warn when the spender is unknown. Operators still use it because users approve things routinely and because the drain can be deferred.

Permit and Permit2

EIP-2612 permit lets a token holder authorise a spender with an off-chain signature instead of an approve transaction. Permit2 generalises this to any ERC-20 through a shared contract that many legitimate protocols use. For a drainer this is ideal: no gas, no on-chain footprint until the drain, and a signature request that looks identical to the one a trusted DEX would show. A single Permit2 signature can grant a spender rights over several tokens with a long expiry. If a user has ever approved the Permit2 contract for a token, which most active DeFi users have, one signed message is enough.

Marketplace order signatures

NFT marketplaces settle trades through signed orders. A seller signs a message listing their items and the price they accept; the marketplace contract fulfils it when a buyer appears. A drainer presents a bulk-listing signature that offers the victim's NFTs for a negligible price, or constructs an order where the consideration is a worthless token. The signature is structurally legitimate and the marketplace contract executes it exactly as designed; the attacker is simply the buyer. Wallets struggle here because the typed data is complex, nested, and identical in shape to a real listing.

Blind eth_sign

eth_sign signs an arbitrary 32-byte hash with no structure the wallet can decode. Whatever the hash represents, including a full transaction, the user sees only hex. Most wallets now block it or warn severely, and kits fall back to it only where it still works. If any front-end you operate uses eth_sign, it is training your users to ignore the one warning that matters.

Address poisoning

Not every drain needs a signature from the victim. Address poisoning exploits the habit of copying an address from transaction history. The attacker generates a vanity address whose first and last characters match an address the victim recently paid, then sends the victim a zero-value or dust transfer from it. The poisoned entry now sits in the victim's history, visually indistinguishable at a glance from the real counterparty. The next time the victim copies the address for a large payment, there is a chance they copy the attacker's. The defence is procedural: address books, full-address verification, and test transactions for new large destinations.

Compromised accounts and paid lures

The quality of the lure determines the conversion rate, and the highest-converting lure is the project's own voice. Session-token theft against Discord administrators, SIM swaps and credential phishing against the people who run a project's X account, and malicious browser extensions installed by community managers are the usual routes. Once inside, the attacker posts the link, pins it, and locks the channel so moderators cannot warn users.

Paid search is the other reliable channel. Ad platforms review landing pages inconsistently and operators rotate domains faster than reviews happen, so a sponsored result for a protocol's exact name sits above the real one for users who searched with intent.

Phishing-as-a-service

The kits are rented, not sold. A developer group maintains the drainer code, the backend that collects signatures and submits transactions, the anti-detection measures, and the per-chain asset ranking, and offers all of it through a private channel with support. Operators bring traffic. Proceeds are split automatically by the kit's own contracts, with the developer taking a fixed share of every drain.

The division of labour explains why defences lag. The developer group has a direct financial incentive to defeat every new wallet warning and sees results across thousands of operators at once, so a new check is tested against a kit that will be updated within days. Operators need no technical skill, which keeps the supply of lures unlimited. When one kit is taken down, operators migrate to the next; the business model survives the brand.

What wallets and simulation can and cannot show

A wallet that simulates a pending transaction against current chain state can show the resulting balance changes, flag an unlimited approval, and warn when the spender is newly deployed or tagged as malicious. For on-chain transactions this works well.

The limits sit where drainers now operate. An off-chain signature has no transaction to simulate; the wallet can only render the typed data and guess at its meaning. For a Permit2 signature, the wallet can show the spender and the amounts, but whether that spender is legitimate depends on context the wallet lacks. For a marketplace order, the wallet can show that items are being listed and for what consideration, if it understands that marketplace's schema; a new or modified schema shows as raw fields. Blocklists catch known domains and addresses and miss the ones created that morning. Simulation also cannot see what a signature will be used for later, because the attacker decides that after the fact.

That is why the defence cannot rest on users alone.

Defending users

The practical measures that reduce losses, in roughly the order we recommend them:

  • Separate wallets by purpose. A hot wallet for minting and interacting with new sites, holding only what that session needs, and a vault wallet that never connects to anything. A drainer can only take what the connected wallet can authorise.
  • Revoke approvals routinely. Approvals outlive the session that created them. Review and revoke spenders for ERC-20 and NFT approvals, including Permit2 allowances, on a schedule.
  • Never sign on a page reached from a link. Bookmark the real site; reach it from the bookmark. Treat search results and social posts as untrusted, including from the project's own account.
  • Use a hardware wallet with clear signing where the device displays the decoded content of typed data, and refuse to sign anything it shows as raw hex.
  • Verify full addresses, not prefixes and suffixes, and use the wallet's address book for recurring counterparties.
  • Treat urgency as a signal. Legitimate airdrops and mints do not expire in the next ten minutes.

For teams

Protocol and NFT teams are not the victims of a drainer, but they are the lure, and users hold them responsible. The team's obligations are to make the real front-end easy to verify, make impersonation expensive, and respond fast when it happens.

Domain and brand monitoring is the first layer. Register lookalike domains across the common top-level domains, monitor certificate transparency logs and new domain registrations for your name, and have a standing relationship with a takedown service or registrar abuse contact so that a report goes out within minutes rather than after a Discord thread forms. Monitor ad platforms for sponsored results impersonating you and report them with the same urgency.

Harden the accounts that speak for you. Hardware security keys on every X, Discord and email account that can post as the project, minimal admin roles, no shared credentials, and a policy that no announcement links go out without a second person's check. Admins should assume their session tokens are a target.

Make the front-end verifiable, as described in Web3 front-end security. A single canonical domain, published and repeated everywhere. An ENS or equivalent name that resolves to the content hash of your deployed front-end so users can verify they are on the real build. Signing flows that use typed data with clear, human-readable field names, never eth_sign, and never a request for an unlimited approval where a bounded one would do. If your protocol integrates Permit2, explain what the signature looks like in your documentation so users learn what legitimate looks like.

Prepare the response. A pre-written warning for every channel, a known list of who can post it, a way to pin it in Discord even when an admin account is compromised, and a path to warn users through the front-end itself. Our article on the first 24 hours after a hack covers the general structure; a phishing wave is the most common reason a team will use it.

What we do in a phishing-resilience assessment

A phishing-resilience assessment looks at a project from the attacker's side, with the goal of answering one question: how hard is it to drain your users using your name?

We start with reconnaissance. We enumerate the project's public surface: domains, social accounts, Discord and Telegram structure, community moderators, ad presence, and the front-end's signing flows. We then identify which lure would convert best and which accounts an attacker would need to compromise to deliver it.

We test the signing surface directly. For each flow in the real front-end, we record what the user is asked to sign and how it renders in the common wallets, with and without hardware signing. Flows that produce blind signatures, unlimited approvals, or typed data that renders as raw fields are findings, because they train users to accept exactly what a drainer will show them.

With the team's agreement we run a controlled simulation against the people who can post as the project: a lookalike admin request, a fake collaboration offer, a counterfeit login page. The aim is to find out whether the account hardening is real before an operator tests it for free.

We review the detection and takedown process by exercising it. We register a lookalike domain, stand up a harmless clone, and measure how long it takes the team to notice, to issue a takedown, and to warn users through each channel. That interval determines how many users are drained.

The report ranks findings by how directly they translate into drained wallets and includes a short runbook: who watches what, who posts what, and how quickly.

Practical next steps

  • Audit your own signing flows in every wallet your users are likely to run, and remove eth_sign and unbounded approvals.
  • Put hardware keys on every account that can post as the project, and remove admin roles nobody needs.
  • Register and monitor lookalike domains, certificate logs and sponsored search for your name, with a takedown contact ready.
  • Publish one canonical domain and an on-chain name that resolves to your front-end's content hash.
  • Write the warning before you need it, and know who can pin it when the usual admin is the one compromised.

The related question of what a team's own keys look like is covered in key management for protocols. If you want a phishing-resilience assessment for your community, scope and process are on the services page, and you can reach us on Telegram.