Pacotes maliciosos no npm se passam por utilitários PostCSS e instalam RAT em Windows

Pesquisadores do JFrog identificaram um novo conjunto de pacotes maliciosos no npm, publicados pelo usuário “abdrizak” no último mês, que se disfarçam de utilitários PostCSS para instalar um trojan de acesso remoto (RAT) em sistemas Windows. O ataque mira diretamente desenvolvedores, abusando do typosquatting contra a biblioteca legítima postcss-selector-parser — que registra mais de 127 milhões de downloads semanais — e adiciona mais um capítulo à escalada de incidentes de supply-chain em registries de código aberto.

O que aconteceu

Os pacotes em questão — aes-decode-runner-pro, postcss-minify-selector-parser e postcss-minify-selector — foram publicados ao longo das últimas semanas e, segundo a JFrog, continuavam disponíveis para download no momento da publicação da análise. Dois deles se apresentam como bibliotecas de codificação AES em camadas, enquanto o terceiro finge ser um minificador de seletores PostCSS. Para parecerem confiáveis, declaram dependências do legítimo postcss-selector-parser.

O nome “postcss-minify-selector-parser” foi escolhido para confundir desenvolvedores com o pacote autêntico, usado em milhões de pipelines de build no ecossistema JavaScript. Como o registro npm não bloqueia automaticamente nomes próximos, esse tipo de typosquatting continua sendo uma das técnicas mais eficientes para distribuir malware via dependências.

Independentemente do pacote instalado, todos convergem para a mesma cadeia de execução e resultam no mesmo payload final: um RAT modular para Windows escrito em Python.

Como o ataque funciona

A execução começa logo na instalação. Um dropper JavaScript grava em disco um script PowerShell chamado settings.ps1 e o executa. Esse script, por sua vez, atua como downloader, baixando um arquivo ZIP do domínio externo nvidiadriver[.]net usando o binário nativo curl.exe — uma técnica de living-off-the-land que reduz a detecção por soluções de endpoint.

O arquivo ZIP traz dentro dele um script VBScript (update.vbs) executado via wscript.exe, um runtime Python completo, um loader Python (loader.py) e uma série de módulos de extensão (.pyd) compilados com Nuitka — abordagem que dificulta a engenharia reversa, já que o código aparece como binários nativos em vez de bytecode Python convencional.

“Aes-decode-runner-pro e postcss-minify-selector-parser se apresentam como pacotes de codecs AES em camadas e dependem do legítimo postcss-selector-parser. Postcss-minify-selector se apresenta como um minificador de seletores PostCSS e depende de postcss-minify-selector-parser”, afirmou a JFrog em sua análise.

O VBScript prepara o ambiente Python na máquina comprometida e dispara o loader.py, que aciona a lógica central do RAT. A partir daí, o operador remoto consegue coletar informações do host, exfiltrar credenciais armazenadas pelo Google Chrome, capturar dados de extensões do navegador, executar comandos shell arbitrários e fazer upload e download de arquivos para um servidor de comando e controle hospedado em 95.216.92[.]207, porta 8000.

Quem é afetado

A campanha mira diretamente o ambiente do desenvolvedor — historicamente um vetor de alto retorno para invasores, porque a máquina de quem escreve código costuma armazenar credenciais privilegiadas e ter conexões com pipelines de produção. Estão em risco:

• Desenvolvedores front-end e DevOps que integraram qualquer um dos três pacotes em seus projetos nas últimas semanas
• Pipelines de CI/CD que executam npm install sem isolamento, propagando a infecção para runners e servidores de build
• Equipes que reutilizam credenciais salvas no Chrome do desenvolvedor para acessar repositórios, dashboards de cloud ou consoles administrativos
• Organizações com extensões corporativas instaladas no navegador do desenvolvedor (cofres de senhas, autenticadores, gerenciadores de sessão SSO)

Análise

O caso reforça uma tendência que vem ganhando força ao longo de 2026: o ecossistema npm deixou de ser apenas um alvo oportunista e passou a ser um terreno de operações organizadas, com pacotes maliciosos descobertos em sequência e, frequentemente, encadeados em operações maiores. A JFrog destaca que essa atividade ocorre em paralelo a outras três campanhas contra npm e TypeScript, incluindo um ataque a uma ferramenta de grafo de conhecimento que utiliza a blockchain Tron para resolver payloads de segundo estágio — uma técnica de C2 descentralizado que torna a remoção da infraestrutura muito mais difícil.

O padrão também converge com a operação PolinRider, atribuída à Coreia do Norte, que vem injetando JavaScript ofuscado em arquivos de configuração de quase 2.000 repositórios legítimos no GitHub. Em conjunto, esses incidentes mostram que invasores estatais e financeiramente motivados estão usando o mesmo playbook: contaminar uma dependência transitiva, manter a aparência funcional do pacote e esperar que o build alheio rode o malware. Para os defensores, isso significa que confiar em revisão visual de package.json não é mais suficiente — é necessário inspecionar o que cada dependência efetivamente executa em postinstall e o que os módulos compilados realmente fazem em runtime.

Outro ponto digno de atenção é o uso de Nuitka. Compilar Python em binários nativos é um movimento que vinha sendo observado em famílias de stealers e infostealers, mas agora começa a aparecer também em payloads distribuídos via supply-chain de bibliotecas web. A consequência prática é que assinaturas baseadas apenas em strings Python ou imports padrão tendem a falhar, exigindo análise comportamental e correlação de eventos de processo.

Recomendações práticas

• Verifique imediatamente se aes-decode-runner-pro, postcss-minify-selector-parser ou postcss-minify-selector estão presentes em package.json, lockfiles ou caches de pacote em qualquer máquina ou runner.
• Remova os pacotes, apague o diretório node_modules e regere o lockfile a partir de uma fonte limpa.
• Bloqueie o domínio nvidiadriver[.]net e o IP 95.216.92[.]207 nos firewalls de rede e nos proxies de saída.
• Rote credenciais salvas no Chrome em qualquer máquina suspeita — incluindo tokens de cloud, chaves SSH, credenciais Git e cookies de sessão.
• Caça dirigida (threat hunting): procure execuções de powershell.exe iniciadas por node.exe, curl.exe baixando de domínios desconhecidos para o usuário, e wscript.exe executando arquivos .vbs vindos de %TEMP%.
• Considere adotar políticas de allowlist de pacotes ou registries internos espelhados, com revisão obrigatória antes de promover novas dependências.
• Ative monitoramento de execução de scripts postinstall — desativá-los por padrão em ambientes de CI é uma medida mitigadora poderosa.

Fonte: The Hacker News