SleeperGem: o malware finge dormir na CI e acorda no seu laptop

SleeperGem é o nome da campanha que a Aikido Security identificou em julho de 2026. Três pacotes RubyGems maliciosos entraram no registro público e passaram batido pela CI. Além disso, eles foram feitos para reconhecer um pipeline e se desligar na hora. Ou seja, o alvo nunca foi o build. O alvo era a máquina do desenvolvedor.

Por que sua CI não acusou absolutamente nada

A resposta está no comportamento do código. Primeiro, o loader verifica cerca de trinta variáveis de ambiente antes de rodar qualquer coisa. Essas variáveis são as que plataformas de CI definem por padrão, como GITHUB_ACTIONS, GITLAB_CI e CIRCLECI. Se alguma aparece, o processo encerra na hora e não faz mais nada. Por isso, um install de rotina no pipeline não mostra sinal algum. Runners de CI são efêmeros e monitorados. Além disso, eles têm pouco valor para quem busca acesso duradouro. Já o laptop do dev guarda credenciais de longa duração, tokens de nuvem e chaves SSH. Essa escolha de design revela onde está a exposição de verdade.

As três gems que ninguém revisou a tempo

Os pacotes envolvidos são o git_credential_manager, o Dendreo e o fastlane-plugin-run_tests_firebase_testlab. Na prática, o primeiro imita a ferramenta oficial da Microsoft, o Git Credential Manager. Dois dos três estavam parados havia anos, sendo que um deles não recebia atualização desde 2020. Em seguida, versões novas surgiram com poucos minutos de diferença. Nenhuma delas tinha commit ou tag correspondente no repositório de origem no GitHub. Portanto, a proveniência já não fechava. Esse é o tipo de sinal que toda equipe deveria observar.

SleeperGem: o require vira gatilho de execução

Aqui está a parte que assusta. Na versão 2.8.2 do git_credential_manager em diante, o código malicioso dispara já no require. Basta que o projeto carregue a biblioteca em memória. O require abre um processo Ruby filho que executa um script de instalação. Em seguida, esse script acessa um Forgejo controlado pelo atacante. De lá, ele baixa um shell script e um binário nativo. Curiosamente, o binário usa o mesmo nome da ferramenta que finge ser. A conexão ainda remove a verificação de certificado. Além disso, o User-Agent vira apenas a palavra Git. Assim, o tráfego malicioso se mistura ao movimento normal do dev.

Duas versões que revelam o atacante iterando

As duas versões finais mostram o atacante ajustando tudo às claras. A 2.8.2 baixa o payload, porém deixa a linha de execução comentada. Dessa forma, o ataque fica montado sem disparar. Já a 2.8.3 remove essa trava. Na execução, o script joga o binário em uma pasta oculta dentro da home. Depois, marca o arquivo como executável e sobe um daemon em segundo plano.

Do require ao root em poucos passos

A persistência aparece em dobro. O malware instala dois mecanismos ao mesmo tempo. Primeiro, cria um serviço de usuário via systemd. Depois, adiciona uma entrada no cron. Ambos usam o nome inocente git-credential-manager. Portanto, remover um método deixa o outro de pé. Em seguida, o script checa se o usuário está nos grupos sudo ou wheel. Se o sudo sem senha estiver ativo, ele se reexecuta como root. Nesse ponto, planta uma cópia setuid do shell do sistema. O caminho escolhido lembra o de um utilitário de rede, para parecer legítimo.

No runner da StepSecurity, o sudo sem senha estava desativado. Por isso, esse ramo parou na checagem de grupo. Ainda assim, o caminho existe e funciona na versão publicada. Qualquer máquina com sudo sem senha seguiria direto por ele. Aliás, essa é uma configuração comum em estações individuais.

O que o Harden-Runner gravou linha por linha

A StepSecurity rodou cada versão comprometida no Harden-Runner. A ferramenta reconstruiu a cadeia inteira em ordem. Na prática, a árvore de processos mostrou cada etapa. Primeiro, o require que abre o processo filho de instalação. Em seguida, o download e a execução do deploy.sh. Depois, a cópia do binário para ~/.local/share/gcm/. Por fim, a subida do daemon, a instalação de systemd e cron e a checagem de grupo com sudo. Esse nível de detalhe separa a análise dinâmica de uma revisão estática. Afinal, a análise estática aponta o padrão suspeito. A execução real, porém, só a dinâmica confirma.

Os logs de rede fecharam o caso. O processo Ruby acessou git.disroot.org, o host Forgejo que servia o payload. Além disso, o plugin do fastlane contatou o mesmo host. Ou seja, os três pacotes pertencem a uma só operação. O comportamento de saída do daemon, contudo, fica fora do alcance de um teste em nível de gem. Para confirmar exfiltração de credenciais, seria preciso uma análise binária separada.

Onde sua equipe está de fato exposta

Aqui vem a lição principal. A análise de dependências via hooks de CI pega malware que age igual nos dois ambientes. O SleeperGem age de forma diferente em cada um. Por isso, esse tipo de varredura passa longe dele. E a próxima campanha que copiar a técnica também vai escapar. Enquanto as equipes reforçam o pipeline, a máquina do dev segue pouco instrumentada. No entanto, é lá que moram tokens, chaves e credenciais persistentes. Portanto, o ponto cego mudou de lugar.

Como blindar a máquina do dev ainda hoje

Primeiro, rastreie a proveniência das suas dependências. Uma gem sem commit ou tag correspondente merece suspeita imediata. Depois, revise versões que ressurgem após anos de silêncio. Além disso, fixe versões e valide hashes no seu lockfile. Em seguida, tire o sudo sem senha das estações de trabalho. Dessa forma, você fecha o caminho de escalonamento para root. Também vale monitorar arquivos e processos no endpoint, e não apenas no pipeline. Por fim, observe conexões estranhas de saída durante require e install. Um User-Agent genérico como Git já é motivo para investigar.

A mudança de estratégia que você não pode ignorar

O SleeperGem mostra uma virada clara de estratégia. Na prática, o atacante evita o build e mira quem escreve o código. Logo, blindar apenas a CI já não basta. A defesa começa no laptop de cada desenvolvedor. Reforce o endpoint hoje, antes que a próxima gem finja dormir.

Acompanhe nosso perfil no Instagram!