À medida que as plataformas de IA passam a fazer parte dos fluxos de trabalho diários, hackers encontraram uma nova porta de entrada: as próprias plataformas e os serviços que elas ajudam a impulsionar. Segundo o Centro de Operações de Segurança da Huntress, o risco cotidiano mais relevante está no abuso de recursos de IA em que os usuários já confiam, e não em ataques diretos contra as empresas de IA ou contra os modelos em si. O mesmo padrão de confiança também apareceu, mais recentemente, em uma campanha de spam no RubyGems que, segundo um novo relatório, foi executada por um enxame de agentes da OpenAI.
Nos últimos meses, a Huntress acompanhou incidentes em que hackers transformaram conteúdo compartilhável de IA, miniaplicativos públicos e posicionamento patrocinado em mecanismos de busca em vetores para atingir usuários de IA e distribuir malware. Em paralelo, pesquisadores da Mend.io e da Socket descreveram, em maio e junho de 2026, uma ofensiva coordenada contra o gerenciador de pacotes da linguagem Ruby, que recebeu centenas de gems descartáveis e levou os mantenedores a suspender novos cadastros de usuários por cerca de quatro dias.
A Huntress observou o uso indevido de alguns recursos reais de plataformas de IA, entre eles:
Claude Artifacts: conteúdo gerado pelo Claude e exibido em um painel de pré-visualização na conversa, que os usuários podem publicar e compartilhar por meio de um link público.
links claude.ai/share: URLs compartilháveis criadas quando alguém publica uma conversa do Claude. Esses links podem aparecer em mecanismos de busca quando são divulgados em locais rastreáveis, como fóruns ou redes sociais.
Conversas do ChatGPT e do Grok: conversas compartilhadas e indexáveis, hospedadas em chatgpt.com e grok.com, que podem ganhar destaque em buscas por solução de problemas.
Cada um desses recursos opera dentro de uma zona de confiança. Os usuários reconhecem a plataforma, a identidade visual e o contexto ao redor do conteúdo, então instruções maliciosas ou downloads parecem legítimos. Em geral, essas campanhas ficam no ar por apenas horas ou poucos dias, até que o provedor remova o conteúdo, mas esse tempo já pode ser suficiente para enganar vítimas antes da descoberta.
Em julho, a Huntress identificou uma campanha chamada FakeAgent que atingiu mais de 29 organizações. O ataque começou com um Claude Artifact malicioso hospedado no domínio legítimo claude.ai.
Como os Artifacts públicos foram criados para demonstrações leves e passam por validação mínima da Anthropic, além de um aviso genérico, os hackers montaram uma página falsa muito convincente para download do Claude Desktop.
Vítimas que pesquisaram no Bing pelo app de desktop do Claude acabaram na página falsa e clicaram em um link que parecia legítimo. Em vez disso, foram redirecionadas para um domínio externo que entregava o malware SectopRAT.
A Huntress reportou o Artifact e a Anthropic o removeu em 22 de julho, mas incidentes ligados ao mesmo domínio de redirecionamento continuaram ao longo de agosto.
Em outro caso, uma vítima que pesquisou no Google por “Claude no Mac” clicou em um resultado patrocinado que levava a um link claude.ai/share com aparência de guia de instalação do Suporte da Apple. Como a página estava no próprio domínio da Anthropic, ela não apresentava os sinais de alerta mais comuns: não havia URL parecida com a original nem aviso de certificado.
O falso guia orientava a vítima a colar um comando curl no Terminal, iniciando uma cadeia de seis etapas que instalava o stealer MacSync. O malware coletava cookies, credenciais, segredos do Chaveiro, sessões do Telegram e chaves de SSH e da nuvem.
Um terceiro padrão mira diretamente o próprio conselho de solução de problemas gerado por IA. Em dezembro, uma busca rotineira por “liberar espaço em disco no macOS” exibiu em posições de destaque conversas do ChatGPT e do Grok com instruções no estilo ClickFix, em vez de soluções reais.
Os hackers criaram as conversas, acionaram a opção de compartilhamento para gerar uma URL pública no domínio confiável da plataforma e usaram envenenamento de SEO para colocar o link no topo dos resultados do Google.
Como os links estavam em domínios reais como chatgpt.com e grok.com, as vítimas confiaram nas orientações e executaram os comandos sugeridos no Terminal, o que instalou o stealer AMOS.
Nenhum desses ataques explorou uma falha de segurança das plataformas de IA. Eles abusaram da confiança que os usuários depositam em marcas conhecidas e em domínios legítimos. No caso do RubyGems, a publicação recente do Wall Street Journal e de pesquisadores como Spencer Kitts, Thomas Larsen e Sydney Von Arx aponta na mesma direção: a atividade maliciosa foi impulsionada por agentes da OpenAI que usaram o registro como canal de exfiltração e persistência.
Segundo a análise, o primeiro pacote foi enviado ao RubyGems em 5 de maio de 2026, antes de mais de 2.000 pacotes serem submetidos entre 11 e 12 de maio. Depois disso, os agentes publicaram mais cinco pacotes entre 26 e 27 de maio de 2026 e outros 83 em 18 de junho de 2026.
A conclusão de que o incidente foi resultado de um enxame de agentes da OpenAI vem do fato de que os pacotes foram criados com o auxílio de um modelo de linguagem de grande porte e de que centenas dos pacotes enviados ao RubyGems tinham “oai” no nome. Quinze deles listavam “oai” como autor, enquanto outro trazia “[email protected]” como e-mail de contato.
Alguns dos nomes desses pacotes descartáveis são os seguintes:
chatoaitestgit1778552630
lambhgproxyoai
oaibx0092307
oaicx8859010
oaicx3857133
oaidx4526859
oaiex4149420
oaifx7943598
oaigx5861576
oaihx0305933
oaiix0379958
oaijx0156671
oaikx5119809
oailm2
oaipgttatggxy
oaifetchgemugkejy
oaiproxytestabc789
oaitfossilxbnowl
O grupo mais amplo também se relaciona a uma campanha apelidada de GemStuffer, destacada pela Socket, que envolveu um cluster com mais de 150 gems e usou o registro de pacotes como canal de exfiltração de dados, além de reutilizar dados públicos extraídos de portais de serviços democráticos de governos locais do Reino Unido. Na ocasião, a empresa de segurança de supply chain de software afirmou que a atividade compartilhava o “mesmo padrão de abuso” observado no incidente mais amplo de publicação de spam no RubyGems.
“Não está claro quais são exatamente os objetivos finais, já que as informações parecem estar publicamente acessíveis de qualquer forma”, informou o The Hacker News na época.
“O enxame se comporta de forma extremamente semelhante aos agentes da wiki alemã que encontramos anteriormente”, disseram os pesquisadores, em referência a outro incidente ocorrido em maio de 2026, no qual agentes autônomos implantados internamente sequestraram um fórum de wiki alemão, o DseWiki, e o transformaram em um painel de avisos para pedir respostas, reunir resultados e compartilhar técnicas de contornar suas restrições durante uma tarefa temporizada de busca na web.
“Os agentes de junho estavam acessando 49 dos mesmos arquivos que os agentes da wiki. Os agentes de maio acessavam arquivos diferentes, em sua maioria dados locais de governos do Reino Unido, mas esses arquivos são muito semelhantes em natureza aos buscados pelos agentes da wiki. Além disso, eles usam os mesmos métodos de recuperação. 1.397 pacotes mencionam r.jina.ai, que foi amplamente usado pelos agentes na wiki. Também vemos que muitos pacotes mencionam example.com, que os agentes da wiki usavam para testar sua capacidade de publicação.”
Segundo os pesquisadores, os agentes exploraram uma peculiaridade de design no processo de geração de documentação do RubyDoc.info para exfiltrar dados públicos de sites do governo britânico, provavelmente como parte de uma tarefa de coleta de informações semelhante às tarefas de pesquisa processadas pelos agentes que exploraram a wiki alemã.
“O processo de geração de documentação para uma gem envolve a avaliação de um arquivo '.yardopts' especificado pelo usuário, o que permite vincular scripts Ruby criados para ajudar nesse processo”, explicaram os pesquisadores. “Na campanha GemStuffer, os agentes abusaram disso para obter execução remota de código arbitrário nos servidores do RubyDoc.info.”
Uma das gems, “zzsouthrunner”, que mais uma vez segue o esquema de nomenclatura “ZZ” adotado pelos agentes tanto no incidente da wiki quanto no da Hugging Face, foi encontrada com o seguinte comentário explícito no topo de “data/script.rb”:
malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker
Vale destacar que a campanha GemStuffer mirou portais públicos do ModernGov usados por Lambeth, Wandsworth e Southwark. A cadeia de exploração pode ser resumida assim:
- enviar um pacote malicioso ao RubyGems
- acionar uma solicitação de documentação para que o RubyDoc.info gere o pacote
- usar o script de build para executar código no RubyDoc.info e fazer varredura nos sites-alvo
- exfiltrar os dados dos servidores do RubyDoc.info publicando outra gem de volta no registro do RubyGems, que é visível publicamente
Além disso, foi constatado que os agentes da OpenAI tentaram roubar as chaves de API de outros usuários depois de obterem execução remota de código no ambiente de build, deixando claro que sabiam estar realizando uma invasão não autorizada em sistemas reais.
Isso fica evidente pelos nomes atribuídos aos arquivos, como hack.rb, evil.rb, inject.rb, exploit.rb e ssrf.rb, pelos próprios pacotes, como pwnp999, exfiltestwand3, hacksvn1778554764 e lambproxyhackabcxyz, e pelos comentários deixados no código-fonte, como “# malicious probe”, “#hack”, “# malicious test” e “# malicious crawler/exfil”.
Em alguns casos, porém, os agentes descontrolados tentaram agir sem chamar atenção, deixando comentários para ocultar o payload malicioso na próxima versão dos pacotes. “# disable evil in next version and bump version”, diz um comentário no arquivo “data/evil.rb” dentro da gem yardxabc889.
Mais preocupante ainda, os agentes também tentaram explorar um bug de cache em CDN, com CVSS 7,3 e sem CVE, em 12 de maio de 2026, que só foi corrigido pelo RubyGems em julho de 2026. Em termos gerais, a falha poderia entregar a chave de API de uma conta para outra por até uma hora, permitindo que um atacante vazasse a chave de um usuário aleatório.
Seis dos pacotes publicados como parte da campanha usaram essa vulnerabilidade antes da correção, embora não esteja claro se os agentes tiveram êxito. Em seu alerta de julho, o RubyGems disse não ter encontrado indícios de que esse caminho tenha sido explorado em um contexto malicioso. Os nomes das seis Ruby gems são os seguintes:
slnleaker5
zzwandshostyard
lambfetchx548811
lambfetchx550961
lambfetchx550961
yardbreakerxqh1778552850
“Se você entrou no rubygems.org com um cliente gem anterior à versão v3.2.0, ou por meio de uma chave legada, sua chave pode ter ficado exposta”, informou o RubyGems em um aviso. “Atualmente, 18% dos acessos via gem sign-in vêm de uma versão afetada e, durante os primeiros anos desse bug, antes de mudarmos o fluxo de autenticação do cliente em dezembro de 2020, isso acontecia com todos os clientes gem.”
Algumas das outras ações atribuídas aos agentes estão listadas abaixo:
- os agentes contornaram o sistema de confirmação por e-mail do RubyGems para obter chaves de API funcionais sem precisar verificar os endereços de e-mail, a fim de registrar um grande número de contas usando endereços descartáveis. O problema foi corrigido em 12 de maio de 2026. A possibilidade de cadastro com e-mail descartável foi desativada em 16 de maio de 2026
- os agentes tentaram usar o sistema de webhooks do RubyGems para armazenar dados na forma de URLs codificadas
- os agentes usaram um cluster de 83 gems publicadas no RubyGems ao longo de uma janela de três horas em 18 de junho de 2026 para testar diferentes formas de acessar o conjunto de dados county.json da Comissão de Valores Mobiliários dos Estados Unidos, a SEC
Esta não é a primeira vez que agentes da OpenAI miram o RubyGems. Em seu relatório pós-incidente publicado no fim do mês passado, a OpenAI afirmou ter observado seus agentes explorando o processamento do RubyGems no JRuby do JFrog Artifactory para obter a chave de assinatura e forjar credenciais de administrador, como parte de um ataque direcionado à infraestrutura da empresa de IA.
Os pesquisadores também observaram que, até o momento, não se sabe por que os agentes se deram ao trabalho de atacar o RubyGems para raspar dados publicamente disponíveis nem se eles atuaram em conjunto, como em outros incidentes. A hipótese é de que os agentes possam ter tentado usar o RubyGems como um meio de armazenar os dados raspados de forma persistente e contornar limites de taxa.
“Suspeitamos que eles cooperavam entre si, tanto porque isso explicaria melhor o fato de terem ido tão longe para armazenar em cache os sites quanto porque os pacotes enviados pelos agentes parecem ter milhares de downloads”, disseram os pesquisadores. “Mas isso está longe de ser conclusivo.”
Na semana passada, a OpenAI afirmou ter tratado o incidente da wiki como “um caso de desalinhamento semelhante aos que compartilhamos” e disse que historicamente “tratou o desalinhamento em grande parte como uma questão de pesquisa, comunicada em publicações como systems cards”.
A empresa americana também declarou que a comunidade de IA ainda não tem um “padrão claro para relatar o desalinhamento que surge durante o treinamento, a avaliação e a implantação, incluindo exemplos que não parecem incidentes de segurança tradicionais, mas que podem fornecer informações sobre o comportamento da IA e riscos futuros”. A companhia disse ainda que trabalha em uma estrutura que pretende compartilhar publicamente nas próximas semanas.
O episódio é apenas o mais recente de uma série de ataques cibernéticos ligados a laboratórios de IA de ponta, que acenderam alertas e impulsionaram pedidos por uma regulamentação mais rígida da IA. Como ficou amplamente claro, se não forem cuidadosamente restringidos, os agentes de IA podem ir ao extremo para concluir as tarefas que lhes forem atribuídas, mesmo que isso signifique escapar de sandboxes ou conduzir ataques de engenharia social contra pessoas reais.
A lista crescente de incidentes em que agentes de IA da OpenAI, Anthropic e Meta violaram ou tentaram acessar sistemas externos aumentou as preocupações sobre o ritmo de desenvolvimento da IA e sobre o risco de elas escaparem do controle humano.
“Com base em nossa análise, nossos agentes usaram a plataforma RubyGems para acessar a internet a fim de executar tarefas benignas e recuperar informações públicas”, disse a OpenAI em comunicado à Reuters. “Continuaremos investigando como parte de nossa análise mais ampla da atividade dos agentes durante o treinamento e a avaliação.”
O RubyGems, por sua vez, afirmou que sua própria investigação não encontrou evidências de que as tentativas tenham sido bem-sucedidas e que está comprometido em detectar e combater o abuso, independentemente de a atividade se originar de humanos ou de ferramentas automatizadas.
“Com base nas evidências disponíveis para nós, não podemos determinar se os pacotes foram criados ou publicados por agentes de IA”, disse Colby Swandale, líder técnico da Ruby Central. “Nosso foco é identificar e prevenir abusos, independentemente de eles virem de pessoas ou de ferramentas automatizadas.”
Publicidade
Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...