When using any wallet for signing, please carefully review the signing content to avoid blind signing or erroneous signing.

EIP-7702 grants addresses capabilities and flexibility similar to smart contracts, and an increasing number of 7702 applications are continuously being created, which is crucial for bringing more people into Web3 and enhancing user experience.

However, the flexibility of 7702 and the current unfamiliarity of most users with 7702 are being exploited by fraud gangs. Recently, we observed that users were phished due to the batch execution capability of Metamask 7702, which allowed interactions that originally required dozens of authorizations to be merged into a single transaction by the phishing gang #InfernoDrainer, resulting in asset theft.

Note: Metamask itself has no security issues. Metamask prioritizes user safety when providing 7702-related capabilities and has implemented many security measures. Users need to understand more about the capabilities and associated risks of 7702 to prevent such security incidents from happening again.

1. Metamask 7702 Delegator Signature Authorization Principles and Security Design

1. Technical Analysis

• Users authorize the already deployed Delegator Contract, pointing the code field of the user account to this contract. The current official MetaMask Delegator Contract address: 0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B

• Authorization structure: (chainId, delegatorAddress, nonce, signature) is written into authorization_list

• Signing method: The underlying logic for EIP-7702 related authorization transactions in Metamask uses a unified signing logic, namely the signEIP7702Authorization method, which performs ECDSA signing on the authorization data digest7702 = keccak256(0x05 ‖ RLP(chainId, delegator, nonce)), generating the (v, r, s) signature structure, which is then attached to the subsequent Type-4 transaction to achieve account authorization and upgrade. For specific implementation, see: https://github.com/MetaMask/eth-sig-util/blob/main/src/sign-eip7702-authorization.ts

• Verification method: The consensus layer verifies through ecrecover(digest7702, sig) == tx.from.

• Security design: The web page cannot induce users to authorize any Delegator because the signEIP7702Authorization method is only implemented within the MetaMask wallet and is not open for calls through window.ethereum on the web page. The signature methods accessible on the web, such as eth_signTypedData_v4, are not applicable for EIP-7702 authorization signatures, and their signature digest format is as follows:

The signature format required by the EIP-7702 specification is:

Since eth_signTypedData_v4 always includes the 0x1901 prefix and the digest calculation process is completely different from 7702, it is almost impossible to make digest712 == digest7702 even with cleverly constructed domainSeparator, primaryType, and message.

Therefore, the web page cannot forge a legitimate 7702 authorization signature through this method. Additionally, MetaMask implements a whitelist mechanism for Delegator addresses, defaulting to only allowing authorization of the official Delegator (0x63c0...32B), prohibiting DApps from injecting addresses, further preventing users from being induced to sign malicious Delegator authorization data.

2. Usage Method

Currently, in Metamask, the way to upgrade an existing EOA to a 7702 smart account (Smart Account) is mainly divided into two categories: active upgrade and passive upgrade.

Active upgrade refers to the user actively clicking the "Switch" button in the wallet interface to authorize a specific Delegator Contract.

Passive upgrade occurs when users interact with certain DApps that support 7702. When Metamask detects relevant operations, it will automatically pop up a prompt suggesting that users complete the upgrade.

2.1 Active Upgrade:

• Transaction content: Only includes the action of upgrading the account, i.e., authorizing a specific Delegator Contract.

• Upgrade process: Enter the account details interface in the wallet, click the switch button in the image below, and the user can upgrade from Ethereum Mainnet to a smart account. After clicking switch, a window will appear for the user to sign the current upgrade transaction:

• Authorization record: After confirmation, wait for the transaction to be on-chain. Successful on-chain means the user has successfully upgraded to a smart account, and specific authorization transaction information can be viewed in the Authorizations (EIP-7702) section on the current wallet address page on etherscan.

2.2 Passive Upgrade

• Transaction content: Includes the action of upgrading the account and batch actions interacting with on-chain contracts.

• Upgrade process: When users interact with certain DApps on-chain, Metamask will actively prompt users that the current transaction can be completed using batch sending by upgrading to a smart account. For example, when swapping certain tokens on Uniswap, clicking the Use smart account button will upgrade to a smart account, and then token authorization and swap will be completed in a single transaction.

2.3 Switching Back to Regular EOA

Regardless of whether the current account is converted to a smart account through active or passive upgrade, the bound Delegator Contract address will be permanently stored on-chain as the current execution logic of the account.

If the user wishes to revert the account to a regular EOA, they need to manually initiate a "switch back to EOA" operation. The essence of this operation is: through an EIP-7702 authorization, submit address(0) as the new Delegator contract address. Once this transaction is successfully on-chain, the code field of the account will be cleared, and the execution logic will revert to the default empty code, returning the account to a regular EOA state.

Enter the account details interface in the wallet, click the switch button, and the user can switch back to a regular EOA account on Ethereum Mainnet.

After clicking confirm, wait for the transaction to be on-chain. Successful on-chain means the user has switched back from a smart account to a regular EOA account, and specific transaction information can also be found on the etherscan page for the current wallet address.

2. 7702 Phishing Attack Example

On May 24, the #InfernoDrainer phishing gang exploited the batch execution capability of the Metamask 7702-Delegator contract to fraudulently obtain token authorizations from users (0xc6D2…06DC) and carried out phishing attacks, resulting in losses exceeding $146,000 in $HashAI, $HUMANS, $ParallelAI, $NeuralAI, $DSync, $Zero1, $NodeAI, $Sensay, and $Virtual.

• Fraud addresses

0x0000db5c8B030ae20308ac975898E09741e70000 0x00008C22F9F6f3101533f520e229BbB54Be90000 0xa85d90B8Febc092E11E75Bf8F93a7090E2ed04DE 0xC83De81A2aa92640D8d68ddf3Fc6b4B853D77359 0x33dAD2bbb03Dca73a3d92FC2413A1F8D09c34181

• Phishing transaction example

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

• Reason for being phished

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

Ethereum Transaction Hash: 0x1ddc8cecbc… | Etherscan

Call 0xe9ae5c53 Method By 0xc6D289d5…0d2E606DC on 0xc6D289d5…0d2E606DC | Success | May-23-2025 02:31:35 PM (UTC)

etherscan.io

• #InfernoDrainer and #PinkDrainer are experimenting with more covert and impactful phishing black market chains utilizing 7702.

According to our research, the current phishing black market gangs #InfernoDrainer and #PinkDrainer are studying and experimenting with more covert and impactful phishing black market chains utilizing 7702. The related addresses are as follows, and we will also publish a more detailed report in the future:

Inferno Drainer:

0x0000db5c8B030ae20308ac975898E09741e70000

Pink Drainer:

0xe49e04F40C272F405eCB9a668a73EEAD4b3B5624

3. Security Recommendations

Wallet Providers:

• Refer to Metamask's implementation and security management of the 7702 Delegator, prohibiting users from authorizing any Delegator and only allowing in-app operations. Remind users that any behavior prompting users to sign authorizations through a web page is a phishing attack.

• Check if the chain matches the current network and remind users of the replay risk when signing with chainID 0.

• Display the target contract when users sign authorizations, and show the specific function call content when users perform batch executions through the Delegator, reducing the risk of phishing attacks.

Users:

• Private key protection is always the most important. Not your keys, not your coins.

• Do not authorize Delegators based on any independent web pages; safe authorizations typically occur only within applications like Metamask.

• When using any wallet for signing, please carefully review the signing content to avoid blind signing or erroneous signing.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。