Arch Linux: 400 pacotes AUR espalham rootkit

Mais de 400 pacotes Arch Linux comprometidos no Arch User Repository (AUR) foram usados para distribuir um rootkit Linux e um malware infostealer voltado ao roubo de credenciais, tokens de acesso e segredos de desenvolvedores. A campanha foi revelada em 12 de junho de 2026 por pesquisadores citados pelo BleepingComputer, com base em análises da comunidade Independent Federated Intelligence Network (IFIN), do pesquisador Whanos e da empresa Sonatype. O ataque explora a confiança em pacotes comunitários do AUR, modifica scripts de instalação e baixa um pacote npm malicioso chamado atomic-lockfile.

Usuários que instalaram pacotes afetados devem verificar indicadores de comprometimento, trocar credenciais e considerar reinstalação limpa se houver sinais de rootkit.

O que aconteceu com os pacotes Arch Linux no AUR

O AUR é um repositório mantido pela comunidade do Arch Linux. Diferentemente dos repositórios oficiais, ele reúne receitas de compilação, chamadas PKGBUILDs, que instruem o sistema a baixar, compilar e instalar programas. Essa flexibilidade torna o AUR essencial para muitos usuários avançados, mas também amplia o risco de ataque à cadeia de suprimentos quando um pacote muda de mantenedor ou recebe um commit malicioso.

Segundo o IFIN, um novo mantenedor teria se passado por um publicador confiável para enviar versões infectadas. Já a Sonatype relatou que o invasor sequestrou ao menos 20 pacotes órfãos e alterou o arquivo PKGBUILD para chamar o npm durante a instalação. Em ambos os cenários, o objetivo era instalar o atomic-lockfile, pacote que carregava um executável Linux suspeito.

Como o atomic-lockfile instalava rootkit e infostealer

A análise técnica indicou que uma amostra do atomic-lockfile incluía um payload ELF chamado deps. De acordo com Whanos, o binário combinava funções de ladrão de credenciais com capacidades opcionais de rootkit baseado em eBPF, recurso do kernel Linux conhecido como extended Berkeley Packet Filter. Em condições específicas e com privilégios elevados, esse tipo de componente pode operar em nível de kernel e ocultar processos locais.

“Ele foi projetado para estações de trabalho de desenvolvedores e ambientes de build. Mira dados de navegadores, apps Electron, Slack, Microsoft Teams, Discord, GitHub, npm, Vault, Docker/Podman, SSH, VPN, históricos de shell e outros segredos locais.”

Whanos, pesquisador independente de segurança

Na prática, os pacotes Arch Linux comprometidos podiam transformar uma instalação aparentemente comum em vetor de exfiltração. O malware tinha referências a arquivamento de dados, manipulação de arquivos multipartes e uploads HTTP, recursos compatíveis com a coleta e envio de informações sensíveis para infraestrutura controlada por atacantes.

Quais dados estavam na mira do malware

O foco da campanha era especialmente perigoso para desenvolvedores, administradores de sistemas e equipes que usam Arch Linux em estações de trabalho ou ambientes de compilação. Em vez de buscar apenas senhas comuns, o infostealer Linux procurava credenciais que dão acesso a repositórios, pipelines, infraestrutura e serviços internos.

• Credenciais do GitHub e tokens de autenticação.
• Artefatos SSH, chaves privadas e configurações locais.
• Tokens do HashiCorp Vault e segredos de infraestrutura.
• Bancos de cookies de navegadores e sessões salvas.
• Dados de Slack, Discord, Microsoft Teams e Telegram.
• Materiais de VPN, Docker, Podman, npm e históricos de shell.

Por que o AUR é um alvo atraente

O AUR oferece acesso rápido a aplicações proprietárias, versões beta, builds nightly, drivers, utilitários de nicho e versões antigas de pacotes. Essa conveniência é parte da força do ecossistema Arch, mas exige revisão cuidadosa. Como o AUR não passa pelo mesmo processo de validação dos repositórios oficiais, um PKGBUILD malicioso pode executar comandos durante a instalação sem que o usuário perceba.

Ataques desse tipo são chamados de ataques à cadeia de suprimentos porque comprometem um componente usado antes do software final chegar ao usuário. No caso dos pacotes Arch Linux comprometidos, a instalação de uma dependência npm adulterada serviu como ponte entre o ecossistema AUR e o ecossistema JavaScript, ampliando a superfície de ataque.

O que os mantenedores e usuários devem fazer

Mantenedores do AUR trabalham para identificar commits maliciosos, remover pacotes afetados e banir contas usadas na campanha. Jonathan Grotelüschen, mantenedor de pacotes do Arch Linux, pediu que a comunidade reporte qualquer pacote suspeito encontrado. A recomendação geral é priorizar projetos com atualizações frequentes, histórico transparente e comunidade ativa.

Para usuários, a resposta deve ser proporcional ao risco. Quem instalou pacotes listados como afetados deve revisar os indicadores de comprometimento publicados por Whanos e usar scripts de verificação mencionados por Michael Taggart, do IFIN, para procurar sinais do atomic-lockfile. Se houver suspeita real de infecção, apenas remover o pacote pode não ser suficiente.

1. Confira a lista de pacotes afetados e commits recentes no AUR.
2. Procure atomic-lockfile, binários suspeitos e chamadas npm inesperadas.
3. Revogue e gere novamente tokens do GitHub, npm, Vault e VPN.
4. Troque senhas e substitua chaves SSH usadas no sistema.
5. Considere reinstalar o Arch Linux do zero se houver indício de rootkit.

Como reduzir riscos ao usar pacotes AUR

O caso reforça uma regra importante: pacotes do AUR devem ser tratados como código de terceiros. Antes de instalar, é prudente ler o PKGBUILD, verificar scripts de pré-instalação e pós-instalação, conferir mudanças de mantenedor e desconfiar de dependências novas que chamam gerenciadores externos, como npm, pip ou curl, sem justificativa clara.

Também é recomendável separar ambientes. Estações de desenvolvimento com chaves de produção, tokens permanentes e acesso a pipelines críticos não devem instalar pacotes comunitários sem revisão. Contas com autenticação forte, tokens de curta duração, cofres de segredo bem configurados e monitoramento de exfiltração reduzem o impacto quando um pacote malicioso consegue chegar ao sistema.

Considerações finais

A campanha contra o AUR mostra como ataques à cadeia de suprimentos podem atingir usuários técnicos justamente pela confiança em repositórios comunitários. O Arch Linux continua sendo uma distribuição poderosa, mas o incidente com atomic-lockfile evidencia a necessidade de revisar scripts, limitar privilégios e manter rotação de credenciais. Para quem usa pacotes Arch Linux comprometidos ou suspeitos, a prioridade é verificar o sistema, revogar segredos e tratar qualquer sinal de rootkit como incidente crítico.