 |
| Bellacosa Mainframe e um dos maiores ataques cibernéticos de sempre bilhões em criptomoedas roubadas |
☕ UM CAFÉ NO BELLACOSA MAINFRAME
O ASSALTO DE US$ 6,3 BILHÕES: AKANE TSUNEMORI CONTRA O CRIME PERFEITO NA BINANCE!
O dia em que uma entrevista de emprego falsa, uma inteligência artificial comprometida e algumas permissões digitais colocaram bilhões de dólares nas mãos dos criminosos.
Bellacosa Mainframe — Arqueologia da Computação, COBOL, Segurança Cibernética e os Fantasmas dos Sistemas Financeiros
🎬 Prólogo — O dia em que o Sistema Sibyl deixou escapar US$ 6,3 bilhões
29 de outubro de 2026.
Imagine uma sala de operações iluminada por dezenas de monitores. Gráficos financeiros atravessam as telas, algoritmos analisam movimentos suspeitos e sistemas automatizados processam transações em velocidades impossíveis para qualquer ser humano.
Tudo parece funcionar.
Até que um alarme aparece.
Uma carteira digital acaba de movimentar uma quantidade gigantesca de criptomoedas para um endereço desconhecido.
Outro alarme.
Mais uma transferência.
E outra.
Em apenas quatro minutos, 233,46 milhões de XRP saem de cinco carteiras conectadas à internet.
A equipe de segurança começa a investigar. Entretanto, as transferências não autorizadas continuam.
Em algum lugar da ficção científica japonesa, a inspetora Akane Tsunemori, protagonista de Psycho-Pass, observaria os acontecimentos com uma pergunta desconfortável:
— Se o sistema era tão inteligente, por que não conseguiu impedir o crime?
Na nossa dramatização, Akane não está diante de um criminoso empunhando uma arma. Tampouco de um assaltante mascarado atravessando a porta de um banco.
Seu adversário é invisível.
Ele usa credenciais legítimas, computadores comprometidos, ferramentas de desenvolvimento e mecanismos criptográficos de autorização.
E o mais perturbador: parte da preparação começou meses antes.
O resultado seria um episódio envolvendo aproximadamente US$ 6,34 bilhões em ativos digitais, segundo o relatório preliminar da Binance.
É um valor que coloca o incidente entre os maiores roubos financeiros já documentados.
Mas seria correto chamá-lo de maior roubo a banco da história?
Em sentido estrito, a Binance não é um banco tradicional. É uma plataforma de negociação e custódia de criptoativos. Também precisamos distinguir o valor total de ativos afetados, a perda efetivamente irrecuperável e os recursos posteriormente congelados.
Apesar dessas ressalvas, o episódio representa uma ruptura histórica na escala dos assaltos digitais.
E Akane tem uma nova investigação.
Seu primeiro suspeito não é uma pessoa. É a confiança excessiva depositada na tecnologia.
Capítulo I — Quem é Akane Tsunemori e por que ela deveria investigar esse crime?
Para compreender nossa investigação, precisamos visitar o Japão distópico de Psycho-Pass.
Na história, a sociedade é supervisionada pelo Sistema Sibyl, uma infraestrutura tecnológica capaz de avaliar o estado psicológico dos cidadãos e estimar seu potencial de criminalidade.
O chamado coeficiente de criminalidade influencia a forma como as autoridades tratam cada indivíduo.
A promessa parece irresistível: detectar o perigo antes que ele se transforme em crime.
A inspetora Akane Tsunemori começa sua carreira acreditando na importância da ordem pública, mas gradualmente descobre que nenhum sistema automatizado está acima do questionamento humano.
Sua grande virtude não é obedecer cegamente às máquinas.
É reconhecer que o julgamento ético, a responsabilidade e a investigação continuam necessários, mesmo quando a tecnologia parece infalível.
Essa característica torna Akane uma excelente tutora para nossa análise.
Imagine o Sistema Sibyl conectado à infraestrutura financeira de uma grande corretora.
Ele analisa milhões de operações, identifica comportamentos suspeitos e calcula pontuações de risco.
Entretanto, os criminosos não precisam necessariamente derrotar o algoritmo.
Podem conseguir que alguém execute um programa contaminado.
Podem roubar uma credencial.
Podem comprometer uma ferramenta aparentemente confiável.
Podem explorar uma autorização que o sistema já considera válida.
Eis o paradoxo central desta investigação:
Um sistema pode executar perfeitamente uma instrução que jamais deveria ter sido autorizada.
A inteligência do sistema não elimina a necessidade de controles independentes.
Esta também é uma das grandes lições de Psycho-Pass: segurança e justiça não são sinônimos de confiança absoluta em mecanismos automatizados.
Capítulo II — Junho de 2026: a primeira armadilha estava escondida numa ferramenta de IA
Nossa cronologia começa em junho de 2026.
Um profissional da equipe Wallet DevOps da Binance procurava instalar uma ferramenta de programação assistida por inteligência artificial.
Nada aparentemente extraordinário.
Programadores utilizam ferramentas de IA para entender códigos, localizar erros, escrever testes e acelerar tarefas repetitivas.
Entretanto, segundo o relatório divulgado pela Binance, o engenheiro encontrou uma instalação adulterada associada ao Homebrew, conhecido gerenciador de pacotes usado em ambientes macOS.
A instalação comprometeu o computador.
A equipe de segurança percebeu a atividade anormal, substituiu o dispositivo e realizou a rotação das credenciais relacionadas.
Até aqui, poderíamos imaginar que o problema estava resolvido.
Mas existe uma diferença entre eliminar um programa malicioso e eliminar todas as consequências de sua execução.
Durante o comprometimento, os invasores obtiveram informações sobre a função do profissional e sobre colegas associados à infraestrutura de carteiras.
Essas informações eram valiosas.
Não necessariamente porque continham a chave de um cofre digital, mas porque ajudavam a identificar quem trabalhava perto desse cofre.
🔎 Curiosidade: o ataque começa muito antes do roubo
Nos filmes, o assaltante estuda os horários dos guardas, observa os veículos blindados e identifica a localização das câmeras.
No crime cibernético, o equivalente pode envolver nomes de equipes, ferramentas utilizadas, relações profissionais e privilégios técnicos.
Conhecer o organograma de uma organização pode facilitar a seleção de novos alvos.
A esse estágio chamamos, genericamente, de reconhecimento.
Não é correto afirmar que todo o planejamento posterior já estivesse definido em junho. O que sabemos é que essa etapa forneceu aos atacantes uma oportunidade de coleta de informações.
Akane examinaria o caso e faria uma observação simples:
— Um computador pode ser substituído. Mas o conhecimento obtido pelo adversário não desaparece automaticamente.
A lição para o programador COBOL
Imagine que você trabalha em uma instituição financeira, desenvolvendo programas COBOL com VS Code e extensões relacionadas ao IBM Z.
Você encontra uma ferramenta prometendo:
Compilar programas automaticamente.
Interpretar mensagens de erro do COBOL.
Gerar JCL com inteligência artificial.
Analisar programas antigos.
Acelerar a conexão com ambientes z/OS.
Parece excelente.
Entretanto, antes de instalar, você precisa verificar a procedência do software, o editor responsável, as permissões solicitadas e sua aprovação no ambiente corporativo.
Um plugin comprometido pode colocar em risco não apenas seu computador, mas também tokens de acesso, repositórios e sessões autenticadas.
A regra é simples:
Uma ferramenta útil não se torna confiável apenas porque aparece nos primeiros resultados de uma pesquisa.
Capítulo III — Setembro: a entrevista de emprego que nunca existiu
Chegamos à parte mais cinematográfica da história.
Em setembro de 2026, outro engenheiro recebeu contato de alguém que se apresentava como diretor de projetos de uma empresa.
A abordagem ocorreu por uma plataforma legítima de busca de emprego.
O profissional participou de uma entrevista com uma suposta representante de recursos humanos.
Depois veio uma segunda conversa, agora com alguém que dizia ser o presidente-executivo da empresa.
A organização era fictícia.
Mas o processo seletivo havia sido construído para parecer real.
Ao final, o candidato recebeu um desafio técnico.
Precisaria baixar um repositório de código e realizar uma atividade de programação.
Quem já participou de processos seletivos em tecnologia conhece esse procedimento.
É comum que empresas solicitem exercícios de lógica, correção de programas ou desenvolvimento de pequenas aplicações.
O problema é que aquele repositório continha código malicioso.
Durante sua preparação, o projeto executava componentes capazes de comprometer o computador.
O relatório preliminar da Binance descreve técnicas de ofuscação, evasão de ferramentas de segurança e substituição de um componente legítimo de desenvolvimento por uma versão maliciosa.
A genialidade perversa da engenharia social
Os criminosos não começaram pedindo senhas.
Eles construíram credibilidade.
Primeiro, uma abordagem profissional.
Depois, uma entrevista.
Em seguida, uma figura de autoridade.
Finalmente, uma atividade aparentemente comum.
O ataque explorou uma característica humana: tendemos a confiar mais em solicitações que aparecem dentro de um processo coerente.
Em Psycho-Pass, um dos temas recorrentes é a diferença entre aparência, intenção e comportamento.
No mundo real, a mesma diferença existe entre uma mensagem profissional e uma ação autorizada.
Uma conversa educada não prova que uma empresa existe.
Uma chamada de vídeo não garante a identidade do interlocutor.
Um repositório bem documentado não garante que seu código seja seguro.
Easter egg — O teste técnico de Akane
Imagine Akane recebendo um desafio:
Desenvolva um programa COBOL capaz de processar pagamentos de clientes. Para começar, execute o instalador disponibilizado pelo nosso recrutador.
Ela provavelmente faria uma pergunta antes de tocar no teclado:
— Por que um teste de lógica de programação precisa executar componentes desconhecidos no meu computador corporativo?
Essa pergunta, aparentemente trivial, poderia interromper toda a cadeia de comprometimento.
Desconfiança técnica bem fundamentada não é paranoia. É disciplina profissional.
Capítulo IV — 20 de outubro: quando a ferramenta de IA se tornou parte do caminho de ataque
No dia 20 de outubro, os invasores avançaram.
Segundo a Binance, utilizaram o computador comprometido durante o falso processo seletivo e uma ferramenta interna de IA para alcançar ambientes associados a outros dois engenheiros da equipe de carteiras.
Entre as descobertas estava um token com permissões de implantação de contêineres.
Para um iniciante, isso talvez pareça apenas um detalhe.
Mas vamos traduzir.
Um contêiner é uma forma de empacotar e executar aplicações com seus componentes e dependências em um ambiente controlado.
Ferramentas de implantação permitem colocar esses componentes em funcionamento.
Se um invasor consegue abusar de credenciais de implantação, pode tentar introduzir código não autorizado em ambientes que confiam nessa infraestrutura.
Isso transforma um problema de estação de trabalho em um problema de cadeia de desenvolvimento.
O que a inteligência artificial fez?
É importante evitar uma conclusão sensacionalista.
O relatório não demonstra que uma IA desenvolveu consciência, escolheu assaltar uma corretora ou decidiu roubar bilhões.
O que foi descrito é o comprometimento e abuso de uma ferramenta interna de IA como parte do caminho utilizado pelos invasores.
A diferença é enorme.
Um assistente inteligente pode integrar diferentes recursos técnicos. Dependendo de suas permissões, ele pode consultar repositórios, acessar arquivos, interagir com ferramentas e executar operações autorizadas.
Se seu ambiente for comprometido, algumas dessas integrações podem ampliar os efeitos do ataque.
Quanto maior a capacidade de uma ferramenta automatizada, maior a importância de limitar seus privilégios.
O paralelo com o IBM Mainframe
Imagine uma ferramenta de IA conectada a um ambiente corporativo de desenvolvimento IBM Z.
Ela consegue consultar programas COBOL, sugerir alterações e preparar execuções de testes.
Até aqui, tudo bem.
Mas seria realmente necessário que a mesma ferramenta também pudesse alterar programas de produção, submeter jobs críticos e acessar credenciais administrativas?
Provavelmente não.
Um desenho de segurança adequado deve separar:
Ambiente de desenvolvimento, onde experimentamos.
Ambiente de homologação, onde validamos.
Ambiente de produção, onde operações reais acontecem.
Além disso, a identidade utilizada para uma função não deveria receber automaticamente acesso às demais.
Akane chamaria isso de um princípio de responsabilidade.
Nós, profissionais de segurança, chamamos de menor privilégio e segregação de funções.
Capítulo V — 29 de outubro: o cofre começa a esvaziar
Finalmente chegamos ao dia do grande assalto.
Segundo a cronologia divulgada pela Binance, entre 17h15 e 19h56 UTC, o atacante acessou o computador de um dos engenheiros comprometidos e utilizou credenciais obtidas de outro profissional.
A partir desse ambiente, implantou um contêiner e acionou um script malicioso.
Pouco depois, o dinheiro começou a sair.
Entre 20h05 e 20h09 UTC, cinco carteiras conectadas à internet transferiram 233,46 milhões de XRP para um endereço controlado pelo invasor.
Outras operações envolveram aproximadamente 970.500 SOL, 44,2 milhões de OP e 18.270 BTC, além de ativos em Ethereum.
A Binance identificou movimentações anormais e iniciou medidas de contenção.
Entretanto, desligar o serviço normal de saques não resolveu tudo.
A razão é tecnicamente fascinante.
O que é uma hot wallet?
Uma hot wallet é uma carteira de criptoativos conectada a uma infraestrutura que permite operações online.
Ela facilita transferências frequentes.
Por outro lado, precisa ser protegida contra comprometimento de seus mecanismos de autorização.
Já uma cold wallet mantém seus mecanismos sensíveis de assinatura mais isolados de sistemas conectados.
Nenhuma dessas categorias, isoladamente, substitui governança, controle de acesso e procedimentos de resposta a incidentes.
O papel do EIP-7702
Uma das partes mais complexas do ataque envolveu o mecanismo EIP-7702 do Ethereum.
Simplificando bastante, ele permite que determinadas contas deleguem capacidades de execução a código de contratos inteligentes.
A funcionalidade tem usos legítimos.
Entretanto, autorizações maliciosas também podem criar riscos caso um atacante consiga estabelecê-las.
Segundo a Binance, os invasores utilizaram o serviço de assinatura comprometido para criar delegações que permitiram continuar movimentando ativos independentemente da infraestrutura normal de saques.
Isso explica por que suspender saques não interrompeu imediatamente todas as operações.
As autorizações problemáticas já existiam na blockchain.
Era necessário revogá-las na própria rede.
O processo envolvia dificuldades adicionais por causa da arquitetura MPC, na qual operações criptográficas são realizadas por mecanismos multiparticipantes.
Não havia simplesmente uma chave privada única que pudesse ser utilizada imediatamente para resolver a situação.
A última transferência não autorizada foi finalizada às 23h56 UTC.
Às 00h10 UTC de 30 de outubro, a Binance executou uma autorização destinada a limpar a delegação maliciosa da carteira envolvida.
O paradoxo do cofre eletrônico
Imagine que você controla um banco com portas eletrônicas extremamente sofisticadas.
Ao descobrir um invasor, manda desligar o sistema principal.
Mas existe uma autorização previamente concedida a outro mecanismo de abertura, que continua válida mesmo depois do desligamento.
Seu problema não é mais apenas interromper o aplicativo.
É cancelar a autorização independente.
Essa é a lição fundamental:
Desligar um sistema não significa revogar todos os poderes que ele concedeu anteriormente.
Capítulo VI — O maior roubo a banco da história?
A dimensão financeira exige alguns cuidados.
A Binance informou que aproximadamente US$ 6,34 bilhões em ativos digitais foram afetados.
Desse montante, cerca de US$ 2,85 bilhões haviam sido congelados ou interceptados até a atualização de 3 de novembro.
A empresa também afirmou que, até 31 de outubro, havia reposto 98% dos ativos afetados e reservado recursos suficientes para cobrir as perdas.
Essas informações não significam que todo o dinheiro roubado tenha sido recuperado.
Congelar ativos, interceptar movimentações e compensar clientes com recursos próprios são procedimentos diferentes.
Também é necessário considerar que as avaliações de criptoativos variam com o mercado.
Mesmo assim, a escala do caso é extraordinária.
Curiosidade histórica: quando os assaltantes precisavam de caminhões
Em 2003, o Banco Central do Iraque tornou-se protagonista de um episódio envolvendo a retirada de aproximadamente US$ 1 bilhão.
O transporte de enormes quantidades de dinheiro físico exigia pessoal, veículos e operações logísticas.
Na era digital, o problema mudou de natureza.
O transporte deixa de ser o principal obstáculo.
O desafio passa a ser conseguir autorizações válidas para transferir valores.
Não estamos afirmando que todos os crimes financeiros sejam comparáveis juridicamente ou operacionalmente.
Estamos observando uma transformação histórica:
No século XXI, comprometer a autorização pode ser mais importante do que conquistar fisicamente o cofre.
Capítulo VII — Akane entra no CPD: o que o COBOL tem a ver com tudo isso?
Agora vamos entrar no laboratório Bellacosa Mainframe.
Imagine uma instituição financeira que utiliza COBOL para registrar e processar pagamentos.
Um programa recebe dados como:
Número da conta de origem.
Número da conta destinatária.
Valor da transferência.
Identidade do solicitante.
Estado da autorização.
Nosso objetivo é impedir que uma transferência seja aprovada apenas porque os dados parecem formalmente válidos.
Para isso, vamos desenvolver um exemplo didático.
Antes, precisamos compreender quatro conceitos da linguagem.
IDENTIFICATION DIVISION: identifica o programa.
DATA DIVISION: define dados e campos utilizados.
PROCEDURE DIVISION: contém a lógica executável.
IF e EVALUATE: permitem implementar decisões com base em condições.
COBOL é especialmente adequado para ensinar regras de negócio, porque sua sintaxe torna relativamente explícitas as condições aplicadas aos dados.
E uma regra de negócio pode funcionar como uma barreira financeira.
Capítulo VIII — Laboratório prático: construindo o mini-Sibyl bancário em COBOL
Vamos construir o programa AKANERISK.
Ele não pretende prever se alguém é criminoso.
Seu objetivo é muito mais limitado e verificável: classificar uma transação com base em regras objetivas.
Esse detalhe é importante.
A segurança financeira deve avaliar comportamento e contexto, evitando transformar pessoas em suspeitas por características pessoais ou critérios discriminatórios.
Nosso programa receberá três condições:
O valor da transferência.
Se o destinatário foi previamente validado.
Se houve aprovação independente.
Para simplificar, vamos estabelecer um limite didático de R$ 10.000.
Valores superiores exigirão aprovação adicional.
Qualquer destinatário não validado fará a transferência ser bloqueada.
Passo 1 — Criando o programa
>>SOURCE FORMAT FREE
identification division.
program-id. AKANERISK.
environment division.
configuration section.
repository.
function all intrinsic.
data division.
working-storage section.
01 ws-valor pic 9(9)v99 value 0.
01 ws-limite pic 9(9)v99 value 10000.
01 ws-destino-ok pic x value 'N'.
01 ws-aprovacao-ok pic x value 'N'.
01 ws-resultado pic x(12).
01 ws-valor-editado pic z(9)9.99.
procedure division.
display "VALOR EM REAIS: "
accept ws-valor
display "DESTINATARIO VALIDADO? S/N"
accept ws-destino-ok
display "APROVACAO INDEPENDENTE? S/N"
accept ws-aprovacao-ok
move function upper-case(ws-destino-ok)
to ws-destino-ok
move function upper-case(ws-aprovacao-ok)
to ws-aprovacao-ok
evaluate true
when ws-destino-ok not = 'S'
move "BLOQUEADA" to ws-resultado
when ws-valor > ws-limite
and ws-aprovacao-ok not = 'S'
move "EM ANALISE" to ws-resultado
when other
move "AUTORIZADA" to ws-resultado
end-evaluate
move ws-valor to ws-valor-editado
display "VALOR: " ws-valor-editado
display "STATUS: " ws-resultado
goback.O exemplo utiliza sintaxe COBOL de formato livre, disponível em compiladores compatíveis com o recurso.
É um simulador educacional, não um componente pronto para processar dinheiro real.
Passo 2 — Entendendo o campo PIC
Observe:
PIC 9(9)V99
Significa que o campo possui nove posições decimais inteiras e duas posições decimais fracionárias.
O V representa uma posição decimal implícita: ele não ocupa uma posição física no armazenamento.
Essa característica permite representar valores decimais de maneira conveniente para aplicações comerciais.
Em contextos financeiros, precisamos ter extremo cuidado com escala, arredondamento, intervalos válidos e armazenamento.
Passo 3 — Entendendo EVALUATE TRUE
A instrução EVALUATE TRUE permite avaliar diversas condições em sequência.
No nosso exemplo, a primeira condição identifica destinatários que não foram validados.
Se a verificação falhar, a transação recebe o estado BLOQUEADA.
Caso contrário, o programa verifica se o valor supera o limite definido e se existe aprovação independente.
Se essa aprovação estiver ausente, o estado será EM ANALISE.
Caso nenhuma condição impeditiva seja encontrada, o programa classificará a transação como AUTORIZADA.
A ordem das verificações é importante.
Uma condição crítica deve impedir que a operação alcance uma decisão permissiva por engano.
Passo 4 — Executando os primeiros testes
Vamos imaginar três transações fictícias.
Teste A
Valor: R$ 500.
Destinatário validado: S.
Aprovação independente: N.
Resultado esperado: AUTORIZADA.
Teste B
Valor: R$ 50.000.
Destinatário validado: S.
Aprovação independente: N.
Resultado esperado: EM ANALISE.
Teste C
Valor: R$ 100.
Destinatário validado: N.
Aprovação independente: S.
Resultado esperado: BLOQUEADA.
Perceba o detalhe.
Mesmo que exista uma aprovação adicional, um destinatário não validado permanece bloqueado.
Essa prioridade representa uma decisão de segurança incorporada à regra de negócio.
Capítulo IX — O que falta para transformar nosso exemplo em um sistema bancário verdadeiro?
Muita coisa!
Nosso programa demonstra decisões básicas, mas não implementa segurança de produção.
Ele aceita informações digitadas pelo usuário sem verificar se as respostas são autênticas.
Uma pessoa poderia simplesmente informar que recebeu aprovação.
Isso não constitui autorização independente.
Numa arquitetura real, precisaríamos de verificações realizadas por serviços confiáveis e protegidos.
1. Validar a identidade
O sistema precisa saber quem está solicitando a operação.
Não basta receber uma identificação textual.
É necessário autenticar a identidade por mecanismos adequados ao risco.
2. Verificar permissões
Mesmo uma pessoa autenticada não deve necessariamente conseguir movimentar qualquer valor.
Precisamos de autorização baseada em funções, limites e contexto.
3. Validar o destinatário
Uma conta cadastrada ou um endereço previamente aprovado deve ser comparado com dados confiáveis.
O próprio solicitante não pode ser a única fonte dessa confirmação.
4. Exigir autorização independente
Transferências acima de determinados limites podem exigir aprovação de outra pessoa ou de um processo separado.
O aprovador não deveria conseguir ser representado apenas por um campo informado livremente.
5. Registrar evidências
Operações relevantes precisam produzir registros confiáveis.
Esses registros ajudam a investigar incidentes, identificar irregularidades e demonstrar que controles foram executados.
6. Evitar duplicidade de execução
Uma operação financeira precisa de mecanismos para impedir que a mesma solicitação seja executada duas vezes indevidamente.
É o problema das transações repetidas.
7. Garantir consistência
É necessário impedir que o saldo de uma conta seja debitado sem a correspondente operação financeira ser concluída ou compensada corretamente.
Aqui entram conceitos de transações atômicas, consistência e recuperação.
8. Preparar a resposta ao incidente
Uma organização precisa saber o que fazer quando descobre um comprometimento.
Isso inclui suspender operações, revogar acessos, invalidar sessões, preservar evidências e restaurar serviços com segurança.
O caso Binance demonstra que essa resposta deve considerar autorizações que continuam válidas fora da aplicação principal.
Capítulo X — O Sistema Sibyl encontra RACF, CICS e Db2
Vamos trazer nossa investigação para um ambiente IBM Z.
Imagine uma instituição financeira com milhões de contas.
O sistema possui programas COBOL executados por transações CICS e dados armazenados no Db2.
O acesso é controlado por mecanismos de segurança do z/OS, incluindo RACF.
Nessa arquitetura, cada componente cumpre uma função diferente.
RACF: controla identidades e permissões sobre recursos protegidos.
CICS: fornece infraestrutura transacional para aplicações online, incluindo mecanismos de segurança e integração.
Db2: oferece persistência, integridade transacional, controle de concorrência e recursos de auditoria.
SMF: reúne registros operacionais importantes para monitoramento, auditoria e investigação.
JCL e JES2: participam do processamento batch e exigem controles sobre submissão, execução e acesso aos recursos.
z/OS Connect: permite expor e consumir serviços e APIs de forma integrada, exigindo proteção adequada das interfaces.
Essas tecnologias podem integrar uma arquitetura segura, mas nenhuma delas constitui garantia absoluta.
É preciso configurar corretamente políticas, permissões e procedimentos.
Uma transferência bancária hipotética
Imagine uma transferência de R$ 20 milhões.
O sistema recebe o pedido.
A aplicação verifica a identidade do solicitante.
Um serviço de autorização confirma os privilégios.
As regras financeiras exigem aprovação independente.
O sistema valida o destinatário.
Uma rotina verifica limites e comportamento anormal.
O Db2 registra alterações consistentes.
Eventos relevantes são enviados aos mecanismos de auditoria.
Somente depois de todas as verificações o fluxo apropriado permite concluir a operação.
Essa sequência é ilustrativa.
Em ambientes reais, algumas verificações acontecem em etapas diferentes e utilizam múltiplos serviços.
O ponto essencial é impedir que a quebra de uma única barreira ofereça controle total sobre os recursos financeiros.
Segurança não é possuir uma porta blindada. É impedir que uma única chave abra todas as portas.
Capítulo XI — Dez mandamentos de Akane Tsunemori para o programador COBOL
Primeiro: nunca execute código desconhecido no computador corporativo.
Mesmo que a solicitação venha de um recrutador simpático ou de uma empresa aparentemente respeitável.
Segundo: não transforme ferramentas de desenvolvimento em administradores universais.
Plugins, assistentes e automações precisam somente dos privilégios estritamente necessários.
Terceiro: proteja credenciais e tokens.
Não armazene segredos em programas-fonte, repositórios ou arquivos compartilhados sem proteção adequada.
Quarto: separe desenvolvimento e produção.
Seu ambiente de testes não deveria oferecer um caminho irrestrito para operações financeiras reais.
Quinto: aplique controles de aprovação independentes.
Quem escreve uma alteração crítica não precisa necessariamente ser quem autoriza sua implantação.
Sexto: trate toda entrada como não confiável até ser validada.
Isso inclui campos de programas COBOL, parâmetros de jobs, dados recebidos por APIs e arquivos de terceiros.
Sétimo: monitore operações incomuns.
Transferências de grande valor, acessos inesperados e mudanças de comportamento podem justificar investigação.
Oitavo: prepare procedimentos de revogação.
É necessário compreender como cancelar tokens, sessões, privilégios e autorizações concedidas a sistemas externos.
Nono: teste o plano de resposta.
Uma organização não deve descobrir durante o ataque que ninguém sabe interromper determinada operação.
Décimo: preserve o julgamento humano.
Sistemas automatizados devem ajudar a decidir, mas não substituir responsabilidade, investigação e análise crítica.
Akane provavelmente aprovaria esse último mandamento.
Capítulo XII — O lado sombrio da inteligência artificial
Existe outra lição importante no episódio.
A inteligência artificial pode melhorar a defesa cibernética, mas também amplia a quantidade de ferramentas integradas ao desenvolvimento.
Um assistente pode analisar milhares de linhas de COBOL.
Pode sugerir testes.
Pode localizar dependências.
Pode ajudar a documentar um sistema legado.
Entretanto, se ele também tiver permissões excessivas, uma exploração bem-sucedida poderá atingir serviços adicionais.
Isso exige atenção especial a agentes de IA capazes de executar ações.
Um agente que apenas responde perguntas possui um perfil de risco.
Um agente que pode ler repositórios internos apresenta outro.
Um agente autorizado a executar comandos e modificar arquivos apresenta riscos adicionais.
E um agente capaz de realizar alterações em produção exige controles ainda mais rigorosos.
A solução não é abandonar a inteligência artificial.
É aplicar à IA os princípios clássicos de engenharia e segurança:
Autenticação, autorização, menor privilégio, monitoramento, isolamento e revisão independente.
Podemos utilizar tecnologia extremamente moderna sem esquecer lições desenvolvidas ao longo de décadas de processamento empresarial.
Talvez esse seja um dos ensinamentos mais interessantes do mainframe.
A tecnologia muda.
Os princípios fundamentais de integridade e responsabilidade continuam.
Capítulo XIII — Quem estava por trás do ataque?
As autoridades americanas atribuíram o incidente a agentes ligados à Coreia do Norte.
O governo norte-coreano rejeitou a acusação.
É importante distinguir atribuição de inteligência cibernética de uma conclusão judicial definitiva.
Investigadores analisam infraestrutura utilizada, ferramentas, padrões de execução, movimentação de recursos e outros elementos técnicos.
Essas evidências podem sustentar avaliações de autoria, mas nem todos os detalhes ficam publicamente disponíveis.
Outra distinção necessária: o fato de determinado grupo utilizar determinadas técnicas não significa que todos os ataques semelhantes sejam praticados pelo mesmo agente.
Uma entrevista falsa, por exemplo, é um método que pode ser reproduzido por grupos distintos.
A defesa precisa concentrar-se nos mecanismos concretos do ataque.
Isso inclui verificar a identidade de recrutadores, isolar código recebido, proteger credenciais e restringir o acesso aos ambientes críticos.
Akane compreenderia perfeitamente essa distinção.
Investigar significa buscar evidências.
Não significa escolher antecipadamente um culpado e interpretar todos os acontecimentos de acordo com essa conclusão.
Capítulo XIV — O paradoxo do Dominator: quando uma máquina autoriza o que deveria impedir
Em Psycho-Pass, o Dominator é um dispositivo associado ao Sistema Sibyl, que condiciona seu funcionamento à avaliação realizada pela infraestrutura automatizada.
O operador não possui controle absoluto sobre a decisão do equipamento.
Isso cria um dilema profundo: e se a avaliação do sistema estiver equivocada?
No universo financeiro, existe uma versão dessa pergunta.
E se uma transação carregar uma assinatura criptográfica tecnicamente válida, mas tiver sido produzida por um processo comprometido?
A assinatura comprova determinadas propriedades criptográficas.
Não comprova, por si só, que o propósito econômico da operação seja legítimo.
Essa distinção é fundamental.
Um código de retorno bem-sucedido não prova a ausência de fraude.
Uma autenticação válida não garante que o usuário esteja agindo livremente.
Um token autorizado não demonstra que o ambiente que o utilizou esteja íntegro.
E um sistema que executou corretamente suas instruções ainda pode produzir um resultado completamente indesejado.
O verdadeiro princípio de Akane
Não basta perguntar:
"Esta operação foi autorizada pela máquina?"
Precisamos perguntar:
"Como essa autorização foi obtida, por quem, para qual finalidade e sob quais condições?"
Essa mudança de perspectiva transforma a segurança.
Ela obriga arquitetos e programadores a analisar não apenas comandos, mas todo o contexto de confiança.
Capítulo XV — O que aconteceu depois do assalto?
Na atualização divulgada em 3 de novembro de 2026, a Binance informou uma série de ações de resposta.
Entre elas estavam a reconstrução de ambientes afetados, a substituição de dispositivos comprometidos, a invalidação de credenciais e o fortalecimento de controles associados às carteiras digitais.
A empresa também informou ter reconstruído a ferramenta interna de IA afetada e iniciado medidas adicionais de detecção de comportamentos anormais.
Outro ponto importante foi a decisão de contratar especialistas independentes para revisar o incidente.
Essa última providência merece atenção.
Depois de um comprometimento dessa magnitude, não basta declarar que tudo está resolvido.
É necessário investigar as causas, identificar falhas de arquitetura, testar as medidas corretivas e validar se os caminhos utilizados pelos invasores foram efetivamente interrompidos.
A empresa também afirmou que os clientes não suportariam diretamente as perdas decorrentes do episódio.
Entretanto, em 4 de novembro de 2026, a investigação ainda era preliminar.
A reconstrução completa dos acontecimentos e a recuperação definitiva dos ativos continuavam sujeitas a novos resultados.
Capítulo XVI — O exercício final de Akane: você conseguiria impedir o próximo ataque?
Imagine que amanhã você assuma a responsabilidade por um sistema financeiro desenvolvido em COBOL.
O sistema funciona há décadas.
Milhões de transações são processadas diariamente.
Existe integração com aplicações web, APIs, plataformas de automação e ferramentas de inteligência artificial.
Seu desafio não é reescrever tudo.
É descobrir onde uma autorização indevida poderia atravessar a arquitetura.
Comece pelo inventário das aplicações.
Identifique quais programas movimentam valores.
Descubra quais usuários, jobs e serviços conseguem executá-los.
Verifique quais identidades possuem privilégios elevados.
Analise como as alterações são aprovadas e implantadas.
Confira quais integrações externas podem solicitar operações financeiras.
Mapeie como a organização revoga acessos comprometidos.
Depois, desenvolva testes que representem comportamentos não autorizados.
Por exemplo:
Uma transferência acima do limite sem aprovação independente.
Uma operação com destinatário não validado.
Uma tentativa de executar novamente a mesma transação.
Uma solicitação realizada por identidade sem permissão.
Uma mudança de configuração sem autorização.
Uma execução originada de ambiente inesperado.
Para cada teste, registre o resultado esperado.
Se a aplicação permitir a operação indevida, você encontrou uma falha de controle a ser investigada.
Não é necessário simular uma invasão real para aprender.
Um ambiente isolado, dados fictícios e testes bem planejados são suficientes para demonstrar muitos problemas de arquitetura.
A aprendizagem começa quando compreendemos que os controles de segurança precisam falhar de maneira segura.
Epílogo — O crime perfeito não começou com bilhões de dólares
A investigação chega ao fim.
Akane Tsunemori observa a reconstrução dos acontecimentos.
Junho: uma ferramenta adulterada.
Setembro: uma entrevista falsa.
Outubro: computadores comprometidos, credenciais expostas, uma ferramenta interna de IA e mecanismos de autorização explorados.
29 de outubro: bilhões de dólares em ativos digitais movimentados indevidamente.
O que parecia um roubo instantâneo foi precedido por uma campanha construída ao longo de meses.
A conclusão é perturbadora.
Os criminosos não precisaram inventar uma nova linguagem de programação.
Não precisaram destruir fisicamente um centro de dados.
Não precisaram carregar dinheiro em caminhões.
Exploraram relações de confiança entre pessoas, dispositivos, credenciais, serviços e mecanismos de autorização.
E conseguiram converter acessos inicialmente limitados em consequências financeiras gigantescas.
É aqui que a filosofia de Psycho-Pass encontra a engenharia de sistemas.
Não podemos entregar toda a responsabilidade a uma tecnologia, por mais sofisticada que ela seja.
Precisamos compreender suas limitações.
Precisamos investigar suas decisões.
Precisamos impedir que uma única credencial, uma única máquina ou um único serviço concentre poderes capazes de produzir um desastre.
Para o programador COBOL iniciante, essa lição vale mais do que decorar centenas de comandos.
Programar sistemas financeiros é compreender as consequências das operações.
É proteger dados.
É preservar integridade.
É construir verificações que continuem funcionando quando alguma parte do ambiente estiver comprometida.
E, acima de tudo, é reconhecer que a segurança não termina quando o programa compila sem erros.
Ela começa quando perguntamos o que pode acontecer se alguém utilizar corretamente o software para realizar uma operação que nunca deveria ter sido permitida.
Na última cena da nossa dramatização, Akane se aproxima de um terminal IBM 3270.
A tela verde exibe:
TRANSACTION REJECTED - AUTHORIZATION FAILED
Ela observa a mensagem, sorri discretamente e encerra a investigação:
— A melhor operação não é aquela que o sistema consegue executar. É aquela que o sistema sabe quando deve impedir.
No Bellacosa Mainframe, o café termina.
O trabalho dos programadores continua.
Porque o próximo grande assalto talvez não comece com um hacker tentando quebrar uma senha. Pode começar com um convite perfeitamente educado para uma entrevista de emprego.
☕ Easter egg — O número que não deveria existir
Existe uma ironia deliciosa para quem conhece tanto Psycho-Pass quanto os sistemas corporativos.
No anime, um coeficiente pode determinar o tratamento dado a um cidadão.
No nosso laboratório, uma regra numérica pode determinar se uma transação deve ser encaminhada para análise.
Mas a comparação revela uma diferença ética importantíssima.
Pessoas não devem ser reduzidas a números supostamente infalíveis.
Transações, por outro lado, podem e devem ser verificadas com critérios objetivos, auditáveis e proporcionais ao risco.
O programa AKANERISK não precisa conhecer a personalidade, as opiniões ou a vida privada de ninguém.
Precisa apenas verificar as condições necessárias para executar uma operação financeira.
Talvez esse seja o verdadeiro ensinamento escondido nesta aventura:
Uma boa tecnologia não substitui a responsabilidade humana. Ela ajuda a exercê-la melhor.
Referências para aprofundamento
Reuters / UOL — 3 de novembro de 2026
Hackers usaram entrevista de emprego falsa antes de roubo da Binance.
Binance — 3 de novembro de 2026
29 October 2026 Binance Security Incident: Initial Findings and Response Update.
https://www.binance.com/en/blog/community/3229153443759566763
Psycho-Pass — Site oficial
Documentação IBM — IBM Z e Enterprise COBOL
https://www.ibm.com/docs/en/cobol-zos
Observação editorial: artigo baseado nas informações publicamente disponíveis até 4 de novembro de 2026. Os diálogos, a participação de Akane Tsunemori e o laboratório bancário são elementos educativos e ficcionais. O código COBOL não representa a infraestrutura utilizada pela Binance nem implementa um mecanismo de autorização bancária de produção.
Bellacosa Mainframe — Porque todo grande sistema tem uma história, e toda grande história merece uma investigação.
