O que é um backdoor em oferta de emprego?
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 exercício, 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 comentários: 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 obrigatória para qualquer dev.
Como funciona o ataque
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 rápido 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
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 são:
- npm postinstall: scripts que rodam automaticamente ao executar
npm install. Basta uma linha nopackage.jsonpara 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 idêntico ao original.
- Makefile com comandos ocultos: o
make setupoumake runcontem comandos de download é execução de binários remotos. - Arquivos .env com instruções maliciosas: pedem que você execute um comando específico "para configurar o ambiente".
- Binários pre-compilados: o projeto inclui um executável que você é instruído 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 e executa código remoto
Como identificar uma oferta suspeita
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.
Entrevista antes do desafio, código aberto para revisao, empresa com histórico verificável, sem pressão 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 domínio 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.txtouCargo.toml. Pesquise cada uma no registro oficial. - Scripts automáticos: procure por scripts
postinstall,prepare,preinstallnopackage.json. - Binários: o projeto inclui arquivos
.exe,.sh,.dylibou.sóque não são do sistema operacional?
O site socket.dev analisa pacotes npm e detecta comportamentos suspeitos como acesso a rede no postinstall, leitura de variáveis de ambiente é ofuscacao de código. Vale checar antes de instalar qualquer dependência nova.
Passo a passo para analisar o código com segurança
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 binários
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
A forma mais segura de rodar código desconhecido é em um ambiente isolado:
# Com Docker (mais rápido)
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
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 segurança é máxima.
Casos de uso reais: quem está sendo atacado
Esse tipo de ataque não é aleatório, 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 prejuízos de milhões 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 júnior: menos familiarizados com ataques de supply chain é mais ansiosos com oportunidades de emprego, são alvos frequentes.
- Contribuidores de projetos open source: atacantes fingem ser mantenedores pedindo para testar uma mudança em um projeto popular.
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 usuário.
- 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 urgência é 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 e Limitações 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 comonpm audité socket.dev. - Limitacoes: payloads muito sofisticados podem ser ativados dias depois da instalação, 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 e Boas Práticas
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 necessário.
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 installoupip install. - Desconfie de urgência: "preciso do desafio em 24 horas" é um sinal de alerta clássico.
- Use um usuário sem privilegios: se precisar rodar na máquina principal, use um usuário do sistema sem acesso a arquivos sensíveis.
- Monitore tráfego de rede: ferramentas como
lsof -i(Linux/macOS) ou Wireshark mostram se algo está se conectando a internet durante a instalação.
# 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 repositórios 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.
Comentários
Deixar um comentárioVocê precisa ter uma conta no CuritibaBlog para comentar.