Penetration Testing for Crypto and Web3

Crypto and Web3 companies get attacked differently than mainstream SaaS. A bug in a checkout flow costs a retailer some fraud losses and an afternoon of cleanup. A bug in a smart contract, a bridge, or a custody wallet can drain funds in minutes, publicly, with no chargeback and no way to claw the money back. That asymmetry is why penetration testing for this sector needs to look different from a standard web app assessment, and why generic testing is not enough.

Why the stakes are different

Traditional web applications fail gracefully most of the time. Crypto and Web3 systems often fail catastrophically. A handful of factors make the sector a distinct threat category:

• Irreversibility. On-chain transactions cannot be reversed. There is no fraud department to call, no bank to freeze the wire.
• Public attack surface. Smart contracts are often deployed with source code visible on-chain or verified on a block explorer. Attackers can read your logic before they ever touch your infrastructure.
• Composability risk. Web3 products integrate with wallets, oracles, bridges, and other protocols. A vulnerability in a dependency becomes your vulnerability.
• Regulatory pressure. Exchanges, custodians, and stablecoin issuers increasingly face compliance obligations that require demonstrable security testing, not just a checkbox audit.
• High-value targets. Treasury wallets, bridge contracts, and custody infrastructure hold liquid value that draws organized, well-funded attackers, not opportunistic scanners.

The result is a threat model where a single missed authorization check or an unvalidated signature can be the difference between a normal Tuesday and a headline. Testing needs to reflect that.

What we actually test

A crypto or Web3 engagement is rarely just a web app scan. Depending on what you have built, scope typically spans several layers:

• Web and API surfaces. The dashboard, admin panels, and REST or GraphQL APIs that front your platform, tested the same way we test any production web application, for injection, broken access control, and logic flaws.
• Wallet and key management flows. How keys are generated, stored, rotated, and authorized. This is where custody incidents actually happen, far more often than an exotic contract exploit.
• Smart contract and on-chain logic. Reentrancy, integer handling, access control on privileged functions, oracle manipulation, and upgrade mechanisms if the contract is proxy-based.
• Infrastructure and cloud. Node operators, RPC endpoints, hot wallets, and the cloud environment hosting your backend services, reviewed with the same cloud and network testing methodology we apply across every engagement.
• Bridge and cross-chain logic. If your product moves value across chains, that boundary gets dedicated attention. It is one of the most exploited attack surfaces in the sector.

All of it is human-led. Automated scanners catch a fraction of what matters in a codebase where a logic error, not a missing patch, is usually the root cause of a real incident. Our testing is led by Jacob Masse, a published security researcher with five CVEs to his name, including CVE-2024-45163, a CVSS 9.1 finding that functioned as a kill-switch against the Mirai botnet. That is the kind of adversarial thinking crypto infrastructure needs: someone who has found and weaponized real vulnerabilities, not just run a checklist.

For engagements that need deeper offensive depth, particularly contract-level exploitation or red-team style attack chains, we co-deliver with our offensive-security partner Lorikeet. You get one point of contact and one report, backed by two teams with complementary specializations.

How we scope it

Scoping starts with a conversation about what you have built and what is actually at risk. A DeFi protocol with a live treasury needs a different test plan than an NFT marketplace or a custodial exchange. We typically walk through:

• What is on-chain versus off-chain, and where the trust boundaries sit between them
• Whether contracts are audited already, and by whom, so we are not duplicating work
• What custody model you use, self-custody, multisig, or third-party custodian
• What compliance driver is behind the engagement, if any, since evidence requirements differ
• Timeline pressure, particularly around mainnet launches or major upgrades

From there we build a scope document that names exactly what gets tested, what does not, and what a pass or fail looks like for each component. No surprise line items, no vague "we'll look around" language.

One test, two purposes

A lot of crypto and Web3 companies are also working toward compliance certifications, either because a bank partner requires it, an institutional client demands it, or a regulator is asking questions. The same penetration test that finds real vulnerabilities also produces the documented evidence auditors expect for SOC 2 and PCI DSS engagements. Rather than running one test for security and a separate one for the auditor, you get a single engagement that satisfies both. If compliance is part of your roadmap, our broader security testing services are built around that dual purpose from the start, and it is worth reviewing our compliance advisory work if you are mapping out a certification timeline alongside the testing.

What you get at the end

Every engagement ends with a report written for two audiences: your engineers, who need reproducible steps and remediation guidance, and your leadership or auditors, who need a clear risk summary they can act on or hand to a partner. We do not pad reports with informational findings to look thorough. If something is not exploitable and not a real risk, we say so.

If your platform touches on-chain value, custody, or bridges, the cost of a missed vulnerability is not theoretical. Contact us to talk through your architecture and get a scoped proposal for a penetration test built for how crypto and Web3 systems actually get attacked.

A contract audit and a penetration test are not the same product

The most common confusion in this sector is between a smart contract audit and a penetration test, and buying the wrong one wastes both money and calendar. A contract audit is a code review of on-chain logic, usually line by line, often supported by formal methods or property-based fuzzing, and it produces findings against the contract source. A penetration test is an adversarial assessment of a running system, including everything the contract touches: the front end, the API, the signing infrastructure, the operators, the cloud account, the deployment pipeline.

The failure mode is a protocol that has three contract audits, publishes them proudly, and gets drained through an admin key that lived in an environment variable on a build server. The contracts were fine. Nobody tested the path to the keys that control them. If you only have budget for one, the honest answer depends on where value actually sits: novel on-chain logic holding pooled funds needs the code review first, while a custodial product with standard contracts and complex operations needs the operational assessment first.

Ideally the two are sequenced, with the code review completed and remediated before the penetration test, so we are testing the system you intend to run rather than a moving target. Tell us what has already been reviewed and by whom during scoping, so we spend our hours on the surfaces nobody has looked at.

Key management is where the money actually leaves

Across the incidents that matter, the root cause is far more often a key handling failure than a clever mathematical exploit. So this is where we spend disproportionate effort, and the questions get uncomfortable.

Where was the seed generated, on what machine, and was that machine ever connected to a network? Who was present, and does a written record of that ceremony exist? How many shares or signers exist, what is the threshold, and, critically, are the signers genuinely independent, or do three of the five keys live on devices controlled by the same two people in the same office? A three-of-five multisig where one person can reach three signing devices is a one-of-one multisig with extra paperwork.

Then the operational layer. What is the hot wallet balance policy, and who enforces it? Is there an address allowlist for withdrawals, and how does an address get added, and can the person who initiates a withdrawal also approve the allowlist entry? Is there a value threshold above which a second human is required, and has anyone tested whether that threshold can be bypassed by splitting the transaction? Are signers reviewing the decoded transaction on a device with a screen, or blind-signing a hash because the tooling makes verification tedious? Blind signing is the mechanism behind several of the largest losses in this sector, and it is almost always adopted because verification was slow rather than because anyone decided it was acceptable.

For threshold and multi-party setups we also look at the recovery path, because recovery is where the real backdoor usually is. A scheme with rigorous signing rules and a poorly controlled emergency reset procedure is only as strong as the reset.

The front end is a real attack surface

Users interact with your protocol through a website, and the website is ordinary infrastructure with ordinary weaknesses. The attacks are not subtle and they keep working. Registrar account takeover leading to a DNS change, so users reach a cloned interface that requests an unlimited token approval. A compromised build pipeline or a malicious dependency update injecting a drainer into the bundle. A stale content delivery configuration serving an old build with a known issue. A subdomain left pointing at a decommissioned host and claimed by someone else.

We test the registrar and DNS provider accounts for MFA and for who holds recovery email access, we review the build pipeline for who can push to production and whether artifacts are integrity-checked, and we look at how dependencies enter the bundle. On the application itself we look at what the interface asks users to sign. Requesting unlimited approvals as a convenience default is a design decision with a long tail of consequences for your users, and it shows up in our reports as a finding even though it is not a vulnerability in the traditional sense.

Privileged functions, upgrades and pause paths

If a contract is upgradeable, the upgrade mechanism is the highest-value target in the system and gets tested as such. Who can propose an upgrade, who can execute it, is there a timelock, and is the timelock long enough for anyone to actually notice and react? A twelve-hour timelock with no monitoring is decoration. We check whether the addresses holding those roles are the ones documented, because drift between the documentation and the on-chain state is common and nobody discovers it until an incident.

The same applies to pause functions and emergency withdrawals. Two questions get asked in every engagement and are answered badly more often than not. First, can you actually pause the system right now, from a device that is with you, without waiting on someone on holiday? Second, has anyone rehearsed it against a fork of mainnet, so you know it works and you know what breaks when you use it? A pause that has never been exercised is a plan, not a capability.

Preparing the environment so the test is worth what you pay

Engagements lose days to environment problems, and the fix is preparation. Give us a forked mainnet environment with realistic state rather than a bare testnet, because most interesting behavior depends on real balances, real liquidity and real integrations. Fund the test accounts before day one. Provide roles at each privilege level, including at least one privileged account, since testing authorization boundaries requires being on both sides of them.

Turn off or allowlist the rate limiting and the WAF for our source addresses, or tell us explicitly that testing through them is the point. Both are valid choices, but deciding it on day three costs a day. If you have integrations with third-party protocols or a custodian, tell them the test is happening. Testing a bridge counterparty without notice is how you get an unrelated incident response process triggered against you.

Finally, tell us where the sharp edges are. Every team has a service that falls over under load or a job that must not be interrupted. Telling us in advance costs nothing. Discovering it during an active test costs you an outage.

The operators are in scope too

Attackers targeting this sector go after people with the same seriousness they go after code. Recruiter approaches carrying malicious files, fake investor calls asking an engineer to install a meeting client, phone number takeovers against staff who still have SMS as a recovery factor somewhere. Where the engagement includes social testing, we look at whether an operations employee can be persuaded to move value or add an address, and at whether the technical controls hold even if the human is fooled. That second half is the point. Assume the human is fooled, and see whether the system still refuses.

Practical controls that come out of this repeatedly: removing SMS recovery from every account associated with treasury or infrastructure, using hardware security keys rather than app-based codes for administrative access, and separating the identity used for exchange and custodian accounts from the identity used for everyday email.

What drives the cost

Penetration testing starts from $1,000 for narrow scopes, and crypto engagements sit above that for reasons worth understanding, since the drivers are things you control.

Surface count is first. A single web application with an API is one thing. A web app plus a mobile app plus a set of contracts plus a bridge plus custody infrastructure is five separate assessments sold under one name, and it takes five assessments worth of hours. Novelty is second: standard, widely deployed contract patterns take less time to reason about than bespoke mechanism design, and bespoke mechanism design is where the interesting bugs are. Environment readiness is third, and it is the one that silently doubles small engagements. Retest scope is fourth, and it should be in the quote from the start rather than negotiated after the findings arrive.

Insist that the retest is included and that it is a real retest against the deployed fix, not a review of your ticket saying the fix shipped. A report without a verified retest tells a bank partner or an institutional counterparty very little, and increasingly they know that.

Bug bounties are not a substitute, and not a competitor

A bug bounty gives you continuous, opportunistic coverage from a large pool of researchers with strong incentives on high-value targets. A penetration test gives you a scheduled, scoped, documented assessment by named people who will talk to your engineers and hand you an artifact your auditors and partners will accept. They cover different gaps.

Two practical points. Do not launch a bounty on an unreviewed codebase: you will pay bounty rates for findings a review would have caught cheaper, and you will do it in public. And make sure your bounty's disclosure terms and your penetration test's reporting do not conflict, particularly around embargo periods and coordinated disclosure to integrating protocols. If your contract is a dependency in someone else's system, your disclosure decisions are theirs too.

When you should not book a test with us

There are several situations where a penetration test is the wrong purchase this quarter, and we would rather say so than take the engagement.

If your contracts have never had a code review, get that first. Paying us to find a reentrancy issue that a dedicated review would have caught more thoroughly is poor value, and we will tell you so during scoping.

If you cannot fix what we find, wait. A report full of critical findings sitting untouched is worse than no report, because it is now documented evidence that you knew. A team that commissions a test to satisfy a partner, fixes the easy findings and leaves the rest, has created a document that can be requested later by a counterparty or a regulator and read against them. Book the test when you have engineering capacity reserved for remediation, not before.

If you are pre-launch with no deployed contracts, no users and no funds at risk, spend the money on architecture review and key management design instead. Getting the custody model right before launch is worth more than testing a system that will be rebuilt anyway.

If your entire need is a compliance checkbox for a framework, say so and we will scope the smallest honest engagement that satisfies it rather than the largest one we could sell. That conversation belongs with the rest of your compliance planning, and it usually costs less than teams expect.

And if the real problem is that nobody at your company owns security decisions between tests, a one-off assessment will not fix it. That is a fractional CISO problem or an ongoing retainer problem, and buying an annual test instead is how organizations end up with a shelf of reports and the same findings in each one.