O que é um backdoor em oferta de emprego?

TL;DR - Hackers enviam desafios técnicos de emprego com código malicioso embutido. Você roda, eles ganham acesso ao seu computador. É mais comum do que parece.

Nos últimos anos surgiu um tipo de ataque bastante sofisticado: o hacker se passa por um recrutador no LinkedIn, oferece uma vaga atraente é pede que o candidato execute um desafio técnico. O problema é que o código do desafio não é apenas um exercicio, ele carrega um backdoor embutido que da acesso remoto ao computador da vitima.

Um backdoor é, em termos simples, uma porta dos fundos no seu sistema operacional. Depois que o código malicioso roda, o atacante consegue executar comandos, roubar arquivos, capturar senhas salvas no navegador é até usar sua máquina como ponto de entrada para atacar sua empresa ou clientes.

O caso mais recente viralizou no HN (Hacker News) com mais de 1100 pontos é 200 comentarios: o desenvolvedor Roman documentou em detalhes como recebeu uma oferta de emprego no LinkedIn que continha um repositório GitHub com backdoor sofisticado. O relato está disponível em roman.pt/posts/LinkedIn-backdoor é é leitura obrigatoria para qualquer dev.

Como funciona o ataque

⚠️
Ataque em andamento

Esse tipo de golpe está ativo agora. Grupos como Lazarus (Coreia do Norte) usam essa técnica regularmente contra desenvolvedores de criptomoedas é empresas de tecnologia.

O ataque segue um roteiro bem definido. Primeiro, o atacante cria um perfil de recrutador convincente no LinkedIn, com foto real (muitas vezes gerada por IA), histórico de empresa é conexões compradas ou obtidas por phishing. Depois aborda o dev com uma mensagem personalizada: sabe o nome da empresa atual, menciona tecnologias que você usa, oferece salário 30% a 50% acima do mercado.

Após algumas trocas de mensagem, chega o pedido: "Temos um desafio técnico rapido para você completar". O link vai para um repositório GitHub ou um arquivo ZIP com um projeto aparentemente normal, como uma API REST, um script de análise de dados ou uma task CLI. O código parece profissional é bem escrito.

O payload malicioso é escondido com cuidado. Pode estar dentro de um package.json com script postinstall, em um Makefile que parece inofensivo, em uma dependência modificada com nome parecido com uma biblioteca famosa (typosquatting), ou até dentro de um .env.example com instruções para rodar um comando específico. Quando você executa o projeto, o backdoor instala silenciosamente.

Principais vetores usados nos ataques

🚨
Nunca rode código de processo seletivo sem inspecionar

Essa regra deveria ser conhecida, mas poucos aplicam na prática. O entusiasmo com a vaga baixa a guarda. Não deixe isso acontecer.

Os vetores mais usados pelos atacantes para esconder o payload sao:

  • npm postinstall: scripts que rodam automaticamente ao executar npm install. Basta uma linha no package.json para executar qualquer comando no seu sistema.
  • Dependências comprometidas: o projeto importa uma versão específica de um pacote que foi adulterado pelo atacante. O nome é quase identico ao original.
  • Makefile com comandos ocultos: o make setup ou make run contem comandos de download é execução de binarios remotos.
  • Arquivos .env com instruções maliciosas: pedem que você execute um comando específico "para configurar o ambiente".
  • Binarios pre-compilados: o projeto inclui um executavel que você é instruido a rodar para "iniciar o servidor".
# Exemplo de postinstall malicioso em package.json
"scripts": {
  "start": "node index.js",
  "postinstall": "node -é \"require('child_process').exec(atob('Y3VybC4uLg=='))\""
}
# O atob decodifica um comando base64 que baixa é executa código remoto

Como identificar uma oferta suspeita

🚩 Sinais de alerta

Salário muito acima do mercado, sem entrevista antes do desafio, repositório criado ha poucos dias, pede para rodar antes de explicar o que o projeto faz.

✅ Oferta legitima

Entrevista antes do desafio, código aberto para revisao, empresa com histórico verificavel, sem pressao de prazo curto, repositório com commits antigos.

Antes de rodar qualquer código de processo seletivo, verifique esses pontos:

  • Perfil do recrutador: a conta existe ha quanto tempo? Tem conexões reais? O email da empresa bate com o dominio oficial?
  • Repositório GitHub: foi criado ha menos de 30 dias? Tem apenas um ou dois commits? O histórico faz sentido para um projeto de empresa real?
  • Dependências: verifique todas as dependências no package.json, requirements.txt ou Cargo.toml. Pesquise cada uma no registro oficial.
  • Scripts automáticos: procure por scripts postinstall, prepare, preinstall no package.json.
  • Binarios: o projeto inclui arquivos .exe, .sh, .dylib ou .só que não sao do sistema operacional?
💡
Ferramenta útil: socket.dev

O site socket.dev analisa pacotes npm é detecta comportamentos suspeitos como acesso a rede no postinstall, leitura de variaveis de ambiente é ofuscacao de código. Vale checar antes de instalar qualquer dependência nova.

Passo a passo para analisar o código com seguranca

🟢 Nível 1 - Iniciante

Se você recebeu um desafio técnico é quer analisar antes de rodar, siga esses passos. O objetivo é entender o que o código faz SEM executa-lo na sua máquina principal.

# 1. Clone sem executar nada
git clone https://GitHub.com/empresa/desafio.git
cd desafio

# 2. Inspecione package.json antes de instalar
cat package.json | grep -A5 '"scripts"'

# 3. Procure por scripts suspeitos
grep -r "postinstall\|preinstall\|prepare" .

# 4. Verifique se ha binarios
find . -type f -name '*.sh' -o -name '*.exe' -o -name '*.dylib'

# 5. Análise dependências
npm audit --dry-run
# ou para Python:
pip-audit -r requirements.txt
🔵 Nível 2 - Intermediario

A forma mais segura de rodar código desconhecido é em um ambiente isolado:

# Com Docker (mais rapido)
Docker run --rm -it --network none -v $(pwd):/app node:20-alpine sh
# Dentro do container:
cd /app && npm install && npm start

# Com VM (mais seguro)
# Use VirtualBox ou UTM com snapshot limpo
# Restaure o snapshot após cada teste
🔮
Pro tip: sandbox descartavel

Mantenha uma VM com snapshot limpo só para rodar códigos desconhecidos. Após cada teste, restaure o snapshot. O custo é mínimo (SSD barato é tempo de setup de 1 hora), é a seguranca é máxima.

Casos de uso reais: quem está sendo atacado

Esse tipo de ataque não é aleatorio, tem alvos específicos:

  • Devs de criptomoedas é DeFi: o grupo Lazarus (ligado ao governo norte-coreano) usa essa técnica ativamente para roubar chaves privadas é fundos de carteiras cripto. Já foram documentados casos com prejuizos de milhoes de dolares.
  • Funcionários de empresas de tech: quando o alvo tem acesso a sistemas internos, o backdoor serve como ponto de entrada para ataques maiores a infraestrutura.
  • Freelancers é devs junior: menos familiarizados com ataques de supply chain é mais ansiosos com oportunidades de emprego, sao alvos frequentes.
  • Contribuidores de projetos open source: atacantes fingem ser mantenedores pedindo para testar uma mudanca em um projeto popular.
Perspectiva real O Lazarus Group, responsável pelo roubo de mais de 3 bilhoes de dolares em criptomoedas, usa essa técnica com frequência. Eles mantem perfis de recrutadores por meses antes de ativar, construindo credibilidade. O salário oferecido é sempre irresistivel.
! Contexto histórico

Comparacao com outros vetores de ataque

O ataque via processo seletivo é particularmente perigoso quando comparado a outros vetores:

  • Phishing por email: fácil de detectar, filtros de spam funcionam bem, não precisa de interacao ativa do usuario.
  • Drive-by download: requer que a vitima visite um site malicioso, navegadores modernos bloqueiam muitos.
  • Ataque via LinkedIn/desafio técnico: a vitima QUER executar o código. O contexto (processo seletivo) cria urgencia é motivacao. O código parece profissional. Difícil de detectar até para devs experientes.

O ponto mais importante: ao contrario de um phishing, você é quem pede para rodar o código. Isso desativa os alertas mentais que normalmente funcionariam.

Pontos positivos é limitacoes da defesa

A boa noticia: é possível se proteger com disciplina. A ma noticia: requer criar hábitos que vao contra o instinto natural de quem quer muito a vaga.

  • O que funciona bem: sandbox com Docker ou VM, análise manual de package.json, verificação de dependências com ferramentas como npm audit é socket.dev.
  • Limitacoes: payloads muito sofisticados podem ser ativados dias depois da instalacao, ou apenas em ambientes específicos. Uma VM não é garantia absoluta se o malware detectar que está em ambiente virtualizado é esperar.
  • O problema real: a maioria dos devs não faz essas verificações porque confiam demais no processo seletivo é tem medo de parecer paranoides.

Dicas é boas práticas

💡
Checklist antes de rodar qualquer desafio técnico

Valide o recrutador no site da empresa. Leia 100% do código antes de instalar qualquer dependência. Use Docker ou VM. Nunca rode com conexão de rede se não for necessario.

Algumas práticas que fazem diferença:

  • Valide a empresa independentemente: não clique no link do perfil do recrutador. Va diretamente ao site oficial é procure o contato dele la.
  • Leia antes de rodar: reserve 30 minutos para ler o código antes de qualquer npm install ou pip install.
  • Desconfie de urgencia: "preciso do desafio em 24 horas" é um sinal de alerta clássico.
  • Use um usuario sem privilegios: se precisar rodar na máquina principal, use um usuario do sistema sem acesso a arquivos sensiveis.
  • Monitore trafego de rede: ferramentas como lsof -i (Linux/macOS) ou Wireshark mostram se algo está se conectando a internet durante a instalacao.
# Monitorar conexões de rede durante npm install
# Terminal 1:
watch -n 1 'lsof -i -n | grep node'

# Terminal 2:
npm install

# Qualquer conexão inesperada é sinal de alerta

Vale a pena se preocupar com isso?

Se você é desenvolvedor, sim. Especialmente se trabalha com criptomoedas, sistemas financeiros, infraestrutura crítica ou tem acesso a repositorios de código de empresas grandes. Você é um alvo de valor.

A boa noticia é que a proteção básica não é complicada: leia o código, use Docker ou VM para rodar, valide o recrutador de forma independente. Esses tres hábitos eliminam a grande maioria dos riscos.

O próximo passo é simples: monte uma VM com snapshot limpo hoje. Pode ser com VirtualBox gratuito, Ubuntu minimal é 20GB de disco. Da próxima vez que aparecer um desafio técnico, você roda la com tranquilidade, sem precisar confiar cegamente no código.