Repositórios falsos de emprego em Next.js entregam malware em memória contra desenvolvedores

Campanha usa avaliações técnicas falsas, tarefas do VS Code e carregadores em Node.js para obter execução em memória, persistência e acesso a sistemas de desenvolvimento com código-fonte, segredos e credenciais.

Componente	Repositórios falsos de projetos Next.js, tarefas do VS Code, bibliotecas JavaScript modificadas, módulos backend e pacote npm eslint-validator associados a cadeias de malware contra desenvolvedores.
Vetor	A vítima é atraída por uma avaliação técnica ou projeto de entrevista, abre ou confia no workspace, inicia o servidor de desenvolvimento ou executa o backend, acionando JavaScript controlado pelo operador em tempo de execução.
Impacto	Execução de JavaScript em memória, comunicação com C2, perfilamento do host, persistência operacional, tarefas sob demanda e risco de coleta de segredos, credenciais, dados de navegadores, carteiras de criptomoedas e arquivos do sistema.
Prioridade	Restringir confiança em projetos recebidos de processos seletivos, revisar automações de workspace, isolar ambientes de desenvolvimento, aplicar privilégio mínimo a contas de desenvolvedor e rotacionar credenciais expostas.
Artefatos	Foram observados nomes e técnicas como Cryptan-Platform-MVP1, runOn: "folderOpen", eslint-validator, JADESNOW, variantes ligadas a Akira Stealer, uso de Vercel, gists do GitHub, encurtadores de URL e recuperação de JavaScript via contrato NFT na Polygon.
IoCs	Indicadores citados incluem gist.githubusercontent[.]com, short[.]gy, JSON Keeper, Mocki, npoint.io, Render, Railway.app e Vercel como serviços abusados para hospedagem ou estágio de payloads.

Resumo técnico

Uma campanha coordenada contra desenvolvedores está usando repositórios falsos apresentados como projetos legítimos de Next.js e avaliações técnicas de emprego. O objetivo é fazer com que a vítima trate o código como parte de um fluxo normal de entrevista, abra o projeto em ferramentas de desenvolvimento ou inicie a aplicação localmente. A partir desse ponto, diferentes caminhos de execução convergem para a mesma finalidade: recuperar JavaScript controlado pelo operador durante a execução e rodá-lo diretamente em memória, reduzindo a dependência de artefatos persistentes em disco.

A operação explora a confiança operacional comum em ambientes de engenharia. Projetos recebidos em processos seletivos costumam ser clonados, abertos em editores, instalados e testados rapidamente, muitas vezes em estáções que também têm acesso a repositórios privados, chaves de API, tokens de nuvem, credenciais de pacote, carteiras de desenvolvimento e sistemas internos. Essa combinação transforma uma avaliação técnica falsa em um vetor de acesso inicial contra ativos de alto valor, especialmente quando o ambiente local não está isolado do restante da identidade corporativa ou da infraestrutura de build.

A cadeia documentada apresenta múltiplos pontos de entrada. Em um deles, a execução ocorre por automação de workspace no Visual Studio Code. Em outro, a atividade é acionada quando o desenvolvedor inicia o servidor de desenvolvimento. Um terceiro fluxo aparece no momento em que o backend da aplicação é lançado, com lógica maliciosa escondida em módulo ou rota. Apesar das diferenças, os fluxos compartilham um padrão: carregadores JavaScript obtêm conteúdo remoto, executam código no processo Node.js e mantêm comunicação periódica com infraestrutura de comando e controle.

Fluxo técnico

O primeiro caminho usa projetos do VS Code preparados para executar tarefas quando a pasta é aberta e confiada. A configuração runOn: "folderOpen" permite que uma tarefa seja disparada no contexto do workspace sem que o usuário perceba uma instalação tradicional de malware. Em campanhas desse tipo, o risco está na fronteira entre conveniência de automação e execução implícita: um projeto que aparenta ser uma avaliação de emprego passa a ser capaz de iniciar scripts, buscar conteúdo remoto e acionar etapas adicionais antes mesmo de uma revisão completa do código.

O segundo caminho é acionado durante o desenvolvimento da aplicação. Ao iniciar o servidor local, bibliotecas JavaScript modificadas, incluindo arquivos apresentados como jquery.min.js, carregam um loader remoto hospedado em infraestrutura externa. O payload recuperado é executado em memória pelo Node.js, o que dificulta análise baseada apenas em arquivos criados no disco. Esse padrão também prejudica revisões superficiais, porque o projeto pode parecer funcional enquanto componentes específicos desviam o fluxo para código remoto em tempo de execução.

O terceiro caminho aparece no startup do backend. A lógica maliciosa fica escondida em módulo ou arquivo de rota, coleta o ambiente do processo e envia variáveis para um servidor externo antes de executar JavaScript retornado pela resposta. Esse ponto é sensível porque variáveis de ambiente frequentemente contêm tokens, URLs internas, segredos de banco de dados, credenciais temporárias, chaves de serviços e configurações de provedores de nuvem. Mesmo quando a execução remota não progride para uma etapa mais agressiva, a exposição desse ambiente já pode comprometer controles de identidade e acesso.

Após o estágio inicial, o malware registra o host e consulta periodicamente um endpoint para obter um identificador único de instância. Esse identificador é reutilizado nas chamadas seguintes para correlacionar sessões, erros e tarefas. O segundo estágio atua como controlador persistente: mantém continuidade da sessão, registra falhas, aplica lógica de repetição, acompanha processos iniciados e pode encerrar atividades gerenciadas quando recebe instrução. O operador também pode enviar JavaScript adicional para execução em memória, incluindo tarefas de descoberta e coleta de dados. Há menção a cadeias que usam JADESNOW, um pacote npm malicioso chamado eslint-validator e uma variante associada ao infostealer Akira Stealer, mas a atribuição permanece limitada quando técnicas semelhantes aparecem com payloads finais diferentes.

Superfície afetada

A superfície principal são estáções de desenvolvedores e ambientes locais usados para avaliação, teste, build ou manutenção de aplicações JavaScript. Sistemas com VS Code, Node.js, npm, acesso a repositórios privados e credenciais persistidas no perfil do usuário ficam mais expostos quando projetos externos são executados sem sandbox. A campanha também toca serviços legítimos usados como hospedagem de payloads, incluindo Vercel, gists do GitHub, Render, Railway[.]app, JSON Keeper, Mocki e npoint[.]io, o que complica bloqueios baseados apenas em reputação de domínio.

O uso de temas de entrevista e projetos de emprego também amplia a chance de execução por usuários tecnicamente capazes, mas pressionados a demonstrar rapidamente que conseguem rodar uma aplicação. Foram observados repositórios em plataformas confiáveis, incluindo Bitbucket, com nomes que simulam produtos ou provas de conceito, como Cryptan-Platform-MVP1. Também há evidências de contas usadas para distribuir projetos maliciosos em plataformas de desenvolvimento, com grande uso de contas criadas por e-mail Gmail, conexões originadas de VPNs de consumo, VPS dedicados e endereços possivelmente ligados a fazendas de laptops.

• Estáções com VS Code configurado para confiar em workspaces recebidos de terceiros.
• Ambientes Node.js usados para iniciar servidores Next.js, backends ou scripts de desenvolvimento.
• Perfis de desenvolvedor com tokens de nuvem, segredos em variáveis de ambiente, credenciais de registries e acesso a repositórios privados.
• Pipelines e identidades de build que compartilham credenciais ou permissões excessivas com estáções de trabalho.
• Projetos de entrevista recebidos por links, repositórios privados, Bitbucket, GitHub ou pacotes npm não verificados.

Hunting e telemetria

A detecção deve combinar telemetria de endpoint, editor, rede, identidade e repositórios. Em endpoints Windows, Linux e macOS, a defesa deve procurar processos Node.js iniciados a partir de diretórios de projetos recém-clonados e realizando conexões HTTP externas para domínios de hospedagem, encurtadores ou endpoints incomuns. A presença de execução em memória reduz a utilidade de buscas apenas por arquivos finais, portanto o foco deve incluir linha de processo, árvore de processos, scripts de inicialização, alterações em .vscode/tasks.json, bibliotecas JavaScript inesperadamente modificadas e módulos backend que enviam variáveis de ambiente para fora da rede.

Em VS Code, sinais relevantes incluem tarefas configuradas para disparar na abertura de pasta, especialmente runOn: "folderOpen", tarefas que chamam shells nativos, scripts que decodificam blocos incorporados e projetos que baixam runtime adicional quando o ambiente não possui dependências esperadas. Em Node.js, a telemetria deve destacar chamadas de rede durante inicialização da aplicação, execução dinâmica de JavaScript retornado por resposta remota e dependências que aparentam ser utilitárias de lint, validação ou biblioteca comum, mas fazem download de payload ofuscado.

Na camada de identidade, alertas devem acompanhar uso anômalo de tokens após a execução de projetos suspeitos. Isso inclui chamadas a repositórios privados a partir de novos endereços, criação de chaves, acesso incomum a artefatos de CI/CD, leitura de secrets, autenticações fora do padrão e eventos de consentimento ou sessão que surjam logo após a execução local da avaliação técnica. Para rede, é útil agrupar conexões para domínios defangados citados, como gist.githubusercontent[.]com e short[.]gy, além de serviços legítimos usados como estágio, sem tratar todos os acessos a essas plataformas como maliciosos por padrão.

• Criação ou alteração de .vscode/tasks.json contendo acionamento automático na abertura da pasta.
• Processos Node.js de projetos recém-obtidos fazendo requisições externas antes de qualquer interação funcional clara.
• Envio de variáveis de ambiente para endpoints externos durante startup do backend.
• Dependências npm incomuns, incluindo eslint-validator, buscando payload ofuscado em armazenamento externo.
• Conexões para encurtadores de URL, gists, Vercel e plataformas de hospedagem usadas fora do padrão normal da equipe.
• Atividade posterior em repositórios, nuvem, registries ou CI/CD usando credenciais presentes na estáção do desenvolvedor.

Mitigação

A resposta deve começar pela contenção do fluxo de confiança em projetos externos. Avaliações técnicas, repositórios enviados por recrutadores e projetos de terceiros devem ser abertos primeiro em ambiente isolado, sem tokens corporativos, sem acesso a VPN interna e sem credenciais persistidas. Workspaces do VS Code não devem ser marcados como confiáveis automaticamente, e tarefas com execução na abertura de pasta precisam passar por revisão antes de qualquer inicialização. Para equipes que recebem muitos projetos externos, imagens descartáveis, máquinas virtuais sem segredos e contas de baixo privilégio reduzem o impacto de um carregador malicioso.

Organizações devem revisar permissões de desenvolvedores, identidades de build e segredos locais. Contas usadas para desenvolvimento não devem ter acesso amplo e permanente a ambientes de produção, registries sensíveis ou sistemas de CI/CD sem autenticação forte e controles condicionais. Segredos que possam ter sido presentes em máquinas expostas precisam ser rotacionados, incluindo tokens de Git, chaves de pacotes, credenciais de nuvem, variáveis de ambiente de aplicações e credenciais armazenadas por navegadores ou ferramentas de linha de comando. A rotação deve ser acompanhada por revisão de uso, porque o abuso pode ocorrer depois da execução inicial.

Para hardening, mantenha autenticação forte, acesso condicional, separação entre infraestrutura de build e estáção de trabalho, revisão de dependências e políticas de bloqueio para automações de workspace desconhecidas. Em incidentes confirmados, preserve artefatos do projeto, telemetria de processos, logs de rede, histórico do editor e eventos de identidade antes de limpeza agressiva. A erradicação deve considerar que parte do código foi executada em memória e que o controlador pode ter recebido tarefas diferentes por instância; por isso, a ausência de um binário final no disco não encerra a análise.

• Abrir projetos de entrevista apenas em sandbox sem credenciais corporativas e sem acesso à rede interna.
• Revisar tasks.json, scripts de inicialização, dependências npm e módulos backend antes de confiar no workspace.
• Bloquear ou alertar para tarefas do VS Code com execução automática na abertura de pasta.
• Aplicar privilégio mínimo a contas de desenvolvedor e identidades de build.
• Rotacionar tokens e segredos presentes em máquinas que executaram projetos suspeitos.
• Correlacionar execução local com acessos posteriores a repositórios, registries, nuvem e CI/CD.
• Criar política formal para avaliações técnicas recebidas de terceiros, com ambiente descartável e logs habilitados.