Worked example · 2024-20

Uniswap Permit2 Phishing Cohort — Ethereum / multi-chain EVM — 2024–2025

Loss: no single consolidated dollar figure at v0.1 — the cohort spans thousands of individual victims across hundreds of phishing domains. ScamSniffer reported approximately $38M in Permit2-signature-based phishing losses across the broader Web3 phishing ecosystem in 2024; the Uniswap Permit2 phishing sub-cohort represents a material fraction of this total. Per-incident losses range from low-four-figure individual wallet drains to six-figure single-victim extractions. The cohort's structural feature is the Permit2 signature as the extraction primitive — a single off-chain signature authorises the attacker's contract to spend the user's tokens, and the signature is solicited under the guise of a legitimate Uniswap interaction.
Recovery: largely unrecovered. Permit2 authorisations are revocable (via the Permit2 contract's allowance invalidation), but by the time the user realises the signature was fraudulent, the attacker's drain transaction has typically already been submitted and confirmed — the Permit2 signature authorises immediate spending, and the attacker drains the wallet in the same transaction or within seconds of receiving the signature. Victim-side recovery is limited to cases where the user revoked the Permit2 authorisation before the attacker's drain transaction was mined (rare — requires the user to detect the phishing in real time and submit a competing revocation transaction with higher gas).
OAK Techniques observed: OAK-T6.008 (Verified-but-Malicious Frontend Routing — the phishing frontend presents legitimate Uniswap branding and displays a "Claim UNI Airdrop" or "Migrate Liquidity" or "Approve Permit2" UI that appears to be the real Uniswap interface; the frontend is structurally an attacker-operated UI that interacts with the real Permit2 contract, and the user's wallet confirmation screen shows the verified Permit2 contract address). OAK-T4.001 (Permit2 Authority Misuse / Permit Phishing — the Permit2 signature authorises the attacker's contract to spend the user's tokens; the signature is solicited under false pretences through a frontend that impersonates a legitimate protocol interaction). OAK-T4.002 (Compromised Frontend Permit Solicitation — contextually adjacent: the phishing frontend is attacker-operated (not a compromised legitimate frontend), but the Permit2 solicitation pattern — a signature that authorises token spending, presented as a routine protocol interaction — is structurally identical to compromised-frontend permit solicitation).
Attribution: pseudonymous The Permit2 phishing domains are operated by distinct pseudonymous actors who license drainer kits from drainer-as-a-service operators. The Angel Drainer group (OAK-G03-adjacent) is the dominant drainer-kit supplier for Permit2 phishing domains in 2024; Inferno Drainer and Pink Drainer are secondary suppliers. The per-domain operators are typically not publicly identified; the drainer-kit fingerprint (on-chain drainer-contract address, signature-request format, off-ramp exchange addresses) provides operator-cluster-level attribution. SEAL ISAC, ScamSniffer, and ZachXBT maintain the canonical phishing-domain blocklists.
Key teaching point: The Permit2 signature is a token-approval primitive disguised as a protocol-interaction signature — the user's wallet confirmation screen shows a Permit2 contract address that is genuine and verified, and the signature-request UI displays a legitimate-looking interaction label ("Claim UNI," "Migrate Liquidity," "Connect Wallet"), but the signature's effect is a blanket token-spending authorisation to an attacker-controlled address. The structural OAK lesson for T6.008 is that the contract address the user inspects is not the locus of trust when the extraction primitive is an off-chain signature rather than an on-chain transaction to a malicious contract. The Permit2 signature is solicited by the phishing frontend, signed by the user's wallet, and submitted on-chain by the attacker — the user never sends a transaction to a malicious contract address, and the wallet confirmation screen's contract-address check is therefore irrelevant. The defender lesson is that wallet UIs must surface Permit2 signature requests with the same friction and clarity as on-chain token-approval transactions, including the spender address, the token, and the amount — and must not collapse Permit2 signatures into generic "Sign Message" prompts.

Summary

Uniswap Permit2 is a token-approval contract deployed by Uniswap Labs that allows users to grant token-spending authorisations via off-chain signatures rather than on-chain approve transactions. The Permit2 contract (0x000000000022D473030F116dDEE9F6B43aC78BA3) is deployed at a canonical address on Ethereum mainnet and across multiple EVM chains. A Permit2 signature — an EIP-712 typed-data signature solicited by a dApp and signed by the user's wallet — authorises a specified spender to transfer a specified amount of a specified token from the user's wallet, for a specified duration. The signature is submitted on-chain by the spender (not by the user) to the Permit2 contract, which validates the signature and records the allowance. The attacker can then call transferFrom on the Permit2 contract to drain the authorised tokens to an attacker-controlled address.

The Permit2 architecture was designed to improve UX — eliminating the need for a separate on-chain approve transaction before every token interaction — but it creates a phishing surface that is structurally more dangerous than the legacy approve pattern. In the legacy pattern, the user must submit an on-chain approve transaction to a token contract; the wallet UI shows the spender address, the token, and the amount; the user can inspect the transaction before signing. In the Permit2 pattern, the user signs an off-chain EIP-712 signature; the wallet UI may show a generic "Sign Message" prompt with a hex-encoded payload that the user cannot parse; and the spender address is embedded in the typed-data structure, not in a human-readable transaction confirmation. The Permit2 phishing cohort exploits this UX gap — the attacker's phishing frontend presents a legitimate-looking UI ("Claim UNI Airdrop," "Migrate Liquidity to V4," "Approve Permit2 for Swap"), the wallet prompts the user to sign a Permit2 signature, and the user approves the signature without reading the typed-data payload that authorises the attacker's contract.

The phishing domains are structurally T6.008: they present legitimate Uniswap branding, they interact with the real Permit2 contract at its canonical address, and the user's wallet confirmation screen shows the real Permit2 contract address. The user's mental model is "I am interacting with Uniswap through the real Permit2 contract" — and that mental model is satisfied by the wallet confirmation screen. The extraction occurs through the Permit2 signature's spender-authorisation field, which the user did not inspect. The phishing frontend is attacker-operated (not a compromised legitimate frontend), but the T4.002 framing (compromised-frontend permit solicitation) is contextually adjacent because the signature-solicitation pattern — a Permit2 signature presented as a routine protocol interaction — is identical regardless of whether the frontend is compromised or attacker-operated.

The cohort's structural significance for T6.008 is that it is the most active and highest-loss-per-year Verification-Evasion phishing vector in the 2024–2025 window. The Permit2 signature bypasses the wallet's contract-address verification — the contract address is correct, and the verification check passes. The extraction primitive is the Permit2 signature, not a malicious contract the user sends a transaction to. T6.008 captures this exact gap: verified-but-malicious frontend routing where the "routing" in this case is the Permit2 signature's spender-authorisation routing — the user signs a signature that routes token-spending authority to an attacker-controlled address, through a frontend that presents legitimate Uniswap branding and interacts with the real Permit2 contract.

Timeline (cohort-scale)

When	Event	OAK ref
2023-01	Uniswap Labs deploys Permit2 contract at canonical address on Ethereum mainnet; Permit2 is marketed as a UX improvement — gasless token approvals via off-chain signatures — and is rapidly adopted across the Uniswap ecosystem and by third-party dApps	(Permit2 deployment)
2023–2024	Permit2 phishing domains begin appearing; early domains use generic "Claim Airdrop" narratives; drainer-kit operators (Angel Drainer, Inferno Drainer, Pink Drainer) integrate Permit2 signature-solicitation into their standard phishing kits	T6.008 + T4.001 phishing emergence
2024	Permit2 phishing becomes the dominant Web3 phishing vector by incident volume; ScamSniffer reports ~$38M in Permit2-signature-based phishing losses across the broader ecosystem in 2024	cohort scale established
2024 Q2–Q4	Uniswap-specific Permit2 phishing domains proliferate — "uniswap-claim[.]com," "uniswap-migrate[.]org," "app-uniswap[.]io," and hundreds of typosquat / near-miss domains — all presenting legitimate Uniswap branding and soliciting Permit2 signatures under false pretences	T6.008 + T4.001 active campaign
2024–2025	Wallet vendors (MetaMask, Rabby, Rainbow) begin surfacing Permit2 signature requests with increased friction — parsing the EIP-712 typed-data payload and displaying the spender address, token, and amount in human-readable form	(wallet-side response)
2025	SEAL ISAC and ScamSniffer maintain canonical Permit2 phishing domain blocklists; Angel Drainer remains the dominant drainer-kit supplier for Permit2 phishing domains	(ongoing)
2025 (v0.1 cutoff)	Cohort documented as the third T6.008 example in OAK; Permit2 phishing is the most active Verification-Evasion phishing vector by incident volume and aggregate loss	(OAK characterisation)

Realised extraction

ScamSniffer reported approximately $38M in Permit2-signature-based phishing losses across the broader Web3 ecosystem in 2024; the Uniswap Permit2 phishing sub-cohort represents a material fraction of this total. Per-incident losses range from low-four-figure individual wallet drains (a single Permit2 signature draining a wallet with a few thousand dollars in tokens) to six-figure single-victim extractions (a high-value wallet signing a Permit2 signature that authorises the attacker's contract to drain all held tokens across multiple assets). The extraction is typically a single transaction — the attacker receives the Permit2 signature from the phishing frontend, submits it on-chain to the Permit2 contract, and calls transferFrom to drain the authorised tokens to an attacker-controlled address, all within seconds of the user signing. The Permit2 authorisation can be scoped to a single token and amount (reducing the extraction to the token the user believed they were interacting with) or to the maximum allowance (draining all tokens the user holds across all assets the Permit2 contract supports).

The cohort's structural extraction profile is a Permit2 signature that authorises the attacker's drainer contract to spend the user's tokens, solicited under the guise of a legitimate Uniswap interaction. The extraction is invisible at the wallet confirmation screen — the user sees the real Permit2 contract address and a generic "Sign Message" prompt, and approves. The Permit2 signature's spender-authorisation field — the field that determines which address receives token-spending authority — is embedded in the EIP-712 typed-data payload and is not surfaced in a human-readable form by standard wallet UIs at v0.1.

References

ScamSniffer 2024 Web3 Phishing Report — $38M Permit2-signature-based phishing loss figure; phishing-domain volume and drainer-kit operator attribution.
SEAL ISAC phishing-domain blocklists — canonical Permit2 phishing domain enumeration; Angel Drainer / Inferno Drainer drainer-contract fingerprinting.
ZachXBT per-victim incident threads — high-value individual Permit2 phishing drains; wallet-drain transaction tracing; off-ramp exchange identification.
Uniswap Labs Permit2 documentation — Permit2 contract architecture; EIP-712 signature format; spender-authorisation semantics.
MetaMask / Rabby wallet security advisories — Permit2 signature-request friction improvements; EIP-712 payload human-readable parsing; spender-address display in Permit2 signature prompts.
Web3 Antivirus / Blockaid — Permit2 signature phishing detection at the transaction-simulation layer; domain-reputation integration for Permit2 solicitation domains.
[eip2612permit] — EIP-2612 permit specification (the architectural predecessor to Permit2; the Permit2 phishing surface structurally generalises the EIP-2612 permit phishing surface first documented in the Dai permit phishing cohort).

Public references

See citations in corresponding technique file.

Discussion

The Uniswap Permit2 phishing cohort is structurally important to OAK for two reasons. First, it is the most active and highest-loss-per-year T6.008 (Verified-but-Malicious Frontend Routing) vector in the 2024–2025 window, making it the strongest per-incident anchor for a Technique whose existing examples (SwapKit router impersonator cohort, Uniswap routing-manipulation frontend cohort) are earlier-stage in their per-incident documentation. The Permit2 phishing cohort provides the dollar-scale and incident-volume anchors that support the T6.008 classification at the emerging maturity level, and its structural fingerprint — a verified contract address on the wallet confirmation screen, with the extraction occurring in the calldata or signature payload — is the cleanest operational example of the T6.008 verification-evasion primitive.

Second, the Permit2 phishing cohort demonstrates a T6.008 sub-pattern that is structurally distinct from the routing-manipulation sub-pattern. The routing-manipulation sub-pattern (SwapKit, Uniswap routing-manipulation) embeds the extraction in the transaction's calldata — a swap path through attacker-owned intermediate contracts. The Permit2 phishing sub-pattern embeds the extraction in an off-chain signature — a Permit2 authorisation whose spender field points to an attacker-controlled address. Both sub-patterns share the T6.008 load-bearing property: the contract address the user inspects (Uniswap Universal Router in the routing-manipulation case, Permit2 contract in the phishing case) is genuine and verified; the extraction occurs in a component the wallet UI does not surface to the user at sign-time. The two sub-patterns differ at the extraction layer (calldata manipulation vs signature-authorisation manipulation) but share the same verification-evasion structure and the same defender response (wallet-side transaction/signature decoding that surfaces the full extraction path to the user before signing).

The Permit2-specific OAK lesson is that off-chain signatures that authorise on-chain token spending must be surfaced by wallet UIs with the same friction and clarity as on-chain token-approval transactions. The user's mental model — "I am signing a message to prove ownership, not authorising a token transfer" — is systematically incorrect for Permit2 signatures, and wallet UIs that present Permit2 signatures as generic "Sign Message" prompts are abdicating the defender-side responsibility to translate the signature's effect into user-comprehensible terms. The wallet-vendor response in 2024–2025 — parsing the EIP-712 typed-data payload and displaying the spender address, token, and amount in human-readable form — is the load-bearing mitigation for this sub-pattern, and its deployment lag (Permit2 was deployed in January 2023; human-readable Permit2 signature prompts began appearing in wallet UIs in mid-2024) is itself a recurring OAK observation: a known mitigation whose deployment lags its documentation is a standing vulnerability surface.

The broad OAK cross-classification (T6.008 + T4.001 + T4.002) reflects the structural multi-Technique nature of the Permit2 phishing cohort. T6.008 captures the verification-evasion primitive: the frontend displays legitimate Uniswap branding, the wallet confirmation shows the verified Permit2 contract, and the extraction occurs through the signature's spender-authorisation field. T4.001 captures the Permit2 authority-misuse primitive: the Permit2 signature is a token-spending authorisation solicited under false pretences. T4.002 captures the contextually-adjacent compromised-frontend pattern: although the phishing frontend is attacker-operated rather than compromised, the signature-solicitation pattern is structurally identical to a compromised legitimate frontend soliciting a Permit2 signature. The cross-classification preserves the full structural nuance — a single-Technique classification (T6.008 alone, or T4.001 alone) would miss the multi-layer nature of the exploitation.