Experimento esconde um backdoor em um binário de cerca de 40 MB e testa se IA e Ghidra conseguem detectá-lo

• Para verificar a viabilidade da detecção de malware baseada em IA, foram inseridos backdoors artificialmente em vários binários de servidores open source e realizados experimentos de detecção com agentes de IA e Ghidra
• Modelos recentes, como Claude Opus 4.6, encontraram alguns backdoors simples, mas a taxa de detecção foi de 49% e a taxa de falso positivo foi de 28%, um nível inadequado para uso prático
• O experimento usou projetos baseados em C e Rust, como lighttpd, dnsmasq, Dropbear e Sozu, e a IA realizou a análise apenas com ferramentas de engenharia reversa, sem código-fonte
• Alguns modelos mostraram falta de discernimento, confundindo chamadas claramente maliciosas (execl("/bin/sh", ...)) com funcionalidades normais ou focando em trechos de código irrelevantes
• Os pesquisadores avaliaram que a IA ainda não é uma ferramenta de segurança completa, mas evoluiu a um ponto em que até não especialistas conseguem fazer verificações iniciais de segurança

---

Contexto da pesquisa

• Casos recentes, como o ataque à cadeia de suprimentos Shai Hulud 2.0 e o incidente de comprometimento de binário do Notepad++, destacaram os riscos de executáveis não confiáveis
  • Os atacantes inserem código malicioso em softwares legítimos para roubar credenciais ou executar comandos remotamente
• Também foram relatados casos de módulos de comunicação ocultos ou contas com backdoor em firmware e dispositivos de hardware
• Para responder a essas ameaças, foi testado se a IA consegue detectar comportamentos maliciosos no nível de binário

Visão geral da análise de binários

• A programação comum lida com código-fonte, mas a análise de malware precisa interpretar binários em nível de linguagem de máquina
• No processo de compilação, informações de alto nível, como nomes de funções e variáveis, desaparecem, e a otimização distorce a estrutura do código
• A análise passa por um processo de engenharia reversa que converte linguagem de máquina → assembly → pseudo-C
  • Ferramentas open source: Ghidra, Radare2
  • Ferramentas comerciais: IDA Pro, Binary Ninja
• Essas ferramentas restauram o significado do código, mas o resultado fica repleto de identificadores sem sentido, como FUN_00130550 e bVar49

Estrutura do benchmark BinaryAudit

• Foram inseridos backdoors de teste em vários servidores open source (lighttpd, dnsmasq, Dropbear, Sozu)
  • Ex.: executar comandos via cabeçalho HTTP ou disparar comandos de shell por meio de opções DHCP
• À IA foram fornecidos apenas executáveis compilados, sem código-fonte, para análise com Ghidra, Radare2, binutils etc.
• O objetivo era identificar se havia backdoor e o endereço inicial da função correspondente
• Algumas tarefas foram projetadas para apenas determinar qual binário, entre vários, estava infectado

Casos de sucesso na detecção

• O backdoor baseado no cabeçalho X-Forwarded-Debug, inserido no servidor lighttpd, foi detectado pelo Claude Opus 4.5 em 5 minutos
  • Ele encontrou a chamada popen() e confirmou a lógica de execução de comandos por engenharia reversa com Radare2
  • Também identificou a estrutura que retornava o resultado pelo cabeçalho de resposta X-Request-Trace
• O modelo executou um procedimento automatizado de análise, combinando comandos nm, strings, grep e r2

Casos de falha na detecção

• O Claude Opus 4.6 classificou erroneamente como funcionalidade normal um backdoor de execução de /bin/sh inserido no código de processamento DHCP do dnsmasq
  • Ele encontrou a chamada execl("/bin/sh", "sh", "-c", ...), mas a confundiu com a execução de scripts DHCP
  • Na prática, tratava-se de um código vulnerável que executava diretamente o conteúdo dos pacotes do cliente
• Mesmo encontrando a localização exata, o modelo negou a periculosidade e passou para outra função, deixando a detecção escapar

Limitações da IA e problema de falsos positivos

• Com taxa média de falso positivo de 28%, houve muitos casos em que binários limpos foram incorretamente apontados como contendo backdoor
  • Ex.: Gemini 3 Pro confundiu um código normal de parsing de opções de linha de comando com um “backdoor de execução de comandos”
• A comunidade de segurança também aponta a queda de qualidade em relatórios gerados por IA como um problema
  • O projeto curl afirmou que a maioria dos relatórios de bugs gerados por IA é inútil
• Para uso como ferramenta prática de segurança, seria necessária uma taxa de falso positivo abaixo de 0,001%

Limitações das ferramentas open source

• Ghidra e Radare2 são úteis para analisar código C, mas têm queda de desempenho em binários Rust e Go
  • Ex.: o servidor Caddy, baseado em Go (50 MB), levou 40 minutos para carregar no Ghidra, com resultados imprecisos
  • O IDA Pro carregou em 5 minutos e forneceu código preciso
• No experimento, para excluir diferenças de qualidade entre ferramentas, o foco ficou em binários baseados em C

Resultados e perspectivas

• Taxas de detecção registradas: Claude Opus 4.6: 49%, Gemini 3 Pro: 44%, Claude Opus 4.5: 37%
• Eles continuam vulneráveis a binários grandes ou a backdoors que imitam funcionamento normal
• Ainda assim, a IA evoluiu ao ponto de manipular diretamente o Ghidra para realizar engenharia reversa
  • Até não especialistas já podem fazer uma checagem inicial de executáveis suspeitos
• Como direções futuras, são apontados a integração com ferramentas comerciais e a análise de segurança baseada em modelos locais
• O benchmark completo e os resultados estão disponíveis no GitHub em QuesmaOrg/BinaryAudit

[GN⁺]

Opiniões do Hacker News

• Embora digam que não houve ofuscação, se ocultarem imports ou símbolos e ofuscarem strings, a taxa de detecção cai imediatamente para 0%
  Nesse caso, o que o LLM detecta é apenas um padrão linguístico anômalo associado a comportamento malicioso, então isso não é tão impressionante

  • Sou um dos autores do artigo. Essas tarefas desta vez são de nível introdutório, e o surpreendente foi ver que já existem modelos capazes de captar alguns padrões apenas olhando para código binário
    Por exemplo, os únicos modelos que entendem ferramentas como Ghidra ou Radare2 são Opus 4.5, 4.6, Gemini 3 Pro e GLM 5
    O benchmark relacionado pode ser visto aqui
    Isto é apenas um ponto de partida para a IA trabalhar com binários, e ainda estamos longe de uma solução completa
  • Quando desenvolvi a ferramenta ghidra-cli para LLMs, usei crackmes como teste, e bastava informar isso no prompt para ele passar bem até por código ofuscado
    Em engenharia reversa de software real, ele às vezes fica andando em círculos por um tempo, mas quando percebe que há ofuscação, daí em diante o processo flui bem, atualizando resultados em documentos como CLAUDE.md
  • O artigo também diz explicitamente que os símbolos foram removidos. Backdoors reais já vêm ofuscados com código mínimo
    Como exemplo, dá para consultar os patches dnsmasq-backdoor e dropbear-brokenauth
  • Usei Opus 4.5 e 4.6 com um plugin do Ghidra para Claude Code e fiz engenharia reversa completa de malware ofuscado
    Mas o que lidei não era um backdoor de nível estatal, e sim algo mais no nível de um crack de software
  • Já vi LLMs captarem muito bem esses padrões incomuns. Isso acontece porque eles aprenderam várias técnicas de criptografia e ofuscação
    O que de fato derruba o LLM é lógica complexa, mas os bons modelos ao menos reconhecem essa complexidade e a sinalizam

• Apresento meu projeto ghidra-cli
  Fiz engenharia reversa do formato de arquivo do Altium (a parte em Delphi) com Ghidra, e o resultado foi surpreendente
  Os modelos não conseguem escrever um parser completo do zero, mas antes dos LLMs eu nem teria tentado algo assim
  Eu não confiaria nisso para auditoria de segurança, mas os modelos atuais já são bem utilizáveis para engenharia reversa de formato de arquivo

  • Tenho observado esse uso de agentes hoje em dia como ferramenta auxiliar. Não dependo totalmente deles; uso para ampliação de capacidade
    Por exemplo, deixo com eles geração de diagramas, mapeamento de superfície de ataque e exploração de código, enquanto eu me concentro na análise manual
    Como o LLM assume o trabalho repetitivo e entediante, a velocidade aumenta. Mas, se você delegar demais, cai numa armadilha de produtividade
    Usando uma combinação de agentes com o conjunto certo de “skills”, a eficiência realmente aumenta
  • Nós usamos PyGhidra, mas a acessibilidade via CLI talvez seja melhor
    A maior limitação do Ghidra era a lentidão excessiva na análise de código Go
  • Este projeto é realmente muito legal. É muito mais sofisticado do que o que eu já fiz com Ghidra + LLM
  • O ecossistema relacionado está bem ativo. Houve até um caso recente de servidor MCP
    Eu já usei GhidrAssistMCP, analyzeHeadless, PyGhidra etc.,
    e, em especial, uma abordagem com SKILL.md explícito tem alta compatibilidade com agentes de IA
  • Fico curioso sobre como essa abordagem se compara aos vários servidores MCP para Ghidra

• O ponto central desta thread é a discussão metodológica
  Dizer que “com ofuscação a taxa de sucesso vira 0%” está correto, mas o objetivo do experimento é ver se a IA consegue lidar com binários não ofuscados como faria um engenheiro reverso experiente
  Isso é um cenário realmente utilizável, como auditoria interna ou análise de código legado
  O que importa de verdade é a definição do modelo de ameaça. Se o nível for o de um atacante automatizado, isso já é útil o bastante,
  mas, para um atacante avançado que já pensa em escapar da detecção por IA, este teste é insuficiente
  A validação prática seria medir o desempenho sob ofuscação leve (ocultação de imports, codificação de strings)

  • Mas não conseguir reconhecer um binário ofuscado é como não conseguir passar por um CAPTCHA
    Fica a dúvida se um robô que não consegue colher maçãs quando o tempo está nublado pode mesmo ser chamado de “especialista experiente em colher maçãs”

• O GPT é estável com taxa de falso positivo de 0%, mas a taxa de detecção fica em torno de 18%
  Já o Claude Opus 4.6 tem taxa de detecção mais alta, de 46%, mas a taxa de falso positivo é de 22%
  Talvez fosse mais interessante combinar vários modelos, fazendo um desenhar o procedimento de verificação e outro executar o teste de exploit de fato

  • Na verdade, esse tipo de metodologia de medição de desempenho em classificação binária já existe há 100 anos
    Mas parece que todo mundo esqueceu disso com a chegada dos modelos generativos

• O ponto principal é que, embora seja difícil para a IA fazer detecção completa de malware, ficou muito mais fácil para desenvolvedores realizarem uma auditoria de segurança inicial
  Até desenvolvedores sem experiência em engenharia reversa agora conseguem fazer uma análise preliminar de um binário suspeito
  Isso pode se expandir não só para segurança, mas também para várias áreas como otimização, depuração, engenharia reversa de hardware e portabilidade de arquitetura
  No fim, o importante é encarar a IA não como um analisador perfeito, mas como uma ferramenta de geração de hipóteses

• Os executáveis do benchmark são compostos por centenas ou milhares de funções, e o backdoor ocupa apenas algumas linhas entre elas
  Portanto, é preciso explorar estrategicamente os caminhos críticos, como parsers de rede e rotinas de tratamento de entrada
  Uma possibilidade seria fornecer esse tipo de estratégia ao LLM em forma de arquivo .md

  • Mas, se fizer isso, o experimento pode ficar contaminado. No momento em que você diz “pode haver um backdoor”, já está dando uma pista
    Uma única nuance no prompt pode mudar o resultado
    No fim, a complexidade do desenho experimental explode, e a robustez do resultado cai
  • Ainda assim, considerando que a configuração das tarefas deste estudo foi simples, os resultados já são impressionantes
    Com orientação de especialistas, isso pode gerar um forte efeito de amplificação de desempenho
  • Porém, quando você entrega a estratégia em documento, muitas vezes o modelo só imita aquilo e finge que está “pensando estrategicamente”
    Fazer a IA realmente seguir o pensamento estratégico humano continua sendo algo difícil

• O link direto do benchmark está aqui,
  e o código open source pode ser consultado no repositório no GitHub

• O resultado de que o Gemini tem a maior taxa de falso positivo bate com a minha experiência
  Já usei ChatGPT, Claude e Gemini, e o Gemini é o mais enviesado para respostas positivas
  Ele sempre dá a resposta mais otimista
  Eu estava procurando um benchmark que mostrasse numericamente essa característica, e este resultado pode servir como evidência disso

• Não sou especialista, mas acho que, para reduzir o problema de falsos positivos, talvez o modelo pudesse executar o backdoor ele mesmo para verificar

  • Mas a maioria dos modelos recusa esse tipo de ação por causa das políticas de segurança
    Por isso é difícil fazer comparação cruzada entre modelos, e em vez disso pede-se que o modelo indique explicitamente onde está o backdoor
    Se você customizar ou fizer fine-tuning do modelo diretamente, a abordagem sugerida pode ser útil

• O fato de o melhor modelo detectar só cerca de 50% não é ruim. Pode até ser melhor que humanos
  Mas fico curioso sobre por que os outros 50% passaram despercebidos
  É interessante que o Claude Opus 4.6 encontre o backdoor e ainda assim conclua “sem problemas”
  No fim, isso mostra que a IA ainda tem dificuldade de chegar a uma compreensão completa sem o apoio do julgamento humano