Dos Incidentes à Regulação: Por Que Instituições de Criptomoedas 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 — os testes de penetração em blockchain são, para aqueles dentro do escopo, uma precaução não opcional. Onde um comprometimento pode alcançar assinatura ou fundos, ou onde regras aplicáveis exigem validação adversarial, trata-se de uma camada necessária de garantia. O argumento se apoia em duas frentes: a origem do risco além do código de contrato e os requisitos ou expectativas regulatórias para validação adversarial.

A exposição institucional vai além dos bugs de contrato, alcançando assinatura, custódia, chaves, pessoas, cadeias de suprimentos e infraestrutura [1]. Assim, 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 pelos testes de penetração tradicionais 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 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 blockchain. Ao longo da série, testes de penetração em blockchain e testes de penetração web3 referem-se à mesma disciplina: usamos o primeiro termo como principal e o segundo como seu sinônimo comum no setor. Ele apresenta o argumento geral, de visão ampla, para a necessidade; 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 originaram-se 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 da carteira quente da BtcTurk também foi rastreada até chaves privadas comprometidas [4]. Nossa pesquisa aponta na mesma direção: entre os incidentes com perdas superiores a $100.000 que rastreamos em 2026, falhas fora do contrato representaram cerca de um em cada oito incidentes, mas mais de três quartos do total de 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, representando cerca de 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 permaneceu uma área de incidentes especialmente ativa 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 valor de ~$90M da Coldcard é o piso verificado on-chain (cerca de 1.405 BTC); estimativas privadas chegam a até ~$130M.

O que liga esses casos aos testes de penetração não é simplesmente o fato de estarem fora do contrato, mas 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 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á bem conhecidas atua em um nível específico. A auditoria em nível de código (auditoria de código) examina o código — a lógica de contratos, carteiras ou serviços. O monitoramento em nível de transação (monitoramento) examina as transações à medida que chegam à cadeia; o 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 criptoativos — as identidades conectadas, a infraestrutura em nuvem, os fluxos de assinatura, as cadeias de aprovação, as carteiras, os fornecedores e os painéis de operador pelos quais o valor se move de um ponto de entrada até uma ação de movimentação de fundos. O caminho acessível de um atacante é uma rota através dessa cadeia: pode partir de um ponto de entrada web, dApp, mobile, API, nuvem ou identidade, passando por assinatura, aprovação e lógica de fundos, e pode passar pelo comportamento de um contrato nesse contexto real, até a ação de movimentação de fundos na outra ponta. A revisão do código não monta esse caminho, e a observação de transações não o antecipa. Mesmo usados juntos, os dois 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 tecnicamente válida, mas que nunca foi a intenção do operador. O que fecha essa lacuna é a validação adversarial independente de que os controles se compõem corretamente no sistema em execução.

Os testes de penetração em blockchain exercitam 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 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. Os testes de penetração em blockchain têm como alvo diretamente essa composição: assumindo a posição de um fornecedor, operador ou interface comprometidos, testam 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 — de fato a impedem. A garantia em nível de código do contrato permanece função da auditoria; os testes de penetração em blockchain engajam um contrato implantado apenas por meio de seu comportamento em produção, quando isso faz parte de uma rota, em nível institucional, até os fundos — escopos complementares distinguidos pela ênfase, não por um limite rígido. A Parte 2 define o que os testes de penetração em blockchain validam e onde termina seu escopo.

1.3 Testes de penetração tradicionais: úteis, mas insuficientes

Os testes de penetração tradicionais continuam valiosos em superfícies de nuvem, web e API, identidade e acesso privilegiado. Sua limitação está no escopo e no contexto de domínio: um engajamento convencional pode não trazer a semântica de negócios própria das criptomoedas ou o modelo acoplado de segurança e conformidade.

No universo cripto, uma assinatura pode autorizar a movimentação irreversível de valor; a aprovação de retirada é uma decisão de controle de fundos, não apenas o envio de um formulário. O crédito de depósitos, a contabilidade de saldos e as transferências internas são lógica financeira. Endereços e transações também podem ter significado relacionado a sanções ou origem de fundos. Um testador pode encontrar um bypass de autenticação, mas deixar de perceber como ele 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.

Os testes de penetração em blockchain aplicam técnicas adversariais consolidadas às superfícies tradicionais, além das superfícies específicas de assinatura, aprovação, lógica de fundos e dinâmica de contratos web3, 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 da mesma forma que um atacante faria. A diferença está no objetivo: um teste convencional normalmente comprova impacto em controles de TI — uma sessão de administrador comprometida, um servidor alcançado — enquanto um teste em blockchain trata a movimentação de valor como 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 realmente se movem ainda estão alinhados.

Em resumo, trata-se de uma garantia complementar, não de uma barreira estática versus dinâmica. Auditorias em nível de código, monitoramento em nível de transação e testes de penetração tradicionais continuam necessários. Os testes de penetração em blockchain os conectam ao validar caminhos acessíveis; eles não os substituem, nem garantem a descoberta de violações, nem garantem prevenção.

Parte 2: O que os reguladores exigem

Os requisitos variam por 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 sua condição, isenções, sistemas e obrigações com assessoria jurídica.

• Estados Unidos, Nova York: requisito explícito com isenção limitada. As entidades abrangidas pela NYDFS 23 NYCRR Part 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 Part 500.

• Dubai: requisito anual e acionado por mudanças. Os VASPs licenciados devem realizar avaliação de vulnerabilidade e testes 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. Os testes de penetração orientados por ameaças não têm cadência universal: a VARA pode exigi-los 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 considerados licenciados devem concluir os testes de penetração e a avaliação de vulnerabilidade com resultados satisfatórios antes da operação restrita [14]. Orientações separadas se aplicam a candidatos de novas corporações. 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 etapas de correção maiores e críticas para constatações de risco médio a alto.

• União Europeia: estrutura proporcional; TLPT condicional à identificação. A DORA abrange entidades financeiras, incluindo provedores de serviços de criptoativos [15]. Ela exige testes apropriados — não especificamente testes de penetração — pelo menos anualmente para sistemas que suportam funções críticas ou importantes. Os testes de penetração são um método selecionado de acordo com o risco e a proporcionalidade. Os testes de penetração orientados por ameaças aplicam-se apenas a entidades identificadas pelas autoridades competentes, ocorrem em sistemas de produção ativos e, em geral, são exigidos pelo menos a cada três anos; as autoridades podem ajustar essa frequência com base no risco. A DORA também impõe condições de independência para os testadores. As microempresas estão fora do requisito do programa de testes.

• Singapura: expectativa de supervisão não vinculante. As Diretrizes de Gestão 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 importantes [16]. Trata-se de orientação de supervisão não vinculante e que não exige um terceiro independente. O Aviso de Higiene Cibernética, de caráter vinculante e voltado a bancos, não especifica testes 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 testes de penetração — não uma categoria de marca "web3". A versão especializada em web3 decorre dos sistemas dentro do escopo: onde eles autorizam, assinam, custodiam ou contabilizam valor em criptoativos, testá-los adequadamente exige a mesma fluência em fluxos de assinatura e 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 apoia 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 instituições dentro do escopo, os testes de penetração em blockchain são uma camada de garantia necessária. Eles validam caminhos acessíveis entre acesso, aprovação, assinatura e fundos, complementando os controles existentes. Não podem garantir a prevenção, provar que teriam impedido qualquer incidente passado específico, nem encontrar todos os caminhos exploráveis. O objetivo é uma 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 único.

Continue com a série:

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

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

• Parte 4: Superfícies de Ataque Web3: Uma Visão Geral dos Testes 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 em 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 Retirada
• Parte 8: Segurança do Livro-Razão de Exchanges: Caminhos de Roubo e Lógica do Plano de Dados

A BlockSec ajuda as instituições a posicionar essa camada com precisão: mapear os ativos, os fluxos de fundos, os limites de confiança e a garantia já existente; confirmar as obrigações que a assessoria jurídica indica como aplicáveis; e então definir 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 testes de penetração em blockchain; o escopo do engajamento e os preços estão disponíveis mediante solicitação. Comece onde os fundos se movem.

Referências

Numeradas em 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. 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 de dezembro de 2024, PDF).
15. União Europeia, Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA), Artigos 24–27.
16. Monetary Authority of Singapore, Technology Risk Management Guidelines (janeiro de 2021), Seções 2 e 13; Notice FSM-N06: Notice on Cyber Hygiene (2024).