How to Beat an Ethereum Sweeper Script and Recover Your Assets

When your secrets are compromised, malicious actors often deploy a sweeper on your account to exploit any future activity associated with the address. This could occur if you attempt to deposit Ethereum (ETH) to salvage tokens, participate in an airdrop, or engage in any other transaction. This article delves into the methods by which users are swept and presents three unique approaches for rescuing un-swept funds, including staked assets.

There has been a notable rise in incidents where individuals pose as Telegram group administrators. These imposters offer assistance to users within the legitimate group’s main channel, despite not being authentic admins. They replicate admin profiles with slight variations in usernames, engaging in complex discussions to confuse users before sharing links to seemingly legitimate websites. These websites mimic authentic branding but ultimately request users’ seed phrases or private keys, resulting in the loss of cryptocurrency and the deployment of a sweeper on the compromised account.

How do Sweepers Work?

Sweepers are automated scripts or bots deployed by malicious actors to monitor and exploit compromised cryptocurrency addresses. These scripts continuously scan the blockchain for any incoming transactions or activities related to the compromised address. Once any new tokens or assets are detected in the compromised wallet, the sweeper automatically transfers them to the attacker’s controlled address. Sweepers operate swiftly and efficiently, aiming to capitalize on any opportunity to siphon funds from compromised accounts before the rightful owners can take action to secure their assets.

The scam would be for a bad actor to obtain assets that would then be locked, even though block explorer still had a price feed for the tokens — a popular one being Minerum (MNE). They would then publish the private key to this address (in some manner that looks innocent or a mistake) and wait for people to deposit ETH to the address, intended to use it as gas to move the tokens. The bad actor would have a sweeper on this account to swiftly move the deposited ETH to their own account. It’s theorized that the locked tokens are considered worthless, so they try to recoup some of that locked value from unsuspecting “greedy” users trying to take the [locked] tokens.

Nowadays we have, at least with a wider application, basic ETH sweepers being deployed on compromised addresses and also some groups using more advanced sweeper logic to sweep ERC20 tokens based on price feeds.

I was doing some recon research on a compromised address earlier this year and discovered that sweepers have continued to evolve:

i) The sweeper favors the asset that is the highest USD value — even if that means spending more in transaction fees to sweep it.

ii) The sweeper will use all the available ETH to maximize the swept value whilst also having a high percentage of being the “winning” transaction for the nonce.

iii) The sweeper has a matching engine to match staked tokens (ie: xKNCa = KNC) to their native token so that price feeds reflect on the staked token.

iv) The sweeper has its own internal nonce counter and periodically resets the nonce to eth.getTransactionCount() output if their highest nonce does not confirm within a timeframe (or is dropped/replaced by another).

v) If there is an asset with high value, desirable by the sweeper, there has been some activity to suggest the operator “sacrificing” some ETH by funding the addresses to attempt to quickly sweep the high-value asset from the account.

vi) Some sweepers do not sweep the assets if the USD value is below a threshold value, meaning you may not realize you have a sweeper on your account. Scary.

Sweeper, No Sweeping!

How do we beat a sweeper?

To start, you (a human) won’t be faster than code, so our solution will involve coding. There are a couple of different routes you can take — neither gives a 100% guarantee, but the odds are likely in your favor.

You will need to create a list of tokens that you want to attempt to rescue, ordered by priority, so that you can easily determine your plan. You will need to list:

• The token contract address

• Whether the token is staked (and if unstaking is timelocked or not)

• Whether the token is able to be transferred

• The tokens value (to the user or in USD terms to realize priority weighting)

It is critical that you go through this methodically so that you can execute this quickly and efficiently. As famously said: “If you fail to plan, you are planning to fail.”

Using TAICHI

The way sweepers work is by monitoring the txpool for incoming transactions to the address they are sweeping. They do this so that before that transaction is confirmed, they have already signed the transaction and are prepared to broadcast the transaction to sweep those funds.

TAICHI allows you to submit signed transactions directly to the miners (SparkPool) without it propagating through the public txpool, meaning sweepers will be blind and it is likely that your transaction will not be front-runned by a sweeper bot (at least in my experience).

The approach here is to have all your transactions pre-signed in nonce order and submit them to TAICHI programmatically. Most sweepers only monitor the public txpool/mempool for incoming ETH transactions and do not call eth_getBalance on every new block (to save on CPU cycles and RPC method calls), meaning they will be blind to the ETH being sent to the account via the private txpool route, and won’t sweep it.

This requires you to do some math to ensure the ETH you seed the address with for gas is wholly utilized on every signed transaction. If you do this math properly, a sweeper that attempts to front-run you may fail! (Usually, I default the gas price to be a few percentages higher than what BlockNative recommends so the miner will be more likely to confirm your transaction in the next block.)

You can make use of MyCrypto offline to generate the signed transactions and push them to TAICHI when you are ready, or create code using ethers.js (or another library) to create the signed transactions.

Using a self-destructing smart contract

Much like the method of using TAICHI, we can use a smart contract to get ETH into the account without it being obvious in the public txpool. We do this by deploying a smart contract from a safe address, and on the construct we send ETH to the compromised address (this will be an internal transaction).

pragma solidity >=0.7.0 <0.9.0;

contract MoveETH {
    constructor(address sendToAddress) payable {
        address payable addr = payable(address(sendToAddress));
        selfdestruct(addr);
    }
}

By deploying this contract, we can send ETH and the compromised address string in the constructor argument. This contract works by creating the contract and self-destructing in the same transaction. The use of selfdestruct() means we clear the blockchain state (since it's a one time use contract) and forward the ETH to the compromised address in 1 transaction.

Example: https://goerli.etherscan.io/tx/0x82ccb222eae55aaea73dd0efee1ea6ed7320f880889f280d4a343b8823f86692

Note that this method, whilst effective, does add additional cost as we are doing more operations than just sending ETH from one account to another. It costs about 70,000 gas. At high gas prices, it could cost ~0.0112ETH in only gas for this method to be used.

From here, we would broadcast pre-signed transactions from the compromised address via TAICHI (or a public node ensuring we are using all the ETH in the account so that a sweeper cannot frontrun us — or at least make it unlikely to be frontrunned as a sweeper would need to send more ETH to the account to pay a higher gas price).

Using Flashbots

Generally speaking, you will need ETH for a transaction to be mined (as transaction fees are paid for by the sender). However, thanks to Flashbots, we can much more easily get a transaction confirmed with 0 gas price (read $0.00 transaction fee) from the EOA by “bribing” the miner with funds from another account — meaning we can move tokens out of the compromised address without funding it with ETH for gas fees. Yes, that’s right!

This strategy requires two accounts — the compromised account, and an account to bribe the miner with.

The Flashbots group has published a project called Flashbots/searcher-sponsored-tx which shares the fundamentals of setting up this strategy to get your transactions confirmed from two accounts.

As we will be paying for the transaction with another account, we do not need the compromised account to have ETH in it. In fact, we don’t want ETH in it — because the last thing you want is for the scammer/sweeper to notice you’re trying to get some funds out, and then use ETH within the compromised account to beat you.

To ensure there’s no ETH in the compromised account, we highly recommend running a burner bot.

We generally advise running this burner bot on more than one machine, using different RPC nodes on each instance. For example, running a burner locally using Infura, and a burner on a remote server with another provider such as Quiknode. This so that you have a redundancy plan in case we have high network latency or node issues (rate limits, syncing issues).

The code in Flashbots/searcher-sponsored-tx will need to be altered for your specific needs, but the engine is there for you to rescue your tokens from a compromised address. The Flashbots engine is flexible enough to support a single transfer() call, or unstake() and transfer().

If you’re not too familiar with code, you can try @kendricktan/flashbots.tools website that gives you a UI to the flashbots functionality: https://flashbots.tools/

NOTE: If the above methods are too difficult and you still need assistance, we can assist you in the rescuing of funds for a gratuity of 10% (minimum $250) of the rescued funds. We would like to offer this for free to everyone, but we’ve received a massive influx of requests for help and our time is already thin as it is. Any proceeds from this service go towards us trying to make this industry a better and safer place!

Thank you for understanding.

If you’d like to move forward with this service, please reach out to Website: https://recuvahacksolution.pro or via WhatsApp: + 1(315) (756) -1228 with the subject line “ Requesting Assistance!”