Operational Security: The Audit Blind Spot

Dmytro Matviiv

CEO HackenProof

4 Minutes Read

Published: 4 Sep 2026

A clean security audit—a smart contract audit, a code review, a penetration test—tells you one thing: what you built does what it's supposed to do, and doesn't do what it isn't. It says nothing about who can move your funds, from which machine, or after which phone call.

That gap is called operational security—and in crypto specifically, 2025 is the year it became impossible to ignore. In practice, that means private key compromise and key leakage—not code bugs—decide whether a project survives its first year.

The Uncomfortable Math

According to Hacken's 2025 Yearly Security Report, Web3 lost $4.0 billion in 2025—up 40% from 2024. Access control exploits—compromised keys, signers, and infrastructure—accounted for $2.12 billion of that, 53% of the year's total, which the report itself calls "the weakest spot" in the industry. Add phishing and social engineering ($952 million, 23.8%) and operational failures are behind 76.8% of everything stolen in 2025. Smart contract vulnerabilities—the thing an audit actually checks—came in at $512 million: 12.8%.

Hacken's own researchers put it bluntly: "Most of the 'access control' exploits you see in news come from North Korea. They don't hack smart contracts, they hack operational processes and weak endpoint security." North Korea-linked actors are tied to $2.03 billion of 2025's losses—just over half—and by Hacken's tracking, virtually all of it came through social engineering and phishing, not code exploits.

An audit report is scoped to code. It was never going to catch any of this.

Anatomy of Key Leakage: Five Ways It Actually Happens

1. A compromised developer machine

Radiant Capital lost $50 million in October 2024 after an attacker posing as a trusted contractor sent a developer a "smart contract audit report" over Telegram. The file was malware (INLETDRIFT) disguised as a PDF. It backdoored the developer's Mac, then spread when he shared the file with teammates. The attackers didn't need the multisig's private keys—they needed a foothold on the machines that displayed transactions before signing.

This is what made the Radiant compromise fatal despite Gnosis Safe and hardware wallets being in place. Once the malware controlled the signers' devices, it intercepted the transaction data shown on-screen and swapped it for a malicious transferOwnership() call before it ever reached the Ledger for signing. Because hardware wallets can't parse Safe transaction payloads, the signers approved something they never saw. Three minutes, $50 million gone.

3. A supply-chain compromise upstream of your infrastructure

Bybit's $1.5 billion loss in February 2025—the single largest crypto theft in history—didn't start at Bybit. Lazarus Group compromised a developer machine at Safe{Wallet}, the multisig provider Bybit relied on, gaining access to AWS credentials. They injected malicious JavaScript into app.safe.global itself, coded to activate only for specific high-value targets. When Bybit's signers approved a routine cold-wallet transfer, the tampered interface masked what they were actually signing. Two minutes after the theft, the malicious code was quietly removed from the S3 bucket. Bybit had done nothing wrong technically—their vendor's operational security was the failure.

North Korean group BlueNoroff has been running a documented playbook: reach out on Telegram, schedule a video call, join with deepfaked executives, then complain of audio issues and ask the target to "install a Zoom extension" to fix it. The file is an AppleScript that quietly installs a backdoor, a keylogger, and a crypto-focused infostealer—while a legitimate-looking Zoom page stays open as cover. No exploit, no phishing link clicked in isolation—just a plausible person, on a real-feeling call, asking for one install.

5. The interface lied, and the signers had no way to know

WazirX lost $235 million in July 2024 when an attacker who had deployed a malicious contract eight days earlier swapped it in as the multisig wallet itself. The Liminal custody interface displayed the transaction as routine. Four separate signers approved it—because what they saw on screen and what they were actually authorizing were two different things. Multisig only protects you if every signer can trust their display.

A sixth pattern worth naming: North Korean operatives have also gotten hired as legitimate contributors—Munchables lost (and eventually recovered) $62.5 million after a developer who'd been on the team for months turned out to be a DPRK-linked operative. Vetting who gets commit access and signing rights is operational security too.

Why The Audit Doesn't—And Can't—Cover This

A smart contract audit answers: is this logic correct, and is it exploitable on-chain? It does not answer: is the machine that deploys this contract clean, is the person on this call who they say they are, can a signer trust what their screen shows them, and does your vendor's opsec become your problem? Those are infrastructure, process, and human questions—outside the scope of any code review, no matter how thorough.

Projects that treat "audited" as "secure" are answering the wrong threat model. The attackers already know this; that's why the mechanisms above skip the contract entirely.

Operational Security Checklist

Key & Access Management

Deployer/private keys live in a multisig or hardware security module (HSM)—never on a single device
A documented, regularly reviewed list of who holds access to critical keys and servers
Access revoked immediately on termination or role change
A written runbook for who can sign or deploy, and how

Infrastructure & Servers

Production servers patched on a regular cadence
SSH keys (not passwords) for server access; 2FA on every admin panel
Contract deployment goes through a secured CI/CD pipeline—never from a personal machine
Monitoring and alerts for unusual activity: unexpected deploys, abnormal transactions

Organizational Controls

Separation of duties—no single person can both deploy and sign alone
Regular internal access reviews
A written incident response plan for the first hours after a suspected compromise

Post-Launch Monitoring

On-chain monitoring with alerts for anomalous function calls
A bug bounty program running alongside—not instead of—your audit

Run this list against your own team honestly. If you can't check every box, that's the gap an attacker will find first—and no audit report will have warned you about it.

Conclusion

A passed audit, or a completed penetration test, closes one chapter—it tells you the code and the infrastructure you tested were sound at that moment. It was never a claim about the weeks and months after, when keys get issued, teams change, and a new signer joins a call they've never joined before. That's the part operational security has to cover, continuously, on its own.

It's also why the strongest programs don't treat security as a single engagement. A standing bug bounty program keeps researchers actively probing your live attack surface between audits—catching what changed since the last review, rather than waiting for the next one to find it.