Types of Penetration Testing for Crypto and Web3 Firms

Why Smart Contract Audits Are Not Enough

The blockchain security industry has spent the last decade building a robust ecosystem around smart contract auditing, and that investment is justified: on-chain code vulnerabilities have produced some of the largest single theft events in financial history. However, the focus on contract code has created a significant blind spot. Blockchain security audits that examine only smart contract logic leave the majority of the actual attack surface unexamined.

Analysis of major crypto losses consistently shows that a large proportion of significant theft events, estimated at over 75% by value when infrastructure and operational incidents are included alongside code exploits, originate outside the smart contract layer. The Bybit incident demonstrated how sophisticated threat actors can compromise the signing infrastructure and social engineer the humans operating it, bypassing multi-sig controls without ever touching the contract code. Exchange hacks frequently begin with phishing attacks against employees, credential theft from internal systems, or cloud misconfiguration: attack vectors that a contract audit has no capability to assess.

The types of penetration testing that address the full attack surface include network testing (external and internal), web application and API testing, social engineering assessments, cloud and infrastructure reviews, physical penetration tests, and red team exercises. Each targets a different layer of risk. An organisation that commissions only contract audits while leaving these layers untested has performed triage on one organ while leaving the rest of the patient unexamined.

The distinction matters practically because attackers do not respect the boundaries of what an organisation has chosen to test. A threat actor targeting a DeFi protocol's treasury does not need to find a reentrancy vulnerability if they can phish the CFO, compromise the admin dashboard, or manipulate the RPC endpoint used by the signers. The attack surface is the whole system, not just its most technically interesting component.

Network Penetration Testing

Network penetration testing assesses the security of an organisation's network infrastructure by attempting to breach it using the same techniques employed by real attackers. It is divided into two fundamental variants with distinct objectives and assumptions.

External Network Penetration Testing

External network penetration testing examines the organisation's internet-facing infrastructure: servers, APIs, remote access services, VPN gateways, exposed management interfaces, and any other systems reachable from the public internet. The tester begins with no privileged access, simulating an external attacker with knowledge only of what is publicly discoverable. The objective is to determine whether an attacker with no prior foothold can gain access to internal systems, sensitive data, or privileged functions through internet-facing entry points.

For crypto firms, external network testing is relevant across the full range of operational types. Node operators running validator infrastructure, custodians with internet-facing key management systems, exchanges with trading and withdrawal APIs, and DeFi teams with administrative tooling all present significant external attack surfaces. Findings from external network tests frequently include exposed administrative services, default credentials on network devices, unpatched services with known vulnerabilities, and misconfigured firewall rules that allow access to internal resources from the internet.

Internal Network Penetration Testing

Internal network penetration testing assumes the attacker has already achieved a foothold inside the network: a realistic assumption given that phishing attacks, supply chain compromises, and insider threats all result in internal access without requiring a breach of the external perimeter. Internal testing evaluates what an attacker can reach and do once inside: lateral movement across network segments, privilege escalation to administrative accounts, access to signing infrastructure, and extraction of sensitive key material or credentials.

Internal network testing is particularly valuable for crypto firms because the most damaging attacks frequently involve internal access. An attacker who has compromised a single employee's workstation needs to reach treasury signing systems, key management infrastructure, or administrative consoles to achieve their objective. Internal network segmentation, privilege controls, and monitoring effectiveness all determine whether that journey from initial access to high-value target is feasible. Internal testing answers that question before an attacker does.

Web Application and API Penetration Testing

Web application penetration testing assesses the security of internet-accessible applications: the dApp frontend, exchange trading interface, administrative dashboards, and any customer-facing web properties. It tests for vulnerabilities including injection attacks, authentication weaknesses, authorisation bypass, insecure direct object references, and cross-site scripting, among others. For Web3 organisations, web application testing must cover both traditional web security considerations and Web3-specific concerns such as wallet connection interfaces, transaction signing flows, and the handling of RPC calls.

Frontend dApp security is an area that many Web3 organisations underinvest in. A compromised frontend that replaces legitimate wallet connection prompts with malicious ones, modifies transaction parameters before signing, or drains approved token allowances can result in user losses at scale without any vulnerability in the underlying smart contracts. DNS hijacking and CDN compromise have been used to replace legitimate dApp frontends with malicious versions, making the integrity of web delivery infrastructure a material security concern.

API penetration testing focuses on the backend interfaces that serve data to frontends and integrate with third-party systems. APIs in crypto environments handle authentication, authorisation, order submission, withdrawal requests, and in many cases direct interaction with on-chain infrastructure. Common API vulnerabilities include broken authentication allowing account takeover, broken object-level authorisation allowing access to other users' data or functions, excessive data exposure in API responses, and rate limiting failures that enable enumeration or brute-force attacks.

Administrative panels and internal dashboards require particular attention. These interfaces often have access to sensitive operational functions: managing user accounts, processing withdrawals, accessing signing infrastructure, and reviewing transaction histories. Administrative panels are frequently developed under time pressure with less rigorous security review than customer-facing interfaces, and they represent a high-value target because compromising them provides direct access to privileged functions.

Social Engineering and Phishing Testing

The human layer of a crypto firm's security posture is the layer most consistently exploited in high-value attacks. Social engineering testing measures how effectively an organisation's employees resist manipulation attempts designed to elicit sensitive information, install malware, or authorise fraudulent actions. It is not a test of individual employees' intelligence; it is a test of the organisation's training programme, process controls, and the degree to which its culture supports security-conscious behaviour under social pressure.

Crypto firms are premium targets for social engineering attacks for several reasons. The assets under management are large and transfers are irreversible. The industry is small enough that attackers can research individuals in detail through public social media and conference records. Remote-first cultures create dependency on digital communication channels that are easier to spoof than face-to-face interaction. And the technical sophistication of many staff members creates a paradoxical vulnerability: those with deep expertise in cryptography and smart contracts may have received no training on social engineering resistance.

Phishing simulations send realistic but controlled phishing emails to employees, measuring click rates, credential submission rates, and reporting rates. Well-designed simulations replicate the tactics of real threat actors: they use spoofed sender addresses matching trusted organisations, reference current events or internal processes, and create urgency to reduce deliberate decision-making. The results identify which departments and individuals require targeted training and measure the overall effectiveness of existing awareness programmes.

Pretexting and vishing (voice phishing) tests involve testers calling employees while impersonating vendors, regulators, IT support, or senior colleagues, and attempting to extract sensitive information or persuade employees to take actions such as resetting credentials, sharing verification codes, or approving transactions. These tests directly mirror the tactics used in confirmed attack scenarios, including the Lazarus Group operations that preceded the Bybit compromise, where attackers conducted extensive social engineering of operational staff before executing the technical phase of the attack.

Physical access attempts test whether employees admit unknown individuals to secure areas, leave sensitive materials unattended, or comply with requests to bypass physical security controls. For firms with hardware signing infrastructure or physical access to key management systems, physical security testing is a direct test of a material attack vector.

Cloud and Infrastructure Penetration Testing

The majority of Web3 organisations run significant portions of their infrastructure on cloud platforms: AWS, Google Cloud Platform, and Microsoft Azure are the dominant providers. Cloud environments introduce a category of misconfiguration risk that does not exist in traditional on-premise infrastructure, and the rate at which crypto firms are compromised through cloud misconfiguration is significant.

Cloud penetration testing assesses the configuration of cloud environments against known attack paths. Common findings include overly permissive IAM roles and policies allowing access beyond what operational requirements justify, publicly exposed storage buckets containing sensitive configuration files or credential material, unrestricted security group rules allowing network access to internal services, and metadata service exploitation allowing privilege escalation from a compromised compute instance to broader cloud account access.

For crypto firms, cloud key management misconfigurations are a specific and critical concern. Organisations that store private keys or key material within cloud key management services must ensure that access controls are configured correctly, that cross-account access is not inadvertently permitted, and that key usage is logged and monitored. A misconfigured KMS policy that allows key usage by unintended principals can result in key extraction or transaction signing by an attacker who has compromised a cloud identity with broader-than-intended permissions.

Container and Kubernetes security is relevant for firms running microservices architectures. Misconfigured Kubernetes clusters have been used as entry points in a number of significant cloud compromise incidents. Common issues include exposed Kubernetes dashboards, overly permissive service account tokens, container escape vulnerabilities from unpatched runtime versions, and secrets stored in environment variables accessible from within containers.

CI/CD pipeline security is an increasingly prominent attack surface following a series of high-profile supply chain attacks. A compromised build pipeline can inject malicious code into releases, exfiltrate secrets stored in pipeline variables, or alter deployment configurations. For crypto firms, a compromised CI/CD pipeline affecting a dApp frontend or node software represents a significant attack vector that can reach end users at scale.

Physical Penetration Testing

Physical penetration testing assesses whether an attacker can gain unauthorised physical access to sensitive areas or equipment. For many software-first organisations, physical security receives minimal formal attention because the primary attack surface is perceived as digital. For crypto firms with hardware signing infrastructure, cold storage devices, dedicated signing workstations, or data centre presence, physical security is a direct component of the key custody attack surface.

Physical penetration tests evaluate scenarios including tailgating (following an authorised individual through a secured door without independently authenticating), badge cloning (capturing and replicating RFID or NFC access credentials), device theft (removing hardware wallets, signing workstations, or backup media from offices), and visitor impersonation (gaining access to secure areas by misrepresenting identity or purpose). Testers also assess environmental controls: whether sensitive screens are visible from public areas, whether documents containing sensitive information are left unattended, and whether unattended workstations are locked.

For firms with dedicated hardware signing environments, the physical access controls around those environments merit specific assessment. An air-gapped signing workstation that an attacker can reach and attach a USB device to is no longer air-gapped. A hardware wallet stored in an unlocked desk drawer in a shared office is not in secure custody. Physical testing makes these vulnerabilities concrete and measurable rather than theoretical.

Red Team Exercises vs Penetration Testing

The terms penetration testing and red team exercise are frequently used interchangeably, but they describe distinct activities with different objectives, methodologies, and appropriate use cases. Understanding the distinction enables organisations to commission the right activity at the right stage of their security maturity.

A penetration test is a scoped, time-boxed engagement with a defined set of target systems and a clear objective: find as many exploitable vulnerabilities as possible within the defined scope and within the available time. It is comprehensive within its scope and produces a detailed technical report mapping each finding to its risk level and remediation requirement. Penetration tests are appropriate for organisations that want to understand their vulnerability posture across a specific technology domain, validate the effectiveness of recent security improvements, or meet a compliance or contractual requirement. They are the appropriate starting point for organisations that have not previously subjected their infrastructure to formal security testing.

Red team exercises simulate a real adversary pursuing a specific objective: gaining access to treasury wallets, exfiltrating signing keys, achieving the ability to modify transaction parameters, or demonstrating a pathway from initial access to a defined high-value target. Red team exercises operate with fewer constraints than penetration tests and may span multiple domains simultaneously: an exercise might begin with a phishing attack against an employee, proceed to internal network lateral movement, and culminate in an attempt to access signing infrastructure. The objective is not to enumerate all vulnerabilities but to determine whether a specific high-value outcome is achievable by a motivated and capable adversary. Red team exercises are appropriate for organisations with a mature security posture who want to test how their people, processes, and technology perform under realistic adversarial conditions.

A penetration test that only covers smart contract code is like a physical security review that only checks the front door lock. The rest of the attack surface remains entirely unexamined.

The appropriate sequencing for most crypto firms is to conduct penetration testing across key domains before progressing to red team exercises. Commissioning a red team exercise against infrastructure with unpatched critical vulnerabilities produces findings that are less valuable than the same exercise would after fundamental vulnerabilities have been remediated. Red team exercises yield the most value when they test the detection and response capabilities of a security team operating against a mature technical baseline.

Threat-Led Penetration Testing (TLPT) and DORA

Threat-led penetration testing (TLPT) is a structured form of adversary simulation that derives test scenarios from real-world threat intelligence specific to the target organisation. Rather than testing a generic list of attack techniques, TLPT begins with an intelligence phase that identifies the specific threat actors most likely to target the organisation, the tactics, techniques, and procedures they are known to use, and the specific assets or functions that represent their likely objectives. Test scenarios are then designed to replicate these specific threats rather than a generic attack model.

For organisations in scope under the European Union's Digital Operational Resilience Act (DORA), TLPT is a mandatory requirement rather than an optional enhancement to a security programme. DORA applies to financial entities including crypto-asset service providers (CASPs) operating in EU-regulated jurisdictions, and it mandates that these entities conduct threat-led penetration testing under DORA according to a defined framework aligned with TIBER-EU (Threat Intelligence-Based Ethical Red-teaming).

The TIBER-EU framework structures TLPT into three phases: a preparation phase establishing scope and governance, a testing phase comprising the threat intelligence collection and the red team engagement itself, and a closure phase covering reporting, remediation tracking, and lessons-learned documentation. Importantly, the framework requires that the test be coordinated with the competent authority and that the threat intelligence provider and test team be independent of each other and of the target organisation.

Even for firms not directly subject to DORA, TLPT represents the most mature and operationally realistic form of security testing available. Organisations that have conducted and remediated findings from penetration testing across multiple domains, and that want to understand their true resilience against the specific threat actors targeting their sector, should consider TLPT as the next step in their testing programme.

How to Prioritise and Scope Penetration Testing

Organisations approaching penetration testing for the first time face the challenge of determining where to begin. The answer depends on the organisation's current attack surface, its threat model, and the resources available for both testing and remediation.

A maturity-based approach sequences testing activities according to the organisation's security baseline. Organisations with no prior formal security testing should begin with external network penetration testing and web application testing: these cover the internet-facing attack surface that represents the most immediately exploitable exposure. Findings from these tests typically include critical and high-severity issues that should be remediated before investing in more sophisticated testing activity. Commissioning a red team exercise against infrastructure with unpatched critical vulnerabilities in its external perimeter is not an efficient use of resources.

Once the external perimeter has been tested and critical findings remediated, internal network testing, cloud configuration review, and social engineering assessments should follow. These address the secondary attack surface: what is achievable once an attacker has gained an initial foothold. The findings from this phase typically inform structural improvements to network segmentation, privilege management, and employee awareness programmes.

For organisations managing significant assets, the testing programme should include explicit coverage of the signing and custody infrastructure. Penetration testing costs for treasury-focused assessments are a small fraction of the potential losses from a successful attack against that infrastructure. Scope documents for treasury-focused testing should explicitly address the systems used to construct, approve, sign, and broadcast transactions, as well as any administrative interfaces and backup/recovery infrastructure.

The distinction between annual testing and continuous testing models is increasingly relevant as the threat landscape evolves. Annual penetration testing provides a point-in-time assessment that may be significantly out of date by the time the next test occurs, particularly for organisations with active development programmes that introduce new attack surface regularly. Continuous testing models, whether through a retained penetration testing partnership, a bug bounty programme, or automated vulnerability scanning supplemented by periodic manual testing, maintain a more current picture of the organisation's security posture.

A well-constructed penetration test scope document is essential to ensure the engagement delivers its intended value. The scope document should define: which systems, networks, and applications are in scope and explicitly which are out of scope; the testing methodology (black box, where the tester begins with no prior information; grey box, where limited information such as architecture diagrams is provided; or white box, where full access to documentation and source code is provided); the techniques that are permitted and any techniques that are explicitly excluded; point-of-contact procedures for emergency communication during the test; emergency stop criteria defining conditions under which testing should be paused; and reporting requirements including format, audience, and timeline.

For crypto-specific engagements, the scope document should explicitly address wallet infrastructure and signing systems. Ambiguity about whether cold storage signing workstations are in scope, or whether testing should include attempts to access key backup media, creates gaps in coverage that may leave the most critical infrastructure unexamined. The scope document is the appropriate place to resolve these questions before testing begins, not during the engagement itself.