Seu sistema de pagamentos existe para movimentar dinheiro — e é exatamente por isso que carteiras hot, fluxos de assinatura e privilégios de administrador são alvos diretos para atacantes. Como os casos abaixo demonstram, a superfície de ataque foi além das vulnerabilidades em contratos inteligentes e chegou à infraestrutura de assinatura, às chaves e às pessoas que as operam.
Esse é o padrão por trás de três dos maiores incidentes relacionados a pagamentos em cripto de 2025. Analisamos as cadeias de ataque em profundidade, e cada uma mapeia um caminho de ataque distinto: um ataque à cadeia de suprimentos na infraestrutura de assinatura, um vazamento de chave de administrador e funcionários de operações comprometidos por engenharia social. A seguir, detalhamos o que aconteceu em cada caso, o que isso revela sobre os rumos dos ataques a sistemas de pagamento em cripto, e então vamos um nível abaixo na camada de contratos sobre a qual esses pagamentos rodam — onde os contratos inteligentes realmente aparecem em um sistema de pagamentos, como as duas principais stablecoins diferem em quem pode congelar ou cunhar seus fundos, e o que um contrato de pagamentos implantado por conta própria precisa antes e depois de entrar em produção.
Bybit, US$ 1,5 bilhão: Quando a Ferramenta de Assinatura Vira o Ataque
Os atacantes nunca exploraram uma vulnerabilidade nos próprios contratos da Bybit — eles comprometeram a interface do Safe{Wallet}, ferramenta terceirizada de gestão de multisig na qual os signatários confiavam. Eles injetaram JavaScript malicioso no código do front-end do Safe{Wallet}. Quando os signatários da Bybit viram o que parecia uma "transferência interna" rotineira na interface web do Safe{Wallet} e a assinaram, estavam na verdade assinando uma operação delegatecall que substituiu o slot 0 do proxy do contrato multisig por um contrato de implementação controlado pelo atacante. Uma vez assinado, os atacantes drenaram a carteira inteira em questão de minutos.
Quatro coisas precisaram falhar simultaneamente para que isso funcionasse:
- Segurança de endpoint — a interface web dos signatários vinha de um terceiro, sem verificação independente.
- Verificação de transação — a assinatura às cegas fez com que os signatários não conseguissem distinguir uma transferência normal de um delegatecall na tela.
- Design do contrato — o privilégio de atualização do proxy não tinha proteção por timelock.
- Isolamento operacional — o ambiente de assinatura não estava fisicamente isolado do ambiente de escritório do dia a dia.
Esse último ponto merece atenção: mesmo uma exchange bem estruturada pode perder US$ 1,5 bilhão quando várias salvaguardas falham ao mesmo tempo — segurança de endpoint, verificação de transação, design do contrato e isolamento operacional. Para uma análise mais aprofundada sobre como fortalecer o próprio ambiente de assinatura, veja gerenciamento de chaves e infraestrutura de assinatura.
UPCX, US$ 70 milhões: Uma Chave de Admin Vazada, Controle Total
Em 2025, o protocolo de pagamentos UPCX perdeu cerca de US$ 70 milhões devido ao vazamento de uma chave privada de administrador.
Aqui, o atacante não precisou enganar ninguém para assinar nada. Ele simplesmente obteve a chave privada do ProxyAdmin, usou a função de atualização de contrato para substituir o contrato de implementação por uma versão maliciosa e, em seguida, chamou withdrawByAdmin para drenar todos os fundos.
A lição é direta: uma chave vazada somada ao privilégio de atualização de contrato equivale a controle total. É por isso que o gerenciamento da chave do ProxyAdmin deve usar MPC ou multisig — nunca um único detentor — e por que as atualizações de contratos precisam de um timelock (por exemplo, um atraso de 48 horas) que dê à equipe uma janela para identificar anomalias antes que uma atualização entre em vigor. Aprofundamos como estruturar esse tipo de configuração de gerenciamento de chaves em outro artigo desta série.
MoonPay, US$ 250.000: Quando os Atacantes Ignoram o Código por Completo
Nem todo ataque a pagamentos em cripto envolve um contrato ou um sistema de chaves. De acordo com um processo de confisco do Departamento de Justiça dos EUA em 2025, o CEO e o CFO da empresa de pagamentos em cripto MoonPay foram vítimas de phishing e perderam cerca de US$ 250.000 em USDT por meio de um único e-mail.
O atacante se passou por uma figura conhecida e usou typosquatting para falsificar o endereço do remetente — trocando um "I" maiúsculo por um "l" minúsculo, quase invisível em uma fonte sem serifa — para induzir os executivos da MoonPay a transferirem USDT para um endereço controlado pelo atacante. Não houve nenhuma vulnerabilidade técnica aqui, e o sistema de chaves jamais foi tocado. Foi engenharia social pura.
A Tether posteriormente congelou cerca de US$ 40.000 dos fundos roubados, enquanto o restante foi para o exterior para o DOJ perseguir.
Alguns pontos se destacam:
- A engenharia social não discrimina — até executivos tecnicamente sofisticados de uma empresa de pagamentos de ponta podem cair nela.
- Sempre verifique o endereço do destinatário de forma independente antes de enviar, nunca apenas pelo endereço exibido em um e-mail. Combine verificação de endereço, lista de permissões e um período de carência para valores elevados.
- A capacidade de congelamento da stablecoin ajudou a recuperar parte da perda após o ocorrido, mas apenas uma fração foi recuperada. Prevenção é mais eficaz do que congelamento posterior.
O Padrão: Três Caminhos de Ataque, Uma Lição
Alinhando esses três casos, um padrão emerge — cada um representa um ponto de falha diferente, mas cada um tem uma defesa bem definida:
| Padrão de ataque | Caso | Alvo | Defesa central |
|---|---|---|---|
| Ataque à cadeia de suprimentos | Bybit | Ferramenta de assinatura / front-end | Verificação independente + isolamento do ambiente de assinatura |
| Vazamento de chave | UPCX | Chave privada de admin | MPC/multisig + timelock |
| Engenharia social | MoonPay | Funcionários de operações / executivos | Verificação de endereço + lista de permissões + treinamento de conscientização em segurança |
A superfície de ataque mudou: não se trata mais apenas de vulnerabilidades em contratos inteligentes — é a infraestrutura de assinatura, as chaves de admin e os funcionários de operações ao redor delas. Se você é responsável por um sistema de pagamentos em cripto, a conclusão prática é defender os três — suas ferramentas de assinatura, suas chaves de admin e seus funcionários de operações — como superfícies de ataque separadas, cada uma com seus próprios controles.
Dito isso, privilégios de contrato figuraram em dois desses três casos — o upgrade de proxy sem timelock foi uma das quatro falhas por trás do caso Bybit, e a chave ProxyAdmin da UPCX foi o ataque inteiro. Portanto, vale ir um nível abaixo: o que a camada de contratos de um sistema de pagamentos realmente é, e o que ela precisa.
Onde os Contratos Inteligentes Realmente Aparecem em Pagamentos
Se você está construindo um produto de pagamentos em cripto, é fácil presumir que segurança de contratos inteligentes significa complexidade no nível de DeFi: uma dúzia de protocolos interagindo, uma teia de premissas econômicas e uma enorme superfície de ataque para defender. Mas geralmente não é nesse território que as empresas de pagamentos vivem. Em comparação com DeFi, onde um cenário pode envolver dezenas de contratos interagindo sob um modelo econômico complexo, a lógica de contratos de pagamentos costuma ser muito mais direta. Do menor para o maior nível de complexidade, os usos se concentram em quatro lugares.
Contratos de stablecoin, usados por quase todas as empresas. USDC e USDT são, eles próprios, contratos inteligentes, com funções de admin como mint, burn, blacklist e pause. Você é um usuário desses contratos, não o implantador — mas ainda precisa entender o modelo de permissões e a capacidade de congelamento deles, o que abordaremos em seguida.
Multisig de contrato e abstração de conta, a camada de carteira e governança. Multisigs de contrato como o Safe gerenciam fundos e privilégios de contrato e estão no núcleo da camada de carteira. A abstração de conta (ERC-4337) também começou a entrar em cenários de pagamento, viabilizando pagamentos sem gas (um paymaster cobre o gas para que o usuário não precise manter o token nativo), limites de gastos corporativos e session keys.
Splits automáticos, liberação condicional e liquidação entre cadeias — a categoria que está escalando agora. É aqui que o "dinheiro programável" faz jus ao nome. O Commerce Payments Protocol da Coinbase e da Shopify divide um recebimento on-chain em tempo real: no momento da captura, o contrato roteia atomicamente a taxa para o feeReceiver e o restante para o comerciante, e pode dividir uma única autorização em múltiplas capturas com taxas diferentes para destinatários diferentes — por exemplo, capturando 1.000 USDC em duas partes, pagando taxas a diferentes destinatários e liquidando o restante para o comerciante. O mesmo protocolo traz o fluxo de autorização/captura familiar das bandeiras de cartão para a cadeia: um contrato de escrow retém os fundos após o comprador autorizar, permitindo que o comerciante faça a captura ou o reembolso posteriormente. No lado da liquidação, o CCTP da Circle usa burn-and-mint nativo para transferência de USDC entre cadeias e pode acionar ações de contrato subsequentes na chegada, encadeando movimentação entre cadeias e liquidação automatizada.
Yield automático e gestão de tesouraria — ainda em estágio inicial. Isso significa colocar reservas ociosas em protocolos DeFi de baixo risco para obter rendimento, ou automatizar a movimentação de tesouraria com contratos. A maioria das empresas de pagamentos ainda não adotou isso em escala, e por boas razões: isso introduz dependências de protocolos externos, o que amplia a superfície de ataque.
A maioria das empresas de pagamentos hoje permanece nas duas primeiras categorias, a terceira está começando a escalar agora, e a quarta ainda é incipiente. Quanto mais simples o uso, menor a superfície de ataque — portanto, adicione complexidade de contratos apenas conforme seu negócio exigir, não pelo simples fato de ser "programável."
O Modelo de Permissões por Trás de Cada Stablecoin que Você Utiliza
Como usuário de stablecoin, você precisa entender o design de permissões incorporado ao próprio contrato. As duas principais stablecoins adotam abordagens opostas.
USDC (Circle) usa um modelo de poderes separados: masterMinter gerencia as permissões de cunhagem, pauser pode pausar o contrato, blacklister gerencia a lista negra e owner gerencia a atribuição de funções. Cada função é independente, sem sobreposição de privilégios (veja o código-fonte do contrato Circle stablecoin-evm).
USDT (Tether) usa um modelo de proprietário único: um endereço de owner detém todos os privilégios ao mesmo tempo — mint, pause e addBlackList. É mais simples em design, mas mais concentrado.
Nenhum modelo é estritamente superior — eles apresentam trocas diferentes. Os poderes separados do USDC são mais seguros, mas mais complexos de operar, enquanto o modelo concentrado do USDT é eficiente, mas depende mais fortemente da segurança de um único endereço de owner. Essa diferença não é apenas acadêmica: ela afeta diretamente seu risco de congelamento caso um emissor de stablecoin precise agir sobre seus fundos.
Melhor Auditoria de Segurança para Web3
Valide design, código e lógica de negócios antes do lançamento
Protegendo os Contratos que Você Mesmo Implanta
Se você implanta seus próprios contratos de recebimento, liquidação, split ou escrow, você precisa de uma auditoria profissional de contratos de pagamentos antes da implantação e de um conjunto de mecanismos de segurança incorporados.
Antes da implantação, contrate uma auditoria de uma empresa de segurança terceirizada independente, além de varreduras automatizadas estáticas e dinâmicas. Certifique-se de que a revisão cubra especificamente gerenciamento de permissões, fluxos de fundos, reentrância e overflow de proporção de split — os riscos específicos de pagamentos, não apenas vulnerabilidades genéricas de contratos.
Em tempo de execução, quatro mecanismos se aplicam:
- Timelock — um atraso (por exemplo, 48 horas) em atualizações de contratos e alterações de parâmetros, dando à sua equipe e à comunidade uma janela para identificar problemas antes que entrem em vigor.
- Circuit breaker — pausa automaticamente as operações do contrato no momento em que uma anomalia é detectada.
- Separação de funções — implantador, atualizador, pausador e admin usam chaves diferentes, de modo que nenhuma credencial única controle tudo.
- Padrão de proxy atualizável — um proxy transparente ou UUPS, com atualizações protegidas por timelock mais multisig.
Após a implantação, revogar imediatamente os privilégios elevados do desenvolvedor é a medida central contra ameaças internas, e é a lição direta do incidente da UPCX mencionado acima: transfira os privilégios de admin e owner para um contrato multisig, proteja a chave do ProxyAdmin com multisig mais timelock, revise regularmente o estado de permissões do contrato para confirmar que não restam privilégios residuais do desenvolvedor, e certifique-se de que toda alteração de permissão on-chain emita um log de evento para monitoramento e auditoria.
Nada disso substitui a própria auditoria — é o que impede que uma auditoria limpa se deteriore em um contrato não monitorado e com privilégios excessivos após o lançamento.
Defenda Quatro Superfícies e Mantenha a Quarta a Menor Possível
Três das superfícies expostas pelos incidentes de 2025 são operacionais: suas ferramentas de assinatura, suas chaves de admin e seus funcionários de operações. A quarta é a camada de contratos, e aqui o objetivo é diferente — não igualar a complexidade do DeFi, mas corresponder ao seu uso real: conheça o modelo de permissões das stablecoins que você utiliza, mantenha seus próprios contratos tão simples quanto o negócio permitir, e trate a auditoria como o dia um de uma prática contínua de higiene de permissões, não como a linha de chegada.
Para entender onde cada uma dessas superfícies se situa no sistema como um todo, veja nossa análise da arquitetura de pagamentos em seis camadas. Para uma análise completa de como esses controles se encaixam, baixe o playbook completo (PDF), e para monitoramento em tempo real capaz de bloquear automaticamente transações de ataque na etapa do mempool, confira o monitoramento de segurança on-chain.
Perguntas Frequentes
Qual foi o maior ataque a pagamentos em cripto em 2025? A Bybit, em fevereiro de 2025, perdendo cerca de US$ 1,5 bilhão (401.347 ETH) após atacantes comprometerem o código do front-end da ferramenta de multisig terceirizada Safe{Wallet} e induzirem os signatários a aprovar um delegatecall malicioso.
Como o ataque à UPCX aconteceu?
Um atacante obteve a chave privada do ProxyAdmin da UPCX, usou a função de atualização de contrato para inserir um contrato de implementação malicioso e chamou withdrawByAdmin para drenar cerca de US$ 70 milhões em fundos.
O incidente da MoonPay foi uma exploração de contrato inteligente? Não. O incidente da MoonPay, no qual o CEO e o CFO foram vítimas de phishing e perderam cerca de US$ 250.000 em USDT, não envolveu nenhuma vulnerabilidade técnica. Foi engenharia social pura, utilizando um endereço de remetente falsificado por typosquatting.
O que Bybit, UPCX e MoonPay têm em comum? Cada ataque teve como alvo uma camada diferente de um sistema de pagamentos — a ferramenta de assinatura, a chave de admin e os funcionários de operações — demonstrando que a maior ameaça migrou das vulnerabilidades em contratos inteligentes para a infraestrutura de assinatura, as chaves e as operações.
Qual é a diferença entre os modelos de permissões do USDC e do USDT?
O USDC (Circle) usa um modelo de poderes separados, com funções independentes de masterMinter, pauser, blacklister e owner. O USDT (Tether) usa um modelo de proprietário único, onde um endereço detém todos os privilégios — mint, pause e addBlackList — ao mesmo tempo.
Quais mecanismos de segurança um contrato de pagamentos implantado por conta própria deve ter? Antes da implantação: uma auditoria independente de terceiros mais varredura automatizada, com revisão focada em gerenciamento de permissões, fluxos de fundos, reentrância e overflow de proporção de split. Em tempo de execução: um timelock em atualizações, um circuit breaker, separação de funções entre chaves e um padrão de proxy atualizável protegido por timelock mais multisig.
Por que revogar os privilégios do desenvolvedor após a implantação é tão importante? É a medida central contra ameaças internas, e é a lição direta do caso UPCX. Transferir os privilégios de admin e owner para um contrato multisig e revisar regularmente o estado de permissões para confirmar que não restam privilégios residuais do desenvolvedor fecha essa lacuna.
