O Retorno de PhantomRaven: Detecção de Três Novas Ondas de Ataques à Supply Chain do npm
Aprofundamento CEVIU
Aprofundamento
A PhantomRaven não voltou, ela evoluiu. As três novas ondas (2, 4), detectadas entre novembro de 2025 e fevereiro de 2026, não são uma repetição da campanha original de outubro de 2025, mas uma operação reestruturada com táticas mais sutis: rotação ativa de contas npm descartáveis, domínios C2 registrados sob padrões temáticos de artefato (ex: 'canvas-artifacts', 'forge-palette') e payloads que agora se autodesativam sob inspeção, como o da Onda 2, que passou a retornar apenas 'Hello, world!' após 12 de março de 2026. Isso não é falha técnica; é controle operacional em tempo real sobre dependências carregadas via HTTP, explorando uma brecha estrutural no npm: o suporte nativo a Remote Dynamic Dependencies (RDD), que permite URLs arbitrárias no package.json e execução imediata do payload durante npm install, sem que o código malicioso jamais toque o registro.
O fato de dois servidores C2 ainda estarem ativos em março de 2026, instâncias EC2 expostas na porta 80, sem criptografia, com endpoints PHP fixos (jpd.php, npm.php), mostra que os atacantes priorizam simplicidade funcional sobre sofisticação. Eles não precisam de infraestrutura oculta: usam nuvem legítima, tráfego HTTP claro e redundância tripla (GET/POST/WebSocket) para garantir exfiltração mesmo com bloqueios parciais. Essa abordagem é barata, difícil de correlacionar e altamente eficaz contra equipes que confiam cegamente em pacotes com SLSA ou proveniência válida, como demonstrado pelo ataque Miasma em junho de 2026, que também usou credenciais roubadas de um funcionário da Red Hat.
Por que isso importa
Esses ataques não são testes acadêmicos. São operações em escala industrial: o npm foi alvo de 10.819 pacotes maliciosos em 2025, quase 90% de todas as detecções em registros de código aberto. A PhantomRaven é parte de um padrão dominante, a cadeia de suprimentos virou o vetor de intrusão mais frequente em 2025 e 2026. Empresas que não bloqueiam tráfego HTTP de saída para domínios suspeitos, não auditam pipelines CI/CD quanto à exposição de tokens em logs ou não exigem aprovação explícita para dependências remotas estão deixando portas abertas para coleta massiva de credenciais de GitHub, GitLab, Jenkins, AWS e Kubernetes, dados que permitem escalonamento lateral imediato em ambientes corporativos.
Perguntas frequentes
Por que o uso de HTTP em texto claro na porta 80 é uma ameaça real, e não só um erro de configuração?
Porque o tráfego HTTP não criptografado é fácil de inspecionar por firewalls e proxies, mas também fácil de falsificar e misturar com tráfego legítimo. Atacantes usam essa simplicidade para evitar detecção por ferramentas que só analisam payloads estáticos, o verdadeiro malware é baixado e executado em tempo real, fora do escopo de scanners tradicionais de SCA ou SAST.
O que torna as Remote Dynamic Dependencies (RDD) tão perigosas comparadas a pacotes maliciosos convencionais?
RDDs não armazenam código malicioso no registro npm. O payload é carregado dinamicamente via URL durante a instalação, o que permite aos atacantes entregar versões diferentes conforme o contexto, limpas para pesquisadores, maliciosas para alvos reais. Isso quebra o modelo de confiança baseado em hashes, proveniência e SLSA, pois a assinatura cobre apenas o pacote vazio, não o conteúdo remoto.
Como o anúncio do npm 12 (julho de 2026) muda a defesa prática contra campanhas como PhantomRaven?
A versão 12 impõe bloqueio por padrão: scripts de instalação (preinstall/install/postinstall) e resolução de dependências remotas (URLs HTTPS, repositórios Git) exigirão aprovação explícita. Isso elimina a execução silenciosa de payloads RDD e força revisão humana ou automação com políticas rígidas, um ponto de fricção necessário para interromper cadeias de ataque automatizadas.
Fontes
- endorlabs.comfonte original
- Categoria
- CEVIU Segurança da Informação
- Publicado
- 16 de março de 2026
- Editoria
- CEVIU Segurança da Informação
