Jump Crypto has seemingly recovered 120.69k wstETH and 3.21k rETH ($225M of assets) from the infamous Wormhole Exploit that occurred one year ago. A recovery group, what appears to be Jump Crypto and Oasis,  “counter exploited” an upgradable proxy contract on the Oasis protocol, securing the stolen funds and transferring them to a fresh wallet.

Jump nor Oasis have publicly confirmed this.

The Wormhole Exploiter (the Exploiter) has continuously shuffled the stolen funds through various dapps on Ethereum. Most recently, they held two Oasis vaults: a wstETH vault opened on January 23, and a rETH vault opened on February 11. Between January 23 and February 16, the Exploiter used these vaults to borrow DAI and lever long ETH staking derivatives. By February 16, the two vaults drew a total of $78M of DAI debt against $220M of collateral. Importantly, both vaults used the automation services offered by Oasis.

For simplicity, only the recovery of the wstETH vault (vault ID 30100) is analyzed because it held $219M wstETH compared to the $6M rETH in the rETH vault (vault ID 30179). Note that the counter exploit simultaneously recovered the funds in both vaults.

Several wallets are involved in the counter exploit. Each address is defined and given an alias that is used throughout this report.

• Oasis Multisig (0x85): A 4 of 12 multisig that owns the Oasis proxy contracts.
• Holder (0x5f): Currently holds the recovered funds and appears to be owned by Jump.
• Sender (0x04): Responsible for executing the counter exploit and appears to be owned by Jump.
• Jump1 (0xf8): Funded the Sender with DAI to repay the debt and recover the collateral. Commonly labeled “Wormhole Deployer 1,” this wallet is tagged to Jump by Etherscan, Nansen, and Arkham.
• Jump2 (0xf5): Received leftover DAI from the Sender. Commonly labeled “Jump Trading,” this wallet is tagged to Jump by Etherscan, Nansen, and Arkham.

Vault 30100

The Exploiter added a stop-loss trigger to vault 30100 just 9 minutes after opening the vault, instantly opening the backdoor for the counter exploit. The AutomationBot contract is given access to the vault when a user adds an automation trigger to an Oasis vault, enabling it to purchase collateral or take on debt if and when the trigger is hit. This change in control can be clearly seen by analyzing the execution trace for this transaction.

The first automated transaction was triggered on February 13. The vault owner took no additional action, while 14.41M DAI debt and 7,547 wstETH collateral was automatically added to the vault.

In isolation, granting control to an external contract is not suspicious. Automated vaults need the ability to act on behalf of the user. However, the Oasis automation contracts use an upgradable proxy pattern, meaning the contract logic can be changed by the contract owner at any time. The owner of the Oasis automation contracts is a 4 of 12 Gnosis Safe we will refer to as the Oasis Multisig.

The Counter Exploit Mechanics

The $227M counter exploit took place on February 21. After a series of transactions across multiple wallets, the final executions delivered 120.7k wstETH and 3.2k rETH to the **Holder** where they currently reside. The **Holder** has a limited transaction history and made its first transaction on February 20, one day before the counter exploit. The recovered assets were sent to the **Holder**by the **Sender**who is responsible for executing a majority of the counter exploit. The **Sender** has no prior transaction history and was funded from KuCoin on February 20.

The process began on February 21 when the **Sender**was added as a signer to the Oasis Multisig. The **Sender**executed five transactions to facilitate the counter exploit and was subsequently removed as a signer from the Oasis Multisig. The Sender was an eligible signer for just 1 hour and 53 minutes.

Each of the five transactions played a key role, but the bulk of the recovery process was executed during the Sender’s third transaction to the Oasis Multisig. To quickly summarize this transaction, the **Sender** upgraded the automation contract to a new proxy that allowed the **Sender** to move the collateral and debt from vault 30100 out of the Exploiter’s control. The image below walks through the execution trace of this transaction and annotates key events in purple. Let’s step through this line by line.

First, the **Sender**initialized a few parameters to enable the counter exploit.

1. Using its privileges on the Oasis Multisig, the **Sender**first updated the change delay to 0 with the ServiceRegistry, allowing it to instantly update proxy contract addresses.
2. The **Sender**deployed two new contracts, we refer to them as Authorizer and Executor. These contracts hoodwink the protocol into acting as the **Sender**commands.
3. With its ability to bypass time delays, the **Sender** updated the Oasis ServiceRegistry to call Authorizer and Executor in place of two key Oasis contracts.
4. The AutomationExecutor proxy address was updated to the Oasis Multisig, giving the **Sender** complete control of vault 30100.

Next, the counter exploit process. The **Sender** must close vault 30100 and migrate its positions to a new vault that is controlled by the multisig.

1. The Oasis Multisig is called in place of the AutomationExecutor, granting full control of vault 30100.
2. The Authorizer is called instead of McdView, which tricks the protocol into thinking that vault 30100 can legally be closed by the Sender. The Authorizer successfully got the **Sender**past the verification steps.
3. The Executor is called to create a new vault 30231, migrate the collateral and debt from 30100 to 30231, and transfer the ownership of 30231 to the Oasis Multisig.
4. The result moved 120,695.43 of wstETH collateral and 76.39M of borrowed DAI from vault 30100 to vault 30231.
5. The Authorizer called again to verify vault 30100 is closed and the job is done.
6. Lastly, the **Sender**restores the proxy contracts back to their original addresses.

The Exploiter’s critical mistake was to give access of vault 30100 to an upgradable proxy contract controlled by a multisig. The Authorizer and Executor played critical roles in the process, but the counter exploit would not have been possible without the full control provided by upgrading the AutomationExecutor proxy.

Once the **Sender** completed the counter exploit, it was removed as a signer from the Oasis Multisig. Just 30 minutes later, the **Sender** began receiving DAI from Jump1. A total of 80M DAI was sent by **Jump1. **The **Sender**used 78.3M DAI to close out the loans in the newly created vaults, and the remainder was sent to Jump2.

Once the DAI debt was cleared, the collateral was withdrawn from the wstETH and rETH vaults and sent to the Holder. The assets have not moved since arriving at the **Holder** 3 days and 2 hours ago at the time of writing.

Notably, it appears Oasis played a critical role in the process by adding the **Sender** as a signer of the Oasis Multisig. Only the current signers have the ability to add new signers, and the addresses 0x93, 0xBc, 0x81, and 0x45 signed the transaction to add the **Sender** to the multisig. If the **Sender** is confirmed to be controlled by Jump, Oasis added an external entity to its multisig, which upgraded its contracts to move funds out of an Oasis user’s vault.