Rogue Developer steals $785,000 with Roar Staking Contract exploit

Addressing a staking contract related to RoAR, hackers drained more than 785,000 from the staking pool when the staking pool was launched. The attacker used a flaw in emergency WithDraw() to pull out a $100 million token shortly after staking the reward. Hacken, a well-known Web3 security auditor, was the first auditor to detect and report details through the official social media platform X account.

Early observations were made that rewards were problematic with regard to calculation or miscalculation of the withdrawal process. However, after some research, it turns out that the fundamental cause is injecting harmful code into the contract constructor. This constructor presets the bet on the attacker’s wallet address during deployment. This preloaded value allowed the wallet to withdraw tokens without staking them on multiple occasions in the first place.

The fraudulent developer behind the incident

Yehor Rudytsia, a security researcher on the chain, analyzed the entire incident and shared his comments with the Crypto community. Exploits were launched after Roar was stolen from his reward, and then assets were offered on decentralized exchanges. The extracted tokens were then exchanged for ETH, and the funds were split into several wallet addresses simultaneously. The transaction passed through tornado cash and confirmed that the laundry was barely visible.

Roar said the attack was not carried out by outsiders, but by internal developers who used a process aimed at early bug testing. The attacker remained dormant for 17 days after signs of attack were revealed. This was the exception of one attack that investigators witnessed. This timing helped hackers get enough market depth to bring stolen tokens back to ETH without significantly affecting the price.

Investigators revealed that the developer pre-set the balance when they created the contract. As a result, the attacker was able to control the withdrawal function from the start of the process. It’s not that the error was missed when coding the second version of the app, it’s an intentional action by the person who visited it.

Attackers used Tornado Cash to obscure the trajectory of their initial funding

The wallet raised early capital through tornado cash. Once the staking contract was empty, the attacker split up and attempted to forward the discharged tokens to various chains and wallet addresses.

Security experts also pointed out that it is operationally exploitable, not a technical vulnerability of the platform. Hacken security researcher Yehor Rudytsia said excessive trust in individual developers should be kept to a minimum in relation to internal controls and clear deployment specifications. He also

“Projects need to implement reproducible builds, implement separation between developers and deployers, and verify that the deployed bytecode matches the audited source. But beyond that, organizations need to treat Dev Access like live attack surfaces.