Avoid the Phishing Attack
Unfortunately, we still 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.
We find there exist four types of common phishing attacks.
- 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 transactionn to sell their NFT at a low price or even for free.
- Others.
The first type is called direct token transfer. The attackers ask users to sign a transaction to transfer his/her Ether to the attacker-controlled account directly. An advanced one is leveraging a malicious smart contract with a function name
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 is a mechanism that makes users let other users (spender) 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, this mechanism has been abused by attackers. The attacker 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, an approval permission does not expire until the user explicitly revokes the approval.
In this video, we'll show you how address poisoning happens, the three types, which are Fake-token attacks, Zero-value attacks, and Dust-transfer attacks to watch out for, and how you can 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 an address that has been in the transaction history of the victim. 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 1x 2 3, and more.
When selling an NFT on NFT markets, e.g., OpenSea, the user firsts sign a transaction of the order, stating the intention to sell their NFT with a price. Then who want to buy this NFT can take the signed order message to fill the order.
This gives the scammer an opportunity that the attacker can lure users to sign a transaction to sell their NFTs at a particularly low price (or even for free). Then the attacker can 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 particularly popular since the user does not understand the meaning when signing an order.
The previous figure shows the UI of MetaMask when signing an order for OpenSea. Unfortunately, such information is challenging for users to understand.
- First, only sign a transaction you understand! If you have some hesitation about the transaction, 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, frequently check your approval and revoke unnecessary ones. You can leverage the Approval Diagnosis of MetaDock for this purpose.
Last modified 1mo ago