Unmasking the Phantom: The Intricate Shadow Transactions Attack Deciphered
Behind the Shadows: An Unseen Attack
In a Twitter thread dated August 2, CZ highlighted a new breed of attack shaking the blockchain world. The perpetrator cunningly exploited an Achilles heel in wallet interfaces: only the head and tail of addresses were visible. Deftly crafting an address bearing a striking resemblance to the victim’s target (0xa7B4…E90570), the attacker lured the unwary user into diverting their tokens into a cleverly concealed trap.
Unraveling the Shadow Transaction Attack
Analyzing the attacker’s transaction records reveals a strange pattern: the attacker never sent any funds to the victim. Instead, the victim consistently transferred fake USDT to the attacker’s address.
Scrutinizing the victim’s address, we discover the cause: shadow transactions. The victim made frequent large transfers to a particular address, possibly a trusted exchange account or cold wallet.
In response to each of these transactions, an identical shadow transaction appeared. These duplicates mimicked the original in terms of time, amount, and sender, but involved a deceptive Tether USD (USDT) token.
The attacker’s modus operandi emerges:
- They scan for targets with significant assets making frequent large transfers to a certain address. The attacker then generates similar addresses to the target’s.
- Next, they deploy a phony Tether USD token, capable of emitting arbitrary transfer operations to the blockchain.
- The attacker monitors the victim. When the victim transacts, the attacker creates a parallel transaction with the fake USDT. As blockchain explorers and wallets don’t validate the initiator, this fake transaction appears as a transfer record in the victim’s history.
- The attacker waits for the victim to copy the recipient address from a past transaction, causing them to copy the attacker’s address and initiate a transfer.
Key Insights into the Shadow Transactions Attack
The ingenuity of the Shadow Transactions Attack lies in its exceptional ability to deceive. A combination of factors contributes to its daunting resistance to prevention:
- Disguised in Plain Sight: Given the complexity of directly recognizing and understanding hexadecimal addresses, most wallets and browsers opt for a user-friendly approach — displaying only the beginning and end of an address. This industry practice inadvertently prompts users to equate addresses with matching heads and tails as identical.
- A False Sense of Security: Victims who regularly transact with a certain address become familiar and trusting of that address, especially its start and end digits. This familiarity breeds a dangerous sense of trust towards the attacker’s address, which is cunningly crafted to bear the same head and tail.
- Manipulation of Trust: All block explorers and wallets rely on on-chain events to keep track of transaction records. Therefore, the attacker can guarantee the appearance of shadow transactions in the user’s wallet simply by forging such events. In comparison to incoming transactions, users are more likely to trust outgoing ones, since they believe these transactions were initiated by themselves.
- Mirror Images: Shadow transactions and authentic ones bear uncanny similarities — nearly identical initiation times, same amounts, identical senders, and seemingly identical recipients. Unless scrutinized closely, these transactions are nearly impossible to tell apart.
The combined impact of these factors makes it frighteningly easy for a user to unknowingly fall prey to this sophisticated scam.
Rampant Onslaught: The Rising Trend of Attacks
This isn’t the first time the cunning Shadow Transactions Attack has reared its head. As early as the beginning of 2023, Goplus had noted a concerning trend. This crafty tactic began to slowly overshadow the traditional ‘dust transactions’, emerging as the dominant scam method in asset transfers.
More alarmingly, this isn’t the work of a single, isolated attacker. There’s evidence of multiple perpetrators conducting simultaneous attacks on a single address, leading to a highly competitive and intense landscape.
In fact, in the case study at hand, we observe a new attacker entering the fray, launching a fresh wave of attacks against the same victim. This rising threat marks a new era in the battle for security within the web3 ecosystem.
Shield Up: Your Anti-Shadow Transaction Checklist
- Trust No Transaction Record: Always use a trusted source or direct recipient for addresses, never from transaction history.
- Inspect, Regularly: Scan your transaction records often for unfamiliar activity.
- Asset-Specific Filters are Your Friend: Filter transaction records by specific assets to weed out rogue transactions.
- Know Your Addresses: Remembering your addresses, although challenging, can be a lifesaver.
- Automate Safely: For institutions and exchanges, automate transfers, use whitelisted addresses to minimize human error.
- Stay Sharp, Keep Learning: Always question, stay skeptical, and remember — knowledge is your best shield.
Silent Threats in the Shadows: A Glimpse of Unseen Dangers
Shadow transactions have notoriously capitalized on phony tokens pretending to be mainstream assets. Yet, the threat extends beyond these deceptive facades, with even authentic, mainstream assets potentially wielded as tools of deceit.
An interesting case in point is the official contract implementation of USDC (https://etherscan.io/address/0xa2327a938febf5fec13bacfb16ae10ecbcf#code). Surprisingly, it does not enforce a non-zero limitation on its `transferFrom` method.
This unanticipated loophole means any individual can prompt a zero-value transfer from any address to any other.
This opens the door for future malefactors to bombard the transaction history of victims with a barrage of zero-value transactions. These transactions, although devoid of any real value, carry a mask of authenticity by virtue of originating from the legitimate USDC contract, adding a new level of deception.
This situation underscores a lingering concern for us at GoPlus Security: many developers may be focusing so heavily on fortifying their own projects that the safety of ordinary users could be unintentionally overlooked.