Extensão maliciosa do VS Code expõe recurso de ransomware e C2 via GitHub

Pacote publicado no marketplace do VS Code ativava automaticamente uma rotina para compactar, enviar e criptografar arquivos de diretórios de teste, enquanto outro conjunto de pacotes npm distribuía o Vidar Stealer por scripts de pós-instalação.

Componente	Extensão susvsex para Visual Studio Code e pacotes npm maliciosos usados para distribuir o Vidar Stealer.
Vetor	Ativação automática da extensão em eventos do VS Code e execução de scripts de pós-instalação definidos em package.json em pacotes npm.
Impacto	Compactação, envio e criptografia de arquivos em diretórios de teste pela extensão; execução do Vidar Stealer a partir de arquivo ZIP baixado de servidor externo nos pacotes npm.
Prioridade	Auditar extensões e dependências instaladas, bloquear pacotes removidos, revisar scripts de pós-instalação e investigar telemetria de acesso a GitHub, Telegram, Steam e ao domínio defangado bullethost[.]cloud.
Artefatos	A extensão usava a função zipUploadAndEncrypt, consultava index.html em repositório privado do GitHub para comandos e gravava resultados em requirements.txt com token embutido.
Números	Dezessete pacotes npm foram associados ao cluster MUT-4831 e somaram ao menos 2.240 downloads antes da remoção, embora parte possa ter vindo de raspadores automatizados.

Resumo técnico

Uma extensão maliciosa para Visual Studio Code, identificada como susvsex, foi publicada no marketplace oficial com capacidades básicas de ransomware e comportamento de comando e controle. O pacote foi enviado em 5 de novembro de 2025 por uma conta chamada suspublisher18, com descrição curta e sinais de implementação imatura. A própria descrição informava que a extensão compactava, enviava e criptografava arquivos de C:\Users\Public\testing no Windows ou /tmp/testing no macOS durante a primeira execução. Em 6 de novembro, a extensão já havia sido removida do marketplace pela Microsoft.

O caso é relevante para equipes de segurança porque combina duas superfícies comuns em ambientes de desenvolvimento: extensões de IDE e pacotes de ecossistema aberto. A extensão não dependia de exploração de vulnerabilidade no VS Code; o risco vinha da confiança concedida a um complemento instalado pelo usuário ou por fluxo automatizado. Uma vez carregada, ela podia se ativar em eventos amplos do editor, inclusive durante instalação ou abertura do VS Code, chamando uma função denominada zipUploadAndEncrypt para operar sobre o diretório configurado.

O mesmo contexto técnico também expôs uma campanha separada no npm envolvendo 17 pacotes que se apresentavam como SDKs funcionais, mas executavam o Vidar Stealer nos sistemas atingidos. Esses pacotes foram associados ao cluster MUT-4831, publicados por contas chamadas aartje e saliii229911, e removidos após ao menos 2.240 downloads. A cadeia usava scripts de pós-instalação no package.json para buscar um arquivo ZIP em infraestrutura externa e iniciar o binário do Vidar contido no arquivo.

Fluxo técnico

Na extensão susvsex, a rotina principal era acionada automaticamente e seguia uma sequência típica de ransomware com exfiltração prévia: criação de um arquivo ZIP a partir do diretório alvo, envio do conteúdo para um servidor remoto e substituição dos arquivos originais por versões criptografadas. O escopo configurado apontava para diretórios de teste, o que limitava o impacto imediato observado, mas a lógica era editável por atualização de extensão ou por comando remoto. Isso torna o comportamento importante mesmo sem evidência de dano amplo, porque a capacidade técnica já estava implementada dentro do pacote.

O mecanismo de comando e controle usava o GitHub como canal indireto. A extensão consultava um repositório privado em busca de novas instruções, interpretando conteúdo armazenado em um arquivo index.html. Depois da execução dos comandos, os resultados eram escritos de volta no mesmo repositório, em requirements.txt, usando um token de acesso do GitHub embutido no código. Esse desenho reduz a necessidade de infraestrutura C2 tradicional e pode se misturar a tráfego legítimo de desenvolvedores, mas também cria evidência útil em proxies, EDRs e registros de acesso a repositórios.

O pacote ainda continha artefatos que indicavam baixo nível de maturidade operacional: comentários descritivos em excesso, arquivos README com instruções de execução, variáveis de espaço reservado e inclusão acidental de ferramentas de descriptografia, código de servidor C2 e chaves de acesso ao GitHub. Esses elementos sugerem uma construção assistida por IA ou altamente automatizada, com pouca revisão operacional. Para defesa, o ponto central não é a autoria, mas a redução da barreira para gerar malware funcional em formatos aceitos por ecossistemas de desenvolvimento.

Nos pacotes npm associados ao Vidar, a execução começava no momento da instalação por meio de scripts de pós-instalação definidos no package.json. A etapa inicial baixava um ZIP de um servidor externo no domínio defangado bullethost[.]cloud e executava o componente do Vidar presente no arquivo. Em algumas variantes, um script PowerShell embutido diretamente no manifesto do pacote fazia o download, depois repassava o fluxo para um arquivo JavaScript responsável pelo restante da cadeia. As amostras do Vidar 2.0 usavam contas hard-coded do Telegram e da Steam como resolvedores de dead drop para obter o servidor C2 final.

Superfície afetada

A superfície de risco inclui estáções de desenvolvimento com VS Code, ambientes em que extensões são instaladas sem revisão centralizada e pipelines ou imagens de build que restauram extensões automaticamente. Mesmo quando o diretório configurado é de teste, a permissão local da extensão acompanha o contexto do usuário que executa o editor. Isso significa que uma alteração posterior de configuração poderia mirar diretórios de projeto, artefatos de build, chaves locais, repositórios clonados ou arquivos temporários sensíveis, caso esses caminhos fossem adicionados ao alvo.

No npm, a exposição está ligada a qualquer fluxo que instale dependências permitindo scripts de ciclo de vida. O risco aumenta em estáções de desenvolvedor, runners de CI/CD, contêineres de build e caches compartilhados que executam postinstall sem isolamento. Pacotes que entregam a funcionalidade anunciada podem passar por testes superficiais, porque o comportamento legítimo convive com a carga maliciosa. Esse padrão dificulta triagens baseadas apenas em importação ou uso aparente da biblioteca.

Como as contas publicadoras dos pacotes npm foram banidas e a extensão foi removida do marketplace, a principal preocupação passa a ser ambiente que instalou os artefatos antes da remoção, cache corporativo, lockfile congelado e cópias internas de pacotes. Downloads automatizados também podem inflar métricas, mas não eliminam a necessidade de investigação local, especialmente quando registros de instalação, cache de pacote ou telemetria de EDR indicam execução de scripts de instalação.

• Estáções Windows ou macOS com a extensão susvsex instalada antes da remoção do marketplace.
• Ambientes VS Code onde extensões podem se ativar automaticamente em instalação ou inicialização do editor.
• Projetos npm que instalaram pacotes publicados pelas contas aartje ou saliii229911 antes da remoção.
• Runners de CI/CD, caches de dependências e imagens de build que preservaram pacotes maliciosos ou seus arquivos ZIP baixados.

Hunting e telemetria

A investigação da extensão deve começar pelo inventário de extensões do VS Code e pela busca pelo identificador susvsex, pelo publicador suspublisher18 e por artefatos de execução associados a zipUploadAndEncrypt. Em endpoints, a defesa deve correlacionar eventos do processo do VS Code com criação de arquivos ZIP, leitura em massa de diretórios de teste, escrita de arquivos criptografados e conexões de saída incomuns logo após instalação ou inicialização do editor. A presença de tráfego GitHub associado à leitura de index.html e escrita em requirements.txt fora de fluxos normais de desenvolvimento é um sinal de alto valor.

Para a cadeia npm, os sinais principais ficam no histórico de instalação de pacotes, no conteúdo de package.json, em logs de package manager, no cache local e nos eventos de criação de processo durante pós-instalação. A defesa deve procurar downloads de ZIP a partir de bullethost[.]cloud, execução de PowerShell iniciada por ferramenta de pacote e transição posterior para JavaScript ou binário extraído. Em rede, acessos a Telegram e Steam podem ser legítimos em estáções de usuário, mas merecem análise quando ocorrem a partir de processos de instalação, runners de build ou diretórios temporários vinculados a dependências.

Como o Vidar é um infostealer, a contenção deve assumir risco de coleta de credenciais e dados de sessão quando houver execução confirmada. O contexto não traz lista de dados exfiltrados neste caso específico, portanto a análise deve se basear em evidência local: processos criados, arquivos acessados, conexões externas, persistência observada e credenciais presentes na máquina no momento da execução. Para a extensão VS Code, a evidência de criptografia e exfiltração deve ser validada pelo caminho de diretório afetado e por registros de upload, sem presumir comprometimento de dados fora do escopo configurado.

• Instalação ou presença da extensão susvsex em diretórios de extensões do VS Code.
• Eventos do VS Code criando arquivos ZIP, lendo diretórios de teste e substituindo arquivos por versões criptografadas.
• Acesso programático ao GitHub com leitura de index.html e escrita em requirements.txt em repositório privado.
• Execução de scripts postinstall em pacotes npm com download de ZIP de bullethost[.]cloud.
• PowerShell ou JavaScript iniciado por ferramenta de pacote durante instalação de dependências.
• Conexões usadas como dead drop resolver via Telegram ou Steam a partir de processo ligado à instalação.

Mitigação

A primeira resposta deve ser remover a extensão susvsex de qualquer estáção identificada, coletar artefatos antes da limpeza quando houver suspeita de execução e verificar se o diretório configurado foi compactado, enviado ou criptografado. Como o token do GitHub estava embutido no código da extensão, qualquer ambiente que tenha interagido com o repositório C2 deve ser tratado como evidência de comunicação externa. A defesa deve bloquear a extensão por política, revisar listas permitidas de extensões e impedir instalação de publicadores não aprovados em ambientes corporativos.

Para npm, a mitigação exige revisão de lockfiles, caches, imagens de build e histórico de instalação. A simples remoção dos pacotes do registro público não limpa cópias locais nem artefatos preservados por mirrors internos. Quando houver evidência de instalação de pacotes ligados ao cluster MUT-4831, é necessário isolar o host ou runner, preservar logs, remover credenciais acessíveis no ambiente, rotacionar segredos expostos a esse contexto e reconstruir imagens a partir de bases limpas. Execução de scripts de ciclo de vida deve ser restringida em ambientes sensíveis, com exceções documentadas para pacotes confiáveis.

Medidas preventivas devem combinar governança de dependências, validação de publisher, análise de manifestos e monitoramento de comportamento. Extensões de IDE precisam ser tratadas como código executável com acesso ao workspace, e não como simples recurso de produtividade. Em pipelines, instalações devem priorizar lockfiles revisados, execução com menor privilégio, isolamento de rede, bloqueio de downloads externos não aprovados e alerta para processos de instalação que iniciem PowerShell, JavaScript ou binários extraídos de arquivos compactados. A resposta deve fechar o ciclo com verificação de telemetria após a remoção, para confirmar ausência de novas consultas a repositórios de comando e controle ou a resolvedores externos.

• Remover susvsex, bloquear o publicador e auditar eventos do VS Code no período posterior a 5 de novembro de 2025.
• Revisar diretórios de teste citados pela extensão para confirmar compactação, upload ou criptografia de arquivos.
• Inventariar pacotes npm instalados antes da remoção e comparar lockfiles, caches e imagens de build.
• Desabilitar ou restringir scripts de pós-instalação em ambientes de CI/CD quando não forem necessários.
• Rotacionar segredos de hosts ou runners com execução confirmada do Vidar Stealer.
• Criar detecções para download de ZIP por processos de package manager e para uso anômalo de GitHub como canal de retorno.