$48M Hedgey Finance Hack Detected by CUBE3.AI Minutes Before Exploit
- Analysis by Tamas Kelemen, Security Researcher at CUBE3.AI
- Contributions from Attila Marosi-Bauer and the CUBE3 Research Team
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.
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. The attack was funded from ChangeNOW. Notably, the vulnerable source code was audited by Consensys in June 2023 (audit report).
Later the same attack was performed on the same contract on multiple chains [Appendix 1], currently resulting in at least $48M in total loss. 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
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:
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. This is possible because 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