The Web2 blind spot: Why audited smart contracts get hacked

On February 21, 2025, Bybit lost approximately 401,347 ETH. The contracts that handled the transfer were audited. They behaved exactly as specified. They did not contain a reentrancy, an oracle manipulation, an access-control gap, or any other bug class a smart contract audit would catch. The attackers compromised a developer machine at Safe Wallet, injected JavaScript into the wallet UI served from an AWS S3 bucket, and waited. When Bybit's multisig signers approved what their browsers showed them was a routine cold-to-warm wallet transfer, they were signing a different transaction underneath.

It was the largest single cryptocurrency theft ever recorded. The smart contracts were not the failure point. The seam between the off-chain UI and the on-chain transaction was.

This post is for protocol engineers, CTOs, and investors who already understand why a smart contract audit matters and want to understand why it is no longer sufficient on its own. We walk through five real cases of audited protocols compromised entirely off-chain, then look at how the OWASP web vulnerability classes map onto Web3 business logic at the seam, and finally examine why real-time monitoring of how users interact with your protocol is what closes the gap that a pre-launch audit cannot.

What a smart contract audit actually attests to

A smart contract audit is a manual and automated review of source code at a specific commit hash. The deliverable is a report listing findings, severity, reproduction steps, and remediation guidance. Modern audits combine line-by-line manual review with static analysis (Slither, Aderyn), property-based fuzzing (Foundry, Echidna), and increasingly formal verification.

The scope is bounded by the repository. An audit covers the contracts at src/. It does not cover the website at app.protocol.com, the API at api.protocol.com, the signing service that produces the EIP-712 payloads consumed by the contracts, the DNS records that resolve those domains, the CDN account that serves the JavaScript bundle, or the developer laptops that produce the artifacts.

This is not a weakness of smart contract audits. It is what they are. We have written elsewhere about when in a protocol's lifecycle to commission different kinds of review, and about why an audit attests to a commit hash rather than a security posture. The point we want to make in this post is more specific: the attacks that drained the largest amounts from audited protocols in 2024 and 2025 happened in the parts of the stack the audit does not cover, and the response to that pattern requires both a different audit scope and a different operational posture once the protocol is live.

Five audited protocols, five off-chain compromises

Bybit, February 2025, $1.5 billion

NCC Group's technical analysis attributes the attack to a compromise of the transaction approval process at Safe Wallet, the multisig solution Bybit used for cold storage. Lazarus Group (tracked by the FBI as TraderTraitor) compromised a Safe Wallet developer's machine, injected malicious JavaScript into the data served by Safe Wallet's AWS-hosted UI, and crafted the payload so that only Bybit's multisig appeared to receive the modified flow. The signers approved a transfer they thought was routine. The transaction that actually executed on chain replaced the wallet's logic, handing Lazarus full control over the cold wallet's contents. Sygnia's forensics found no compromise of Bybit's own infrastructure.

We covered the full Bybit, Cetus, and Balancer cluster in our 2025 exploit lessons piece. The salient detail for this post: the contracts were correct, the signers were following procedure, and the attack landed because the layer the signers saw with their eyes was lying to them.

Curve Finance, August 2022 ($575K) and May 2025 (incident response)

In August 2022, Curve Finance's curve.fi domain was DNS-hijacked. Attackers compromised iwantmyname, the nameserver provider, cloned the Curve frontend, and rerouted traffic to the clone. Users who connected their wallets were prompted to approve a malicious spender contract at 0x9eb5f8e83359bb5013f3d8eee60bdce5654e8881. Approximately $575,000 was drained in the window before the team identified the issue and pushed users to the alternate curve.exchange interface. REKT's writeup characterized it cleanly: DeFi protocols are only as secure as their centrally-hosted frontend.

In May 2025, Curve was hit again. The .fi domain was DNS-hijacked a second time within a week. The team migrated to neutral nameservers and stood up curve.finance as a secondary interface while the incident played out. Same class of attack, three years later, on a protocol that had every smart contract audit money could buy.

BadgerDAO, December 2021, $120 million

BadgerDAO's technical postmortem documents an attack that started not with a smart contract exploit but with a Cloudflare API key compromise. The attacker deployed a Cloudflare Worker (a JavaScript runtime that operates on traffic as it passes through Cloudflare's edge) via an API key created without the knowledge or authorization of Badger engineers. The first evidence of attempted account takeover is dated August 20, 2021. The first malicious script execution is dated November 10, 2021. The mass drain happened on December 2, 2021. The script injected unlimited spend approvals into the user's MetaMask transaction flow when they interacted with the BadgerDAO app, targeting roughly 500 wallets. Around $120 million was stolen.

Halborn's writeup is unambiguous: "From the perspective of the project's smart contracts, nothing had gone wrong." Trail of Bits founder Dan Guido, quoted in Vice's coverage at the time, put it concretely: "Supply chain integrity means every link in the chain. Badger clearly thought through parts of their development and deployment process, using simple and secure tools like Github and a single-page web application. However, success for supply chain integrity requires perfection, and instantly accurate security monitoring." That last phrase is the one we will come back to.

KyberSwap, September 2022, $265K

KyberSwap's frontend served users a malicious "Increase Allowance" prompt that routed approvals to an attacker-controlled spender. The initial public statement blamed Google Tag Manager. The official postmortem, published after a fuller investigation, identified a deeper root cause: a compromised Cloudflare account belonging to a former KyberSwap SRE employee. The malicious script targeted whale wallets specifically, increasing the take per compromised session. Two large addresses were impacted; total losses were $265,000.

The KyberSwap case is instructive for two reasons. First, the initial attribution (GTM) was wrong; the actual attack chain was further upstream in the Cloudflare account itself. Audits and incident response both have to walk back the causal chain past the most visible artifact. Second, the proximate cause was an offboarded employee whose access was never revoked. That is a standard OWASP-class identity and access management failure, not a Web3-specific bug.

Squarespace DNS hijack cluster, July 2024, ~228 protocols at risk

In July 2024, Compound Finance's frontend redirected visitors to a malicious page that ran a wallet-draining script. Celer Network detected an attempt against its own domain at the same time and recovered the records before users were affected. Pendle and a long list of other DeFi domains were subsequently flagged. The common thread, as identified by Blockaid and reported by BleepingComputer, was Squarespace.

Google had sold its domain business to Squarespace in late 2023. The forced migration of Google-registered domains to Squarespace did not preserve two-factor authentication on the migrated accounts. Attackers exploited this by triggering password resets on the Squarespace side of accounts that the legitimate owners thought were 2FA-protected. Once they had account access, they modified DNS A records and pointed user-facing domains to Inferno Drainer infrastructure. The DefiLlama developer 0xngmi compiled a list of 126 affected DeFi domains within hours of the incident; Blockaid estimated 228 protocol frontends remained at risk for some period after disclosure.

The protocol teams did nothing wrong on the day of the attack. The compromise had been latent in the registrar account since the migration.

Five audited protocols, five off-chain failure modes mapped to stack layers

Why isolated smart contract audits no longer suffice

These five cases share a pattern. The contracts were either audited (Bybit, BadgerDAO, KyberSwap, Compound) or had survived years of public scrutiny with no exploit (Curve). The attack landed in one of the off-chain components: a developer machine, a DNS provider, a registrar, a CDN account, a third-party signing service. The on-chain code was correct throughout.

The conclusion is structural, not editorial. Modern DeFi protocols are mostly off-chain. The contracts are the smallest part of the codebase. The backend that signs EIP-712 payloads, the API that gates state transitions, the frontend that constructs transactions, the indexer that feeds the UI, the relayer that forwards user operations, the CI pipeline that produces the bundle the user actually downloads, all of it is off-chain. The smart contract is the last 5 percent of the stack and the first thing teams audit. The first 95 percent is where the attacks are landing.

This is why we have spent the last year arguing publicly that the weakest link in DeFi is not the smart contract, and why Web2 infrastructure failures keep becoming Web3 exploits. The pattern is consistent enough that we now treat smart contract audits and off-chain pentests as two halves of the same engagement.

OWASP vulnerabilities, Web3 business logic, and the seam between them

The off-chain attack surface that drains Web3 protocols is not exotic. It is the OWASP Top 10 and the OWASP API Security Top 10 applied to a stack that has a wallet at the edge.

Broken access control (OWASP web app A01, OWASP API Top 10 BOLA). Six of the ten OWASP API Top 10 vulnerabilities involve technically valid requests. The attacker has real credentials, calls real endpoints, gets real data back. Automated scanners cannot detect these issues because they require knowledge of the business logic. In a Web3 context, this class includes: an API that lets a user trigger an on-chain action they shouldn't be authorized for; a signed-payload endpoint that produces a signature for any caller; a webhook receiver that fires an on-chain call without authenticating the caller. The downstream contract enforces nothing here because it doesn't know it was called by an unauthorized off-chain actor; the request looks valid on chain.

Broken authentication (OWASP API Top 10). The KyberSwap root cause was an ex-employee's Cloudflare account that retained access after offboarding. Identity-and-access-management hygiene at every third-party service the protocol depends on (DNS registrar, CDN, cloud provider, monitoring tools, deploy pipelines) is in scope for a serious off-chain audit. So is multi-factor enforcement on those accounts, recovery email separation, and audit logs.

Security misconfiguration. The Squarespace cluster is a textbook example. A migration removed 2FA from accounts whose owners didn't realize the property hadn't transferred. The Galxe attack of October 2023, which we noted briefly because it illustrates the same class, was a social-engineering compromise of Dynadot's registrar support flow that bypassed 2FA. Domain registrar lockdowns, DNSSEC, and registrar-level monitoring are configuration items, not features.

Software and data integrity failures (supply chain). BadgerDAO is the canonical case. A compromised third-party (Cloudflare) account ran scripts inside the Badger frontend. Bybit took the same pattern to its industrial conclusion: a compromised developer machine at a third party (Safe Wallet) injected JavaScript that ran inside the Bybit signing flow. Our supply-chain attacks against Web3 teams post covers npm dependency confusion, CI/CD pipeline integrity, and SBOM controls in more depth.

Injection (OWASP web app A03). Server-side request forgery (SSRF) and template injection have shown up in NFT metadata fetchers and wallet integration endpoints. SQL injection still exists in Web3 backends that index on-chain state into Postgres. The standard Web2 defenses apply unchanged.

The seam-specific bugs, the ones a generalist pentester is likeliest to miss, sit where off-chain authority crosses into on-chain consequence. EIP-712 signatures generated off-chain and consumed on-chain. APIs that gate state transitions. Backend orchestration of on-chain capital. When two separate vendors audit the two sides, no one owns that seam. The TypeScript audits in Web3 piece goes deeper on what the off-chain layer actually contains in a modern Web3 stack.

Two tracks, one engagement

This is why we run smart contract audits and off-chain pentests as a single engagement, not as two separate purchases. We call it the Full-Stack Audit. One team scopes both sides at once, and the boundary risks (signed payloads, off-chain state authority, API trust at the on-chain interface) get reviewed jointly rather than falling between two vendors.

The on-chain track is our standard smart contract audit. Manual line-by-line review, Slither and custom Aderyn detectors, Foundry invariants, mutation testing, and Krait readiness checks. It covers EVM (Solidity, Vyper, Yul), Solana (Rust, Anchor), and Move, Cairo, and Sway protocols. The pre-audit checklist covers what the team should have ready before kickoff.

The off-chain track is a white-box and black-box pentest of the surface around the contracts. Authentication, authorization, data exposure, OWASP Top 10 fundamentals, and Web3 business logic. It covers REST and GraphQL APIs, microservices, indexers, relayers, dApp frontends, signed-payload generation paths, webhook receivers, and the infrastructure underneath. The Application Security Audits page has the detailed scope.

The most recent public Full-Stack engagement was Dripster, a leveraged prediction-market vault on Polygon. The on-chain contract handled a 14-state position lifecycle with EIP-712 signature-gated state transitions. The off-chain NestJS backend signed those payloads and routed orders to Polymarket. We audited both tracks in parallel and closed both reports within a day of each other. The findings that mattered most were on the seam: assumptions the contract made about what the backend would and would not sign, and the corresponding assumptions the backend made about what would and would not be accepted on chain. Neither audit would have caught those issues on its own.

That is the structural argument for the Full-Stack Audit. The next section is the operational one.

The audit ended. The attack hasn't started yet.

A pre-launch audit is a snapshot. The day you ship, your protocol begins generating attack surface that did not exist when the audit ran. Users connect wallets. Approvals get granted. A third-party drainer crew adds your project to their target list. Your DNS provider experiences turnover. Your CDN account's API keys age. A developer leaves and isn't fully offboarded from every service.

The framing that has become consensus among incident responders is that exploits are not atomic events. They are processes. Hypernative's writeup on the Euler attack puts it cleanly: "An exploit is not a singular event, but rather a process that unfolds over time. Because of that, hacks can be detected in real time and can be stopped." The Euler attacker funded the attack from Tornado Cash ten minutes before exploitation, deployed two staging contracts twelve seconds apart eight minutes before exploitation, and only then executed the main exploit transaction. Forta's Attack Detector V3 fired warnings three minutes before the attack landed, with the victim already correctly identified as Euler.

Three minutes is not a long time to respond manually. It is plenty of time for an automated pause to fire. If Euler had had an automated circuit breaker wired to Forta alerts, $197 million would have stayed in the contract.

The lesson generalizes. Most off-chain compromises also generate observable pre-exploit signals. BadgerDAO's malicious script first ran on November 10, 2021. The mass drain landed on December 2. That is twenty-two days of observable anomalous approval patterns in the on-chain data. Curve's hijacked domain pointed to the wrong IP, a state visible in DNS resolver logs and TLS certificate transparency feeds. Bybit's malicious Safe Wallet JavaScript was being served from S3 with a bundle hash different from the known-good Safe Wallet version. The signal was there in every case. The question is whether anyone was looking.

Detection windows on real DeFi attacks: pre-exploit signals vs. drain

Catching the attack on the act: monitoring at three surfaces

Effective post-deployment security treats the seam between off-chain and on-chain as a monitorable signal. Three surfaces generate the most useful pre-exploit telemetry: the on-chain user interaction stream, the off-chain infrastructure state, and the mempool.

On-chain user-interaction signals

Approvals are the highest-yield signal for catching frontend compromises. The mechanics of every major wallet drainer attack, BadgerDAO, KyberSwap, Inferno Drainer's entire kit, route through approve or increaseAllowance to a spender address that the protocol never authorized. That spender is, by construction, a fresh contract that has never received approvals before. A sudden spike in approvals to a previously unseen address, originating from many of your protocol's users in a short window, is approximately a perfect signature of a hijacked frontend.

Concretely, the things worth instrumenting:

Approvals from your protocol's user base to spender addresses not in your canonical contract registry. Threshold low: even one is suspicious if the user has never approved that spender before.
Sudden distribution shift in function-call mix. A protocol that normally sees 95 percent swap calls and 5 percent admin calls suddenly showing a flood of transferFrom from a single spender is a five-alarm signal.
Invariant breaks at the contract level. TVL drift past a threshold within N blocks; total supply diverging from the sum of balances; reserve utilization spike; oracle staleness past expected bounds. These are protocol-specific; they require the engineering team to declare what "normal" looks like before they can detect "abnormal."
Token movements to addresses associated with known drainer infrastructure. Address-tagging feeds from Chainalysis, TRM Labs, or open-source equivalents close this loop.

Off-chain infrastructure signals

The Web2 plane generates observable state changes that should require explicit approval to occur. Most teams don't monitor them.

DNS records. A diff in A-records or NS-records outside a planned deployment window is a hijack indicator. Curve and Squarespace incidents both produced DNS diffs visible to any monitor.
TLS certificate transparency logs. A new certificate issued for your domain to a different CA, or with an unusual configuration, indicates either a deploy you didn't authorize or a compromise. The CT log is public; subscribing to it for your domains takes one HTTP endpoint.
CDN configuration. New Cloudflare Workers script, new edge route, new transformation rule, new API key created. BadgerDAO's audit logs contained the worker deployment that drained the protocol; the diff was visible but unreviewed.
Production bundle hash. Pin the known-good hash of your production JavaScript bundle and diff against what your CDN actually serves. Subresource Integrity (SRI) hashes on every third-party script tag enforce this at the browser level: a modified third-party script will fail to execute. SRI applied to all non-first-party scripts would have stopped the KyberSwap and Bybit attacks at the user's browser.
Domain registrar account state. 2FA enforcement, recovery email, registrar lock, session log. Migrations are particularly dangerous (the Squarespace cluster is the canonical case). Audit any property migration.

Mempool signals

Many exploits leave fingerprints in the mempool before the main exploit transaction lands. The detection surface is rich enough to support an entire industry of attack-detection bots.

Suspicious contract deployment. Forta's malicious-contract ML bot scans every contract creation across multiple chains for opcode-level patterns associated with previous exploits. The team behind it reported precision around 88 percent and recall around 59 percent at the threshold used in production. False positives are higher than you'd want for automated pause, but the detection rate on actual hacks is high enough to be a primary signal in a human-in-the-loop runbook.
Funding from privacy mixers. Tornado Cash, Railgun, and others. An EOA funded from a mixer that immediately deploys a contract that calls into your protocol is a textbook pre-attack signature. Forta's Tornado Cash bot fired on the Euler attacker ten minutes before exploitation.
Dry-run transactions. Attackers frequently rehearse on testnet, or with small amounts on mainnet, before the real exploit. The dry-run shows up as anomalous call patterns from an address that has never previously interacted with the protocol.

Are you audit-ready?

Download the free Pre-Audit Readiness Checklist used by 30+ protocols preparing for their first audit.

No spam. Unsubscribe anytime.

Available tooling

Several vendors have built out this space; we mention them here for reference, not endorsement.

Forta. Decentralized network with community-built detection bots and the Forta Attack Detector. The Euler retrospective is the cleanest published case. Forta's average time-to-detection across 2024 incidents was reportedly around 950 seconds before exploitation, with 83 percent of attacked protocols receiving no false positives in the 60 days prior to their attack (Attack Detector 2.0 figures).
Hypernative. Machine-learning-based detection across smart contract behavior, suspicious flow patterns, and bytecode of newly deployed contracts. Bitwise selected Hypernative in March 2026 for institutional DeFi exposure across its $15B+ platform.
Blockaid. Wallet-side and protocol-side detection. Blockaid was the firm that publicly attributed the July 2024 Squarespace cluster and warned users in real time via MetaMask integrations.
Chainalysis Hexagate. Flow-level anomaly detection at protocol and exchange boundaries.
OpenZeppelin Defender Sentinel, Tenderly Alerts. Protocol-specific invariant alerts. Useful for the team's own custom signals (e.g. "TVL changed by more than 5 percent in 100 blocks" or "oracle deviated more than 3 percent from canonical source").
In-house. For any protocol with $50M+ TVL, custom invariant monitoring scripted against an indexer or RPC is table stakes. The Forta detection bot model demonstrates the design pattern.

A monitoring posture that actually catches the attack

Detection alone is not enough. The Euler team received Forta's alerts and could not pause the protocol fast enough through a manual multisig. The architectural lesson is that detection must be wired to an automated response, or the detection is academic.

A baseline monitoring posture for a protocol going to mainnet:

Define your invariants. What is true at every block? TVL is between A and B. Reserve ratio is above X. Oracle freshness is within Y seconds. Sum of balances equals total supply. Auditors flagging this during the engagement is half the work; the team operationalizing it as monitoring is the other half. We covered this pattern in defense-in-depth workflow.
Instrument approval anomalies. Subscribe to your protocol's user base's approve and increaseAllowance events. Maintain a registry of canonical spender addresses. Alert on any approval to a non-canonical spender. False positive rate will start high; tune over weeks.
Subscribe to Web2 surface alerts. DNS diff, CT log subscription, CDN config audit log, registrar account audit log. These are checklist items; commodity SaaS exists for each one.
Pin and verify the production bundle. Known-good hash of every JavaScript file your frontend depends on. SRI on every third-party script. Continuous diff against the live deployment.
Wire a circuit breaker. A pause function callable by a hot key from your monitoring infrastructure. The trust model is: the cost of a false-positive pause is far lower than the cost of a real exploit running to completion. Most protocols treat pause as a multisig action and lose the response time. The teams that fared best in 2024 and 2025 had keyed-down pause authority with a clear runbook for unauthorized triggers.
Rehearse the runbook. When an alert fires at 3am UTC, who responds, what's the decision tree, what's the rollback, what's the user communication. This is operational, not architectural, and it is consistently the bottleneck that real incident response hits.

The security audit subscription we offer covers iterative review while the engineering team builds these systems. The monitoring layer is downstream of the architecture; getting the architecture right cuts the noise on the monitoring stack by an order of magnitude.

Six-step monitoring posture wired to an automated circuit breaker

What this means for a CTO scoping a security engagement

If you are about to ship a Web3 protocol and have a smart contract audit on order:

Add the off-chain pentest to the engagement. Same vendor if possible, so the seam gets owned. If you can't get it from one vendor, write the seam responsibilities into both contracts so neither side disclaims them.
Treat domain, DNS, CDN, and registrar as in-scope for the off-chain audit. The history of off-chain DeFi attacks is dominated by these surfaces. The 2024 Squarespace cluster, BadgerDAO's Cloudflare worker, KyberSwap's Cloudflare account, Curve's nameserver: all four were standard infrastructure compromises that any senior pentester knows how to model.
Have a monitoring plan before mainnet, not after the first incident. The Forta or Hypernative subscription is not a post-incident response; it is part of the launch checklist. The internal invariant monitoring is the other half.
Wire the detection to an automated pause. If your pause is gated on a multisig that takes ten minutes to round up signers, your detection budget is ten minutes minus your alert-to-signer latency. That is not a defense; it is a delayed obituary.
Get the OPSEC right around the wallet flow. Bybit's signers approved what the UI showed them. A trained signer with a hardware wallet that displays the actual calldata, and the discipline to verify that what's displayed matches what was intended, would have caught the malicious payload. This is human, not technical.

If your team is comparing vendor scope and pricing, our 2026 audit pricing guide breaks down what a defensible quote looks like across smart contract and full-stack engagements.

The on-chain and off-chain surfaces are one attack surface

Smart contract audits matter. They will continue to matter. They are not the whole picture, and the protocols that have lost the most money in the last 18 months are mostly protocols whose contracts were audited and uncompromised.

The Zealynx Full-Stack Audit reviews the on-chain code and the off-chain stack in parallel, with the boundary risks reviewed jointly rather than fragmented across two vendors. The Application Security Audit is the off-chain track on its own, for teams whose contracts are already covered. The Smart Contract Audit is the on-chain track on its own, for teams whose off-chain surface is genuinely minimal.

The seam between the audited code and the world around it is what the attackers are pulling on. Audit it together. Monitor it together.

Get in touch

If your protocol has a frontend, an API, a backend signing service, or any meaningful off-chain infrastructure, your audit scope should reflect it. Send us your repos and a target date at zealynx.io/quote and we will come back with scope and quote within 24 hours.

You have contracts only and the off-chain surface is genuinely minimal. Start with our Smart Contract Audit.
You have contracts plus a real off-chain stack (frontend, API, signers, indexers). The Full-Stack Audit is the right scope.
Your contracts are already audited and you need someone to look at the rest of the stack. The Application Security Audit covers the off-chain layer on its own.
You ship every two weeks and need continuous review rather than a one-shot audit. The Security Audit Subscription covers iterative review across a release cadence.
You are earlier in the cycle and want a free automated readiness pass before scoping the audit. Run Krait on your contracts first.

Frequently asked questions

1. I already commissioned a smart contract audit. Do I need a full-stack audit too?

If your protocol has a frontend, an API, a backend signing service, or any meaningful off-chain infrastructure, yes. The five case studies in this post all involved protocols with audited contracts. The audits did their job. The attacks landed elsewhere. The full-stack audit covers that elsewhere. The Full-Stack Audit page describes the two-track scope and how the boundary risks are owned by a single team.

2. What is the difference between a smart contract audit and a full-stack audit?

A smart contract audit reviews source code at a commit hash in your contract repository. It does not cover the website at app.protocol.com, the API at api.protocol.com, the service that signs EIP-712 payloads, the DNS records that resolve those domains, the CDN account that serves your JavaScript, or the developer laptops that build the artifacts. A full-stack audit reviews both the contracts and that off-chain stack as a single engagement, with the seam between them owned by one team rather than disclaimed by two vendors. See our post-audit security post for why an audit attests to a commit hash rather than a security posture.

3. Can a smart contract auditor catch a DNS hijack or a CDN compromise?

No. A DNS hijack and a CDN compromise are both invisible to a smart contract audit because the contract has no knowledge of what URL the user typed into their browser, what IP that URL resolved to, or what JavaScript was served from that IP. The auditor reviews source code at a commit hash; the DNS record and the CDN configuration live outside that scope. When Web2 infrastructure breaks DeFi walks through exactly which Web2 components fall outside the smart contract scope.

4. What is a wallet drainer attack and how do they bypass an audited smart contract?

A wallet drainer is a phishing kit that, once a user lands on a malicious page, automates the entire approve-and-transfer sequence to steal tokens or NFTs. The user signs approve or increaseAllowance calls to a spender address controlled by the attacker; the attacker's contract then calls transferFrom to drain the wallet. The smart contract behaves exactly as designed: the user signed the approval, so the transfer is valid. The audit cannot prevent this because the bug is not in the contract. It is in the page the user thought they were on. BadgerDAO, KyberSwap, and the entire Inferno Drainer family route through this pattern.

5. How does real-time monitoring catch a DeFi exploit before funds are drained?

By treating an exploit as a process rather than an event. Most attacks generate observable signals before the main drain transaction lands: attacker funding from Tornado Cash, suspicious contract deployment, dry-run transactions, invariant drift on the target protocol, anomalous approval patterns from the user base. Forta reported an average time-to-detection of roughly 950 seconds (about 16 minutes) before exploitation across 2024 incidents; the Euler attacker was visible 10 minutes before the first exploit transaction. The detection is only useful if it is wired to an automated circuit breaker — a pause function that fires from monitoring infrastructure without waiting for a multisig to round up signers. Defense-in-depth workflow covers the architecture.

6. What is the minimum monitoring posture for a $50M+ TVL DeFi protocol?

At a minimum: (1) three protocol-specific invariant alerts (TVL bounds, supply/balance reconciliation, oracle freshness); (2) DNS and Certificate Transparency log monitoring on all production domains; (3) Forta Attack Detector or an equivalent feed subscribed to the contract addresses; (4) approval-anomaly alerts on the user base, with a registry of canonical spender addresses; (5) a pause function callable from monitoring infrastructure with a written runbook for who responds at 3am UTC. Most of this is commodity tooling — the engineering work is defining what "normal" looks like for your protocol so abnormal can be detected.

Glossary

EIP-712. Ethereum standard for typed, structured data signing. Off-chain services that sign payloads consumed by on-chain contracts almost always use EIP-712. The seam where most of the boundary bugs live.

Wallet drainer. A phishing kit that automates the approve-and-transfer flow to steal tokens or NFTs once a user is on a malicious page. Inferno Drainer is the canonical example.

Subresource Integrity (SRI). A browser-enforced check that a script loaded from a third-party origin matches a hash specified by the page. Prevents script substitution attacks at the user agent.

Certificate Transparency (CT) log. A public append-only log of every TLS certificate issued by a participating Certificate Authority. Allows real-time monitoring for unauthorized certificate issuance against a domain.

DNS hijacking. Unauthorized modification of DNS records to redirect users from a legitimate domain to an attacker-controlled clone. The Curve and Squarespace incidents are both DNS hijacks.

Supply chain attack. Any attack where the compromise enters via a trusted upstream component — a dependency, a build pipeline, a third-party script, a vendor account.

Circuit breaker. A contract-level pause function wired to monitoring infrastructure that can halt operations when an alert fires, without waiting for multisig signers.

Forta. Decentralized network of detection bots that monitor on-chain activity for security and operational anomalies. Originated as an OpenZeppelin project.

Hypernative. Commercial real-time security platform focused on DeFi protocol monitoring and automated response.

OWASP Top 10. Industry-standard list of the ten most critical web application security risks, maintained by the Open Web Application Security Project.

OWASP API Security Top 10. Companion list focused on API-specific vulnerabilities, including BOLA (Broken Object Level Authorization), broken authentication, and access to sensitive business flows.

Are you audit-ready?

Download the free Pre-Audit Readiness Checklist used by 30+ protocols preparing for their first audit.

No spam. Unsubscribe anytime.