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

Para instituições e provedores de serviços de criptoativos — 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. Onde um comprometimento pode alcançar a assinatura ou os fundos, ou onde regras aplicáveis exigem validação adversarial, trata-se de uma camada necessária de garantia. O argumento se sustenta em dois pilares: a origem do risco além do código do contrato e os requisitos ou expectativas regulatórias para validação adversarial.

A exposição institucional se estende além dos bugs de contrato para assinatura, custódia, chaves, pessoas, cadeias de suprimentos e infraestrutura [1]. Como tal, essa superfície não é totalmente coberta pelas soluções familiares de segurança web3 — auditoria em nível de código e monitoramento em nível de transação — nem pelo teste de penetração tradicional isoladamente. 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 casos em que a custódia é terceirizada. Paralelamente, reguladores em vários mercados impõem requisitos, obrigações condicionais ou expectativas de supervisão com diferentes escopos, periodicidades e regras de independência.

Este artigo abre nossa série sobre teste de penetração em blockchain. Ao longo da série, teste de penetração em blockchain e teste de penetração 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 de alto nível para a necessidade desse tipo de teste; artigos posteriores definem a disciplina, seus limites operacionais e a superfície de ataque institucional em detalhe.

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 atribuída a chaves privadas comprometidas [4]. Nossa pesquisa aponta na mesma direção: entre os incidentes envolvendo perdas acima de $100.000 que rastreamos em 2026, falhas fora do contrato representaram cerca de um em cada oito incidentes, mas mais de três quartos das perdas totais. Em agosto de 2026, sete dos dez maiores hacks no leaderboard público da rekt.news, excluindo fraudes e outras entradas que não são hacks, foram comprometimentos fora do contrato, respondendo por aproximadamente 70% tanto em número de incidentes quanto em valor em dólares [5].

Carteiras e sistemas de custódia tornam o 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, pipeline de assinatura de transações, cadeia de suprimentos e dependências, exposição de dados sensíveis e implementação criptográfica.

* O piso verificado on-chain da Coldcard é de ~$90M (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 que se eles podem ser explorados frequentemente depende de como as peças implantadas — identidades, dependências, controles de assinatura, aprovações e a lógica de fundos — se alinham em um caminho que um atacante pode 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 (code audit) examina o código — a lógica do contrato, da carteira ou do serviço. O monitoramento em nível de transação (monitoring) 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 fundos das instituições de criptoativos — as identidades conectadas, a infraestrutura em nuvem, os fluxos de assinatura, as cadeias de aprovação, as carteiras, os fornecedores e os consoles de operadores por meio dos quais o valor se movimenta 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 pela assinatura, aprovação e lógica de fundos, e pode passar por como um contrato se comporta nesse contexto ativo, até a ação de movimentação de fundos do outro lado. Revisar o código não monta esse caminho, e observar as 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 liberar 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 execução.

O teste de penetração em blockchain exercita o sistema montado e em execução para descobrir e demonstrar se tal caminho pode alcançar os fundos antes que um incidente o exponha. O padrão do caso 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 blockchain visa essa composição diretamente: assumindo a posição de um fornecedor, operador ou interface comprometidos, ele testa se tal ponto de apoio pode transformar uma aprovação aparentemente válida em uma movimentação não autorizada de fundos, 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 permanece tarefa da auditoria; o teste de penetração em blockchain se envolve com um contrato implantado apenas por meio de seu comportamento ativo onde 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 blockchain valida e onde termina seu escopo.

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

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 nem 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 meramente 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 de fundos. Um testador pode encontrar uma falha de autenticação, mas não perceber como ela se combina com uma incompatibilidade 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 tanto às superfícies tradicionais quanto às superfícies específicas do web3 de assinatura, aprovação, lógica de fundos e dinâmica de contratos em todo o sistema em execução. Seu diferencial é o julgamento especializado em segurança web3, não novas ferramentas: os testadores interpretam custódia, intenção de transação, fluxos de fundos e controles de conformidade como um atacante o faria. A diferença é de objetivo: um teste convencional tipicamente comprova o impacto sobre controles de TI — uma sessão de administrador comprometida, um servidor alcançado — enquanto um teste blockchain 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 entre estático e 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 blockchain os conecta ao validar caminhos alcançáveis; ele não os substitui, não 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 desencadeadas por reguladores para entidades e sistemas especificados.

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

• Estados Unidos, Nova York: requisito explícito com isenção limitada. Entidades cobertas pela NYDFS 23 NYCRR Parte 500 [12], incluindo empresas de moeda virtual licenciadas pela DFS, devem testar os 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 Parte 500.

• Dubai: requisito anual e desencadeado 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 não possui uma periodicidade 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. Candidatos a plataforma de negociação de ativos virtuais considerados licenciados 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. Um terceiro independente deve cobrir a infraestrutura e as aplicações especificadas nas camadas de aplicação e de rede. Antes da operação restrita, a administração deve concluir todas as principais etapas de retificação para achados de risco médio a alto.

• União Europeia: estrutura proporcional; TLPT condicional à identificação. O DORA abrange entidades financeiras, incluindo provedores de serviços de ativos criptográficos [15]. Ele exige testes apropriados — não especificamente teste de penetração — pelo menos anualmente para sistemas que suportam 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 se aplica apenas a entidades identificadas pelas autoridades competentes, é executado em sistemas de produção reais e geralmente é exigido pelo menos a cada três anos; as autoridades podem ajustar essa frequência com base em critérios de risco. O DORA também impõe condições de independência para os testadores. Microempresas estão fora do requisito de programa de testes.

• Cingapura: expectativa de supervisão não vinculante. As Diretrizes de Gerenciamento de Risco Tecnológico da MAS 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 e não exige um terceiro independente. O Aviso de Higiene Cibernética vinculante, específico para bancos, não especifica o teste de penetração. O aviso vinculante de pagamento ou de token 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 "web3" com marca própria. A versão especializada em web3 decorre dos sistemas dentro do escopo: onde eles autorizam, assinam, custodiam ou contabilizam valor 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 periodicidade, a independência do testador, a remediação, as evidências e se o teste apoia o licenciamento, a conformidade contínua ou um exercício desencadeado por regulador.

Conclusão: os dois pilares convergem

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

Continue com a série:

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

• Parte 3: Regras de Engajamento e Segurança em Produção para Teste de Penetração Institucional em Blockchain

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

Também nesta série, com 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 de Operações Automatizadas
• Parte 7: Segurança do Plano de Controle de Tesouraria: Aprovações de Assinatura e Saque
• Parte 8: Segurança do Livro-Razão de Exchange: Caminhos de Roubo e Lógica do Plano de Dados

A BlockSec ajuda instituições a posicionar essa camada com precisão: mapeando os ativos, fluxos de fundos, fronteiras de confiança e garantias existentes; confirmando as obrigações que a assessoria jurídica indica serem aplicáveis; e então definindo 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; 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 na ordem de primeira aparição.

1. BlockSec, Crypto Payment Security Playbook.
2. Federal Bureau of Investigation dos EUA, DC3, e Agência Nacional de Polícia do Japão, Identification of North Korean Cyber Actors (TraderTraitor) Responsible for Theft of $308 Million from Bitcoin.DMM.com (dezembro de 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. Departamento de Serviços Financeiros do Estado de Nova York, 23 NYCRR Part 500 — Cybersecurity Requirements for Financial Services Companies.
13. Autoridade Reguladora de Ativos Virtuais de Dubai, Technology and Information Rulebook, Parte I, Seção E.
14. Comissão de Valores Mobiliários e Futuros de Hong Kong, Circular 24EC65 (18 de dezembro de 2024, PDF).
15. União Europeia, Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA), Artigos 24–27.
16. Autoridade Monetária de Cingapura, Technology Risk Management Guidelines (janeiro de 2021), Seções 2 e 13; Notice FSM-N06: Notice on Cyber Hygiene (2024).