El malware estaba firmado por Red Hat
Esta semana, código destinado a robar credenciales llegó a los desarrolladores llevando el nombre de Red Hat. La amenaza no vino de fuera de su círculo de confianza: vino de dentro. No puede auditar hasta salir de ahí. Pero sí puede mantener sus credenciales fuera de su alcance.
Esta semana, código firmado por Red Hat intentó robar sus credenciales.
Los atacantes accedieron a la cuenta de un desarrollador de Red Hat y publicaron versiones manipuladas de paquetes oficiales de Red Hat. En el momento en que una máquina instalaba uno, se ejecutaba automáticamente código oculto que buscaba todo lo valioso que encontraba: claves de nube, tokens de acceso, inicios de sesión, cualquier cosa que abriera una puerta. Después usaba lo robado para propagarse.
Fíjese en la forma de esto. El objetivo no era Red Hat: era usted. Su nombre, su cuenta de confianza, el flujo de instalación que ha usado mil veces sin pensarlo: eso no fue la víctima. Fue el arma. El ataque no se coló por su círculo de confianza. Entró por la puerta principal llevando una credencial que usted mismo emitió. Eso es lo que diferencia a los ataques a la cadena de suministro de todo lo demás: el peligro no es un desconocido al que pueda bloquear, sino el proveedor en el que ya decidió confiar, que entrega la carga por usted. Y esto era Red Hat: una de las empresas con mayor madurez en seguridad que existen, con revisión real y presupuesto real. El código malicioso se distribuyó bajo su nombre de todos modos.
Así que esta es la conclusión que no puede eludir: si Red Hat no puede garantizar que lo que instala de su parte está limpio, nadie puede. Ni su framework, ni su proveedor de CI, ni esa dependencia tres niveles más abajo que nunca ha leído. En algún momento ejecutará código que no escribió y que no pudo auditar por completo. Eso no es un fallo de proceso: es lo que significa construir sobre el software de otros.
Siga analizando. Siga fijando versiones. Siga auditando. Todo eso merece la pena hacerlo; solo no dependa de ello, porque esta semana nada de ello habría ayudado: el malware llegó pre-confiado. La pregunta real no es cómo mantener el código malicioso fuera. Es esta: cuando el código malicioso se ejecute en su máquina, ¿ha protegido sus secretos?
Para casi todos, la respuesta honesta es no. Mire lo que capturó este ataque: variables de entorno, tokens guardados en ficheros, y después se acercó a los gestores de secretos en la nube y les pidió que entregaran su contenido. Así viven las credenciales en 2026: apiladas en un solo lugar, al alcance de cualquier cosa que esté ejecutándose. Una mala instalación no roba un secreto. Los roba todos, y luego se propaga.
La solución es dejar de guardar sus credenciales donde su código pueda alcanzarlas. Manténgalas a distancia.
Esa es toda la idea detrás del funcionamiento de Clavitor. Sus secretos no viven en su entorno; nada espera en un fichero .env para ser leído. Un programa —o un agente de IA— nunca posee la credencial. Obtiene la capacidad de usar una, recuperada en el momento exacto en que se necesita —nunca almacenada, nunca en caché— desde una de nuestras 21 ubicaciones en seis continentes, de modo que la copia más cercana está siempre a milisegundos de distancia, limitada al único secreto que se le concedió, con cada acceso registrado. Cuando un script de instalación malicioso tantea en busca de claves, encuentra una habitación vacía.
Y asumimos que en algún momento se capturará una credencial, por lo que lo que lleva un agente es casi inútil si se roba. Solo funciona desde la máquina a la que se emitió: cópiela y ejecútela desde los propios servidores del atacante, y se rechaza. Está limitada en frecuencia y supervisada: unos pocos secretos por minuto, de modo que no puede aspirar su bóveda, y en el momento en que supera su puñado habitual salta una alerta y se bloquea. La estrategia entera de un gusano —capturarlo todo rápido, usarlo en todas partes— choca con un muro.
No prometemos inmunidad: si una credencial está en uso activo en el instante en que se ejecuta el malware, esa puede ser capturada —ninguna arquitectura reescribe la física—. Pero ese es el punto. El ataque a Red Hat fue devastador porque una sola instalación podía vaciar un almacén completo de secretos y convertirlo en arma. La distancia, más una credencial fijada a una sola máquina y limitada a un goteo, convierte «se lo llevaron todo y se propagaron» en «puede que hayan capturado una clave en tránsito, y no funcionó en ningún otro sitio». Esa es la distancia entre una catástrofe y una nota al pie.
El malware estaba firmado por Red Hat. No puede auditar hasta superar eso. Asuma que el código entra —y asegúrese de que, cuando lo haga, sus secretos no estén ahí esperándolo.
(Registrado públicamente como «Miasma», una variante de la familia de gusanos npm autopropagables Shai-Hulud. Los análisis técnicos merecen su tiempo; esta entrada trata sobre la parte que no cambia de uno a otro.)
Fuentes: