Backdoor disfarçada em oferta de emprego no LinkedIn: repositório falso no GitHub usou nome real de desenvolvedor

O ataque descrito por Roman não é uma anomalia, é o novo padrão de cadeia de suprimentos maliciosa em 2026. Diferente de campanhas anteriores que dependiam de pacotes publicados em registries (npm, PyPI), essa operação usa um repositório público *no GitHub* como vetor principal, com identidade roubada e execução automática via npm prepare, um hook subutilizado e pouco auditado. Isso evita detecção por scanners tradicionais de packages, já que o código nunca entra no registry: ele é executado diretamente ao clonar e instalar dependências.

O domínio rest-icon-handler.store já foi associado a outras campanhas da mesma família, segundo relatórios do Socket Labs e da Trellix em maio de 2026. E o uso de um jornalista real como 'recrutador' não é acaso: ataques recentes como o Megalodon (maio/2026) e o Fake Font usam perfis legítimos com deepfakes ou dados públicos para aumentar credibilidade, o LinkedIn virou uma plataforma de distribuição de malware com taxa de sucesso crescente: 52% dos ataques de phishing globais em 2022 usavam sua marca, e em 2026 esse vetor se refinou com alvos técnicos precisos.

Em maio, a CEVIU reportou duas campanhas distintas com a mesma lógica: a Contagious Interview (0G Labs/Web3) e a TrapDoor (34 pacotes em npm/PyPI/Crates.io). Agora, em junho, o modus operandi evoluiu: trocou-se o pacote malicioso por um repositório GitHub atribuído a um desenvolvedor real sem seu conhecimento. Não há mais necessidade de publicar no registry, basta enganar o recrutador (ou o dev) para clonar e rodar npm install. O script prepare é o gatilho, e ele funciona mesmo em repositórios públicos, sem aviso visual. Também é a primeira vez que vemos um caso documentado com impersonificação direta de commits (39 commits falsos) + domínio C2 operando desde abril/2026, segundo análise de IOC do GitHub Abuse Team.

Isso muda a superfície de ataque: agora não basta escanear pacotes instalados, é preciso validar toda origem de código externo, mesmo em repositórios públicos e com autoria aparentemente confiável. O GitHub não verifica a autoria real dos commits, só a assinatura GPG ou o email configurado. Um perfil falso pode ter 100% de commits válidos tecnicamente, mas zero relação com o autor. Para empresas, isso exige revisão imediata de políticas de onboarding: nenhuma dependência externa deve ser integrada sem sandboxing prévio, verificação de integridade de commits (com git verify-commit) e análise estática automatizada antes de qualquer npm install ou git clone.