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

0x5a147c4da09b1b52d985e3605cf782e3218186c4679da7c847006b20e5f40a2a

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

0x5be838af26394a4a50d1051156abddbd743016e1a4a5a29bdb66488e489d3db6
0xe40747ff7136bd58f8ec82e6efd83a0cd72f34941ec23f7c3e2d066ffdd36900
0x4c7fc0cd1e26f58f6291767988cb6359e88910ccd520d154a2431052dc36cdcc
0x5b13788e8901fa3cd27d84351ddbe7fb27738b3092ddae97b9bbba83c31c62f5
0x7b9d6f5ea8d25b9dbd79328cbc6e55a8de4607ff9c51b7a86b58798d2f2cb4ab
0x8e26e5ed562ab9b323a28ac496a15252336fe69e526a99487211d0cd157006aa
0x131d406831816512c65483b8a9cf3198cdf1c84accf1cb1407dc448ef0f76be2

2.2 Indirect withdraws

0x086dbb4580a0c1f7c3bb77616d20673b4433716033b947e764b60c3b0ec33774

0x29c29cc4321dbb9ad57250f7396354508658ec4b7867e535953c35abe3b70f76

2.3 Forwarding funds to attacker address

0x0bc9427f2b475aaf36f3ad62b1f96df96518ccf58945a26f6974bd4110e64551

3. Preparation

3.1 Token distribution transactions

0xec39f131a1687f686a8760bd7fd520e3fef7a42d083ed0ae0fe7f6eb8bc78d1b
0x3b306248ea623ee478389835d749973eeef23bfe55e420a28c6a93f471aee1b5
0x583a7ffa40d3cf2838eaa40d4c1cd126261b8fd6a952f86bff4d968a541945fa
0xe6eebde0edada99f015fde9389c53ab5c8a68c6cbfcd221bbddc54c346ea9fe0
0xc6477092169d3dad177ee039f5d8fd5e0dee64a4a4eb1a10069a4e6e956986a6
0x3918c39287f7004187554e719f287ff3c6b1ba8d10fc4dc8cfb52e1e59ad52d1
0xa7f70ff1aba1f60b8c10794095c730b4ab1b1aad782fcd130c33ea073c53c2f8
0x85cc48c650a92756296bc65cd03339bd65aeed35a3c9730c7c7db710e96efa48
0x0aff46e85630e2462f2fdd4bbcd63600283951512c4478bee1e39dfab7af3547

3.2 Deployment of helper contracts:

0x24a0e8a8c855898f9e9269015e25cf20f44e1d07b413f3a15471f9fc29a82e66
0x7e60af0c102fffd43b9bd72d6cdac0f2b60793b5d4d0275a8de129934891d626
0xbe8248b57802eb4fa2e40d2349851f403dde9e809ef30dfe3aa1fb38a2fcf21f
0x7eb1e493fa9b7189cdf527e8528a8745a49bfe4d46a12dc6c9f955068eaa521b
0x1f7686be582483673f7ceabc2114346449af6ce38615f2e7869cc4356519b16a
0x24f7a508c121ca5dd6e6cba1c66737db0e112db505c550d52fe9b01811d9fc2d
0x50d140a20e275d33644291532ff6e5299155c3fa7418cb685372a828d9d7ed01Each transaction deployed 200 contracts, except the last one only 20, total of 1220 contracts.

3.3 Helper contract addresses — sample

0x0603399ee150c01094ea43ae20d584cc25e518a6
0x11fdb4760329ddc4326cbc6fd8b046b6967b821f
0xcdc75e566075158b037942d8778544b5847ff320
0x9f4a5e7ec194df99370e700b05707f0503b4c8cf
0xdca22227c6856f92e9d5a1a4e5c396e3fafef344
0xaae1ba7f1455c91e9de7f1872e2193de4e448fce
0x1e17d76d74637587e53dfdb86fa2bd0286c6d56f

3.4 UBC dust transfers

0x1e4e83fe66d4de03872237450999e49c144313e32ec1566def785d89171b8c69
0xa299df9b9bef7cab9bf87802394230182bd95efad36979a2f4b0f514be9b9fce
0x28900f3bb2d9f31a8e0890c5a45d4c47708bd0635ab3ee271a46f4311e37673c
0x3b543807aab6618c35feee58ca39114cbd404ebb2ccd643b5acd36af341c18a7
0x32567a3a148ebf78c3ca24dcca5aeeb0a3e59d5370c4e81a65c28420679b7816

3.5 Execution transaction

0xf3112bd90756262df0418ba7e5b25c8b4b15455dc238c4104c3ded77ba7dc8e4

3.3 Execution transaction

4. Deposits to Tornado Cash

0xb1bda94668c4fd3509821a6e0b554a3d2fee140de84ba08ef0ea7cda883b3f8b
0xd3353ccb3ade0eee259a4e6ea867b10edf76127d0925ba403ddaeedf3549344e
0x9e3c0acad4acf2b0c2c9f7a2f13416a21dc3058a30754d9925ee51b0a3a18810
0xa345408e21e49bc18bcd99ce4c2e4a2c4f9c193515b1eda4821ef7e9a7e1dc4d
0x336122c5746a3122d1d2ab62217588a17007f771d6e7334ec6fd1ebc652030fe
0x8e60465e9cbca7676effcf02586d1d2da95aa98265f34809cd6e5c09946d12d9
0x848d2780b8ae7d54de6ce2e6444540c9627949610591afd9ee4ddee1cbe3429a

[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

0x704b19def4ed7dd4e26e7c526039868410402b9b7cf279013c36bb88a10af530
0x920d3a48035f6e9ae7ab9913f4ac9638537d15831935a5e8a26fa5656242621f
0x77169ce0e6cbb11cdb29010a0636a4605be9e6998039596e0c624de18a4cb43b
0x3a144d2423823026a2ef61ac4f4e4e0db3c7b21ad91f4a0253b15a1ddd019295
0x51edcaabe3169df138b8e71f55445d5d117de3c586efc182918145101b585b5d
0xdc2ab403507666897a50a86bc5df24e380e4fe900253cfc0fa09e66d3e6abc1b
0x361aec6041f1ba373893e36ee47c9f2fa1f759f4cea2728fbfdf05d2adaec5d0
0x70c2521184492d5db74020f197163b27dd79c60af7ca7e576ccafc985e1a828d
0x7c7a4d3e5526098b5b656de5d4b1d9580704551305606a66fa887160cdd2e4f2
0x09034805582770356f5629ff2a103e4b199723feb8757b56b57504bf6275169c

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

6.2 TFK token address

0x75f35e1ef8ebc5d49479c63a9b109670cb651132

7. Staking transaction

0x8d1127ced9b69c905bf6c03af32a8a5e46e2e595ad486362099ad03f5b05b248

8. Claim transaction

0xe64530857e64e9be1c5ef669ed883770edc6cef005e9464eeb54072ee925ebba