AUR do Arch Linux: 400+ Pacotes Comprometidos com Malware que Rouba Credenciais e Instala Rootkit

Estava a fazer scroll pelo Lobste.rs num dia normal de junho quando vi o título: “400+ AUR packages compromised”. O café quase foi para o lado. Uso Arch há anos, tenho dezenas de pacotes do AUR instalados, e o meu primeiro pensamento foi “já fui?”.

No dia 11 de junho de 2026 a comunidade Arch Linux recebeu más notícias. A Independent Federated Intelligence Network (IFIN) reportou que mais de 400 pacotes do AUR foram comprometidos numa campanha coordenada. Os investigadores da Sonatype apelidaram-na de “Atomic Arch”. É o maior incidente de segurança na história do AUR.

O alvo? Credenciais de programadores: tokens do GitHub, chaves SSH, sessões Slack e Discord, tokens OpenAI, wallets de criptomoedas. O vetor? Pacotes órfãos do AUR que qualquer um pode adotar.

O que é o AUR (e porque interessa)

O Arch User Repository é um repositório comunitário. Qualquer utilizador pode submeter PKGBUILDs: scripts que dizem como descarregar, compilar e instalar software que não está nos repositórios oficiais do Arch.

Para muitos, o AUR é essencial. É onde encontras versões beta, aplicações proprietárias, ferramentas niche e versões antigas de pacotes que já não estão nos oficiais.

A diferença crítica? Os repositórios oficiais ([core], [extra], [multilib]) são mantidos por programadores de confiança com processos de review. O AUR não. É um sistema de confiança comunitária: não há curadoria. Qualquer pessoa cria uma conta, adota pacotes órfãos e submete alterações.

Esta abertura é a maior força e a maior fraqueza do AUR. Sempre foi uma faca de dois gumes para mim: adoro ter acesso a tudo, mas nunca soube bem em quem confiar. Este incidente veio provar que a desconfiança era justificada.

O ataque: como 400+ pacotes foram comprometidos

O modus operandi foi simples.

Os atacantes identificaram pacotes órfãos cujos mantenedores originais os abandonaram. No AUR qualquer pessoa pode adotá-los. Não há limite de quantos podes adotar nem período de carência.

O atacante adotou dezenas (possivelmente centenas) de pacotes órfãos de uma só vez. A comunidade notou que isto devia ter disparado alertas nos moderadores, mas não disparou.

Depois de adotar os pacotes, o atacante modificou os PKGBUILDs:

1. Adicionou npm como dependência do pacote mesmo em pacotes que não têm nada a ver com Node.js ou JavaScript
2. Alterou os emails de contacto do mantenedor para contas Gmail
3. Adicionou um ficheiro .install com um post-install hook que executava:

   npm install atomic-lockfile

4. O pacote npm atomic-lockfile (versão 1.4.2) continha um preinstall hook que executava um binário ELF Linux chamado deps

O post-install hook corre com privilégios de root através do pacman. E a instrução maliciosa está num ficheiro .install, não no PKGBUILD principal. Se inspecionasses o PKGBUILD rápido, não detetavas nada.

O malware: deps (infostealer com rootkit eBPF)

O investigador de segurança Whanos (do blog ioctl.fail) fez uma análise forense ao binário deps. O resultado não é bonito.

O deps é um ELF para Linux x86-64 com 3MB, escrito em Rust com máquinas de estado assíncronas. É malware profissional, longe do trabalho de um script kiddie.

O que rouba

O deps foi desenhado para ambientes de desenvolvimento e estações de trabalho de programadores. O alvo são credenciais e tokens de:

• Browsers: Chrome, Firefox, Edge, Brave, Vivaldi, Opera, Yandex e dezenas de outros (incluindo Flatpak). Rouba cookies, sessões e credenciais guardadas.
• Slack, Discord, Microsoft Teams: tokens de sessão, cookies, metadados de contas
• GitHub: tokens de acesso pessoal, chaves SSH
• npm: tokens de publicação
• HashiCorp Vault: tokens armazenados localmente
• Docker/Podman: credenciais de registries
• OpenAI/ChatGPT: tokens bearer
• Wallets de criptomoedas: ficheiros locais e seed phrases
• SSH: chaves privadas, configurações, known_hosts
• VPN: ficheiros .ovpn
• Shell histories: bash, zsh, fish, incluindo comandos com docker ssh rsync, etc.

Persistência e evasão

O malware instala persistência com systemd service units:

Com privilégios de root carrega um rootkit eBPF que:

• Esconde PIDs específicos de /proc
• Esconde nomes de ficheiros de diretorias
• Esconde socket inodes de /proc/net/tcp
• Mata tentativas de ptrace contra processos escondidos
• Usa pinned maps em /sys/fs/bpf/hidden_pids, hidden_names e hidden_inodes

Se o rootkit estiver ativo, ps, htop e netstat não mostram o processo nem os sockets do malware.

C2 e exfiltração

O C2 comunica através de um serviço onion (Tor):

olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion

Usa POST /api/agent para comando e controlo com transporte local via loopback/SOCKS.

Os ficheiros roubados são enviados para temp.sh via POST /upload. Os metadados (IDs de upload) são retransmitidos pelo canal onion.

O binário também tem referências a um stager que descarrega um ficheiro de /bin/linux do mesmo C2. Provavelmente um minerador de Monero (/usr/bin/monero-wallet-gui é referenciado no código).

Impacto: quem foi afetado?

O ataque afetou exclusivamente o AUR. Os repositórios oficiais do Arch ([core], [extra], [multilib]) não foram comprometidos.

Os pacotes afetados incluem desde temas de Window Maker a ferramentas COSMIC, bibliotecas Perl e Python, e aplicações comerciais como o apple-music-desktop. A lista completa está no thread oficial da mailing list AUR.

O número real de sistemas infetados é difícil de estimar, mas dada a popularidade do AUR e a variedade de pacotes comprometidos, pode ser significativo. Sobretudo entre programadores que confiam no AUR para ferramentas de desenvolvimento.

A resposta da comunidade

A reação foi rápida:

• O mantenedor do Arch Jonathan Grotelüschen publicou na mailing list AUR a confirmar que estavam a reverter/apagar os commits maliciosos e banir as contas
• Os moderadores estão a identificar e reverter alterações
• A IFIN, a Sonatype e o Whanos publicaram análises detalhadas
• Um script de verificação foi partilhado para detetar o atomic-lockfile

O ataque ainda estava em curso na tarde de 12 de junho. Foram reportados pacotes maliciosos a usar também o bun (outro runtime JavaScript) como vetor. O mais perturbador foi perceber que a campanha continuava ativa enquanto a comunidade tentava contê-la — sinal de que os atacantes não tinham medo de ser apanhados.

Como verificar o teu sistema

Se usas Arch Linux (ou EndeavourOS, Garuda, CachyOS, Manjaro), executa:

1. Lista pacotes instalados do AUR:

   pacman -Qm

2. Compara com a lista de comprometidos no gist de Michael Taggart (inclui um script de deteção)

3. Verifica se atomic-lockfile existe nos caches npm:

   find / -name "atomic-lockfile" 2>/dev/null

4. Inspeciona processos suspeitos:

   ps aux | grep -i deps
   systemctl list-units --type=service --all | grep -i deps

5. Verifica pinned maps eBPF (requer root):

   ls /sys/fs/bpf/ | grep -E "hidden|deps"

Se algum dos teus pacotes estiver na lista comprometida:

• Assume que as tuas credenciais estão queimadas
• Roda todas as passwords, tokens e chaves SSH
• Considera reinstalar o sistema de raiz (um rootkit eBPF sobrevive a limpezas normais)
• Verifica acessos não autorizados nos teus serviços (GitHub, Slack, Discord…)

Lições

Este incidente expõe fragilidades no modelo do AUR:

1. Não há limites na adoção de pacotes órfãos. Adotar 400 de uma só vez não disparou alertas.
2. Não há revisão obrigatória de PKGBUILDs. Qualquer alteração é aceite sem verificação.
3. Os emails dos mantenedores mudaram sem verificação. Usaram contas Gmail.
4. Post-install hooks correm como root sem sandboxing.

Sugestões para a comunidade Arch:

• Limitar adoção de pacotes: máximo por período de tempo
• Exigir verificação de email antes de adotar
• Notificar a comunidade quando um pacote órfão é adotado (com período de carência)
• Promover AUR helpers que mostrem diffs dos PKGBUILDs antes de instalar (como paru ou yay com --review)

Para ti, utilizador: o AUR é conteúdo gerado pela comunidade, não oficial. Cada PKGBUILD devia ser inspecionado antes de executar, sobretudo quando o pacote muda de mantenedor.

O que devia mudar

Se há coisa que este ataque devia mudar é a perceção de que o AUR é “só mais um repositório”. Não é. É conteúdo gerado pela comunidade sem curadoria, e cada pacote é um risco potencial.

A questão é como manter a abertura que torna o AUR útil sem criar portas escancaradas para ataques destes. Limitar adoção de pacotes órfãos, exigir verificação de email em mudanças de mantenedor, e promover helpers que mostrem diffs antes de instalar parecem-me passos óbvios. O que não percebo é porque ainda não existem.

O “Atomic Arch” não vai ser o último. A pergunta é o que a comunidade Arch vai fazer antes do próximo.

Fontes

• Arch Linux Mailing List - Comunicado oficial de Jonathan Grotelüschen
• BleepingComputer - Over 400 Arch Linux packages compromised
• Whanos/ioctl.fail - Preliminary analysis of AUR malware
• Sonatype - Atomic Arch npm campaign
• IFIN - 400 AUR packages compromised
• Script de deteção (gist)
• GamingOnLinux - Cobertura do incidente