Desenvolvedor quase é hackeado em falsa entrevista, mas agente de IA identifica repositório malicioso

O desenvolvedor Python Roman Imankulov quase caiu em uma armadilha disfarçada de oportunidade de trabalho. O ataque, conduzido por uma pessoa que se apresentou como recrutadora de uma pequena startup de criptomoedas, usava um repositório aparentemente problemático como pretexto para induzir a execução de código malicioso durante uma avaliação técnica.

O contato ocorreu pelo LinkedIn. A suposta recrutadora afirmou que a empresa precisava de um lead engineer e pediu ajuda para analisar um código de prova de conceito que não funcionava. Segundo ela, o problema estaria relacionado a um módulo Node depreciado. A abordagem parecia plausível, mas algo no pedido chamou a atenção de Imankulov.

Em entrevista por telefone, o desenvolvedor afirmou que já havia ouvido falar desse tipo de ataque e, por experiência anterior, levantou a hipótese de que ele próprio poderia ser o alvo. Em vez de clonar e executar o projeto diretamente em sua máquina, ele adotou uma postura mais cautelosa: criou uma VPS na Hetzner, clonou o repositório nesse ambiente isolado e usou seu agente de codificação Pi, executando Codex, para realizar uma análise somente leitura do código.

A expectativa inicial era que a ferramenta apenas apontasse baixa qualidade no código e autorizasse uma revisão convencional. O resultado foi diferente. Segundo Imankulov, o agente respondeu quase imediatamente com um alerta para não executar o projeto, indicando que havia uma armadilha no repositório.

A análise com IA apontou o arquivo app/test/index.js como suspeito. O conteúdo escondia uma backdoor por meio de uma URL de servidor fragmentada para parecer parte de uma configuração de suíte de testes. O script incluía uma requisição de rede capaz de executar qualquer código enviado pelo servidor em resposta.

Imankulov afirmou que havia aberto o arquivo manualmente e, ao passar os olhos pelo conteúdo, interpretou o código como apenas mal escrito. Para ele, parecia um arquivo típico de um desenvolvedor descuidado, não uma ameaça evidente. O agente de IA, no entanto, identificou no mesmo arquivo a vulnerabilidade que ele havia deixado passar.

O ataque não exigia que a vítima executasse manualmente um binário suspeito. Bastaria instalar o projeto usando npm. O arquivo package.json do repositório continha um hook “prepare”, executado após a instalação, projetado para rodar o script malicioso durante o processo de instalação das dependências.

Esse detalhe torna o ataque especialmente perigoso para desenvolvedores. O comando npm install faz parte da rotina de trabalho em projetos JavaScript e Node.js, e muitos profissionais o executam automaticamente ao avaliar um repositório. Ao esconder a execução dentro de um hook de ciclo de vida do npm, os invasores transformam um fluxo legítimo de desenvolvimento em vetor de comprometimento.

A arquiteta independente de open source e segurança Devashri Datta explicou ao The Register que a abordagem é insidiosa justamente por sequestrar workflows comuns de desenvolvimento. O adversário não depende de um arquivo executável claramente suspeito. Ele se apoia em um comando rotineiro e confiável, executado durante a resolução de dependências.

Segundo Datta, a fragmentação da string usada para montar a URL maliciosa também foi deliberada. Em vez de deixar um domínio suspeito escrito de forma direta no código, os operadores dividiram a informação em pequenas constantes, dificultando a detecção por ferramentas de análise estática que procuram indicadores de comprometimento hardcoded.

O repositório malicioso original não está mais acessível, provavelmente removido pelo GitHub após a denúncia de Imankulov, embora uma cópia ainda tenha sido encontrada. A investigação também mostrou outro elemento comum em ataques de engenharia social contra desenvolvedores: a aparência de legitimidade.

Os commits no repositório pareciam ter sido feitos por um desenvolvedor com presença pública estabelecida e histórico real de trabalho. Quando Imankulov entrou em contato com o suposto autor, ele afirmou que já havia sido impersonado no GitHub mais de uma vez e que não havia escrito aquele código.

A identidade da recrutadora também levantou sinais de falsificação. O perfil no LinkedIn fazia referência a uma jornalista de artes real, mas Imankulov acredita que a conta associada era falsa. As interações com a suposta recrutadora indicavam um nível de conhecimento técnico que não aparecia no histórico profissional exibido no perfil.

O caso ocorre em um cenário no qual contas falsas em plataformas profissionais continuam sendo usadas para golpes. Embora o LinkedIn afirme remover dezenas de milhões de contas falsas antes que elas interajam com usuários, centenas de milhares ainda conseguem ser criadas e entrar em contato com pessoas antes de serem detectadas. Entre janeiro e junho de 2025, a plataforma restringiu 386 mil contas após denúncias de usuários, acima das 266 mil no semestre anterior e das 86 mil registradas no primeiro semestre de 2021.

Ataques de engenharia social contra a cadeia de suprimentos de software se tornaram cada vez mais comuns. Campanhas recentes associadas à Coreia do Norte, por exemplo, têm usado entrevistas falsas e ofertas de emprego para comprometer contas de desenvolvedores, roubar credenciais e obter acesso a ambientes internos.

Outros desenvolvedores também relataram quase ter caído em golpes semelhantes, em alguns casos igualmente salvos por agentes de IA usados para revisar o código antes da execução. Para Datta, a resposta de Imankulov aponta uma mudança importante na higiene de revisão de código entre profissionais mais atentos à segurança.

Historicamente, a recomendação era revisar manualmente código não confiável ou executá-lo em sandbox. Neste caso, o desenvolvedor usou um agente local de IA em um ambiente restrito e somente leitura para analisar a base de código antes de executar qualquer comando. A IA, nesse contexto, atuou como uma camada defensiva no endpoint do desenvolvedor, capaz de identificar rapidamente comportamentos anômalos, como uma suíte de testes fazendo conexão externa para buscar código não verificado.

O incidente também mostra por que a segurança da cadeia de suprimentos de software precisa considerar o ambiente local dos engenheiros. Uma estação de trabalho de desenvolvedor pode conter chaves SSH ativas, tokens de provedores cloud, sessões autenticadas e acesso a repositórios internos. Se esse dispositivo for comprometido durante uma falsa entrevista técnica, o impacto pode ir além do usuário individual e atingir a organização.

Uma mudança relevante pode reduzir esse vetor no ecossistema npm. O GitHub, mantenedor do npm, prepara o lançamento do npm 12, que altera o comportamento do comando npm install. A configuração allowScripts passará a vir desativada por padrão, impedindo que scripts preinstall, install ou postinstall de dependências sejam executados automaticamente, a menos que sejam explicitamente autorizados no projeto.

Segundo Leo Balter, gerente de produto do GitHub, scripts de ciclo de vida executados durante a instalação representam a maior superfície de execução de código no ecossistema npm. Como cada npm install pode rodar scripts de dependências transitivas, um único pacote comprometido em qualquer ponto da árvore de dependências pode executar código arbitrário em uma máquina de desenvolvimento ou runner de CI.

Para Imankulov, a mudança é bem-vinda, mas ele já adotou uma medida prática por segurança pessoal: passou a usar pnpm para garantir que scripts desse tipo não sejam executados por padrão. A decisão reflete uma postura crescente entre desenvolvedores que lidam com código de terceiros ou projetos recebidos em contextos de baixa confiança.

Datta defende que empresas devem ir além de orientações genéricas e aplicar barreiras técnicas. Entre as medidas estão o uso de contêineres isolados para desenvolvimento, workstations seguras em nuvem e ambientes descartáveis para avaliar código externo ou não confiável. Essas práticas reduzem o risco de que uma avaliação técnica, uma prova de conceito ou um processo seletivo se transforme em ponto de entrada para credenciais corporativas.

O caso reforça uma mudança no alvo dos ataques à cadeia de suprimentos. Em vez de esperar que um pacote malicioso chegue a um repositório corporativo, invasores estão tentando comprometer desenvolvedores antes mesmo que uma linha de código entre no pipeline da empresa. A ameaça começa no endpoint individual, no momento em que o profissional clona um repositório, instala dependências e confia em fluxos automatizados do próprio ecossistema de desenvolvimento.