Address Poisoning Attacks


Table of Contents:


What is Address Poisoning

Address poisoning involves the attacker creating deceptive transactions in the victim's address transaction history, tricking victims into sending funds to the attacker's address.

The tactics employed by address poisoning attackers have evolved over time, yet their objective remains the same: deceiving users into copying the attacker's address when sending onchain transactions.

In this article, we will go through:

How Does Address Poisoning Work?

To increase the likelihood of users copying the wrong transfer address, attackers deploy a combination of spoofing methods in their address poisoning schemes:


Token spoofing

Attackers deploy token contracts with the name and symbol resembling those of well-known or familiar tokens. The aim is to trick victims into believing these tokens are legitimate.

A fake token with the exact name and symbol as USDT was flagged by Team Etherscan

Block explorers are not the only interfaces attackers use to deceive unsuspecting users.

When other dApp frontend interfaces aggregate all transactions in one tab, anyone can create a fake "ETH" token and disguise it as a genuine ETH transaction:

Source: twitter.com/pcaversaccio/status/1715405608311300553

The solution? Inspect the transaction and compare it with several other sources to ensure its legitimacy.


Address spoofing

Attackers use a 'vanity' address generator to create an address that closely resembles a target address's first and last few characters. When truncated in the middle, it appears exactly the same as the target address, thereby fooling unsuspecting victims.

Attackers can then use the spoofed address to send tiny amounts of legitimate tokens like USDC or USDT to the victim's address, hoping that the victim will copy the spoofed address and unknowingly send their funds to the attacker the next transaction. Read more here.

Below is an example of a victim who mistakenly transferred $20m to the spoofed address. Please note the striking similarity in the first and last few characters:


Event spoofing

Attackers take advantage on the implementation of the ERC-20 token standard. The transferfrom() function enables another address to transfer tokens on behalf of the function caller and subsequently emit the Transfer event.

Screenshot taken from eips.ethereum.org/EIPS/eip-20#transferfrom

These spoofed Transfer events can either mislead users into thinking:

  • A popular figure is transferring a particular token, or
  • An entity is airdropping tokens to users.
A spoofed event misleading users to believe Vitalik transferred fake zkSync tokens
A spoofed event showing Opensea transferred 10 OSRS tokens to the destination address

Attackers take advantage on the design of ERC-20 token standard to carry out address poisoning attacks in 2 ways:

  • Zero-value token transfers (Spoofed event + address)

For transfers involving legitimate tokens like USDC/USDT/DAI, attackers would initiate a transferFrom function sending 0 value tokens. Every address is default to 0 value approval, so the Transfer event is emitted.

They then combine this with address spoofing to increase the likelihood of a victim copying the wrong transfer address and sending money to the attacker.

Notice how the spoofed address looks almost exactly the same as the target address:

Note: Etherscan hides zero-value transfers by default; they were unhidden for demo purposes
  • Spoofed token-transfers (Spoofed event + address + token)

The goal is to mimic the target token transfer event as closely as possible, so the victim would mistakenly copy the spoofed address and send money to the attackers.

Attackers deploy spoofed token to USDC/USDT/DAI, initiates a transferFrom function from or to the spoofed address, with token value matching the target transfer event's.

Notice how you wouldn't be able to tell these 2 events apart if Etherscan displays the spoofed USDC the same way as the legit one:

A spoofed event mimicking the target token transfer event as closely as possible

Attackers constantly monitor the chain for frequent or huge token transfers (usually stablecoins) and immediately create spoofed events to pollute an address' token transfer history.

Notice how the spoofed events are created as soon as 1 minute after the target token transfer:

Spoofed events were created within a minute after the target token transfer
Imagine you wanted to make another token transfer 2 minutes after the initial one. You assume the latest address in your token transfer history is correct and copy the spoofed address as your destination address, effectively transferring your money to the attackers.

Address poisoning takes place on many different Web3 interfaces, not limited to Etherscan. See how a spoofed token transfer event displayed from a wallet interface can cause the victim to copy the wrong receiver address, costing them ~$1.45M:

Attackers routinely employ contract functions with unique method IDs to carry out bulk event spoofing. These functions are difficult to trace, given that the associated contracts remain unverified.

Example of a unique method ID used to carry out bulk event spoofing
Source: https://twitter.com/etherscan/status/1679474644934623232

What you can do to protect yourself

To combat Token Spoofing:

  • Note that any ERC-20 token that hasn't been verified by Etherscan may not have its logo displayed correctly, please be cautious when interacting with them
  • Compare a token with various sources, and if you find them suspicious, do not interact with these tokens. Hide them with Token Ignore List

To combat Address Spoofing:

Notice how the address highlight feature helps tell apart similar looking addresses
  • Etherscan recently displayed more of the first and last few characters of an address to make spoofed address distinguishable (each additional character is increasingly difficult for attackers to generate):

To combat Event Spoofing:

  • Turn on the option to hide zero-value token transfers
  • Take note of the popup reminder that appears when copying address on token transfer pages if:
    • Tokens are of poor reputation
    • Tokens do not have updated information
    • Transaction originated from an address that is different to the sender of the token
  • Transfers of tokens with poor reputation are now hidden across Etherscan by default
  • Transfers of tokens added to the Custom Ignore List are also hidden throughout the site

Team Etherscan aggressively flags spoofed tokens and addresses, be cautious when interacting with them.


Conclusion

Address poisoning attacks are a recurring problem simply because one huge amount wrongly sent by a victim is enough to recover the attackers' operation costs. It requires a concerted effort from parties across the Ethereum stack to put safeguards/standards in place to protect users and drive down the profitability of these attacks.

These attacks are possible because attackers have found a way to circumvent token standards and use block explorers and wallet interfaces to deceive users. Learn more about some common issues related to non-standard ERC-20 tokens on Etherscan: https://info.etherscan.com/non-standard-token-contracts/


Further reading on Address Poisoning Attacks

  • Teck Yuan Lee
Updated