A campanha que transforma testes técnicos em portas traseiras e executa código em memória em ambientes de desenvolvimento

Os desenvolvedores tornaram-se um alvo estratégico para atores maliciosos que buscam não só roubar credenciais, mas plantar acessos persistentes em máquinas com informações sensíveis. Um relatório recente da Microsoft descreve uma campanha coordenada que aproveita projetos ou testes técnicos falsos — principalmente fingindo ser projetos Next.js ou exercícios de entrevista — para induzir os desenvolvedores a executar código que depois carrega e executa programas controlados pelos atacantes. O objetivo final é muito claro: conseguir execução remota de código em memória e, daí, expandir controle sem deixar rastros em disco. Você pode ler a análise da Microsoft aqui: Microsoft Defender Security Research.

A ameaça vale a confiança que as equipes de desenvolvimento depositam nas ferramentas e fluxos cotidianos. Três caminhos de execução, distintos em seu ativador mas convergentes em seu resultado, foram descritos pelos pesquisadores. No primeiro, um arquivo de configuração do Visual Studio Code aproveita a automação do workspace para invocar tarefas ao abrir a pasta do projeto; a configuração usa um trigger que executa comandos remotos ao confiar o projeto, o que permite baixar um carregador hospedado em plataformas públicas e executá-lo a quente.

O segundo vector é o que acontece durante o desenvolvimento: basta lançar o servidor com o clássico comando de desenvolvimento — por exemplo, npm run dev — para ativar código oculto em bibliotecas JavaScript modificadas que aparentam ser dependências inofensivas, como um arquivo minificado de jQuery. Esse código malicioso descarrega um loader de um domínio de staging (com frequência Vercel) que, posteriormente, executa instruções diretamente no processo de Node.js.

O terceiro método é disparado ao iniciar o backend da aplicação: módulos ou rotas aparentemente legítimos podem conter lógica que, ao arrancar, envia o ambiente do processo (variáveis de ambiente, por exemplo) para um servidor externo e executa a resposta JavaScript em memória. Em todos os casos, a mesma carga útil JavaScript faz um perfil da máquina e contata periodicamente um endpoint de registro para obter um identificador único (“instanceId”) que serve para correlacionar e gerenciar a sessão.

A importância técnica de executar código em memória é que reduz a pegada forense em disco e facilita a entrega de uma segunda etapa que actue como controlador: um “stage 2” capaz de executar tarefas a procura, descobrir ativos no ambiente e exfiltrar informações. A Microsoft salienta que o controlador incorpora telemetria de erros, lógica de reintento e capacidade para gerenciar processos filhos – ou seja, se comporta como uma ferramenta de acesso remoto bem projetada. Mais detalhes no relatório original da Microsoft: relatório técnico.

Não é apenas Vercel: os atacantes também começaram a usar servidores de estágio alternativos para alojar etapas posteriores. Abstract Security Tem documentado uma mudança nas táticas para o uso de gists do GitHub e encurtar os URLs para esconder a verdadeira proveniência dos payloads. Além disso, identificaram um pacote npm malicioso chamado "eslint-validator" que recupera um payload ofuscado do Google Drive: esse payload coincide com uma família de malware JavaScript conhecida como BeaverTail.

No Windows observaram-se cadeias de infecção ainda mais elaboradas: uma tarefa de VS Code pode lançar um programa por lotes que download Node.js se não estiver presente, usa utilitários nativos como certutil para decodificar blocos de código embebidos e, com o runtime de Node, exibe um malware em Python protegido com PyArmor. Outras análises apontam para técnicas criativas de resiliência: injetar código dentro de contratos NFT em blockchains como Polygon para que o payload se recupere a partir daí, dificultando sua retirada e aumentando sua disponibilidade.

Pesquisadores independentes como Red Asgard Eles seguiram essa atividade e a vinculam com táticas usadas em campanhas anteriores conhecidas por sua sofisticação. Enquanto a Microsoft evita atribuir a campanha a um ator específico, os padrões coincidem com uma família de operações que no passado estiveram relacionadas com grupos norte-coreanos sob a hashtag “Contagious Interview” em alguns relatórios públicos.

Plataformas de colaboração e repositórios públicos não foram imunes: GitLab informou a eliminação de mais de uma centena de contas responsáveis por distribuir projetos maliciosos ligados a esta campanha. Sua equipe de inteligência também encontrou evidências internas que apontam para uma estrutura organizada por trás dessas operações, com registros financeiros e controle de desempenho de equipes, o que sugere uma atividade sustentada e orientada para benefício econômico. Mais contexto na análise do GitLab: GitLab Threat Intelligence.

Para aqueles que trabalham em desenvolvimento, isso deve soar o alarme: os repositórios de “teste técnico” ou modelos de entrevista são vetores ideais porque encaixam com tarefas diárias. Executar um servidor local, abrir um workspace ou confiar num projecto por defeito pode ser suficiente para desencadear uma cadeia de execução maliciosa. Ferramentas e serviços legítimos que hospedam conteúdos externos (Vercel, Render, Railway, JSON Keeper, npoint.io, entre outros) foram reutilizados pelos atacantes para armazenar e servir payloads.

As recomendações práticas não são radicais, mas exigem disciplina: limitar privilégios de contas de desenvolvimento, segregar ambientes de build e CI/CD da equipe de desenvolvimento, aplicar autenticação forte e acesso condicional, e filtrar ou auditar as tarefas e máquinas incluídas nos projetos antes de executá-las. Também convém digitalizar dependências, evitar executar programas de terceiros sem revisão e não confiar automaticamente em prompts de confiança do VS Code ou em tarefas com o runOn configurado para abrir pastas.

Além disso, as empresas e os responsáveis pela segurança devem instrumentar a detecção de processos Node.js que descarregam e avaliam JavaScript em memória, monitorizar as ligações enviadas para serviços de hospedagem públicos e usar listas brancas onde possível. Fornecedores de repositórios e plataformas já estão tomando medidas: a eliminação de contas e a coordenação entre equipamentos de segurança faz parte da resposta. Para entender a dimensão humana do problema e como o “emprego” é explorado como isco, o relatório do Okta oferece uma perspectiva interessante sobre como alguns candidatos falsos passam controles e são usados nestes esquemas: Análise do Okta.

A mensagem para a comunidade técnica é simples e urgente: não baixem a guarda. A combinação de engenharia social com a automação de fluxos de desenvolvimento converte um projeto Git aparentemente inocuo em uma porta traseira efetiva. Rever tasks.json, auditar dependências e tentar com suspeita qualquer projeto que solicite executar comandos automáticos ao abrir são medidas que podem parar estas cadeias antes de executarem o seu primeiro payload em memória.

Esta campanha é um lembrete de que a segurança do desenvolvimento deve incluir controlos específicos para os fluxos e ferramentas do dia-a-dia. Não se trata apenas de proteger servidores em produção: proteger o “cliente” – o equipamento do desenvolvedor – é igual de crítico quando esse cliente contém chaves, tokens e acesso a infraestrutura que pode se traduzir em segundos. Manter boas práticas de higiene de credenciais, segmentação e revisão de código é hoje uma defesa imprescindível.