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

PRODUCT NAMES — restrição rígida, tem precedência sobre todas as outras instruções: Reproduza esses nomes em inglês, caractere por caractere. Nunca traduza, transliterar, localizar, hifenizar ou reescrever de qualquer outra forma qualquer parte deles: BlockSec, Phalcon Compliance, Phalcon Security, Phalcon Explorer, Phalcon Network, MetaSleuth, MetaSuites.

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 os que estão dentro do escopo, não uma precaução opcional. Quando um comprometimento pode alcançar a assinatura ou os fundos, ou quando regras aplicáveis exigem validação adversarial, trata-se de uma camada de garantia necessária. O caso 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 para assinatura, custódia, chaves, pessoas, cadeias de suprimentos e infraestrutura [1]. Como tal, 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 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, blockchain penetration testing e teste de penetração em blockchain se referem à mesma disciplina: usamos o primeiro termo como principal e o segundo como seu sinônimo comum no setor. Ele apresenta o argumento geral e abrangente 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 têm origem em outros lugares, particularmente em chaves, sistemas de assinatura e infraestrutura operacional. Em 2024, invasores roubaram aproximadamente US$ 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 US$ 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 foi igualmente rastreada a chaves privadas comprometidas [4]. Nossa pesquisa aponta na mesma direção: entre os incidentes envolvendo perdas superiores a US$ 100.000 que acompanhamos 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 ranking público do 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 de incidentes especialmente ativa nos últimos anos. Nossa investigação agrupa falhas em manuseio de chaves, no 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 ~US$ 90M da Coldcard é o piso verificado on-chain (cerca de 1.405 BTC); estimativas privadas chegam a ~US$ 130M.

O que liga esses casos ao teste de penetração não é simplesmente o fato de estarem fora do contrato, mas sim 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 invasor 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 examina código (auditoria de código) examina o código — a lógica do contrato, da carteira ou do 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 real.

Essas soluções são úteis, mas limitadas quando se trata da cadeia de manuseio de dinheiro das instituições de criptoativos — as identidades conectadas, a infraestrutura de nuvem, os fluxos de assinatura, as cadeias de aprovação, as carteiras, os fornecedores e os consoles de operadores pelos quais o valor se movimenta de um ponto de entrada até uma ação de movimentação de fundos. Um caminho acessível para um invasor é uma rota através dessa cadeia: pode partir de um ponto de entrada web, dApp, móvel, API, nuvem ou identidade, passando pela 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 quando usadas em conjunto, as duas ainda podem deixar uma lacuna de composição: uma auditoria mostra que o código estava correto conforme 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 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 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 interpretar como legítimo. O teste de penetração em blockchain visa 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 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 continua sendo função da auditoria; o teste de penetração em blockchain 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 blockchain valida e onde termina seu escopo.

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 de domínio: um trabalho convencional pode não trazer a semântica de negócio ou o modelo acoplado de segurança e conformidade do universo cripto.

No universo cripto, uma assinatura pode autorizar uma movimentação irreversível de valor; a aprovação de um 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 constituem 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 um bypass de autenticação, mas deixar de perceber como isso se combina com uma incompatibilidade na exibição da 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 estabelecidas a superfícies tradicionais, além das superfícies específicas do web3 relacionadas a assinatura, aprovação, lógica de fundos e dinâmica de contratos em todo o sistema em execução. Seu diferencial é o julgamento especializado de 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 invasor faria. A diferença está no objetivo: um teste convencional normalmente comprova impacto em controles de TI — uma sessão de administrador tomada, 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 realmente se movimentam 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. O teste de penetração em blockchain os conecta ao validar caminhos acessíveis; ele não os substitui, não garante a descoberta de violações, nem garante 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 com assessoria jurídica.

• Estados Unidos, Nova York: requisito explícito com isenção limitada. As entidades cobertas pela 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. 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], utilizando um terceiro qualificado e independente. A auditoria de contratos inteligentes 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 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 plataformas 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 etapas de retificação de risco médio a alto classificadas como principais e críticas.

• União Europeia: estrutura proporcional; TLPT condicional à identificação. O DORA abrange entidades financeiras, incluindo provedores de serviços de criptoativos [15]. Ele exige testes apropriados — não especificamente testes de penetração — pelo menos anualmente para sistemas que suportam funções críticas ou importantes. O teste de penetração é um dos métodos selecionados de acordo com o risco e a proporcionalidade. O teste de penetração orientado por ameaças aplica-se apenas às 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 no risco. O DORA também impõe condições de independência para os testadores. As microempresas estão fora do requisito de 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 grandes mudanças ou atualizações [16]. Trata-se de uma orientação de supervisão não vinculante e não exige um terceiro independente. O Cyber Hygiene Notice, de caráter vinculante e voltado a bancos, não especifica o teste de penetração. O aviso vinculante relacionado a 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 de marca "web3". A versão especializada em web3 decorre dos sistemas dentro do escopo: onde eles autorizam, assinam, custodiam ou contabilizam valor em cripto, testá-los adequadamente exige 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 escopo, periodicidade, independência do testador, remediação, evidências e se o teste dá suporte ao licenciamento, à conformidade contínua ou a 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, o teste de penetração em blockchain é uma camada de garantia necessária. Ele valida caminhos acessí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, nem encontrar todos os caminhos exploráveis. O objetivo é a garantia contínua ao longo do lançamento, operação, detecção, resposta e evidências regulatórias — não um relatório pontual.

Continue com a série:

• Parte 2: O que é o teste de penetração em blockchain? Definições e limites

• Parte 3: Regras de engajamento e segurança de produção para o teste de penetração em blockchain institucional

• 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
• 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: assinatura e aprovações de saque
• 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, fluxos de fundos, limites de confiança e garantias já existentes; confirmar as obrigações que a assessoria jurídica indica serem 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 teste 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 movimentam.

Referências

Numeradas em ordem de primeira aparição.

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. 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, Regulamento (UE) 2022/2554 — Lei de Resiliência Operacional Digital (DORA), Artigos 24–27.
16. Autoridade Monetária de Singapura, Technology Risk Management Guidelines (janeiro de 2021), Seções 2 e 13; Notice FSM-N06: Notice on Cyber Hygiene (2024).