Zero Transfer Phishing - Part 1 - Attack Analysis

While this phishing technique does not directly target Coinbase Exchange custodial services or systems, we strongly believe that it is important to address any attacks or vulnerabilities within the crypto community as a whole and hope the information in the blog will help strengthen and inform the entire ecosystem.

In late November, attackers began creating smart contracts designed to create zero-value token “transfers” from a victim address to a spoofed address similar to one that the victim has previously sent to. Because those “transfers” do not represent the actual transfer of any token, they have a zero value. As such, they do not require the normal approval by the source / victim wallet to be processed and recorded to the public blockchain. Why does this matter?

The idea is to trick the victim into accidentally sending to this spoofed address that belongs to the attacker vs. the correct address that they have previously interacted with.  Why does that work?  Because when many users set up a new transaction, they will very often rely on their transaction history to check what address(es) they have previously sent to and copy-pasting this address from the last transaction the victim sent to it. And how do most users confirm that an address is correct?  They will quickly scan the first and last several characters of the wallet address to validate that it is consistent across all transactions in their history. They often do NOT compare and validate each and every character.

Scan - Copy - Paste - Robbed!

This attack directly targets the common practices and tools that many people use when engaging the crypto ecosystem. Blockchain explorers are normally a reliable and extremely trustworthy source to check past transactions. So are previous transactions listed in a users’ software wallet. This attack uses these tools in combination with the common practices of users against them.

Between late November and Feb 13, 2023, this attack has led to a loss of $19m in victim funds from various wallet providers. To be clear, this is not a Coinbase specific problem. This is a problem for the whole crypto ecosystem. Identifying and countering attacks that can negatively impact our community is a huge part of our mission here at Coinbase and was a major driver in creating the Unit 0x team.  

The three part blogpost series will delve into how the exploit works, how it evolved, how successful it's been and what the top campaigns have done to rake in funds.

Coinbase Wallet has proactively implemented a solution to fully protect users from these types of attacks as part of its mission to make web3 exploration more secure.

How does it work?

A successful zero transfer phishing attack happens in three stages:

1. The attacker monitors on-chain token transfers and selects a victim.

2. The attacker analyzes a victim’s ERC20s transfers and selects a recipient address from them.

3. The attacker generates a spoofed address that looks similar to the recipient of a transaction that the victim previously sent.

4. The attacker broadcasts a specially crafted transaction on behalf of the victim to that spoofed address.

5. The victim picks up a spoofed recipient address from a blockchain explorer or through their wallet

The attack is illustrated in the diagram below:

Image 1: Zero Transfer Attack Flow In this section we will review each stage of the attack and discuss exactly attackers’ steps to trick users into sending their assets to a spoofed address.

Step 1

The attack begins by bad actors actively watching on-chain logs for token transfer events such as the one below:

Image 2: Sample transaction

Step 2 

In the transaction above 0x0204a5…1d0e77 transfers 5 USDC to 0x5ecf9f7d…821a7e. The attacker selects 0x0204a5…1d0e77 as the victim and 0x5ecf9f7d…821a7e as the address they will spoof.

Step 3

The attacker starts generating a vanity address closely resembling the destination address 0x5ecf9f7d…821a7e. Profanity2 by 1inch is one such tool which can bruteforce addresses based on the provided mask. The screenshot below illustrates a sample session generating a vanity address matching first and last four characters:

Image 3: Generating vanity addresses

Step 4

After generating a vanity address which appears sufficiently similar to the destination address used by a victim, the attacker broadcasts a specially crafted transaction with the victim address as a source and the newly generated vanity address as a destination:

Image 4: Zero Transfer Phishing Transaction

Notice the above transaction actually sent 0 USDC tokens. In order to generate an on-chain transfer event which will be recognized by blockchain explorers and wallets, attackers use a transferFrom method available in ERC-20 token implementations. Below is a sample implementation from ethereum.org:

Image 5: ERC-20 transferFrom method

The transferFrom method allows one to specify arbitrary owner and “buyer” (read: recipient) addresses to initiate the transfer as long as the owner has previously approved a certain allowance to be used by the message sender. Since a legitimate owner address has never approved an attacker to transfer tokens on their behalf, the allowed[owner][msg.sender])will return 0 by default. 

However, the only way the attacker can satisfy the highlighted require check is by setting the numTokens parameter to zero effectively transferring zero tokens. 

To simplify, the require statement is:

numTokens <= allowed[owner][msg.sender];

And since the attacker isn’t the owner, we know:

numTokens <= 0;

Therefore, if the attacker sets numTokens = 0, they can still emit a Transfer event.

Once the transferFrom method executes, it emits a Transfer event which is picked up by blockchain explorers and wallets as a successful transaction.

Image 6: Zero transfer transaction Transfer log.

Step 5

The attack relies on a user carelessly copying the spoofed destination address from a blockchain explorer or a wallet software when sending future transactions. The social engineering aspect of the attack is more effective if transaction addresses are abbreviated with only a few characters from the beginning and end of the address visible.

Recommendations

As bad actors continue to evolve their craft it is critical for the crypto ecosystem to remain vigilant to new threats. To address this particular threat it is recommended for consumers to implement the following practices:

• Verify the entirety of the address before sending. Attackers may have generated a vanity address to closely resemble a legitimate one.

• Be mindful about copying addresses from transactions which you did not originate or that look suspicious. Existing ERC-20 tokens will continue allowing zero transactions to and from arbitrary transactions.

• Use blockchain explorers (e.g. Etherscan) and wallets (e.g. Coinbase Wallet) which flag or filter malicious transactions and addresses.

The following approaches can be implemented by blockchain explorers and wallets to help shield consumers from this and similar threats:

• Flag or filter transfer events with the value set to 0. Consider derivative exploitation vectors for non-ERC-20 transfer events (e.g. NFTs, staking, etc.).

• Implement address mask collision detection to identify similar addresses which are unlikely to have been generated randomly (e.g. same N first and last characters).

• If shortening addresses consider including 3+ bytes on each side to make mass vanity generation harder (e.g. 0x123456...abcdef).

• Alert users on new/unknown addresses when initiating transfers.