Dos Incidentes à Regulação: Por Que Instituições Cripto Precisam de Testes de Penetração em Blockchain

Para instituições de cripto e provedores de serviços—incluindo exchanges de criptomoedas, empresas de pagamento, custodiantes de ativos digitais e provedores de carteiras custodiais e não-custodiais—o teste de penetração em blockchain é, para aqueles dentro do escopo, não uma precaução opcional. Quando um comprometimento pode alcançar assinaturas ou fundos, ou quando as regras aplicáveis exigem validação adversarial, trata-se de uma camada necessária de garantia. O argumento se sustenta em duas frentes: a origem do risco além do código do contrato e os requisitos regulatórios ou expectativas de validação adversarial.

A exposição institucional se estende além dos bugs de contrato, alcançando assinatura, custódia, chaves, pessoas, cadeias de suprimentos e infraestrutura [1]. Sendo assim, essa superfície não é totalmente coberta pelas soluções de segurança web3 já conhecidas—auditoria em nível de código e monitoramento em nível de transação—nem apenas pelo teste de penetração tradicional. Isso se aplica a qualquer instituição em que uma pessoa, fornecedor, interface ou aplicação possa influenciar o que é assinado, aprovado, creditado ou movimentado—incluindo os casos em que a custódia é terceirizada. Paralelamente, reguladores em diversos mercados impõem requisitos, obrigações condicionais ou expectativas de supervisão com escopos, cadências e regras de independência diferentes.

Este artigo abre nossa série sobre testes de penetração em web3. Ao longo da série, teste de penetração em blockchain e teste de penetração em web3 se referem à mesma disciplina: usamos o primeiro como termo principal e o segundo como seu sinônimo comum no setor. O artigo apresenta o argumento geral e abrangente para a necessidade desse tipo de teste; artigos posteriores definem a disciplina, seus limites operacionais e a superfície de ataque institucional em detalhes.

Parte 1: De onde vem o risco

1.1 Risco além do contrato inteligente

As vulnerabilidades de contratos inteligentes continuam importantes, mas muitas das maiores perdas recentes se originaram em outros lugares, particularmente em chaves, sistemas de assinatura e infraestrutura operacional. Em 2024, atacantes roubaram aproximadamente $305 milhões da DMM Bitcoin ao comprometer um provedor de software de carteira e manipular uma solicitação de transação legítima [2]. Em 2025, a Bybit perdeu aproximadamente $1,5 bilhão após um comprometimento na cadeia de suprimentos manipular sua interface de assinatura [3], enquanto a perda de hot wallet da BtcTurk também foi rastreada até chaves privadas comprometidas [4]. Nossa pesquisa aponta na mesma direção: entre os incidentes com perdas acima de $100.000 que rastreamos em 2026, as falhas fora do contrato representaram cerca de um em cada oito incidentes, mas mais de três quartos do total das perdas. Em agosto de 2026, sete dos dez maiores hacks no ranking público do rekt.news, excluindo fraudes e outras entradas que não são hacks, foram comprometimentos fora do contrato, correspondendo a aproximadamente 70% tanto em número de incidentes quanto em valor em dólares [5].

Carteiras e sistemas de custódia tornam esse padrão concreto, e a segurança de carteiras permanece uma área especialmente ativa de incidentes nos últimos anos. Nossa investigação agrupa as falhas em manuseio de chaves, o pipeline de assinatura de transações, cadeia de suprimentos e dependências, exposição de dados sensíveis e implementação criptográfica.

* Os ~$90M da Coldcard são o piso verificado on-chain (cerca de 1.405 BTC); estimativas privadas chegam a até ~$130M.

O que conecta esses casos ao teste de penetração não é simplesmente o fato de estarem fora do contrato, mas sim que a possibilidade de exploração muitas vezes depende de como as peças implantadas—identidades, dependências, controles de assinatura, aprovações e lógica de fundos—se alinham em um caminho que um atacante consegue percorrer de ponta a ponta—de um ponto de entrada até os fundos.

1.2 Auditoria em nível de código e monitoramento em nível de transação: essenciais, mas limitados

Cada uma das soluções de segurança web3 já conhecidas atua em um nível específico. A auditoria em nível de código examina o código (auditoria de código) examina o código—do contrato, da carteira ou da lógica de serviço. O monitoramento em nível de transação (monitoramento) examina as transações à medida que chegam à cadeia; a Phalcon Security [11], por exemplo, detecta, alerta e bloqueia atividades maliciosas em tempo de execução.

Essas soluções são úteis, mas limitadas quando se trata da cadeia de movimentação de dinheiro das instituições de cripto—as identidades conectadas, a infraestrutura em nuvem, os fluxos de trabalho de assinatura, as cadeias de aprovação, as carteiras, os fornecedores e os consoles de operador pelos quais o valor se move de um ponto de entrada até uma ação de movimentação de fundos. O caminho alcançável por um atacante é uma rota através dessa cadeia: ele pode partir de um ponto de entrada web, dApp, mobile, API, nuvem ou identidade, passando por assinatura, aprovação e lógica de fundos, podendo passar por como um contrato se comporta nesse contexto ao vivo, até a ação de movimentação de fundos na outra ponta. Revisar o código não monta esse caminho, e observar transações não o antecipa. Mesmo usadas em conjunto, as duas abordagens ainda podem deixar uma lacuna de composição: uma auditoria mostra que o código estava correto como escrito, não que as identidades, aprovações e assinantes implantados ainda o aplicam; e o monitoramento pode deixar passar uma transferência que é tecnicamente válida, mas que nunca foi o que o operador pretendia. O que fecha essa lacuna é a validação adversarial independente de que os controles se compõem corretamente no sistema em funcionamento.

O teste de penetração em blockchain exercita o sistema montado e em funcionamento para descobrir e demonstrar se tal caminho pode alcançar os fundos antes que um incidente o exponha. O padrão da Bybit mostra a forma do problema: uma interface de assinatura comprometida transformou a própria aprovação dos operadores em uma transferência que eles nunca pretenderam—um resultado que o contrato, uma auditoria dele e o monitoramento de transações poderiam cada um interpretar como legítimo. O teste de penetração em web3 tem como alvo diretamente essa composição: assumindo a posição de um fornecedor, operador ou interface comprometidos, ele testa se tal ponto de apoio pode transformar uma aprovação com aparência válida em uma movimentação de fundos não autorizada, e quais controles implantados—identidades, etapas de aprovação, verificações de assinatura—realmente a impedem. A garantia em nível de código do contrato continua sendo trabalho da auditoria; o teste de penetração em web3 interage com um contrato implantado apenas por meio de seu comportamento ao vivo, quando isso faz parte de uma rota em nível institucional até os fundos—escopos complementares distinguidos por ênfase, não por uma fronteira rígida. A Parte 2 define o que o teste de penetração em web3 valida e onde seu escopo termina.

1.3 Teste de penetração tradicional: útil, mas insuficiente

O teste de penetração tradicional continua valioso em superfícies de nuvem, web e API, identidade e acesso privilegiado. Sua limitação está no escopo e no contexto do domínio: um engajamento convencional pode não trazer a semântica de negócio própria das criptomoedas ou o modelo acoplado de segurança e conformidade.

No mundo cripto, uma assinatura pode autorizar a movimentação irreversível de valor; a aprovação de saque é uma decisão de controle de fundos, não apenas o envio de um formulário. O crédito de depósitos, a contabilização de saldos e as transferências internas são lógica financeira. Endereços e transações também podem carregar significado relacionado a sanções ou à origem dos fundos. Um testador pode encontrar uma falha de bypass de autenticação, mas não perceber como ela se combina com uma inconsistência na exibição de assinatura, uma política de aprovação fraca ou uma falha de arredondamento, formando um caminho até os fundos.

O teste de penetração em blockchain aplica técnicas adversariais consolidadas às superfícies tradicionais, além das superfícies específicas do web3, como assinatura, aprovação, lógica de fundos e dinâmica de contratos, em todo o sistema em funcionamento. Seu diferencial é o julgamento especializado de segurança em web3, não novas ferramentas: os testadores interpretam custódia, intenção da transação, fluxos de fundos e controles de conformidade como um atacante o faria. A diferença está no objetivo: um teste convencional normalmente comprova impacto em controles de TI—uma sessão de administrador assumida, um servidor alcançado—enquanto um teste web3 trata a movimentação de valor como a condição final. Ele vai além: altera o destinatário ou o valor dentro de uma solicitação de assinatura legítima e verifica se o que o aprovador vê, a política de aprovação e os fundos que efetivamente se movem ainda estão alinhados.

Em resumo, trata-se de uma garantia complementar, não de uma barreira estático-versus-dinâmico. Auditorias em nível de código, monitoramento em nível de transação e testes de penetração tradicionais continuam necessários. O teste de penetração em web3 os conecta ao validar caminhos alcançáveis; ele não os substitui, nem garante a descoberta de violações, nem garante a prevenção.

Parte 2: O que os reguladores exigem

Os requisitos variam de acordo com a jurisdição, criando um espectro de obrigações de licenciamento, contínuas e acionadas por reguladores, para entidades e sistemas específicos.

Esses exemplos são ilustrativos, não constituem aconselhamento jurídico. As instituições devem confirmar seu status, isenções, sistemas e obrigações junto a assessoria jurídica.

• Estados Unidos, Nova York: requisito explícito com isenção limitada. As entidades cobertas pelo NYDFS 23 NYCRR Part 500 [12], incluindo empresas de moeda virtual licenciadas pelo DFS, devem testar seus sistemas de informação a partir de dentro e de fora de seus limites, com base em avaliação de risco, pelo menos anualmente. Uma parte interna ou externa qualificada pode realizar o teste. Pequenas entidades qualificadas recebem uma isenção limitada dessa disposição de teste, mas permanecem sujeitas às demais disposições aplicáveis da Part 500.

• Dubai: requisito anual e acionado por mudanças. Os VASPs licenciados devem realizar avaliação de vulnerabilidades e teste de penetração pelo menos anualmente e antes de introduzir novos sistemas, aplicações ou produtos [13], usando um terceiro qualificado e independente. A auditoria de contrato inteligente se aplica quando relevante para os negócios e atividades do VASP. O teste de penetração orientado por ameaças (threat-led penetration testing) não possui uma cadência universal: a VARA pode exigi-lo quando necessário e proporcional, com base no risco.

• Hong Kong: requisito de condição de licença para candidatos considerados licenciados. Os candidatos a plataformas de negociação de ativos virtuais consideradas licenciadas (deemed-to-be-licensed) devem concluir o teste de penetração e a avaliação de vulnerabilidades com resultados satisfatórios antes da operação restrita [14]. Orientações separadas se aplicam a candidatos de novas empresas (new-corporation applicants). Um terceiro independente deve cobrir a infraestrutura e as aplicações especificadas, tanto na camada de aplicação quanto na de rede. Antes da operação restrita, a gestão deve concluir todas as etapas de retificação de constatações de risco médio a alto, tanto as principais quanto as críticas.

• União Europeia: estrutura proporcional; TLPT condicionado à identificação. A DORA abrange entidades financeiras, incluindo provedores de serviços de ativos criptográficos [15]. Ela exige testes apropriados—não especificamente teste de penetração—pelo menos anualmente para sistemas que sustentam funções críticas ou importantes. O teste de penetração é um método selecionado de acordo com o risco e a proporcionalidade. O teste de penetração orientado por ameaças (threat-led penetration testing) se aplica apenas a entidades identificadas pelas autoridades competentes, é realizado em sistemas de produção ao vivo e, em geral, é exigido pelo menos a cada três anos; as autoridades podem ajustar essa frequência com base em critérios de risco. A DORA também impõe condições de independência para os testadores. As microempresas estão fora do requisito de programa de testes.

• Cingapura: expectativa de supervisão não vinculante. As MAS Technology Risk Management Guidelines afirmam que as instituições financeiras devem realizar testes de penetração e esperam que sistemas acessíveis pela internet sejam testados pelo menos anualmente ou após mudanças ou atualizações significativas [16]. Trata-se de orientação de supervisão não vinculante, que não exige um terceiro independente. O Cyber Hygiene Notice, vinculante e restrito a bancos, não especifica o teste de penetração. O aviso vinculante sobre pagamentos ou tokens de pagamento digital está fora do escopo deste artigo.

Em conjunto, esses regimes exigem ou esperam o teste de penetração—não uma categoria específica denominada "web3". A versão especializada em web3 decorre dos sistemas dentro do escopo: quando eles autorizam, assinam, custodiam ou contabilizam valor em cripto, testá-los adequadamente requer a mesma fluência em assinatura e fluxo de fundos descrita na Parte 1.

A conclusão é precisa: um conjunto substancial de entidades licenciadas em jurisdições específicas já enfrenta um requisito ou expectativa de supervisão—não o mesmo mandato em todos os mercados. As distinções determinam o escopo, a cadência, a independência do testador, a remediação, as evidências e se o teste sustenta o licenciamento, a conformidade contínua ou um exercício acionado pelo regulador.

Conclusão: As duas frentes convergem

A origem do risco e os requisitos ou expectativas regulatórias apontam para a mesma conclusão: para as instituições dentro do escopo, o teste de penetração em web3 é uma camada de garantia necessária. Ele valida caminhos alcançáveis em acesso, aprovação, assinatura e fundos, complementando os controles existentes. Ele não pode garantir a prevenção, provar que teria impedido qualquer incidente específico do passado, ou encontrar todos os caminhos exploráveis. O objetivo é a garantia contínua ao longo do lançamento, da operação, da detecção, da resposta e das evidências regulatórias—não um relatório pontual.

Continue com a série:

• Parte 2: O Que É Teste de Penetração em Web3? Definições e Limites

• Parte 3: Regras de Engajamento e Segurança em Produção para Testes de Penetração em Web3 Institucionais

• Parte 4: Superfícies de Ataque Web3: Uma Visão Geral do Teste de Penetração

Também nesta série, publicação em breve:

• Parte 5: Segurança de Autorização e Assinatura: Web, dApps e Mobile
• Parte 6: Segurança de Nuvem e CI/CD: Superfícies de Ataque em Operações Automatizadas
• Parte 7: Segurança do Plano de Controle de Tesouraria: Assinatura e Aprovações de Saque
• Parte 8: Segurança de Livro-Razão de Exchanges: Caminhos de Roubo e Lógica do Plano de Dados

A BlockSec ajuda instituições a posicionar essa camada com precisão: mapeia os ativos, os fluxos de fundos, as fronteiras de confiança e a garantia já existente; confirma as obrigações que a assessoria jurídica indica como aplicáveis; e então define o objetivo do teste, o escopo, o acesso, as salvaguardas de produção, as evidências de remediação e o plano de reteste. Para identificar sua lacuna de garantia, [fale com nossa equipe de teste de penetração em blockchain](https://blocksec.com/blockchain-penetration-testing) ; o escopo do engajamento e os preços estão disponíveis mediante solicitação. Comece por onde os fundos se movem.

Referências

Numeradas em ordem de primeira aparição.

1. BlockSec, Crypto Payment Security Playbook. https://blocksec.com/crypto-payment-playbook

2. U.S. Federal Bureau of Investigation, DC3, e Japan National Police Agency, Identification of North Korean Cyber Actors (TraderTraitor) Responsible for Theft of $308 Million from Bitcoin.DMM.com (dezembro de 2024). https://www.fbi.gov/news/press-releases/fbi-dc3-and-npa-identification-of-north-korean-cyber-actors-tracked-as-tradertraitor-responsible-for-theft-of-308-million-from-bitcoindmmcom

3. BlockSec, Bybit $1.5B Hack: In-Depth Analysis of the Malicious Safe{Wallet} Upgrade Attack. https://blocksec.com/blog/bybit-1-5-b-hack-in-depth-analysis-of-the-malicious-safe-wallet-upgrade-attack

4. rekt.news, BtcTurk — Rekt. https://rekt.news/btcturk-rekt

5. rekt.news, Leaderboard. https://rekt.news/leaderboard

6. SwissBorg, SwissBorg Security Update: Kiln Breach. https://swissborg.com/blog/swissborg-security-update-kiln-breach

7. BlockSec, TrustWallet Incident: A Stolen API Key Turns the Official Update Channel into a Backdoor. https://blocksec.com/blog/trust-wallet-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. https://slope-finance.medium.com/slope-wallet-sentry-vulnerability-digital-forensics-and-incident-response-report-d7a5904e5a39

9. BlockSec, Our Short Analysis of the Profanity Tool Vulnerability. https://blocksec.com/blog/our-short-analysis-of-the-profanity-tool-vulnerability

10. BlockSec, Coldcard Entropy Failure and Seed Recovery (exposição de chave privada). https://blocksec.com/blog/coldcard-entropy-failure-seed-recovery

11. BlockSec, Phalcon Security (monitoramento e bloqueio de transações). https://blocksec.com/phalcon/security

12. New York State Department of Financial Services, 23 NYCRR Part 500. https://www.dfs.ny.gov/industry_guidance/cybersecurity

13. Dubai Virtual Assets Regulatory Authority, Technology and Information Rulebook, Part I, Section E. https://rulebooks.vara.ae/rulebook/e-testing-and-audit

14. Hong Kong Securities and Futures Commission, Circular 24EC65, 18 de dezembro de 2024. https://apps.sfc.hk/edistributionWeb/api/circular/openFile?lang=EN&refNo=24EC65

15. União Europeia, Regulation (EU) 2022/2554 (Digital Operational Resilience Act), Artigos 24-27. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng

16. Monetary Authority of Singapore, Technology Risk Management Guidelines (janeiro de 2021), Seções 2 e 13, https://www.mas.gov.sg/regulation/guidelines/technology-risk-management-guidelines; _Notice FSM-N06, Notice on Cyber Hygiene_ (2024), https://www.mas.gov.sg/regulation/notices/notice-fsm-n06