Campanha de fornecimento de pacotes infecta npm e PyPI com binário Go sckit e roubo de credenciais

Uma campanha de fornecimento de pacotes comprometeu recentemente componentes legítimos usados por desenvolvedores e pipelines de integração contínua para distribuir uma ferramenta maliciosa multiplataforma. Os atacantes inseriram um binário Go chamado "sckit" em versões concretas de um pacote npm e de um pacote em PyPI, e o código malicioso é ativado automaticamente ao carregar a dependência ou ao processar eventos de memória em tempo de execução. Relatórios de Aikido, SafeDep, Socket e StepSecurity confirmam a afectação das versões 0.1.21, 0.1.23 e 0.1.25 do pacote npm @memtensor/memos-cloud-openclaw-plugin e da versão 2.0.34 do pacote PyPI MemoryOS (esta última foi colocada em quarentena em PyPI). O pacote npm pode ser consultado no seu registo público npmjs.com e a entrada afectada do ecossistema em Python pypi.org.

No que está verificado até agora, as versões maliciosas incluem um carregador que lança o binário Go quando o plugin é iniciado (no caso de npm) ou quando o módulo "memos" se importa (em PyPI). O executável está compilado de forma estática e atua como um ladrão de credenciais: coleta arquivos de configuração e tokens (.npmrc, .vault-token, id_ecdsa, credentials.db, access_tokens.json, stored_tokens.json, stored_tokens), variáveis de ambiente contendo chaves (NPM_TOKEN, PYPI_API_TOKEN, etc.), e chaves ou tokens de serviços como AWS, GitHub, GitLab, Hugging Face, HashiCorp Vault, Slack, Stripe e SendGrid. O malware exfiltra esta informação a um servidor de comando e controle hospedado sob o domínio relatado pelas assinaturas de análise como skyleen.fr.

Tecnicamente, como funciona a intrusão: O vetor inicial foi a publicação maliciosa de novas versões de bibliotecas legítimas. SafeDep documenta que os atacantes conseguiram publicar esses pacotes utilizando tokens de publicação disponíveis nos pipelines do GitHub Actions do projeto MemTensor; concretamente, introduziram commits que dispararam workflows que expunham ou facilitaram o uso do token de publicação. Uma vez distribuído o pacote, o binário sckit é executado no contexto do processo que carrega a dependência, o que lhe permite herdar variáveis de ambiente e acesso ao mesmo usuário e sistema de arquivos que a aplicação ou o job da CI onde se importou a dependência.

Além disso, a análise do malware indica capacidades de autopropagação: modelos e mecanismos para inserir a carga útil em pacotes npm, pacotes Python e workflows do GitHub Actions, o que lhe permite se comportar de forma worm-like e publicar por si mesmo novas versões maliciosas se você obter tokens válidos. Em termos práticos, isto significa que uma equipe com acesso a repositórios, credenciais de publicação ou com workflows com privilégios excessivos poderia facilitar a propagação automática a outros projetos e contas.

Quem são os afetados e por que importa: A vítima primária são as máquinas de desenvolvedores e os jobs de CI que instalem ou importem as versões comprometidas. Uma vez que o plugin afeta um componente projetado para se integrar em agentes de "memoria" para ferramentas de IA e runtime de agentes, os processos infectados costumam dirigir texto de usuário, prompts e credenciais temporárias ou permanentes, pelo que a exposição pode incluir segredos injetados para uma tarefa concreta. Em prática, isto coloca em risco repositórios, contas de serviços na nuvem, tokens de pacotes e segredos usados por pipelines, com o potencial de escalada (reutilização de credenciais, publicação de versões maliciosas, movimento lateral em infra-estruturas de CI/CD).

Atos confirmados: As versões assinaladas dos pacotes contêm o binário e o launcher maliciosos; o domínio de exfiltração relatado é skyleen.fr; a técnica de obtenção do token de publicação envolveu pipelines do GitHub Actions do projeto; PyPI colocou em quarentena a versão afetada. Estimações e elementos ainda incertos: Não está totalmente confirmado o alcance total (se houver outros pacotes comprometidos além de MemTensor), a autoria do ator que colocou a carga útil ou o número de organizações afetadas. As análises também sugerem, mas não garantem, que a campanha é desenhada para auto-propagar quando consegue credenciais suficientes.

O que deve fazer uma equipe de desenvolvimento ou uma organização agora: as medidas são urgentes e concretas. Primeiro, pinnear dependências a versões seguras: para o pacote npm, voltar à versão 0.1.20; para PyPI, à 2.0.33, segundo as análises disponíveis. Segundo, revogar e rodar imediatamente qualquer credencial que pudesse ter estado no ambiente do processo (tokens de npm/PyPI, chaves AWS, tokens do GitHub/GitLab, segredos de Vault, etc.). Terceiro, procurar e parar processos suspeitos chamados ou que executem "sckit" e remover binários não reconhecidos em ambientes de desenvolvimento e runners de CI; além de bloquear o domínio de C2 e seus subdomínios a nível de rede e proxy (skyleen.fr e variantes).

Acções técnicas de detecção e contenção recomendadas: procurar traços de "skyleen" e nomes de binários em repositórios e artefatos: grep -R "skyleen" . /var && ps aux | grep sckit || true; verificar arquivos de tokens (.npmrc, credentials.db, .vault-token, id_ecdsa) por modificações recentes, comparar checksums com builds esperados, revisar logs de GitHub Actions em busca de commits ou workflows não autorizados e auditar a configuração de secrets em repositórios. Auditad quais contas e workflows têm permissões de publicação e eliminad tokens de publicação embebidos em repositórios; em seu lugar, usar mecanismos de federação temporária como OIDC e princípios de menor privilégio (ver guia do GitHub sobre OIDC: Configuring OpenID Connect in your workflow).

Medidas de mitigação a médio prazo: habilitar a digitalização de segredos em commits e artefatos, forçar 2FA em contas relevantes, restringir permissões dos runners de CI, rotar chaves de longo uso a credenciais de curta duração, auditar e limitar tokens de publicação, gerar SBOMs e assinar artefatos e releases para detectar modificações não autorizadas. Também é fundamental rever os pontos de integração de terceiros (bots, plugins, agentes de memória) e tratar as dependências como ativos que requerem controle de mudanças e verificação de integridade.

Por último, Não se deve assumir que a incidência está contida até completar uma revisão forense. Se a sua organização utilizou as versões comprometidas, proceda com a rotação de segredos, uma busca exaustiva de contaminação em repositórios e runners, e uma reconstrução de artefatos de fontes limpas. Se detectar publicações não autorizadas feitas pelas suas contas ou workflows, investigar imediatamente e, se necessário, contacte os fornecedores de registo (npm, PyPI, GitHub) para assistência na remediação e notificação.

O episódio destaca que os pipelines automatizados e os tokens de publicação são um objetivo crítico para adversários interessados em comprometer a cadeia de fornecimento de software. A combinação de binários multiplataforma e mecanismos para herdar contexto de execução torna dependências populares em vetores extremamente potentes: a prevenção exige tanto controles técnicos (least privilege, OIDC, rotação de segredos) como operacionais (revisiones de commits, monitoramento de CI, bloqueio de domínios maliciosos e respostas forenses rápidas).