NexFlow › Ice phishing

Ice phishing — the signature attack that never touches the chain

The most invisible approval theft: a signature that authorizes a transfer without ever sending a transaction. Microsoft named it 'ice phishing' — here are the exact mechanics and the defense.

Updated 2026-10-06 · ~8 min read · every claim sourced and dated

Ice phishing is the approval scam’s most refined form: instead of asking you to send an on-chain approval transaction, the attacker collects an off-chain signature — a cryptographic authorization created in your wallet that never touches the blockchain until the attacker uses it. Microsoft’s security research team named the technique in 2022 after identifying it in attacks against Web3 users; it has since become the preferred drain vector precisely because it’s harder to see coming than a normal transaction.

Every claim below names its source and date.

What an off-chain signature actually is

Ethereum’s token standards include a feature designed to save gas: instead of sending an approval transaction (which costs gas), you can sign an approval message — a structured blob authorizing a spender — that the spender later submits on-chain themselves, paying the gas. Standards like EIP-2612 (permit) and Uniswap’s Permit2 built legitimate UX on this: sign gaslessly, the dapp executes. The legitimate mechanism and the attack vector are the same thing — the signature authorizes a transfer of your tokens without you ever broadcasting a transaction, and nothing on-chain exists to warn you until the moment it executes.

Why it’s worse than a normal approval scam

Three properties make ice phishing the technically nastier variant. First, invisibility: a normal approval transaction shows up in your wallet history as a sent transaction; a permit signature shows up as nothing — just “you signed a message”, which thousands of legitimate dapps also request for harmless login (“Sign-In with Ethereum”). The dangerous signature and the benign one look nearly identical in wallet UIs that render them as indistinguishable “signature request” prompts.

Second, dormancy: the signature sits valid until its deadline — the attacker collects it, waits, and executes when the balance is worth taking or when you’ve forgotten the click. Third, detachment: the signature doesn’t require the site that requested it to execute it — the kit can collect signatures from a thousand victims and execute them all later from a different surface entirely.

What the attack actually looks like

The lures are the usual family — fake airdrop claims, verification pages, mint sites, compromised real sites — but the request is the payload: a signature prompt the site frames as “sign to verify eligibility”, “gasless claim — just sign”, or “confirm wallet ownership”. The wallet shows a typed-data signature (EIP-712) — to a user it renders as a wall of fields; the fields encode a Permit/Permit2 approval for a specific token, amount (often max), and deadline. Wallets that decode it show “Permit: approve [contract] to spend [amount]”; wallets that don’t show hex. The scam lives in the gap between those two renderings.

The honest asterisk: the standard is also the fix’s substrate

The part that makes this defensible rather than hopeless: EIP-712 typed data is structured — the fields are machine-readable, so a wallet CAN decode exactly what a signature grants, and the good ones increasingly do (showing “approving spender X for amount Y on token Z” rather than raw hex). The defense tooling is a race in progress, not a lost cause — Permit2 approvals are also revocable through the same audit surfaces as normal approvals. What’s unrecoverable is the pre-decode period: any signature given while your wallet rendered it as an undifferentiated blob is a grant you made blind.

How to spot it and what to do

The identification rule is blunt but complete: any “sign to” request from a site you didn’t navigate to yourself and wouldn’t wire money through is hostile — the cost of refusing a legitimate gasless claim is missing an airdrop; the cost of a wrong signature is the wallet. In wallet UIs that decode typed data, look for spender addresses that aren’t the site’s known contract and amounts set to max. In UIs that don’t decode, treat an unreadable signature request from an untrusted site as an automatic decline — you cannot audit what you cannot read, so the only correct answer is no.

Post-incident: permit signatures and Permit2 grants are revocable on the same audit surfaces as standard approvals (revoke.cash covers Permit2 where the spender standard supports it). Revoking kills the dormant grant before it executes — the signature is only dangerous until you invalidate the allowance it created or would create.

The Permit2 wrinkle, precisely

Uniswap's Permit2 deserves specific attention because it changed the attack surface's shape. The classic permit (EIP-2612) is per-token: a signature approves one token for one spender. Permit2 is a shared intermediary: you approve the Permit2 contract once per token (a normal on-chain approval), and thereafter off-chain signatures can grant allowances to arbitrary spenders within that approval. For users it's one approval for all permit-enabled apps; for attackers it means a wallet that has EVER used Permit2 carries a standing approval the malicious signature can hook into — the sig doesn't create the allowance from zero, it redirects an existing one.

Practical consequence: the wallet that has used Permit2 for legitimate swaps is exactly the wallet an ice-phishing signature can drain — the exposure isn't theoretical or exotic, it's the default state of an active DeFi wallet. Audit tools that show Permit2 allowances (and let you revoke the Permit2 approval itself) are the corresponding hygiene.

Why blocklists can't carry this one

The deeper reason this attack class persists: the malicious artifact is a signature, not a domain or contract — and signatures have no reputation surface to blocklist. The fake site can be flagged, the drainer contract can be flagged, but the collected signature is a portable capability valid anywhere until expiry. Kits rotate collection surfaces precisely because the payload doesn't depend on the surface.

That shifts the defense permanently user-side: the only choke point is the moment of signing. Wallet-side decoding of typed data (showing the spender, amount, and deadline in human terms) is the industry's answer-in-progress — but until every wallet renders every signature request fully decoded, the user-facing rule remains the whole defense: a signature request you can't read, from a page you didn't seek out, is a decline.

The verdict, precisely

Ice phishing is the approval scam stripped of its only visible trace: a signature that authorizes theft without a transaction, valid dormant, executed on the attacker’s schedule. The defense is the same discipline as every signature attack, made stricter by the invisibility — refuse signature requests from untrusted pages on sight, because a signature you can’t read is a signature you already gave.

Frequently asked