Phishing Signatures That Drain Crypto Wallets and How to Spot Them
Phishing attacks on crypto wallets have grown more surgical. The old trick of asking for a seed phrase still exists, but it is no longer the main threat. The more dangerous play works entirely through signatures. No transaction gets broadcast. No funds move on-chain until it is too late. The wallet just signs a message, and the attacker walks away with everything.
Three signature types are responsible for most of these silent drains: eth_sign, permit, and setApprovalForAll. Each works differently. Each has tells that most users miss. This page explains what they look like, what the wallet warnings actually mean, and why simulation tools can fail you.
eth_sign - the blind signature
eth_sign is the rawest signature request in Ethereum. It asks your wallet to sign an arbitrary hash. The wallet displays a block of unreadable hex or scrambled text. MetaMask warns you outright: "Only sign this message if you fully understand the content and trust the requesting site." Rabby shows a similar red banner.
Most users do not know what that warning actually means. It means the signature can authorise anything. The attacker crafts a hash that, when verified by a smart contract, gives them full control over your tokens. The message itself is not human-readable because it was never meant to be. If you see a wall of hex and the wallet is telling you to be cautious, stop. Do not sign.
The simple rule: never sign an eth_sign request. There is no legitimate reason for a normal user to sign raw hashes. If a site asks for it, close the tab.
permit - the deceptive approval
permit is part of the ERC-2612 standard. It was designed to let users approve token spending in a single transaction, saving gas. The user signs an off-chain message that says "I permit this contract to spend X amount of my tokens." The attacker then submits that signed message on-chain to drain the wallet.
The wallet shows a structured message with fields: owner, spender, value, deadline, and a nonce. The warning text is softer than eth_sign. MetaMask says "Sign this message to allow a third party to spend your tokens." That sounds less alarming than it is. Many users see the word "permit" and think it is a harmless gas optimisation.
The danger is that permit signatures can be replayed. If you sign one, the attacker can submit it later - seconds, hours, or days after you signed. The deadline field might look like a safety net, but attackers often set it far in the future or bypass it entirely.
Look closely at the spender address. If you do not recognise it, do not sign. Look at the value. If it says a massive number or "unlimited," that is a red flag. No legitimate site asks for unlimited approval via a signature.
setApprovalForAll - the blanket permission
setApprovalForAll is an ERC-721 and ERC-1155 function. It grants a spender full control over all of an owner's NFTs or semi-fungible tokens in a given contract. The phishing version tricks the user into signing a message that calls this function off-chain.
The wallet display varies. MetaMask might show a structured message with fields like "owner," "operator," and "approved." The warning says something like "This operator will be able to transfer all your tokens in this contract." Rabby's warning is similar.
The key difference from permit is scope. permit limits the spend to a specific token balance. setApprovalForAll covers every token you own in that contract. One signature, and every NFT in that collection is forfeit.
Check the "operator" address. If it is not a marketplace you trust explicitly, do not sign. Check the contract address. If it does not match the NFT collection you think you are interacting with, that is a trap.
Why transaction simulation alone may miss these
Transaction simulation tools - like those built into Rabby or third-party extensions - simulate on-chain movements. They catch obvious malicious contract calls. But off-chain signatures bypass simulation entirely. The simulator never sees a transaction because no transaction exists yet.
The attacker collects the signed message and submits it later from a different wallet or through a relay contract. The simulation tool had nothing to simulate at the time you signed. By the time the drain transaction hits the mempool, your approval is already live.
Simulation is useful for catching on-chain attacks. It is not a defence against signature-based phishing. Treat every signature request as a potential threat, even if the simulator says it is clean.
Your mental checklist for every signature request
Before you click "Sign," run through this list in order:
- What type of signature is this? If it is
eth_sign, deny immediately. No exceptions. - Can I read every field? If any field is hex, gibberish, or says "data" with a long string, do not sign.
- Who is the spender or operator? If the address is unfamiliar, paste it into a block explorer. If it has no transactions or was created recently, reject.
- What is the value or scope? If it says "unlimited" or covers all tokens in a contract, that is a warning.
- Does the site match the URL in your address bar? Phishing sites clone legitimate interfaces. Cross-check the domain, not just the appearance.
No single check is foolproof. But running all five before every signature will stop the vast majority of drain attempts. The attackers are counting on you to rush. Do not.
Not financial advice. 4547onsol.xyz publishes market data and general information about digital assets. Crypto assets are volatile and you can lose everything you put in. Nothing here is a recommendation to buy, sell or hold, and we make no price predictions.
Prices are sourced from third parties and may be delayed or wrong. Verify anything you intend to act on against a primary source.