We observe an increasing trend of phishing attacks that caused hundreds of millions of losses. Therefore, besides the technique perspective, we must inform users of common phishing methods and educate how to avoid a phishing attack.
Types of Phishing Attacks
We find four types of common phishing attacks exist.
-
Direct token transfer: The attacker lures users to directly transfer the native token (Ether) or ERC20/ERC711 tokens to attacker-controlled accounts.
-
Approval phishing: Approval is a mechanism that delegates a user's token to a spender by signing an approval transaction. The attacker can lure users to sign a transaction to approve his/her tokens to the attacker, and then the attacker can transfer the victim's token.
-
Address Poisoning: Like fake-token attacks, zero-value attacks, and dust-transfer attacks.
-
NFT Zerobuy phishing: The attacker lures users to sign a transaction to sell their NFT at a low price or even for free.
-
Others.
Direct Token Transfer
The first type is called direct token transfer. Attackers ask users to sign a transaction to transfer their Ether directly to the attacker-controlled account. An advanced one leverages a malicious smart contract with a function named SecurityUpdate or ClaimRewards to make users sign the transaction.
The previous figure (the right one) shows an example of a phishing transaction with SecurityUpdate function in the smart contract. If users sign this transaction, his/her Ether will be transferred to this smart contract and then to the attacker.
Approval Phishing
Approval is a mechanism that makes users let other users (spenders) spend his/her tokens. For instance, a user can approve his USDC to a smart contract so that the smart contract can operate on the USDC token on behalf of the user, e.g., swapping the USDC to other tokens. Since the user has approved his tokens to the smart contract, the operation on the user's USDC token by the smart contract does not need another confirmation (or a new signed message) from the user. This can make the whole flow smooth.
However, attackers have abused this mechanism. They can lure users to sign a transaction to approve his USDC (or other valuable tokens) to the attacker-controlled contract or EOA address. After that, the attacker can transfer the user's tokens to the attacker.
The previous figure shows a transaction that approves the USDT to the attacker. Note that approval permission does not expire until the user explicitly revokes it. So, revoke the malicious approval as soon as possible.
We also note a new type of phishing attack leveraging the legitimate contract, which we called it as ROP in Web3 phishing attack. See our blog for more information.
Address Poisoning
In this video, we'll show you how address poisoning happens, including fake-token attacks, zero-value attacks, and dust-transfer attacks, and how to spot fishy transactions on Etherscan.
Zero-value transfer: The attacker makes a zero-value transfer record of popular tokens (USDC, for example) from the victim to a phishing address. This phishing address is similar to the address in the victim's transaction history. When the victim directly copies the address for the next transfer, they may copy the phishing address from the transaction history. Read more on our Twittter, Coinbase investigation 1 2 3, and more.
NFT Zerobuy Phishing
When selling an NFT on NFT markets, e.g., OpenSea, the user first signs a transaction, stating the intention to sell their NFT with a price. Then, those who want to buy this NFT can take the signed order message to fill the order.
This gives the scammer an opportunity to lure users into signing a transaction to sell their NFTs at a particularly low price (or even for free). The attacker can then take this transaction and fill this order on the NFT market to get the victim's NFT at a low price (or for free).
This phishing is prevalent since the user needs help understanding the meaning when signing an order.
The previous figure shows MetaMask's UI when signing an order for OpenSea. Unfortunately, such information is challenging for users to understand.
How to Protect Ourselves
- First, only sign a transaction you understand! If you have any questions about the transaction, please do not sign it.
- Second, take multiple wallets to perform the transaction. Use a wallet address for daily transactions but with a small number of tokens. Put most tokens in a separate wallet address that does not sign transactions except transferring tokens to the first wallet.
- Third, please check your approval and remove unnecessary ones. You can leverage the Approval Diagnosis of MetaSuites for this purpose.
