¿Qué se restaura después del robo de una credencial?
Puede hacer copias de seguridad de los datos. No puede hacer copias de seguridad de la confianza. Cuando se roba una credencial no hay nada que restaurar, así que la única defensa consiste en no dejar tras el muro nada que merezca la pena llevarse.
Observe con qué seguridad responde a casi todo lo demás. Muere un disco, restaura desde la copia de seguridad. Llega el ransomware, conmuta a la réplica. Toda la disciplina de la recuperación ante desastres existe para que el fallo sea sobrevivible, y con los datos funciona: RAID no es una copia de seguridad, así que mantiene una copia de seguridad, y queda cubierto de cualquier modo.
Luego llega a la credencial, y treinta años de esa maquinaria no tienen nada que ofrecerle. No existe una copia limpia de la confianza desde la que restaurar. Una vez que se llevan una clave, no revierte la intrusión: revoca, vuelve a emitir y reconstruye la trama de confianza desde cero. Y mientras lo hace, todo lo que se autentica a través de esas credenciales cae con ellas: la nómina, los despliegues, las bases de datos a las que llegan sus propias aplicaciones, los agentes que tardó un año en desplegar.<br>El negocio no se ralentiza: se detiene. Puede hacer copias de seguridad de los datos. No puede hacer copias de seguridad de la confianza. Así que la respuesta honesta a la pregunta con la que empezaba es la incómoda: nada. No se sale de esto restaurando.
Qué ha ocurrido realmente
2026 está haciendo que esa distinción sea cara. Una nueva familia de ataques a Linux —Copy Fail, DirtyClone, pedit COW— se instala en una máquina sin cambiar un solo archivo en disco. Envenenan la copia de un binario de sistema de confianza que reside en la memoria del núcleo y ejecutan esa en lugar del original. El archivo en disco nunca se toca, así que su monitor de integridad lo comprueba, lo encuentra idéntico al de ayer e informa de que todo está en verde; su antivirus analiza el disco y no encuentra nada incorrecto, porque nada en disco está incorrecto. El atacante tiene un shell de root mientras cada instrumento que usted posee certifica que la máquina está limpia, y un reinicio borra las pruebas, porque solo existieron en la memoria.
Sus herramientas no están rotas. Vigilan los bytes en reposo sobre el disco, que fue el lugar correcto que observar durante veinte años, cuando cambiar lo que hace un programa significaba cambiar su archivo. El terreno se movió bajo la suposición, no bajo la herramienta. Consérvelas, pero sea claro respecto a lo que son: un muro, calificado según si resiste.
La pregunta que evitamos
Durante treinta años hemos calificado la seguridad por una sola cosa: ¿consiguió mantenerlos fuera? Cortafuegos, EDR, monitor de integridad: todo ello es prevención, y la prevención es una pregunta legítima. Lo que ya no es legítimo es apostar por ella una compañía, porque cuando una intrusión puede ser invisible, no dejar rastro y sobrevivir a que sus mejores herramientas informen de que todo está limpio, «mantenerlos fuera» deja de ser una estrategia y pasa a ser una esperanza.
La pregunta que evitamos es la que decide cuán grave llega a ser el día: cuando entren —y entrarán—, ¿qué pueden llevarse? Y sea lo que sea, la primera regla es la que nos enseñó el almacenamiento: no puede hacerse una copia de seguridad de ello. La confianza no se recupera.
Diseñado para esto, a propósito
Así que la jugada nunca consistió en buscar una copia de seguridad de sus credenciales. No existe, y esa es justo la clave. La jugada consiste en asegurarse de que, cuando el muro caiga, no haya nada detrás que valga la pena llevarse.
Una credencial emitida al modo de Clavitor nunca permanece en reposo en la máquina que el atacante acaba de comprometer como root. Está vinculada a esa única máquina, así que una copia sustraída en cualquier otro lugar es peso muerto. Está limitada a una única tarea y caduca, de modo que incluso root, incluso un root invisible y sin rastro, obtiene un token de vida breve para una tarea, no las llaves de todo. Y el registro de lo que tocó vive fuera de la máquina, en la bóveda, encadenado por hash, donde alguien que controle la máquina no puede reescribir la historia en silencio. La intrusión sigue teniendo éxito. El atraco sale con las manos vacías, y el único registro al que no pueden acceder ya dejó escrito lo ocurrido.
Nada de esto le hace inexpugnable, y quien venda eso miente. Hace que la intrusión sea sobrevivible: retira de la mesa el único desenlace del que no puede recuperarse, la confianza que no puede restaurar. Si usted mismo pega una clave maestra de vida larga en un archivo de esa máquina, root la leerá; nada le salva de levantar justo aquello que esto existe para eliminar. Una copia de seguridad tampoco detiene el ransomware. Solo significa que el ransomware no acaba con usted.
La lección no es «compre un muro mejor»
Quizá la revisión de seguridad no debería abrir con la pregunta que llevamos treinta años formulando. No «¿es seguro?»: todo el mundo dice que sí, y todo el mundo acaba equivocándose. Formule la que el almacenamiento ya aprendió a hacerse: cuando esto falle, ¿importará? Usted respondió esa pregunta por sus datos el día en que comprendió que RAID no bastaba y mantuvo una copia de seguridad. Sus credenciales no tienen copia de seguridad. Así que la única respuesta que queda es asegurarse de que no haya nada allí que perder.
Dejamos por escrito las reglas que una herramienta de credenciales debe respetar para el día en que el muro caiga.
Clavitor (@clavitorai) es la bóveda de credenciales creada para agentes de IA, y contra ellos. clavitor.ai
Fuentes
[1] Unit 42 (@Unit42_Intel) — Copy Fail (CVE-2026-31431): What You Need to Know. Una escritura en la caché de páginas corrompe la copia en memoria de un binario privilegiado como /usr/bin/su sin tocar el archivo en disco; afecta a casi todas las distribuciones, núcleos desde 2017.
[2] The Hacker News (@TheHackersNews) — New Linux pedit COW Exploit Enables Root Access by Poisoning Cached Binaries (CVE-2026-46331). Envenena el /bin/su en caché; las comprobaciones de integridad de archivos devuelven resultados limpios.
[3] The Hacker News (@TheHackersNews) — New DirtyClone Linux Kernel Flaw Lets Local Users Gain Root via Cloned Packets (CVE-2026-43503). La modificación solo existe en memoria; no deja rastro de auditoría, y un reinicio restaura el binario original.