Paquetes npm de Red Hat atacados: más de 30 repositorios distribuyen un ladrón de credenciales en la nube
Una campaña coordinada de ataque a la cadena de suministro de npm para el robo de credenciales en la nube ha golpeado a uno de los nombres más reconocidos del software empresarial. Atacantes desconocidos comprometieron más de 30 paquetes npm de Red Hat Cloud Services, primero secuestrando la cuenta de GitHub de un empleado de Red Hat y usando ese acceso para enviar commits maliciosos. El malware incrustado en estos paquetes, identificado como una variante de la cepa 'Mini Shai-Hulud', se ejecuta automáticamente en el momento de la instalación y comienza inmediatamente a extraer credenciales en la nube, incluyendo claves de acceso de AWS, GCP y Azure, junto con claves SSH y archivos de configuración de Kubernetes.
Este incidente destaca no por una debilidad en npm en sí, sino por la forma en que los atacantes entraron: a través de una identidad de desarrollador legítima y de confianza.
Cómo se comprometieron los paquetes npm de Red Hat
La cadena de ataque comenzó con el compromiso de una sola cuenta de GitHub perteneciente a un empleado de Red Hat. Una vez dentro de esa cuenta, los atacantes tuvieron el acceso necesario para enviar código directamente a los repositorios vinculados a los paquetes npm de Red Hat Cloud Services. Dado que los commits provenían de una cuenta de colaborador reconocida, los pipelines automatizados y los revisores de código tuvieron una barrera mucho más alta para detectar algo sospechoso.
Esta es la característica definitoria de un ataque a la cadena de suministro de software: la carga maliciosa viaja dentro de software legítimo, firmado y distribuido a través de canales de confianza. Los desarrolladores que instalaron o actualizaron cualquiera de los paquetes afectados durante la ventana de compromiso habrían ejecutado el malware sin saberlo en sus propios sistemas, sin ninguna advertencia obvia. Los paquetes en sí continuaron funcionando normalmente, lo que dificultó aún más la detección.
La variante de malware 'Mini Shai-Hulud' está diseñada específicamente para ejecutarse en el momento de la instalación, justo cuando un desarrollador escribe npm install. No espera a que se lance la aplicación ni a que un usuario interactúe con ella. Este enfoque acorta drásticamente el tiempo entre la infección y la extracción de datos.
Qué credenciales se robaron y por qué son importantes
La lista de objetivos del malware parece una lista de verificación de las cosas más perjudiciales que un atacante podría extraer de la estación de trabajo de un desarrollador o de un ejecutor de pipeline CI/CD. Los archivos de credenciales de AWS, Google Cloud Platform y Azure son objetivos principales, ya que estas claves a menudo tienen permisos amplios en la infraestructura de producción. Las claves privadas SSH y los archivos de configuración de Kubernetes completan el botín, dando a los atacantes posibles rutas de movimiento lateral hacia redes internas y clústeres de orquestación de contenedores.
Para las organizaciones que ejecutan pipelines de compilación automatizados, el riesgo de exposición se amplifica. Los sistemas CI/CD frecuentemente almacenan credenciales en la nube de larga duración como variables de entorno o secretos montados. Un solo ejecutor de compilación infectado podría entregar silenciosamente claves que controlan entornos de nube completos, abriendo potencialmente la puerta a la extracción de datos, el despliegue de ransomware o el acceso persistente a través de puertas traseras.
Esta es también la razón por la que los equipos de seguridad deben tener en cuenta que los puntos de entrada de la cadena de suministro frecuentemente se encadenan con compromisos más profundos del sistema. La reciente señalización por parte de CISA de CVE-2026-31431, una falla de escalada de privilegios local en Linux, es un recordatorio directo: los atacantes que aterrizan en un sistema con credenciales robadas o acceso inicial rara vez se detienen allí. Buscan el siguiente eslabón en la cadena.
Por qué los ataques a la cadena de suministro son un punto ciego para la seguridad estándar
Las herramientas de seguridad convencionales se basan en la suposición de que el código externo, no firmado o desconocido es la amenaza. Los cortafuegos, los agentes de detección de endpoints y los escáneres basados en firmas están calibrados para marcar anomalías. Los ataques a la cadena de suministro subvierten ese modelo al esconderse dentro de software que lleva una firma legítima y llega a través de un canal esperado.
En este caso, la marca Red Hat y el historial de la cuenta de GitHub asociada habrían otorgado a los paquetes comprometidos un alto grado de confianza implícita. Los desarrolladores que trabajan en infraestructura relacionada con Red Hat pueden haber instalado estos paquetes precisamente porque esperaban que estuvieran bien mantenidos y seguros.
Las herramientas estándar de escaneo de dependencias que verifican versiones vulnerables conocidas no detectarían los ladrones de credenciales en tiempo de instalación a menos que la versión maliciosa ya hubiera sido marcada en una base de datos de vulnerabilidades. El ataque explota la brecha entre la detección de 'conocido malo' y el análisis de comportamiento.
Defensas en capas: gestión de secretos, segmentación de red y VPNs
Ningún control único detiene un ataque sofisticado a la cadena de suministro, pero las defensas en capas pueden reducir significativamente el radio de afectación.
Gestión de secretos en lugar de archivos de credenciales locales. La mitigación más efectiva es eliminar por completo los archivos de credenciales estáticos de las máquinas de desarrollo y los ejecutores de CI/CD. Las herramientas que emiten credenciales de corta duración y justo a tiempo significan que, incluso si se roba una credencial, expira antes de que un atacante pueda hacer un uso significativo de ella.
Fijación de dependencias y verificación de integridad. Bloquear los paquetes a hashes de commits específicos y verificados, en lugar de rangos de versiones flotantes, limita la exposición a cambios de código inesperados. Combinar esto con verificaciones automáticas de integridad del contenido del paquete agrega otra capa de detección.
Segmentación de red y filtrado de salida. El malware Mini Shai-Hulud necesita enviar datos robados a algún lugar. Restringir las conexiones salientes desde los entornos de compilación y las máquinas de desarrollo a endpoints conocidos puede prevenir la extracción incluso cuando el malware se ejecuta con éxito. Las VPNs y las arquitecturas de red de confianza cero pueden hacer cumplir estas políticas de salida de manera consistente en equipos distribuidos.
Autenticación multifactor en cada cuenta de desarrollador. El compromiso inicial aquí fue una toma de control de la cuenta de GitHub. Los requisitos estrictos de MFA, particularmente las llaves de seguridad de hardware o la autenticación basada en passkeys, dificultan sustancialmente el secuestro de cuentas.
Monitoreo del comportamiento en los pipelines de CI/CD. Alertar sobre consultas DNS salientes inesperadas o conexiones de red durante la fase de compilación puede revelar el malware en tiempo de instalación antes de que se utilicen las credenciales robadas.
Lo que esto significa para ti
Si tu entorno de desarrollo u operaciones depende de algún paquete npm de Red Hat Cloud Services, la prioridad inmediata es auditar qué versiones de paquetes están en uso, verificar indicadores de compromiso en los registros de red alrededor de los eventos de instalación y rotar cualquier credencial en la nube que pueda haber estado presente en los sistemas afectados.
De manera más amplia, este incidente es un aviso para revisar la higiene de las credenciales en la nube de principio a fin. ¿Se almacenan las credenciales como archivos en las máquinas de los desarrolladores? ¿Las variables de entorno de CI/CD tienen el alcance del menor privilegio? ¿Se aplica MFA en cada cuenta con derechos de publicación de paquetes?
Los ataques a la cadena de suministro tienen éxito al explotar la confianza. La contramedida es construir sistemas que no dependan únicamente de la confianza implícita; las identidades verificadas, los secretos con tiempo limitado y el monitoreo del comportamiento son la base. Comienza hoy con una auditoría de credenciales y trata cada dependencia como una superficie de ataque potencial que merece un escrutinio.
