Venus Protocol's 12-Hour Gambit to Reverse a $13M Delegate-Approval Exploit

A single compromised video-conferencing client set off a chain of events that cost a Venus Protocol user roughly $13 million — and pushed the lending platform into an emergency governance process that paused the entire protocol to claw the funds back.

How the access was obtained

At 9:05 AM UTC on September 2nd, the victim opened a Zoom client that had been secretly backdoored, giving the attacker remote access to the machine. Rather than attacking Venus's smart contracts directly, the intruder waited for the victim to sign a delegate approval transaction — a routine permission widely used across DeFi to let a protocol manage positions without exposing private keys. That signature effectively handed administrative control of the $13 million wallet to the attacker. Only six seconds elapsed between the signature and the start of the exploit.

The exploit

At 09:05:36 UTC, the attacker executed the drain in a single transaction (0x4216f924ceec9f45ff7ffdfdad0cea71239603ce3c22056a9f09054581836286 on BNB Chain), a sequence later detailed in Venus Protocol's post-incident write-up:

1. Flash-borrow 285.72 BTCB.
2. Use the borrowed BTCB, plus an additional 21 BTCB supplied by the attacker, to clear the victim's outstanding debt.
3. With the delegate permission now active, transfer the victim's holdings — including $19.8 million in vUSDT, $7.15 million in vUSDC, 285 BTCB, and several other tokens.
4. Pledge the newly stolen assets as collateral to borrow $7.14 million in USDC against the victim's remaining BNB.
5. Borrow additional BTCB to repay the original flash loan, closing the transaction.

The entire sequence completed atomically, leaving the wallet empty and the attacker holding a large stolen position collateralized largely by the victim's own former assets.

Venus's response

Monitoring tools from Hexagate and Hypernative flagged the activity just four minutes later, at 09:09 UTC, given the scale of the loss involved. Within twenty minutes of the exploit, Venus paused core protocol functions platform-wide — halting borrowing, withdrawals, and liquidations — in an effort to keep the attacker's stolen collateral trapped within the system rather than converted or withdrawn.

That decision required more than an engineering call, since it meant freezing the platform for every user, not just the compromised account. Venus put the matter to an emergency snapshot vote, branded internally as a "Lightning Vote". The proposal laid out a four-phase plan: first, a partial restoration allowing users to protect themselves from liquidation; second, a forced liquidation of the attacker's position; third, a full security review; and fourth, a full resumption of normal protocol operations. The vote passed with 100% approval.

Execution of the counter-liquidation

At 21:36 UTC — roughly twelve hours after the initial exploit — Venus carried out the plan, briefly re-enabling liquidations, seizing the attacker's collateral (which consisted largely of the stolen assets), and then disabling liquidations again once the seizure was complete. By 21:58 UTC, normal protocol functions were restored and the funds had been recovered.

The victim and the social-engineering campaign

The account holder was identified as Kuan Sun, founder of Eureka Crypto, a fact Venus Protocol later confirmed. Sun published his own account of how the attack unfolded, describing a campaign that, in his telling, had been in motion since April, beginning with the compromise of a contact identifying themselves as being from "Stack Asia BD" whom he had met at a conference in Hong Kong.

According to his recollection, the malicious Zoom client had already granted the attacker access to his machine during what he believed was a legitimate call, during which he was told his microphone wasn't working and prompted to "upgrade." Later, his Chrome browser crashed and prompted him to restore his tabs; after clicking to do so, his Rabby wallet browser extension had reportedly been silently replaced with a fraudulent version that suppressed the wallet's normal security warnings. He proceeded with what he believed was a routine Venus withdrawal — something he says he had done thousands of times before — but this time without the usual risk warnings, transaction simulation, or safety checks, since the compromised interface presented the delegate approval as an ordinary transaction. Neither his hardware wallet nor Rabby's built-in protections were able to help once the front end itself had been compromised.

Per the victim's account, the operation was reportedly attributed to North Korea's Lazarus Group. Sun subsequently expressed gratitude toward Venus Protocol, PeckShield, SlowMist, Chaos Labs, Hexagate, Hypernative Labs, and Binance for assisting in the fund recovery.

The governance question

The episode ended with the victim's funds restored and the attacker left without profit, but it also demonstrated that a protocol marketed as decentralized retained — and was willing to exercise — the ability to pause itself and override its own liquidation logic in response to a single user's loss. The unanimous outcome of the emergency vote raises the question of how much of that consensus reflected genuine agreement versus the pressure of an unfolding crisis. Whatever the answer, the incident underscored that emergency administrative powers, not purely immutable code, ultimately determined the outcome.