Skip to content
Quantix Security Labs

Blockchain Penetration Testing

Most losses in Web3 do not start in a contract. Penetration testing examines the off-chain systems that build transactions, hold keys, serve users and connect to nodes. All testing is conducted under a written authorisation that defines targets, techniques, timing and contacts, and nothing outside that scope is touched.

Authorised testing of the infrastructure around your contracts.

Dark illustration of concentric security layers around a signing core; authorised probe paths stop at the outer layers while one path winds through gaps towards the core.

Service overview

Between the user and the chain, every layer can change a transaction.

A secure contract can still be drained through a compromised frontend, a leaked deployer key or an exposed node. Testing follows the path a request actually takes.

Most losses in Web3 do not start with a contract bug. They start where a user is told what to sign, where a relayer holds a hot key, where a build pipeline pulls a dependency, or where an RPC endpoint answers a method it should not. A penetration test examines those systems with the mindset of someone trying to change, steal or forge a transaction.

Testing is manual and guided by a threat model agreed at the start. Tooling provides coverage; the findings that matter usually come from understanding how your application builds, signs and relays transactions, and where an attacker could step in between.

Every engagement runs under written rules of engagement. Nothing outside the agreed scope is touched, and either side can stop testing at any time.

Covers
Frontends, APIs, wallets, auth, cloud, RPC, backend services
Excludes by default
Smart contracts, denial of service, social engineering
Starts with
Signed rules of engagement

Applies to

  • Web3 frontends and dApp interfaces
  • Public and internal APIs
  • Wallet integrations and signing flows
  • Authentication and session management
  • Cloud infrastructure and CI/CD pipelines
  • RPC endpoints and node infrastructure
  • Backend services, indexers and relayers
Signing-flow testingAPI and auth testingCloud and CI/CD reviewRPC hardening
  1. 1User and walletLives here:Browser, wallet extension or mobile wallet, hardware signerWe test:Signing prompts, message clarity, phishing resistance of the flow
  2. 2Web3 frontendLives here:dApp bundle, CDN, DNS, third-party scripts, wallet connectorsWe test:Script integrity, supply chain, transaction construction, DNS and CDN takeover paths
  3. 3API and backendLives here:REST and GraphQL APIs, indexers, relayers, admin panelsWe test:Authentication, authorisation, input validation, business logic, rate limiting
  4. 4Signing and keysLives here:Hot wallets, KMS or HSM, multisig tooling, deployer keys, CI secretsWe test:Key exposure, signing policy, separation of duties, secret handling in pipelines
  5. 5RPC and nodesLives here:Self-hosted nodes, RPC providers, mempool access, load balancersWe test:Exposed admin methods, response integrity, provider trust, network exposure
  6. 6ChainLives here:Deployed contracts, bridges, oraclesWe test:Out of pentest scope; covered by smart contract audits and monitoring
A request crosses five trust boundaries before it reaches the chain. Penetration testing covers layers 1 to 5; the contracts themselves are reviewed in a smart contract audit.

Threats addressed

How attackers reach users without touching the contract.

Each threat below maps to a class of real incidents in the ecosystem. The threat model decides which ones a given engagement prioritises.
  • Frontend supply chain

    Interface serving malicious transactions

    A hijacked DNS record, compromised CDN or poisoned build dependency makes a trusted site request approvals to an attacker.

  • Signature phishing

    Users asked to sign more than they see

    Permit, Permit2 and setApprovalForAll requests whose real effect is hidden by the interface or the wallet prompt.

  • Cross-site scripting

    Script injection in a signing context

    Any injected script in a dApp can rewrite calldata between the review screen and the wallet request.

  • Broken access control

    API objects reachable by the wrong account

    Object-level authorisation gaps that expose other users’ orders, withdrawal addresses or KYC data.

  • Signature replay

    Sign-in messages accepted twice

    Sign-In with Ethereum flows that reuse nonces, ignore domain or chain ID, or never expire sessions.

  • Key management

    Hot keys on reachable services

    Relayers, keepers and deployers holding signing keys on hosts that are reachable or over-permissioned.

  • Infrastructure exposure

    RPC methods that should not answer

    Admin, debug or personal namespaces exposed on node endpoints, or a single provider whose responses go unverified.

  • Cloud misconfiguration

    One credential, whole environment

    Broad IAM roles, public storage, leaked CI secrets and missing separation between staging and production.

  • Business logic

    Off-chain logic the contract trusts

    Price feeds, allowlists or merkle roots computed off-chain and published without integrity checks.

Technical capabilities

Eight areas, scoped to what you run.

Not every engagement covers every area. The scope follows your architecture and the threats that matter to it.
  • Web applications

    dApps and dashboards: transaction construction, client-side trust, session handling and the integrity of what users are asked to sign.

  • APIs

    REST and GraphQL endpoints, including authorisation on every object, mass assignment, rate limits and business-logic abuse.

  • Wallet integrations

    Connector libraries, signature requests, chain switching and how the application handles rejected, replayed or modified signatures.

  • Frontend infrastructure

    DNS, CDN, hosting, build pipelines and third-party scripts: the paths by which a trusted interface could serve malicious transactions.

  • Authentication systems

    Sign-In with Ethereum flows, nonce handling, OAuth, admin access, multi-factor enforcement and account recovery.

  • Cloud infrastructure

    IAM policies, network exposure, storage permissions, secrets management and the blast radius of a single compromised credential.

  • RPC endpoints

    Exposed administrative and debug methods, unauthenticated node access, response integrity and dependence on a single provider.

  • Backend services

    Indexers, relayers, keepers and bots: the services that hold keys or submit transactions on behalf of the protocol.

Assessment methodology

Six phases, from signed scope to retest.

Each phase produces a record, so at the end you can see what was tested, how, and with what result.
  1. 01

    Authorisation and rules of engagement

    Written scope, permitted techniques, windows, contacts and stop conditions, signed before any traffic is sent.

  2. 02

    Reconnaissance and threat modelling

    Map the attack surface from the outside in, identify the assets that matter, and agree which attack paths to prioritise.

  3. 03

    Testing

    Manual testing guided by the threat model, supported by tooling. Public frameworks such as the OWASP Web Security Testing Guide inform coverage.

  4. 04

    Validation within agreed limits

    Demonstrate impact only as far as the rules of engagement allow, with evidence captured for every finding.

  5. 05

    Reporting

    Executive summary for decision makers, technical findings with reproduction steps for engineers, ranked by risk.

  6. 06

    Retest

    Remediated findings are retested and their status recorded in the final report.

Nothing is tested without written permission.

All testing is conducted under an agreed, written and authorised scope. Before any traffic is sent, both sides sign rules of engagement that define exactly what may be tested, how, and when. Systems outside that scope are not touched, even if a path to them is found.

What the rules of engagement define

Targets and environments
Hostnames, IP ranges, repositories and accounts in scope, and whether testing runs against production or staging.
Permitted techniques
What is allowed, what is excluded (for example denial of service or social engineering), and what needs a separate approval.
Testing windows
When testing may run, so your operations team can tell our traffic from an attack.
Stop conditions
Named contacts on both sides and the conditions under which testing pauses immediately.
Data handling
How any data encountered is handled, stored and destroyed, and what must never be accessed.
Third-party approvals
Confirmation that hosting, cloud and RPC providers permit testing under their policies.

Tools & techniques

Standard tooling, applied by people who read transactions.

The tools are public and well known. What differs is knowing which request, header or calldata field changes what a user ends up signing.
Tools and techniques used for Blockchain Penetration Testing
Tool or techniqueCategoryWhat it is used for
Burp Suite ProfessionalWeb and API testingIntercepting proxy for manual testing of requests, sessions, authorisation and business logic.
OWASP ZAPWeb and API testingScripted and passive scanning to support manual coverage across large surfaces.
Nuclei and ffufDiscoveryTemplate-based checks and content discovery for exposed paths, panels and misconfiguration.
Playwright with an instrumented providerWallet and signingDrives the dApp through real flows and records every wallet request, so calldata can be compared with what the UI shows.
Foundry cast and anvilTransaction analysisDecodes, simulates and replays transactions built by the frontend or backend against a local fork.
Prowler / ScoutSuiteCloud reviewConfiguration review of IAM, storage, network exposure and logging in AWS, GCP and Azure.
Gitleaks / TruffleHogSecretsSearches repositories, build logs and artefacts for keys, mnemonics and tokens.
SemgrepSource reviewTargeted rules for injection, unsafe deserialisation and signing logic in backend services.
NmapNetworkService discovery on in-scope ranges, including node RPC and peer-to-peer ports.

Ecosystem coverage

Technical depth per execution environment.

Infrastructure differs per chain: node clients, RPC namespaces, wallet standards and signing formats. Testing adapts to the ecosystems your application serves.

Ethereum

Layer 1, proof of stake EVM

Programming languages
SolidityVyperYul
Supported standards
  • ERC-20
  • ERC-721
  • ERC-1155
  • ERC-4626
  • EIP-2612
  • EIP-712
  • ERC-1967
  • ERC-4337
Typical vulnerabilities
  • Reentrancy, including read-only reentrancy
  • Oracle and spot-price manipulation
  • Access control on privileged functions
  • Proxy storage collisions and initializer misuse
  • Signature replay across chains and contracts
  • Front-running and MEV exposure
Assessment methodologies
  • Line-by-line manual review
  • Invariant fuzzing (Foundry, Echidna)
  • Symbolic execution and formal verification
  • Economic attack modelling
Monitoring capabilities
  • Proxy admin and implementation changes
  • Governance proposals and timelock queues
  • Large transfers and treasury outflows
  • Oracle deviation against reference feeds

Ecosystems indicate technical specialisation only, not partnerships or endorsements.

Deliverables

Reports written for the people who decide and the people who fix.

Every finding includes evidence, impact, reproduction steps and a remediation recommendation, ranked by the same severity rubric used across Quantix reports.
  • Executive summary

    Overall risk, the attack paths that matter most and the decisions they call for.
  • Technical findings

    Evidence, impact, likelihood, reproduction steps and a recommended fix for each issue.
  • Attack path narratives

    How individual weaknesses chain together from an external position to a signed transaction.
  • Rules of engagement record

    What was authorised, what was tested, when, and what was out of scope.
  • Hardening recommendations

    Configuration and process changes that reduce exposure beyond individual findings.
  • Retest report

    Final status of every finding after remediation, with retest evidence.

Key assessment areas

  • Transaction construction and signing integrity
  • Frontend supply chain and script integrity
  • Authentication, authorisation and session handling
  • API input validation and business logic
  • Secrets management and key exposure
  • Cloud configuration and network exposure
  • RPC and node hardening

Typical deliverables

  • Rules of engagement and authorisation record
  • Findings with evidence, impact and reproduction steps
  • Risk-ranked remediation plan
  • Retest of remediated findings
  • Executive and technical reports

What a penetration test finding looks like

One finding from the Quantix research assessment of the Larkspur Wallet SDK, as it appears in the technical report.

LW-01HighResolvedBusiness logicCWE-451

Displayed transaction summary is not derived from the signed payload

Larkspur Wallet SDK · packages/sdk-core/src/sign/request.ts:L64–L118

buildSignRequest accepts a transaction and an optional display object. When display is present, its recipient, amount and memo are used for the human-readable summary sent to the wallet; the SignDoc that will actually be signed is serialised separately from the transaction argument.

Nothing checks that the two agree. A page that controls both arguments can show the user "Send 1 ATOM to cosmos1…abc" while the SignDoc contains a MsgSend of the full balance to a different address, or an authz MsgGrant.

Exploit sequence

  1. A compromised dApp page calls buildSignRequest with a MsgGrant giving the attacker authz over the user’s funds.
  2. It passes display = { recipient: <the expected address>, amount: "1 ATOM" }.
  3. The wallet shows the small transfer; the user approves.
  4. The signed MsgGrant lets the attacker execute transfers on the user’s behalf.

Recommendation

Remove the display override. Generate the summary by decoding the exact bytes of the SignDoc that will be signed, render unknown message types explicitly as unrecognised, and add differential tests that decode each request independently.

packages/sdk-core/src/sign/request.tsdiff
-export function buildSignRequest(tx: TxInput, display?: DisplayHints): SignRequest {-  const signDoc = serializeSignDoc(tx)-  const summary = display ? summaryFromHints(display) : summaryFromTx(tx)+export function buildSignRequest(tx: TxInput): SignRequest {+  const signDoc = serializeSignDoc(tx)+  // The summary is always decoded from the bytes that will be signed.+  const summary = summaryFromSignDoc(decodeSignDoc(signDoc.bytes))   return { signDoc, summary } }

FAQ

Questions teams ask before an engagement

Only if you authorise it in writing. Many teams prefer a production-equivalent staging environment for intrusive tests and limited, read-only checks against production. The rules of engagement record the decision.

No. Contracts are reviewed in a smart contract audit, which uses a different method. A penetration test covers the systems around them: how transactions are built, signed, relayed and served to users.

Only when explicitly requested and agreed in writing, with named participants and boundaries. It is excluded by default.

A list of assets and environments in scope, test accounts for each role, a technical contact during testing windows, and confirmation that your hosting and RPC providers allow testing.

Testing is designed to avoid disruption: denial-of-service techniques are excluded unless agreed, intrusive tests are scheduled in agreed windows, and either side can stop testing at any time.

Test the path your users actually take.

Tell us what you run, where it is hosted and which environments are available for testing. We will reply with scoping questions and a draft of the rules of engagement.