Mais de 400 pacotes do Arch Linux AUR são sequestrados em ataque de supply chain com stealer Rust e rootkit eBPF

Mais de 400 pacotes do Arch User Repository (AUR) foram sequestrados nesta semana em um ataque coordenado de supply chain que reescreveu seus scripts de build para instalar um infostealer escrito em Rust capaz de carregar um rootkit eBPF quando executado com privilégios de root. A campanha, batizada de “Atomic Arch” pela Sonatype, é rastreada sob o identificador Sonatype-2026-003775 com CVSS 8.7 e teve como vetor inicial o pacote npm atomic-lockfile@1.4.2.

O que aconteceu

O ataque não explorou nenhuma vulnerabilidade de software — explorou o modelo de confiança do AUR, o repositório comunitário do Arch Linux. Os criminosos adotaram pacotes órfãos, isto é, projetos cujos mantenedores originais abandonaram, e editaram silenciosamente as instruções de compilação (PKGBUILD e scripts .install) para baixar e executar código malicioso durante o build local nos sistemas das vítimas.

Importante destacar que os repositórios oficiais do Arch Linux não foram afetados — o AUR é mantido pela comunidade e funciona como uma camada paralela de pacotes não auditados. Os atacantes também forjaram metadados de commits git para fazer parecer que as alterações vinham de mantenedores antigos, em uma tentativa de mascarar a autoria das modificações.

A descoberta inicial, divulgada pela Sonatype, listava cerca de 20 pacotes comprometidos. Em menos de 24 horas, rastreadores comunitários e a thread no aur-general catalogaram mais de 400 pacotes afetados — o número segue crescendo conforme novas adoções suspeitas são identificadas.

Como o ataque funciona

Uma vez adotado um pacote órfão, o PKGBUILD era modificado para incluir um comando “npm install atomic-lockfile” durante o processo de build. Esse pacote npm carregava um hook preinstall que executava um binário ELF Linux chamado “deps” — o verdadeiro payload da operação. Bastava o usuário compilar o pacote do AUR para o binário ser executado em sua máquina.

O pesquisador independente Whanos fez engenharia reversa do binário e descreve um infostealer em Rust mirando especificamente estações de trabalho de desenvolvedores e servidores de build. Ele coleta credenciais, chaves SSH, tokens de API e outros segredos, exfiltrando os arquivos via HTTP para temp.sh e mantendo comando e controle através de um serviço onion Tor acessado por proxy loopback local.

“O ataque funcionou porque o AUR ainda confia no nome e no histórico de um pacote, em vez de quem o mantém agora. Um pacote recém-adotado, ou um que de repente ganha novos hooks de instalação, agora merece a mesma suspeita de um pacote vindo de um estranho.” — análise técnica publicada por The Hacker News

Quando o binário tem privilégios de root e a capability adequada, ele opcionalmente carrega um rootkit eBPF que oculta seus próprios processos, nomes de processos e socket inodes das ferramentas padrão. O rootkit usa mapas BPF pinados chamados hidden_pids, hidden_names e hidden_inodes, além de matar tentativas de debugger se conectar. Há também uma segunda payload ainda em análise, supostamente um cryptominer associado ao monero-wallet-gui.

Quem é afetado e quais são os riscos

Os principais atingidos são desenvolvedores e administradores de sistemas que usam Arch Linux e instalaram ou atualizaram pacotes do AUR a partir de 11 de junho de 2026. Entre os pacotes confirmados como comprometidos estão “alvr” e “premake-git”, além de outras dezenas listadas no mailing list do Arch.

• Estações de desenvolvimento com chaves SSH, tokens de API e segredos de produção armazenados localmente
• Servidores de CI/CD que executam build automatizado de pacotes AUR (raro, mas crítico)
• Máquinas pessoais de usuários Arch com privilégios de root concedidos ao processo de build
• Qualquer sistema onde o rootkit eBPF tenha sido carregado — a remoção do pacote AUR não garante limpeza completa

O hash SHA-256 do payload principal é 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b. Uma segunda onda do ataque, identificada por trackers comunitários, usa o pacote npm “js-digest” em vez de atomic-lockfile, com um ELF diferente mas vinculado ao mesmo publicador npm — ou seja, vale verificar os dois indicadores.

Análise

Este incidente reforça uma tendência preocupante no cenário de ataques a cadeia de suprimentos: o foco em pacotes abandonados como vetor primário de comprometimento. Em vez de criar typosquats (pacotes com nomes semelhantes a populares), os atacantes hoje preferem “herdar” pacotes legítimos com histórico, downloads e confiança já estabelecidos. Em 2018, vimos uma versão menor desse playbook quando um pacote PDF-viewer abandonado foi comprometido. Em 2026, a operação Atomic Arch escalou o mesmo modus operandi para centenas de projetos.

O que torna esse caso particularmente alarmante é a combinação inédita de um stealer “smash-and-grab” — feito para coletar segredos rapidamente — com um rootkit eBPF persistente. Normalmente esses dois perfis de ataque são separados: stealers buscam impacto imediato, rootkits buscam permanência. Vê-los acoplados sugere que os atacantes estão diversificando o modelo de negócio do ataque: vendem credenciais agora e mantêm acesso para monetização posterior, possivelmente com mineração de Monero. Para a comunidade Arch, o evento expõe um problema estrutural — o modelo de adoção de pacotes órfãos é vulnerável a sequestro por design, e o AUR precisará repensar como sinaliza mudanças de propriedade.

Recomendações práticas

• Audite todos os pacotes AUR instalados ou atualizados a partir de 11 de junho de 2026 contra as listas de afetados publicadas no mailing list aur-general
• Bloqueie domínios temp.sh e o tráfego para serviços onion Tor em ambientes corporativos onde isso não é parte do fluxo legítimo
• Considere uma instalação de Arch comprometida como totalmente comprometida — desinstalar o pacote não basta após a execução de um rootkit eBPF
• Implemente verificação de integridade de PKGBUILD: scripts que de repente incluem chamadas a “npm install” ou “bun install” em pacotes nativos são bandeira vermelha
• Em ambientes de desenvolvimento corporativo, mova o build de pacotes AUR para contêineres descartáveis ou VMs efêmeras
• Monitore os IOCs publicados pela ioctl.fail, incluindo o SHA-256 do payload (6144d4…) e os endereços onion do C2
• Para detecção forense, procure por mapas BPF pinados com nomes hidden_pids, hidden_names ou hidden_inodes em /sys/fs/bpf/

Fonte: The Hacker News