In this post, we detail a certain type of rug pull wherein scammers apparently create tokens out of thin air before dumping them on unsuspecting investors.

Our analysis links these scams to a single group responsible for orchestrating over 200 exit scams.

In these ultimately fraudulent schemes, the creators launch a new ERC-20 token and create a Uniswap V2 liquidity pool for it. Initially, the pool contains pre-mined tokens and a certain amount of wETH. As unsuspecting users (or automated contracts, as we'll see) purchase the new tokens, attackers drain the wETH from the liquidity pool.

However, the tokens they extract seem to materialize out of nowhere. The attackers design – and repeatedly execute – a "game-within-a-game" to deceive users with basic technical skills who can navigate Etherscan, using diversions to mask the exit scam and its mechanisms. The tokens do not appear in the total supply and do not activate the usual transfer event. This renders them essentially invisible on Etherscan and makes the scam very difficult to detect without advanced analysis.

Scrutinizing the Scam

Let's focus on one example – $MUMI – to shed light on the dynamics of this specific type of exit scam. The scams hinge on a transaction in which the fraudster utilizes a massive amount of secretly-minted tokens to siphon off assets from the liquidity pool. In the case of MUMI, the attacker used 416,483,104,164,831 MUMI tokens to obtain around 9.736 wETH, severely impacting the pool's liquidity.

This incident, however, is merely the culminating step of a much larger and more complex fraudulent operation. To understand the full extent of the scam, we need to dig deeper.

Deploying the Tokens

At 7:52 a.m. on March 6 (UTC), the perpetrator's address (0x8AF8) executed the deployment of a contract named MUMI (officially termed MultiMixer AI) under the ERC-20 standard, with the contract address 0x4894. An initial minting of 420,690,000 tokens was conducted, all of which were assigned to the account which deployed the contract.

The quantity of pre-mined token matches the contract’s source code:

Adding Liquidity

At 8:00 AM, just eight minutes following the token's creation, 0x8AF8 proceeded to add liquidity to the pool. This address activated the openTrading function within the token contract, thus establishing a MUMI-wETH liquidity pool via Uniswap V2. The entire batch of pre-mined tokens, alongside 3 ETH, was deposited into the pool, resulting in an acquisition of 1.036 LP tokens.

From the original allocation of 420,690,000 tokens designated for liquidity, 63,103,500 were redirected back to the token contract (address 0x4894). The contract's code indicates that a specific fee is imposed on each token transfer, collected directly by the token contract itself, as seen in the _transfer function.

Although a separate fee collection address (0x7ffb) was defined within the contract, the fees continued to be allocated to the token contract instead. This discrepancy meant that the actual amount of MUMI tokens integrated into the liquidity pool was 357,586,500, reflecting the deduction of transaction fees, diverging from the original meme number of 420,690,000.

Locking Liquidity

At 8:01, just one minute after the creation of the pool, the attacker's address (0x8AF8) locked all 1.036 LP tokens obtained through their provision of liquidity.

Locking these LP tokens theoretically ensured that all MUMI tokens under the control of the attacker (except those allocated for transaction fees) were now embedded within the liquidity pool. This act was supposed to prevent the attacker from performing the rug pull they would eventually pull off. Locking LP tokens is a common strategy employed by many projects to build trust among participants. This is meant to reassure investors about the integrity of new tokens.

But is this safety measure as reliable as it seems? You can probably guess the answer…

The Rug is Pulled

At 8:10, a secondary malicious address (0x9DF4) was activated, utilizing the previously specified tax address (0x7ffb) as per the token contract.

There are several points to note here:

1. The tax contract’s initiating address is distinct from that of the token, hinting at possible attempts by the project's team to separate their activities across different addresses to reduce direct linkage and complicating tracking efforts.
2. The tax address contract is not open-source, implying the potential existence of undisclosed operations with the tax address.
3. The tax contract was deployed after the token contract, with the tax address hard-coded into the token contract. This indicates that the project team could anticipate the tax contract address since the CREATE command is deterministic based on the creator address and nonce, allowing the project team to predict the contract address beforehand through creator address simulation.

Historically, many exit scams have been orchestrated via such tax addresses, aligning with the suspicious patterns noted above.

At 11:00 AM, three hours post-token launch, the second attacker address (0x9DF4) commenced the rug pull, leveraging the swapExactETHForTokens method within the tax contract (0x77fb). This enabled the exchange of 416,483,104,164,831 MUMI tokens for roughly 9.736 ETH, effectively draining the liquidity from the pool.

As the tax contract (0x77fb) remains closed-source, we decompiled its bytecode.

The decompiled swapExactETHForTokens function within the tax contract primarily facilitates the conversion of a defined quantity of xt (as set by the deployer) through the UniswapV2 router, transforming the contract's MUMI tokens into ETH, which are then dispatched to the designated _manualSwap address.

The storage address housing the _manualSwap address is 0x0. Upon querying using the json-rpc getStorageAt command, we confirmed that the _manualSwap address corresponds precisely to the tax contract's (0x77fb) deployer: Attacker 2 (0x9DF4).

The input parameter "xt" of this rugpull transaction amounted to 420,690,000,000,000,000,000,000, equivalent to 420,690,000,000,000 MUMI tokens (MUMI tokens have a decimal of 9).

Ultimately, the project team drained the wETH within the liquidity pool and completed the entire exit scam using 420,690,000,000,000 MUMI tokens. However, a critical question arises: where did the tax contract (0x77fb) acquire such a vast number of MUMI tokens?

Recall that at the time of the MUMI token's initial creation the total minted supply was recorded at 420,690,000. Post-scam analysis still showed the MUMI token contract reflecting the same total supply of 420,690,000 (represented as 420,690,000,000,000,000 when accounting for the nine decimal places).

The tax contract (0x77fb) held an amount of MUMI tokens vastly surpassing the declared total supply in the token contract (420,690,000,000,000). These tokens appeared inexplicably, defying logical supply constraints. Moreover, it was established earlier that the designated tax address 0x77fb, originally meant to collect transaction fees from MUMI token transfers, did not fulfill this role. Instead, these fees were rerouted to the token contract.

In order to investigate the token source of the tax contract (0x7ffb), we examined its ERC-20 transfer event history.

Among the six documented transfer events associated with 0x77fb, every recorded instance originated solely from the tax contract itself (0x7ffb), without a single event marking the receipt of MUMI tokens. This initial analysis suggests that, inexplicably, the tax contract's MUMI tokens materialized from nowhere.

Therefore, the substantial MUMI tokens seemingly originating from thin air within the tax contract (0x7ffb) address possess two notable characteristics:

1. They do not affect the total supply metric within the MUMI token's framework.
2. Their supply increase failed to initiate the standard Transfer event.

There must, therefore, be a hidden mechanism within the MUMI token contract—a backdoor allowing the covert adjustment of the balance variable. This manipulation skirts changes to the totalSupply and circumvents the activation of Transfer events, revealing a deceitful or non-standard implementation of the ERC-20 standard. In essence, this anomaly is proof of hidden token minting activities by the project's insiders, invisible to conventional supply and event tracking methods.

The next step involves verifying the aforementioned hypothesis. We conducted a direct search for the keyword "balance" within the MUMI token contract source code.

We identified a private function labeled swapTokensForEth. This function, accepting an input parameter named tokenAmount of the type uint256, alters the internal state variable _taxWallet, which correlates to the MUMI token holdings of the tax contract (0x7ffb). Specifically, in the fifth line of the function, the tokenAmount is amplified by 10 to the power of _decimals — effectively multiplying the tokenAmount by a billion (1,000,000,000). Following this inflation, the specified amount of MUMI tokens undergoes conversion into ETH via the liquidity pool, with the resultant ETH being transferred to the token contract (0x4894).

Upon searching for the keyword “swapTokenForEth”, we discovered that this function is called within the _transfer function.

A closer examination of the calling conditions reveals:

1. The function activates when the recipient of a transfer is the MUMI-WETH liquidity pool.
2. The swapTokensForEth operation is engaged only after transactions surpassing a threshold defined by _preventSwapBefore (set to five times) are conducted.
3. The tokenAmount involved is determined by the lesser of two quantities: the MUMI balance held by the token contract or the _maxTaxSwap limit.

When a user converts wETH to MUMI tokens in the liquidity pool more than five times, the system secretly mints tokens for the tax address. A portion of these freshly minted tokens is subsequently converted into ETH and stored in the token contract's reserves.

To external observers, this mechanism appears to operate under the guise of regular tax collection, wherein the project seemingly accrues ETH incrementally from taxes, storing these funds within the token contract.

This is intended for users to witness, leading them to believe that this represents the source of the project's profits. However, behind the scenes, once the user's transaction count reaches five, the account balance is directly manipulated, and the liquidity pool is drained.

Profiting from the Process

Following the invocation of the swapTokensForEth function, the token contract's _transfer function subsequently triggers sendETHToFee, which facilitates the transfer of ETH, accumulated from the tax operations within the token address, directly to the tax contract (0x77fb).

This ETH, now held in the tax contract (0x77fb), is accessible for withdrawal through a rescue function, specifically included for this purpose within the contract's architecture.

One of the most recent profitable transactions in the exit scam looked like:

This transaction unfolded in two stages. The initial swap exchanged 4,164,831 MUMI tokens for 0.349 ETH. The subsequent swap traded 416,483,100,000,000 MUMI tokens for 9.368 ETH. The latter swap’s major discrepancy, where 420,690,000,000,000 tokens are referenced below, stems from a portion of these tokens being redirected as tax to the token contract (0x4894).

The first swap is actually a part of the second swap process. Upon the token's transfer from the tax contract (0x7ffb) to the liquidity pool contract, the trigger condition for the backdoor function within the token contract is met, resulting in the invocation of swapTokensForEth. The first swap initiated by this function does not constitute a critical step in this scam.

The entire narrative of this exit scam, from its inception, through liquidity creation, and culminating in the sweeping rug pull of MUMI tokens, unfolds over a brief span of roughly three hours. The operation culminates with a return of 9.7 ETH. When we tally the expenses — 3 ETH for establishing liquidity, an additional 3 ETH for acquiring MUMI tokens from the pool for setup, and slightly under 0.5 ETH for the combined costs of contract deployment and transaction initiation — the total investment tallies to approximately 6.5 ETH ($21,617 at the time of writing). This results in a profit margin exceeding 50%.

Additional Transactions and Targeting Mechanisms

In addition to the core operations of the scam, there were five other instances where the attacker exchanged ETH for MUMI. The details of these transactions are documented here:

1. Transaction 1 on Etherscan
2. Transaction 2 on Etherscan
3. Transaction 3 on Etherscan
4. Transaction 4 on Etherscan
5. Transaction 5 on Etherscan

Through an examination of the externally-owned account (EOA) addresses interacting within the liquidity pools, it was observed that a considerable number of these addresses are associated with newly-deployed bots. The rapid pace at which the scam unfolded suggests that it was potentially designed to prey upon these bots and automated scripts.

The elaborate setup — ranging from the complex and potentially unnecessary contract arrangements to the strategic locking of liquidity, coupled with the suspicious activities of addresses exchanging ETH for MUMI tokens — suggests the creation of a façade orchestrated to sidestep the security measures of anti-fraud systems deployed by bot developers.

All proceeds earned from the scam were ultimately transferred by the secondary attack address (0x9dF4) to a common fund sinking address (0xDF1a). This address also features prominently in the initial funding and concluding phases of numerous recent exit scams, hinting at a centralized orchestrator.

A preliminary analysis highlighted that this address became active around two months prior and has been associated with over 7,000 transactions thus far. Its engagements include interactions with more than 200 different tokens. The transaction histories for about 40 of these tokens reveal a consistent pattern: each associated liquidity pool underwent a transaction wherein the amount of tokens swapped significantly surpassed the total token supply, leading to a swift and significant depletion of ETH.

Regarding the origins of these dubious activities, we also examined the deployment transactions for tokens like Zhonghua and TOPG.

Zhonghua ($中華) deployment transaction. Source: Etherscan

TOPG ($G) deployment transaction. Source: Etherscan

It can be concluded that this address effectively functions as a large-scale automated "exit scam" harvester, targeting new bots on-chain.

This address is still active.

Conclusion

If a token mechanism allows for the creation of new tokens without adjusting the totalSupply and bypassing the Transfer event, it complicates the ability to identify secret token minting. This places the security of the token in the hands of the project team's integrity, a high-risk bet to take.

To mitigate these risks, it would be beneficial to refine token standards or develop a new method that can accurately track changes in a token's total supply and ensure the transparency of all modifications. Relying solely on event logs for monitoring token status updates has shown to be insufficient.

Moreover, maintaining alertness is crucial, as while the community's awareness of scams is improving, the tactics employed by attackers are becoming increasingly sophisticated. This ongoing cat-and-mouse game is proof of the importance of education and analysis for those navigating the Web3 world.