(https://i.imgur.com/SLk92n7.jpeg)
La comunidad de Linux enfrenta una de las campañas de ataque a la cadena de suministro más importantes de los últimos años después de que actores maliciosos lograran comprometer más de 400 paquetes alojados en el Arch User Repository (AUR). La operación, bautizada como Atomic Arch por los investigadores de Sonatype, permitió distribuir malware diseñado para robar credenciales, tokens de acceso, claves SSH y otros secretos críticos de desarrolladores y administradores de sistemas.
A diferencia de muchos incidentes recientes relacionados con vulnerabilidades de software o fallos de seguridad de día cero, este ataque explotó directamente el modelo de confianza del ecosistema AUR. Los atacantes no comprometieron la infraestructura de Arch Linux ni vulneraron los repositorios oficiales. En su lugar, aprovecharon paquetes abandonados o huérfanos para heredar la reputación y confianza acumulada durante años por sus mantenedores originales.
El resultado fue una campaña de gran alcance capaz de afectar a cualquier usuario que compilara o actualizara paquetes comprometidos desde el 11 de junio.
Cómo funcionó el ataque contra el Arch User RepositoryEl Arch User Repository es una plataforma comunitaria que permite a los usuarios compartir scripts de construcción conocidos como PKGBUILD para instalar software en Arch Linux. A diferencia de los repositorios oficiales, estos paquetes son mantenidos por la comunidad y dependen en gran medida de la confianza entre desarrolladores y usuarios.
Los atacantes identificaron paquetes abandonados cuyos mantenedores originales ya no participaban activamente en el proyecto. Posteriormente solicitaron la adopción de dichos paquetes, un procedimiento legítimo dentro del ecosistema AUR.
Una vez obtenidos los permisos de mantenimiento, modificaron discretamente los archivos PKGBUILD y los scripts de instalación para incorporar instrucciones maliciosas. Como los nombres de los paquetes, el historial del proyecto y la funcionalidad final permanecían intactos, los usuarios no tenían motivos aparentes para sospechar.
Además, los investigadores descubrieron intentos de falsificación de metadatos de Git para que determinadas modificaciones parecieran realizadas por mantenedores históricos de confianza, aumentando aún más la credibilidad de los cambios.
El paquete malicioso oculto tras una instalación aparentemente legítimaLa carga maliciosa principal se distribuía mediante la ejecución de:
- npm install atomic-lockfile
- bun install js-digest
Durante el proceso de compilación del paquete.
En la primera oleada, el paquete npm
[email protected] incluía un script de preinstalación encargado de ejecutar un binario ELF para Linux denominado deps.
Desde la perspectiva del usuario, la instalación parecía completamente normal. El software solicitado se instalaba correctamente y funcionaba según lo esperado. Sin embargo, en segundo plano, el malware comenzaba a recopilar información sensible del sistema.
Este enfoque demuestra una evolución significativa en los ataques a la cadena de suministro, donde los ciberdelincuentes ya no necesitan engañar a los usuarios con aplicaciones falsas, sino que aprovechan proyectos legítimos y ampliamente utilizados.
Qué información roba el malwareTras analizar el binario malicioso mediante ingeniería inversa, el investigador independiente Whanos identificó un sofisticado ladrón de credenciales desarrollado en Rust y orientado específicamente a entornos de desarrollo.
Entre los datos recopilados se encuentran:
Navegadores ChromiumEl malware extrae información de navegadores basados en Chromium, incluyendo:
- Google Chrome
- Microsoft Edge
- Brave
- Opera
- Otros derivados de Chromium
Los datos robados incluyen cookies, sesiones activas, tokens de autenticación y almacenamiento local.
Aplicaciones ElectronLa amenaza también apunta a plataformas empresariales y de colaboración como:
- Slack
- Discord
- Microsoft Teams
Esto permite a los atacantes secuestrar sesiones activas sin necesidad de conocer contraseñas.
Credenciales de desarrolloUno de los objetivos prioritarios son los entornos DevOps y desarrollo de software. El malware busca:
- Tokens de GitHub
- Credenciales npm
- Secretos de HashiCorp Vault
- Tokens asociados con OpenAI y ChatGPT
- Información de cuentas y metadatos
- Infraestructura y acceso remoto
La carga maliciosa también recopila:
- Claves SSH
- Archivos known_hosts
- Historiales de terminal
- Configuraciones VPN
- Credenciales Docker
- Credenciales Podman
Esta información puede utilizarse posteriormente para comprometer servidores corporativos, repositorios de código y entornos de nube.
Persistencia avanzada mediante systemdUna vez ejecutado, el malware intenta mantenerse activo incluso después de reinicios.
Para lograrlo instala servicios persistentes mediante systemd.
Cuando obtiene privilegios de root:
- Se copia en directorios bajo /var/lib/
- Crea servicios en /etc/systemd/system/
- Configura reinicio automático permanente
Si se ejecuta con privilegios limitados:
- Se instala en el directorio del usuario
- Utiliza unidades bajo ~/.config/systemd/user/
- Mantiene persistencia a nivel de sesión
Esto dificulta significativamente la detección y eliminación manual.
El peligroso rootkit eBPFUno de los elementos más llamativos de la campaña es la presencia opcional de un rootkit basado en eBPF.
Aunque inicialmente algunos informes sugirieron que el rootkit era el componente principal del ataque, los análisis posteriores demostraron que únicamente se carga cuando el malware ya dispone de privilegios elevados.
Su función principal consiste en ocultar:
- Procesos maliciosos
- Nombres de procesos
- Conexiones de red
- Inodos de sockets
- Actividad asociada al malware
Además, intenta bloquear herramientas de depuración para dificultar los análisis forenses.
Los investigadores identificaron mapas BPF persistentes con nombres como:
- hidden_pids
- hidden_names
- hidden_inodes
La presencia de estos artefactos constituye un fuerte indicador de compromiso.
Más de 400 paquetes afectados y una segunda oleadaLos primeros informes de Sonatype identificaron poco más de veinte paquetes comprometidos. Sin embargo, las investigaciones comunitarias posteriores revelaron una dimensión mucho mayor.
En apenas 24 horas, investigadores y usuarios de Arch Linux habían identificado más de 400 paquetes comprometidos.
Las estimaciones más recientes sitúan la cifra en aproximadamente 408 paquetes, aunque la lista continúa evolucionando debido a la eliminación de commits maliciosos y nuevos hallazgos.
Posteriormente apareció una segunda campaña basada en el paquete malicioso js-digest, distribuido mediante Bun en lugar de npm.
Los investigadores creen que ambas operaciones están relacionadas debido a similitudes en la infraestructura utilizada y en los responsables de publicar los paquetes maliciosos.
Qué deben hacer los usuarios afectadosLos administradores de Arch Linux recomiendan asumir una posible exposición si se instaló o actualizó cualquier paquete AUR después del 11 de junio.
Las medidas prioritarias incluyen:
Verificar paquetes instalados
Comparar todos los paquetes AUR instalados con las listas comunitarias de paquetes comprometidos.
Buscar indicadores de compromisoRevisar:
- npm install atomic-lockfile
- bun install js-digest
- src/hooks/deps
En historiales de compilación y registros del sistema.
Rotar credencialesSi el malware pudo ejecutarse, se recomienda reemplazar inmediatamente:
- Claves SSH
- Tokens GitHub
- Tokens npm
- Credenciales Docker
- Secretos Vault
- Sesiones de navegador
- Credenciales de servicios cloud
Revisar persistenciaInspeccionar:
- Servicios systemd desconocidos
- Directorios /var/lib/
- ~/.config/systemd/user/
- /sys/fs/bpf/
En busca de artefactos sospechosos.
Reinstalar sistemas comprometidosSi el paquete se ejecutó con privilegios root, los expertos recomiendan una reinstalación completa desde medios confiables.
La presencia potencial de un rootkit eBPF impide garantizar la integridad del sistema mediante simples procedimientos de limpieza.
Un nuevo ejemplo de los riesgos en la cadena de suministroLa campaña Atomic Arch demuestra que los atacantes están desplazando cada vez más su atención hacia la confianza depositada en proyectos legítimos y mantenedores históricos.
En lugar de explotar vulnerabilidades técnicas complejas, los ciberdelincuentes heredaron la reputación de proyectos abandonados para distribuir malware de forma silenciosa y efectiva.
El incidente también pone de relieve la necesidad de revisar cuidadosamente cualquier PKGBUILD o script de instalación antes de compilar software desde AUR, especialmente cuando se trata de paquetes recientemente adoptados o proyectos que han permanecido inactivos durante largos periodos.
A medida que continúan las investigaciones, este ataque ya se perfila como uno de los incidentes más significativos de 2026 relacionados con la seguridad de la cadena de suministro en Linux, recordando a desarrolladores y administradores que la confianza puede convertirse en el vector de ataque más peligroso cuando no se verifica adecuadamente.
Fuente: https://thehackernews.com/