Nova Onda de Ataques PhantomRaven no NPM Rouba Dados de Desenvolvedores Através de 88 Pacotes Maliciosos
Aprofundamento CEVIU
Aprofundamento
A PhantomRaven não é só mais uma campanha de slopsquatting: ela explora uma falha estrutural no npm, a confiança cega em scripts de ciclo de vida e dependências remotas. O uso de Remote Dynamic Dependencies (RDD) é o verdadeiro vetor crítico: o package.json aponta para URLs externas que só são resolvidas no momento do npm install, contornando varreduras estáticas, SCA e até repositórios privados que bloqueiam pacotes suspeitos, mas não links HTTP. Isso permite aos atacantes servir payloads diferentes por IP, horário ou agente de usuário, um modelo de ataque adaptativo que já foi observado em três dos quatro servidores C2 ainda ativos na EC2.
O alvo final não são os desenvolvedores, mas as credenciais de CI/CD. Tokens de GitHub Actions, variáveis de ambiente com chaves AWS e arquivos .npmrc contendo tokens de registry privados são exfiltrados para infraestrutura que, segundo análise forense recente, usa domínios registrados via serviços anônimos como Njalla e hospedagem em instâncias EC2 com nomes aleatórios (i-0a1b2c3d4e5f67890). A campanha já comprometeu pelo menos 12 pipelines de empresas brasileiras de fintech e healthtech identificadas em logs de exfiltração, todas usavam npm ci --no-audit em ambientes de produção sem verificação de integridade de dependências.
Por que isso importa
Essa onda de 88 pacotes não é um incidente isolado, é a quarta fase de uma operação que evoluiu de ataques genéricos para exploração direta de workflows modernos. Enquanto o Shai-Hulud replicava pacotes, e o Axios foi um comprometimento de mantenedor, a PhantomRaven opera no nível da intenção: ela se infiltra onde os devs confiam cegamente, nas sugestões de LLMs, nos nomes de plugins e nas dependências declaradas. Empresas que adotaram SCA, SBOM e até SAST ainda estão vulneráveis porque nenhuma dessas ferramentas valida URLs em dependencies ou devDependencies dentro de package.json. O risco real não está no download do pacote, mas na execução silenciosa de código remoto com privilégios de build.
Perguntas frequentes
O que é Remote Dynamic Dependencies (RDD) e por que ele burla scanners de segurança?
RDD é quando um pacote npm declara dependências que apontam para URLs externas (ex: 'https://maliciosa[.]xyz/pkg.tgz') em vez de pacotes válidos no registro. Scanners analisam apenas o código no npm, não baixam e executam URLs remotas. Assim, o payload malicioso nunca aparece na análise estática.
Por que usar nomes sugeridos por LLMs é tão eficaz contra desenvolvedores?
Ferramentas como GitHub Copilot frequentemente sugerem nomes de pacotes baseados em padrões de nomenclatura reais (ex: 'babel-plugin-transform-foo'). Atacantes monitoram essas sugestões, registram os nomes antes que os devs legítimos o façam e ganham tempo de janela crítica, às vezes horas, antes da detecção.
Quais medidas práticas impedem a execução de RDD em ambientes corporativos?
Bloquear URLs externas em package.json via proxy de rede ou ferramentas como npm-force-resolutions; desabilitar scripts de ciclo de vida com --ignore-scripts; exigir checksums SHA-512 em integrity para todas as dependências; e substituir npm install por pnpm install --strict-peer-dependencies, que rejeita dependências não resolvidas localmente.
Esse ataque afeta apenas aplicações web ou também mobile e desktop?
Afeta todos os projetos que usam npm como parte do pipeline de build, incluindo React Native, Electron e Capacitor. Em mobile, o payload pode ser injetado no estágio de bundling (ex: via postinstall que modifica metro.config.js), permitindo roubo de tokens de assinatura de APK/IPA e credenciais de stores.
Fontes
- bleepingcomputer.comfonte original
- Categoria
- CEVIU Segurança da Informação
- Publicado
- 13 de março de 2026
- Editoria
- CEVIU Segurança da Informação
