Hackers norte-coreanos abusam de tarefas automáticas do VS Code para instalar StoatWaffle

Hackers norte-coreanos abusam de tarefas automáticas do VS Code para instalar StoatWaffle

Campanha Contagious Interview usa projetos maliciosos do Visual Studio Code, engenharia social em entrevistas técnicas e módulos Node.js para roubo de credenciais e acesso remoto.

ComponenteProjetos maliciosos do Microsoft Visual Studio Code com arquivo tasks.json e malware modular StoatWaffle implementado em Node.js.
VetorEngenharia social em processos falsos de recrutamento técnico, com repositórios GitHub, GitLab ou Bitbucket e tarefas automáticas acionadas por runOn: folderOpen ao abrir a pasta no VS Code.
ImpactoExecução automática de código Node.js, instalação de baixadores em estágios, roubo de credenciais de navegadores, coleta de dados de extensões, possível roubo do iCloud Keychain em macOS e controle remoto por RAT.
PrioridadeAtualizar o VS Code para versões com proteção contra tarefas automáticas, manter task.allowAutomaticTasks desativado e revisar repositórios recebidos em entrevistas antes de abrir workspaces.
Artefatostasks.json, task.allowAutomaticTasks, projetos VS Code hospedados no GitHub, scripts em Vercel ou GitHub Gist, pacotes npm maliciosos e cargas associadas a StoatWaffle, FlexibleFerret, PylangGhost e BeaverTail.
AlvosDesenvolvedores, fundadores, CTOs e engenheiros sêniores ligados a criptomoedas, Web3 e ambientes com acesso elevado a infraestrutura técnica ou carteiras digitais.
Resumo técnico

A campanha Contagious Interview, também rastreada como WaterPlum, passou a usar projetos maliciosos do Visual Studio Code como mecanismo de execução inicial para o malware StoatWaffle. O ponto central da técnica está no arquivo tasks.json, configurado com runOn: folderOpen, o que permite acionar uma tarefa automaticamente quando qualquer arquivo da pasta do projeto é aberto no VS Code. Esse abuso desloca a execução para um fluxo que desenvolvedores costumam tratar como parte normal de avaliações técnicas, reduzindo a percepção de risco durante entrevistas falsas ou exercícios de programação.

O StoatWaffle é descrito como um malware modular em Node.js com módulos de stealer e RAT. A cadeia começa com a verificação da presença do Node.js no ambiente comprometido; se o runtime não existir, a carga tenta obtê-lo do site oficial e instalá-lo antes de continuar. Em seguida, um baixador consulta periodicamente um servidor externo para buscar outro estágio, que repete o comportamento de comunicação com endpoint adicional e executa a resposta recebida como código Node.js. O modelo favorece atualização rápida da carga, seleção de módulos conforme o perfil do alvo e manutenção de acesso sem expor todas as capacidades na primeira etapa.

Fluxo técnico

O vetor de entrada combina engenharia social e confiança no ecossistema de desenvolvimento. Os operadores montam processos de recrutamento convincentes, abordam vítimas em redes profissionais e direcionam candidatos para repositórios ou pacotes apresentados como parte de avaliação técnica. Em alguns casos, os alvos são persuadidos a executar comandos ou dependências hospedadas em GitHub, GitLab ou Bitbucket. Na variação com VS Code, o risco é agravado porque a abertura do workspace pode ser suficiente para disparar a tarefa definida pelo repositório, sem que a vítima precise executar manualmente um binário suspeito.

Depois da execução inicial, a cadeia orientada a Node.js permite múltiplos comportamentos. O módulo de roubo coleta credenciais e dados de extensões armazenados em navegadores Chromium e Mozilla Firefox; em sistemas macOS, também há referência ao roubo do banco do iCloud Keychain. O módulo RAT comunica-se com o servidor de comando e controle para receber instruções, mudar diretório de trabalho, enumerar arquivos, executar código Node.js, enviar arquivos, procurar diretórios recursivamente por palavras-chave, executar comandos de sistema e encerrar a própria atividade. Esses recursos sustentam roubo financeiro, coleta de segredos técnicos e expansão seletiva dentro do ambiente de desenvolvimento.

A infraestrutura e os artefatos mudaram ao longo da campanha. Amostras anteriores usavam uma aplicação em Vercel para entregar dados a qualquer sistema operacional, com comportamento essencial semelhante em Windows, macOS ou outros ambientes capazes de executar Node.js. Mutações mais recentes deixaram domínios baseados em Vercel e passaram a usar scripts hospedados no GitHub Gist para baixar e executar estágios posteriores, culminando em FlexibleFerret em parte dos casos. O mesmo ecossistema de atividade inclui pacotes npm maliciosos que propagam PylangGhost, páginas de falso CAPTCHA no estilo ClickFix e repositórios públicos comprometidos com JavaScript ofuscado para levar à execução do BeaverTail.

Superfície afetada

A superfície mais exposta é formada por estáções de trabalho de desenvolvedores que abrem projetos externos no VS Code, principalmente quando o fluxo de seleção, auditoria de código ou colaboração temporária exige testar repositórios de terceiros. O risco não depende apenas de sistemas Windows: o próprio comportamento descrito para o baixador foi tratado como essencialmente equivalente entre sistemas operacionais, desde que as condições de execução permitam Node.js e a cadeia consiga obter ou usar o runtime. Ambientes com credenciais persistidas em navegadores, extensões de carteira, tokens de acesso a repositórios, sessões de nuvem e chaves de publicação têm maior impacto operacional.

A seleção de vítimas indica interesse em pessoas com acesso privilegiado ao ecossistema de criptomoedas e Web3, incluindo fundadores, CTOs e engenheiros sêniores. Esse perfil pode concentrar permissões em infraestrutura corporativa, pipelines, organizações GitHub, carteiras digitais e sistemas internos. O risco também se estende a projetos de código aberto quando uma conta com permissão de escrita é comprometida. Na campanha PolinRider, centenas de repositórios públicos receberam JavaScript ofuscado, e quatro repositórios da organização Neutralinojs foram citados entre os comprometidos após abuso de uma conta de colaborador antigo com acesso de escrita em nível organizacional.

A atualização do VS Code em janeiro de 2026, versão 1.109, introduziu a configuração task.allowAutomaticTasks com padrão desativado para impedir execução não intencional de tarefas definidas em tasks.json ao abrir workspaces. A proteção também impede que a configuração seja definida no nível do workspace por um repositório malicioso com .vscode/settings.json. A versão 1.110, de fevereiro de 2026, acrescentou um aviso secundário quando uma tarefa automática é detectada em um workspace recém-aberto, funcionando como barreira adicional depois do prompt de confiança do workspace.

Os elementos concretos da superfície incluem workspaces do VS Code recebidos fora de canais confiáveis, repositórios usados em entrevistas técnicas, pacotes npm usados como avaliação de habilidades, extensões maliciosas do VS Code e contas de repositório com permissão de escrita. A presença de Node.js no endpoint reduz o atrito para a execução da cadeia; a ausência do runtime não elimina o risco, porque a carga descrita tenta instalar Node.js antes de iniciar os estágios seguintes.

  • Estáções de trabalho que abrem projetos VS Code de entrevistas, testes técnicos ou repositórios não verificados.
  • Contas de desenvolvedores com tokens de GitHub, GitLab, Bitbucket, npm, nuvem, CI/CD ou carteiras de criptomoedas acessíveis no mesmo ambiente.
  • Projetos com .vscode/tasks.json contendo tarefa automática acionada por runOn: folderOpen.
  • Organizações de código aberto nas quais colaboradores mantêm permissões amplas de escrita ou force-push.
Hunting e telemetria

A investigação deve começar pela correlação entre abertura de workspaces no VS Code e criação de processos Node.js inesperados. Em endpoints de desenvolvedores, eventos relevantes incluem execução de tarefas do VS Code logo após clonagem ou abertura de repositório, processos filhos iniciados a partir do editor, instalação não planejada de Node.js, conexões externas originadas por Node.js e gravação de artefatos temporários associados a baixadores. O objetivo é distinguir atividade legítima de build ou teste de execução automática disparada por um projeto recebido em processo seletivo ou canal externo.

Na camada de repositórios, a defesa deve procurar alterações incomuns em .vscode/tasks.json, .vscode/settings.json, scripts de inicialização, dependências npm e JavaScript ofuscado adicionado a projetos públicos. Eventos de force-push, commits feitos por contas antigas em horários incomuns, mudanças em centenas de repositórios e inclusão de código que busca cargas criptografadas ou scripts externos são sinais de risco. Em ambientes npm, a investigação deve cobrir pacotes recém-instalados durante testes técnicos, dependências transitivas não reconhecidas e execução de hooks ou scripts que iniciem interpretadores fora do fluxo de build esperado.

Na telemetria de identidade e acesso, os sinais mais importantes são uso anômalo de tokens de desenvolvedor após interação com entrevista falsa, criação de chaves, alterações em permissões de repositório, publicação inesperada de pacotes e acesso a carteiras ou serviços de nuvem a partir de hosts usados para avaliação técnica. Como os módulos de stealer coletam credenciais de navegadores e extensões, qualquer suspeita em endpoint deve ser tratada como possível exposição de sessões persistentes, mesmo quando não houver confirmação de movimentação lateral ou vazamento amplo.

  • Processos node iniciados pelo VS Code imediatamente após abertura de workspace externo.
  • Arquivos .vscode/tasks.json com execução automática por runOn: folderOpen ou tarefas que buscam conteúdo remoto.
  • Instalação inesperada de Node.js em estáção de trabalho de usuário que não utiliza esse runtime regularmente.
  • Conexões de Node.js para serviços externos usados como estágio de entrega, incluindo aplicações serverless ou scripts hospedados em repositórios.
  • Alterações súbitas em repositórios públicos, force-push por colaborador legítimo e inclusão de JavaScript ofuscado.
Mitigação

A medida técnica mais direta é atualizar o Visual Studio Code para versões que desativam tarefas automáticas por padrão e exibem aviso adicional para workspaces com esse comportamento. A configuração task.allowAutomaticTasks deve permanecer desativada no nível global, e equipes de engenharia devem tratar qualquer repositório que tente acionar tarefas ao abrir a pasta como artefato de alto risco até revisão manual. Workspaces de entrevistas e avaliações externas devem ser abertos em ambiente descartável, sem sessões de navegador, chaves SSH, tokens de repositório, carteiras ou credenciais corporativas disponíveis.

A resposta a uma suspeita deve combinar contenção do endpoint, revogação de credenciais e revisão de repositórios. Como a cadeia inclui stealer e RAT, não basta remover o projeto malicioso: é necessário revogar tokens de GitHub, GitLab, Bitbucket, npm, nuvem e carteiras acessíveis no host, invalidar sessões de navegador, auditar extensões, verificar publicações recentes e revisar permissões de contas com escrita em organizações. Para projetos de código aberto, mantenedores devem examinar commits recentes, force-pushes, alterações em scripts e dependências, além de reduzir permissões permanentes de colaboradores que não precisam de escrita contínua.

Processos de recrutamento também precisam ser incorporados ao modelo de ameaça. Candidatos e empresas devem separar avaliações técnicas de ambientes de produção, exigir análise prévia de repositórios recebidos, bloquear execução automática em editores e desencorajar testes que dependam de comandos fornecidos por terceiros. Em organizações com foco em criptomoedas e Web3, a política deve impedir que carteiras, seed phrases, extensões financeiras e contas administrativas coexistam no mesmo perfil usado para abrir código desconhecido. A validação final deve confirmar que as versões do VS Code estão corrigidas, a configuração de tarefas automáticas está controlada e alertas de endpoint cobrem execução anômala de Node.js a partir do editor.

  • Atualizar o VS Code para versões 1.109, 1.110 ou posteriores e manter task.allowAutomaticTasks desativado.
  • Abrir repositórios de entrevistas e testes técnicos apenas em máquina virtual ou contêiner sem credenciais persistentes.
  • Revisar manualmente .vscode/tasks.json, .vscode/settings.json, scripts npm e dependências antes de abrir ou executar projetos externos.
  • Revogar tokens e sessões de contas de desenvolvimento quando houver execução suspeita de Node.js iniciada pelo editor.
  • Auditar permissões de escrita em organizações de repositórios e restringir force-push a contas e ramos estritamente necessários.

Postar um comentário

0 Comentários