AUR bloqueado: o malware que rouba as suas chaves SSH e cripto voltou

A equipa de DevOps do Arch Linux desativou temporariamente a adoção de pacotes no Arch User Repository (AUR) depois de detetar uma nova vaga de apropriações maliciosas de pacotes órfãos, seguidas da injeção de código nocivo. A medida foi anunciada a 30 de julho de 2026 e surge apenas seis semanas depois de uma campanha semelhante ter comprometido mais de 1.500 pacotes. Desta vez, investigadores identificaram um infostealer com funções de trojan de acesso remoto (RAT) e de propagação por SSH, distribuído através da rede Tor. As repositórios oficiais do Arch não foram afetadas — o problema é exclusivo do AUR, o repositório mantido pela comunidade.

O que aconteceu no AUR

Robin Candau, conhecido na comunidade como «Antiz», publicou o aviso em nome da equipa de DevOps do Arch Linux através da lista de correio oficial. O anúncio surgiu a 30 de julho de 2026 e explica que o AUR permite a qualquer utilizador registado adotar pacotes que ficaram órfãos pelos seus mantenedores originais, uma funcionalidade concebida para manter o software da comunidade atualizado quando os mantenedores ficam inativos.

É precisamente esta funcionalidade que os atacantes estão a explorar. Segundo a equipa, os agentes de ameaça têm adotado pacotes não mantidos e depois enviado commits maliciosos, provavelmente embutindo malware, backdoors ou payloads de supply-chain nos ficheiros PKGBUILD que os utilizadores mais tarde compilam e instalam; em resposta, a equipa desativou a funcionalidade de adoção por completo enquanto investiga e remedeia o incidente. A equipa de DevOps confirmou a medida de emergência a 30 de julho de 2026, invocando uma campanha ativa de apropriações não autorizadas seguidas da injeção de commits nocivos.

Para quem não conhece o AUR: funciona como um repositório comunitário onde os utilizadores podem submeter, manter e adotar scripts de build (PKGBUILDs) para software que não está incluído nos repositórios oficiais do Arch, sendo que a adoção permite a um utilizador assumir a propriedade de um pacote órfão. O problema estrutural é que o modelo assenta na confiança no nome e no historial de um pacote, mais do que em quem o mantém neste momento.

Como funciona o malware desta vaga

A análise técnica da campanha mais recente foi conduzida pela Independent Federated Intelligence Network (IFIN). A IFIN reportou que a campanha começou a 29 de julho com o pacote «openconnect-sso» e que apresenta muitas semelhanças com a campanha anterior, incluindo o uso da rede Tor para staging.

No ataque mais recente, os investigadores identificaram uma infeção em duas fases, sendo a primeira um loader e a segunda um payload Linux x86_64 descrito como malware de roubo de dados com funcionalidades de administração remota (RAT) e de worm por SSH. A análise mostrou que o loader de primeira fase foge à deteção ao verificar a presença de debuggers, sandboxes, máquinas virtuais e ambientes de CI/CD antes de instalar serviços systemd e cron jobs para garantir persistência.

Em seguida, descarrega e lança um cliente Tor disfarçado de dbus-daemon para obter o payload de segunda fase a partir de um servidor «.onion». A segunda fase é um infostealer escrito em Rust que visa credenciais de navegadores, carteiras de criptomoeda, dados de gestores de palavras-passe, segredos de cloud e de desenvolvimento, chaves de API de serviços de IA, chaves SSH e tokens de plataformas de mensagens.

A dimensão exata ainda não está fechada. O estado de comprometimento destes pacotes não foi confirmado de forma independente e uma lista de todos os 200 pacotes AUR considerados maliciosos não foi disponibilizada à data de publicação. Ainda assim, segundo o mesmo investigador, a campanha alastrou a pacotes AUR bastante populares como boringssl-git, icloudpd, windscribe-cli-v2-bin, stirling-pdf-desktop-bin, openconnect-sso, arduino-language-server-noclang-bin e pgadmin4-server.

Cronologia dos ataques ao AUR

Sobre os precedentes: o Arch Linux retirou três pacotes maliciosos do AUR que instalavam o CHAOS RAT em dispositivos Linux; chamavam-se «librewolf-fix-bin», «firefox-patch-bin» e «zen-browser-patched-bin», foram carregados pelo mesmo utilizador, «danikpapas», a 16 de julho, e removidos dois dias depois após serem sinalizados pela comunidade. Já a campanha de junho de 2026 recorreu a uma técnica diferente: os atacantes modificaram os scripts PKGBUILD com um hook de pós-instalação que descarregava discretamente um pacote npm malicioso chamado atomic-lockfile, que continha um hook de preinstall que implantava um binário ELF Linux chamado deps.

A Sonatype acompanha a campanha de junho como Sonatype-2026-003775 com uma pontuação CVSS de 8.7. Não foi atribuído nenhum CVE.

Indicadores e o que verificar

Com base na análise dos investigadores, estes são elementos a vigiar num sistema Arch que use o AUR:

• Processo dbus-daemon anómalo — pode ser um cliente Tor disfarçado usado para contactar o servidor «.onion».
• Novos serviços systemd ou cron jobs criados após uma instalação recente de pacote AUR.
• Modificações inesperadas em PKGBUILD com hooks de pós-instalação, chamadas a npm install ou execução de binários durante a fase de build.
• Acessos anómalos a diretórios sensíveis como .ssh, .gnupg, .config e ficheiros de dados de navegadores.
• Ligações SSH de saída inesperadas — o payload inclui capacidades de worm que lê id_rsa/id_ed25519 e known_hosts para se propagar lateralmente.

Recomendações de mitigação imediata:

• Ler sempre o PKGBUILD antes de correr makepkg, yay ou paru; não tratar o AUR como os repositórios oficiais.
• Desconfiar de pacotes recentemente adotados ou que subitamente ganham novos hooks de instalação.
• Confrontar quaisquer instalações recentes com as listas de pacotes afetados publicadas pela comunidade.
• Em caso de suspeita de execução, rodar palavras-passe, chaves SSH e tokens de API, e rever registos de acesso.
• Se o malware correu com privilégios de root, reinstalar o sistema é a via mais segura — a componente de ocultação torna a limpeza pouco fiável.

Porque é que isto importa em Portugal

Embora o Arch Linux seja uma distribuição de nicho, o alvo escolhido é revelador: o malware foi especificamente construído para atacar estações de trabalho de programadores e ambientes de CI/build, ou seja, não os utilizadores de secretária casuais, mas os programadores e os sistemas que constroem e distribuem código, tendo por objetivo dados de navegadores e de aplicações Electron, Slack, Microsoft Teams, Discord, credenciais de GitHub, tokens de npm, segredos do HashiCorp Vault, configurações Docker e Podman, chaves SSH, credenciais de VPN e ficheiros de histórico da shell. Comprometer a máquina de um programador é, na prática, comprometer as chaves para tudo o que essa pessoa toca.

Este tipo de ataque à cadeia de fornecimento de software é uma das ameaças que motivou o reforço regulatório europeu. Para as PME e organizações portuguesas abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), a gestão de risco na cadeia de fornecimento e a resposta a incidentes deixaram de ser opcionais. O CNCS e o CERT.PT recomendam a validação de origem do software, a segregação de ambientes de desenvolvimento e a rotação de credenciais após qualquer suspeita de exposição.

Há ainda uma dimensão de proteção de dados: se as credenciais roubadas derem acesso a sistemas que tratam dados pessoais, pode configurar-se uma violação de dados com obrigações de notificação à CNPD ao abrigo do RGPD. A lição transversal — para cidadãos, PME e profissionais — é que a confiança num nome de pacote familiar não substitui a verificação de quem o mantém agora e do que o build vai executar.

Perguntas frequentes

Os repositórios oficiais do Arch Linux estão afetados?

Não. O incidente é exclusivo do AUR, o repositório mantido pela comunidade. Os pacotes dos repositórios oficiais do Arch passam por curadoria e não foram comprometidos por esta campanha.

Como sei se instalei um pacote malicioso?

Verifique se instalou ou atualizou pacotes AUR desde final de julho de 2026, confronte-os com as listas de pacotes afetados publicadas pela comunidade e procure processos anómalos como um falso dbus-daemon, novos serviços systemd ou cron jobs e ligações SSH de saída inesperadas.

O que faço se acho que fui comprometido?

Rode imediatamente palavras-passe, chaves SSH e tokens de API, reveja os registos de acesso e remova o pacote suspeito. Se houver indícios de execução com privilégios de root, reinstalar o sistema é a opção mais segura, dado que o malware pode ocultar-se.

Porque é que os atacantes visam programadores?

Porque as máquinas de programadores guardam chaves SSH, tokens de GitHub e npm, segredos de cloud e credenciais que abrem portas a muitos outros sistemas. Comprometer um programador pode dar acesso a toda a cadeia de software que essa pessoa mantém.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela equipa de DevOps do Arch Linux, pela Independent Federated Intelligence Network (IFIN), pela Sonatype e por investigadores de segurança, bem como em reportagem da BleepingComputer e da Phoronix.