Mercado apertado, processo seletivo mais duro e take-home test virando rotina: esse já era um combo cansativo para quem trabalha com desenvolvimento. O problema é que agora ele também virou vetor de ataque.
Relatórios publicados por Elastic, Microsoft e JFrog mostram uma campanha que se aproveita justamente da confiança em entrevistas técnicas, desafios práticos e repositórios aparentemente normais para roubar credenciais, arquivos sensíveis e até abrir acesso remoto na máquina do dev.
Não é phishing grosseiro. Em vários casos, o pacote malicioso vem escondido dentro de um projeto funcional, com cara de teste real, stack plausível e fluxo que parece parte normal da seleção.
O que muda nesse golpe é o ponto de entrada
Segundo a Elastic, a investigação começou depois de um falso recrutador abordar pessoas em um canal de vagas e mandar um desafio técnico trojanizado. O repositório parecia legítimo, rodava de verdade e tinha trechos maliciosos escondidos no projeto.
Na amostra analisada, o payload era montado a partir de fragmentos em arquivos SVG e executado quando o servidor do projeto era iniciado. A Microsoft descreve a mesma lógica em escala maior: recrutadores falsos, testes práticos, pacotes npm ou tarefas do VS Code e, no fim, um backdoor rodando em segundo plano.
É isso que torna a campanha especialmente perigosa: ela não depende de um clique descuidado em um anexo suspeito. Ela depende de um comportamento que hoje já virou rotina para muita gente em TI — baixar código, abrir no editor, instalar dependências e provar que consegue entregar.
O que os atacantes tentam pegar
Os relatórios convergem num ponto: a ambição do golpe é muito maior do que “roubar um login”. Dependendo da variante, o malware tenta coletar:
- credenciais salvas no navegador;
- dados de extensões de carteira cripto;
- arquivos como
.env, chaves SSH, histórico de shell e documentos; - clipboard, screenshots e dados da máquina;
- acesso remoto para execução de comandos.
A JFrog mostrou outro braço do mesmo ecossistema: pacotes npm com nome plausível, README copiado e comportamento escondido em dependências que parecem banais. O detalhe importante aqui é editorial, não só técnico: o ataque está sendo moldado para o ambiente real de trabalho de quem programa.
Ou seja: ele mira justamente a máquina que costuma concentrar código, tokens, acesso a cloud, sessões de navegador, repositórios privados e credenciais de produção. Um notebook de dev comprometido vale muito.
Por que isso conversa tanto com o momento do mercado
Esse tipo de campanha cresce num contexto em que muita gente está mais vulnerável a pressão de processo seletivo. Quem está procurando vaga aceita mais etapas, faz mais take-home, baixa mais material “de teste” e tolera mais fricção para não perder oportunidade.
É aí que o golpe encaixa. Ele imita a linguagem do mercado atual: projeto curto, desafio assíncrono, stack moderna, promessa de conversa depois da entrega e alguma urgência para começar logo.
O lado cruel é que ele explora uma dor real. O profissional já está cansado de pipeline lento, ghost job e triagem opaca. Quando aparece algo com aparência concreta, a tendência é baixar a guarda.
Sinais que merecem acender alerta antes de rodar qualquer teste
Nenhum sinal isolado prova golpe, mas alguns padrões merecem freio imediato:
- recrutador empurrando contato para DM, Telegram ou e-mail improvisado muito cedo;
- repositório sem histórico confiável, com zip solto ou origem mal explicada;
- pedido para rodar scripts antes mesmo de você entender a base;
- instrução para confiar no workspace do VS Code ou instalar pacote estranho “para o teste funcionar”;
- urgência artificial do tipo “roda isso rápido e me manda hoje”.
Em processo sério, dá para existir pressa. O que não deveria existir é opacidade demais justamente no material que você vai executar localmente.
Se você já rodou algo suspeito, trate como incidente
Se bateu a dúvida depois de executar o teste, o melhor caminho não é “observar mais um pouco”. É assumir comprometimento possível e agir rápido.
- desconecte a máquina da rede;
- revogue e rotacione tokens, senhas, chaves e sessões importantes;
- revise acessos de GitHub, cloud, npm, registries e contas com MFA;
- inspecione processos, diretórios temporários e histórico recente de comandos;
- se a máquina concentra acesso crítico, considere resposta completa de incidente.
Nos relatórios, os próprios pesquisadores recomendam tratar hosts afetados como potencialmente comprometidos antes de simplesmente trocar uma ou outra senha. Faz sentido: quando o objetivo inclui coleta ampla de arquivos e acesso remoto, o estrago possível vai além da primeira credencial vazada.
A lição mais importante para 2026
Durante muito tempo, o conselho de segurança para dev parecia girar em torno de dependency confusion, pacote malicioso e segredo exposto em repositório. Isso continua valendo. Mas agora o funil de contratação também entrou de vez na superfície de ataque.
Então a regra prática muda um pouco: take-home e desafio técnico precisam ser tratados com a mesma desconfiança operacional que você já usaria com código de origem duvidosa.
Não porque todo processo seletivo seja suspeito. Mas porque os melhores golpes de 2026 estão justamente imitando os processos que a gente aprendeu a tratar como normais.
