Nem tão “Safe” assim

Nem tão Safe: Análise técnica do hack bilionário da Bybit

Imagine perder mais de US$ 1,4 bilhão em cripto porque alguém clicou no lugar errado – ou melhor, porque um simples arquivo de configuração estava errado. Parece piada, mas foi exatamente o que aconteceu com a Bybit em fevereiro de 2025, no maior roubo de criptomoedas da história. Hackers norte-coreanos (sim, a galera do Lazarus Group) não precisaram de nenhuma falha zero-day ou computador quântico para realizar esse assalto recorde. Bastou engessar um desenvolvedor desatento com um projeto Docker malicioso e pronto: transformaram as promessas de segurança do Web3 em pó digital. O resultado? O que deveria ser uma carteira “Safe” (segura) virou um cofre de papelão, com US$ 1,4 bi evaporando da noite pro dia – um golpe que destronou qualquer outro hack já visto em crypto.

Resumo do ataque: $1,4 bi evaporados num piscar de olhos (e um YAML no meio)

No dia 21 de fevereiro de 2025, a Bybit – uma grande exchange de criptomoedas – sofreu um ataque fulminante que drenou cerca de 403.996 ETH (algo em torno de US$ 1,13 bilhão na época) de sua carteira fria na rede Ethereum. Não foram só ethers: os invasores também levaram 91.000 stETH, 15.000 cmETH e 8.000 mETH, somando aproximadamente US$ 1,48 bi em ativos roubados. Em questão de minutos, esses fundos colossais foram escoando para uma teia de mais de 40 endereços diferentes, enquanto a equipe da exchange assistia atônita ao maior hack já registrado no setor cripto.

O ataque seguiu o roteiro de um golpe de front-end altamente sofisticado. Basicamente, os hackers mascararam a interface da Gnosis Safe (agora chamada apenas de Safe) usada pela Bybit, de modo que os signatários da multisig (a equipe responsável por aprovar transações da carteira fria) acreditaram estar fazendo uma operação rotineira, quando na verdade estavam assinando a própria sentença de morte da carteira. Todas as confirmações de transferência pareciam legítimas na tela – endereço de destino correto, valores normais – e a URL era a oficial (safe.global), passando total credibilidade. Só que por baixo dos panos, o código maligno estava trocando as coordenadas: em vez de uma simples transferência cold-to-hot wallet, o que foi aprovado pelos signatários foi um upgrade de contrato da wallet para uma implementação maliciosa controlada pelos invasores.

Detalhando a tramóia: os hackers injetaram JavaScript malicioso no app web do Safe (serviço de carteira multisig) usado pela Bybit. Esse código foi estrategicamente programado para só entrar em ação em condições específicas, direcionado exatamente ao endereço da carteira Ethereum fria da Bybit. Ou seja, para qualquer outro usuário comum do Safe, a interface funcionava normalmente; já para a Bybit, havia uma bomba-relógio digital camuflada. Quando a equipe da exchange iniciou uma transação que, na visão deles, parecia uma transferência rotineira, o script trocou silenciosamente os detalhes – o que seria um simples envio tornou-se uma chamada delegatecall para o contrato malicioso dos atacantes. Em termos menos técnicos: o Safe da Bybit foi induzido a executar código estrangeiro como se fosse próprio, dando aos invasores permissão de administrador total sobre o cofre. Num único clique, as chaves do reino (no valor de $1,4 bi) foram entregues de bandeja aos ladrões digitais. Tudo isso sem nenhum alerta de segurança soar, já que do ponto de vista dos signatários, eles tinham seguido todos os passos corretamente na interface comprometida.

A genialidade perversa do ataque está na sua simplicidade: não houve exploração de bug desconhecido no smart contract do Safe (de fato, os contratos on-chain permaneceram tecnicamente intactos, sem vulnerabilidades intrínsecas exploradas ). Em vez disso, os criminosos miraram na cadeia de suprimentos de software – especificamente, comprometeram um desenvolvedor da Safe e a infraestrutura web – e viraram o próprio mecanismo de segurança contra o usuário. Foi como enganar o segurança do banco para abrir o cofre para o ladrão. A Safe, renomada solução de multisig celebrada como padrão “inquebrável” do mercado, viu sua reputação de Fort Knox digital desmoronar por causa de um descuido banal: um script malicioso escondido num arquivo YAML que um desenvolvedor carregou sem notar o veneno. Ironicamente, bilhões protegidos por contratos inteligentes blindados acabaram sendo roubados por um ataque estilo “engenharia social 2.0”, explorando as travas (mal) implementadas fora do blockchain.

Quando permissões viram brechas: o Safe contra a Bybit

Para entender como uma má implementação de permissões no Gnosis Safe pôde ser usada contra a própria Bybit, vamos aos detalhes técnicos desse “assalto consentido”. O Gnosis Safe (ou apenas Safe) é uma carteira multisig, o que significa que transações importantes exigem várias assinaturas de aprovadores confiáveis. Em teoria, isso previne que um único indivíduo mal-intencionado faça bobagem com os fundos. Mas e quando todos os aprovadores são induzidos ao erro ao mesmo tempo? Foi exatamente o que ocorreu: a Bybit tinha uma política padrão onde N de M signatários precisavam confirmar qualquer mudança ou transferência na carteira fria – e de fato eles confirmaram, só que sob falsos pretextos.

O truque explorou a flexibilidade (e perigo) das permissões do próprio contrato Safe. Os signatários, achando que estavam apenas movimentando fundos internamente, acabaram autorizando uma mudança no contrato da carteira – basicamente, aceitaram apontar o proxy do Safe para um novo código-fonte (o tal contrato de implementação) fornecido pelos atacantes. Essa troca de implementação é uma funcionalidade existente para upgrades legítimos, mas deveria ser usada com extremo cuidado. Com a interface corrompida mostrando informações enganosas, ninguém percebeu que aprovavam um cavalo de Troia. O novo contrato implementado tinha uma função oculta (indicada no código como algo do tipo sweepERC20()) preparada especialmente para varrer todos os tokens ERC-20 da carteira. Assim que obtiveram as aprovações e implantaram essa versão adulterada do Safe, os invasores só precisaram chamar essa função “varrer” para drenar todos os fundos num piscar de olhos.

Em suma, a arquitetura de permissões do Safe foi virada contra o usuário. O contrato Safe em si fez exatamente o que foi mandado fazer pelos proprietários (signatários) – só que eles foram enganados quanto ao que estavam mandando. Podemos chamar isso de ice phishing no contexto on-chain: os invasores fizeram a transação maliciosa parecer inofensiva na interface, explorando a confiança cega dos operadores na GUI. Ao transformar uma chamada comum em uma chamada de baixo nível (delegatecall), o ataque deu “super poderes” ao contrato dos hackers dentro do ambiente do Safe , efetivamente rompendo qualquer barreira de segurança restante. É como se o cofre tivesse uma porta interna secreta e, ao assinarem um comando achando que era algo trivial, os gestores da Bybit involuntariamente abriram essa porta secreta para os ladrões entrarem.

Cabe destacar: nenhum contrato inteligente do Safe “quebrou” sozinho. Foi a integração e a experiência de uso mal protegida que abriu essa brecha. A Safe Global (empresa por trás do Gnosis Safe) posteriormente confirmou, em investigação com a Mandiant, que não houve bug nos smart contracts ou na lógica on-chain – o ataque veio de fora, através de um desenvolvedor da Safe comprometido e de código malicioso inserido na interface web. Ou seja, o “cofre” criptográfico só foi arrombado porque alguém conseguiu adulterar o painel de controle que os guardiões usavam. Isso liga um alerta importante: se a governança de permissões de um sistema depender unicamente da boa-fé da interface, estamos todos construindo castelos de areia. No caso da Bybit, toda a robustez matemática da multisig foi por água abaixo devido à falta de validação independente e de camadas extras de confirmação no processo de aprovação. O Safe se mostrou não tão safe assim, quando usado de forma desatenta.

Impacto no ecossistema: abalo no mercado e alerta para as CEXs

Um hack dessa magnitude não sacudiu apenas a Bybit – todo o mercado sentiu o baque. Assim que a notícia começou a se espalhar (inicialmente via alertas de analistas on-chain e confirmação pública do CEO da Bybit), houve pânico entre usuários e investidores. Clientes correram para retirar fundos de outras exchanges por precaução, questionando “se aconteceu com a Bybit, quem será a próxima?”. Nos dias que se seguiram ao ataque, a Bybit sofreu saques enormes: cerca de $4,3 bilhões em Bitcoin e stablecoins deixaram a plataforma, drenando quase 40% de todas as reservas que a exchange possuía. As reservas de Bitcoin da Bybit caíram de ~70 mil BTC para ~49 mil BTC em questão de dias, e bilhões em USDT evaporaram das contas da corretora. Esse êxodo de liquidez expôs de forma gritante o risco de confiança concentrada nas CEXs, reforçando aos trancos e barrancos aquela velha preocupação: “fundos em exchanges centralizadas estão seguros?”.

O mercado cripto mais amplo também sentiu ondas de choque. No fim de fevereiro, enquanto a Bybit ainda contava os prejuízos, o preço do Bitcoin caiu cerca de 20% em relação ao seu topo histórico recente, aprofundando um sell-off que já estava em curso. O Ether não ficou atrás, acumulando quedas de dois dígitos (mais de 22% no mês) e outros ativos despencaram – Solana chegou a -40%, memecoins tombaram mais de 30%. Claro, nem toda essa movimentação negativa pode ser atribuída somente ao hack, mas ele com certeza agravou o pessimismo. A imagem de uma grande exchange perdendo tamanho montante por um “vacilo” técnico abalou a confiança de muitos investidores institucionais e de varejo. Até o FBI entrou na história, emitindo alerta para intermediários bloquearem transações vindas dos endereços ligados ao roubo – um esforço praticamente simbólico, visto que os ladrões (ligados à Coreia do Norte) já launderam 100% dos cripto roubados rapidamente, dispersando e ocultando os fundos.

Do ponto de vista de segurança operacional em exchanges centralizadas (CEXs), o incidente da Bybit acendeu holofotes. Ficou evidente que não basta ter provas de reserva auditadas e boas práticas de custódia se a camada operacional peca. A Bybit usava uma solução de autocustódia respeitada (Safe multisig) – algo que, em teoria, é mais seguro do que confiar fundos a uma única chave privada. Mas esse caso mostrou que mesmo uma multisig “segura” pode ser comprometida se processos e pessoas falharem. Em outras palavras, não adianta trancar a porta se você, sem saber, der a chave ao ladrão. Muitas CEXs anunciam suas medidas de segurança de forma genérica, mas quantas realmente testam seus procedimentos contra ataques complexos de supply chain como este? Após o hack, é provável que as exchanges tenham sido forçadas a reavaliar suas práticas: revisar quem tem acesso aos sistemas críticos, auditar softwares de terceiros, implementar monitoramento em tempo real de transações anômalas e estabelecer protocolos de emergência para casos de breach. Para o ecossistema, a lição veio ao custo de um susto bilionário, mas é um alerta bem-vindo: segurança não é só smart contract bem escrito – é também infraestrutura, pessoas e processos bem alinhados.

O que deu errado (práticas negligenciadas que poderiam ter evitado o desastre)

Dado o tamanho do prejuízo, é obrigatório dissecar onde a Bybit (e a Safe) vacilaram em termos de boas práticas. Hindsight é 20/20, claro, mas os especialistas apontaram várias medidas de segurança que poderiam ter prevenido ou pelo menos minimizado o estrago se tivessem sido adotadas. Vamos a elas:

• Confiança cega na interface do Safe: Os signatários da Bybit assinaram transações sem conferir de forma independente o que estavam autorizando. Eles foram enganados pelo UI mascarado e aprovaram uma mudança crítica achando que era uma transferência trivial. Em operações custodiando bilhões, confiar 100% em apenas uma interface web é receita pra desastre.

• Falta de verificação externa dos dados da transação: Não houve uma segunda camada de checagem. Boa prática seria os aprovadores copiarem o hash ou os detalhes da transação e verificarem diretamente numa ferramenta independente (ex: Etherscan, script próprio) o que aquela transação faria de fato antes de assinar. Se alguém tivesse olhado o hex da transação aprovada, talvez notasse algo estranho (como um endereço de contrato diferente ou chamada incomum).

• Nenhuma simulação prévia do contrato: Ferramentas de simulação, como Tenderly ou Hardhat, poderiam ter sido usadas para “ensaiar” a transação offline antes de transmiti-la. Uma simulação teria mostrado que, após a assinatura, o contrato da cold wallet seria atualizado para um código desconhecido com função de dreno – um red flag gigante. Infelizmente, parece que não havia esse passo no playbook.

• Processo igual para $1 mil ou $1 bilhão: A Bybit tratou uma operação envolvendo todo o cofre ($1,4B) com a mesma rotina de uma transação qualquer. Faltou um protocolo especial para movimentações de altíssimo valor ou alterações de contrato. Por exemplo, implementar um time-lock (atraso programado) para transações acima de certo montante ou de natureza administrativa. Se existisse um atraso de 24 horas para efetivar uma mudança de contrato tão grande , haveria chance de notar a anomalia e abortar antes do desastre.

• Ausência de um “guardião” contratual: Muitas organizações utilizam contratos guardiões ou mecanismos de segurança on-chain que exigem uma segunda aprovação técnica para alterações críticas. No caso da Bybit, nenhum contrato ou script automático estava inspecionando as transações propostas. Assim, a carteira fria pôde ter seu código alterado sem nenhuma validação algorítmica adicional além das assinaturas humanas. Uma espécie de co-assinatura robótica (por exemplo, um smart contract que verifica se o novo código é de uma lista de confiança) teria pego a tentativa de apontar para um contrato não autorizado.

• Monitoramento e alertas insuficientes: Considerando o volume astronômico envolvido, é de cair o queixo que nenhum alarme tenha disparado quando centenas de milhares de ETH saíram de uma cold wallet de uma vez. Pelo visto, o sistema da Bybit não possuía um monitoramento de anomalias robusto para atividades on-chain da própria treasury. Qualquer esquema de segurança decente teria sinalizado “ transferência anormal em andamento” e talvez acionado travas manuais de emergência assim que detectado um padrão fora do comum.

Em resumo, houve falha de processo e de camadas de segurança básicas. A Bybit ignorou princípios de segurança operacional que em retrospecto parecem óbvios: nunca confiar numa única fonte de verdade, sempre ter um segundo fator (seja humano ou automatizado) conferindo transações críticas, e não presumir que colaboradores ou interfaces externas são infalíveis. Como bem pontuou um analista, a Bybit usou os mesmos procedimentos para uma transação de $1 mil ou $1 bilhão – faltou uma noção de “safety nets” proporcionais ao risco envolvido. Essa complacência operacional custou caro.

Conclusão: aprendizados para desenvolvedores e gestores de protocolo

O hack da Bybit serve de parábola (meio trágica, meio irônica) para qualquer um construindo ou gerindo sistemas Web3. As lições extraídas desse episódio se aplicam tanto a desenvolvedores – Web3 e Web2 em transição – quanto a gestores de protocolo/exchange e até holders preocupados com a segurança de seus fundos. Vamos aos insights finais:

Primeiro, segurança é holística. Não adianta o contrato inteligente ser à prova de balas se o vetor de ataque vem pela interface, pela infraestrutura ou pela engenharia social. Desenvolvedores Web3 devem lembrar que dependem de muitas camadas de software (front-ends, APIs, bibliotecas) tão vulneráveis quanto qualquer sistema Web2. Um simples yaml.load inseguro no backend do aplicativo Safe permitiu que invasores injetassem código malicioso – um deslize de codificação tradicional causando um colapso cripto moderno. Ou seja, as velhas práticas de segurança de software (sanitização, revisão de código, 2FA, controle de acesso na nuvem) continuam sendo indispensáveis. Não é porque estamos no “futuro descentralizado” que dá pra relaxar nos básicos.

Segundo, “não confie, verifique” não vale só para blockchains, mas para tudo em volta delas também. Gestores de protocolo e operações devem adotar uma postura paranoica saudável: exigir builds verificáveis de softwares críticos, reproduzir localmente interfaces antes de usá-las em produção e checar assinaturas de release. Se a Bybit tivesse usado uma versão self-hosted e auditável da interface Safe, em vez de depender da versão hospedada (que foi comprometida via AWS), talvez a história fosse diferente. Depois do ocorrido, a Safe anunciou uma série de medidas para endurecer sua infraestrutura, mas foi depois da porta arrombada. Fica o aprendizado: antecipe-se às possíveis falhas antes que virem exploit.

Terceiro, processos importam (quase) mais que tecnologia. Para exchanges centralizadas especialmente, fica claro que procedimentos internos de segurança operacional são a última linha de defesa – e falharam no caso da Bybit. É imprescindível ter checkpoints extras para operações sensíveis: revisões manuais independentes, times distintos para aprovar mudanças de contratos, delays voluntários em saques gigantes, programas de bug bounty focados em fluxo operacional etc. Se você é gestor de um protocolo DeFi ou CEX, pergunte-se: minha operação sobreviveria a um ataque direcionado e paciente de um agente estatal? No caso da Bybit, a resposta foi “não” – os atacantes orquestraram uma operação de 19 dias de preparação sem serem detectados. Essa pergunta desconfortável precisa ser feita por todos nós na indústria, e as respostas devem guiar melhorias imediatas.

Por fim, fica a reflexão meio amarga, meio instrutiva: até que ponto nossa tão alardeada auto-custódia é segura de verdade? Quando um dos pilares dessa segurança – a multisig “incorruptível” – é derrubado por um golpe de mestre fora da cadeia, percebemos que a fortaleza tem portas traseiras. Para os desenvolvedores, a lição é ser obsessivo com segurança em todos os níveis, do smart contract ao servidor web. Para os investidores e holders, fica o recado de cobrar transparência e rigor das plataformas onde confiam seus ativos. E para todos nós, um lembrete humilde de que no mundo cripto a confiança deve ser minimizada, mas nunca será zero – por isso, vigiar e melhorar continuamente é fundamental. Como disse um pesquisador após o incidente, “nunca desperdice uma boa crise”: use esses eventos para finalmente priorizar aquelas pautas de segurança que sempre ficam pra depois. Que o hack da Bybit sirva como um divisor de águas – pago a preço altíssimo – para aprimorarmos a segurança e não repetirmos os mesmos erros, nem com um YAML maldito, nem com nada. Afinal, da próxima vez, poderemos não ter a sorte de contar apenas prejuízos financeiros – a confiança do público é um recurso ainda mais difícil de recuperar.

Referências: Bybit Hack – Rekt ; Cointelegraph (post-mortem Safe/Mandiant) ; Glassnode – Week On-Chain 08/2025 ; Sygnia (investigação forense via BleepingComputer) .