A pessoa que solicita um pagamento passou pela verificação de identidade. O pagamento foi aprovado, e a assinatura da transação é válida. Isso significa que os fundos estão seguros?
Não necessariamente.
Em 2025, a BigONE perdeu cerca de 27 milhões USD, enquanto a Bybit sofreu um ataque de 1,5 bilhões USD. Em outubro de 2026, a Binance relatou um incidente de segurança que afetou aproximadamente 6,34 bilhões USD em ativos digitais. Esses incidentes mostram por que o armazenamento seguro das chaves privadas, por si só, não pode garantir a segurança dos fundos.
Por isso, as instituições precisam olhar além do armazenamento seguro das chaves privadas. O que justifica o pagamento? O que exatamente está sendo assinado? Quem determina se uma transação pode ser assinada? E, após a execução, como o sistema determina se o pagamento foi concluído?
Neste artigo, a BlockSec usa incidentes divulgados publicamente para examinar riscos de autorização negligenciados ao longo do ciclo de vida do pagamento, da iniciação à liquidação.
Nossa próxima série técnica, Além do Armazenamento Seguro, explorará detalhadamente dois caminhos de ataque:
-
Abusar dos recursos de assinatura de um sistema sem obter suas chaves privadas.
-
Explorar falhas em implementações criptográficas para recuperar essas chaves.
Em Que Ponto um Pagamento em Cripto Pode Ser Desviado?
Um pagamento executado por meio de uma carteira geralmente envolve quatro etapas:
-
Fundamentação e autorização do pagamento.
-
Construção e verificação da transação.
-
Autorização da assinatura e uso da chave.
-
Execução e liquidação.
1. Fundamentação e Autorização do Pagamento
Antes de assinar uma transação, a instituição deve verificar se o pagamento subjacente é legítimo:
• Para um saque de cliente, a plataforma precisa verificar a identidade do cliente, confirmar que há fundos suficientes disponíveis e conferir se a solicitação está de acordo com suas regras de negócio.
• Uma transferência interna também exige a aprovação apropriada da tesouraria.
Mas um invasor pode alterar registros de contas ou a lógica de controle de riscos. O sistema pode então seguir seu fluxo de trabalho normal e aprovar um pagamento que nunca deveria ter sido feito.
Em 16/07/2025, por exemplo, a BigONE divulgou um incidente de segurança envolvendo uma carteira quente, com perdas estimadas em 27 milhões USD. A BigONE afirmou que suas chaves privadas permaneceram seguras. A investigação da SlowMistrelatou que o invasor havia modificado a lógica dos servidores relacionada a contas e controles de risco, possibilitando transferências não autorizadas.
O ponto principal é que as informações e regras usadas para aprovar o pagamento já haviam sido alteradas antes da assinatura.
Para instituições de pagamento, portanto, não basta verificar se uma solicitação vem de um serviço interno. Cada pagamento deve poder ser rastreado até uma instrução do cliente ou decisão da tesouraria que possa ser verificada de forma independente. As instituições também precisam verificar se uma única identidade comprometida poderia forjar solicitações, alterar registros e modificar regras de aprovação.
2. Construção e Verificação da Transação
O que você vê é realmente o que pretende assinar?
Após a aprovação de um pagamento, o sistema deve converter os dados da operação, como o endereço do destinatário e o valor, em dados de transação que a carteira possa assinar.
Se esse processo for comprometido, a interface poderá exibir uma transferência, enquanto a transação enviada para assinatura, na verdade, altera quem controla a carteira.
Sua assinatura poderia, então, autorizar um invasor a assumir o controle da carteira, mesmo que você acredite estar aprovando uma transferência.
O ataque de aproximadamente 1,5 bilhões USD à Bybit em 2025 ilustra esse risco. A Bybit pretendia transferir ETH de uma carteira fria para uma carteira morna. O invasor comprometeu a interface do Safe e fez uma transação maliciosa parecer uma transferência rotineira. Os signatários a aprovaram, autorizando, sem saber, uma alteração na lógica de controle da carteira.
O invasor usou as assinaturas válidas para substituir a lógica de controle da carteira e, em seguida, usou a nova lógica para movimentar ativos sem obter nova aprovação dos proprietários originais para cada saque subsequente. Para uma análise on-chain detalhada, consulte a análise da BlockSec sobre o ataque de 1,5 bilhões USD à Bybit.
A lição é clara:
A verificação antes da assinatura deve abranger a transação completa que está sendo assinada e os efeitos de sua execução. Ela não pode depender apenas do que a interface exibe. Mesmo vários signatários podem deixar de detectar um problema se todos se basearem na mesma visualização comprometida.
Transferências, atualizações da carteira e alterações nas permissões de saque também devem ter requisitos de autorização distintos. A aprovação de uma transferência comum não deve poder ser usada para alterar o controle da carteira.
3. Autorização da Assinatura e Uso da Chave
Quem pode assinar e quem pode alterar as regras de assinatura?
Mesmo que não consigam assinar transações diretamente, invasores podem obter controle equivalente ao alterar as regras ou substituir o código em execução no sistema.
Portanto, as permissões administrativas que regem o acesso às chaves de assinatura precisam ser examinadas com o mesmo rigor que as próprias permissões de assinatura.
De acordo com o relatório oficial da Resolv sobre seu incidente de segurança de março de 2026, as tentativas iniciais do invasor de obter acesso para assinatura falharam. O invasor então usou uma função privilegiada para alterar a política de acesso à chave e conceder a si mesmo autorização para assinar. Com essa autorização, o invasor emitiu 80 million de USR por meio de duas transações não autorizadas.
Em outro incidente, o relatório inicial da Binance sobre o incidente descreve um caminho diferente para obter acesso à assinatura. O invasor usou o dispositivo comprometido de um funcionário e uma ferramenta interna de IA para chegar aos dispositivos dos engenheiros responsáveis pelas carteiras. Usando um token de implantação de contêiner roubado, o invasor implantou um contêiner e executou um script malicioso. O acesso não autorizado ao serviço interno de assinatura de carteiras permitiu, então, que transações contornassem o fluxo normal de saques.
Os pontos de entrada foram diferentes, mas ambos os incidentes expõem o mesmo problema subjacente:
Proteger as chaves também significa controlar quem pode alterar as políticas de acesso a elas, modificar o ambiente de assinatura ou conceder permissões de assinatura.
Portanto, as instituições de pagamento precisam examinar as três perguntas:
-
Quem pode chamar a API de assinatura?
-
Quem pode conceder permissão para chamá-la?
-
Quem pode implantar ou modificar o serviço de assinatura?
A segregação de funções entre a aprovação da operação, o uso da chave e as alterações administrativas também deve continuar eficaz quando uma identidade privilegiada é comprometida.
4. Execução e Liquidação
O risco termina quando uma transação é assinada?
Não necessariamente. As instituições também devem considerar quando uma transação assinada pode ser executada e como ela pode ser invalidada.
Risco 1: Uma transação assinada pode continuar passível de execução
Uma transação foi assinada, mas ainda não foi executada. Ela ainda pode ser enviada posteriormente?
Em alguns mecanismos, sim. Cancelar a solicitação de negócio subjacente não invalida automaticamente uma transação assinada.
No incidente da Drift Protocol em 01/04/2026, o invasor usou o mecanismo de nonce durável da Solana para manter transações pré-assinadas válidas além do curto período de validade das transações comuns. Enquanto o nonce relevante não tivesse sido consumido nem avançado, as transações ainda poderiam ser enviadas para execução posteriormente.
Quando uma solicitação de negócio é cancelada ou uma atividade suspeita é detectada, as instituições precisam de uma forma definida de invalidar transações assinadas, mas não executadas. Elas também devem especificar quem está autorizado a fazer isso.
Risco 2: Uma transferência interna pode ser interpretada incorretamente e gerar um reembolso adicional
Em 12/09/2026, a Chainflip sofreu uma exploração envolvendo Tron USDT. O invasor anexou um memo elaborado a uma transação que os validadores já haviam assinado. O sistema da Chainflip interpretou incorretamente o memo como uma operação de swap separada, tratou esse swap como malsucedido e emitiu um reembolso. A Chainflip relatou seis pagamentos não autorizados que totalizaram aproximadamente 736,4 mil USDT.
Uma transferência on-chain não representa necessariamente um novo pagamento de cliente nem justifica um reembolso. Antes de fazer um pagamento ou emitir um reembolso, o sistema também deve verificar a origem dos fundos, o tipo de operação de negócio e se a obrigação de pagamento correspondente já foi cumprida.
Qual É a Resiliência do Seu Sistema de Pagamentos?
Esses casos mostram que fundos podem ser perdidos tanto antes quanto depois da assinatura. Uma assinatura válida, por si só, não comprova que:
• O pagamento tem uma justificativa de negócio legítima.
• A operação assinada corresponde ao que foi aprovado.
• A obrigação de pagamento ainda não foi cumprida.
Uma avaliação de segurança relevante para uma instituição de pagamento deve, portanto, responder a perguntas concretas:
• Cada pagamento pode ser rastreado até uma justificativa de negócio verificável de forma independente?
• A operação completa que está sendo assinada corresponde ao que foi aprovado, incluindo eventuais alterações de permissão ou transações adicionais?
• Se uma identidade operacional ou administrativa for comprometida, controles independentes continuarão em vigor para bloquear ou limitar transferências de fundos não autorizadas?
• Após a suspensão dos saques, assinaturas existentes e autorizações on-chain ainda podem ser usadas para movimentar fundos? Como a instituição pode confirmar que a contenção é eficaz?
No entanto, uma revisão pontual da configuração não pode fornecer respostas duradouras a essas perguntas.
Atualizações de software, alterações de permissões e mudanças nas operações de negócio podem alterar os limites de segurança existentes. As instituições precisam reavaliar se seus controles continuam eficazes após essas mudanças.
As ferramentas de IA também podem introduzir novas superfícies de ataque. O monitoramento contínuo ajuda as equipes a detectar atividades suspeitas. Os exercícios de resposta a incidentes testam se as equipes conseguem limitar novas saídas de fundos após o comprometimento de uma identidade crítica ou de um ambiente de produção.
Para saber mais sobre a avaliação desses riscos, veja como a Solução de Segurança de Pagamentos da BlockSec ajuda as instituições a manter a segurança na era da IA.
Participe do Nosso Webinar: Protegendo Fundos na Era da IA
Para explorar essas questões, a BlockSec realizará um webinar on-line, "Protegendo Fundos na Era da IA". Com base em incidentes de segurança recentes envolvendo corretoras e empresas de pagamento, a sessão examinará como invasores obtêm acesso a sistemas que movimentam fundos por meio de pessoas, ferramentas e ambientes de produção, e como as instituições podem aprimorar a detecção de ameaças, as verificações de autorização e a resposta a incidentes.
Palestrantes convidados:
• Yajin Zhou: professor associado da The Chinese University of Hong Kong; cofundador e CEO da BlockSec
• Lei Wu: professor associado da Zhejiang University; cofundador e CTO da BlockSec
• Muhui Jiang: CSO da BlockSec
Data e horário: quarta-feira, 11/11/2026, às 7:00 p.m., horário de Singapura (SGT, UTC+8)
Formato: Webinar on-line
Benefício para os participantes: Duas instituições participantes serão selecionadas durante a sessão para receber uma avaliação preliminar de segurança gratuita.
Identificar riscos cedo é essencial para proteger cada pagamento.
Convidamos executivos, líderes de segurança e equipes técnicas de instituições de pagamento a se juntarem a nós para examinar os pontos cegos de segurança ao longo do ciclo de vida do pagamento.
Entre em contato com nossa equipe de vendas para saber mais sobre o webinar.
Visite o Site Oficial da BlockSec>>>
