HalluSquatting transforma alucinação de assistentes de código em via para instalar bots

HalluSquatting transforma alucinação de assistentes de código em via para instalar bots

Pesquisadores demonstram que nomes inventados de forma previsível por agentes de IA, combinados a injeção indireta de prompt e execução autônoma, permitem implantar código controlado pelo atacante em múltiplas estáções.

ComponenteAssistentes de código com capacidade de buscar recursos externos e executar comandos no terminal (Cursor, Windsurf, GitHub Copilot, Cline, Gemini CLI e família OpenClaw)
VetorHalluSquatting: registro antecipado de nomes hallucinados previsíveis em repositórios ou lojas de plugins, com instruções adversárias que chegam por injeção indireta de prompt no conteúdo baixado
ImpactoEm testes controlados, o agente executou código fornecido pelo atacante; com recurso popular, o mesmo nome plantado pode alcançar muitas máquinas e ser usado para montar uma botnet convencional
PrioridadeDesativar modos de execução sem revisão humana, exigir busca/verificação do recurso real antes do fetch e validar nomes sugeridos por IA como hipóteses, não como fatos
ArtefatosInstruções adversárias embutidas em repositórios ou skills registrados sob nomes inventados; payloads de teste eram marcadores inofensivos que percorriam o mesmo caminho de um bot real
MitigaçãoPlanejador que consulta existência real antes de clonar/instalar; restrição a auto-run; verificação manual do origem esperado; pré-registro defensivo de nomes hallucinados e bloqueio de reutilização de nomes conhecidos
Resumo técnico

Uma linha de pesquisa acadêmica descreveu um encadeamento chamado HalluSquatting, que explora o hábito de assistentes de programação baseados em IA de inventar nomes de projetos com aparência legítima quando o recurso pedido não está bem representado nos dados de treinamento. Em vez de depender de exploracão de rede clássica, senhas fracas ou worming entre hosts, o modelo adversário antecipa o nome falso que o modelo gera com alta consistência, registra esse identificador em um marketplace ou hospedeiro de código e aguarda que o próprio assistente do usuário busque e integre o conteúdo plantado.

O ataque combina alucinação — afirmação de um nome inexistente como se fosse real — com injeção indireta de prompt: as instruções maliciosas viajam embutidas no material que o agente baixa, e não no texto digitado pelo usuário. Como muitos desses assistentes expõem um terminal entre as ferramentas nativas, uma vez que o planejamento interno passa a seguir as diretrizes plantadas, ações do tipo instalar um bot tornam-se operações que o agente consegue disparar. Em experimentos, esse caminho levou à execução de código controlado pelo pesquisador-atacante na máquina local.

Os autores posicionam o resultado como limite inferior de risco e não como falha isolada de um único produto. Não há um CVE único a corrigir: o ponto frágil é o modo como agentes de IA confiam em nomes que nunca foram fornecidos de forma verificável. Se o assistente puder buscar um recurso externo e executar comandos com pouca ou nenhuma revisão humana, a superfície permanece aberta. Com um alvo popular o bastante, um único nome registrado pode ser reutilizado por muitos pedidos de fetch, o que os pesquisadores enquadram como mecanismo de recrutamento para uma botnet.

Fluxo técnico

A cadeia começa pela escolha de um repositório ou plugin em tendência. A popularidade importa porque um recurso muito recente tende a estar ausente ou mal coberto no treinamento do modelo, exatamente o cenário em que a alucinação de nomes sobe. O adversário então provoca o assistente várias vezes, com formulações distintas, e registra o nome inventado com maior frequência. Nos experimentos, a mesma escolha errada apareceu em até 85% dos pedidos de repositório e em 100% das instalações de skill nas taxas de pico reportadas; a variação completa fica no artigo científico.

Em seguida, o nome falso é reivindicado no GitHub ou em uma loja de plugins, e o conteúdo hospedado recebe instruções adversárias. Quando um usuário legítimo pede ao assistente que obtenha o recurso popular, o modelo tende a resolveer para o mesmo identificador plantado e baixa a versão do atacante. A injeção indireta se funde ao contexto operacional do agente, que passa a tratar as diretrizes embutidas como parte da tarefa. O terminal integrado é então usado para cumprir esses passos, incluindo a instalação de um bot convencional.

Os testes cobriram Cursor, Windsurf, GitHub Copilot, Cline, Gemini CLI da Google e a família OpenClaw. Os payloads empregados eram marcadores inofensivos, não malware real; a observação dos autores é que um payload vivo percorreria o mesmo caminho. A equipe comunicou fabricantes, operadores de modelos e marketplaces antes da divulgação pública e omitiu os passos exatos necessários para reproduzir o ataque de ponta a ponta.

Do ponto de vista defensivo, o mecanismo não depende de um exploit de protocolo que firewalls tipicamente inspecionam. O veículo é texto interpretado pelo agente. O bot instalado, uma vez em execução, comporta-se como qualquer membro de botnet: a inovação está na combinação de nome previsivelmente inventado, registro aberto em marketplace e permissão de fetch mais execução. Peças próximas já existiam — slopsquatting para pacotes inventados por IA, phantom squatting para domínios hallucinados e falhas de triagem em lojas de skills — mas HalluSquatting fecha o ciclo até a execução sob controle do atacante.

Superfície afetada

Qualquer ambiente em que um assistente de código possa obter conteúdo externo e acionar o terminal sem aprovação explícita entra no perfil de risco. Isso inclui estáções de desenvolvimento corporativas, notebooks pessoais usados com agentes locais e fluxos onde auto-run ou flags de permissão ampla estão ativos. Os sistemas operacionais não precisam ser homogêneos: ao contrário de botnets clássicas centradas em uma família de dispositivos, aqui a entrega é mediada pelo agente, e o bot resultante herda a plataforma da máquina-alvo.

A superfície também inclui marketplaces e hospedeiros que permitem registrar nomes plausíveis sob contas novas. Scanners de upload não eliminam o risco por si: em junho, pesquisa citada no contexto mostrou que skills maliciosas passaram por vários filtros de loja em menos de uma hora. Pacotes e repositórios hallucinados já tiveram precedentes de penetração no ecossistema de desenvolvimento sem, necessariamente, chegar à mesma etapa de hijack do agente.

Usuários de modos que desligam a confirmação pré-comando — como flags de pular permissões em Claude Code e modos yolo no Gemini CLI — concentram a exposição. Camadas que inspecionam o que o agente leu ou está prestes a fazer, como modos de segurança adicionais em Claude Code e verificação Conseca no Gemini CLI, reduzem probabilidade, mas não removem a dependência de confiança em nomes não validados.

Contexto histórico ligado ao mesmo tema ajuda a medir o alcance da superfície de nomes inventados: em janeiro de 2026, Charlie Eriksen, da Aikido Security, identificou o pacote npm inventado react-codeshift, cujo caminho havia se espalhado para 237 projetos de código, com agentes ainda tentando instalá-lo diariamente; o pesquisador registrou o nome antes que um adversário o fizesse. A Unit 42 da Palo Alto Networks descreveu phantom squatting com cerca de 250 mil domínios hallucinados ainda disponíveis para registro. Esses casos sustentam a premissa de inventário previsível, embora não sejam o mesmo encadeamento completo de HalluSquatting.

  • Agentes com fetch externo mais terminal e revisão humana fraca ou ausente
  • Repositórios e lojas de plugins/skills com registro aberto de nomes plausíveis
  • Modos auto-run e flags que dispensam confirmação de comando
  • Estáções heterogêneas (qualquer SO onde o assistente rode com privilégios de execução)
  • Precedente de pacotes e domínios hallucinados já exploráveis via registro antecipado
Hunting e telemetria

A caça defensiva deve partir do comportamento do agente, não só de assinaturas de malware clássicas. Em logs de endpoint e de ferramentas de desenvolvimento, procure sequências em que o assistente resolve um nome de repositório ou skill diferente do pedido explícito do usuário, especialmente quando o recurso solicitado é recente ou em tendência. Correlacione downloads e clagens com hosts de contas novas, repositórios criados há pouco tempo e skills publicadas sob nomes que não batem com o projeto canônico esperado.

Em identidade e execução local, priorize eventos de instalação ou configuração de agent remoto/bot sem ticket de mudança, seguidos de comunicação de saída atípica. Como o contexto de pesquisa usou placeholders, a telemetria operacional deve focar em classes de indicador: criação de serviços de persistência, novos binários em diretórios de ferramentas do desenvolvedor, e processos filhos do agente de IA que disparam gestores de pacote ou clonagem de git imediatamente após uma sugestão de nome não solicitada.

Na rede, observe conexões iniciadas logo após fetch de conteúdo textual por agentes, sobretudo se o conteúdo baixado alterar o plano de ação do assistente. Não espere o padrão de exploit de porta conhecido de botnets legadas: o gatilho inicial é interpretação de texto. Após o estabelecimento do bot, a telemetria se aproxima de botnet convencional — heartbeat, canais de comando e controle e instalação de módulos — e deve ser caçada com regras já usadas para esses implantes, separando a fase de entrega mediada por IA da fase de operação do bot.

Em repositórios internos e pipelines, inventarie menções a pacotes ou remotes sugeridos por assistentes e compare com fontes oficiais. Names inventados que reaparecem em vários projetos, como no precedente do react-codeshift, são sinal de alucinação sistêmica e devem ser tratados como candidatos a squatting. Monitore tentativas diárias de instalação de artefatos que não existem no registry canônico ou que foram registrados por contas externas ao fornecedor esperado.

  • Divergência entre nome pedido pelo usuário e nome efetivamente clonado/instalado pelo agente
  • Contas e repositórios novos hospedando nomes altamente similares a projetos em tendência
  • Processos filhos do assistente executando gestores de pacote ou git sem aprovação registrada
  • Persistência e C2 compatíveis com bot convencional após um episódio de fetch por agente
  • Repetição do mesmo identificador inventado em múltiplos projetos ou logs de agente
Mitigação

A condição necessária do ataque é um agente que baixa recurso externo e o executa sem verificação humana efetiva. Fechar esse elo interrompe a cadeia. A correção estrutural mais eficaz, segundo o enquadramento da pesquisa, é fazer o assistente consultar a existência real do recurso antes do fetch: uma busca que ancore o planejamento no que de fato existe reduz a alucinação de nomes. Quem desenvolve esses produtos também pode treinar o planejador para tratar palavras de ação como clonar, instalar e buscar como sinais de alto risco que exigem validação prévia.

No curto prazo, equipes de segurança e usuários devem manter a confirmação padrão antes de cada comando e evitar modos que desliguem essa trava em estáções com acesso a código ou segredos. Qualquer nome fornecido por IA deve ser tratado como hipótese até confirmar o mantenedor, a URL canônica e a conta oficial. Antes de um agente puxar um repositório ou pacote, valide que o identificador resolve para a origem esperada — e não para um clone recente criado sob grafia inventada.

Camadas que inspecionam conteúdo lido ou ações iminentes diminuem o risco residual, mas não substituem a política de não deixar o agente operar sozinho sobre artefatos baixados. Em plataformas e marketplaces, as alavancas incluem impedir reutilização de nomes de repositórios conhecidos sob contas novas e pré-registrar nomes que modelos inventam com frequência — a mesma lógica defensiva já usada contra typosquatting — de modo que esses identificadores apontem de volta ao projeto legítimo.

A resposta a um incidente suspeito deve seguir ordem clara: isolar a estáção onde o agente executou fetch não autorizado; revogar tokens e sessões locais que o bot possa ter herdado; remover persistência e binários instalados após o hijack; auditar histórico de prompts e ferramentas do assistente para reconstruir o nome plantado; e varrer frota e repositórios internos em busca do mesmo identificador. Em paralelo, notifique o marketplace e o fornecedor do agente com evidências do nome e da conta, sem redistribuir o conteúdo adversário. Revalide controles de auto-run e o processo de aprovação de instalação de skills antes de reabilitar o assistente.

O posicionamento dos pesquisadores reforça que ataques desse tipo tendem a melhorar com o tempo e que a fraqueza é sistêmica na confiança depositada em nomes não verificados. Organizações que adotam agentes codificadores em escala precisam incorporar inventário de alucinações conhecidas, restrição de permissões de execução e checagem de proveniência aos padrões de AppSec e de threat hunting, tratanto HalluSquatting como vetor de entrega de malware mediado por supply chain de agentes, e não apenas como curiosidade de modelo generativo.

  • Exigir lookup/verificação de existência real antes de clone, install ou fetch
  • Manter confirmação humana; desabilitar auto-run e flags de permissão ampla em ambientes sensíveis
  • Validar mantenedor, conta e URL canônica de qualquer nome sugerido por IA
  • Pré-registrar nomes hallucinados e bloquear reuse de nomes populares em contas novas
  • Em incidente: isolar host, remover bot, rotacionar credenciais locais e caçar o mesmo nome na frota

Postar um comentário

0 Comentários