Phishing Attacks

Web3 Phishing Attacks: Detection and Defense

Web3 phishing attacks target the person approving a transaction rather than a flaw in contract code. A malicious signature can grant an attacker permission to transfer tokens or NFTs without exposing the victim's private key.

This guide explains approval phishing, wallet drainers, address poisoning, and frontend compromise. It also shows the transaction patterns users and auditors should examine before signing.

What Exactly is a Web3 Phishing Attack?

Traditional Web2 phishing often tries to steal credentials. A Web3 phishing attack instead tricks a user into signing a malicious blockchain transaction or off-chain message. That signature may grant explicit permission to transfer ERC-20 tokens, NFTs, or other assets.

Because Web3 applications rely on cryptographic signatures and smart contract approval mechanisms, an attacker may not need the private key. A valid approval signature can be enough.

The Restaurant Bill Analogy

Imagine signing a restaurant bill that contains an additional clause authorizing access to your bank account. The signature is valid, but its scope is much broader than expected.

That is the central problem in approval phishing. The user expects to authorize a routine action, such as verifying a wallet or claiming an airdrop, but instead approves access to assets.

The Impact of Web3 Phishing

Reported incidents show that phishing is a significant source of losses in the crypto ecosystem:

Published incident datasets put 2024 phishing losses at $1.05 billion across 296 incidents. That is close to half of all Web3 funds reported stolen that year.

The $55M DAI Phishing Incident

On August 21, 2024, an experienced crypto holder lost $55.47 million in DAI after signing a malicious transaction. The case shows that experience alone does not protect a signer when the transaction's effect is unclear.

What Happened

The victim, identified on-chain as 0xf2B8..., unknowingly signed a setOwner transaction on a DeFi Saver Proxy contract. The call transferred control of a highly collateralized Maker vault to the phishing address.

The campaign used Inferno Drainer, a phishing-as-a-service toolkit used to create sites that imitate legitimate DeFi interfaces.

Subsequent Transactions

After taking ownership of the Maker vault, the attacker:

1. Hijacked the protocol by switching the owner address to their own.

2. Minted 55,473,618 DAI directly into their wallet.

3. Swapped 27.5 million of that DAI for 10,625 ETH to start obfuscating the trail.

4. Routed the remaining funds across dozens of mixer addresses.

Calls that change ownership deserve explicit review. Published 2024 hack datasets attribute 31.9% of reported crypto hacks to a setOwner call.

Why the Attack Worked

The attack followed a common sequence:

• Clicked a malicious link disguised as a standard DeFi interface.

• Confirmed a prompt in their wallet, assuming it was a routine connection signature.

• Did not identify that the transaction called setOwner.

• Had no transaction simulation warning before approval.

That single signature accounted for more than 11% of the year's reported wallet-drainer losses.

Types of Web3 Phishing Attacks

Web3 phishing comes in several distinct forms, each exploiting different mechanisms:

Another technique is frontend hijacking, where attackers compromise a protocol's real website or deployment infrastructure and serve malicious transactions to users. The $1.5B Bybit incident and the $120M BadgerDAO attack both involved compromised trusted interfaces or infrastructure.

How Approval Phishing Works: Step-by-Step

Approval phishing (often called "ice phishing," a term Microsoft coined in 2022) exploits the same token approval system that makes DeFi work. Nothing in the attack is a code bug, which is why reading the calldata is the only reliable defense.

Why do token approvals even exist?

Many decentralized exchanges, lending protocols, and NFT marketplaces require users to approve a smart contract before it can spend their tokens. Unlike native ETH transfers, ERC-20 integrations commonly use allowances so another contract can call transferFrom().

The risk is that an attacker can substitute a malicious spender address for the legitimate protocol the user intended to approve.

The Classic Attack Flow

The 4 Phases of an Ice Phishing Attack

A typical approval phishing attack follows four steps:

The "Big Three" Functions Attackers Target

Three functions carry almost all of the losses:

{
  "title": "🎬 Approval phishing: one signature, drained later",
  "stage": { "width": 920, "height": 440 },
  "nodes": [
    { "id": "victim", "label": "Victim", "role": "wallet: 50k USDC", "emoji": "🧑", "x": 60, "y": 200, "color": "cyan" },
    { "id": "token", "label": "USDC Token", "role": "approve / transferFrom", "emoji": "🪙", "x": 440, "y": 60, "color": "purple" },
    { "id": "attacker", "label": "Attacker", "role": "malicious spender", "emoji": "🎣", "x": 720, "y": 200, "color": "red" }
  ],
  "links": [
    { "from": "victim", "to": "token" },
    { "from": "attacker", "to": "token" },
    { "from": "token", "to": "attacker" }
  ],
  "nets": [
    { "id": "victim", "label": "Victim wallet" },
    { "id": "atk", "label": "Attacker" }
  ],
  "legend": [
    { "cls": "call", "label": "contract call" },
    { "cls": "token", "label": "token transfer" },
    { "cls": "sig", "label": "approval / signature" },
    { "cls": "fail", "label": "rejected / blocked" }
  ],
  "scenarios": {
    "Vulnerable (blind unlimited approve)": [
      { "note": "Victim holds 50,000 USDC. A pixel-perfect phishing site prompts what looks like a routine 'connect' signature.", "hi": ["victim"], "bal": { "victim": "50,000 USDC" }, "net": { "victim": "50,000", "atk": "0" } },
      { "note": "It is actually <b>approve(attacker, unlimited)</b>. The victim signs without reading the fine print.", "tone": "bad", "hi": ["victim","token"], "chip": { "from": "victim", "to": "token", "label": "✍️ approve(attacker, ∞)", "cls": "sig" } },
      { "note": "The token's allowance ledger now lets the attacker move <b>all</b> of the victim's USDC - forever, until revoked.", "tone": "bad", "hi": ["token"], "bal": { "token": "allowance: ∞" } },
      { "note": "Hours later, the attacker calls <b>transferFrom(victim, attacker, 50k)</b>. No new victim signature needed.", "tone": "bad", "hi": ["attacker","token"], "chip": { "from": "attacker", "to": "token", "label": "📞 transferFrom(50k)", "cls": "call" } },
      { "note": "The token moves every approved USDC to the attacker. The wallet is drained from a single past click.", "tone": "bad", "hi": ["token","attacker"], "chip": { "from": "token", "to": "attacker", "label": "💸 50,000 USDC", "cls": "token" }, "bal": { "victim": "0 USDC", "attacker": "+50k" }, "net": { "victim": "0", "atk": "+50,000" } }
    ],
    "Fixed (scoped approval + simulation)": [
      { "note": "Same lure - but the victim's wallet runs a transaction simulator that decodes the prompt before signing.", "hi": ["victim"], "bal": { "victim": "50,000 USDC" }, "net": { "victim": "50,000", "atk": "0" } },
      { "note": "It flags it: 'this grants UNLIMITED spend to an unknown address.' The victim rejects.", "tone": "ok", "hi": ["victim","token"], "chip": { "from": "victim", "to": "token", "label": "⛔ approve rejected", "cls": "fail" } },
      { "note": "For real use, the victim approves only the <b>exact amount</b> needed (or uses Permit2 with an expiry), never unlimited.", "tone": "ok", "hi": ["victim","token"], "chip": { "from": "victim", "to": "token", "label": "✍️ approve(dapp, 100)", "cls": "sig" }, "bal": { "token": "allowance: 100" } },
      { "note": "With no standing unlimited allowance, a phishing spender has nothing to drain.", "tone": "ok", "hi": ["victim"], "bal": { "victim": "50,000 USDC safe" }, "net": { "victim": "50,000", "atk": "0" } }
    ]
  }
}

Why Unlimited Approvals Increase Risk

The standard ERC-20 approval mechanism creates persistent authority that phishing campaigns can exploit.

The flaw is not in the token code. It sits in the habit, encouraged by most frontends, of granting permanent unlimited approvals.

The Risky Pattern in Action

// VULNERABLE PATTERN - DO NOT USE IN PRODUCTION
// This shows how unlimited approvals enable phishing attacks

contract VulnerableToken is ERC20 {
    // Standard ERC-20 approve - allows UNLIMITED approvals
    function approve(address spender, uint256 amount) public override returns (bool) {
        // No limit on amount - can be type(uint256).max
        // No expiration - approval lasts FOREVER
        // No notification - user may forget about this approval
        _approve(msg.sender, spender, amount);
        return true;
    }

    // A DeFi frontend typically requests:
    // approve(contractAddress, type(uint256).max)
    // This grants PERMANENT, UNLIMITED access to your tokens
}

// When a phishing site calls:
// token.approve(ATTACKER_ADDRESS, type(uint256).max)
// The attacker can drain ALL your tokens at ANY time

Why is this dangerous?

Four properties of the approval model do the damage:

1. Approvals default to unlimited amounts (type(uint256).max)

2. Approvals have no expiration - they last forever

3. Users can't easily see or manage active approvals

4. A single approval grants access to all tokens of that type

In March 2024 alone, ERC-20 tokens accounted for 89.5% of the $71.5 million lost to phishing that month.

Phishing Attacker Contract Example

Here's how an attacker exploits approvals they've obtained through phishing.

// ATTACKER CONTRACT - Educational purposes only
// Demonstrates how phishing-obtained approvals are exploited

contract PhishingDrainer {
    address public attacker;

    constructor() {
        attacker = msg.sender;
    }

    // After tricking a victim into calling:
    // token.approve(address(this), type(uint256).max)
    // The attacker can drain all their tokens:

    function drainERC20(
        IERC20 token,
        address victim,
        uint256 amount
    ) external {
        require(msg.sender == attacker, "Not attacker");

        // This works because the victim already approved this contract
        token.transferFrom(victim, attacker, amount);
    }

    // For NFTs, after victim calls:
    // nft.setApprovalForAll(address(this), true)
    function drainNFT(
        IERC721 nft,
        address victim,
        uint256 tokenId
    ) external {
        require(msg.sender == attacker, "Not attacker");

        // Transfer NFT from victim to attacker
        nft.safeTransferFrom(victim, attacker, tokenId);
    }

    // Advanced: Drain multiple tokens in a single transaction
    function drainMultiple(
        address victim,
        IERC20[] calldata tokens,
        uint256[] calldata amounts
    ) external {
        require(msg.sender == attacker, "Not attacker");

        for (uint i = 0; i < tokens.length; i++) {
            uint256 balance = tokens[i].balanceOf(victim);
            uint256 amount = amounts[i] < balance ? amounts[i] : balance;
            tokens[i].transferFrom(victim, attacker, amount);
        }
    }
}

Attack Execution Summary

1. Deploy the drainer contract (or use a drainer-as-a-service kit)

2. Lure victims to a fake site mimicking a legitimate protocol

3. Request approval - the wallet popup asks to approve the drainer contract

4. Wait - the approval persists indefinitely

5. Call drainERC20() or drainNFT() to steal all approved assets

Modern wallet drainers like Inferno Drainer automate the whole flow. The kit scans the connected wallet for valuable assets and builds the drain transaction itself.

How to Prevent Phishing Attacks: Best Practices

Reducing phishing risk requires controls across contract permissions, application infrastructure, wallet interfaces, and user signing practices.

Phishing-Resistant Approvals in Smart Contracts

As developers, we have a responsibility to protect our users. Here is how smart contracts can and should be designed to severely minimize phishing risks using modern safety patterns.

// SECURE CONTRACT - Phishing-resistant token approval pattern
// Uses expiring approvals and amount limits

contract PhishingResistantToken is ERC20 {
    // IMPROVEMENT 1: Approval expiration
    struct Approval {
        uint256 amount;
        uint256 expiry;
    }

    mapping(address => mapping(address => Approval)) private _timedAllowances;

    event ApprovalWithExpiry(
        address indexed owner,
        address indexed spender,
        uint256 amount,
        uint256 expiry
    );

    // STEP 1: CHECKS - Validate the approval parameters
    function approveWithExpiry(
        address spender,
        uint256 amount,
        uint256 duration
    ) public returns (bool) {
        require(spender != address(0), "Invalid spender");
        require(amount > 0, "Amount must be positive");
        require(duration <= 30 days, "Max approval: 30 days");

        // STEP 2: EFFECTS - Store approval with expiration
        uint256 expiry = block.timestamp + duration;
        _timedAllowances[msg.sender][spender] = Approval({
            amount: amount,
            expiry: expiry
        });

        emit ApprovalWithExpiry(msg.sender, spender, amount, expiry);
        return true;
    }

    // Override transferFrom to check expiration
    function transferFrom(
        address from,
        address to,
        uint256 amount
    ) public override returns (bool) {
        Approval storage approval = _timedAllowances[from][msg.sender];

        // STEP 1: CHECK - Is the approval still valid?
        require(block.timestamp <= approval.expiry, "Approval expired");
        require(approval.amount >= amount, "Insufficient allowance");

        // STEP 2: EFFECTS - Decrease the allowance
        approval.amount -= amount;

        // STEP 3: INTERACTIONS - Execute the transfer
        _transfer(from, to, amount);
        return true;
    }
}

Security Features

Uniswap's Permit2 implements expiring approvals. Its AllowanceTransfer contract stores a uint48 expiration with each user approval, while SignatureTransfer supports one-time signatures that cannot be reused after consumption.

Advanced Phishing Variations

Phishing techniques change as wallet interfaces and approval standards evolve. The following variants require different checks from a standard on-chain approve() call.

1. Off-Chain Permit Signature Phishing

One approval-phishing variant uses EIP-2612 permit() to obtain approval through an off-chain signature. The victim pays no gas and submits no on-chain transaction; the attacker can relay the signed message later.

How it works:

1. You are prompted to "verify" your wallet by signing what looks like a harmless message.

2. The structured message contains the token address, spender, approved amount, deadline, and nonce.

3. The attacker takes your raw signature and submits it on-chain via the permit() function.

4. With a valid approval, the attacker calls transferFrom() to move the approved tokens.

This variant is easy to miss. Because the victim signed a message rather than a transaction, the approval does not initially appear in on-chain history, and some wallet interfaces have historically shown very little detail for these signatures.

The largest single phishing theft of 2025 was $6.5 million in September, caused directly by a malicious Permit signature.

2. Address Poisoning

Address poisoning targets a habit almost everyone in crypto has: copy-pasting addresses directly from their transaction history.

Attack sequence:

1. The attacker generates a "vanity" wallet address that matches the first 4-6 and last 4-6 characters of an address you frequently use.

2. They send you a tiny amount of tokens, or a zero-value transaction, from that lookalike address.

3. The lookalike address now sits in your recent transaction history on block explorers and wallet interfaces.

4. You copy the address from history and send funds to the attacker.

Real incidents:

• December 2025: A trader lost $50M in USDT after copying a poisoned address. Binance's CZ later pushed for wallet-level poison address blocking.

• May 2024: A victim lost $71M in WBTC but recovered funds after negotiating with the attacker.

• November 2023: Florence Finance lost $1.45M USDC to the same technique.

Published address-poisoning research counts over 270 million attempts across Ethereum and BNB Chain, and $83 million in confirmed losses.

3. Frontend Hijacking

Some phishing campaigns never build a fake site at all. They compromise the protocol's real one.

4. Wallet Drainer-as-a-Service (DaaS)

Some Web3 phishing operations use commercial drainer-as-a-service kits. Operators distribute subscription tools through private forums or messaging channels and may provide interface updates, support, and automated revenue sharing.

Examples of drainer services:

In Q1 2024, three kits (Angel, Pink, and Inferno) accounted for 92% of drainer activity. Pink exited later that year, and Acedrainer took roughly 20% of the market within a single quarter.

Common Phishing Misconceptions

Several common security assumptions do not account for approvals, off-chain signatures, or compromised frontends:

Related Web3 Vulnerabilities

Phishing attacks often overlap with permission and external-call risks:

• Access Control Attacks: Both involve unauthorized permission grants, whether caused by a code flaw or social engineering.

• Call Attacks: Drainers rely on external calls and token transfer functions after obtaining approval.

• Flash Loan Attacks: An attacker may combine obtained permissions with borrowed liquidity to manipulate a victim's DeFi positions.

Test your Web3 phishing IQ

Frequently Asked Questions (FAQ): Web3 Phishing

Anti-Phishing Checklist

Use the relevant checklist for wallet activity or protocol development:

For Everyday Web3 Users

• Install a transaction simulation tool (Pocket Universe, Fire, or Blowfish)

• Use a hardware wallet for significant holdings

• Never approve unlimited token amounts - edit to exact amounts needed

• Regularly check and revoke unused approvals via Revoke.cash

• Verify the full address when sending transactions - not just first/last characters

• Never sign messages or transactions from links in Discord, Twitter, or email

• Use separate wallets: hot wallet for DeFi, cold wallet for storage

• Send a small test transaction before large transfers to new addresses

• Bookmark DeFi sites - never click links from search ads or social media

For Protocol Developers & Smart Contract Auditors

• Implement expiring approvals in token contracts (like Permit2)

• Request exact approval amounts in your frontend, not type(uint256).max

• Add Content Security Policy headers to prevent script injection

• Use Subresource Integrity (SRI) for all external scripts

• Implement transaction preview/simulation in your dApp UI

• Display clear, human-readable approval details to users

• Monitor for unauthorized changes to your frontend deployment

• Secure CI/CD pipelines and cloud credentials with hardware keys

Practice Phishing Analysis

Reading transaction details is useful, but security review also requires practice tracing approvals and testing their limits in a controlled environment.

The Smart Contract Hacking course includes:

• 320+ video lessons covering approval exploitation, signature phishing, flash loan attacks, reentrancy, and related topics.

• 40+ hands-on exercises for exploiting and securing vulnerable contracts.

• Instruction from JohnnyTime, Trust, Pashov, and other working security researchers.

• A 2,000+ member Discord community for technical discussion and peer support.

• SSCH Certification for participants who complete the requirements.

You can review student outcomes and success stories before deciding whether the course fits your goals.

View the course curriculum and enrollment options