Malware em hook post-checkout do git mira desenvolvedores

O desenvolvedor Frank Wiles escreveu em 2 de outubro de 2026 que atacantes tentaram tomar as suas contas com um repositório git armado. A armadilha era um hook post-checkout, um script que o git executa toda vez que você troca de branch. É o caso mais recente de uma campanha que atinge quem procura emprego desde pelo menos maio. Para os desenvolvedores, a lição é que simplesmente fazer checkout de um branch no repositório de outra pessoa pode executar o código dela.

O que aconteceu com Frank Wiles

O atacante se passou pelo dono de uma empresa de desenvolvimento, escreveu Wiles no seu blog. Ele pediu que Wiles revisasse um NDA, um acordo de confidencialidade, e compartilhou um repositório pelo Dropbox. Depois, pediu que ele trocasse para um "branch do NDA".

Essa troca de branch foi o gatilho. Um hook post-checkout estava na pasta .git/hooks/ do repositório. Quando Wiles trocou de branch, o hook baixou um programa feito para o sistema operacional dele a partir de um servidor hospedado na Vercel. Ele tornou o arquivo executável, executou-o e depois apagou a si mesmo.

Wiles acredita que o objetivo era "obter acesso à minha conta do Github e/ou a outros acessos ligados a clientes da REVSYS". Ele observa que o hook post-checkout é pouco usado, o que facilita que passe despercebido. O conselho dele a outros desenvolvedores é ficar "extra vigilante e vigiar as suas credenciais como um falcão".

Como os hooks do git viram uma arma

Os hooks do git são pequenos scripts que o git executa automaticamente em momentos definidos, como antes de um commit ou depois de um checkout. São um recurso normal, usado para tarefas como rodar um linter. Um git clone normal a partir de um servidor não copia os hooks, e é por isso que esses atacantes usam outros caminhos.

Os relatos mostram dois caminhos:

• Enviar a pasta inteira. Wiles recebeu o repositório pelo Dropbox. Em um caso que Andrii analisou em um post de blog de maio, o alvo recebeu uma "base de código de demonstração" no Google Drive. Uma pasta compartilhada ou um arquivo compactado pode incluir o diretório oculto .git, com hooks e tudo.
• Pedir que a vítima ative os hooks. O OpenSourceMalware descreve repositórios que guardam hooks em uma pasta .githooks. As vítimas parecem tê-los ativado com git config core.hooksPath .githooks sem lê-los.

De qualquer forma, o hook roda durante o trabalho comum. No caso que Andrii analisou, ele disparou com git checkout dev, o comando para ver o código principal.

O que o malware rouba

As cargas variam, mas miram as mesmas coisas. A análise de Andrii encontrou um programa que procurava chaves SSH como id_ed25519, arquivos .env, carteiras de criptomoedas e certificados. Ele vasculhava as pastas Desktop, Documents e Downloads e enviava arquivos com menos de 10 MB. Ele também enviava o conteúdo da área de transferência a cada segundo, e deixava o atacante executar comandos na máquina.

Um texto de julho no blog Citizen Dot descreve uma armadilha parecida por trás de uma vaga falsa. Um "recrutador" no LinkedIn ofereceu um contrato remoto que pagava "10.000 a 15.000 dólares por mês". O projeto para fazer em casa veio como um zip no Google Drive, com um hook do git que baixava um ladrão de carteiras de criptomoedas.

Quem está por trás

O OpenSourceMalware liga a campanha ao Lazarus Group, o grupo hacker norte-coreano. Ele associa o truque do hook do git à campanha "Contagious Interview" de entrevistas de emprego falsas, que mira principalmente pessoas de cripto e web3. Nos casos que estudou, o malware rodava "na primeira vez que o candidato tenta corrigir o bug e fazer commit". Ele chamou os hooks post-checkout de uma variante "ainda mais perversa", porque disparam com uma simples troca de branch.

O caso que Wiles descreve usou um falso cliente e um NDA, não uma oferta de emprego. O método, um hook oculto que baixa a sua carga de um servidor, é o mesmo.

O que isso significa para desenvolvedores

Nunca abra na sua própria máquina um repositório que você recebeu como pasta ou arquivo compactado. Em vez disso, clone-o do zero a partir de um host git, ou abra-o dentro de uma máquina virtual ou de um contêiner descartável. Um clone novo deixa para trás os hooks de quem enviou.

Antes de rodar qualquer comando git em código compartilhado, olhe dentro de .git/hooks/ em busca de arquivos sem a terminação .sample. Verifique se o .git/config tem uma configuração hooksPath e procure uma pasta .githooks. O conselho do autor do Citizen Dot é inspecionar pastas ocultas como .git e .vscode antes de mexer em código não confiável.

Você também pode desligar os hooks para um único comando. Rodar git -c core.hooksPath=/dev/null checkout <branch> aponta o git para um local vazio, então nenhum hook roda.

Trate qualquer pedido para mudar as suas configurações do git como um sinal de alerta. Um cliente ou empregador de verdade não tem motivo para pedir que você ative os hooks dele. Se você acha que um hook já rodou, presuma que as suas chaves SSH, tokens e segredos do .env estão expostos. Troque-os a partir de uma máquina limpa e verifique a sua conta do GitHub em busca de novas chaves ou sessões.