Hack da Binance: o alerta para quem contrata sistema feito com IA

A Binance perdeu cerca de US$ 6,3 bilhões a partir do notebook de um engenheiro, e governos tiveram serviços derrubados por falhas básicas. Veja por que sistema feito só no vibe coding, sem quem entenda de segurança e infraestrutura, é o alvo mais fácil.

O hack da Binance, em 29 de outubro, foi o maior roubo de criptomoedas já registrado: cerca de US$ 6,3 bilhões saíram das carteiras da corretora em poucas horas. Pelo que a própria Binance informou até agora, o ataque pode ter começado no notebook comprometido de um engenheiro de DevOps, e não em uma falha de criptografia. Se uma empresa com equipe de segurança dedicada cai pela infraestrutura do dia a dia, um sistema montado só com vibe coding, sem ninguém que entenda de infraestrutura, programação e segurança, é o alvo mais fácil do mercado.

Resposta rápida

  • O que aconteceu? Em 29 de outubro, carteiras da Binance em cerca de dez blockchains foram esvaziadas. A Binance estima o prejuízo em US$ 6,3 bilhões e suspendeu saques em várias redes.
  • Como entraram? Segundo a Binance, o invasor teria usado o notebook de um engenheiro para acessar um serviço interno e enviar saques não autorizados. A empresa diz que nenhuma chave privada vazou. A análise técnica completa ainda não foi publicada.
  • Quem foi? Empresas de rastreamento de blockchain apontam o grupo norte-coreano TraderTraitor (ligado ao Lazarus). Até agora, nenhum governo confirmou oficialmente a autoria.
  • Os clientes perdem dinheiro? A Binance afirma que vai cobrir todas as perdas com o fundo de emergência SAFU e recursos próprios. Emissores de stablecoins congelaram perto de US$ 3 bilhões ligados ao ataque.
  • O que isso tem a ver com a sua empresa? Os atacantes atuam como operação de Estado: ensaiam, automatizam e procuram o elo mais fraco. Sistema gerado por IA sem revisão técnica costuma trazer exatamente as falhas que esse tipo de atacante procura primeiro.

O que se sabe do hack da Binance até agora

A carteira do atacante foi abastecida um dia antes, com pequenos saques de um misturador de criptomoedas. No dia 29, o código do ataque foi testado horas antes de rodar. Por volta das 20h (horário UTC), carteiras da Binance no XRP Ledger enviaram 233 milhões de XRP para um único endereço. Na meia hora seguinte, as carteiras quentes de outras redes foram esvaziadas, incluindo uma única transação de US$ 2,5 bilhões em ether. Uma segunda leva atingiu Avalanche e Polygon no fim da noite.

A leitura dos registros na blockchain sugere que o invasor não roubou as chaves: ele conseguiu dar ordens à própria infraestrutura de assinatura da corretora. Em outras palavras, o sistema assinou e enviou as transferências porque o pedido chegou de dentro, por um caminho que deveria ser confiável.

A resposta foi rápida em uma frente: a Tether bloqueou mais de 1 bilhão de dólares em USDT na carteira principal do atacante em menos de 40 minutos, e a Circle congelou mais de 800 milhões em USDC. Mesmo assim, mais de US$ 3 bilhões seguem fora do alcance dos emissores. Os números ainda são preliminares e variam entre as fontes.

Este é o segundo grande caso do mercado cripto em poucas semanas. Em setembro já tínhamos analisado o que os hacks de setembro revelam sobre risco e governança.

Não foi só a Binance: governos também caíram em outubro

Na mesma semana, três órgãos públicos confirmaram incidentes graves:

  • Moldávia: entre 19 e 23 de outubro, dados ligados a cerca de 750 mil números de identificação pessoal foram extraídos dos serviços digitais do Estado. O governo desligou 82 serviços públicos e mais de 30 sistemas para conter o ataque. A agência responsável disse que serviços estavam acessíveis sem autenticação.
  • Estados Unidos (Departamento de Segurança Interna): um grupo publicou dados de mais de 40 mil funcionários e terceirizados. O invasor diz que os registros vieram do sistema de login único usado pelo órgão. A fornecedora do login nega ter sido invadida, e o caminho de entrada não foi esclarecido.
  • Flórida (Departamento de Educação): o portal de auxílio estudantil sofreu acesso não autorizado identificado em 19 de outubro, com possível exposição de dados de 4,9 milhões de pessoas, incluindo números do Seguro Social.

O padrão se repete: credencial, acesso e configuração. Em nenhum desses casos o problema confirmado foi uma criptografia quebrada. Foi uma porta aberta ou uma chave confiável demais.

Por que isso é um alerta para quem contrata sistema feito com IA

Ataques como o da Binance são feitos por equipes profissionais, financiadas, que ensaiam antes de agir e lavam o dinheiro em minutos. Do outro lado, o mercado vive uma onda de sistemas criados com vibe coding: a pessoa descreve o que quer para uma IA, aceita o código gerado e publica, sem ler, revisar ou entender o que foi entregue.

A IA escreve código rápido, e isso tem valor. O problema é quem contrata: muitas empresas estão entregando o sistema que guarda clientes, pedidos, pagamentos e dados pessoais a fornecedores ou profissionais que não sabem avaliar o que a IA escreveu. Sem base em infraestrutura, programação, segurança e arquitetura, ninguém percebe que o sistema funciona na demonstração e está aberto para qualquer um na internet.

E a mesma tecnologia que gera código em minutos também ajuda a vasculhar código em minutos. O custo de achar uma falha caiu para quem ataca. Uma falha básica deixou de ser um risco teórico e virou alvo de varredura automática.

Os casos de vibe coding que já deram errado neste ano

  • Moltbook, em janeiro: uma rede social de agentes de IA, construída com ferramentas de IA, teve expostos 1,5 milhão de tokens de acesso a APIs e 35 mil e-mails poucos dias após o lançamento. A causa foi um banco de dados Supabase configurado sem regras de segurança por linha.
  • Lovable, de março a abril: uma falha de autorização na plataforma permitia que um usuário gratuito lesse código-fonte, perfil e credenciais de banco de outros projetos com poucas chamadas de API. A falha ficou aberta por 48 dias depois de reportada. A empresa contesta e diz que não houve vazamento.
  • Vulnerabilidades catalogadas: pesquisadores do Georgia Tech contaram 35 vulnerabilidades oficiais (CVEs) causadas por código gerado por IA só em março, contra 6 em janeiro, e estimam que o número real seja muito maior.

As falhas mais comuns em sistema feito só no vibe coding

São quase sempre as mesmas, e todas são invisíveis para quem só testa clicando nas telas:

  1. Chave de API ou senha de banco dentro do código do navegador, onde qualquer visitante consegue ler.
  2. Banco de dados sem regra de acesso: o sistema mostra só os seus pedidos na tela, mas a API devolve os pedidos de todo mundo.
  3. Autorização que confere o login, mas não o dono do dado: basta trocar um número na URL para ver o cadastro de outro cliente.
  4. Webhooks de pagamento sem verificação de assinatura: alguém simula a confirmação de um pagamento que nunca existiu.
  5. Segredos no repositório e servidor com tudo exposto: painel administrativo, porta do banco e logs abertos para a internet.
  6. Nenhum log, backup testado ou plano de resposta: quando o incidente acontece, ninguém sabe o que saiu nem desde quando.

No Brasil, cada item dessa lista envolve dados pessoais e, portanto, a LGPD. Vazamento por falha básica não é azar, é falta de cuidado que a lei cobra. Veja como preparar o site da sua empresa para coletar dados com segurança.

Profissional que usa IA × vibe coding sem base técnica

PontoProfissional que usa IAVibe coding sem base técnica
Código geradoLido, revisado e entendido antes de ir ao arAceito porque "funcionou"
ArquiteturaDefinida antes: o que fica no servidor, o que fica no navegadorO que a IA decidiu no momento
Acesso a dadosRegra por usuário e por registro, testadaConfia na tela para esconder o dado
Segredos e chavesNo servidor, com rotação e permissão mínimaNo código, no repositório, no navegador
InfraestruturaServidor fechado, backup testado, monitoramentoConfiguração padrão de quem criou a conta
Quando der problemaSabe onde olhar e o que desligarPede para a IA "consertar" e torce

A diferença não é usar ou não usar IA. Nós usamos IA todos os dias. A diferença é ter alguém que assume a responsabilidade técnica pelo que vai para produção.

7 perguntas para fazer antes de contratar um sistema

  1. Quem revisa o código gerado por IA antes de ir ao ar, e com qual critério?
  2. Onde ficam as chaves de API, senhas de banco e tokens de pagamento?
  3. Como o sistema garante que um cliente não veja o dado de outro?
  4. Em que servidor o sistema roda, quem administra e quem aplica as atualizações de segurança?
  5. Existe backup automático? Quando foi o último teste de restauração?
  6. Quais acessos ficam registrados em log, e por quanto tempo?
  7. Se houver um incidente numa sexta à noite, quem atende e qual é o primeiro passo?

Se as respostas forem vagas, o preço baixo está cobrando a conta em outro lugar. Para comparar fornecedores com critério, veja software house, freelancer ou equipe interna: como decidir com segurança e como escolher uma software house com critério.

Já tem um sistema feito assim? Por onde começar

  1. Procure segredos expostos: abra o sistema no navegador, veja o código carregado e o repositório. Chave encontrada é chave a ser trocada imediatamente.
  2. Teste o acesso entre usuários: crie duas contas e tente ver o dado de uma pela outra, trocando identificadores na URL e nas chamadas de API.
  3. Revise as regras do banco: em serviços como Supabase e Firebase, confirme se as regras de acesso estão ligadas em todas as tabelas.
  4. Feche o servidor: só as portas necessárias abertas, painel administrativo protegido e atualizações em dia.
  5. Ligue logs e backup: e faça um teste de restauração de verdade.
  6. Peça uma revisão técnica independente de quem não escreveu o sistema.

Perguntas frequentes

A Binance foi hackeada por causa de vibe coding?

Não há nenhuma indicação disso. Pelo que foi divulgado até agora, a entrada teria sido o notebook de um engenheiro e o abuso de um serviço interno. O ponto é outro: se uma empresa desse porte cai pela infraestrutura do dia a dia, um sistema sem nenhuma revisão técnica está muito mais exposto.

Os clientes da Binance vão perder dinheiro?

A Binance afirma que os fundos dos usuários estão seguros e que vai cobrir todas as perdas com o fundo SAFU e recursos próprios. Os saques foram suspensos temporariamente em algumas redes como precaução.

Vibe coding é sempre ruim?

Não. Para protótipo, teste de ideia ou ferramenta interna sem dados sensíveis, pode ser ótimo. O risco aparece quando o código vai para produção com dados de clientes, pagamentos ou integrações, sem que ninguém com base técnica revise.

Como saber se o meu fornecedor usa IA sem revisão?

Faça as 7 perguntas acima. Quem revisa de verdade responde com nomes, ferramentas e processos. Quem não revisa responde que "o sistema é seguro" sem dizer como.

Sistema feito com IA é seguro?

Pode ser, desde que alguém com conhecimento de segurança, infraestrutura e arquitetura defina a estrutura, revise o código e mantenha o servidor. A segurança vem do processo, não da ferramenta que escreveu o código.

Tecnologia rápida, com responsabilidade técnica

Usamos IA para entregar mais rápido, com código revisado, arquitetura definida antes da primeira linha e servidor administrado por quem responde por ele. É assim que fazemos o desenvolvimento de sistemas web e a gestão de servidores cloud de alta performance. Se o seu sistema foi feito às pressas e você quer saber o tamanho do risco, fale com a nossa equipe.

Fontes

Gostou do conteúdo?

Fale com nossos especialistas e descubra como podemos transformar o digital da sua empresa.