From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing

For crypto institutions and service providers—including cryptocurrency exchanges, payment companies, digital-asset custodians, and custodial and non-custodial wallet providers—blockchain penetration testing is, for those in scope, not an optional precaution. Where a compromise can reach signing or funds, or applicable rules call for adversarial validation, it is a necessary layer of assurance. The case rests on two legs: risk provenance beyond contract code and regulatory requirements or expectations for adversarial validation.

Institutional exposure extends beyond contract bugs to signing, custody, keys, people, supply chains, and infrastructure [1]. As such, this surface is not fully covered by the familiar web3 security solutions—code-level audit and transaction-level monitoring—or by traditional penetration testing alone. This applies to any institution where a person, vendor, interface, or application can influence what gets signed, approved, credited, or moved—including where custody is outsourced. In parallel, regulators in several markets impose requirements, conditional obligations, or supervisory expectations with different scopes, cadences, and independence rules.

This article opens our blockchain-penetration-testing series. Throughout the series, blockchain penetration testing and web3 penetration testing refer to the same discipline: we use the former as the primary term and the latter as its common industry synonym. It presents the high-level, whole-picture case for necessity; later articles define the discipline, its operating boundaries, and the institutional attack surface in detail.

Part 1: Where the risk comes from

1.1 Risk beyond the smart contract

Smart-contract vulnerabilities remain important, but many of the largest recent losses have originated elsewhere, particularly in keys, signing systems, and operational infrastructure. In 2024, attackers stole roughly $305 million from DMM Bitcoin by compromising a wallet-software provider and manipulating a legitimate transaction request [2]. In 2025, Bybit lost approximately $1.5 billion after a supply-chain compromise manipulated its signing interface [3], while BtcTurk’s hot-wallet loss similarly traced to compromised private keys [4]. Our research points in the same direction: among incidents involving losses above $100,000 that we tracked in 2026, off-contract failures represented about one in eight incidents but more than three-quarters of total losses. As of August 2026, seven of the ten largest hacks on rekt.news’s public leaderboard, excluding fraud and other non-hack entries, were off-contract compromises, accounting for roughly 70% by both incident count and dollar value [5].

Wallets and custody systems make the pattern concrete, and wallet security has stayed an especially active area of incidents in recent years. Our investigation groups failures into key handling, the transaction-signing pipeline, supply chain and dependencies, sensitive-data exposure, and cryptographic implementation.

* Coldcard's ~$90M is the verified on-chain floor (about 1,405 BTC); private estimates run as high as ~$130M.

What ties these to penetration testing is not simply that they fall outside the contract, but that whether they can be exploited often depends on how the deployed pieces—identities, dependencies, signing controls, approvals, and fund logic—line up into a path an attacker can walk end to end—from an entry point to the funds.

1.2 Code-level audit and transaction-level monitoring: essential but limited

Each of the existing well-known web3 security solutions works at a specific level. Code-level audit (code audit) examines code—contract, wallet, or service logic. Transaction-level monitoring (monitoring) examines transactions as they reach the chain; Phalcon [11], for example, detects, alerts on, and blocks malicious activity at runtime.

These solutions are useful but limited when they come to the money-handling chain of crypto institutions—the connected identities, cloud infrastructure, signing workflows, approval chains, wallets, vendors, and operator consoles through which value moves from an entry point to a fund-moving action. An attacker's reachable path is a route across that chain: it can run from a web, dApp, mobile, API, cloud, or identity entry point through signing, approval, and fund logic, and can pass through how a contract behaves in that live context, to the fund-moving action at the other end. Reviewing the code does not assemble that path, and watching transactions does not anticipate it. Even used together, the two can still leave a composition gap: an audit shows the code was sound as written, not that the deployed identities, approvals, and signers still enforce it; and monitoring can wave through a transfer that is technically valid yet was never what the operator intended. What closes that gap is independent adversarial validation that the controls compose correctly in the running system.

Blockchain penetration testing exercises the assembled, running system to discover and demonstrate whether such a path can reach the funds before an incident exposes it. The Bybit pattern shows the shape of the problem: a compromised signing interface turned the operators' own approval into a transfer they never intended—an outcome the contract, an audit of it, and transaction monitoring could each read as legitimate. Blockchain penetration testing targets that composition directly: taking the position of a compromised vendor, operator, or interface, it tests whether such a foothold can turn a valid-looking approval into an unauthorized fund movement, and which deployed controls—identities, approval steps, signing checks—actually stop it. Contract code-level assurance remains the audit's job; blockchain penetration testing engages a deployed contract only through its live behavior where that forms part of an institution-level route to funds—complementary scopes distinguished by emphasis, not a hard boundary. Part 2 defines what blockchain penetration testing validates and where its scope ends.

1.3 Traditional penetration testing: useful but not enough

Traditional penetration testing remains valuable across cloud, web and API, identity, and privileged-access surfaces. Its limitation is scope and domain context: a conventional engagement may not bring crypto's business semantics or coupled security and compliance model.

In crypto, a signature can authorize irreversible value movement; withdrawal approval is a fund-control decision, not merely a form submission. Deposit crediting, balance accounting, and internal transfers are money logic. Addresses and transactions can also carry sanctions or source-of-funds meaning. A tester might find an authentication bypass yet miss how it combines with a signing-display mismatch, weak approval policy, or rounding flaw into a path to funds.

Blockchain penetration testing applies established adversarial techniques to traditional surfaces plus web3-specific signing, approval, fund-logic, and contract-dynamic surfaces across the running system. Its differentiator is specialist web3 security judgment, not new tooling: testers interpret custody, transaction intent, fund flows, and compliance controls as an attacker would. The difference is one of objective: a conventional test typically proves IT-control impact—an admin session taken over, a server reached—while a blockchain test treats the movement of value as the end condition. It keeps going: it alters the recipient or amount inside a legitimate signing request and checks whether what the approver sees, the approval policy, and the funds that actually move still line up.

To sum up, this is complementary assurance, not a static-versus-dynamic wall. Code-level audits, transaction-level monitoring, and traditional penetration tests remain necessary. Blockchain penetration testing connects them by validating reachable paths; it does not replace them, guarantee breach discovery, or guarantee prevention.

Part 2: What regulators require

Requirements vary by jurisdiction, creating a spectrum of licensing, ongoing, and regulator-triggered obligations for specified entities and systems.

These examples are illustrative, not legal advice. Institutions should confirm their status, exemptions, systems, and obligations with counsel.

• United States, New York: explicit requirement with limited exemption. Covered entities under NYDFS 23 NYCRR Part 500 [12], including DFS-licensed virtual-currency businesses, must test information systems from inside and outside their boundaries, based on risk assessment, at least annually. A qualified internal or external party may test. Qualifying small entities receive a limited exemption from this testing provision but remain subject to Part 500's other applicable provisions.

• Dubai: annual and change-triggered requirement. Licensed VASPs must conduct vulnerability assessment and penetration testing at least annually and before introducing new systems, applications, or products [13], using a qualified, independent third party. Smart-contract audit applies where relevant to the VASP's business and activities. Threat-led penetration testing has no universal cadence: VARA may require it when necessary and proportionate based on risk.

• Hong Kong: licence-condition requirement for deemed applicants. Deemed-to-be-licensed virtual asset trading platform applicants must complete penetration testing and vulnerability assessment with satisfactory results before restricted operation [14]. Separate guidance applies to new-corporation applicants. An independent third party must cover specified infrastructure and applications across application and network layers. Before restricted operation, management must complete all major and critical rectification steps for medium-to-high-risk findings.

• European Union: proportional framework; TLPT conditional on identification. DORA covers financial entities, including crypto-asset service providers [15]. It requires appropriate testing—not specifically penetration testing—at least annually for systems supporting critical or important functions. Penetration testing is one method selected according to risk and proportionality. Threat-led penetration testing applies only to entities identified by competent authorities, runs on live production systems, and is generally required at least every three years; authorities may adjust that frequency on risk grounds. DORA also imposes tester-independence conditions. Microenterprises are outside the testing-programme requirement.

• Singapore: non-binding supervisory expectation. MAS Technology Risk Management Guidelines say financial institutions should conduct penetration testing and expect Internet-accessible systems to be tested at least annually or after major changes or updates [16]. This is non-binding supervisory guidance and does not require an independent third party. The binding, bank-scoped Cyber Hygiene Notice does not specify penetration testing. The binding payment or digital-payment-token notice is outside this article's scope.

Taken together, these regimes require or expect penetration testing—not a branded "web3" category. The web3-specialist version follows from the systems in scope: where they authorize, sign, custody, or account for crypto value, testing them properly calls for the same signing- and fund-flow fluency Part 1 describes.

The conclusion is precise: a substantial set of licensed entities in specific jurisdictions already face a requirement or supervisory expectation—not the same mandate in every market. The distinctions determine scope, cadence, tester independence, remediation, evidence, and whether testing supports licensing, ongoing compliance, or a regulator-triggered exercise.

Conclusion: The two legs converge

Risk provenance and regulatory requirements or expectations point to the same conclusion: for in-scope institutions, blockchain penetration testing is a necessary assurance layer. It validates reachable paths across access, approval, signing, and funds while complementing existing controls. It cannot guarantee prevention, prove it would have stopped any specific past incident, or find every exploitable path. The objective is continuing assurance across launch, operation, detection, response, and regulatory evidence—not a one-off report.

Continue with the series:

• Part 2: What Is Blockchain Penetration Testing? Definitions and Boundaries

• Part 3: Rules of Engagement and Production Safety for Institutional Blockchain Penetration Testing

• Part 4: Web3 Attack Surfaces: A Penetration Testing Overview

Also in this series, publishing soon:

• Part 5: Authorization and Signing Security: Web, dApps, and Mobile
• Part 6: Cloud and CI/CD Security: Automated Operations Attack Surfaces
• Part 7: Treasury Control-Plane Security: Signing and Withdrawal Approvals
• Part 8: Exchange Ledger Security: Theft Paths and Data-Plane Logic

BlockSec helps institutions place this layer precisely: map the assets, fund flows, trust boundaries, and existing assurance; confirm the obligations counsel says apply; then define the test objective, scope, access, production safeguards, remediation evidence, and retest plan. To identify your assurance gap, talk to our blockchain penetration testing team; engagement scope and pricing are available upon request. Start where the funds move.

References

Numbered in order of first appearance.

1. BlockSec, Crypto Payment Security Playbook.
2. U.S. Federal Bureau of Investigation, DC3, and Japan National Police Agency, Identification of North Korean Cyber Actors (TraderTraitor) Responsible for Theft of $308 Million from Bitcoin.DMM.com (December 2024).
3. BlockSec, Bybit $1.5B Hack: In-Depth Analysis of the Malicious Safe{Wallet} Upgrade Attack.
4. rekt.news, BtcTurk — Rekt.
5. rekt.news, Leaderboard.
6. SwissBorg, SwissBorg Security Update: Kiln Breach.
7. BlockSec, TrustWallet Incident: A Stolen API Key Turns the Official Update Channel into a Backdoor.
8. Slope, Slope Wallet Sentry Vulnerability: Digital Forensics and Incident Response Report.
9. BlockSec, Our Short Analysis of the Profanity Tool Vulnerability.
10. BlockSec, Coldcard Entropy Failure and Seed Recovery.
11. BlockSec, Phalcon Security.
12. New York State Department of Financial Services, 23 NYCRR Part 500 — Cybersecurity Requirements for Financial Services Companies.
13. Dubai Virtual Assets Regulatory Authority, Technology and Information Rulebook, Part I, Section E.
14. Hong Kong Securities and Futures Commission, Circular 24EC65 (18 December 2024, PDF).
15. European Union, Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA), Articles 24–27.
16. Monetary Authority of Singapore, Technology Risk Management Guidelines (January 2021), Sections 2 and 13; Notice FSM-N06: Notice on Cyber Hygiene (2024).