Atacantes tomaron el control de más de 400 paquetes huérfanos en el repositorio AUR de Arch Linux para instalar un malware que roba credenciales y secretos de desarrolladores. El software malicioso utiliza un rootkit eBPF para ocultarse y puede persistir en el sistema mediante servicios de systemd. Se recomienda a los usuarios revisar sus instalaciones desde el 11 de junio y reinstalar el sistema si se ejecutaron paquetes afectados con permisos de root.



Los atacantes tomaron el control de más de 400 paquetes en el Arch User Repository (AUR) esta semana y reescribieron sus scripts de construcción para instalar un robador de credenciales en cualquier máquina que los compilara.

El malware es un binario de Rust diseñado para recolectar secretos de desarrolladores. Cuando se ejecuta con privilegios de root, también puede cargar un rootkit eBPF para ocultarse. El AUR es la colección de paquetes de la comunidad de Arch Linux y es independiente de los repositorios oficiales de Arch, los cuales no se vieron afectados.

Si instalaste o actualizaste un paquete de AUR el 11 de junio o después, compruébalo con las listas actuales de paquetes afectados antes de confiar en el equipo. La lista de nombres es larga, sigue creciendo y aún no está completa.

Este ataque va dirigido al modelo de confianza, no a un fallo de software. Los paquetes comprometidos mantuvieron sus nombres, sus historiales y la confianza que los acompañaba. Solo cambiaron las instrucciones de construcción.

La trampa estaba en la receta, haciendo que el paquete pareciera exactamente el software que los usuarios pretendían instalar. Sin exploits, sin zero-days y sin señales de que los propios sistemas de Arch fueran vulnerados.

Los atacantes adoptaron paquetes abandonados, editaron los archivos de construcción y dejaron que los usuarios ejecutaran la carga útil por ellos. Sonatype, que llamó a la campaña Atomic Arch, descubrió que iban tras proyectos huérfanos: paquetes cuyos mantenedores se habían marchado, dejándolos abiertos para que cualquiera los adoptara.

También falsificaron los metadatos de los commits de git para que los cambios parecieran provenir de un mantenedor veterano, una cuenta que un Usuario Confiable de Arch Linux confirmó más tarde que nunca fue comprometida.

Qué hace el malware

El investigador independiente Whanos realizó una ingeniería inversa de la carga útil "deps" y describe un robador de credenciales en Rust dirigido a estaciones de trabajo de desarrolladores y sistemas de construcción. Recolecta:

* Cookies, tokens y almacenamiento local de navegadores basados en Chromium (Chrome, Edge, Brave y muchos más)
* Datos de sesión de aplicaciones Electron, incluyendo Slack, Discord y Microsoft Teams
* Tokens de GitHub, npm y HashiCorp Vault, además de material de portador de OpenAI/ChatGPT y metadatos de cuentas
* Claves SSH, known_hosts e historiales de shell
* Credenciales de Docker y Podman y perfiles de VPN

Los archivos robados se envían vía HTTP a temp.sh. El comando y control funciona a través de un servicio onion de Tor mediante un proxy de bucle local.

Para lograr persistencia, instala un servicio de systemd con Restart=always. Con root, se copia a sí mismo en /var/lib/ y escribe una unidad en /etc/systemd/system/; como usuario normal, utiliza el directorio home y una unidad de usuario en ~/.config/systemd/user/. De cualquier manera, quiere volver.

Los primeros análisis exageraron el rootkit eBPF. Es opcional y solo se carga cuando el binario ya tiene privilegios de root y la capacidad adecuada. No se usa para ganar privilegios. Cuando se activa, oculta los propios procesos del malware, los nombres de los procesos y los inodes de los sockets de las herramientas estándar, utilizando mapas BPF anclados llamados hidden_pids, hidden_names y hidden_inodes, y bloquea los intentos de adjuntar un depurador.

Esto cambia el consejo de limpieza. Eliminar el paquete AUR no es suficiente una vez que la carga útil se ha ejecutado. Un gestor de paquetes puede eliminar los archivos que conoce, pero no puede probar que la máquina esté limpia después de que una carga útil capaz de instalar un rootkit haya tenido la oportunidad de ejecutarse.

El binario también prepara un segundo archivo vinculado a monero-wallet-gui que el análisis marca como un posible cryptominer no analizado. Un rootkit eBPF unido a un robador rápido es inusual, y es por eso que este caso merece más que un simple encogimiento de hombros.

Alcance y una segunda ola

El primer informe de Sonatype contabilizó más de 20 paquetes secuestrados. En un día, los rastreadores de la comunidad y el hilo aur-general de Arch habían catalogado más de 400, con una lista maestra compilada mediante grep del espejo git de AUR, situándolo en torno a 408, y listas consolidadas que subían aún más.

El propio paquete npm atomic-lockfile mostró solo 134 descargas semanales en Socket antes de ser retirado del registro, por lo que la exposición real es la ruta de construcción de AUR más que las instalaciones de npm.

Una segunda ola utilizó bun install js-digest, impulsada desde un conjunto separado de cuentas que los rastreadores de la comunidad vinculan al mismo editor de npm que atomic-lockfile. Su carga útil es un binario diferente, un ELF distinto según su hash, que la comunidad también marcó como malicioso.

Aún se está contando hasta dónde ha llegado esta ola. Los primeros desgloses enumeraron unas pocas docenas de paquetes, mientras que las búsquedas posteriores basadas en grep del espejo de AUR devolvieron números mucho más altos que pueden incluir fluctuaciones a medida que se eliminan los commits. De cualquier manera, no es una simple nota al pie de la primera ola, así que busca tanto atomic-lockfile como js-digest.

Qué hacer ahora

Los mantenedores de Arch están restableciendo los commits maliciosos, prohibiendo las cuentas y pidiendo a los usuarios que sigan informando de paquetes sospechosos en el hilo de la lista de correo.

Trata la lista publicada de paquetes afectados como incompleta. Por tu parte:

• * Comprueba cualquier paquete AUR instalado o actualizado el 11 de junio o después contra las listas de paquetes de la comunidad y los scripts de detección. Busca en el historial de construcción reciente y en las cachés: npm install atomic-lockfile, bun install js-digest y la ruta de la carga útil src/hooks/deps.
• * Si un paquete marcado se ejecutó, trata el equipo como comprometido en sus credenciales. Cambia todo lo que el robador toque: sesiones de navegador, claves SSH, tokens de GitHub y npm, sesiones de Slack, Teams y Discord, tokens de Vault, credenciales de Docker y Podman, y cualquier clave de la nube.
• * Busca persistencia. Comprueba si hay servicios de systemd desconocidos y archivos inesperados en /var/lib/. Inspecciona /sys/fs/bpf/ para encontrar los mapas hidden_pids, hidden_names y hidden_inodes. Revisa las conexiones salientes a Tor y a servicios de carga de archivos.
• * Si el paquete se ejecutó como root, asume que el rootkit está presente y reinstala desde un medio confiable. No hay otra forma de confiar en el sistema.
• * De ahora en adelante, lee el PKGBUILD y cualquier hook de .install antes de compilar, especialmente en paquetes adoptados recientemente o que repentinamente se activan tras un largo periodo de inactividad. Si no entiendes las instrucciones de construcción, no instales el paquete.

Para la detección, el SHA-256 de la carga útil principal es 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b; el conjunto completo de indicadores, incluido el host C2 onion, está en el análisis de ioctl.fail.

La misma táctica de adopción afectó a un paquete de visor de PDF abandonado en 2018; la versión de 2026 simplemente lo escaló, como parte de una serie más amplia de ataques a la cadena de suministro que secuestran proyectos huérfanos para heredar la confianza en lugar de usar typosquatting para engañar a los usuarios. La lista de afectados sigue incompleta y no se ha asignado ningún CVE; Sonatype rastrea la campaña como Sonatype-2026-003775 (CVSS 8.7).

El ataque funcionó porque el AUR todavía confía más en el nombre y el historial de un paquete que en quien lo mantiene ahora. Un paquete adoptado recientemente, o uno que de repente presenta nuevos hooks de instalación, merece ahora la misma sospecha que un paquete de un extraño.

Fuente:
THN