Wallet Phishing: Seven Patterns and Permission Checks
A wallet asks you to sign. Is it logging you in, or giving someone permission to spend a token later? Before looking for the confirm button, answer that question. If the request cannot be explained, close it.
Educational information, not a security guarantee. Confirmed transfers generally cannot be reversed, while unused permissions may be exploited quickly. See the disclaimer.
When I would close the signing window
Fatigue, urgency and switching between several tasks make details easier to miss. There is no verified “night-time success rate” behind this advice, and the patterns below are not ranked by dollars lost.
- A page rushes you toward a deadline without time to inspect the request.
- You only wanted to read or log in, but the prompt contains a spender, token amount or NFT operator.
- A friend or moderator sends a link that you have not independently verified.
- The wallet shows an account, network or asset different from the one you intended.
Legitimate events can have deadlines. Urgency alone does not prove fraud, but it does not justify skipping the check. I would rather miss an event than grant a permission I cannot explain.
Seven patterns to recognise
1 · Token and NFT approvals
Under the ERC-20 standard, approve grants a particular spender an allowance for one token. It does not itself transfer that token. A later successful call can use the permission, and a broad allowance can expose future deposits of the same token.
For NFTs, setApprovalForAll gives an operator authority over the relevant collection contract, not every asset in every collection in the wallet. Both mechanisms have legitimate uses. The function name is not enough to identify phishing.
Check the network, token contract, full spender or operator address, amount and purpose. A familiar protocol name is not an address check. If a simple claim asks for spending permission over unrelated assets, reject it until the reason is clear. Known protocols do not get an automatic exception for unlimited approvals.
2 · Permit signatures with financial consequences
ERC-2612 lets a signed message change an allowance when it is submitted under the required conditions. Inspect the domain, verifying contract, spender, amount, nonce and deadline. A webpage calling the request “login verification” does not change what it authorizes.
Permit2 separately supports time-bound allowances and one-time signature transfers, with a token approval to Permit2 beneath them. Similar names do not mean identical revocation rules.
Resetting a current ERC-20 allowance does not universally invalidate unused signatures. An unused ERC-2612 permit may set it again while its nonce and deadline remain valid. Permit2 requires checking the relevant permission layer and nonce. After a suspicious signature, preserve its contents and act on the specific mechanism; do not wait for a monthly cleanup.
3 · Address poisoning
An attacker puts an address resembling a trusted one into your transaction history, hoping you will copy it later. Small transfers, zero-value transfers or misleading token records can be used; there is no fixed attack amount.
Obtain the receiving address from a trusted source and check the entire address and network. Save verified recipients in an address book. Human-readable names need spelling and current resolution checks too. Recheck the final address for a larger transfer even after a successful small test.
4 · Clipboard hijacking
Malware can replace the address between copying and pasting. Pasting it into a text editor first does not establish that the device is clean: both copies can be changed, or malware can target the wallet specifically.
Inspect the final destination in the signing interface and on the hardware display when available. If an address changes unexpectedly, stop handling funds on that device and investigate from a trusted clean environment. Neither an operating-system brand nor an antivirus product makes this impossible.
5 · Links from compromised communities
A familiar moderator account or friend can be compromised. Start from an independently verified project site and check the announcement there. Search ads, reply links and direct messages should not be your only evidence of identity.
Even a genuine official account or website can be taken over. Inspect the wallet request separately from the page's appearance. Reading an announcement does not require giving a contract spending permission.
6 · Extensions and device compromise
An extension publisher, software supply chain or local device can be compromised. Reach an extension listing from the project's verified site, and check the publisher and extension identity. A large download count is not proof of safety.
Keep only the extensions you need. A separate browser profile reduces mixing but does not isolate you from malware in the shared operating system.
Hardware wallets help keep private keys separate. They do not retract old permissions: an attacker using an existing allowance may move assets without another button press on the device. Check requests and protect recovery material as well.
7 · Fake support asking for recovery credentials
“Syncing”, “repairing a node” and “unlocking an account” are not reasons to send a recovery phrase or private key to support. Do not share a backup screen or give remote-control access to someone who contacts you.
Initiate support through a verified official channel. If the phrase was exposed, changing the app password or revoking approvals is insufficient. Treat accounts derived from that seed as compromised and use a clean device with a new seed. The wallet-drain response guide explains why this differs from allowance abuse.
Three hypothetical prompts, not historical case reports
“View this NFT” requests setApprovalForAll. That is management permission, not permission to read a page. Reject it unless you actually need and understand the operator's authority.
“Free login” includes a token amount. Check whether it is a permit or another financially meaningful signature. No gas charged to you at that moment does not mean no asset risk.
“Support repair” asks for the recovery phrase. Stop the conversation. Restore only in verified wallet software on a trusted device, never on a webpage sent by the caller.
These examples explain requests. They do not claim victims, dates, losses or transaction evidence from a security firm's investigation.
Before signing or sending
- Verify the entry point, account and network.
- Explain why this operation needs the permission.
- Read the full destination, token, amount and expiry.
- Check the final recipient instead of copying unfamiliar history entries.
- Respond immediately to suspected misuse or key exposure.
Periodic approval cleanup helps, but tools only cover their supported networks and permission types. An empty list is not proof that the wallet is safe.
FAQ
Do hardware wallets stop every phishing attack?
No. They isolate keys but can still sign malicious requests you confirm. Previously granted allowances may be used without a new device confirmation.
I signed a bad approval but nothing has moved yet — can I still revoke?
There may be time to act, but no guarantee. Identify the network, permission and affected assets, then revoke or migrate as appropriate. Unused signatures may require separate nonce or permission-layer handling.
Which wallets have built-in phishing protection?
Several provide warnings or simulations, with coverage that changes by version and network. No warning does not establish safety; still inspect the addresses, permissions and asset changes.
What is address poisoning?
It puts an address resembling a trusted one in your history so you may later copy the wrong recipient. Check the full address, network and source, including current name resolution.
I never click suspicious links — am I still at risk?
Yes. Malware, compromised familiar sites or accounts, clipboard replacement and old approvals remain possible risks. Avoiding unfamiliar links is one defence, not a guarantee.