Ethereum sweepers are rampant; how can users recover funds from leaked addresses?

This article was published on Babit Information, author: Harry Denley, translated by: Sato Xi.

Have you ever encountered a situation where you send some Ethereum funds and then find that your wallet is immediately emptied? You might have been targeted by a sweeper. This article aims to help you address this issue, originally written by MyCrypto security & anti-phishing engineer Harry Denley.

When your secret is leaked, malicious parties typically set up a sweeper on your account to exploit anything that happens on that address in the future, such as when users deposit ETH to try to withdraw some tokens, during airdrops, or other situations.

This article outlines how users' funds are swept away and three unique methods to rescue any funds that have not been swept (e.g., staked funds).

How Users Are Phished

Recently, we have seen a large number of users impersonating Telegram group administrators. These fake administrators offer help to users requesting assistance in the main channel (even though they are not the real administrators; they copy the admin's profile information but with slight differences in the username). These impostors often use a lot of jargon to confuse users and share a link to a seemingly legitimate website, but it ultimately asks you to enter your mnemonic phrase or private key.

Then, your crypto assets disappear, and a sweeper is on the scene.

Here is an example of one of these fake websites:

How Sweepers Work

Sweepers are codes that monitor the blockchain (including the txpool, which technically is not on-chain) and react to specific transactions by signing them according to a set of programmed rules, faster than humans can.

This means that when you check your address on a blockchain explorer or "connect" it to a dapp's UI, the sweeper is invisible. Only after you sign and broadcast a transaction to the network can the sweeper see your activity.

Over time, we have observed the evolution of sweepers and the activities that exploit them.

Evolution of Sweepers

During 2017, a significant amount of activity exploited tokens with locking features (i.e., you cannot successfully call transfer()) but included price feeds. Dave Appleton published an article about these activities.

The way malicious parties exploited this scam was by posting private keys to this address (in a seemingly innocent or erroneous manner) and waiting for people to deposit ETH into that address (to transfer tokens from the address). Then, the malicious party would have a sweeper program for that account to quickly transfer the deposited ETH to their own account. Theoretically, locked tokens are considered worthless, so they try to profit from those unsuspecting "greedy" users.

Today, leaked addresses are basically deployed with ETH sweeper programs, and some organizations use more advanced sweeper logic to sweep ERC20 tokens based on price feeds.

Earlier this year, I conducted some reconnaissance on a leaked address and found that sweepers are continuously evolving:

1. Sweepers prefer assets with the highest dollar value, even if it means incurring higher transaction fees to sweep;
2. Sweepers will use all available ETH to maximize sweep value, while also having a high percentage of nonce "winning" transactions.
3. Sweepers have a matching engine that matches staked tokens (i.e., xKNCa=KNC) with their native tokens so that price feeds are reflected on the staked tokens.
4. Sweepers have their own internal nonce counter, and if their highest nonce random number is not confirmed within a time frame (or is dropped/replaced by another), they periodically reset the nonce random number to eth.getTransactionCount() output.
5. If there are high-value assets targeted by the sweeper, some activities suggest that operators "sacrifice" some ETH through funding addresses to try to quickly sweep high-value assets from the account.
6. If the dollar value is below a certain threshold, some sweepers will not sweep assets, meaning you might not even know your account is being targeted by a sweeper, which is quite terrifying.

The first article describing sweepers appeared in 2017, and now we observe that sweepers have become more advanced, designed to maximize the operator's profits while causing the maximum loss to victims.

How to Defeat Sweepers?

First, as humans, we cannot be faster than code, so our solutions can only involve coding. You can choose several different routes, none of which can provide a 100% guarantee, but they are beneficial for us.

You need to create a prioritized list of tokens you want to attempt to rescue, so you can easily determine your plan. You need to list:

1. Token contract address;
2. Whether the token is staked (and whether unstaking is time-locked);
3. Whether the token is transferable;
4. Token value (in USD);

The key is to complete this task methodically so that you can execute quickly and effectively. As a saying goes, "If you fail to plan, you are planning to fail."

Using TAICHI

Sweepers work by monitoring incoming transactions to their sweeping address in the txpool, while TAICHI allows you to submit signed transactions directly to miners (SparkPool) without broadcasting through the public txpool, meaning the sweeper program will be invisible, and it is likely that your transaction will not be preempted by the sweeper bot (at least in my experience).

Image from TAICHI.NETWORK

The method here is to have all your transactions pre-signed in nonce order and programmatically submitted to TAICHI. Most sweepers only monitor the public txpool/mempool for incoming ETH transactions and do not call eth_getBalance on every new block (to save CPU cycles and RPC method call costs), meaning they will be oblivious to ETH sent to the account routed through a dedicated txpool and will not sweep it.

This requires you to do some math work, and if the math is executed correctly, the sweeper program attempting to preempt the transaction may fail! (Typically, I default the gas price to be a few percentage points higher than the "fast" category on GasNow, so miners are more likely to confirm your transaction in the next block.)

You can use MyCrypto offline to generate signed transactions and push them to TAICHI when ready, or create code using ethers.js (or other libraries) to create signed transactions.

Method 2: Using a Self-Destructing Smart Contract

Just like using the TAICHI method, we can use a smart contract to send ETH to the account without showing up in the public txpool. We do this by deploying a smart contract from a secure address and then structurally sending ETH to the leaked address (which will be an internal transaction).

By deploying this contract, we can send ETH along with the leaked address string in the constructor parameters. The contract works by creating the contract and self-destructing in the same transaction. Using selfdestruct() means we clear the blockchain state (as it is a one-time use contract) and forward ETH to the leaked address in one transaction. (Example)

Please note that while this method is effective, it incurs additional costs because what we are doing is not just sending ETH from one account to another. The cost of this method is about 70,000 gas, and with high gas prices, the transaction fee cost of using this method could reach 0.0112 ETH.

Method 3: Using Flashbots

Generally, we need to pay ETH to have a transaction confirmed (since transaction fees are paid by the sender). However, with the advent of Flashbots, we can more easily "bribe" miners with funds from another account at a 0 gas price (i.e., $0 transaction fee) to confirm the transaction, meaning we can transfer tokens out of the leaked address without paying gas fees in ETH, yes, that's right.

This strategy requires using 2 accounts, one being the leaked account and the other being the account bribing the miners.

The Flashbots team has released a project called Flashbots / searcher-sponsored-tx, which has the basic principles for setting up this strategy to confirm your transaction from both accounts.

Since we will use another account to pay the transaction fees, there is no need to deposit ETH into the compromised account.

To ensure that there is no ETH in the leaked account, we strongly recommend running a Burner bot.

We generally recommend using different RPC nodes for each instance and running this burner bot on more than one computer. For example, run the burner bot locally using Infura and run another burner bot on a remote server with another provider (like Quiknode). This way, you have a backup plan in case of high network latency or node issues (rate limiting, synchronization issues).

The code in Flashbots/searcher-sponsored-tx needs to be modified according to your specific needs, but this engine can help you rescue tokens from the leaked address. This Flashbots engine is flexible enough to support a single transfer() call or unstake() and transfer() calls.

If you are not very familiar with coding, you can also try using the @kendricktan/flashbots.tools website.