Los atacantes se apoderaron de más de 400 paquetes en el Arch User Repository (AUR) esta semana y reescribieron sus scripts de compilación para instalar un ladrón de credenciales en cualquier máquina que los haya creado.
El malware es un binario de Rust creado para recopilar secretos de los desarrolladores. Cuando aterriza con root, también puede cargar un rootkit eBPF para ocultarse. AUR es la colección de paquetes comunitarios de Arch Linux y está separada de los repositorios oficiales de Arch, que no se vieron afectados.
Si instaló o actualizó un paquete AUR a partir del 11 de junio, compárelo con las listas actuales de paquetes afectados antes de confiar en el host. La lista de nombres es larga, sigue creciendo y aún no está completa.
Este ataque persigue el modelo de confianza, no una falla de software. Los paquetes comprometidos conservaron sus nombres, sus historias y la confianza que los acompañaban. Sólo cambiaron las instrucciones de construcción.
La trampa estaba en la receta, dejando el paquete exactamente igual al software que los usuarios pretendían instalar. Ningún exploit, ningún día cero y ninguna señal de que los propios sistemas de Arch hayan sido violados.
Los atacantes adoptaron paquetes abandonados, editaron los archivos de compilación y permitieron a los usuarios ejecutar la carga útil por ellos. Sonatype, que nombró la campaña Arco Atómicolos encontró persiguiendo proyectos huérfanos: paquetes cuyos mantenedores se habían retirado, dejándolos abiertos para que cualquiera los adoptara.
También falsificaron los metadatos de git commit para que los cambios parecieran provenir de un mantenedor de larga data, una cuenta que un usuario de confianza de Arch Linux confirmó más tarde que nunca estuvo comprometida.
Una vez que se adoptaba un paquete, se editaba su script PKGBUILD o .install para ejecutar npm install atomic-lockfile durante la compilación, colocando el paquete npm malicioso junto con un par de paquetes legítimos para cubrirse. Ese paquete, atomic-lockfile@1.4.2, lleva un gancho de preinstalación que ejecuta un ELF de Linux incluido llamado deps. Compile el paquete y el binario se ejecutará.
Los ejemplos confirmados reportados a la lista de correo de Arch incluyen los paquetes alvr y premake-git.
Qué hace el malware
Investigador independiente Whanos ingeniería inversa la carga útil de deps y describe un ladrón de credenciales de Rust dirigido a estaciones de trabajo de desarrolladores y sistemas de compilación. Recoge:
- Cookies, tokens y almacenamiento local de navegadores basados en Chromium (Chrome, Edge, Brave y muchos más)
- Datos de sesión de aplicaciones de Electron, incluidos Slack, Discord y Microsoft Teams
- Tokens de GitHub, npm y HashiCorp Vault, además de material al portador OpenAI/ChatGPT y metadatos de cuenta
- Claves SSH, hosts_conocidos e historiales de shell
- Credenciales de Docker y Podman y perfiles VPN
Los archivos robados se envían a través de HTTP a temp.sh. El comando y el control se ejecutan a través de un servicio cebolla Tor a través de un proxy de bucle invertido local.
Para lograr persistencia, instala un servicio 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 de inicio y una unidad por usuario en ~/.config/systemd/user/. De cualquier manera, quiere volver.
Los primeros artículos sobrevendieron el rootkit eBPF. Es opcional y solo se carga cuando el binario ya tiene raíz y la capacidad adecuada. No se utiliza para ganar privilegios. Cuando se activa, oculta los propios procesos del malware, los nombres de los procesos y los inodos de socket de las herramientas estándar, utilizando mapas BPF anclados llamados hide_pids, hide_names y hide_inodes, y elimina los intentos de adjuntar un depurador.
Eso cambia los consejos de limpieza. Eliminar el paquete AUR no es suficiente una vez que se ha ejecutado la carga útil. Un administrador de paquetes puede eliminar los archivos que conoce. No puede demostrar que la máquina esté limpia después de que una carga útil compatible con rootkit haya tenido la oportunidad de ejecutarse.
El binario también presenta un segundo archivo vinculado a monero-wallet-gui que el análisis señala como un posible criptominero no analizado. Un rootkit eBPF acoplado a un ladrón que ataca y atrapa es inusual, y es por eso que éste vale más que encogerse de hombros.
Alcance y una segunda ola
El primer artículo de Sonatype contó más de 20 paquetes secuestrados. En un día, los rastreadores comunitarios y el Arco hilo general de aur había catalogado más de 400, con una lista maestra compilada al buscar el espejo git de AUR, colocándola alrededor de 408, y listas consolidadas subiendo más.
El paquete atomic-lockfile npm en sí mostró solo 134 descargas semanales en Enchufe antes de que fuera retirado del registro, por lo que la exposición real es la ruta de compilación de AUR en lugar de las instalaciones de npm.
Una segunda ola utilizó bun install js-digest, impulsado desde un conjunto separado de cuentas que los rastreadores de la comunidad vinculan al mismo editor npm que atomic-lockfile. Su carga útil es un binario diferente, un ELF separado por su hash, que la comunidad también marcó como malicioso.
Aún se está contando hasta qué punto se ha extendido esta ola. Los primeros desgloses enumeraron unas pocas docenas de paquetes, mientras que las búsquedas posteriores basadas en grep en el espejo AUR arrojaron números mucho más altos que pueden incluir la deserción a medida que se eliminan las confirmaciones. De cualquier manera, no es una nota a pie de página de la primera ola, así que verifique tanto atomic-lockfile como js-digest.
Que hacer ahora
Los mantenedores de Arch están restableciendo las confirmaciones maliciosas, prohibiendo las cuentas y pidiendo a los usuarios que sigan informando paquetes sospechosos en el hilo de la lista de correo.
Trate la lista publicada de paquetes afectados como incompleta. Por tu parte:
- Verifique cualquier paquete AUR instalado o actualizado a partir del 11 de junio con las listas de paquetes de la comunidad y los scripts de detección, que comparan sus paquetes externos con el conjunto defectuoso conocido. Grep historial de compilación reciente y cachés para npm install atomic-lockfile, bun install js-digest y la ruta de carga útil src/hooks/deps.
- Si se ejecutó un paquete marcado, trate al host como con credenciales comprometidas. Rote todo lo que toca el ladrón: 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 nube.
- Caza por la perseverancia. Busque servicios systemd desconocidos (tanto unidades del sistema como ~/.config/systemd/user/) y archivos inesperados en /var/lib/. Inspeccione /sys/fs/bpf/ para ver los mapas Hidden_pids, Hidden_names y Hidden_inodes. Revisar las conexiones salientes a Tor y cargar servicios.
- Si el paquete se ejecutó como root, asuma que el rootkit está presente y reinstálelo desde un medio confiable. De lo contrario, no hay forma de confiar en el sistema.
- En el futuro, lea PKGBUILD y cualquier enlace .install antes de compilar, especialmente para paquetes adoptados recientemente o que se activan repentinamente después de un largo período de inactividad. Si no comprende las instrucciones de compilación, no instale el paquete.
Para la detección, el SHA-256 de la carga útil principal es 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b; el conjunto completo de indicadores, incluido el host cebolla C2, se encuentra en el análisis ioctl.fail.
La misma táctica de adopción afectó a un paquete de visor de PDF abandonado en 2018; la versión 2026 simplemente la amplió, 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 utilizar errores tipográficos para engañar a los usuarios. La lista de afectados aún está 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 la AUR todavía confía en el nombre y el historial de un paquete antes que en quién lo mantiene ahora. Un paquete adoptado recientemente, o uno del que de repente surgen nuevos ganchos de instalación, ahora merece la misma sospecha que un paquete de un extraño.
