Jump Crypto and Oasis counter-exploit Wormhole hacker for $225m
- A Web3 firm Jump Crypto and a DeFi platform Oasis.app have conducted a counter-exploit on the Wormhole protocol hacker.
- They have successfully recovered $225 million in digital assets and transferred them to a safe wallet.
Jump Crypto, a Web3 infrastructure firm, and Oasis.app, a decentralized finance (DeFi) platform, have conducted a counter-exploit on the Wormhole protocol hacker, recovering $225 million in digital assets and transferring them to a safe wallet.
The Wormhole attack took place in February 2022 and resulted in the theft of approximately $321 million in Wrapped ETH (wETH) due to vulnerability in the protocol’s token bridge.
Since then, the hacker has moved around the stolen funds through various Ethereum-based decentralized applications (dApps), and via Oasis, they recently opened up a Wrapped Staked ETH (wstETH) vault last month, and a Rocket Pool ETH (rETH) vault early this month.
The Oasis.app team confirmed a counter-exploit had occurred in a blog post on 24 February, stating that it had received an order from the High Court of England and Wales to retrieve certain assets related to the address associated with the Wormhole exploit.
The retrieval was started by Oasis Multisig and a court-authorized third party, which was identified as Jump Crypto in a previous report from Blockworks Research.
Funds transferred to safe wallets
The transaction history of both vaults shows that Oasis moved 120,695 wsETH and 3,213 rETH on 21 February and placed them in wallets under Jump Crypto’s control. The hacker also had approximately $78 million in debt in MakerDao’s DAI stablecoin, which was recovered.
According to the blog post, it can also be confirmed that the assets were immediately transferred to a wallet controlled by an authorized third party, as required by the court order. It no longer has any control or access to these assets.
In response to the negative implications of Oasis being able to retrieve crypto assets from its user vaults, the team stressed that this was only possible due to a previously unknown vulnerability in the design of the admin multisig access.