Mais de 400 pacotes do Arch User Repository foram modificados para distribuir um infostealer com rootkit eBPF. É um dos maiores ataques à cadeia de fornecimento de sempre no ecossistema Arch.
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.
Neste artigo vou explicar-te:
- Como o ataque funcionou
- O que o malware fazia
- Se os repositórios oficiais do Arch foram afetados
- Como verificar o teu sistema
- O que podes fazer para te protegeres
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. Este incidente veio prová-lo.
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:
- Adicionou
npmcomo dependência do pacote mesmo em pacotes que não têm nada a ver com Node.js ou JavaScript - Alterou os emails de contacto do mantenedor para contas Gmail
- Adicionou um ficheiro
.installcom um post-install hook que executava:bash npm install atomic-lockfile - O pacote npm
atomic-lockfile(versão 1.4.2) continha umpreinstallhook que executava um binário ELF Linux chamadodeps
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. Não é trabalho de um script kiddie: é malware profissional.
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 stored credentials.
- Slack, Discord, Microsoft Teams: tokens de sessão, cookies metadados de contas
- GitHub: tokens de acesso pessoal, SSH keys
- 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
dockersshrsync, etc.
Persistência e evasão
O malware instala persistência com systemd service units:
| Modo | Caminho |
|---|---|
| Root | /etc/systemd/system/<nome>.service com Restart=always |
| User | ~/.config/systemd/user/<nome>.service |
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
ptracecontra processos escondidos - Usa pinned maps em
/sys/fs/bpf/hidden_pids,hidden_namesehidden_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.
Como verificar o teu sistema
Se usas Arch Linux (ou EndeavourOS, Garuda, CachyOS, Manjaro), executa:
-
Lista pacotes instalados do AUR:
bash pacman -Qm -
Compara com a lista de comprometidos no gist de Michael Taggart (inclui um script de deteção)
-
Verifica por
atomic-lockfilenos caches npm:bash find / -name "atomic-lockfile" 2>/dev/null -
Inspeciona processos suspeitos:
bash ps aux | grep -i deps systemctl list-units --type=service --all | grep -i deps -
Verifica pinned maps eBPF (requer root):
bash 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:
- Não há limites na adoção de pacotes órfãos. Adotar 400 de uma só vez não disparou alertas.
- Não há revisão obrigatória de PKGBUILDs. Qualquer alteração é aceite sem verificação.
- Os emails dos mantenedores mudaram sem verificação. Usaram contas Gmail.
- 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
paruouyaycom--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.
Conclusão
O “Atomic Arch” é um dos maiores ataques à cadeia de fornecimento no ecossistema Arch Linux. Não é o primeiro (Julho de 2025 teve incidentes com Chromium packages) e não vai ser o último enquanto o AUR funcionar com pouca supervisão.
Dito isto, não entres em pânico. Verifica os pacotes que usas, presta atenção a mudanças de mantenedor e usa --review nos AUR helpers. O AUR continua a ser uma ferramenta útil - desde que não confies cegamente.
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
Comentários (0)
Nenhum comentário ainda. Seja o primeiro!
Deixar comentário