Tamás Kelemen

Tamás Kelemen

15min read

Predicting Blockchain Sybil Attacks with CUBE3.AI

Predicting blockchain Sybil attacks with CUBE3.AI is a critical component for ensuring trustlessness, decentralisation, and gaining network effects for protocols and businesses. Detecting fraudulent addresses and contract activity reduces the collapse of chain integrity from threats like 51% attacks, rug pulls, information manipulation, identity manipulation as well as general network congestion.

In the past, we have called out fraudulent bots detected across web2. In this article, we’ll examine two recent web3 examples of how CUBE3 models detected Sybil attacks that effectively bypassed the sell-limits and referral rewards. We detail tactics used by bad actors, and how to mitigate future risk.

Predictive Sybil Attack Summary

On May 9th and May 15th, CUBE3’s AI model detected over 2,000% spike in the number of newly deployed malicious contracts targeting projects. Typically, we observe a daily average of two-digit suspicious deployments on EVM compatible chains like Binance, but on just these days in particular, we reported over 2,500 malicious contracts targeting projects on Binance alone.

  • May 9th: Our investigation revealed that the vast majority of detections were linked to a single hack. As part of a Sybil attack, the attacker deployed 1,220 helper contracts, all sharing the exact same bytecode.
  • May 15th: Similar tactics were used targeting AutochainMining contract. The attack was carried out by leveraging a flash loan from PancakeSwapV3 and deploying 1,000 helper contracts with identical bytecode to exploit the referral reward mechanism of the victim contract.
  • June 14th: CUBE3 detected the attacker claimed the mining rewards for each helper contract as expected.

Because the Application Binary Interface (ABI) of the exploit contracts have a 74% similarity, we have detailed how bad actors use Sybil attacks in similar ways to take advantage of protocols and communities below.

What is a Sybil Attack and Why Does it Matter?

Before digging into the details of the detected exploits, let’s define a Sybil attack in the context of blockchain and decentralised networks. 

A blockchain Sybil attack is where a single entity creates and operates multiple fake identities or nodes within the network. The purpose of such an attack is to gain advantage of the network or a protocol by making each node appear as a separate participant, while in reality, they are all controlled by the same entity.

Without Sybil resistance, a blockchain network is vulnerable to various attacks, which can lead to total failure of assets and community in three ways:

  1. Network Disruption: Basic network instability leads to delays, congestion, or complete failure.
  2. Security Breaches: Transactions and fraudulent data compromise the network making it vulnerable to attack.
  3. Loss of Trust: Decline in network adoption and participation due to lack of confidence.

CUBE3 Sybil Attack Detection #1 — May 9th, 2024

On May 9th, CUBE3 detected a malicious contract four seconds after it was deployed[1.2]: 

A few hours later, the helper contracts were deployed and detected 11 seconds after deployment [1.3]:

Interestingly, it’s victim contract was a previously flagged weeks earlier as a potential rug pull token called UBC: 

Several UBC elements raised suspicions about the token’s intentions. Notably, the code limits the maximum sell amount to 0.001% of the seller’s balance. Although, addressing the token is beyond the scope of this analysis, it is notable that with one malicious contract we are able to map suspicious activity across the ecosystem.

The original attacker address was funded from Tornado Cash, sending funds directly to the attacker address [2.1], and also indirectly [2.2] through another EOA [2.3]. 

Phase 1 — Preparation

1.1 Distributing tokens

As a first step, the attacker called the addUser function of the exploit contract multiple times [3.1]. This function distributes UBC tokens and liquidity pool tokens of PancakeSwap V2: UBC-BSC-USD 7 to the addresses on which the helper contracts will be deployed later.

The attacker utilised the CREATE2 opcode, to determine the addresses of contracts that hadn’t been deployed yet. This opcode allows for a more predictable method of determining an address where a contract will be deployed in the future. This level of predictability enabled the attacker to distribute tokens to addresses ahead of the helper contracts’ deployment.

(more on CREATE2: https://docs.openzeppelin.com/cli/2.8/deploying-with-create2)

1.2 Deployment of Helper Contracts and Approvers

The attacker called initUser function on exploit contract multiple times [3.2], each call has the following results:

  1. exploit contract deploys a new helper contract [3.3]
  2. helper contract gives infinite approval for the exploit contract’s address on Binance-Peg BSC-USD (BSC-USD)
  3. helper contract gives infinite approval for the exploit contract’s address on UBC
  4. helper contract gives infinite approval for the exploit contract’s address on PancakeSwap V2: UBC-BSC-USD 7
  5. helper contract gets selfdestructed, gas reward goes to exploit contract address
  6. repeat from step 1 as many times as instructed in the function call

1.3 UBC Dust Transfers

In the next step the attacker triggered a function in the exploit contract with multiple transactions [3.4], which sent just 1 token from each helper address to PancakeSwap V2: UBC-BSC-USD 7 liquidity pool.

Phase 2 — Sybil Attack Execution

In the second phase [3.5] of the attack, the exploit contract requested a flash loan of 200,000 BSC-USD from PancakeV3Pool. Using these borrowed funds, the exploit contract executed a series of carefully calculated swaps between UBC and BSC-USD, each time depleting more BSC-USD from the liquidity pool. This process utilised the 1,220 deployed helper contracts, each acting as an individual entity, effectively bypassing the sell limit imposed by the token.

May 9th Sybil Attack Aftermath

At the start of the execution BSC-USD dropped from $56,573 to $4,814, indicating a $51,759 reduction in the pool.[3.6]

The attacker deposited 25 BNB into Tornado Cash, distributed across seven transactions [4], totaling around $14,000, assuming a BNB price of $580 at the time of the attack.

CUBE3 Sybil Attack Detection #2— May 15th, 2024

On May 15, another and extremely similar Sybil attack was launched with exploiting a protocol’s referral reward mechanism[5]. Once again, CUBE3 detected the attacker contract[5.2] 11 seconds after deployment. The helper contract was deployed 30 minutes after the initial contract and detected in under 30 seconds by CUBE3.[5.3]

The target of this exploit was AutochainMining contract. Specifically the component of the Autochain staking protocol on Binance, which promises monthly payouts for users who stake assets in the AutochainMining contract. When a user locks tokens in the protocol, a small portion of the locked tokens is sent to the Autochain team as a fee. Additionally, users can specify a referrer, who receives a small referral reward. This referral system likely aims to motivate users to introduce new participants to the protocol.

We have not verified the legitimacy of Autochain
Always do your own research before using a protocol.

As we will discuss later, the Autochain referral reward mechanism was exploited by the attacker. 

Phase 1 — Sybil Attack Preparation

During the preparation phase, the attacker deployed 1,000 helper contracts in 10 transactions [6.1] by calling addUser function of the exploit contract, and transferred 50 TFK tokens [6.2] to each helper contract.

Phase 2 — Sybil Attack Staking

The attacker called the 0x2b7392e7 function of the exploit contract [7], which triggered the execution. The attacker performed the following actions for each helper contract:

  1. Exploit contract transfers 100 BSC-USD to helper contract
  2. Helper contract calls mining function of AutochainMining contract with referrer=exploit address, which results in:
  3. Helper contract sends 100 BSC-USD from helper contract to AutochainMining
  4. AutochainMining swaps 76 BSC-USD to ATC at actual price
  5. AutochainMining sends 10 BSC-USD to exploit address as referrer reward
  6. AutochainMining sends 2 + 12 BSC-USD to Autochain system as “reward” (fee)
  7. Helper contract calls AutochainMining.swap with 50 tokens, which:
  8. sends 50 FKD from helper contract to AutochainMining
  9. sends 50 ATC from AutochainMining to helper contract
  10. Helper contract sends 50 ATC to exploit contract

This way the Exploit contract was able to stake certain amount of assets in AutochainMining, while receiving 10% of the invested value as referral reward.

Phase 3 — Sybil Addresses Claim Mining Reward

Based on the source code of AutochainMining, users can access their payouts after 30 days. As expected, we detected activity from the attacker on June 14th, 30 days after the initial staking. In this transaction [8], the attacker claimed the mining rewards for each helper contract. Autochain protocol legitimately offers the reward. The profit made by the attacker primarily came from the referral reward obtained in the previous step.

Predicting Sybil Attacks with CUBE3.AI

CUBE3.AI’s model successfully predicted two blockchain Sybil attacks before they occurred, demonstrating its importance in maintaining trust and decentralisation in blockchain networks. The attacks involved the deployment of malicious contracts and fraudulent activities, leading to significant spikes in suspicious activities. 

The first attack involved a single hack with over 1,200 helper contracts, while the second targeted the AutochainMining contract with 1,000 helper contracts. The attacks highlight the vulnerability of blockchain networks to Sybil attacks, which can lead to network disruption, security breaches, and loss of trust.

  • by Tamás Kelemen, CUBE3.AI Security Researcher

Appendix #1 — May 15

1. “Victim” token rug pull transaction


1.1 May 9th Attacker EOA: 0x65bba34c11add305cb2a1f8a68cecbd6e75089cd

1.2 May 9 Exploit contract Address: 0xfd6ff006a303e6092220c33c56135a27bba31379
Deployed at: May 9, 2024 03:16:57 AM UTC
Detected at: May 9, 2024 03:17:01 AM UTC

1.3 May 9, Helper exploit contract example address: 0x0603399ee150c01094ea43ae20d584cc25e518a6
Deployed at: May 9, 2024 05:40:50 AM UTC
Detected at: May 9, 2024 05:41:02 AM UTC

2. Funding transactions

2.1 Direct withdraws


2.2 Indirect withdraws



2.3 Forwarding funds to attacker address


3. Preparation

3.1 Token distribution transactions


3.2 Deployment of helper contracts:

Each transaction deployed 200 contracts, except the last one only 20, total of 1220 contracts.

3.3 Helper contract addresses — sample


3.4 UBC dust transfers


3.5 Execution transaction


3.3 Execution transaction

4. Deposits to Tornado Cash


[3.6] LP token Balance

The token balances in the UBC — BSC-USD liquidity pool were as follows:

Before execution:

  • UBC: 207878118635741489414440791
  • BSC-USD: 56573341884383355633549

After execution:

  • UBC: 3356846383227998073968518173
  • BSC-USD: 4814364670404359036672

Appendix #2 — May 15

5. Victim contract:0xf904665324542eeb3323334fdaa8fa526106af36Deployed by: 0x43f375ccdcfabd225d9680d0d2711999af1e84b3 (Autochain: Deployer) Deployed at: Apr 8, 2024 07:48:33 AM UTC

5.1 — Attacker: 0x762fac581205423f5029f01f699b78582485d054 — Funded from Tornado Cash 

5.2 — Exploit contract Address: 0x5beda519135e4167d852f8dbb313776ccdf32a94
Deployed by: 0x762fac581205423f5029f01f699b78582485d054 (attacker address)
Deployed at May 15, 2024 12:23:57 PM UTC
Detected at: May 15, 2024 12:24:08 PM UTC

5.3 -Example helper contract address: 0x00157fc53535b1b50f0aa88fad5b1598d71286d4
Deployed by: 0x762fac581205423f5029f01f699b78582485d054 (attacker address) Created by: 0x5beda519135e4167d852f8dbb313776ccdf32a94 (exploit contract) 

Deployed at: May 15, 2024 12:52:12 PM UTC 

Detected at: May 15, 2024 12:52:35 PM UTC

6. Preparation

6.1 Helper contract preparation transactions


Each deployed 100, a total of 1000 contracts. After deployment, 50 TKN token was transferred to each helper contract.

6.2 TFK token address


7. Staking transaction


8. Claim transaction


Tamás Kelemen

Tamás Kelemen

CUBE3.AI Security Researcher

Stay informed, stay protected.
Get the latest web3 security news first