Sitemap

Understanding EIP-7702 Phishing Attacks: A Comprehensive Guide to Protection Strategies for Wallets

6 min readJun 3, 2025

--

EIP-7702 introduces smart contract-like functionality to externally owned addresses, significantly expanding their capabilities and flexibility. As more applications leverage this technology, it plays an increasingly vital role in Web3 adoption and user experience enhancement.

However, cybercriminals are exploiting both the powerful features of EIP-7702 and users’ limited understanding of this emerging technology. We have recently documented cases where attackers, particularly the #InfernoDrainer group, leveraged Metamask’s 7702 batch execution feature to consolidate what would typically require multiple authorization steps into a single malicious transaction, resulting in significant asset losses.

Disclaimer: This security concern does not reflect any inherent vulnerability in Metamask itself. The wallet provider has implemented robust security measures and maintains a security-first approach when enabling 7702 functionality. The key to prevention lies in educating users about EIP-7702’s capabilities and potential risks to mitigate future security incidents.

I. Metamask 7702 Delegator Authorization Mechanism and Security Architecture

1. Technical Analysis

  • Authorization Process: Users authorize a deployed Delegator Contract, redirecting their account’s code field to that contract. Current MetaMask official Delegator Contract address: 0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B
  • Authorization Structure: (chainId, delegatorAddress, nonce, signature) written to authorization_list
  • Signing Mechanism: MetaMask employs unified signing logic for EIP-7702 authorizations via the signEIP7702Authorization method. It performs ECDSA signing on the authorization digest digest7702 = keccak256(0x05 ‖ RLP(chainId, delegator, nonce)), generating (v, r, s) signature structure attached to subsequent Type-4 transactions for account authorization and upgrades. Implementation reference: https://github.com/MetaMask/eth-sig-util/blob/main/src/sign-eip7702-authorization.ts
  • Verification Process: Consensus layer validates through ecrecover(digest7702, sig) == tx.from
  • Security Design: Web applications cannot trick users into authorizing arbitrary Delegators since signEIP7702Authorization is exclusively implemented within MetaMask’s internal architecture and not exposed to web interfaces via window.ethereum. Web-accessible signing methods like eth_signTypedData_v4 are incompatible with EIP-7702 authorization signatures due to different digest formats:
digest712 = keccak256(
"\x19\x01" ‖ domainSeparator ‖ keccak256(encodeStruct(primaryType, message))
)
  • And the signature format required by EIP-7702 specification is:
digest7702 = keccak256(
0x05 ‖ RLP(chainId, delegator, nonce)
)

Since eth_signTypedData_v4 includes a fixed 0x1901 prefix with completely different digest computation, it’s virtually impossible to construct domainSeparator, primaryType, and message values that would result in digest712 == digest7702.

Therefore, web applications cannot forge legitimate EIP-7702 authorization signatures through this method. Additionally, MetaMask implements a whitelist mechanism for Delegator addresses, exclusively permitting authorization of the official Delegator (0x63c0…32B) by default and preventing DApps from injecting custom addresses, further protecting users from malicious Delegator authorization attempts.

2. Usage Methods

MetaMask currently offers two approaches for upgrading existing EOAs to EIP-7702 Smart Accounts: Active Upgrade and Passive Upgrade.

Active Upgrade occurs when users manually click the “Switch” button in the wallet interface to authorize a specific Delegator Contract.

Passive Upgrade is triggered when users interact with EIP-7702-compatible DApps, prompting MetaMask to automatically display upgrade suggestions upon detecting relevant operations.

2.1 Active Upgrade:

  • Transaction Content: Contains solely the account upgrade action, authorizing a specific Delegator Contract
  • Upgrade Process: Navigate to the wallet’s account details interface and click the switch button to upgrade the user account to a Smart Account on Ethereum Mainnet. After clicking switch, a signature window appears for the current upgrade transaction:
  • Authorization Record: Upon confirmation, the transaction is submitted for on-chain processing. Successful mining indicates the user has successfully upgraded to a Smart Account. Users can verify the specific authorization transaction details by visiting their wallet address on Etherscan and checking the “Authorizations (EIP-7702)” section.

2.2 Passive Upgrade

  • Transaction Content: Includes both the account upgrade action and batch interactions with on-chain contracts
  • Upgrade Process: When users interact with certain DApps, MetaMask proactively suggests completing the current transaction through Smart Account upgrade for batch execution. For example, when performing token swaps on Uniswap, clicking the “Use smart account” button upgrades to a Smart Account, allowing token approval and swap operations to be completed within a single batched transaction.

2.3 Reverting to Regular EOA

Regardless of whether the account was converted to a Smart Account through active or passive upgrade methods, the bound Delegator Contract address is permanently stored on-chain as the account’s current execution logic.

If users wish to restore their account to a regular EOA, they need to manually initiate a “Switch back to EOA” operation. The essence of this operation is: submitting an EIP-7702 authorization with address(0) as the new Delegator contract address. When this transaction is successfully mined, the account’s code field will be cleared, execution logic will revert to the default empty code, and the account will return to regular EOA status.

Navigate to the wallet’s account details interface and click the switch button to revert the user account back to a regular EOA on Ethereum Mainnet.

After clicking confirm, wait for the transaction to be mined. Successful on-chain execution means the user has successfully switched from Smart Account back to regular EOA. The specific transaction information can also be found on the current wallet address page on Etherscan.

II. EIP-7702 Phishing Attack Case Study

On May 24th, the #InfernoDrainer phishing group exploited MetaMask’s 7702-Delegator contract batch execution functionality to fraudulently obtain token approvals from user (0xc6D2…06DC) and execute a phishing attack, resulting in losses exceeding $146,000 worth of $HashAI $HUMANS $ParallelAI $NeuralAI $DSync $Zero1 $NodeAI $Sensay $Virtual tokens.

Fraudulent Addresses:

0x0000db5c8B030ae20308ac975898E09741e70000

0x00008C22F9F6f3101533f520e229BbB54Be90000

0xa85d90B8Febc092E11E75Bf8F93a7090E2ed04DE

0xC83De81A2aa92640D8d68ddf3Fc6b4B853D77359

0x33dAD2bbb03Dca73a3d92FC2413A1F8D09c34181

Phishing Transaction Example:

https://etherscan.io/tx/0x09c264618e93983510aaeb7aa2c91c8254a8b2ec66167438f3f6c28b866b6eba

Root Cause of Phishing:

The user (0xc6D2…06DC) executed a malicious batch authorization transaction:

https://etherscan.io/tx/0x1ddc8cecbcaad5396fdf59ff8cddd8edd15f82f1e26779e581b7a4785a5f5e06

#InfernoDrainer and #PinkDrainer are experimenting with more covert and impactful EIP-7702 based phishing criminal networks.

According to our research, the phishing criminal groups #InfernoDrainer and #PinkDrainer are currently researching and experimenting with more covert and impactful EIP-7702 based phishing criminal networks. The relevant addresses are as follows, and we will release more detailed reports subsequently:

Inferno Drainer:

0x0000db5c8B030ae20308ac975898E09741e70000

Pink Drainer:

0xe49e04F40C272F405eCB9a668a73EEAD4b3B5624

III. Security Recommendations

For Wallet Providers:

  • Reference MetaMask’s implementation and security management of 7702 Delegator, prohibit users from authorizing arbitrary Delegators, and only allow in-app operations. Remind users that any behavior requesting signature authorization through web pages constitutes a phishing attack.
  • Check if the chain matches the current network and warn users of replay risks when signing with chainID 0.
  • Display the target contract when users sign authorization, and show specific function call details when users perform batch execution through Delegator, reducing the risk of phishing attacks.

For Users:

  • Private key protection remains paramount. Not your keys, not your coins.
  • Do not authorize Delegators based on any independent web pages. Secure authorization typically occurs only within applications like MetaMask.
  • When using any wallet for signing, carefully review the signature content to avoid blind signing or erroneous signing.

--

--

GoPlus Security
GoPlus Security

Written by GoPlus Security

Empowering a #SaferWeb3 with user-driven, open access security solutions. Championing user education for a fortified front against adversaries.

No responses yet