SlowMist: Analysis of the Furucombo Hack

The well-known DeFi project Furucombo was hacked and lost more than 15 million U.S. dollars. The SlowMist security team immediately intervened in the analysis and shared the details of the attack with everyone.

Attack details analysis

The contract in question this time is in Furucombo’s own agency contract. The entire attack process is very simple. By setting the logical address of Furucombo’s AaveV2 Proxy, the attacker caused all subsequent logic called through the Furucombo proxy contract to be forwarded to the attacker’s own malicious contract, resulting in the theft of any funds.

As shown in the figure above, the entrance of the attacker is in Furucombo’s batchExec function. Let’s analyze the batchExec function first:

The above is the specific implementation of the batchExec function of the Furucombo Proxy contract. The _preProcess and _postProcess contracts respectively do some data processing before and after the call. There is no specific call logic involved, so you can ignore it here. We mainly observe the core _execs function:

Through the analysis of the execs code, it is not difficult to find that the main logic of the function is to check the data in the configs array and perform some processing on the data according to the data in the configs array. But reviewing the above call data of the attacker, it is not difficult to find that in the call data of the attacker, the data of configs is a 0 address:

There is a trick here. Since address 0 is an EOA address, all function calls to the EOA address will succeed, but will not return any results. Combined with this trick, the part of the configs data in the execs function can be temporarily ignored. Directly see the final core _exec function:

The logic of the _exec function is also very simple. After verifying the _to address, it directly forwards the data to the specified _to address. And through the analysis of the attack transaction, we can find that this _to address is indeed an officially designated legal address.

The last step is to call the _to address, which is the initialize function of the officially designated AaveV2 Proxy contract, and set the attacker’s own malicious address to the logical address of the AaveV2 Proxy contract. Through the analysis of the Furucombo contract, it can be found that there are no serious security points in the entire calling process, and the whitelist of the calling address is also checked. Then the problem can only lie in the corresponding proxy logic to be called, that is, the AaveV2 Proxy contract.

We directly analyze the logic of the initialize function of the AaveV2 Proxy contract:

You can see that the initialize function is a public function, and at the beginning it checks whether _implementation is 0 address, if it is 0 address, an error is thrown. The purpose of this check is actually to check whether _implementation is set. If it is set, it cannot be set again. Based on this setting, it is not difficult to figure out that the initialize function can only be called once. Unless AaveV2 Proxy has never set _implementation, this call will not succeed. Isn’t Furucombo really set the corresponding _implementation? With this question, we checked the status change within the transaction. as follows:

It can be seen that the storage location is changed to 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc in the transaction, and the content written is the attacker’s own malicious contract address 0x86765dde9304bea32f65330d266155c4fa0c4f04.

The location 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc is the storage address of the _implementation data.

In other words, the official has never set the _implementation address of the AaveV2 Proxy contract, which caused the attacker to take advantage of this loophole and cause the loss of Furucombo’s assets.


Through the analysis of the entire incident, Furucombo’s accident was not within the scope of the security vulnerability. The main reason was that the official added the inactive AaveV2 Proxy contract to its whitelist and did not initialize the AaveV2 Proxy contract. , Causing the attacker to take advantage of it.


At present, due to the attack on Furucombo, any user who has authorized tokens to the Furucombo contract (0x17e8ca1b4798b97602895f63206afcd1fc90ca5f) will face the risk of capital loss.

The SlowMist security team recommends that users who have interacted with Furucombo check whether they have authorized relevant tokens to the Furucombo contract. If authorized, the relevant authorization shall be revoked in time to avoid further losses.

Reference link:

Token authorization check address:

Attack transaction:

About us

SlowMist Technology is a company focused on blockchain ecosystem security. It has served many top or well-known projects around the world through “the security solution that integrated the threat discovery and threat defense while tailored to local conditions” and has nearly a thousand commercial customers. SlowMist’s security solutions include security audit, threat intelligence (BTI), bug bounty, defense deployment, security consultant, and other services. SlowMist is equipped with cryptocurrency anti-money laundering (AML), false top-up scanner, vulnerability scanner, and vulnerability monitoring (Vulpush), hacked project archives (SlowMist Hacked), smart contract firewall (FireWall.X), Safe Staking and other SAAS security products. It has been widely concerned and recognized by the industry.

Focuses on Blockchain Ecosystem Security, have served over 1k+ customers.