A campanha oculta malware em npm e Go dentro de VS Code que se ativa ao abrir seu projeto

Pesquisadores em cibersegurança devem desencorajar uma campanha recente que aproveitou pacotes maliciosos tanto em npm como no ecossistema Go para introduzir um roubador de informação baseado em Python em máquinas Windows, Linux e macOS. O relevante não é apenas o malware em si, mas a tática: os atacantes esconderam a execução dentro de uma tarefa automática do Visual Studio Code e disfarçaram código JavaScript como um arquivo de fonte, tornando um fluxo de trabalho cotidiano do desenvolvedor em vetor de infecção.

Os pacotes npm identificados — entre eles html-to-gutenberg e fetch-page-assets, que incluíam dependências comprometidas — foram subidos no final de maio de 2026 e já não estão disponíveis no registo. Em paralelo, análises da comunidade apontaram pelo menos 16 repositórios Go que publicaram versões com a mesma carga maliciosa. A execução inicial é activa quando a pasta do pacote é aberta como espaço de trabalho no VS Code e a tarefa maliciosa marcada com runOn: 'folderOpen' é executado automaticamente; essa opção está documentada no próprio guia de tarefas do VS Code e é precisamente o mecanismo que abusaram dos atacantes https://code.visualstudio.com/docs/editor/tasks#_runon.

A cadeia de ataque é sofisticada e escalonada: o suposto arquivo de fonte contém JavaScript que recupera um estádio de encriptação seguinte a partir de transações em blockchains (usando serviços como TronGrid e Aptos) — uma técnica de "dead drop" que dificulta a tomada abaixo do conteúdo—, configura uma conexão a infraestrutura controlada pelo atacante, ativa um backdoor sobre Socket.io e finalmente descarrega e instala um infostealer em Python. O componente final recolhe credenciais de navegadores, gestores, wallets, armazéns de credenciais do sistema operacional e artefatos de desenvolvimento (como credenciais do Git e dados do VS Code), empacote a informação e a exfiltra, mesmo através de um bot do Telegram se o atacante forneceu um token.

Além do impacto direto na confidencialidade de credenciais e fundos de criptomoedas, este incidente destaca duas tendências preocupantes: primeiro, os atacantes orientam suas campanhas ao perfil “desenvolvidodor” e usam ferramentas legítimas (IDEs, pacotes populares) para camuflar sua atividade; segundo, a reutilização de infra-estruturas resilientes (blockchain como armazém de etapas) aumenta a persistência e a dificuldade de mitigação.

Para equipamentos e desenvolvedores a recomendação imediata é contundente: remova qualquer dependência suspeita ou versões publicadas nas datas assinaladas e procure pistas de execução automática nas máquinas de desenvolvimento. Em particular, inspecione pastas .vscode em projectos locais e contas de desenvolvedor em repositórios públicos; verifique se existem tasks.json com opções que permitam executar comandos ao abrir a pasta e rever ficheiros binários ou “fontes” que contenham código JavaScript em vez de dados de fonte legítimos. Se você detectar compromisso ativo –conexões salientes incomuns, processos desconhecidos ou arquivos comprimidos com dados sensíveis – contemple o isolamento e a reinstalação de sistemas afetados e coordene uma resposta forense para determinar o alcance.

Do ponto de vista da gestão de risco, é imprescindível rotar credenciais após uma possível exposição: mude senhas e API keys, substitua tokens e chaves de serviço na nuvem, invalide sessões e clientes OAuth, e assegure o acesso a carteiras cripto (migração de fundos para wallets novas com chaves privadas seguras se houver suspeita de roubo). Active autenticação multifator e prefira gestores de senhas dedicados contra o armazenamento em navegadores. Para contas de registo (npm, GitHub, etc.) habilite 2FA e políticas de verificação de pacotes.

No plano organizacional, adopte controles de higiene na cadeia de fornecimento de software: implemente bloqueio de versões e assinaturas de pacotes quando possível, use ferramentas de Software Composition Analysis (SCA) e políticas de aprovação para dependências novas, e execute builds e análises em ambientes CI/CD controlados que não dependan do workspace do desenvolvedor. O GitHub oferece guias e funcionalidades orientadas para a segurança da cadeia de abastecimento que podem ajudar a estabelecer essas práticas https://docs.github.com/en/code-security/supply-chain-security. Igualmente, configure políticas de “workspace trust” e evite permitir a execução automática de tarefas a partir de diretórios não verificados.

Os incidentes como este também requerem uma abordagem pró-ativa: monitoramento de rede para detectar comunicações para domínios ou padrões invulgares (incluindo tráfego para APIs de blockchain e proxies), auditoria contínua de dependências e produção de SBOMs (Software Bill of Materials) para poder identificar rapidamente o que software poderia ter estado em risco. Se você gerencia ativos com fundos em cripto, automatice alertas sobre movimentos de fundos e estabeleça procedimentos de emergência para sua transferência segura.

Finalmente, a comunidade deve notar que as defesas tradicionais de registo de pacotes e controlos em execução não bastam se a cadeia de entrega pode ativar funcionalidades do IDE ou apoiar-se em infra-estruturas descentralizadas para alojar etapas. Este caso é um lembrete de que a segurança do desenvolvimento não é apenas responsabilidade de operações ou de uma única equipe: requer coordenação entre desenvolvedores, responsáveis pela segurança, administradores de repositórios e fornecedores de ferramentas.