$48M Hedgey Finance Hack Detected by CUBE3.AI Minutes Before Exploit

Today, CUBE3.AI’s ML model detected an (ongoing) $48M attack against Hedgey Finance, seconds after it was deployed, and 5 minutes before the first $1.3M transaction exploit. The Hedgey Finance hack is one of many recent postmortems and analysis we have detected recently in categories ranging from rug pulls and several flash loan attacks.

See this post and docs to learn more on CUBE3.AI’s Runtime Application Self-Protection (RASP) product that blocks these types of threats before they can do damage.

CUBE3.AI detected a malicious transaction at 07:07:03 (UTC) targeting a Hedgey Finance smart contract, ClaimCampaigns. The attacker exploited a business logic flaw in the victim contract allowing them to drain an initial $1.3M USDC with a help of a flash loan from Balancer. ChangeNOW funded the attack. Notably, Consensys audited the vulnerable source code in June 2023 (audit report).

Later, attackers actively performed the same attack on the same contract across multiple chains [Appendix 1], which has currently resulted in a total loss of at least $48 million. Our analysis revealed multiple attacker addresses and exploit contracts [Appendix 2]. It is unknown at the moment whether these attacks are all executed by the same malicious actor or others started to copy the initial attack.

Hours after the attack, the Hedgey Finance team alerted its users in an X post about the hack and advised to cancel active claims via their official website.

IMPORTANT: Please be aware of the scam links being spammed under the official statement, coming from a nearly identical Twitter handle; notice the extra L (”l”) in “hedgeylfinance”. This is a scam link routing to a malicious site, do not click on it.

In the rest of this post we will be focusing on the first exploit transaction. Our aim is to provide technical insights about the vulnerability which made the hack possible and the steps the attacker performed during execution. We will start by outlining the involved addresses and transactions, then examine the vulnerable contract code. Finally, we explore the execution flow of the hack.

Addresses Involved in Hedgey Finance Hack

Victim

Hedgey Finance — ClaimCampaigns contract.

Ethereum: 0xbc452fdc8f851d7c5b72e1fe74dfb63bb793d511

First, the same vulnerable smart contract is deployed to at least 5 chains on the same address. (Ethereum, Binance, Polygon, Arbitrum, Avalanche)

Attacker (EOA)

0xded2b1a426e1b7d415a40bcad44e98f47181dda2

Funded from ChangeNOW at 2024–04–19 06:46:23 (UTC).

Exploit contract (SC)

0xc793113f1548b97e37c409f39244ee44241bf2b3

Deployed at: 2024–04–19 07:00:11 (UTC)

Detected by CUBE3.AI ML at: 2024–04–19 07:00:31 (UTC)

Transactions

1. Hedgey Finance Hacker Preparation

Not malicious by itself, just preparing the attack…

transaction hash: 0xa17fdb804728f226fcd10e78eae5247abd984e0f03301312315b89cae25aa517 blockchain: ethereum block: 19687887 onchain timestamp: 2024–04–19 07:05:59 (UTC)

2. Hedgey Finance Hacker Funds Drain

transaction hash: 0x2606d459a50ca4920722a111745c2eeced1d8a01ff25ee762e22d5d4b1595739 blockchain: ethereum block: 19687890 onchain timestamp: 2024–04–19 07:06:47 (UTC) detected by Cube3: 2024–04–19 07:07:03 (UTC)

Hedgey Finance Hack Root Cause Analysis

Vulnerability

During campaign creation the user transfers the locked tokens to the ClaimCampaigns contract (line 187), then the contract gives allowance on these tokens to the user:

Moreover, after the user cancels the campaign, the contract withdraws all the locked tokens to the campaign manager. The vulnerability lies in the failure to revoke the allowance for the campaign manager. Although the comment for the function claims to “prevent anyone from claiming additional tokens”, this is only handled in the contract’s claim logic, not in the token’s allowance logic. As a result the allowance still exists in the token contract’s perspective.

Attack Flow Summary

Transaction 1: Preparation

Attacker receives $1.3M USDC in flash loan from Balancer to the exploit contract
Attacker creates campaign with locking $1.3M USDC via the createLockedCampaign function
Attacker cancels campaign via the cancelCampaign function, exploit contract receives the locked $1.3M USDC from ClaimCampaigns contract

Transaction 2: Draining funds

Attacker transfers $1.3M USDC from ClaimCampaigns contract using transferFrom on USDC token contract. Therefore, the allowance from ClaimCampaigns contract to the exploit contract was never revoked.

Takeaway

This incident highlights the limitations of relying solely on code audits for comprehensive protection against potential attack vectors. It emphasises the importance of active, real-time transaction security measures in effectively countering cyber and fraud threats.

Appendix

1. List of Attack Transactions

[transaction hash — chain id] 0x2606d459a50ca4920722a111745c2eeced1d8a01ff25ee762e22d5d4b1595739–1 0x47da1ac72d488f746865891c9196c1632ae04f018b285b762b2b564ad1d3a9e5–1 0xe4dbeba25b0c0d67f8ecaff5ec7c0a9569ddc10c817ab6815d5bc3dfb22e9ec0–1 0xd0c23f115c66a060ffab78c91c6f9085db5af6257a72858b7fd4def6b7735617–1 0x4eb093c25d111efa1e8b7f6dc32cc47573c4651b6ea2e30d74bf2449c796692f — 1 0x51988f56315afb8417c48948092fb6c6b1007b52aac98e71b21010ddeafea95c — 1 0x108a52c403fe206bafb34ce1880138f22591f82b0f45c6c77de7c8787dc6a834–1 0xf336ff5c7465893a87c79ac514abe2e3fac1b3e06cbe185c00ea6af18d4e7a84–1 0x9edb3c12cd3d3352ec56c8222aaa51bbec3e47b693deb9ffa3bcd0a0060a420c — 1 0x21d51b17b6834f9837472c37e7271c75a55bf449d773f4e00c9aa316af7f5a5c — 1 0x5ddd5192f012f79d6a5fbb97abe2f61705838f6a7c9c223ddcd7f37fd930707d — 1 0x456d96e3040d5da6dfaa7f1c26523a3fc6adc8bfe84bc97bd736513f689cf15a — 1 0x91ef02e6a99bf97cf5ff54d7084736f826fb280b1af14819c4d86a63c4145099–1 0x13de542bb28df2f1b07ea4a07c7073cb7efa38057e708e65851f8b00176eed79–1 0xc9e3f0329fe027782760f95477838d0a6c9203ef6f61cfb4a27b60f26b265afd — 1 0xc52cc6980f0700d8d90fbebe32a5bee07f5ae4d62996bc425db4b76da687e3ec — 1 0x6a9251b084ff7a5dd74281d8972a762461f4336c615776d34d5c0ec738b592f6–1 0x302d20eae77336a913be1d8673b09456022c5fc110a114c0d79fb653015fe367–1 0x570147d83ca9c4377f53f1d8e9e18649bbe69431cc81b3fb3689cc3931b2b9ce — 1 0x3211c2a21e069e6ccd8159216e0ac185f0a9ae08d36e08388307ace3f8c3c7df — 1 0x9bd9a440aa0cc8487d9de5aafeb13e339d8d80c9d6497a27c9def7d582f52592–1 0xd89ed3da025e7875a8581d52beffba43340a18771fc2f71d939f91a31e39f535–1 0x79fad458486924cddd10d4316e4a8ebc2b387a9fccebc4fda79c659c8f0f3da0–1 0xf1b248b7f217b46a2f52bad1fb8fea294eea57ce0af85d63a14f52479e250220–1 0x45b2cf13abfa85be7fd277b357da4bc836dee221a7be55cc20b862c6121eb213–1 0x353a710d9a52a919a5d7220211f11e7851cf99f1243373376c8eb2e48a94b396–1 0x0929eccb3aca9dfb87a9998ffb821ca3f685e881255e8d96535f407c10253217–1 0x8b5ca7dabee5cdc74240d83f80a46fe79a86aa277002c354e83c639666732efc — 1 0xd2ed6cbf430f38571146e701e435a060afb40d55151c2d388fcdd6d726671d3f — 1 0x286b3e337b1e97d801350095a546339b450f1f753f25f3ca4b50d16f0081b1f0–1 0x97b4bcb4de1ace0c030ef83e8c0eaeb0f56a1bcd2fae2c4ac0216168c6d4b311–1 0x64c4cda28c5f14c761fb34c86adbf07436c1deb179479525cb06ae4718b34509–1 0xe4c01e5e08bb60d443892a3776a5b93669d9b977fbd246cf01e9d31087544c7b — 1 0x13ea56ad02087e331a49ae78d6fa93e6356d9df5fe48f236dbfe65b404b9dea4–1 0xf85369f91698a78eb4f42c533bec540c54f3752e7cb321eadd6eb6f7c1c1c305–1 0x43dcba00e16c051d3f638a8911d5165e753eba4d84c9cea826603321f2b20d47–1 0x1348fe639d2d7507ce2f2260a703e0b50b0bf4b6daddf85e826e27a220d84ddd — 1 0xa9f83fb438b6dc741b392042fd76969e9e2ff53f141ecc6fd1e6f85b5b0d4290–42161 0x001ef761e63168bb5e0d05d6d258b8a46e6021fb15658208bee24cc391c7623f — 42161 0x57379df7a69ebc470ec6bd6dbefa56de1e30f1adc5623e905f0d65d3eaa858a2–42161 0x76d9ad0d813420e860294e3810d86ee5cb05cdde4a20763bc4a3f67208e53214–42161 0x0965c1625ec0a0293b3010783a0e118c7e12937e54ca9e7eadce6840155130a6–42161 0x59ad100bcc25494902495dfb03920c4d2223796b92cda21cfcbae1c06c8a333b — 42161 0x04732ec18e161308426a6b553166181237766bcd5c585704b39d87999a7464d0–42161 0xcebf40002e3eef38fae2928e3552899c76a737b19a2015d4f8d3ddb23a5c9c0e — 42161 0x9dea875ccff2183e796596decd211e66bc0e6a02027fc39b4028f51320fa6b55–42161

2. List of attacker and exploit addresses

[attacker address — exploit address — chain id] 0xded2b1a426e1b7d415a40bcad44e98f47181dda2–0xc793113f1548b97e37c409f39244ee44241bf2b3–1 0xded2b1a426e1b7d415a40bcad44e98f47181dda2–0xd818ff3d5cfc938014b270d0c8029ba04629b549–1 0xf0cad3c3ba1db3e47fc830c490b3db40af8d010f — 0xb0aeb4871de758dc704471165a9b0c386c6074c2–1 0xbb58c156dcbfc3b3d8c6560ea9741ee16bd467fa — 0x887427516d9bde790d094830832b46de33f5ebcb — 1 0xc7241e27ee4b8d32b59a10e848b48530047a8c5b — 0xbb52f1723ddf2c84ba2668f4e04712f572cbf780–42161