An Automated Scam against ERC20 Transactions
A friend of mine has recently fallen victim to an insidious scam aimed at USDT stablecoin users on Ethereum mainnet. In principle, it can be deployed against any popular ERC20 token, so it is worth discussing it in the more general context of the ERC20 standard. The scammers are casting a very wide net, threatening anyone copying the target address from what they assume to be the most recent transaction to the same recipient.
In this writeup, I will explain how the scam works and what can be done to avoid falling victim to it. Unfortunately, not much can be done to recover the funds after the fact.
The typical victim experience is the following:
First, you send a small amount of tokens to your counterparty in a “handshake transaction” to verify that they receive them. After they report on successfully receiving your tokens, you send the larger amount to the target address copied from the handshake transaction. Your counterparty does not receive your tokens. If you trace what happened to your tokens, you’d find out that they have been immediately exchanged on a DEX into Ethers and sent on to some other address that hasn’t been used before. In short, your tokens have been stolen and prevented from being frozen by placing the scammers’ address on Tether’s blocklist. The scammers got their haul in Ethers and not much can be done about it.
This is, however, not the only way in which one can fall victim to these scammers. If you copy the target address from a past token transaction, even if it is not a handshake transaction, you may end up with your tokens being stolen the same way.
What has just happened?
The scammers are monitoring the targeted token’s ERC20 contract (USDT, in this case) for transactions and if they detect a token transfer, they make a transferFrom() call to a malicious ERC20 token contract deployed by themselves, which shares the name with the targeted token (“Tether USD” in this case) and responds with the same total minted amount, if its totalSupply() method is called. It also mimics some other aspects of the targeted token contract. The transferFrom() call by the attackers has the victim’s source address and a target address that matches the recipient in the victim’s transaction in the first few and last few digits. But it is a different address, controlled by the attackers. The amount of tokens transfered is the same as in the victim’s transaction. The call succeeds, as the malicious contract obviously does not check the allowance and does not require a previous approve() call by the victim, as a real ERC20 token contract would.
Now, blockchain explorers such as Etherscan and possibly some wallet software would display this transferFrom() call as a token transfer from the victim very similar to the token transfer that they have actually performed. It may pass superficial inspection, as the token name, the symbol, the amount and the beginning and the end of the target address match. In the actual attack that I have seen the ERC55 capitalization of the beginning and the end of the address did not match. But it is not computationally prohibitive to cover that base, so even though in this case the victim could have caught the attack by looking at the capitalization of the few hex digits that they did check, it is not a reliable way of avoiding being scammed. More sophisticated versions of this same attack can be expected to take care of ERC55 capitalization of the beginning and the end of the target address.
Thus, the victim is expected to mistake the attackers’ transferFrom() call for their own previous transaction and copy the target address from it into his next token transfer thereby transfering the tokens to the attackers.
What can you do to avoid being scammed?
Whenever making a blockchain transaction, always use the primary source for the target address and meticulously check the entire address before approving a high-value transaction. Pay attention to ERC55 capitalization, as it may help catching some errors.
If the primary source of the target address is not available for some reason, before copying the target address from a previous transaction, make sure that it was, indeed, a transaction made by you to the actual token contract. Check the token contract’s address (blockchain explorers will help you identify popular ERC20 contracts).
While it is not relevant for this particular attack, it is worth asking the recipient to check the transaction identifier and/or the source address from which they received the handshake transaction, because in an ongoing (typically targeted) man-in-the-middle attack the attacker might have already diverted your handshake, but forwarded it to your intended recipient so that they confirm the receipt of the funds.
In general, be very paranoid about the target address of high-value token transfers. If there is a signed contract about performing a service in exchange for payment, try having the target address included in that contract.
What can the ecosystem do to fight this scam?
The scam relies on a peculiarity of the ERC20 standard, in which token transfers can be initiated by a party different from the payer under certain circumstances. While it is a know weakness of the standard and caused many problems, it is unreasonable to expect the entire Ethereum ecosystem to change their primary token standard. The rationale for this mechanism is that unlike native token (ETH) transfers, recipient contracts of ERC20 token transfers are not notified about incoming token transactions, so the conventional way of transfering tokens to contracts is by approving them for taking the tokens themselves through this mechanism. In hindsight, the token standard might have been designed better, but that ship has sailed a long time ago and I see no possibility to fix it. So the solutions should lie elsewhere.
Blockchain explorers and wallets that do display outgoing token transfers not initiated by the monitored address should make such transfers visually distinct from the ones that the user initiated. In this particular attack, in order to save on gas costs, the attackers batched multiple scammy token transfers in single transactions. Such complex transactions should be definitely flagged by explorers as distinct from simpe token transfers, but again, even a single transferFrom() call could have been malicious, so they are worth flagging.
Etherscan makes some effort to flag malicious ERC20 token contracts (probably after they are reported). Older instances of this scam are, indeed, flagged by Etherscan in a reasonably alarming way, but the scammers are regularly re-deploying new instances of the malicious contract, so this is not a very effective way to combat the scam, though it does impose some trivial additional cost on the scammers. At the time of the attack on my friend, the token contract was not flagged by Etherscan as a probable scam (it still isn’t at the time of writing). Perhaps, displaying warnings about all recently deployed ERC20 contracts would help. In the particular instance of the attack that I have seen, the contract was deployed just before the attack. It is also worth noting that there are, at the time of writing, 356 other contracts with exactly matching bytecode, all of which are, of course, scams. Perhaps, block explorers could flag all ERC20 contracts that are caught executing transferFrom() calls without a matching approve().
In order to transact with the tokens sent to the trap address, the attackers must transfer some ETH to those same addresses (and they do). Perhaps, by tracing the origin of these Ethers, it could be possible to find the scammers, but it is a very expensive investigation and they did exert quite a bit of effort to make it more difficult and cover their tracks. Similarly, it might be possible, though very difficult to go after the deployment transactions of scam contracts and the (batched) transferFrom() calls. However, given the magnitude of this scam, it might be worth the effort, financed by operators of attacked ERC20 tokens (Tether, in this instance), to track down the scammers and take action against them.
Finally, it is worth repeating that the entire Ethereum community, every Ethereum user, should take reasonable security measures in proportion to the value at risk. The higher the value of a transaction, the more effort should be made to secure it. This scam does not exploit any hitherto unknown vulnerability. Standard, well known security practices are adequate against it. Please do follow them.
P.S. This scam is a fairly advanced version of the address poisoning attack.