Investigadores de segurança de cadeia de fornecimento de software identificaram um conjunto de 18 pacotes maliciosos no repositório npm, concebidos para entregar um cavalo de Troia de acesso remoto (RAT) multiplataforma a programadores que utilizam ferramentas internas do Alibaba. Segundo a Socket.dev, a análise de um pacote npm malicioso, o lib-mtop, que continha um simples downloader, conduziu a uma investigação sobre uma campanha dirigida que permaneceu por detetar durante três meses. A operação distribuiu os componentes do RAT por vários pacotes para que cada peça parecesse inofensiva quando examinada isoladamente.
Resposta rápida: Um conjunto de 18 pacotes npm que imitam nomes de bibliotecas privadas do Alibaba (âmbito @ali) montou um RAT multiplataforma durante a instalação, capaz de executar comandos, roubar credenciais e mover-se lateralmente por ferramentas como o DingTalk. As equipas que instalaram qualquer um dos pacotes listados devem tratar o ambiente como comprometido, remover as dependências, rodar segredos e refazer a partir de máquinas limpas.
O que aconteceu
O ponto de partida da investigação foi o pacote lib-mtop. Trata-se de um pacote sem âmbito com o mesmo nome de um pacote privado do Alibaba sob o âmbito “@ali”; embora tenha sido publicado pela primeira vez em novembro de 2023 sem qualquer funcionalidade, três novas versões (v1.0.1, v1.0.2 e v1.0.3) foram carregadas em março e abril. Isto indica um possível controlo indevido da conta do responsável pela manutenção, embora não se possa excluir a hipótese de um mantenedor a agir de forma maliciosa.
A técnica-chave da campanha é a personificação de dependências internas. Os atacantes utilizaram uma cadeia de dependências em camadas na qual pacotes-isco de nível superior copiavam os nomes de pacotes privados sob o âmbito “ali” do Alibaba; quando um programador instalava um destes sósias, dependências adicionais forneciam o downloader e os componentes de processamento de regras. Muitos destes nomes sombreiam pacotes privados de âmbito @ali, garantindo que, em ambientes com acesso aos registos privados do Alibaba, a resolução de dependências parece legítima enquanto puxa silenciosamente módulos controlados pelo atacante.
Como funciona a cadeia de ataque
A arquitetura assenta na fragmentação deliberada da lógica maliciosa. Até 10 pacotes-isco de nível superior dependem do “smart-config-manager”, que funciona como uma ponte de camada intermédia que os liga aos pacotes maliciosos que contêm a lógica do carregador. A partir daí, um dos pacotes de camada inferior contacta um repositório GitHub para obter e armazenar uma configuração de motor de regras e, depois, utiliza-a para executar uma carga maliciosa que contacta um servidor remoto para obter malware secundário; o notável é que o motor de regras recorre ao módulo vm para realizar o download dependendo do sistema operativo da vítima, sendo o payload obtido de um domínio que se faz passar pelo Alibaba (aone-cli-next.oss-cn-beijing.aliyuncs[.]com) para se misturar e escapar à deteção.
O aspeto engenhoso é que cada componente é, isoladamente, defensável. O pacote local-config-parser, descrito como “analisador de ficheiros de configuração JSON com motor de avaliação de regras embutido”, implementa realmente essa lógica: analisa regras de um ficheiro JSON local e avalia-as usando o módulo vm do Node.js, comunicando apenas com o sistema local — nada de suspeito à primeira vista. Individualmente, estes pacotes pareciam inofensivos; combinados, formavam uma cadeia de entrega de malware por fases.
Nas fases seguintes, o comportamento diverge consoante o sistema. O script de terceira fase setting.js realiza reconhecimento do host e identificação do sistema operativo e, em seguida, obtém uma carga aone-cli de quarta fase adaptada à plataforma da vítima, estabelecendo persistência de formas específicas de cada SO. No macOS, planta um script de fundo malicioso via ~/.zshrc e um Launch Agent com intervalo de dez minutos; no Windows, tenta terminar a aplicação de segurança oficial Alilang e substituir o seu núcleo app.asar por uma versão trojanizada.
O RAT aone-cli e as suas capacidades
A carga final é um backdoor complexo equipado com execução de comandos abrangente, upload e download arbitrário de ficheiros, reconhecimento do host, encenação de cargas e capacidades de movimento lateral; tem ainda a capacidade de persistir injetando código malicioso em aplicações de colaboração empresarial comuns como o DingTalk, o Wukong e o Qoder. O RAT emite beacons automaticamente para um endpoint C2 codificado, sondando por comandos, e expõe um conjunto estruturado de comandos (como info, pwd, screenshot, download, proxy, run_python, install_node_module, aipoison e dws_lateral), reencaminhando quaisquer instruções não reconhecidas diretamente para a shell do SO.
Para escapar à deteção de rede, o tráfego para o servidor C2 é disfarçado com cabeçalhos falsos de Origin e Referer apontando para alidocs.dingtalk.com, misturando-se com o tráfego legítimo para os domínios oficiais de documentação do DingTalk. A componente de roubo de dados é ampla: segundo a SafeDep, o malware “tinha três mecanismos de persistência separados instalados que mantêm um stealer em execução muito depois de o pacote ser desinstalado” e “o roubo de credenciais visa ambientes de investigação e HPC, recolhendo filas de tarefas SLURM e inventários de GPU juntamente com os habituais segredos de nuvem”.
Cronologia da campanha
| Data | Evento |
|---|---|
| Novembro de 2023 | Primeira publicação de lib-mtop, sem funcionalidade e com poucos downloads |
| Final de março de 2026 | Três novas versões de lib-mtop transformam-no num carregador malicioso |
| 27–28 de abril de 2026 | Encenação coordenada; smart-config-manager e módulos dependentes publicados a partir de contas npm recém-criadas |
| Julho de 2026 | Divulgação pública da investigação, após cerca de três meses sem deteção |
A correlação temporal da criação de contas e da atividade de publicação sugere encenação coordenada entre 27 e 28 de abril de 2026: node-data-utils e fast-transform-pipeline parecem ter sido usados como veículos de teste para a entrega do carregador multipacote, enquanto o smart-config-manager e os seus módulos dependentes foram publicados a 28 de abril a partir de várias contas npm recém-criadas.
Indicadores e pacotes a verificar
O conjunto malicioso identificado abrange os seguintes 18 pacotes: lib-mtop, aone-kit, aone-kit-cli, aone-sandbox, local-config-parser, smart-config-manager, cloud-config-fetcher, fast-transform-pipeline, aone-cloud-cli, colder-cli, def-open-client, feedback-ai-sdk, flight-compare-analyzer, lwp-web-client, lzd-unified-station-sdk, open-worker-cli, test-skill-zip e uniapi-bridge. A investigação nota ainda um pacote adicional, node-data-utils, descrito como parte da linha temporal de encenação.
Entre os artefactos técnicos úteis para deteção: o domínio aone-cli-next.oss-cn-beijing.aliyuncs[.]com, que se faz passar pelo Alibaba; a necessidade de inspecionar ficheiros Python à procura do valor INJECTMARKER; e a injeção de fragmentos Python em diretórios .skills, garantindo que um script.js malicioso é lançado via runtime Bun sempre que essas ferramentas de IA são executadas.
Mitigação recomendada
- Tratar como comprometido qualquer ambiente que tenha instalado um dos pacotes listados e iniciar a remediação a partir de um dispositivo limpo.
- Preservar prova forense sempre que possível, remover os pacotes, rodar segredos de desenvolvimento e de nuvem expostos e inspecionar ficheiros Python pelo valor INJECTMARKER.
- Identificar todas as estações de trabalho que instalaram as dependências afetadas e rever atividade suspeita relacionada com o DingTalk.
- Desativar a execução de scripts de instalação em pipelines (por exemplo,
npm install --ignore-scripts) e fixar versões conhecidas como boas, evitando atualizações automáticas de dependências.
Porque é que isto importa em Portugal
Embora esta campanha vise especificamente programadores ligados ao ecossistema do Alibaba, a técnica é universal e aplicável a qualquer organização que dependa de repositórios de código aberto. Reflete o risco mais amplo visto em ataques recentes à cadeia de fornecimento do npm, onde uma dependência aparentemente inofensiva se pode tornar o ponto de entrada para um comprometimento maior. A quantidade de downloads foi limitada, mas a capacidade do RAT de recolher dados, executar comandos e mover-se por ferramentas relacionadas cria um risco de espionagem potencialmente sério para as organizações afetadas.
Para PME e organizações portuguesas, o episódio reforça a importância de gerir o risco da cadeia de fornecimento de software — uma área central do novo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2). As entidades abrangidas devem manter inventários de dependências, práticas de gestão de vulnerabilidades e capacidade de resposta a incidentes, contando com o apoio do CNCS/CERT.PT para notificação e coordenação. Nos casos em que estejam envolvidas credenciais ou dados pessoais, aplica-se ainda o RGPD, com potenciais deveres de notificação à CNPD.
Quem está por trás
A atribuição permanece por confirmar. Não se sabe exatamente quem está por trás da campanha, mas a presença de comentários em chinês no código-fonte, combinada com o facto de os commits do GitHub estarem carimbados com o fuso UTC+08:00, indica que é possivelmente o trabalho de um agente de ameaça de língua chinesa a visar programadores de língua chinesa que usam ferramentas do Alibaba Group. Ainda assim, os comentários em chinês e os metadados de commit em hora padrão da China podem apontar para um operador de língua chinesa, embora não estabeleçam atribuição.
Perguntas frequentes
Quais são os 18 pacotes npm afetados?
Incluem lib-mtop, aone-kit, aone-kit-cli, aone-sandbox, local-config-parser, smart-config-manager, cloud-config-fetcher, fast-transform-pipeline, aone-cloud-cli, colder-cli, def-open-client, feedback-ai-sdk, flight-compare-analyzer, lwp-web-client, lzd-unified-station-sdk, open-worker-cli, test-skill-zip e uniapi-bridge.
Como é que a campanha evitou a deteção durante meses?
Dividiu a lógica maliciosa por vários pacotes que, isoladamente, pareciam legítimos, usou nomes que imitavam dependências privadas internas e disfarçou o tráfego C2 com cabeçalhos apontando para domínios oficiais do DingTalk.
O que devo fazer se instalei um destes pacotes?
Tratar o ambiente como comprometido, refazer a partir de um dispositivo limpo, remover os pacotes, rodar segredos de desenvolvimento e de nuvem, inspecionar ficheiros Python pelo valor INJECTMARKER e rever atividade suspeita relacionada com o DingTalk.
Esta campanha afeta apenas utilizadores do Alibaba?
O alvo direto são programadores ligados às ferramentas internas do Alibaba, mas a técnica de personificação de dependências privadas é genérica e serve de aviso a qualquer organização que dependa de repositórios de código aberto como o npm.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Socket.dev, pela SafeDep e por outros investigadores de segurança de cadeia de fornecimento de software.