Web3 penetration testing

A smart contract audit has a scope, and a report worth reading states it: these files, at this commit, on this chain. Everything outside that boundary is not a gap in the work. It is a different piece of work that was not commissioned.

That boundary is narrower than most teams assume. The contract is the part that holds the funds, so it receives the review. It is also the part an attacker finds hardest to change, because it is public, immutable by default, and watched. The surrounding system is none of those things.

In plain terms: the audit answers whether the vault is built correctly. A penetration test asks who has a key to the room the vault is in, and what happens if they are not the person you think.

Architecture diagrams show contracts, a front end and an API. The surface an intruder works against is larger and less tidy.

It includes the hosting account that serves the interface and the DNS records that point at it. The API and whatever it trusts about the client calling it. The cloud roles, including the ones granted for a migration two years ago and never revoked. The repository, the people with merge rights, and the automation that holds deploy credentials. The administrative tooling built quickly because only staff would ever see it. The laptops and phones belonging to the people who sign transactions.

In plain terms: your protocol is on chain, but your organisation is not, and an attacker is content to attack either.

A careful user can read your contract, confirm the deployed bytecode matches what was audited, and check who holds the admin keys. None of that tells them anything about the page they are looking at.

They are trusting that the domain still resolves to your hosting, that the hosting still serves your build, and that every dependency in that build is the one you intended. A registrar account with a recoverable password, a stale token with write access to the hosting bucket, or a compromised package somewhere in the dependency tree each produce the same outcome: a page that looks correct and constructs a transaction that is not.

This path takes user funds without touching the protocol. The contract behaves exactly as audited, the chain records a valid signature, and nothing on chain was defeated, because the deception happened before the user signed.

In plain terms: the interface is part of your product in every way that matters to a user, and it is the part they have no way of checking.

A multisig with a five-of-nine threshold is a statement about cryptography. Whether five of those nine can be reached is a statement about operations, and the second question is the one an intruder asks.

The practical questions are where each signer's key material lives, what else runs on that machine, whether the hardware wallet is held by a person or sits permanently connected in an office, how a signer is replaced when somebody leaves, and whether any single person controls enough of the signing set to act alone in practice.

A recovery path deserves the same attention. Seed phrases in a shared password manager, a cloud backup made once during setup, or a custodian whose own account recovery runs through an email address, each reduce the scheme to the weakest of those paths rather than to its stated threshold.

In plain terms: a threshold describes how many signatures are required. It does not describe how hard those signatures are to obtain, and only the second number is a security property.

A protocol that advertises immutable contracts can still change what its users interact with, because something decides which build reaches production and which address the interface points at.

That decision usually sits with a pipeline: a repository, a set of merge permissions, and automation holding credentials for the hosting account and sometimes for a deploy key. Whoever can influence what that pipeline ships has an upgrade path over the product, and it is rarely governed like one. Contract upgrades get a timelock and an announcement. A front-end deploy gets a merge.

The question worth asking is whether what reached production is what was reviewed. That is answerable, by matching the deployed artefacts against the audited commit, and it is a different exercise from the audit itself.

In plain terms: a timelock on the contract and a one-click deploy on everything else is a strong lock on one door of a building with several.

A scanner produces a list. A penetration test produces a route, and the difference is what a buyer is paying for.

Three isolated issues of middling severity may be worth scheduling. The same three, where the first yields a credential that reaches the second and the second grants access used by the third, describe a path from the public internet to your signing infrastructure. The individual ratings are unchanged; the conclusion is not.

This is why the deliverable is a narrative. It states where the test started, what each step yielded, how far it reached, and where it was stopped, either by a control that worked or by the agreed limit of the engagement. A reader can then judge the exposure rather than count issues by colour.

In plain terms: severity ratings describe weaknesses one at a time. An attacker does not use them one at a time.

A penetration test is an attack carried out with permission, and the permission is a document rather than an understanding. It names the systems in scope, the accounts and addresses used, the window, the people to contact, and what is excluded.

The exclusions matter as much as the inclusions. Destructive testing, denial of service, and anything touching real customer data are normally out of scope unless a client asks for them specifically and a window is agreed. Testing is usually run against an environment that mirrors production, with production reserved for findings that cannot exist anywhere else.

Scope also protects third parties. Your cloud provider, your custodian and your payment processor are separate parties with their own rules, and testing their systems because yours depends on them is not yours to authorise.

In plain terms: the written scope is what separates a security engagement from an incident, and it is written before anyone starts.

Six questions, answerable without a test.

If somebody held your DNS registrar account for one hour, what could they do, and how quickly would you know?

Which credentials can deploy the front end, where do they live, and when was that list last checked against the people who still work here?

For each signer on the multisig: what machine holds the key, what else runs on it, and who could reach it?

Which cloud roles still exist from a migration or an incident, and what can each of them reach today?

If an administrative account were taken over, what is the worst sequence of actions available, and is any step of it alerted?

What proves that the interface your users loaded this morning was built from the commit you believe it was?