O repositório de pacotes da comunidade Arch Linux, o AUR (Arch User Repository), foi alvo de um dos maiores ataques de cadeia de suprimentos (supply chain attack) já registrados contra uma distribuição Linux. Batizada de “Atomic Arch” pelos pesquisadores da Sonatype, a campanha comprometeu mais de 1.579 pacotes entre os dias 11 e 12 de junho de 2026, injetando um infostealer baseado em Rust combinado com um rootkit eBPF capaz de roubar credenciais, exfiltrar dados e se ocultar do sistema operacional. Neste artigo do Blog Dolutech, detalhamos como o ataque funcionou, quais foram as cargas maliciosas envolvidas, como verificar se o seu sistema foi comprometido e quais medidas adotar imediatamente.
O que é o AUR e por que ele é um alvo atraente
O Arch User Repository é um repositório mantido pela comunidade que complementa os repositórios oficiais do Arch Linux, como [core], [extra] e [multilib]. Qualquer utilizador pode submeter e manter pacotes, que são distribuídos na forma de arquivos PKGBUILD, scripts de construção que descrevem como compilar e instalar um determinado software a partir do código-fonte.
Por design, o AUR opera com supervisão centralizada mínima. Enquanto os repositórios oficiais passam por revisão rigorosa por parte dos Trusted Users do Arch, o AUR depende da vigilância da comunidade. Essa abertura é justamente o que o torna poderoso para disponibilizar software rapidamente, mas também o que cria superfície de ataque considerável.
Um ponto crítico do modelo de governança do AUR é o conceito de pacotes órfãos: quando um mantenedor abandona um pacote, ele fica disponível para adoção por qualquer membro da comunidade. O processo de adoção é simples e conta com pouca verificação de intenção, o que, como demonstrou a campanha Atomic Arch, pode ser explorado em larga escala.
A Campanha Atomic Arch: Linha do Tempo
Primeira Onda (11 de junho de 2026)
Pesquisadores da Sonatype identificaram a campanha no dia 11 de junho de 2026. Os atacantes adotaram pacotes órfãos legítimos do AUR e modificaram os seus PKGBUILD para incluir um script de pós-instalação que executava o seguinte comando:
npm install atomic-lockfile minimist chalkEsse comando baixava silenciosamente o pacote npm malicioso atomic-lockfile (versão 1.4.2), junto com dois pacotes legítimos utilizados como cobertura. O atomic-lockfile continha um gancho de pré-instalação (preinstall) que executava um binário ELF nativo para Linux chamado deps (SHA256: 6144D4...), escrito em Rust.
Segunda Onda (12 de junho de 2026)
No dia seguinte, surgiu uma segunda vaga que utilizava o runtime Bun em vez do npm para parte dos pacotes afetados. Novos pacotes maliciosos foram identificados: js-digest (SHA256 do payload: 7883BD...) e lockfile-js, todos publicados pelo mesmo publisher no npm (herbsobering). Contas de atacantes adicionais, como custodiatovar e veramagalhaes, foram identificadas na adoção de pacotes órfãos para essa segunda onda.
Um detalhe técnico relevante: pelo menos em um caso, a conta arojas, que pertencia a um mantenedor legítimo de longa data, foi falsificada via forjamento de metadados de commit git, sem que a conta original tivesse sido comprometida. Isso foi esclarecido publicamente por David Runge da equipe Arch Linux em 12 de junho. A capacidade de imitar commits de mantenedores confiáveis aumentou significativamente a dificuldade de detecção.
Escalonamento do Número de Pacotes
| Momento | Pacotes comprometidos |
|---|---|
| Início (11/06) | ~400 |
| Horas depois | ~900 |
| Fim do dia (12/06) | 1.579 (lista parcial) |
A própria atualização final da equipe Arch Linux reconheceu que a lista de 1.579 pacotes era “muitos (mas não todos) dos pacotes afetados”, deixando claro que o número real pode ser ainda maior.
Análise Técnica do Payload Malicioso
A Dolutech considera este o ponto mais crítico do incidente: o payload não estava dentro dos pacotes AUR, mas sim dentro de uma dependência npm maliciosa. Isso é uma técnica deliberada para escapar de ferramentas de detecção tradicionais que analisam apenas o PKGBUILD em si.
O Binário deps (atomic-lockfile)
O binário ELF contido no atomic-lockfile é um Rust-based infostealer com as seguintes capacidades identificadas por análise estática:
Rootkit via eBPF:
O executável referencia um programa eBPF (scales.bpf.c) e APIs da biblioteca libbpf, incluindo:
bpf_object__loadbpf_program__attachbpf_map__pin
O eBPF (extended Berkeley Packet Filter) permite que programas rodem dentro do kernel Linux com privilégios elevados. A análise revelou hooks para getdents64() (syscall de enumeração de entradas de diretório) e estruturas nomeadas hidden_pids, hidden_names e hidden_inodes, indicando funcionalidade de ocultação de processos, arquivos e inodes. Em outras palavras: o malware é capaz de se esconder da listagem de processos e de ferramentas como ls ou find.
Furtividade e Anti-Debugging:
O binário inclui lógica baseada em PTRACE_ATTACH e PTRACE_SEIZE para detectar e dificultar análise por debuggers.
Exfiltração de Credenciais:
As referências identificadas no binário incluem alvos de alto valor para roubo de credenciais:
- Credenciais do GitHub (tokens OAuth e SSH keys)
- Artefatos SSH (chaves privadas em
~/.ssh/) - Tokens HashiCorp Vault
- Bases de dados de cookies do browser (Chrome, Firefox, etc.)
- Dados do Slack, Discord, Microsoft Teams e Telegram
- Tokens de CI/CD e segredos de pipelines
Infraestrutura C2:
Relatórios adicionais apontam para uso de comunicações baseadas em Tor e a presença de referências a mineração de Monero como possível estágio posterior à infecção.
Exfiltração via HTTP:
O binário inclui suporte a multipart/form-data e referências a POST /upload, indicando capacidade de envio de dados coletados para servidor remoto.
A Sonatype rastreia a campanha como Sonatype-2026-003775 com CVSS de 8.7.
Como Verificar se o Seu Sistema foi Afetado
A equipa Arch Linux publicou uma lista dos pacotes comprometidos conhecidos. O método mais direto para cruzar os pacotes instalados no seu sistema contra essa lista é o seguinte comando:
curl -s 'https://md.archlinux.org/s/SxbqukK6IA' \
| grep -E '^[a-z0-9][a-z0-9@._+-]*$' \
| xargs -r pacman -Q 2>/dev/nullO que esse comando faz, linha por linha:
curl -s 'https://md.archlinux.org/s/SxbqukK6IA': Baixa a lista oficial de pacotes comprometidos publicada pelos mantenedores do Arch Linux.grep -E '^[a-z0-9][a-z0-9@._+-]*$': Filtra apenas as linhas que correspondem a nomes válidos de pacotes Arch Linux (evitando interpretar linhas de cabeçalho ou comentários como nomes de pacotes).xargs -r pacman -Q 2>/dev/null: Para cada nome de pacote filtrado, verifica com opacmanse ele está instalado no sistema. Erros (pacotes não encontrados) são descartados com2>/dev/null.
Se algum pacote aparecer como resultado, ele estava instalado e consta na lista de comprometidos.
Verificação Complementar: Pacotes Externos
Para listar todos os pacotes instalados que não provêm dos repositórios oficiais (ou seja, pacotes AUR ou instalados manualmente):
pacman -QmCompare manualmente a saída com a lista em https://md.archlinux.org/s/SxbqukK6IA para identificar pacotes suspeitos que possam não estar na lista automatizada.
Verificação no Histórico de Build
Se você utiliza helpers como yay, paru ou makepkg diretamente, pesquise no histórico de builds por indicadores de comprometimento:
grep -r "atomic-lockfile\|js-digest\|lockfile-js\|src/hooks/deps" ~/.cache/yay/ ~/.cache/paru/ /tmp/ 2>/dev/nullSe qualquer um desses padrões for encontrado em PKGBUILDs em cache, trate o host como comprometido.
O que Fazer se o Seu Sistema foi Comprometido
Caso o resultado das verificações anteriores indique que você instalou um dos pacotes afetados durante o período de 10 a 12 de junho de 2026, siga este plano de resposta a incidentes:
1. Rotacione todas as credenciais imediatamente:
- Tokens GitHub, GitLab e npm
- Chaves SSH (gere novos pares e revogue as chaves antigas nos servidores)
- Tokens HashiCorp Vault e segredos de CI/CD (GitHub Actions, GitLab CI, Jenkins)
- Senhas salvas em browsers (Chrome, Firefox)
- Sessões ativas do Slack, Discord, Teams e Telegram (encerre todas as sessões abertas)
- Credenciais Docker e Podman
2. Remova o pacote e as dependências npm maliciosas:
# Remova o pacote AUR comprometido (substitua <pacote> pelo nome real)
sudo pacman -Rns <pacote>
# Verifique e remova o atomic-lockfile do ambiente npm global
npm ls -g atomic-lockfile 2>/dev/null
npm uninstall -g atomic-lockfile 2>/dev/null3. Procure por persistência:
O malware pode ter instalado serviços systemd ou hooks persistentes:
systemctl list-units --type=service --state=running | grep -v "\.service"
ls -la /etc/systemd/system/ | grep -v "$(pacman -Qlq systemd | grep '.service$')"4. Considere reinstalação do sistema:
Dado que o payload inclui um rootkit eBPF capaz de ocultar processos e arquivos, a única forma garantida de eliminar a ameaça em um sistema comprometido é uma reinstalação limpa do Arch Linux a partir de mídia confiável.
Por que a Cadeia de Suprimentos Linux está sob Ataque Crescente
Nós temos cobertura sobre supply chain attacks de forma recorrente no Blog Dolutech, e o incidente Atomic Arch encaixa num padrão que se consolida em 2026: atacantes estão abandonando a tentativa de criar confiança do zero e passando a herdar confiança existente.
Nos ataques de typosquatting, o atacante cria um pacote com nome similar ao legítimo. No brandjacking, explora a familiaridade do nome. No modelo Atomic Arch, o atacante adquire a propriedade de projetos que já possuem confiança estabelecida junto à comunidade, sem precisar convencer ninguém a instalar algo novo.
Do ponto de vista do utilizador, a operação é completamente transparente: ele está simplesmente atualizando um pacote familiar, de um mantenedor aparentemente reconhecido, com histórico de commits que parece legítimo. Não há sinal de alerta óbvio.
Essa dinâmica é agravada por três fatores estruturais do ecossistema AUR:
- Pacotes com atualizações infrequentes: Mudanças maliciosas podem permanecer despercebidas por longos períodos sem que o pacote receba revisão ativa da comunidade.
- Dependência de vigilância comunitária descentralizada: Sem uma equipa de segurança centralizada com capacidade de auditoria contínua, a detecção depende de relatos individuais.
- Uso de AUR helpers com automação elevada: Ferramentas como
yayeparucompilam e instalam pacotes com mínima inspeção manual dos scripts subjacentes. Quando o próprioPKGBUILDé o vetor, essa automação elimina a última barreira de inspeção humana.
Implicações Regulatórias: NIS2, DORA e LGPD
Para organizações que utilizam sistemas Arch Linux (incluindo derivados como Manjaro, EndeavourOS e CachyOS) em ambientes produtivos ou de desenvolvimento, o incidente Atomic Arch levanta obrigações regulatórias diretas.
Europa (NIS2 e DORA): A Diretiva NIS2 (Diretiva UE 2022/2555) exige que entidades essenciais e importantes implementem medidas de gestão de riscos de cadeia de suprimentos de software (Artigo 21). Um incidente de comprometimento de pacotes instalados em infraestruturas produtivas pode configurar obrigação de notificação ao CERT nacional competente (como CERT.PT em Portugal) no prazo de 24 horas para o relatório inicial. O DORA (Regulamento UE 2022/2554) aplica exigências semelhantes para entidades do sector financeiro, com ênfase em gestão de risco de terceiros e resiliência operacional digital.
Brasil (LGPD): Se dados pessoais de titulares brasileiros foram processados nos sistemas afetados, a LGPD (Lei nº 13.709/2018) impõe ao controlador a obrigação de comunicar incidentes de segurança à ANPD e aos titulares afetados em prazo razoável (Art. 48). Organizações com operações no Brasil devem avaliar se o infostealer teve acesso a dados pessoais antes de determinar as obrigações de notificação aplicáveis.
Resposta da Equipe Arch Linux
A equipa do Arch Linux respondeu com rapidez após o incidente ser reportado na mailing list aur-general pelo mantenedor Jonathan Grotelüschen em 11 de junho de 2026. As ações tomadas incluíram:
- Reset e exclusão de todos os commits maliciosos identificados
- Banimento permanente das contas atacantes identificadas
- Publicação de lista centralizada de pacotes afetados para uso da comunidade
- Alerta público de que criação de contas AUR, atualizações e adoção de pacotes poderiam sofrer interrupção durante a mitigação
Os repositórios oficiais do Arch Linux, [core], [extra] e [multilib], permaneceram integralmente não afetados durante todo o incidente, pois estão sujeitos a processos de revisão controlados pelos Trusted Users.
Boas Práticas para Utilizadores do AUR
Com base no ocorrido, reunimos as recomendações que fazem diferença real no dia a dia:
- Revise sempre o PKGBUILD antes de instalar: Leia o diff completo de qualquer atualização de pacote AUR antes de confirmar a instalação. Procure por chamadas a
npm install,pip install,curl | bashou similares que não estavam presentes antes. - Prefira pacotes com mantenedores ativos e histórico longo: Pacotes recentemente adotados por novos mantenedores merecem atenção redobrada.
- Evite instalar pacotes órfãos sem revisão: O status de órfão é um sinal de alerta adicional.
- Considere ferramentas de auditoria de PKGBUILD: Projetos como
aurutilspermitem maior controle sobre o processo de build sem automação excessiva. - Mantenha um inventário de pacotes AUR instalados: Execute
pacman -Qmregularmente e revise a lista.
Conclusão
O ataque Atomic Arch representa uma inflexão no nível de sofisticação dos ataques direcionados a ecossistemas Linux. Ao combinar adoção legítima de pacotes órfãos, forjamento de commits de mantenedores confiáveis, payload em duas camadas (PKGBUILD + dependência npm) e um rootkit eBPF com capacidades avançadas de furtividade, os atacantes demonstraram que a confiança estabelecida numa comunidade open source pode ser capitalizada como vetor de ataque altamente eficaz.
A Dolutech reforça: se você usa Arch Linux ou qualquer derivado e instalou pacotes do AUR entre 10 e 12 de junho de 2026, execute imediatamente o comando de verificação fornecido neste artigo e siga o plano de resposta a incidentes descrito acima. Não espere sinais visíveis de comprometimento: o rootkit eBPF foi projetado precisamente para não os exibir.
Fonte principal: Sonatype Research (Sonatype-2026-003775, CVSS 8.7), Phoronix, mailing list aur-general do Arch Linux, GitHub lenucksi/aur-malware-check.
Amante por tecnologia Especialista em Cibersegurança e Big Data, Formado em Administração de Infraestrutura de Redes, Pós-Graduado em Ciências de Dados e Big Data Analytics e Machine Learning, Com MBA em Segurança da Informação, Escritor do livro ” Cibersegurança: Protegendo a sua Reputação Digital”.
