Hackers ligados à Coreia do Norte usam projetos maliciosos do VS Code contra desenvolvedores

Campanha usa repositórios de teste técnico, tarefas do VS Code e JavaScript ofuscado para instalar backdoors com execução remota em ambientes de desenvolvimento.

Componente	Projetos maliciosos abertos no Microsoft Visual Studio Code, especialmente configurações de tarefas em tasks.json.
Vetor	Engenharia social contra desenvolvedores por supostos testes de emprego, com repositórios em GitHub, GitLab, Bitbucket ou links intermediários como Notion[.]so.
Impacto	Execução de JavaScript ofuscado, instalação de backdoors, comunicação recorrente com servidor remoto, fingerprinting do sistema e execução remota de código condicionada à confiança concedida ao repositório.
Prioridade	Bloquear abertura automática de projetos não verificados, revisar tarefas do VS Code antes de confiar no repositório e investigar execução de Node.js iniciada por diretórios clonados de origem desconhecida.
Artefatos	runOn: folderOpen, tasks.json, BeaverTail, InvisibleFerret, TsunamiKit, XMRig, AnyDesk e dependência npm maliciosa grayavatar.
IoCs	Domínio defangado ip-regions-check.vercel[.]app e uso de cargas hospedadas em domínios Vercel, sem publicação de links ativos.
Mitigação	Validar conteúdo de repositórios antes da abertura no IDE, permitir somente pacotes npm revisados e correlacionar processos de Node.js, Python, mineradores e ferramentas de acesso remoto iniciados a partir de projetos recém-clonados.

Resumo técnico

A atividade acompanha uma campanha associada a atores de ameaça ligados à Coreia do Norte que mira desenvolvedores por meio de projetos maliciosos do Microsoft Visual Studio Code. O fluxo observado se apoia em uma etapa socialmente plausível: o alvo recebe um repositório apresentado como avaliação técnica, clona o projeto e o abre no IDE. A cadeia passa a depender da relação de confiança concedida ao diretório, porque o VS Code pode processar configurações de tarefas do projeto e executar ações definidas pelo próprio repositório. Nesse cenário, o projeto não funciona apenas como isca visual ou arquivo contaminado isolado; ele atua como contêiner de execução para scripts ofuscados, lógica de download e mecanismos de persistência em camadas.

A técnica se conecta à campanha conhecida como Contagious Interview, na qual engenheiros de software, especialmente profissionais ligados a criptomoedas, blockchain e fintech, são abordados em contextos de recrutamento ou testes de código. O objetivo operacional é obter execução inicial em estáções usadas para desenvolvimento, ambientes que frequentemente concentram chaves de acesso, carteiras digitais, código-fonte, tokens de integração, dependências privadas, credenciais de navegador e acesso a infraestrutura interna. O comprometimento descrito não exige uma vulnerabilidade nova no VS Code; ele explora o comportamento legítimo de automação do IDE combinado com engenharia social, confiança do usuário e conteúdo malicioso dentro do repositório.

A evolução recente inclui diferentes métodos de entrega. Em uma variação, o arquivo de tarefas aciona JavaScript ofuscado ao abrir a pasta do projeto. Em outra, o conteúdo tenta buscar uma carga remota em domínios Vercel e mantém alternativas embutidas, disfarçadas como dicionários de verificação ortográfica, caso a recuperação externa falhe. Também foram observadas cadeias com BeaverTail e InvisibleFerret, além de uma investigação paralela envolvendo TsunamiKit e XMRig. O conjunto aponta para operadores que adaptam rapidamente formato, linguagem e infraestrutura, mantendo o mesmo princípio defensivamente crítico: o repositório recebido fora do fluxo normal da organização deve ser tratado como código executável, não como material passivo.

Fluxo técnico

A infecção começa quando o desenvolvedor abre no VS Code um repositório preparado pelo operador. O gatilho central fica nas configurações de tarefas, em especial no uso de runOn: folderOpen, que permite a execução automática quando a pasta ou arquivos dentro dela são abertos. Antes da execução, o VS Code solicita confiança no autor do repositório. Se o usuário concede essa confiança, o IDE processa tasks.json e pode iniciar comandos arbitrários definidos no projeto. O abuso é relevante porque transforma um gesto comum de avaliação técnica em um evento de execução local, com pouca fricção visual para o usuário e com aparência compatível com rotinas legítimas de build, teste ou preparação de ambiente.

Em sistemas macOS, a cadeia descrita recupera uma carga JavaScript remota e a entrega ao runtime Node.js, mantendo a execução em segundo plano e suprimindo saída visível. O comando operacional foi omitido, mas o efeito defensivo é claro: a tarefa cria um processo independente do IDE, baixa código de infraestrutura externa e executa lógica JavaScript fora do fluxo normal de revisão de dependências. A carga hospedada em Vercel contém a lógica principal do backdoor, coleta informações básicas do host, estabelece comunicação com servidor remoto e mantém um ciclo de execução persistente. O canal permite fingerprinting do sistema, execução remota de código JavaScript adicional e comunicação contínua com o operador.

Uma etapa observada após a infecção inicial executou novas instruções JavaScript cerca de oito minutos depois. Esse código passou a sinalizar ao servidor em intervalos de aproximadamente cinco segundos, aceitar JavaScript adicional e apagar rastros de atividade quando recebia um sinal específico do operador. A presença de comentários e formulações no código sugeriu possível assistência de ferramenta de inteligência artificial na geração do script, mas essa inferência não altera a análise defensiva: a ameaça reside no encadeamento entre tarefa do IDE, runtime local, canal remoto e capacidade de mudar instruções rapidamente após o primeiro acesso.

Outras variações usam mecanismos de fallback. Quando a tarefa não consegue buscar a carga no domínio externo, o repositório pode carregar droppers multiestágio escondidos em arquivos que simulam dicionários inofensivos. Em campanha relacionada, o contato com a vítima ocorreu pelo LinkedIn, com o operador se apresentando como executivo de um projeto chamado Meta2140 e entregando um link Notion[.]so contendo avaliação técnica e URL para um repositório Bitbucket. A cadeia também previa alternativas como instalação da dependência npm maliciosa grayavatar ou execução de JavaScript responsável por obter um controlador Node.js com módulos para keylogging, capturas de tela, varredura do diretório pessoal, substituição de endereços de carteira copiados para a área de transferência, coleta de credenciais de navegadores e conexão persistente com servidor remoto.

Superfície afetada

A superfície principal é a estáção de trabalho do desenvolvedor, não um servidor exposto diretamente à internet. Isso muda a prioridade de defesa: controles de endpoint, identidade, repositórios e ferramentas de desenvolvimento precisam ser analisados como parte do mesmo fluxo. A campanha tira proveito de hábitos normais de engenharia, como clonar projetos, abrir pastas no IDE, instalar dependências, executar testes e aceitar arquivos de configuração incluídos pelo repositório. Ambientes com acesso a carteiras, código privado, chaves de API, repositórios corporativos, pipelines de CI/CD ou sistemas financeiros internos ficam mais sensíveis porque a execução ocorre no ponto onde essas credenciais e permissões costumam estar disponíveis.

Os setores citados como alvo incluem criptomoedas, blockchain e fintech, áreas nas quais desenvolvedores podem ter contato com ativos digitais, infraestrutura técnica e propriedade intelectual. O impacto confirmado no contexto inclui backdoors, execução remota de código, fingerprinting, coleta de dados locais, keylogging, capturas de tela, mineração com XMRig em certas cadeias e implantação de AnyDesk para acesso remoto. O risco de acesso indevido a código-fonte, sistemas internos e ativos digitais decorre dessas capacidades e do perfil das vítimas, mas deve ser tratado como consequência condicionada ao ambiente comprometido, não como vazamento confirmado em todos os casos.

A presença de BeaverTail e InvisibleFerret em camadas Node.js e Python amplia o escopo de investigação para além do VS Code. A cadeia pode iniciar em uma tarefa do IDE, mas evoluir para ambientes paralelos de Python, módulos persistentes, mineradores e ferramentas legítimas abusadas para acesso remoto. Também há referência a TsunamiKit em repositório malicioso separado que usa tarefa do VS Code para buscar JavaScript ofuscado e instalar um backdoor de maior funcionalidade junto com XMRig. Para defesa, isso significa que o evento inicial pode parecer um processo de desenvolvimento, enquanto os sinais posteriores aparecem como execução de runtime, conexão externa, varredura de arquivos, captura de entrada e criação de canais remotos.

• Desenvolvedores abordados por supostos testes técnicos e instruídos a clonar repositórios de terceiros.
• Projetos abertos no VS Code com confiança concedida ao repositório e tarefas automáticas habilitadas.
• Estáções macOS com execução de JavaScript via Node.js a partir de tarefas do projeto.
• Ambientes com carteiras digitais, credenciais de navegador, código-fonte privado ou acesso a infraestrutura interna.
• Cadeias que combinam Node.js, Python, dependências npm, minerador XMRig e AnyDesk.

Hunting e telemetria

A caça deve começar pela correlação entre eventos de clone ou abertura de repositório e criação de processos pelo VS Code. Um sinal forte é o lançamento de Node.js a partir de diretórios recém-clonados ou pastas de avaliação técnica, especialmente quando o processo tenta recuperar JavaScript remoto, executa código ofuscado ou mantém comunicação recorrente com infraestrutura externa. A existência de tasks.json com runOn: folderOpen deve ser tratada como artefato de alto interesse quando o repositório veio de contato externo, recrutamento, mensagem direta ou domínio intermediário. O objetivo não é bloquear toda automação do IDE, mas diferenciar tarefas internas revisadas de tarefas recebidas de origem não confiável.

Em endpoint, procure árvores de processo nas quais o VS Code origina shells, Node.js, Python, mineradores, AnyDesk ou processos persistentes sem relação com a rotina do projeto. A telemetria de rede deve destacar conexões para domínios Vercel incomuns, inclusive ip-regions-check.vercel[.]app, com beacons frequentes ou recuperação de JavaScript. Como a infraestrutura pode mudar rapidamente, o indicador individual tem vida curta; a detecção mais resistente combina padrão de execução, origem do diretório, linguagem usada, ofuscação, intervalo de comunicação e ações pós-infecção. Logs de EDR podem registrar apagamento de arquivos temporários, criação de ambientes Python paralelos, acesso a diretórios pessoais e leitura de perfis de navegadores.

No ecossistema de desenvolvimento, revise lockfiles, caches de pacotes, histórico de instalação npm e alterações em dependências após contato externo. A dependência grayavatar aparece como alternativa maliciosa em uma das cadeias, mas a defesa não deve depender apenas desse nome. O comportamento de risco é a instalação de dependência não revisada durante teste técnico, seguida de execução de controlador Node.js, coleta de arquivos sensíveis e comunicação persistente. Em ambientes de identidade e repositório, investigue logins, tokens usados a partir da estáção suspeita, criação de chaves SSH, alterações em permissões de repositórios e uso anômalo de credenciais depois do horário do contato de recrutamento.

• Criação de processos Node.js, Python, shell, XMRig ou AnyDesk originados por VS Code ou por diretórios recém-clonados.
• tasks.json contendo runOn: folderOpen em repositórios recebidos por avaliação técnica, LinkedIn, Notion[.]so ou mensagens diretas.
• Conexões para domínios Vercel incomuns, incluindo ip-regions-check.vercel[.]app, com recuperação de JavaScript ou beaconing recorrente.
• Acesso automatizado ao diretório pessoal, perfis de navegador, área de transferência, arquivos de carteira ou capturas de tela.
• Instalação de pacotes npm não aprovados, especialmente quando ocorre imediatamente após abertura de projeto externo.

Mitigação

A resposta deve tratar repositórios de avaliação externa como conteúdo executável. Antes de abrir no VS Code, o time deve revisar arquivos de configuração, scripts de build, dependências, tarefas e hooks fora do IDE ou em ambiente isolado. Quando houver solicitação de confiança no autor do repositório, a concessão deve ocorrer apenas depois de verificar tasks.json, package.json, scripts npm, arquivos de inicialização e referências a domínios externos. Para fluxos de recrutamento, uma política defensiva eficaz é abrir projetos desconhecidos em máquina descartável, contêiner sem credenciais ou perfil de usuário sem acesso a repositórios e carteiras.

Para endpoints suspeitos, a contenção deve começar com isolamento de rede, preservação de artefatos e coleta de árvores de processo, histórico de shell, logs do VS Code, cache npm, conexões recentes, arquivos alterados no diretório do projeto e processos persistentes. Em seguida, revogue tokens, chaves e sessões que estavam acessíveis ao usuário comprometido, com prioridade para repositórios privados, provedores de cloud, carteiras, gerenciadores de pacotes, CI/CD e credenciais armazenadas no navegador. A simples remoção do repositório não é suficiente quando há sinais de backdoor, ambiente Python paralelo, AnyDesk ou comunicação contínua com servidor remoto.

No controle preventivo, organizações devem restringir execução automática de tarefas não revisadas, monitorar abuso de IDEs em EDR, permitir instalação npm apenas de registros e pacotes aprovados quando possível e registrar eventos de confiança concedida a workspace. A validação posterior precisa confirmar ausência de processos persistentes, mineradores, ferramentas de acesso remoto e módulos de coleta. Como a campanha muda payloads e métodos em intervalos curtos, regras baseadas apenas em nomes de arquivos ou domínios devem ser complementadas por detecções comportamentais: IDE iniciando runtime de script, runtime buscando código remoto, script acessando dados de usuário e canal externo mantendo execução remota.

• Revisar tasks.json, scripts npm e dependências antes de confiar em qualquer repositório recebido fora de canais internos.
• Abrir testes técnicos de terceiros em ambiente descartável, sem tokens, carteiras, chaves SSH ou sessões corporativas.
• Bloquear ou alertar quando VS Code iniciar Node.js, Python, shell ou ferramenta de acesso remoto a partir de projeto não aprovado.
• Revogar credenciais e tokens expostos no host sempre que houver execução de backdoor ou coleta de arquivos sensíveis.
• Correlacionar endpoint, rede, npm, identidade e repositórios para confirmar se houve uso indevido de permissões após a infecção.