Versões maliciosas do `node-ipc` roubam segredos de desenvolvedores e usam canal DNS para exfiltração

Pacote npm recebeu três versões comprometidas com backdoor e stealer acionado em tempo de execução, mirando credenciais de nuvem, chaves SSH, tokens Kubernetes, configurações de CLI e artefatos de desenvolvimento.

Componente	Pacote npm node-ipc, especificamente as versões node-ipc@9.1.6, node-ipc@9.2.3 e node-ipc@12.0.1.
Vetor	Carga maliciosa anexada ao arquivo node-ipc.cjs como uma IIFE, executada quando o pacote é carregado por require('node-ipc'), sem depender de scripts preinstall, install ou postinstall.
Impacto	Coleta e tentativa de exfiltração de segredos de desenvolvimento e nuvem, incluindo credenciais AWS, Google Cloud, Azure, chaves SSH, tokens Kubernetes, configurações de GitHub CLI, estados Terraform, histórico de shell e senhas de bancos de dados.
Prioridade	Remover as versões comprometidas, reinstalar versões limpas conhecidas como 9.2.1 ou 12.0.0, rotacionar segredos expostos e bloquear tráfego de saída para sh.azurestaticprovider[.]net.
Versões	node-ipc@9.1.6 e node-ipc@9.2.3 executam a carga de forma ampla quando carregadas; node-ipc@12.0.1 inclui uma verificação de impressão digital por SHA-256 que torna a execução condicionada a um caminho de módulo específico.
IoCs	Domínio de comando e controle informado: sh.azurestaticprovider[.]net; técnica adicional: exfiltração por consultas DNS TXT redirecionadas ao IP do C2.
Artefatos	Conta publicadora atiertant, arquivo node-ipc.cjs, domínio de e-mail atlantis-software[.]net associado a uma hipótese de recuperação de conta por domínio expirado.

Resumo técnico

Três versões recentes do pacote npm node-ipc foram identificadas com comportamento malicioso compatível com stealer e backdoor. O comprometimento afeta node-ipc@9.1.6, node-ipc@9.2.3 e node-ipc@12.0.1, publicadas em um pacote conhecido do ecossistema JavaScript. A carga não age como um instalador malicioso tradicional: ela foi incorporada ao arquivo node-ipc.cjs e passa a executar quando a aplicação carrega o módulo por require('node-ipc'). Isso amplia o risco para ambientes em que o pacote já está presente em dependências diretas ou transitivas, porque a execução depende do uso do módulo em tempo de execução, não apenas do momento de instalação.

O objetivo observado é coletar segredos locais de desenvolvedores e de ambientes de automação. A carga enumera o host, procura arquivos e configurações associados a credenciais, compacta os dados em um arquivo GZIP, divide o conteúdo em partes e tenta exfiltrar o material por rede. Entre os alvos estão credenciais de AWS, Google Cloud e Microsoft Azure, chaves SSH, tokens Kubernetes, configurações de GitHub CLI, arquivos de estado do Terraform, configurações de Claude AI e Kiro IDE, senhas de bancos de dados e histórico de shell. O conjunto de dados visado indica foco em identidades técnicas usadas para publicar código, administrar infraestrutura, executar pipelines e acessar serviços de nuvem.

Fluxo técnico

A técnica de execução é relevante para defesa porque evita os pontos de controle mais comuns em ataques npm. Muitas campanhas de supply chain usam scripts de ciclo de vida, como preinstall, install ou postinstall, para executar código durante a instalação do pacote. Neste caso, a carga foi anexada como uma IIFE no fim de node-ipc.cjs. Quando uma aplicação importa o pacote, a função é invocada imediatamente e aciona a enumeração do ambiente. Isso significa que ambientes que bloqueiam scripts de instalação ainda podem ser afetados se resolverem e executarem uma das versões comprometidas em produção, testes, estáções de desenvolvimento ou tarefas de CI/CD.

As versões da linha 9.x apresentam risco amplo porque não dependem de uma condição de alvo específica para disparar a coleta. Já node-ipc@12.0.1 contém uma etapa de verificação por SHA-256: a carga monta um hash a partir de fragmentos ofuscados no código e compara o resultado com uma impressão digital esperada antes de continuar. Esse comportamento reduz a execução em hosts aleatórios e sugere uma tentativa de mirar um projeto ou desenvolvedor cujo caminho de módulo principal já era conhecido. Para defesa, essa diferença importa porque uma instalação de 12.0.1 aparentemente inerte em um laboratório não elimina o risco em um ambiente cujo caminho de execução satisfaça a condição codificada.

Depois da etapa de acionamento, o malware procura artefatos locais associados a identidades técnicas. O conteúdo coletado é compactado em GZIP e enviado por HTTPS POST ao domínio sh.azurestaticprovider[.]net, que imita visualmente uma propriedade legítima relacionada a nuvem. A carga também implementa um segundo caminho de exfiltração por DNS. Primeiro, resolve o domínio usando 1.1.1.1 como resolvedor primário e 8.8.8.8 como fallback para obter o IP do C2. Em seguida, passa a direcionar consultas diretamente ao IP obtido e codifica partes do arquivo como registros DNS TXT. Essa escolha reduz a visibilidade de organizações que dependem apenas de logs de resolvedores corporativos, porque as consultas podem não passar pela infraestrutura DNS monitorada.

Outro detalhe operacional é a tentativa de continuidade fora do processo original do Node.js. A carga tenta criar processos filhos em segundo plano e de forma destacada, permitindo que a exfiltração prossiga mesmo depois de a aplicação pai ser encerrada. Esse comportamento exige que a contenção não se limite a remover a dependência do projeto. Em estáções de desenvolvedores, runners de CI e servidores de build, é necessário verificar processos Node.js órfãos, conexões de saída persistentes, arquivos temporários de compactação e atividades de leitura massiva em diretórios de configuração, chaves e caches de ferramentas.

Superfície afetada

A superfície principal inclui qualquer ambiente que tenha resolvido, instalado ou executado node-ipc@9.1.6, node-ipc@9.2.3 ou node-ipc@12.0.1. O risco não se restringe a aplicações que declaram node-ipc diretamente em package.json; dependências transitivas, caches de gerenciadores de pacote, imagens de build, ambientes de teste e artefatos gerados durante pipelines também devem ser considerados. Como a execução ocorre ao carregar o módulo, a simples presença no lockfile não confirma execução, mas é um indicador suficiente para investigação, especialmente quando há logs mostrando tarefas Node.js, testes automatizados, bundles ou serviços que importaram a dependência.

A conta atiertant foi usada para publicar as versões comprometidas e aparece como mantenedora, mas não tinha histórico anterior de publicação associado ao pacote. O pacote havia ficado sem atualização por um longo período antes das versões maliciosas. Uma hipótese técnica para o acesso de publicação envolve o domínio atlantis-software[.]net, associado ao e-mail da conta, que expirou em 2025-01-10 e foi registrado novamente em 2026-05-07. Se esse domínio era usado para recuperação de senha, o novo controlador poderia receber mensagens de redefinição e obter acesso à conta npm sem comprometer diretamente a infraestrutura original do mantenedor. Essa hipótese deve orientar auditoria de domínio expirado e de contas de publicação antigas em projetos internos.

Os segredos mais expostos são aqueles disponíveis em disco ou variáveis locais no momento da execução. Isso inclui diretórios de configuração de nuvem, arquivos de credenciais de CLI, chaves privadas SSH, tokens de acesso a repositórios, credenciais de bancos de dados, estados Terraform com material sensível, kubeconfigs, históricos de shell e configurações de ferramentas de IA ou IDEs que armazenam tokens. Em CI/CD, o impacto pode se estender a permissões de publicação npm, acesso a repositórios privados, leitura ou alteração de infraestrutura de nuvem e movimentação lateral entre ambientes quando o mesmo segredo é reutilizado.

O histórico do pacote também aumenta a necessidade de validação rigorosa. Em 2022, versões anteriores do node-ipc receberam comportamento destrutivo relacionado a sistemas localizados na Rússia ou Belarus, e versões subsequentes incluíram a dependência peacenotwar. O caso atual, porém, tem outra natureza: trata-se de republicação suspeita de versões com coleta e exfiltração de segredos, sem caracterização de typosquatting. Para operadores, o ponto central é tratar versões comprometidas de um pacote conhecido como risco de cadeia de suprimentos, mesmo quando o nome do pacote parece familiar e o projeto tem longo histórico de uso.

• Projetos com node-ipc@9.1.6, node-ipc@9.2.3 ou node-ipc@12.0.1 em package-lock.json, npm-shrinkwrap.json, yarn.lock ou pnpm-lock.yaml.
• Estáções de desenvolvimento e runners de CI que executaram require('node-ipc') durante testes, builds, scripts auxiliares ou serviços Node.js.
• Ambientes com credenciais locais de nuvem, kubeconfig, chaves SSH, configurações de GitHub CLI, estados Terraform, históricos de shell ou senhas de banco de dados acessíveis ao usuário do processo.
• Contas npm, domínios de e-mail e mantenedores antigos com fluxo de recuperação de senha dependente de domínios expirados ou não monitorados.

Hunting e telemetria

A investigação deve começar pela resolução de dependências. Procure as três versões comprometidas em lockfiles, caches npm, artefatos de build, imagens de contêiner, diretórios node_modules persistidos e logs de instalação. Como o vetor não depende de scripts de instalação, hunting baseado apenas em execução de postinstall é insuficiente. A busca deve correlacionar quando a versão foi baixada, em qual host foi carregada, qual usuário executou o processo Node.js e quais segredos estavam acessíveis naquele contexto. Em pipelines, revisar logs de execução ajuda a identificar jobs que importaram o pacote e tinham variáveis sensíveis, tokens de publicação ou credenciais de nuvem injetadas.

No endpoint, procure leituras incomuns em diretórios de configuração de nuvem, SSH, Kubernetes, Terraform, bancos de dados, CLIs de desenvolvimento e históricos de shell por processos Node.js. Verifique criação de arquivos compactados temporários, uso anormal de CPU ou I/O durante builds, processos filhos destacados, processos Node.js que sobrevivem ao encerramento do processo pai e conexões de saída logo após importação do módulo. O domínio sh.azurestaticprovider[.]net deve ser tratado como indicador de rede, mas a ausência desse domínio em logs corporativos não é evidência de limpeza, pois a carga também pode usar DNS direto ao C2.

Na camada de rede, examine tráfego HTTPS para sh.azurestaticprovider[.]net e consultas DNS fora dos resolvedores autorizados, especialmente para 1.1.1.1, 8.8.8.8 ou IPs externos usados diretamente como resolvedores. O canal por DNS TXT pode aparecer como volume incomum de consultas longas, alta entropia em nomes consultados, padrões de fragmentação ou consultas originadas por hosts de build que normalmente não fazem resolução direta. Em ambientes com egress control, uma regra que permite DNS arbitrário para a internet reduz a capacidade de conter esse tipo de exfiltração.

Em nuvem e identidade, faça hunting retrospectivo para uso anômalo de chaves e tokens que estavam disponíveis nos hosts afetados. Procure chamadas de API fora de regiões, horários, endereços IP, agentes de usuário ou padrões de serviço usuais. Em AWS, Google Cloud e Azure, a prioridade é identificar operações administrativas, criação de chaves, leitura de segredos, alteração de políticas, enumeração de recursos e uso de credenciais de automação após a janela de exposição. Em repositórios e registries, revise publicações de pacotes, criação de tokens, alterações em workflows, abertura de secrets, pushes inesperados e downloads de repositórios privados.

• Presença de node-ipc@9.1.6, node-ipc@9.2.3 ou node-ipc@12.0.1 em lockfiles, caches, imagens e diretórios node_modules.
• Execução de node seguida de leitura de arquivos de ~/.aws, ~/.config/gcloud, configurações Azure, .ssh, kubeconfig, estados Terraform, GitHub CLI e históricos de shell.
• Conexões HTTPS para sh.azurestaticprovider[.]net ou resolução direta via 1.1.1.1, 8.8.8.8 e IPs externos usados como resolvedores.
• Consultas DNS TXT longas, fragmentadas ou de alta entropia originadas por estáções de desenvolvimento, runners de CI ou servidores de build.
• Processos Node.js destacados, órfãos ou em segundo plano após encerramento do build, teste ou aplicação que carregou node-ipc.

Mitigação

A resposta deve tratar hosts que executaram as versões comprometidas como potencialmente expostos. O primeiro passo é remover node-ipc@9.1.6, node-ipc@9.2.3 e node-ipc@12.0.1 de dependências diretas e transitivas, atualizar lockfiles e reinstalar versões limpas conhecidas, como 9.2.1 ou 12.0.0, quando compatíveis com o projeto. Em seguida, invalide caches de dependências, refaça imagens de build e impeça que pipelines reutilizem artefatos produzidos durante a janela de exposição. A simples alteração de package.json não basta se runners, contêineres ou caches ainda contiverem a versão maliciosa.

A rotação de segredos deve ser ampla e orientada pelo escopo real do host afetado. Devem ser rotacionadas credenciais de nuvem, tokens de GitHub CLI, chaves SSH, tokens Kubernetes, senhas de banco de dados, tokens de publicação npm, credenciais de CI/CD e qualquer segredo armazenado em arquivos de configuração ou variáveis acessíveis ao processo. Estados Terraform e caches de ferramentas precisam ser avaliados porque podem conter credenciais ou referências sensíveis. Sempre que possível, substitua segredos persistentes por credenciais temporárias, restrinja permissões por função e aplique políticas que limitem leitura, publicação e alteração de infraestrutura por identidades de build.

Na rede, bloqueie e monitore sh.azurestaticprovider[.]net, mas também feche a saída DNS direta para a internet. Hosts corporativos e runners devem resolver nomes apenas por resolvedores autorizados e registrados. Regras de firewall ou proxy devem impedir que processos de build enviem DNS para 1.1.1.1, 8.8.8.8 ou destinos arbitrários, exceto quando houver necessidade documentada. Para HTTP e HTTPS, aplique allowlists por função em ambientes de CI/CD, registrando destino, processo e job responsável. Essa contenção reduz a eficácia de canais alternativos de exfiltração mesmo quando o domínio principal muda.

Também é necessário revisar governança de publicação e manutenção de pacotes. Organizações que publicam pacotes npm devem auditar mantenedores, e-mails de recuperação, domínios expirados, tokens antigos e contas inativas. Contas com poder de publicação precisam de autenticação forte, e domínios associados a e-mails de recuperação não devem expirar sem descomissionamento formal. Para consumo de dependências, repositórios internos devem exigir lockfiles revisados, pinagem de versões, verificação de diffs em pacotes publicados e alertas quando um pacote dormente recebe atualização repentina por uma conta sem histórico esperado.

• Substituir as versões comprometidas por 9.2.1 ou 12.0.0, atualizar lockfiles e reconstruir artefatos sem reutilizar caches afetados.
• Rotacionar credenciais de AWS, Google Cloud, Azure, SSH, Kubernetes, GitHub CLI, npm, bancos de dados, CI/CD e segredos presentes em estados Terraform.
• Bloquear sh.azurestaticprovider[.]net e impedir DNS direto para fora dos resolvedores corporativos autorizados.
• Revisar logs de nuvem, repositórios, registries e pipelines para ações realizadas por identidades cujos segredos estavam disponíveis no período de exposição.
• Auditar contas npm mantenedoras, e-mails de recuperação e domínios expirados associados a permissões de publicação.