TL, DR
O cenário de ameaças à cadeia de suprimentos de código aberto mudou fundamentalmente. Três tendências convergentes estão redefinindo o risco:
Chegaram as minhocas que se propagam sozinhas.
- Shai Hulud (Setembro de 2025): Primeiro ataque de worm npm — roubou credenciais via pós-instalação. hooks, e então republicou-se autonomamente em cerca de 700 versões de pacotes usando tokens de mantenedor comprometidos.
- Verme de Vidro (Outubro de 2025): Malware de extensão do VS Code usando payloads invisíveis codificados em Unicode e um servidor de comando e controle (C2) indestrutível baseado em blockchain (Solana). Mais de 35 mil instalações, com recursos completos de RAT direcionados a carteiras de criptomoedas.
- Shai-Hulud 2.0 (Nov 2025): Transição entre registros, do npm para o Maven Central, por meio de ferramentas automatizadas de espelhamento, além do GitHub Discussions usado como instância de comando e controle (C2) e um mecanismo de limpeza destrutivo como alternativa.
A IA agora é a operadora, não apenas a ferramenta.
Uma campanha de ciberespionagem documentada alcançou execução autônoma usando Claude como mecanismo de orquestração — reconhecimento, exploração, movimentação lateral e exfiltração com supervisão humana mínima. A barreira para ataques sofisticados caiu de "equipe de especialistas" para "alguém que entende de instruções".
Abuso de infraestrutura em grande escala
A campanha IndonesianFoods inundou o npm com cerca de 44,000 pacotes de spam que exploravam sistemas de recompensa de blockchain (Protocolo TEA), persistindo por quase dois anos antes de ser removida. Cenários de segurança ofensiva também estão abusando da infraestrutura de código aberto.
ponto de partida
Cada máquina de desenvolvedor comprometida agora é um ponto potencial de propagação de worms. O roubo de credenciais permite a disseminação autônoma. A IA pode orquestrar ataques na velocidade da máquina. As abordagens tradicionais de detecção e remoção estão falhando contra servidores de comando e controle imutáveis e a propagação entre registros. A defesa deve partir do pressuposto de que o sistema está comprometido e focar na velocidade de contenção.
Novas ameaças aos ecossistemas de código aberto: worms, malware criado por IA e abuso de confiança em larga escala.
O ecossistema de código aberto está passando por uma mudança paradigmática nas ameaças à cadeia de suprimentos. Os pacotes maliciosos tradicionais não se propagavam sozinhos, a IA não era uma preocupação para os agentes de ameaças e a disseminação de ataques era limitada.
Nos últimos meses, testemunhamos a convergência de três categorias de ameaças que, embora preocupantes individualmente, representam uma mudança fundamental no panorama de riscos para o desenvolvimento de software, quando considerados em conjunto:
- Vermes autopropagáveis em ecossistemas de embalagensPacotes maliciosos que se propagam autonomamente por meio de roubo de credenciais e republicação automatizada. Isso transforma cada máquina de desenvolvedor comprometida em um novo vetor de infecção.
- Geração e exploração de malware impulsionadas por IAOs agentes maliciosos usam modelos de linguagem complexos para escrever payloads, descobrir vulnerabilidades e orquestrar ataques na velocidade da máquina.
- Exploração de confiança em larga escalaAlguns agentes abusam sistematicamente das recompensas por contribuições de código aberto, infraestrutura de repositórios e ferramentas de desenvolvimento, criando picos com milhares de publicações de pacotes de spam, afetando os registros.
As principais técnicas que permitem ataques sofisticados à cadeia de suprimentos de software deixaram de ser teóricas. Elas são ativas, documentadas e cada vez mais acessíveis a agentes de ameaças menos sofisticados. A barreira para a realização de ataques à cadeia de suprimentos caiu por terra — o que antes exigia equipes de atacantes experientes agora pode ser executado por agentes de IA com supervisão humana mínima.
Este artigo examina incidentes recentes envolvendo diretamente pacotes maliciosos de código aberto ou o abuso de IA e infraestrutura de código aberto, analisa as novas técnicas que os possibilitaram e explora as capacidades emergentes que podem definir a próxima geração de ameaças. Na última seção, examinamos o que pode ser feito para limitar o risco.
NOTA: Este pôster foi gerado por IA e apresenta falhas graves na compreensão do que está acontecendo. A IA está longe de ser perfeita para certos usos.
Sha1-Hulud: O primeiro ataque de worm autorreplicante do npm
Descoberto em 14 de setembro de 2025, Shai Hulud Representa o primeiro ataque de worm autopropagável documentado no ecossistema npm. O nome foi escolhido por agentes maliciosos que parecem ser fãs de ficção científica! O ataque começou com credenciais de desenvolvedor comprometidas — provavelmente obtidas por meio de campanhas de phishing que se passavam pelo npm. Conecte-se solicitações ou burlas de MFA. Uma vez dentro do sistema, o ataque do worm executou um ataque em várias etapas que transformou o roubo de credenciais em propagação autônoma. O ataque foi grave o suficiente para merecer uma CISUm alerta.
Arquitetura Técnica:
O malware opera através de uma carga útil JavaScript altamente minificada e agrupada pelo Webpack (bundle.js) que é executado por meio de um gancho de pós-instalação…
Coleta de credenciais:
Após a execução, a carga útil implementa uma descoberta secreta abrangente:
- Lixões
process.enve examina o sistema de arquivos em busca de segredos de alta entropia. - Executa o TruffleHog para verificação sistemática de credenciais.
- Consultas a endpoints de metadados na nuvem (
169.254.169.254,metadata.google.internal) - Alvos de tokens npm em
.npmrc, PATs do GitHub e CI/CD segredos!
Infraestrutura de exfiltração:
O ataque do worm emprega múltiplas estratégias de exfiltração:
- Abuso do GitHub ActionsFluxos de trabalho contendo
${{ toJSON(secrets) }}que serializa todos os segredos do repositório.
Propagação Autônoma:
O mecanismo de autorreplicação do verme opera através do seguinte algoritmo (em pseudocódigo):
function propagate(token, owner) {
userPackages = npmApi.listPackages(owner, token);
for (pkg in userPackages) {
tgz = npmApi.fetchTarball(pkg, token);
modified = injectBundleAndPostinstall(tgz);
npmApi.publish(modified, token);
}
}
Com qualquer token npm roubado, o worm enumera todos os pacotes pertencentes ao mantenedor comprometido e injeta... bundle.js com um gancho de pós-instalação e republicações. Esse comportamento autônomo fez com que o número de infecções saltasse de dezenas para centenas de pacotes em questão de horas.
Métricas de impacto:
-
Detecção inicial: 14 de setembro de 2025, por
Daniel Pereira
O “paciente zero” parece ser
rxnt-authentication:0.0.3. - Raio de explosão do ataque: Aproximadamente 700 versões de pacotes maliciosos foram publicadas, com alvos de alto perfil e milhões de downloads semanais. Limitadas a pacotes npm e repositórios do GitHub.
-
Infraestrutura: C2 em
217.69.3.218, exfiltração para140.82.52.31:80/wall -
Persistência: Fluxos de trabalho do GitHub em branches com nome
shai-hulud -
Indicadores observáveis: Repos foram abertos ao público com
-migrationsufixo
Shai-Hulud é um worm de coleta de segredos. Ele não tentou roubar dinheiro ou destruir infraestrutura. Os segredos exfiltrados e os repositórios expostos podem ser usados para ataques direcionados, portanto, os danos subsequentes decorrentes do roubo de credenciais podem se manifestar posteriormente. O verdadeiro custo reside na remediação, na rotação de credenciais e no risco de ataques secundários.
Um efeito positivo foi forçando o GitHub/NPM a tomar medidas imediatas : descontinuar tokens clássicos legados e outras credenciais de publicação fracas, e avançar em direção ao “Jardim do Éden do OIDC” OpenSSF'S Publicação confiável .
Mas continue lendo! O verme emergiu mais uma vez das areias de Arrakis.
Sha1-Hulud 2.0: O Verme Arrakis Contra-Ataca
Dois meses após a campanha inicial Shai-Hulud, os agentes de ameaças retornaram com "A Segunda Vinda" — uma onda significativamente mais agressiva que aprendeu com as vulnerabilidades do primeiro ataque. A campanha se autoidentificou por meio de repositórios rotulados como “Sha1-Hulud: A Segunda Vinda.”
Vamos examinar as principais diferenças em relação à primeira onda. preinstall O gancho substituiu o vetor de execução pós-instalação original. De acordo com
Pantera,
@asyncapi/avro-schema-parser@3.0.25 foi o “paciente zero” desta segunda onda, explorando uma vulnerabilidade.
pull_request_target Gatilho de fluxo de trabalho. (Se você "conhece alguém que usa isso", por favor, leia
Por que o parâmetro `pull_request_target` é tão perigoso?
).
Propagação entre Registros:
O worm se espalhou do npm para o Maven Central por meio de espelhamento automatizado. mvnpm A ferramenta —que converte pacotes npm em artefatos Maven sem revisão de segurança— republicou automaticamente pacotes npm comprometidos, como
posthog-node@4.18.1 as
org.mvnpm:posthog-node:4.18.1.
Este foi o primeiro worm conhecido a infectar vários registros: uma vulnerabilidade no npm que afetou o ecossistema Java sem qualquer interação direta. O Maven Central removeu os artefatos em 25 de novembro de 2025, mas o período de exposição ainda afetou cargas de trabalho Java/JVM e enterprise construir sistemas.
Tempo de execução do Bun para Evasão:
Os atacantes implantaram um preinstall: node setup_bun.js gancho que instalou o
Viveiro tempo de execução para evitar o monitoramento específico do Node. O Bun proporcionou uma execução mais rápida para a carga útil ofuscada de mais de 480,000 linhas (bun_environment.js) e contornou a instrumentação tradicional do Node.js.
GitHub Actions como infraestrutura de comandos:
O worm implantou executores ocultos e auto-hospedados do GitHub Actions em $HOME/.dev-env/ em Windows, macOS e Linux. Mais avançado ainda, criou discussion.yaml Fluxos de trabalho que monitoravam eventos do GitHub Discussions e executavam o conteúdo das mensagens de discussão como comandos de shell — transformando efetivamente o GitHub Discussions em um canal C2 invisível.
Capacidade de limpeza destrutiva:
Ao contrário da primeira onda, que se concentrou na coleta de credenciais, Shai-Hulud 2.0 introduziu um limpador destrutivo Acionado quando não havia credenciais válidas disponíveis para propagação. Esse "interruptor de homem morto" garantia danos mesmo se a replicação falhasse, sinalizando uma mudança de operações puramente focadas em espionagem para campanhas potencialmente destrutivas.
Apesar de utilizar técnicas furtivas (runtime Bun, ofuscação), a campanha foi extremamente ruidosa — republicando centenas de pacotes, criando múltiplos repositórios públicos, enviando grandes quantidades de credenciais e instalando runners autohospedados de longa duração. Esse ritmo agressivo contrasta fortemente com os ataques tradicionais à cadeia de suprimentos, que dependem de furtividade. Isso sugere confiança em um impacto rápido ou uma tática deliberada de "sobrecarga" para maximizar os danos em um curto período.
GlassWorm: Código Invisível Encontra Blockchain C2
Em 17 de outubro de 2025, uma extensão do VS Code chamada GlassWorm introduziu duas técnicas inéditas no cenário de ameaças à cadeia de suprimentos: código malicioso invisível usando camuflagem Unicode e infraestrutura de comando e controle baseada em blockchain.
Técnica de ocultação Unicode:
A principal inovação do GlassWorm reside no abuso de seletores de variação Unicode — caracteres especiais que não produzem saída visual, mas permanecem executáveis em JavaScript. Isso cria código malicioso que aparece como linhas em branco em editores de código, comparações do GitHub e realce de sintaxe de IDEs. Essa técnica compromete fundamentalmente a revisão humana de código, ocultando a lógica executável dentro de regiões visualmente vazias.
O ataque teve como alvo extensões do VS Code no marketplace OpenVSX. A análise da extensão CodeJoy (v1.8.3) revelou grandes seções invisíveis contendo JavaScript executável codificado com caracteres Unicode não imprimíveis. Para um desenvolvedor que revisa o arquivo, o conteúdo parece normal, com linhas em branco. Para o ambiente de execução do JavaScript, trata-se de uma carga maliciosa completa.
Arquitetura C2 baseada em blockchain:
O GlassWorm implementa um mecanismo de comando e controle indestrutível usando a blockchain Solana. O malware busca transações a partir de um endereço de carteira predefinido; os campos de memorando de transação contêm objetos JSON com URLs codificadas em base64.
Essa arquitetura cria vantagens poderosas:
- ImutabilidadeTransações em blockchain não podem ser modificadas ou excluídas.
- AnonimatoAs carteiras de criptomoedas são pseudônimas e difíceis de rastrear.
- Resistência à censuraSem provedor de hospedagem para pressionar, sem infraestrutura para confiscar.
- Tráfego legítimoAs conexões com os nós RPC da Solana são indistinguíveis da atividade comum da blockchain.
- Atualizações dinâmicasÉ possível enviar novas URLs de conteúdo por menos de US$ 0.01 por transação.
Mesmo que os defensores bloqueiem o servidor de carga útil decodificada (217.69.3.218), os atacantes podem simplesmente publicar uma nova transação apontando para um URL alternativo. Todos os sistemas infectados buscarão automaticamente o local atualizado.
C2 de backup: Google Agenda
Para redundância, o GlassWorm usa um evento do Google Agenda como canal C2 secundário. O título do evento contém um URL de carga útil codificado em base64.
https://calendar.app.google/M2ZCvM8ULL56PD1d6
Event title: aHR0cDovLzIxNy42OS4zLjIxOC9nZXRfem9tYmlfcGF5bG9hZC9xUUQlMkZKb2kzV0NXU2s4Z2dHSGlUdg==
Decodes to: http://217.69.3.218/get_zombi_payload/qQD%2FJoi3WCWSk8ggGHiTdg%3D%3DIsso proporciona um serviço legítimo que ignora os controles de segurança e pode ser atualizado simplesmente editando o evento no calendário.
Entrega de carga útil:
Os servidores C2 entregam payloads criptografados usando AES-256-CBC. As chaves de descriptografia são geradas por solicitação e transmitidas por meio de cabeçalhos HTTP personalizados, garantindo que os payloads interceptados não possam ser descriptografados sem uma nova solicitação.
ZOMBI: Capacidades RAT de Espectro Completo
A carga útil final (ZOMBI) transforma estações de trabalho de desenvolvedores infectadas em infraestrutura criminosa:
- Servidor proxy SOCKSImplanta servidores proxy para rotear o tráfego do atacante através das redes da vítima, permitindo acesso interno e anonimato.
- WebRTC P2PEstabelece canais de controle ponto a ponto que contornam firewalls por meio de NAT traversal.
- BitTorrent DHTUtiliza tabelas hash distribuídas para distribuição descentralizada de comandos que não podem ser desativadas.
- VNC oculto (HVNC)Fornece acesso remoto invisível à área de trabalho, executado em desktops virtuais que não aparecem na tela nem no Gerenciador de Tarefas.
Segmentação de carteira de criptomoeda:
O ZOMBI busca ativamente por 49 extensões diferentes de carteiras de criptomoedas, incluindo MetaMask, Phantom e Coinbase Wallet. Combinado com acesso remoto invisível, isso possibilita o roubo direto de fundos das máquinas dos desenvolvedores.
Coleta e propagação de credenciais:
Assim como o Shai-Hulud, o GlassWorm coleta tokens do npm, credenciais do GitHub e tokens de acesso do OpenVSX. Essas credenciais permitem a propagação autônoma para pacotes e extensões adicionais, criando um comportamento de propagação semelhante ao de um worm.
Métricas de impacto:
- Detecção inicial: Outubro 17, 2025
- Total de instalaçõesMais de 35,800 unidades no marketplace do OpenVSX e do VS Code (possivelmente inflado por bots)
- Extensões comprometidas: 16 confirmados (15 OpenVSX, 1 Microsoft Marketplace)
- Infraestrutura: Primário C2 em
217.69.3.218, exfiltração para140.82.52.31:80/wall - Carteira Blockchain:
28PKnu7RzizxBzFPoLp69HLXp9bJL3JFtT2s5QzHsEA2(Solana) - Estado actualAtivo, com infraestrutura operacional até o momento desta publicação.
Espionagem cibernética orquestrada por IA
Todos estamos aprendendo a trabalhar com ferramentas de IA. Observando as técnicas usadas em ataques recentes, podemos nos perguntar: Será que agentes maliciosos estão usando IA para criar malware? Certamente. Mas eles podem ampliar ainda mais os ataques, utilizando IA como arma para a orquestração. O que se segue é uma campanha de ciberespionagem — mas imagine essas mesmas técnicas aplicadas a ataques automatizados direcionados a sistemas de código aberto.
Em setembro de 2025, Antrópico detectado e interrompido O primeiro ciberataque documentado foi executado em grande parte sem intervenção humana. A campanha alcançou 80-90% de execução autônoma. Utilizando o Claude Code como mecanismo de orquestraçãoCom agentes de IA realizando reconhecimento, exploração, movimentação lateral e exfiltração de dados, isso marca a transição de ataques assistidos por IA para operações cibernéticas orquestradas por IA.
O grupo de ameaças, GTG-1002 (um grupo patrocinado pelo Estado chinês), teve como alvo cerca de 30 organizações dos setores de tecnologia, finanças e governo. Eles desenvolveram uma estrutura autônoma que transformou o Claude Code de um assistente de programação em um mecanismo de operações cibernéticas.
IA como Sistema de Orquestração
Em vez de usar IA como consultora, a GTG-1002 usou Claude como o operador principalA estrutura dividiu ataques de múltiplas etapas em tarefas isoladas, cada uma aparentemente benigna por si só. Por meio de instruções cuidadosamente elaboradas e personas estabelecidas, os atacantes induziram Claude a executar ações prejudiciais sem compreender seu contexto malicioso.
A IA executou etapas técnicas enquanto o mecanismo de orquestração monitorava o estado da campanha, gerenciava as transições de fase e agregava os resultados ao longo de sessões de vários dias. A intervenção humana se limitou à supervisão de alto nível: inicialização, seleção de alvos, aprovação de escalonamentos e validação da exfiltração.
Ferramentas comuns — scanners de rede, exploits de banco de dados — foram orquestradas por meio de soluções personalizadas. Servidores MCP.
Essa abordagem automatiza operações em velocidades impossíveis para humanos. Claude chegou a analisar dados roubados para priorizar informações valiosas, mantendo um contexto consistente entre as sessões, enquanto operadores humanos retornavam posteriormente para revisar o progresso.
Engenharia Social da IA: Burlando os Controles de Segurança
O sucesso da campanha dependeu de convencer Claude a realizar tarefas de intrusão cibernética, apesar de seu treinamento em segurança. A técnica: encenação de enganoOs atacantes se fizeram passar por analistas de segurança cibernética realizando investigações legítimas. Combinado com o isolamento de tarefas, isso foi suficiente para burlar os controles de segurança da IA.
Alucinações são ótimas!
Claude frequentemente tinha alucinações com os resultados — relatando explorações bem-sucedidas que falharam, inventando credenciais, fabricando descobertas. Por enquanto, isso limita as operações totalmente autônomas, mas à medida que os modelos melhorarem, essas fragilidades diminuirão. Até lá, uma falha comum da IA é, ironicamente, nossa melhor amiga 🙃.
Detecção e Resposta:
A Anthropic detectou a campanha por meio de padrões de uso anômalos que indicavam comportamento intrusivo sistemático. Eles baniram as contas associadas, notificaram as organizações afetadas, coordenaram com as autoridades e integraram os padrões de ataque em controles de segurança mais abrangentes.
Implicações na cadeia de suprimentos:
Todas as técnicas demonstradas aqui são diretamente aplicáveis aos ecossistemas de pacotes. A IA poderia descobrir autonomamente mantenedores vulneráveis, gerar pacotes maliciosos e orquestrar ataques em todo o registro em velocidade de máquina. A barreira caiu de "equipe de cibercriminosos especialistas" para "operador que entende os comandos da IA".
Precisa de um exemplo prático de recrutamento de IA para ciberataques? Leia ShadowRay 2.0Ataques fazem a IA se voltar contra ela mesma em uma campanha global. , onde adversários usaram os recursos de orquestração do Ray ("o Kubernetes da IA") para executar uma botnet global de cryptojacking que se espalhou autonomamente por clusters Ray expostos.
Outro exemplo:
Angularidade ataque
, explorando o mesmo pull_request_target Problema mencionado anteriormente. Ele detecta ferramentas de linha de comando de IA instaladas localmente (Claude, Gemini, Q com flags de bypass) e as utiliza para reconhecimento. telemetry.js cargas úteis,
Os prompts incluíam coisas
como isso:
Abuso de infraestrutura: campanhas de spam em larga escala envolvendo pacotes.
Além de pacotes de distribuição de malware, o ecossistema de código aberto enfrenta abusos de infraestrutura por meio de campanhas de spam que inundam os registros com milhares de pacotes. DevOps para crimes cibernéticos é comum: os atacantes rotineiramente usam SCMe registros para OSINT, distribuição de estágios de malware, extração de segredos e manutenção de comando e controle. Mas essas plataformas também podem ser abusado para fins não maliciososEmbora não sejam tradicionalmente maliciosas, essas campanhas consomem recursos do registro, poluem os resultados de pesquisa e corroem a confiança.
Dois exemplos significativos demonstram essa tendência: Comidas indonésias (explorando recompensas de contribuidores) e o Campanha dos Elfos (Testes da equipe vermelha que saíram do controle).
IndonesianFoods: Exploração do Protocolo TEA
A principal motivação foi a fraude financeira através de exploração do Protocolo TEA , um sistema baseado em blockchain projetado para compensar desenvolvedores de código aberto.
Os atacantes publicaram milhares de pacotes interconectados contendo tea.yaml Arquivos vinculados às suas carteiras Ethereum formavam redes de dependência circular para inflar as métricas de contribuição. Scripts automatizados publicavam cerca de 12 pacotes por minuto com nomes e termos alimentícios indonésios gerados aleatoriamente. O arquivo README de um dos pacotes chegou a se gabar dos ganhos com tokens TEA, confirmando a motivação financeira.
A campanha abrangeu cerca de 44,000 pacotes — mais de 1% do npm — e persistiu por quase dois anos. Dependências circulares significavam que a instalação de um único pacote poderia instalar centenas de pacotes de spam. Os resultados de busca foram prejudicados, a confiança nas métricas dos pacotes foi abalada e a largura de banda e o armazenamento do registro foram intensamente consumidos.
Embora o abuso do protocolo TEA tenha sido documentado em abril de 2024, a remoção sistemática só ocorreu em novembro de 2025, revelando lacunas críticas na detecção de abusos no registro. O episódio minou a confiança em modelos de financiamento baseados em blockchain e expôs a facilidade com que os sistemas de recompensa podem ser manipulados.
Campanha dos Elfos: Testes Automatizados de Infraestrutura
O método da campanha dos elfos Em dezembro de 2025, a ênfase era no abuso da infraestrutura em vez de intenções maliciosas. As descrições dos pacotes faziam referência a "desafio de captura da bandeira" e "testes" (incluindo um texto em francês: "Package généré automatiquement toutes les 2 minutes"), sugerindo origens em pesquisa de segurança ou exercícios de CTF.cises.
Os pacotes seguiram padrões consistentes. elf-stats-* Nomes com temas sazonais. Alguns continham shells reversos triviais (comandos simples de uma linha em bash), tão pouco sofisticados que pareciam ter sido criados apenas para testes de detecção, e não para exploração real.
O ritmo operacional — um pacote a cada 2 minutos em várias contas — testou os recursos de limitação de taxa e detecção de abusos do npm. A campanha demonstrou que o envio automatizado de pacotes pode persistir por horas ou dias antes de qualquer intervenção, consumindo armazenamento, largura de banda e recursos de moderação.
Mais importante ainda, isso sinalizou para outros agentes maliciosos que ataques de inundação automatizados são viáveis, podendo inspirar futuras campanhas de abuso.
Novas Táticas, Técnicas e Procedimentos (TTPs)
| TTP | Técnica | Impacto | Detecção |
|---|---|---|---|
| Propagação autônoma por meio da reutilização de credenciais | Após coletar tokens npm, credenciais do GitHub ou chaves de API de registro, o malware enumera programaticamente todos os pacotes pertencentes ao mantenedor comprometido e injeta payloads maliciosos em novas versões. | Um único token comprometido pode infectar dezenas ou centenas de pacotes em questão de horas. Cada nova vítima se torna um ponto de propagação para disseminação adicional. | Monitore surtos repentinos de publicações de pacotes por parte de um único mantenedor, especialmente quando acompanhados de uma pós-instalação suspeita. hooks ou grandes adições binárias. |
| Infraestrutura C2 multicamadas com imutabilidade de blockchain | O servidor C2 primário utiliza transações em blockchain (Solana, Ethereum) onde os campos de memorando contêm URLs de carga útil criptografadas ou codificadas. O servidor C2 secundário utiliza serviços legítimos (Google Agenda, Pastebin, GitHub Gists) como canais de backup. | As abordagens tradicionais de remoção de conteúdo falham — as transações em blockchain não podem ser removidas e o uso indevido legítimo do serviço é difícil de distinguir do uso normal. | Monitore consultas RPC incomuns na blockchain provenientes de máquinas de desenvolvedores, especialmente para endereços de carteira específicos. Acompanhe as conexões com serviços de calendário ou sites de compartilhamento de texto a partir de ambientes de desenvolvimento. |
| Injeção de código invisível via Unicode Stealth | O JavaScript malicioso é codificado usando seletores de variação Unicode (U+FE00 a U+FE0F) e caracteres de largura zero que não são renderizados em editores, mas permanecem como código executável válido. | A revisão de código torna-se ineficaz. Os desenvolvedores que examinam os arquivos de origem veem linhas em branco enquanto os interpretadores de JavaScript executam malware oculto. | Analise os arquivos de origem em busca de caracteres Unicode não imprimíveis, especialmente seletores de variação e junções de largura zero. Implemente verificações automatizadas que decodifiquem e analisem o conteúdo real em bytes dos arquivos de origem, e não sua representação renderizada. |
| Ações do GitHub como infraestrutura de exfiltração |
Implantar fluxos de trabalho contendo ${{ toJSON(secrets) }} Expressões que serializam todos os segredos do repositório e os enviam via POST para endpoints controlados pelo atacante. O fluxo de trabalho é executado na infraestrutura do GitHub, aparentando ser legítimo. CI/CD atividade.
|
Roubo completo de segredos do repositório sem acionar os métodos tradicionais de detecção de exfiltração, já que o tráfego se origina dos intervalos de IP confiáveis do GitHub. |
Arquivos de fluxo de trabalho de digitalização para toJSON(secrets) padrões. Monitore fluxos de trabalho que realizam requisições HTTP externas com corpos POST grandes. Alerte sobre adições de fluxos de trabalho a repositórios sem PRs correspondentes ou commit história.
|
| Implantação híbrida de RAT em ambientes de desenvolvimento | Implemente recursos completos de RAT (proxy SOCKS, VNC, WebRTC P2P) projetados especificamente para operar em estações de trabalho de desenvolvedores. Direcione as credenciais de desenvolvimento, o acesso ao código-fonte e o posicionamento na rede interna, em vez dos dados tradicionais do usuário. | Desenvolvedores comprometidos fornecem acesso direto a repositórios de código-fonte. CI/CD pipelines, infraestrutura em nuvem e redes corporativas internas. | Monitore implantações inesperadas de servidores proxy, processos de servidores VNC, conexões WebRTC de máquinas de desenvolvimento e participação na rede DHT do BitTorrent. Implemente segmentação de rede rigorosa e filtragem de saída. |
| Infecção em cadeia de dependência | Pacotes maliciosos declaram outros pacotes controlados pelo atacante como dependências. A instalação de um pacote desencadeia a instalação automática de toda a cadeia. | Uma única dependência maliciosa pode introduzir dezenas de pacotes controlados pelo atacante. A limpeza exige a identificação e remoção de toda a cadeia de infecção. | Analise os grafos de dependência em busca de padrões incomuns — dependências circulares, pacotes irmãos com nomes aleatórios ou adições repentinas de dependências. Implemente instalações somente com arquivo de bloqueio para evitar a resolução automática de dependências. |
Postura Defensiva
Chegou a era dos worms de cadeia de suprimentos que se propagam sozinhos. A defesa exige automação, vigilância e controles arquitetônicos que pressuponham a possibilidade de comprometimento, em vez de apenas torcer pela detecção. Cada instalação de pacote é um vetor de infecção em potencial. Cada credencial é um mecanismo de propagação. A questão não é mais se os ataques ocorrerão, mas sim a rapidez com que você poderá detectá-los e contê-los quando acontecerem.
A defesa contra pacotes maliciosos do tipo worm exige uma mudança da varredura reativa para a prevenção proativa e o monitoramento contínuo:
Pipeline Controles:
- Aplicar instalações somente de arquivo de bloqueio (
npm ci,yarn install --frozen-lockfile) para evitar atualizações automáticas de dependências e garantir o controle estrito da versão. - Implementar a verificação prévia de pacotes e árvores de dependências completas, bloqueando pacotes maliciosos antes da execução.
- Bloquear pacotes com características suspeitas: pacotes muito grandes, ofuscação, pré/pós-instalação inesperada. hooks.
- Exigir revisão de código para adições e atualizações de dependências.
Gerenciamento de credenciais:
- Minimize o escopo do token — os tokens de publicação devem ter como alvo apenas pacotes específicos, sempre que possível.
- Implementar tokens de curta duração com rotação automática.
- Nunca armazene tokens no código-fonte ou em variáveis de ambiente.
- Utilize contas de serviço CI dedicadas com privilégios mínimos.
Detecção e monitoramento:
- Monitore os padrões de publicação e receba alertas sobre picos incomuns de publicações de mantenedores individuais.
- Monitore os fluxos de trabalho do GitHub Actions em busca de serialização de segredos, como:
toJSON(secrets). - Adições ao fluxo de trabalho de varredura para solicitações HTTP externas.
- Detectar novos repositórios públicos com nomes incomuns ou conteúdo codificado.
- Monitore as estações de trabalho dos desenvolvedores em busca de servidores proxy inesperados. CI/CD executores, processos VNC ou consultas RPC de blockchain.
Resposta a Incidentes:
- Trate qualquer execução de instalação suspeita. hooks como um compromisso total.
- Suponha que todos os tokens nos hosts comprometidos foram roubados — faça a rotação imediatamente.
- Reconstrução afetada CI/CD Corredores de imagens limpas.
- Audite todos os pacotes pertencentes a contas comprometidas em busca de versões maliciosas.
- Verifique a persistência nos fluxos de trabalho e configurações do repositório do GitHub.
Os fornecedores de IA costumam afirmar que qualquer ferramenta pode ser usada para o bem ou para o mal. Os sistemas de IA não podem impedir completamente o uso duplo, mas podem impor obstáculos e melhorar a visibilidade forense. A verdadeira questão de design não é "a IA pode ser usada indevidamente?", mas sim "quanto de obstáculo podemos adicionar sem prejudicar a utilidade legítima?". Um fato permanece: Quebrar as regras dos sistemas de IA atuais é muito fácil.A análise de prompts maliciosos em ataques recentes mostra que o não-determinismo do LLM se estende aos seus guardrails.
Diversas ideias estão surgindo para aprimorar a segurança da IA: autenticação forte de origem, isolamento de conteúdo confiável e controles baseados em políticas para sistemas externos (com o MCP e protocolos similares entrando em cena). Só o tempo dirá se a IA se tornará a próxima arma para ataques em larga escala à infraestrutura de software livre.
Saiba Mais
- Shai-Hulud: O worm de pacotes npm explicado
- Ataque à cadeia de suprimentos Shai-Hulud 2.0 NPM
- GlassWorm: Primeiro worm autopropagável usando código invisível chega ao mercado OpenVSX – Koi Security
- Interrompendo a primeira campanha de ciberespionagem orquestrada por IA relatada – Anthropic
- Analisando os comandos de IA usados no ataque Nx
- Comprometimento generalizado da cadeia de suprimentos afeta o ecossistema npm – CISA
- Nosso plano para uma cadeia de suprimentos do npm mais segura – Blog do GitHub
Sobre o autor
Escrito por Luis rodriguez , Cofundador e CTO da Xygeni Segurança.
Luís é um físico.cist, matemático, e CISSP com mais de 20 anos de experiência em segurança de software. Ele liderou e contribuiu para importantes iniciativas de segurança em diversas áreas. SAST, SCAe tecnologias avançadas de análise de código. Hoje, ele se concentra em software supply chain security, combinando pesquisa aprofundada com engenharia prática para ajudar as equipes a defender o DevSecOps moderno. pipelines de ameaças emergentes.
