A Ameaça que Explora as Tarefas do Visual Studio Code para Executar Código Remoto

Há semanas que os investigadores de segurança vêm observando uma variação inquietante nas técnicas dos grupos ligados à Coreia do Norte: em vez de recorrer apenas a emails de phishing clássicos ou a exploits web, estão explorando o fluxo de trabalho cotidiano dos desenvolvedores. A treta consiste em convencer engenheiros — especialmente aqueles que trabalham em criptomoeda, blockchain e finanças — de clonar um repositório e abrir o projeto em Visual Studio Code, com o gancho de um suposto exercício técnico ou uma oferta laboral. Se a vítima confiar no repositório e abrir o projeto, é ativada uma cadeia que pode terminar entregando um backdoor com capacidades de execução remota.

O mecanismo central do ataque são os ficheiros de configuração de tarefas do VS Code (tasks.json), que podem ser configurados automaticamente quando a pasta do projecto é aberta. Essa opção –usada legitimamente para automatizar tarefas de desenvolvimento – está sendo abusada para orquestrar downloads e execução de código JavaScript ofuscado hospedado em serviços externos como domínios em Vercel. Pesquisas públicas e relatórios técnicos documentaram como essa mesma tática serviu para implantar famílias de malware como BeaverTail (capa Node.js) e InvisibleFerret (capa Python), além de mineiros e backdoors conhecidos pelo ecossistema de ameaças.

As análises iniciais, publicadas por grupos como OpenSourceMalware e ampliados por assinaturas como Jamf, mostram uma evolução constante: quando o projecto é aberto no VS Code, a aplicação solicita ao utilizador que indique se confia no autor do repositório; se essa confiança for concedida, o VS Code processa automaticamente o tasks.json e pode executar comandos arbitrários na máquina. No macOS, por exemplo, tem-se visto como a cadeia de execução é lançada em segundo plano - usando ferramentas padrão do sistema - para recuperar e executar um payload JavaScript com Node.js, permitindo que o processo continue mesmo se o editor for fechado.

JavaScript remoto atua como implante principal: cria um ciclo persistente que coleta informações básicas do computador, faz fingerprinting e mantém comunicação contínua com um servidor de comando e controle, o que habilita a execução remota de código. Em alguns incidentes, detectou-se que minutos após a infecção inicial foram descarregadas instruções adicionais que beaconéan ao servidor a cada poucos segundos, executam mais código e, ante a ordem do operador, limpam rastros para dificultar a pesquisa. Os pesquisadores até têm apontado indícios de uso de ferramentas de inteligência artificial para gerar partes do código, pela presença de comentários inline e certo estilo de redação no JavaScript.

Além da técnica principal, os atores prepararam rotas de reserva para maximizar sua taxa de sucesso. Se a tarefa de VS Code não conseguir recuperar o payload a partir de Vercel, o repositório pode esconder droppers sofisticados dentro de arquivos que aparentam ser inofensivos – por exemplo, “dicionários” para correção ortográfica – que também contêm JavaScript ofuscado. Em outros casos é oferecida a instalação de uma dependência npm maliciosa (se identificou o pacote grayavatar em análise pública) ou a transferência de um controlador Node.js que, por sua vez, lança módulos para registar cliques, capturar ecrãs, procurar ficheiros sensíveis na pasta do utilizador, suplantar endereços de carteira copiados para a área de transferência e extrair credenciais de navegadores. Paralelamente, os atacantes preparam um ambiente em Python que facilita a mineração de criptomoeda com XMRig, a implantação de ferramentas de acesso remoto e a exfiltração de dados.

Pesquisas complementares documentaram variantes com nomes e componentes distintos: equipamentos como Red Asgard Analisaram repositórios que distribuem um backdoor chamado Tsunami (também conhecido como TsunamiKit) junto a um mineiro XMRig, enquanto outros relatórios técnicos descreveram como os atacantes abordam vítimas via redes profissionais como o LinkedIn para enviar links para testes técnicos que apontam para repositórios maliciosos, explorando a confiança profissional.

Por trás destas operações estão atores ligados ao regime norte-coreano, que historicamente colocaram o foco em especialistas em software com acesso a infra-estruturas financeiras e chaves digitais. O benefício para o grupo atacante é claro: acessar código fonte, segredos, contas e, em muitos casos, mover ou roubar ativos digitais. A variação e multiplicidade dos vetores observados sugere uma estratégia deliberada de experimentar com diferentes técnicas para aumentar a probabilidade de comprometimento e, consequentemente, a capacidade de financiamento de suas operações.

Estas campanhas são também uma lição sobre como as ferramentas legítimas para desenvolvedores podem se tornar vetores de ataque quando se confia cegamente em conteúdo externo. Visual Studio Code oferece funções pensadas para economizar tempo, mas essa automação pode tornar-se perigosa se não se aplicarem controles e boas práticas. Se você quer aprofundar como as tarefas do VS Code funcionam, a documentação oficial é um bom ponto de partida: Documentação de tasks no Visual Studio Code.

Para aqueles que trabalham em desenvolvimento ou gerem equipamentos técnicos, a recomendação é clara: não conferir confiança automática a repositórios desconhecidos, rever qualquer tasks.json antes de permitir a sua execução e tratar com cautela dependências externas. As organizações devem complementar estas medidas com controlos de rede que bloqueiem domínios suspeitos, políticas de execução restritivas para ambientes de desenvolvimento e ferramentas de detecção que possam identificar comportamentos de beaconing, persistência e mineração. Os relatórios e análises públicas de grupos como Jamf, Red Asgard e Security Alliance oferecem detalhes técnicos úteis para defensores que queiram compreender e mitigar essas ameaças; você pode consultar suas publicações para ampliar a leitura: Jamf, Red Asgard e Security Alliance.

Em suma, a ameaça não é apenas técnica, mas cultural: confiar em repositórios e exercícios técnicos sem verificar sua proveniência é uma vulnerabilidade humana que os atacantes exploram com criatividade. A boa notícia é que, ao contrário das lacunas por vulnerabilidades de dia zero, esse abuso é melhor gerido com políticas e práticas de higiene digital: inspecionar, questionar e limitar a execução automática no ambiente de desenvolvimento pode evitar que uma entrevista ou um desafio acadêmico se tornem a porta de entrada para um backdoor persistente.