Receber contato direto de recrutador no LinkedIn já mexe com a cabeça de muita gente. Se a vaga parece boa demais, paga em dólar e ainda vem com pressa, a tentação de ignorar o desconforto e seguir em frente é real.
Foi exatamente aí que um desenvolvedor percebeu que a entrevista não era entrevista nenhuma. Segundo o relato publicado por Appaji e depois discutido no Hacker News, o suposto processo seletivo mandava um desafio técnico em FastAPI com um detalhe escondido: o repositório já vinha armado para puxar código remoto e rodar payload no computador da vítima.
O caso é forte por dois motivos. Primeiro, porque parece plausível demais para quem trabalha com software. Segundo, porque ele não nasceu do nada. Em 2025, o Canaltech já tinha resumido uma campanha maior de falsas entrevistas usada para instalar malware em candidatos. Ou seja: não é paranoia de terminal. É uma categoria real de golpe.
Se você está procurando vaga agora, vale tratar esse tipo de teste técnico como material potencialmente hostil até prova em contrário.
o que aconteceu nesse caso
No relato original, o dev recebeu no LinkedIn uma abordagem para uma vaga de Python remota, com faixa de US$ 10 mil a US$ 15 mil por mês em modelo contract-to-hire. A proposta já parecia generosa demais para o contexto dele, mas ainda não era impossível a ponto de encerrar a conversa na hora.
Depois do currículo, veio um link do Google Drive com um PDF de instruções e um ZIP com o suposto projeto do teste. O pacote parecia legítimo: backend em FastAPI, SQLAlchemy, estrutura conhecida, dependências limpas e nada gritante no requirements.txt.
O alerta apareceu quando ele fez uma coisa simples que muita gente não faz: rodou um tree -a para olhar os diretórios ocultos. Lá estava a pasta .git/hooks cheia de scripts já configurados. No pre-commit, o comportamento era direto demais para passar batido: detectar o sistema operacional, baixar um script remoto por IP cru e executar em segundo plano.
A partir daí a história piora. O segundo estágio baixava outro arquivo, renomeava, dava permissão de execução, puxava parser.js e package.json, instalava dependências em Node e deixava o processo rodando de forma silenciosa. O autor também notou que o payload mudava conforme o identificador enviado na URL, sinal de rastreamento por vítima.
No fim, o suposto teste técnico não existia para medir arquitetura nem Git. As tarefas com Git estavam ali para aumentar a chance de o candidato acionar o hook malicioso sem perceber.
por que esse caso assusta mais do que o golpe comum de vaga
Golpe de vaga falsa já é ruim quando serve só para colher currículo, documento ou conversa fora da plataforma. Aqui o problema sobe um nível: o candidato é empurrado para executar código local como parte de um ritual que parece normal para a área.
É isso que torna o caso especialmente perigoso para devs, analistas de dados, pessoal de infra e qualquer profissional acostumado a clonar projeto, instalar dependência e rodar comando sem transformar isso em evento extraordinário.
No Hacker News, a discussão foi nessa linha. Uma das reações mais úteis foi tratar esse contato como ligação “do banco”: se veio por abordagem direta, a validação precisa sair do canal do próprio golpista. Outra observação importante apareceu nos comentários: mesmo quando a empresa citada é real, o outreach pode ser falso ou terceirizado de um jeito opaco demais para inspirar confiança.
No Brasil, isso conversa bem com o que a gente já vem vendo em temas como vaga fantasma no LinkedIn e recrutador falso em TI. A diferença é que agora o prejuízo não é só emocional ou de tempo perdido. Pode virar comprometimento real de máquina, credencial e carteira.
os sinais que merecem travar sua mão antes do próximo comando
Nem todo teste técnico remoto é golpe. Mas alguns sinais já justificam parar tudo e validar melhor:
- abordagem boa demais, rápida demais e com faixa salarial usada como isca logo na primeira troca;
- PDF bonito demais compensando falta de processo claro, site de carreira ou email corporativo verificável;
- entrega de ZIP ou repositório por Google Drive, WeTransfer ou pasta solta sem trilha oficial da empresa;
- tarefa que força
git commit,npm install, scripts locais ou correção de ambiente cedo demais; - domínio estranho, IP cru, comando copiado em terminal ou “ajuste” para câmera/microfone funcionar;
- pressão para executar o teste na sua máquina principal.
Quando dois ou três desses sinais aparecem juntos, o melhor cenário já deixou de ser “processo normal”.
o mínimo de higiene para olhar teste técnico sem agir como alvo fácil
Se você está em busca ativa, não dá para virar refém do medo. Mas também não dá para continuar tratando qualquer take-home como se viesse esterilizado.
O mínimo hoje é isso aqui:
- validar a vaga no site oficial da empresa ou por email corporativo real;
- checar se o recrutador existe mesmo e se aparece ligado à empresa fora da conversa inicial;
- inspecionar arquivos ocultos, hooks, scripts de bootstrap e dependências antes de rodar qualquer coisa;
- abrir o material em máquina isolada, VM ou ambiente descartável quando houver comando local;
- nunca copiar e colar comando “de correção” passado por entrevistador para câmera, terminal, Git ou pacote;
- tratar teste técnico como código de terceiro: leitura primeiro, execução depois.
Isso parece exagero até o dia em que não parece mais.
o ponto editorial que esse caso deixa
Mercado ruim costuma empurrar candidato para um estado mental péssimo: aceitar pressa, aceitar obscuridade, aceitar processo torto porque “vai que é minha chance”. É justamente nesse estado que golpe bem montado funciona melhor.
O problema é que o ritual da área ajuda o golpista. Em TI, executar projeto, instalar dependência, mexer com Git, rodar script e resolver ambiente fazem parte da rotina. Então a fraude não precisa parecer totalmente estranha. Ela só precisa parecer familiar o bastante.
Talvez o ajuste mais importante para 2026 seja esse: processo seletivo também virou superfície de ataque. Não só inbox, não só currículo, não só link de phishing. Processo técnico mesmo.
Se a vaga for séria, pedir validação adicional não deveria matar a oportunidade. Se matar, talvez o problema já estivesse ali desde o começo.
