EIP-7702 grants addresses capabilities and flexibility similar to smart contracts, and more and more 7702 applications are being created continuously, which is crucial for bringing more users into Web3 and improving user experience.
However, the flexibility of 7702 and the fact that most users are still unfamiliar with 7702 are being exploited by fraudulent groups. Recently, we observed that users were phished because the batch execution capability of MetaMask 7702 caused interactions that originally required dozens of authorizations to be consolidated into a single transaction by the phishing gang #InfernoDrainer, resulting in asset theft.
Note: MetaMask itself does not have security issues. MetaMask prioritizes user security when providing 7702-related capabilities and has implemented many security measures. Users need to understand more about the capabilities and related risks of 7702 to prevent similar security incidents from happening again.
One, Principles and Security Design of the Metamask 7702 Delagator Signing Authorization
1. Technical Analysis
The user authorizes the 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) written into authorization_list
Signing method: MetaMask's underlying layer uses a unified signing logic for EIP-7702 related authorization transactions, specifically the signEIP7702Authorization method, performing ECDSA signing on the authorization data digest7702 = keccak256(0x05 ‖ RLP(chainId, delegator, nonce)), generating (v, r, s) signature structure, which is attached to subsequent Type-4 transactions, implementing 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 completes verification via 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 does not allow calls through window.ethereum from the web. Accessible signing methods 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 eth_signTypedData_v4 containing the fixed prefix 0x1901, and the digest calculation process being completely different from 7702, it is almost impossible to make digest712 == digest7702 even with cleverly constructed domainSeparator, primaryType, and message.
Therefore, the web version cannot forge a legitimate 7702 authorization signature through this method. In addition, MetaMask implements a whitelist mechanism for Delegator addresses, allowing only the official Delegator (0x63c0...32B) to be authorized by default, prohibiting DApps from injecting addresses on their own, further preventing users from being misled into signing malicious Delegator authorization data. EIP-7702 grants addresses capabilities and flexibility similar to smart contracts, and more and more 7702 applications are being created continuously, which is crucial for bringing more users into Web3 and improving user experience.
However, the flexibility of 7702 and the fact that most users are still unfamiliar with 7702 are being exploited by fraudulent groups. Recently, we observed that users were phished because the batch execution capability of MetaMask 7702 caused interactions that originally required dozens of authorizations to be consolidated into a single transaction by the phishing gang #InfernoDrainer, resulting in asset theft.
Note: MetaMask itself does not have security issues. MetaMask prioritizes user security when providing 7702-related capabilities and has implemented many security measures. Users need to understand more about the capabilities and related risks of 7702 to prevent similar security incidents from happening again.
One, Principles and Security Design of the Metamask 7702 Delagator Signing Authorization
1. Technical Analysis
The user authorizes the 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) written into authorization_list
Signing method: MetaMask's underlying layer uses a unified signing logic for EIP-7702 related authorization transactions, specifically the signEIP7702Authorization method, performing ECDSA signing on the authorization data digest7702 = keccak256(0x05 ‖ RLP(chainId, delegator, nonce)), generating (v, r, s) signature structure, which is attached to subsequent Type-4 transactions, implementing 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 completes verification via 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 does not allow calls through window.ethereum from the web. Accessible signing methods 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 eth_signTypedData_v4 containing the fixed prefix 0x1901, and the digest calculation process being completely different from 7702, it is almost impossible to make digest712 == digest7702 even with cleverly constructed domainSeparator, primaryType, and message.
Therefore, the web version cannot forge a legitimate 7702 authorization signature through this method. In addition, MetaMask implements a whitelist mechanism for Delegator addresses, allowing only the official Delegator (0x63c0...32B) to be authorized by default, prohibiting DApps from injecting addresses on their own, further preventing users from being misled into signing malicious Delegator authorization data.
2. Usage Method
Currently in MetaMask, the method for upgrading existing EOA to a 7702 smart account (Smart Account) is mainly divided into two categories: active upgrades and passive upgrades.
Active upgrade refers to the user actively clicking 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 suggesting that users complete the upgrade after detecting related operations.
2.1 Active Upgrade:
Transaction content: only includes the action of upgrading the account, that is, authorizing a specific Delegator Contract.
Upgrade process: Enter the account details interface of the wallet, click the switch button shown in the figure below, and the user can upgrade to a smart account on Ethereum Mainnet. After clicking switch, a window will appear for the user to sign the current upgrade transaction:
Authorization records: After confirmation, wait for the transaction to be on-chain. Successful on-chain means the user has successfully upgraded to a smart account and can view specific authorization transaction information from the **Authorizations (EIP-7702)** section on the etherscan page of the current wallet address.
2. Usage Method
Currently in MetaMask, the method for upgrading existing EOA to a 7702 smart account (Smart Account) is mainly divided into two categories: active upgrades and passive upgrades.
Active upgrade refers to the user actively clicking 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 suggesting that users complete the upgrade after detecting related operations.
2.1 Active Upgrade:
Transaction content: only includes the action of upgrading the account, that is, authorizing a specific Delegator Contract.
Upgrade process: Enter the wallet's account details interface, click the switch button shown in the image below, and the user can upgrade to a smart account on Ethereum Mainnet. After clicking switch, a window will appear for the user to sign the current upgrade transaction:
Authorization records: After confirmation, wait for the transaction to be on-chain. Successful on-chain means the user has successfully upgraded to a smart account and can view specific authorization transaction information from the **Authorizations (EIP-7702)** section on the etherscan page of the current wallet address.
2.2 Passive Upgrade
Transaction content: includes the action of upgrading the account and batch actions interacting with on-chain contracts.
Upgrade process: When the user interacts with certain DApps on the chain, MetaMask will actively prompt the user that the current transaction can be completed by upgrading to a smart account using batch sending. For example, when performing swaps of certain tokens on Uniswap, by clicking the Use smart account button, the user upgrades to a smart account, and thereafter token authorization and swap will be completed in one transaction.
2.3 Switch Back to Regular EOA
Whether using active upgrades or passive upgrades to convert the current account to a smart account, 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 back 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 account's code field will be cleared, and the execution logic will revert to the default empty code, returning the account to the regular EOA state.
Enter the account details interface of the wallet, click the switch button, and the user can switch from Ethereum Mainnet back to a regular EOA account.
After confirming, wait for the transaction to be on-chain. Successful on-chain means the user has switched from a smart account back to a regular EOA account, and the specific transaction information can also be found on the etherscan page of the current wallet address.
Two, 7702 Phishing Attack Examples
On May 24, the #InfernoDrainer phishing gang exploited the batch execution feature of the Metamask 7702-Delagator contract to fraudulently obtain token authorizations from users (0xc6D2…06DC) and executed 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
Phishing transaction example
https://etherscan.io/tx/0x09c264618e93983510aaeb7aa2c91c8254a8b2ec66167438f3f6c28b866b6eba
Reason 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 and #PinkDrainer are experimenting with more covert and impactful phishing black industrial chains utilizing 7702.
According to our research, the phishing black production gangs #InfernoDrainer and #PinkDrainer are currently studying and experimenting with more covert and impactful phishing black industrial chains utilizing 7702. The relevant addresses are as follows, and we will also publish a more detailed report later:
Inferno Drainer:
0x0000db5c8B030ae20308ac975898E09741e70000
Pink Drainer:
0xe49e04F40C272F405eCB9a668a73EEAD4b3B5624
Three, Security Recommendations
Wallet provider:
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 that lets users sign authorizations through the web is phishing.
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 the user signs authorization, and show the specific function call content when the user performs batch execution through the Delegator to reduce the risk of phishing attacks.
User:
Protecting private keys is always the most important thing. Not your keys, not your coins.
Do not authorize Delegators based on any independent webpages; secure authorizations typically occur within applications like MetaMask.
When using any wallet for signing, carefully check the signing content to avoid blind signing or mis-signing. After confirming, 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 the specific transaction information can also be found on the etherscan page of the current wallet address.
Two, 7702 Phishing Attack Examples
On May 24, the #InfernoDrainer phishing gang exploited the batch execution feature of the Metamask 7702-Delagator contract to fraudulently obtain token authorizations from users (0xc6D2…06DC) and executed 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
Phishing transaction example
Reason for phishing
User (0xc6D2…06DC) executed a malicious batch authorization transaction:
#InfernoDrainer and #PinkDrainer are experimenting with more covert and impactful phishing black industrial chains utilizing 7702.
According to our research, the phishing black production gangs #InfernoDrainer and #PinkDrainer are currently studying and experimenting with more covert and impactful phishing black industrial chains utilizing 7702. The relevant addresses are as follows, and we will also publish a more detailed report later:
Inferno Drainer:
0x0000db5c8B030ae20308ac975898E09741e70000
Pink Drainer:
0xe49e04F40C272F405eCB9a668a73EEAD4b3B5624
Three, Security Recommendations
Wallet provider:
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 that lets users sign authorizations through the web is phishing.
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 the user signs authorization, and show the specific function call content when the user performs batch execution through the Delegator to reduce the risk of phishing attacks.
User:
Protecting private keys is always the most important thing. Not your keys, not your coins.
Do not authorize Delegators based on any independent webpages; secure authorizations typically occur within applications like MetaMask.
When using any wallet for signing, carefully check the signing content to avoid blind signing or mis-signing.