EIP-7702 grants addresses capabilities and flexibility similar to smart contracts, and an increasing number of 7702 applications are being created, which is crucial for bringing more people into Web3 and enhancing user experience.
However, the flexibility of 7702 and the fact that most users are still unfamiliar with 7702 is being exploited by fraudulent gangs. Recently, we have observed that users have had their interactions, which originally required authorization dozens of times, merged into a single transaction by the phishing gang #InfernoDrainer due to the batch execution capability of Metamask 7702, resulting in asset theft.
Note: Metamask itself does not have security issues. Metamask prioritizes user security when providing users with the capabilities related to 7702 and has implemented many security measures. Users need to have a better understanding of the capabilities and associated risks of 7702 to prevent such security incidents from happening again.
The principle and security design of Metamask 7702 Delagator signature authorization
Technical Analysis
The Delegator Contract deployed with user authorization points the code field of the user's account to this contract. Current official MetaMask Delegator Contract Address: 0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B
Authorization structure: (chainId, delegatorAddress, nonce, signature) written into authorization_list
Signature method: Metamask uses a unified signature logic for EIP-7702-related authorization transactions, that is, the signEIP7702Authorization method, and digest7702 = keccak256(0x05 ‖ RLP(chainId, delegator, nonce)) ECDSA signature, generate (v, r, s) signature structure, and attach it to subsequent Type-4 transactions to realize account authorization and upgrade, as described in:
Verification method: The consensus layer completes the verification through the ecrecover(digest7702, sig) == tx.from.
Security Design: The web version cannot induce users to authorize any Delegator because the signEIP7702Authorization method is only implemented within the MetaMask wallet and is not accessible for calls from the web through window.ethereum. The signature methods accessible on the web, such as eth_signTypedData_v4, are not suitable for EIP-7702 authorization signatures, and the signature digest format is as follows:
The signature format required by the EIP-7702 specification is:
Due to the fact that eth_signTypedData_v4 always includes the 0x1901 prefix and the hash calculation process is completely different from 7702, it is almost impossible for digest712 to equal digest7702, even with a cleverly constructed domainSeparator, primaryType, and message.
Therefore, the web version cannot forge a legitimate 7702 authorization signature through this method. In addition, MetaMask also implements a whitelist mechanism for the Delegator address, which by default only allows authorization of the official Delegator (0x63c0...32B), prohibiting DApps from injecting addresses themselves, further preventing users from being induced to sign malicious Delegator authorization data.
Usage
Currently in Metamask, the methods to upgrade an existing EOA to a 7702 smart account are mainly divided into two categories: active upgrade and passive upgrade.
Active upgrade refers to the user's active click on the "switch" button in the wallet interface to authorize a specific Delegator Contract.
Passive upgrades occur when users interact with certain DApps that support 7702. Metamask will automatically pop up a prompt after detecting the relevant operations, suggesting that users complete the upgrade.
2.1 Active Upgrade:
Transaction content: only includes the action of upgrading and modifying the account, that is, authorizing a specific Delegator Contract.
Upgrade process: Enter the account details page of the wallet, click the switch button in the image below, and you can upgrade the user on the Ethereum Mainnet to a smart account. After clicking the 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 the chain. A successful on-chain means the user has successfully upgraded to a smart account and can view the specific authorization transaction information from the **Authorizations (EIP-7702)** section on the current wallet address page on etherscan.
2.2 Passive Upgrade
Transaction details: including actions to upgrade accounts and batch actions interacting with on-chain smart contracts.
Upgrade Process: When users interact with certain DApps on the blockchain, Metamask will proactively prompt users that the current transaction can be completed by upgrading to a smart account using batch sending. For example, when swapping certain tokens on Uniswap, clicking the Use smart account button will upgrade to a smart account, and then the token authorization and swap will be completed in one transaction.
2.3 Switch back to regular EOA
Whether upgrading actively or passively to convert the current account into a smart account, the bound Delegator Contract Address will be permanently stored on the chain as the current execution logic of the account.
If you want to restore your account to normal EOA, you need to manually initiate a "switch back to EOA" operation. The essence of this operation is to submit the address(0) as a new Delegator contract address with a single EIP-7702 authorization. When the transaction is successfully uploaded to the chain, the code field of the account will be cleared, the execution logic will be restored to the default empty code, and the account will be rolled back to the normal EOA state.
Enter the account details interface of the wallet, click the switch button to switch the user from Ethereum Mainnet back to a regular EOA account.
After clicking confirm, wait for the transaction to be on-chain. Successful on-chain means that the user has switched from the smart account back to a regular EOA account. The specific transaction information can also be found on the current wallet address page on etherscan.
Example of a 7702 Phishing Attack
On May 24, the #InfernoDrainer phishing gang exploited the batch execution feature of the Metamask 7702-Delagator smart contracts 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 $Virtual.
Call 0xe9ae5c53 Method By 0xc6D289d5...0d2E606DC on 0xc6D289d5...0d2E606DC | Success | May-23-2025 02:31:35 PM (UTC)
etherscan.io
#InfernoDrainer 和 # PinkDrainer is experimenting with a more covert and impactful phishing black industry chain using 7702.
According to our research, current phishing black market groups #InfernoDrainer 和 #PinkDrainer are studying and experimenting with more covert and impactful phishing black industry chains utilizing 7702. The related addresses are as follows, and we will also release a more detailed report later:
Inferno Drainer:
0x0000db5c8B030ae20308ac975898E09741e70000
Pink Drainer:
0xe49e04F40C272F405eCB9a668a73EEAD4b3B5624
Security Recommendations
Wallet provider:
Referencing Metamask's implementation and security management for the 7702 Delegator, users are prohibited from authorizing any Delegator and are only allowed to perform operations within the application. Users are reminded that any action prompting them to sign authorization through a webpage is a phishing attack.
Check if the chain matches the current network and remind the user that there is a replay risk when signing with chainID 0.
Display the target smart contracts when the user signs the authorization, and show the specific function call content when the user executes in batches through the Delegator, reducing the risk of phishing attacks.
User:
The protection of private keys is always the most important. Not your keys, not your coins.
Do not authorize Delegator based on any independent web page; secure authorization typically only occurs within the application, like in Metamask.
When using any wallet to sign, please carefully review the content of the signature to avoid blind signing or mis-signing.
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Depth restoration of the 7702 phishing attack principles, how should wallets and users prevent it?
EIP-7702 grants addresses capabilities and flexibility similar to smart contracts, and an increasing number of 7702 applications are being created, which is crucial for bringing more people into Web3 and enhancing user experience.
However, the flexibility of 7702 and the fact that most users are still unfamiliar with 7702 is being exploited by fraudulent gangs. Recently, we have observed that users have had their interactions, which originally required authorization dozens of times, merged into a single transaction by the phishing gang #InfernoDrainer due to the batch execution capability of Metamask 7702, resulting in asset theft.
Note: Metamask itself does not have security issues. Metamask prioritizes user security when providing users with the capabilities related to 7702 and has implemented many security measures. Users need to have a better understanding of the capabilities and associated risks of 7702 to prevent such security incidents from happening again.
The principle and security design of Metamask 7702 Delagator signature authorization
Technical Analysis
The Delegator Contract deployed with user authorization points the code field of the user's account to this contract. Current official MetaMask Delegator Contract Address: 0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B
Authorization structure: (chainId, delegatorAddress, nonce, signature) written into authorization_list
Signature method: Metamask uses a unified signature logic for EIP-7702-related authorization transactions, that is, the signEIP7702Authorization method, and digest7702 = keccak256(0x05 ‖ RLP(chainId, delegator, nonce)) ECDSA signature, generate (v, r, s) signature structure, and attach it to subsequent Type-4 transactions to realize account authorization and upgrade, as described in:
Verification method: The consensus layer completes the verification through the ecrecover(digest7702, sig) == tx.from.
Security Design: The web version cannot induce users to authorize any Delegator because the signEIP7702Authorization method is only implemented within the MetaMask wallet and is not accessible for calls from the web through window.ethereum. The signature methods accessible on the web, such as eth_signTypedData_v4, are not suitable for EIP-7702 authorization signatures, and the signature digest format is as follows:
The signature format required by the EIP-7702 specification is:
Due to the fact that eth_signTypedData_v4 always includes the 0x1901 prefix and the hash calculation process is completely different from 7702, it is almost impossible for digest712 to equal digest7702, even with a cleverly constructed domainSeparator, primaryType, and message.
Therefore, the web version cannot forge a legitimate 7702 authorization signature through this method. In addition, MetaMask also implements a whitelist mechanism for the Delegator address, which by default only allows authorization of the official Delegator (0x63c0...32B), prohibiting DApps from injecting addresses themselves, further preventing users from being induced to sign malicious Delegator authorization data.
Currently in Metamask, the methods to upgrade an existing EOA to a 7702 smart account are mainly divided into two categories: active upgrade and passive upgrade.
Active upgrade refers to the user's active click on the "switch" button in the wallet interface to authorize a specific Delegator Contract.
Passive upgrades occur when users interact with certain DApps that support 7702. Metamask will automatically pop up a prompt after detecting the relevant operations, suggesting that users complete the upgrade.
2.1 Active Upgrade:
Transaction content: only includes the action of upgrading and modifying the account, that is, authorizing a specific Delegator Contract.
Upgrade process: Enter the account details page of the wallet, click the switch button in the image below, and you can upgrade the user on the Ethereum Mainnet to a smart account. After clicking the 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 the chain. A successful on-chain means the user has successfully upgraded to a smart account and can view the specific authorization transaction information from the **Authorizations (EIP-7702)** section on the current wallet address page on etherscan.
2.2 Passive Upgrade
Transaction details: including actions to upgrade accounts and batch actions interacting with on-chain smart contracts.
Upgrade Process: When users interact with certain DApps on the blockchain, Metamask will proactively prompt users that the current transaction can be completed by upgrading to a smart account using batch sending. For example, when swapping certain tokens on Uniswap, clicking the Use smart account button will upgrade to a smart account, and then the token authorization and swap will be completed in one transaction.
2.3 Switch back to regular EOA
Whether upgrading actively or passively to convert the current account into a smart account, the bound Delegator Contract Address will be permanently stored on the chain as the current execution logic of the account.
If you want to restore your account to normal EOA, you need to manually initiate a "switch back to EOA" operation. The essence of this operation is to submit the address(0) as a new Delegator contract address with a single EIP-7702 authorization. When the transaction is successfully uploaded to the chain, the code field of the account will be cleared, the execution logic will be restored to the default empty code, and the account will be rolled back to the normal EOA state.
Enter the account details interface of the wallet, click the switch button to switch the user from Ethereum Mainnet back to a regular EOA account.
After clicking confirm, wait for the transaction to be on-chain. Successful on-chain means that the user has switched from the smart account back to a regular EOA account. The specific transaction information can also be found on the current wallet address page on etherscan.
On May 24, the #InfernoDrainer phishing gang exploited the batch execution feature of the Metamask 7702-Delagator smart contracts 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 $Virtual.
fraud Address
0x0000db5c8B030ae20308ac975898E09741e70000 0x00008C22F9F6f3101533f520e229BbB54Be90000 0xa85d90B8Febc092E11E75Bf8F93a7090E2ed04DE 0xC83De81A2aa92640D8d68ddf3Fc6b4B853D77359 0x33dAD2bbb03Dca73a3d92FC2413A1F8D09c34181
Fishing transaction example
Reasons for Phishing
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 和 # PinkDrainer is experimenting with a more covert and impactful phishing black industry chain using 7702.
According to our research, current phishing black market groups #InfernoDrainer 和 #PinkDrainer are studying and experimenting with more covert and impactful phishing black industry chains utilizing 7702. The related addresses are as follows, and we will also release a more detailed report later:
Inferno Drainer:
0x0000db5c8B030ae20308ac975898E09741e70000
Pink Drainer:
0xe49e04F40C272F405eCB9a668a73EEAD4b3B5624
Wallet provider:
Referencing Metamask's implementation and security management for the 7702 Delegator, users are prohibited from authorizing any Delegator and are only allowed to perform operations within the application. Users are reminded that any action prompting them to sign authorization through a webpage is a phishing attack.
Check if the chain matches the current network and remind the user that there is a replay risk when signing with chainID 0.
Display the target smart contracts when the user signs the authorization, and show the specific function call content when the user executes in batches through the Delegator, reducing the risk of phishing attacks.
User:
The protection of private keys is always the most important. Not your keys, not your coins.
Do not authorize Delegator based on any independent web page; secure authorization typically only occurs within the application, like in Metamask.
When using any wallet to sign, please carefully review the content of the signature to avoid blind signing or mis-signing.