Photograph from NASA’s Expedition 49.

A protocol can change who controls its funds without changing a line of code. An engineer gains a deployment role. A new signer joins a multisig. A bridge changes which verifier it trusts. Each decision changes what a compromised device or account can reach.

Operational security, or OpSec, covers how a team grants access, verifies sensitive actions and recovers control. An OpSec review should answer a concrete question: what could a compromised person, device or service authorize, and which independent control would stop it? Binance’s October 2026 breach shows how far those permissions can reach.

Deployment access put Binance’s wallet signer within reach

The attacker entered through a fake coding assignment

In Binance’s preliminary account, a fake recruiter sent an engineer a coding assignment in September. The repository ran malicious code on a work laptop and tampered with a local development tool. The attacker later used an internal AI tool to reach other engineers’ devices. One of those devices held a credential that could deploy containers. With it, the attacker ran a malicious workload and reached the wallet signing service.

Access to that service let the attacker initiate transactions outside the normal withdrawal process. Binance reported roughly $6.34 billion in assets affected, including 233.46 million XRP transferred from five hot wallets in four minutes and 18,270 BTC transferred from a hot wallet. A deployment credential had become a route to the infrastructure that signed withdrawals.

Pausing withdrawals left a permission live onchain

On Ethereum, the attacker obtained an EIP-7702 authorization that delegated a Binance wallet to code under the attacker’s control. The wallet remained delegated after Binance paused withdrawals. Binance had to clear the permission onchain and reported $2.85 billion frozen or intercepted by its November 3 update.

An emergency shutdown is incomplete while malicious authority remains live onchain.

Four more routes from trusted access to stolen funds

Across these five selected incidents, about $8.8 billion was affected at reported gross values. Each shows how an attacker acquired the authority to reach funds.

‍

Bybit · $1.5 billion

Sygnia’s investigation found that a tampered Safe interface made a change to the cold wallet’s implementation look like a routine transfer. Legitimate signers approved it, giving the attacker control of the wallet. The FBI estimated the theft at $1.5 billion. Separate keys still depended on the same interface to explain what was being signed.

Bitget · $388 million

Mandiant traced the breach from third-party security appliances into the production wallet job server. Bitget reported $388 million in unauthorized transfers from hot and warm wallets. Cold wallets were unaffected, giving the incident a clear boundary and showing why it matters which wallets a compromised service can reach.

KelpDAO · $292 million

In LayerZero’s investigation, attackers poisoned internal blockchain data sources and disrupted an external provider. The bridge’s sole configured verifier attested to an event that never occurred, releasing 116,500 rsETH. Aave’s incident report traced about 77% of those tokens into Aave collateral positions. A verifier’s operating risk had become a lending market’s exposure.

Drift · $285 million

Chainalysis’ early account traced the takeover to transactions the attacker had obtained signatures for in advance. Solana’s durable nonces let those transactions execute later. Once the attacker gained administrative control, they enabled bogus collateral and borrowed real assets against it. Drift’s recovery plan called for independent transaction review, dedicated signing devices and timelocks on critical admin actions.

Measure access by the funds it can reach

Hacken’s Q2 2026 analysis found smart contract bugs in 44 of 67 incidents. Compromises involving keys, signers and infrastructure accounted for 88.3% of the $763.9 million stolen, heavily influenced by Drift and KelpDAO. In Hacken’s Q3 report, access control and operational failures accounted for 40% of losses. A few compromised operational roles can dominate the loss total.

A small set of roles can control large balances

Teams need privileged roles to run a live protocol. The exposure depends on what those roles can change.

   
• An upgrade admin can change the code governing funds already deposited in a vault.
   
• A market administrator can change what counts as collateral and how much can be borrowed against it.
   
• A wallet service can sign across several networks, so one compromised request path can reach balances on each.
 

The stakes grow with the value those roles control, even when the approval process stays the same. Put limits where the request is signed or executed, and require separate approval to change those limits. A cap inside a request dashboard covers only the transactions that pass through it.

A custom protocol still runs on familiar infrastructure

A protocol’s code can be unique while its engineers use the same package managers, cloud tools and hiring platforms as everyone else. Google’s threat intelligence team has documented fake interviews that persuade developers to run code from a repository. The important question after that code runs is what credentials and services the device can reach.

The access map changes between audits

A team can offboard a contributor from its identity provider while their hardware wallet address remains a governance signer. A new CI role can reach production without any contract code changing. A verifier can switch to a fallback that shares the same administrator as its primary provider. The operating setup has its own change history. Review permissions when those changes happen and verify the resulting state in each system, including onchain.

Start with the transaction an attacker would want

Pick a real action, such as upgrading a vault, adding collateral or moving treasury funds. Use the actual access policies and transaction records to answer three questions.

   
1. Who can set it in motion? Include people, service accounts and roles that can deploy code or change approval rules.
   
2. What stops it if the proposer is compromised? Have a separate approver verify the payload and work out how much value could move before a limit or delay intervenes.
   
3. Who can take the authority back? Run the drill with your usual signing interface and coordination channel unavailable. Time how long it takes to revoke access and verify the change onchain.
 

Why Sherlock is building an OpSec assessment

Audited contracts still depend on the people and infrastructure authorized to operate them. We’re developing an OpSec assessment with Aurélien Donneger to map those routes to privileged actions, prioritize the paths that put funds at risk and give teams a plan for tightening access, signing and recovery controls. If there’s one workflow your team wants to put through that exercise, bring it to Sherlock.

‍