When Keys Beat Code: Compromised account attacks

TL;DR. Compromised accounts and stolen keys, not smart contract bugs, are now the leading cause of DeFi attacks by incident count. Here's what that looks like in four 2026 incidents, and how to spot it using an explorer.

• In May 2026, compromised accounts and stolen keys accounted for more than half of all DeFi attacks by incident count for the first time, overtaking smart contract exploits as the leading attack vector.
• Consensys removed a software contractor tied to North Korea in 2026 after the developer spent roughly a month contributing to MetaMask's codebase, including work connected to crypto-to-fiat services and the mobile wallet.
• Drift Protocol's $285 million loss in April and KelpDAO's $292 million loss in the same month both traced back to compromised access (an admin key and a manipulated cross-chain message pathway), not a Solidity bug.
• Smart contract logic exploits haven't disappeared: Allbridge Core lost $1.65 million to a flash loan price manipulation attack on July 19, its second such incident since 2023.

Why we're looking at this now

For years, the DeFi security conversation centered on code. Audit contracts, run a bug bounty, get a second opinion, ship. That model assumes the attacker has to find a flaw you missed.

2026's data tells a different story. According to industry incident tracking, compromised accounts, meaning private key theft, access compromise, and credential abuse, made up more than 50 percent of DeFi attacks by incident count in May 2026. That's the first time access compromise has outpaced smart contract exploits as the primary attack source. The dollar figures back it up too: social engineering and access-control failures accounted for the majority of exploit losses tracked in 2025, and 2026 has continued the trend.

The MetaMask case: access risk doesn't need a hack

The clearest illustration this year doesn't involve a drained pool at all. Consensys discovered and removed a software contractor tied to North Korea who had spent about a month embedded in MetaMask's codebase. The contractor, operating under an alias and a GitHub handle unconnected to any real identity, had contributed to work touching crypto-to-fiat services and the wallet's mobile application before Consensys cut off access.

Fortunately, nothing was drained. But this is what "compromised access" looks like before it becomes a headline number. State-linked actors, particularly groups associated with North Korea, have spent 2025 and 2026 refining their approach: embed as legitimate-looking remote developers inside crypto companies in addition to hunting zero-day exploits from the outside.

Drift and KelpDAO: when the key is the exploit

April 2026 produced two of the year's largest losses, and neither was a classic smart contract bug.

Drift Protocol, the largest perpetual futures DEX on Solana, lost approximately $285 million on April 1. The attack combined a compromised admin key with oracle price manipulation and fabricated collateral. The contracts did what they were told, but a bad actor exploited them.

KelpDAO lost roughly $292 million on April 18 when its LayerZero bridge integration was compromised. Attackers linked to North Korea's Lazarus Group compromised RPC nodes and used denial-of-service traffic to fabricate cross-chain messages, convincing the protocol that tokens had been burned on the source chain when they hadn't been. The bridge released real assets against a message that was never legitimate. There was no contract bug, the verification layer was fed false inputs by an insider, causing the drain.

Both incidents moved markets well beyond their own protocols. Aave alone saw roughly $13 billion in DeFi outflows and froze rsETH markets in the aftermath of the KelpDAO exploit, despite Aave's own contracts never being touched. Large-scale attacks have fallout that is rarely contained only to the compromised protocol.

And... code bugs are still very much alive

It would be a mistake to read this and say "smart contract security no longer matters." It clearly still does. On July 19, Allbridge Core paused its cross-chain bridge after an attacker took a $1.12 million USDC flash loan from Kamino, used it to distort the exchange rate inside Allbridge's own stablecoin pool, withdrew liquidity at the skewed rate, and repaid the loan inside the same transaction, walking away with roughly $1.65 million.

AI is accelerating the 2-way street between code bugs and audits. Anyone can find an exploit easier, and teams can also find issues with their own code that may have escaped human-led audits.

What this means for builders

The practical implication is that the definition of security and what it means for a project needs to expand.

Access control is now a first-class attack surface. Who has admin keys, who can merge code, who onboards contractors, and how quickly access gets revoked are now questions with the same weight as "did the audit pass." The MetaMask case shows the exposure window can be a month or longer of quiet, legitimate-looking commits before anyone notices.

Multisig and key management deserve the same rigor as contract logic. An admin key with too few signers, too little monitoring, or too casual an operational process is a single point of failure no audit will flag, because audits look at what the code allows, but not always at who holds the keys that can act on it.

Cross-chain messaging needs multiple independent verifiers. The pattern behind KelpDAO, a single verification path that an attacker can spoof or overwhelm, keeps showing up in bridge incidents. Diversifying who attests to a cross-chain message removes the single point of failure that made the fabricated-burn attack possible in the first place.

On-chain monitoring still catches what access control misses. Even when the initial compromise happens off-chain (a stolen credential, a malicious contractor, a phished admin), the resulting transactions are visible. Unusual withdrawal patterns, such as an admin key suddenly moving funds outside its normal behavior, or a bridge minting against a burn that never happened, all leave a trace. Watching for that trace is a different discipline than auditing Solidity, and it's the one most teams underinvest in.

How to actually look for this on an explorer

Access compromise doesn't hide the way a subtle Solidity bug does. The exploit itself is usually a handful of transactions that look wrong the moment you know what to check. Here's what that checking looks like in practice.

Confirm what an address actually is before you trust it. An admin key, a multisig, or a bridge verifier should be a known, labeled address behaving in a known way. Pulling up an address's basic info tells you immediately whether it's an EOA or a contract and when it first transacted on a given chain. A privileged address that's suddenly an EOA when it should be a multisig, or one with a first-transaction timestamp from a few days ago instead of years ago, is worth stopping on.

Filter transaction history by method, not just by address. A full transaction list for a busy contract creates a lot of noise: funding transfers, routine calls, and the one exploit sequence buried somewhere in the middle. Filtering by the specific method selector (a withdrawal function, an admin-only call, a bridge's mint or release function) isolates exactly the transactions that matter and strips out everything else. This is the same approach that made it possible to trace 30 drain transactions included into a single block during last quarter's Gnosis Safe module exploit.

Watch token holdings on privileged addresses, not just balances. A consolidation wallet or an admin address that suddenly holds a token it's never held before, or holds a single token at a suspiciously round number, is a stronger signal than a balance change alone. Spam airdrops clutter an attacker's entry wallet; a clean, single large holding usually marks the address actually consolidating stolen funds.

Reconstruct the timeline in both directions. Pagination matters here. The first batch of results after a rough time window often starts mid-attack, not at the beginning. Paginating backward with the cursor from the earliest transaction in a batch, rather than assuming the first page is the first block, is usually the difference between finding the real starting timestamp and missing it by minutes.

For bridges specifically, check both sides of the message. A fabricated cross-chain message, the KelpDAO pattern, only looks wrong if you compare the source chain and destination chain side by side: was there actually a burn or lock event matching the mint or release on the other end? An explorer that reads both chains lets you check that correlation directly instead of trusting the bridge's own internal accounting.

None of this requires finding a bug in anyone's code. It requires treating a privileged address the same way you'd treat a stranger's wallet: verify what it is, watch what it does, and don't assume a label is accurate just because it's been correct before.

Where this leaves the industry

Neither attack category is going away. Flash loans aren't getting more expensive, so price-manipulation attempts against thin liquidity will keep happening. And state-linked actors have found that patient social engineering against a hiring pipeline is often cheaper and quieter than hunting for a zero-day, so that approach isn't going anywhere either.

What's changed is the ratio, and ratios shift budgets. If access compromise is now the leading cause of incidents by count, the marginal dollar spent on a fourth audit pass is probably less valuable than the same dollar spent on access review, multisig hardening, and the kind of address-level monitoring outlined above.

Want the next deep-dive delivered directly?

Subscribe to the Monthly Brief for research, data, and analysis on where onchain security, infrastructure, and multichain tooling are headed next.

Subscribe to the Monthly Brief →