Wallet drainers turn a wallet prompt into permission to take funds.

A wallet drainer gets a visitor to sign a transfer or give an attacker permission to spend their crypto assets. Fake mint, payment, trading and wallet-repair pages load the code through bundled scripts, local settings files and remote imports.

fake crypto page
  -> local bundle or remote drainer script
  -> visitor connects a wallet
  -> permit signature, token approval or transfer request
  -> attacker receives funds or permission to spend them

The page loads a drainer behind a familiar action

OpenSea impersonations put wallet-connection scripts behind a mint or claim button. A Creditlink clone appends a script from a same-origin /secureproxy route carrying an IPFS path and a timestamp to prevent caching. Another counterfeit Web3 page loads settings.js beside a remote web3-ethers.js module.

Wallet-repair pages load settings from /api/init, ask the visitor to switch networks and then request token approvals or transfers. Fake Trust Wallet transfer forms present an amount and recipient field while their signing code prepares an unlimited USDT approval to a configured spender.

Permits and approvals give away spending permission

A token approval names a spender and the amount it can spend. Drainer pages request MaxUint256, the maximum allowance, then report the wallet and approval to a backend or Telegram bot. The fake Transit Swap page requests an unlimited approval first and a direct USDT transfer next, using destinations supplied by its server.

A permit grants spending permission through a signed message. Inferno Drainer builds that message from the token's chain, address, nonce and permit configuration, then binds it to a recipient selected by the drainer. Its warning-bypass branch substitutes a generated address before constructing the permit.

An Etherscan ownership-verification clone asks for a USDC ReceiveWithAuthorization signature that authorizes the full balance to an attacker address. It sends the signed data to /api/store-victim.

Direct transfers and recovery-phrase forms

A counterfeit Uniswap connect action reads the wallet's native balance, subtracts a gas allowance and requests a transfer. It then reads token balances and requests token transfers. A Trust Wallet lure retrieves merchantAddress from api/getConfig and uses it as the recipient of the full TRON USDT balance.

Other pages ask for the recovery phrase or private key. A fake pending-transaction form tells the visitor to connect a wallet and enter a phrase or key for verification, then posts the secret to submit.php.

Packed scripts hide the request until the page runs

Drainer loaders use compressed strings, generated functions and dynamic imports to keep the signing code out of plain page source. One embeds hexadecimal XZ data, decompresses it through WebAssembly and passes the result to eval. Another decompresses an LZ-String UTF-16 payload and runs it through new Function.

Self-hosted settings hide permit priorities, transfer modes and minimum wallet-value gates behind hex, XOR and Base64 decoding. Controller settings supply prompts such as a sign-in request or an insufficient-activity message according to the connected wallet's balance.

A Solana drainer pads a signing batch with dummy transactions, then discards the padding and relays the original signed batch.

What we see across these sites

Month	New sites
September	112
October so far	31

Of the 39 sites captured since 25 September, 0 ran WordPress.

Of the 2 sites recaptured at least 25 days after their first match, 1 still served wallet-drainer code (50%).

Checking the page and its signing code

Keep the HTML, loaded scripts and configuration replies. Trace the wallet button through to the request it prepares. Check for:

• mint, claim, transfer or repair buttons that load an unfamiliar wallet script
• packed code that decompresses text and runs it through eval, Function or a dynamic import
• approve calls with a maximum allowance and a spender supplied by page settings
• typed-data signatures containing a spender, recipient, full balance or token permit
• transfers that use the full wallet balance or a server-supplied recipient
• recovery-phrase or private-key inputs posted to a collector
• reports of connected wallets, approvals or signatures sent to a backend or bot

On a compromised site, remove the added code and restore changed templates and scripts from a trusted deployment. Review CMS, hosting and deployment access, rotate affected credentials and clear cached copies. Retest the wallet action from a clean browser profile and compare the requested spender, amount and recipient with the site's intended transaction.