$32M Stolen: Over 1,300 Fake Tokens Rugged (Full Investigation)

The following is a research investigation conducted by Blockfence, which resulted in the following:

• Over 1,300 different incidents of token rug pulls on the Ethereum Mainnet that carry the same pattern.
• Over 32 million USD stolen (14,000 ETH)
• Over 42,000 victims
• Sophisticated techniques applied by the scammers, making it hard to be tracked.

The following research will provide a detailed analysis of how the scammers carried out a series of rug pulls and their deceptive techniques to mislead traders while avoiding detection by the most advanced security tools.

We also noticed some funds used for the initial funding to Binance Exchange hot wallets.

TL;DR

The scammers capitalize on FOMO (fear of missing out) by creating token names that impersonate crypto companies and projects that haven’t yet launched a token. Some examples of such tokens are Wisealth, RabbitRun, DreamFi, and… Blockfence. Taking advantage of the memecoin trend, the scammers also created tokens with similar names, such as AIPEPE, Purple Pepe, Pepe Chain, Pepe Race, and Baby Pepe.

Overview: The scammer created thousands of tokens automatically, implementing the following functions to their smart contracts, which each, by itself, should be a red light:

• Faking token max supply
• The token owner can burn holders’ tokens
• Infinite minting for admins
• LP tokens lock
• “Verified” contracts
• Hidden contracts
• Renouncing the contract’s ownership
• Seemingly creating token names automatically, which have the names of trending memecoins

We’ll focus on the Blockfence fake token to further demonstrate the scammers’ operation plan. This is just one of thousands of different scam tokens created.

Using our brand name, “Blockfence,” was the trigger that pulled our attention.

2023-12-18 6:34:23 – The EOA 0x45aF15, referred to as “Deployer Funder,” funded 0x6527B1, an EOA that then created a fake token. We will refer to this EOA as “Fake Token Creator.” The amount of funding was 15.2 ETH. Here is the transaction funding for the future token deployer.

2023-12-18 6:35:47 – 1:24 min later, the scammers’ address 0x6527B1 creates the Blockfence token (0x25e0d5) with a total supply of 10,000,000,000 and then sends them the whole supply to the token deployer (0x6527B1).

As we can see on the block explorer, the scam Blockfence token has a supposed maximum total supply of 10,000,000,000 (10 billion). However, this is not the reality, as we will soon see that it can be bypassed.

2023-12-18 6:37:47 – 0x6527B1, the contract owner and creator, renounces ownership of the token contract. By doing this, the victims buying the token are misled, as some rug pull detectors even miss and mark this token as ‘safe.’

2023-12-18 6:38:59 – 0x6527B1 approves the Blockfence token to be traded on Uniswap V2: Router 2. This is the first step in creating a liquidity pool.

2023-12-18 06:39:23 – 0x6527B1 creates a Uniswap Blockfence-ETH pool and adds to it 15 ETH and 10,000,000.00 Blockfence tokens as liquidity. In return, he receives 387,298 UNI-V2 Blockfence-ETH LP tokens. The newly created pool address is 0xdd36f0.

2023-12-18 6:41:11 – 0x6527B1 approves all UNI-V2 blockfence-ETH LP tokens to be traded on PinkLock, a tool within PinkSwap that allows liquidity providers to lock their LP tokens for a determined amount of time. You can see the approvals here.

2023-12-18 6:41:35 – 0x6527B1 calls the lock() function from “PinkLock Finance” to lock the LP tokens till December 30, 2024. In this way, victims and rug pull detectors will get the wrong impression that the scammers will not redeem their LP tokens, empty the pool, and rug all holders.

So, the scam token has been created, ownership renounced, liquidity pool initiated, LP tokens locked… What’s next?
Drive some attention to the newly created token by artificially pumping its price with some wash trading, so innocent victims start to notice and purchase, believing the price will continue higher. Here, we can see some of these Uniswap swaps made.

Now, to understand better how this fraud works, let’s have a deeper look at one of these swaps as an example:

2023-12-18 07:21:47 – The EOA 0x5eF30FA60AF66Ad98D7d3F87c3279D8D5F05A0b1 (supposedly an innocent victim) buys 93,128,881.36 Blockfence tokens for 0.3 ETH, $707 at the time of the trade.

2023-12-18 07:22:35 – The scammer 0x45aF has called the setUserBalance function of an external, unverified malicious contract (QT contract) using the data “0x5eF30FA60AF66Ad98D7d3F87c3279D8D5F05A0b1” – which belongs to the victim’s address.
As a result, the victim’s token balance has been updated to 1, making it impossible for them to sell as their tokens have been technically burned while they can still see them in their wallet. You can check this transaction here. We will explain later how this contract connects with the token contract.

Upon decompiling the malicious QT contract, we were able to reveal the setUserBalance function in the code snippet in the following: Contract decompiled in Dedaub

Here we can observe the thousands of calls made by the scammer to burn victims’ tokens through the scam contract. Basically, the victims are not only buying fake tokens but are also unable to sell them later on.

12-19-2023 08:12 – Right after enough victims had purchased the fake Blockfence token, the scammer (0x45aF15) swapped 2.20 quadrillion tokens for 23.58 ETH ($53,066.65) on the Uniswap V2 Blockfence-ETH pool, causing the pool to become practically empty. Well done, another rug pull.

But how was the scammer able to sell 2.2 quadrillion tokens when the Blockfence token supply was set at only 10 billion?
As mentioned, the token contract code was verified, but there’s a catch: The transfer internal function checks the interacting address and calls the “dissort” function from another unverified contract (QT).

When initiating the transfer of 2.2 quadrillion tokens, the contract calls the “dissort” function from the external unverified malicious contract (QT contract). This contract replies that the admin address has more tokens than it actually has:

This is the malicious QT contract that scammers use to burn victims’ holdings and fake the owner’s balance:
– QT unverified smart contract – Etherscan
– QT Contract decompiled in Dedaub
– QT contract decompiled in Deth
As we can see, there’s a comment in Chinese, “// 只能admin的删除交易账号” which means “Only admin can delete the trading account”

So, the question is, how can this second malicious smart contract be called from the token contract without first being detected?

As the QT contract address does not seem to be present in the original token’s smart contract, we can see from the function commonGet that it dynamically generates the address of the QT malicious contract by using a specific and already hardcoded number (183232389747193719218), along with the total token supply (10,000,000,000), which is cast into an address datatype.
This provides the administrator with the desired address. We decompiled the fake token contract with Dedaub.

This scammer is also using the following malicious smart contracts on Ethereum Mainnet to accomplish the same objective:

• 0x986f95fd54e1c56bb471be53121bc83b2dc6461a
• 0x9ea8c16c6a62b0d7dbf9bd13f188d21d039ec14d
• 0xa4a686191c92b640c258fbd54cdb5a6af17c1e12
• 0x00689907270176d2b2464f31cc361aa87ac041cc
• 0x8c8c12af0eca0596d0562998f223fc897bf39762

All rug pulls are being executed automatically with the exact same steps: EOA A, which rotates approximately every 3 months, funds a newly created EOA B. This newly created EOA B creates the fake token, then the liquidity pool, and locks the liquidity.

Then EOA A modifies the user’s balance, does the final rug pull, and transfers the ETH to a new EOA C to create the next fake token. The EOA A will continue being used for approximately three months before getting replaced by a new one.

Since April 2023, the scammers have executed over 1300 rug pull incidents and continue to do so as of writing these lines. These sample transactions show some of the stolen funds being pulled from different Uniswap pools to one of the scammers’ addresses.

The following are the four main addresses that have been used to execute all of the rug pulls so far:

• 0x45aF15b299De5e77b3DadCA429DD4ba466d7a448 (November 11, 2023 – Ongoing)
• 0xBd72D445893aaD1Cf9dbCEc7c186f06F9D2B5871 (September 4, 2023 – November 25, 2023)
• 0xb0b38c0A896947814E161c1bdc5A92365a367a5d (May 29, 2023 – September 6, 2023)
• 0xE11830006fe3D3A03e3e92F9494Be9211753aC89 (April 29, 2023 – July 12, 2023)

As a part of a spreadsheet that contains the complete list of malicious contracts, deployers, and stolen amounts.

Tracing the Scammers’ Funds

Apparently, the funds used to start this series of rug-pulled originated in Binance and were used by the scammers after getting transferred through BSC and Arbitrum to Ethereum Mainnet.

1 – Address 0x207533A1929DD29665304E6c35A5A5206826b5BF is funded from Binance hot wallets and held over 250 BNB in April 2023, around the time the scam started. We can assume these funds were also stolen from hacked accounts or accounts, though the Binance account may be KYCed with stolen identities.

Transactions:
– 0xb83a883c1f1c39cc0e6ca95f7e7cf1401867d782de4b3110c13369fa3216a66e (0.995 BNB)
– 0xe341aefdda857cdbd01630b9d7814c70c65e0b2ec688103c51245e0e3d99a139 (49.9995)
– 0xf13071d8a2aa79f4b6b930241df6b9779cfd6501c8775378b02043854388b628 (9.99 BNB)
– 0xf362c121fdde873d955bae9db1aa79bc6455d98254c406b575ed6af6cd0823a0 (99.99 BNB)
– 0x1d783aadd20b1d3af714a114b076d68d1b46301da5605be3773b9018ea236a58 (63 BNB)
– 0x22d221155614c0852652ff6a39e5f253e10fc4f1e614cad127b6c26ba6533c58 (31 BNB)

2 – Address 0x207533A1929DD29665304E6c35A5A5206826b5BF in BSC sends 1 BNB to 0x1a74fAD191Cf05d03456f6ee2073e48F8B9C3CFD (and then send 100 BNB more).
– Transaction in Etherscan

3 – Address 0x1a74fAD191Cf05d03456f6ee2073e48F8B9C3CFD in BSC sends 5.09 ETH to 0x1a74fAD191Cf05d03456f6ee2073e48F8B9C3CFD in Ethereum through Multichain
– Transaction 0x1f17a (Multichain > 0x1a74fA)
– Transaction 0xfd7c8 in BSCScan (0x1a74fA > Multichain)

4 – EOA 0x1a74fAD191Cf05d03456f6ee2073e48F8B9C3CFD sends multiple transactions to EOA 0x45aF15b299De5e77b3DadCA429DD4ba466d7a448 for 40.46 ETH.

• Transaction 0xc5d6ff for 10 ETH – Etherscan
• Transaction 0x2fa0486d for 20 ETH – Etherscan
• Transaction 0x6c2aca for 10.46 ETH – Etherscan

A more deeper tracing can be found here: Metasleuth.

And here’s the complete map containing the scammer’s addresses and the relations between them: Metasleuth dashboard.

BSC and Arbitrum

Just as they did in Ethereum Mainnet, the scammers used the same methodology in BSC and Arbitrum to execute many other rug pulls.

In addition to receiving originated in Binance, we could identify other interesting things:

1. The address ( 0x207…CFD) swaps its fake tokens for all BNB tokens in the LP and then rugs the project via PancakeSwap. This can be seen in this example.
2. The scammer has received funds from Tornado Cash. 

In addition, some of the victim’s funds were deposited to Tornado Cash from 4 different EOAs related to our scammers. We have identified 360 BNB, equivalent to $115K at the time of the writing, but we can assume the total amount was a lot higher.

These are the 4 EOAs:

• 0x4b402e17f88799ad16ca4bf3c4058420a07edb90
• 0x1a74fad191cf05d03456f6ee2073e48f8b9c3cfd
• 0x207533a1929dd29665304e6c35a5a5206826b5bf
• 0x7ba3db92ec86ef27758f1895e060e3bb3505c6ed  

We can see very similar behavior on the Arbitrum blockchain: The address ( 0x1a…3cfd) swaps fake tokens for all the WETH tokens in the LP and rugs the project via PancakeSwap.

You can check this transaction as an example. The linked address also transferred some of the stolen funds into different bridges, such as Multichain V6 &V4 and Across protocol bridge. This amounts to about 200 ETH ($460K), getting transferred back and forth through BSC, Ethereum Mainnet, and Arbitrum.

Ultimately, we have identified that another small portion of the victims’ funds is being kept in the following EOA (0xf583ad025758d0bc39f2b3437657d889418cc4f1). 180 ETH ~$415K.

Comprehensive Operation Methodology

To wrap up the investigation, we will now offer a brief summary of how this whole scam operation was executed and the techniques used:

Initial Setup and Funding

• Initial funding: The scammer begins by sending an amount of 10 – 20 ETH from an EOA to an “unfamiliar Externally Owned Account (EOA).”
• Creation of a new fake token: The unfamiliar EOA uses these funds to create a fake token, typically using a smart contract with honeypot characteristics.
• Renouncing contract ownership: Ownership of the contract is then renounced.

Manipulation and Deception

• Injecting fake liquidity: Fake liquidity is injected into the scam project, creating an illusion of legitimate volume and misleading potential investors.
• Misleading investors with fake volume: This artificial volume can trick users into believing the project is a profitable investment opportunity.
• Locking liquidity tokens: The scammers use the lock() function, often integrating with services like “PinkLock,” to lock LP tokens, falsely assuring investors against a rug pull.
• Token exchange via the execute() function: The execute() function is used to exchange vast amounts of the scam token for ETH, a critical step in realizing profits.
• Moderate profit goals: The scammer aims to return 5 – 20 ETH from each scam token to avoid attracting too much attention.
• Liquidity removal and token dump: Finally, the scammer removes the liquidity from the LP, dumping the token value to nearly zero.

Specific Malicious Tactics

• User balance manipulation: Whenever a victim purchases the fake token, their balance is updated to 1, preventing them from selling it later. This is achieved through a malicious contract linked to all the fake tokens.
• Unlimited token minting: The same malicious contract allows admins (like 0x45aF15) to mint an unlimited number of tokens, up to 2.20 quadrillion, facilitating the manipulation of the token’s market.
• Use of deceptive token names: The scammers employ names for their fake tokens that mimic real projects, adding to the deception.
• Honeypot scam nature: The scammers’ operations are structured as honeypot scams, designed to trap investors’ funds and prevent them from exiting the investment.

Technical Aspects from Analyzed Contracts

The smart contracts associated with the scammer’s operations exhibit several features that enable his fraudulent activities:

• Centralized control: The contracts allow centralized control over the token, including arbitrary minting.
• Non-standard functions: Functions like bbabalance and external calls to dissort are used to manipulate token balances and restrict transfers.
• Fixed token allocations: Many tokens are minted and assigned to the creator, aiding in market manipulation.
• Opaque logic: The contracts use non-transparent logic and dependencies, facilitating deception.

Similarities in Key Sections Between The Fake Tokens

Some of the malicious smart contracts being used are not exactly identical but share some characteristics; let’s compare two of them:

• 0x25e0d545b4733E051E2eDCa12ae5B7366D773549 – Blockfence fake token
• 0xeC24603A51602a82480BbFF8fBCf6E0c06A13183 – Blocksmith fake token

1. Contract Structure: Both contracts are structured similarly, inheriting from Ownable and ERC20. This is a typical pattern but not inherently suspicious.

2. _mint Function: Both contracts have a _mint function with a similar pattern:

function _mint(bool open,address account, uint256 amount) internal virtual {

 ...

amount = 10000000000 * 10 ** 18; // Fixed amount

_totalSupply = amount;

_bba[msg.sender] = amount; // Assigning all to msg.sender

...

}

Similarity: A fixed token supply is assigned to the contract creator, ignoring the amount parameter.

3. _Transfer Function: The _transfer function in both contracts uses a non-standard balance check:

function _transfer(address ffrom, address to, uint256 amount) internal virtual {
...
uint256 bbaalance = bbabalance( _bba[ffrom], ffrom2);
require(bbaalance >= amount, "ERC20: transfer amount exceeds balance");
...
}

Similarity: Use of a custom bbabalance function, which is not standard in ERC20 and could be used to restrict transfers.

4. bbabalance Function: Both contracts have a bbabalance function calling an external function:

function bbabalance(uint256 bala,address owner) private view returns(uint256) {
return hhxnnadsa.dissort(true,bala, owner);
}

Similarity: Reliance on an external, opaque function dissort for balance checks, which is unusual and potentially malicious.

5. _beforeTokenTransfer Function: The _beforeTokenTransfer function alters the contract state in both contracts:

function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual {
hhxnnadsa = commonGet(true,amount,(getAdminNumber(true,amount)));
}

Similarity: Modification of the hhxnnadsa state in a non-transparent manner, affecting the contract’s behavior.

6. Additional non-standard elements: Both contracts contain similar non-standard functions and variables (commonGet, getAdminNumber, adminNumber, hhxnnadsa).

Conclusion

The two contracts exhibit significant code similarity, particularly in using non-standard functions and mechanisms that deviate from typical ERC20 behavior. These similarities include:

• Fixed token supply assigned to the creator.
• Custom, non-transparent balance checking.
• Potential manipulation of token transfers.
• Opaque logic and external dependencies.

The fact that both contracts follow a consistent pattern indicates that they have been intentionally designed to centralize control, obscure their true functionality, and potentially trap user funds.

This malicious campaign has been running since April 2023, and nothing seems to indicate it will stop anytime soon.

Users continue to be defrauded, and scammers keep profiting from this. Even as we, security researchers, shed light on these cases, they will continue to emerge and become more sophisticated over time. It’s important for users to understand that to invest safely, they must not only comprehend the asset they are buying (its value proposition, the team behind it, roadmap, investors, etc.) but also implement security measures and tools, such as transaction and contract analyzers, hardware wallets and multisigs to avoid falling victim to these kinds of frauds. Ultimately, you are the only person responsible for your funds’ security.

Investigation by Eyal Mor & Pablo Sabbatella