PhantomRaven a campanha de dependências remotas que coloca em jaque npm

Nos últimos meses, a comunidade JavaScript voltou a receber um lembrete desconfortável: as cadeias de fornecimento de software continuam sendo um dos vectores favoritos para os atacantes. Uma campanha conhecida como "PhantomRaven", inicialmente detectada no final de 2025 e ampliada por pesquisas posteriores, tem publicado pacotes maliciosos no registro npm com a intenção de roubar dados sensíveis de desenvolvedores e ambientes de integração contínua.

A peculiaridade técnica do PhantomRaven é seu uso de dependências dinâmicas remotas (Remote Dynamic Dependencies, RDD), uma tática simples mas eficaz: em vez de incorporar o código malicioso dentro do pacote publicado, os atacantes apontam do arquivo package.json para uma dependência hospedada em um URL externo. Ao executar o npm install essa dependência é descarregada a partir do servidor do atacante e executada, sendo a verificação estática automatizada que analisa o conteúdo do pacote no registo. Você pode ver uma explicação técnica de como o npm interpreta package.json na documentação oficial do npm: https://docs.npmjs.com/cli/v9/configuring-npm/package-json.

As pesquisas públicas sobre PhantomRaven, entre elas a da empresa Endor Labs, descrevem várias ondas de publicação: após a descoberta inicial, foram detectadas novas rodadas entre novembro de 2025 e fevereiro de 2026 em que os atacantes lançaram dezenas de pacotes desde contas descartáveis. Endor Labs documenta em detalhe a persistência da campanha, a consistência do payload e a infraestrutura associada; o seu relatório está disponível aqui: https://www.endorlabs.com/learn/return-of-phantomraven. Segundo essas análises, muitas das amostras seguem acessíveis no registro npm.

Outro traço recorrente na campanha é o emprego de técnicas de "slopsquatting" ou typosquatting: os pacotes maliciosos tentam parecer-se a projetos legítimos muito usados - por exemplo Babel ou GraphQL Codegen - publicando nomes que poderiam ser confundidos com os sugeridos por assistentes automáticos ou por quem copia e pega precipitadamente uma recomendação. A combinação de nomes convincentes e a dependência remota reduz a probabilidade de detecção e aumenta a probabilidade de um desenvolvedor instalar o pacote por erro.

Uma vez que o código malicioso chega à máquina, seu objetivo é claro e perigoso: coletar informações que permitam ao atacante mover-se lateralmente ou exfiltrar segredos. Endor Labs observa que as amostras buscam arquivos e configurações locais como .gitconfig e .npmrc, variáveis de ambiente e tokens utilizados por pipelines CI/CD —GitHub, GitLab, Jenkins, CircleCI—; também recolhem vestígios do sistema (IP, hostname, versão de Node) para perfilar a vítima. O envio dos dados para o servidor de controle e comando (C2) é normalmente realizado por HTTP GET, embora os autores também usaram POST e WebSocket para garantir redundância.

A infraestrutura usada por PhantomRaven mostrou padrões repetidos: domínios que incluem a palavra "artifact", servidores na Amazon EC2 frequentemente careciam de certificado TLS, e um payload cuja maior parte do código permaneceu inalterada entre ondas. Ainda assim, os operadores rotaram contas de npm e e-mails, ajustaram metadados e mudaram endpoints PHP para se manter operacionais com mudanças mínimas.

Isto deixa várias lições práticas para qualquer desenvolvedor ou equipe de segurança. Primeiro, não existe atalho: verificar a proveniência de um pacote e sua publicação é mais importante do que nunca. Não basta copiar o sugerido por um chatbot ou colar sem olhar um nome que "suena bem". Inspeccionar o package.json, rever o autor e a reputação do publicador, e verificar a existência de um repositório de fonte razoável são passos simples que podem evitar muitas surpresas desagradáveis. Para aqueles que gerem pipelines e repositórios, é recomendável activar ferramentas de digitalização de dependências e detecção de segredos que estejam integradas no fluxo de trabalho; o GitHub oferece capacidades de secret scanning e o Dependabot para atualizações de segurança que ajudam a reduzir o risco: https://docs.github.com/en/code-security/secret-scanning.

Também é conveniente aplicar controlos de segurança nos tokens e credenciais: limitar o alcance dos tokens CI/CD, rotar periodicamente e não expor em arquivos que possam ser lidos por processos de terceiros. A nível organizacional, a prática de construir artefatos em ambientes isolados e de usar allowlists de pacotes confiáveis (em vez de instalar pacotes desde o registro público sem supervisão) reduz a superfície de ataque. Recursos como OWASP e análise de cadeias de fornecimento oferecem orientações úteis sobre higiene de dependências e detecção precoce: https://owasp.org/www-project-dependency-check/.

Existem também soluções comerciais e comunitárias que podem ajudar a mitigar riscos: scanners de segurança de dependências, mirrors privados de pacotes, e políticas de publicação mais rigorosas nos repositórios internos. Plataformas como Snyk publicaram guias e análises sobre como as cadeias de fornecimento continuam sendo vetores críticos; ver, por exemplo, sua cobertura sobre ataques à cadeia de fornecimento: https://snyk.io/blog/supply-chain-attacks/.

Embora a técnica de PhantomRaven não seja sofisticada do ponto de vista criptográfico ou de ofuscação do código - o payload apenas mudou entre amostras -, sua eficácia reside na simplicidade operacional e na exploração de hábitos humanos: confiar em nomes, seguir exemplos sem verificar e executar instalações em ambientes com privilégios. Uma pequena mudança nos hábitos de desenvolvimento e a adopção de controlos básicos de segurança podem reduzir consideravelmente a exposição.

Se você for programador, verifique os seus projetos e pipelines: busca dependências que apontem para URLs externos em package.json, confirma que não existem pacotes desconhecidos nos seus lockfiles e considera digitalizar máquinas de desenvolvimento e runners CI com ferramentas que detectem comunicações anormais a domínios suspeitos. Se você gerir uma organização, promove políticas de confiança zero em relação a pacotes de terceiros e fornece aos equipamentos um catálogo de dependências aprovadas e atualizadas.

A indústria já teve episódios semelhantes e as soluções são, em grande parte, conhecidas. A lição é que a vigilância deve ser contínua: os atacantes repetirão padrões que funcionem e rodarão o mínimo necessário para seguir adiante. Manter-se informado, aplicar controlos técnicos e, sobretudo, verificar duas vezes antes de instalar, são passos que hoje fazem parte da segurança básica de qualquer projeto baseado em npm.