El exploit no existe. Aún puedes demostrar que funciona contra ti

Durante treinta años, la gestión de vulnerabilidades se ha basado en un lujo que hoy parece imposible: un margen de meses entre el hallazgo de una vulnerabilidad y su posible explotación. Se priorizaba por gravedad, se programaba el parche, se validaba y se seguía adelante. Ese generoso margen era lo que hacía funcionar todo el sistema. La IA ha eliminado el retraso manual que mantenía lenta la creación de exploits. Leer el aviso, encontrar la ruta, dar forma a la cadena, probar qué funciona: nada de eso puede permitirse moverse a velocidad humana. Hoy, los plazos entre la divulgación y el exploit se miden en horas, no en meses. El Zero Day Clock, que sigue esto en tiempo real, promedia unas 8 horas en 2026, frente a los 53 días de hace solo dos años. La cifra varía con los nuevos datos, pero ya está claramente por debajo de las 24 horas.

No puedes parchear para salir de esto

El reflejo habitual es simplemente parchear más rápido. Pero la reparación no es un interruptor que se activa. Los parches dependen de múltiples contingencias: pruebas de regresión, ventanas de cambio y compromisos de disponibilidad. Y hoy, todos los números importantes se mueven en la dirección equivocada. El Informe de Investigaciones de Violaciones de Datos 2026 de Verizon, basado en más de 13.000 organizaciones, encontró que: el tiempo medio de reparación para vulnerabilidades conocidas explotadas es ahora de 43 días, frente a 32 el año pasado; la proporción de organizaciones que las parchean completamente ha bajado del 38% al 26%; e incluso los mejores solo corrigen entre el 30 y el 40% de estas vulnerabilidades en la primera semana, una tasa que apenas ha cambiado en años. Cuando el ataque corre en horas y la reparación en semanas, la brecha se produce en medio. Y la pista solo se alarga. El volumen lo garantiza: 48.185 CVEs en 2025, menos del 0,6% fueron parcheados. 'Parchear para salir' ha dejado de ser una matemática viable. Y lo que es peor, estas son cifras previas a Mythos. Mythos es el umbral en el que los modelos de IA pudieron encontrar y explotar vulnerabilidades por sí mismos, y no es teórico: el modelo Mythos de Anthropic encontró una falla que había estado oculta en OpenBSD, ampliamente considerado uno de los sistemas operativos más seguros del mundo, durante 27 años. La línea base de 2025 se ha convertido en el suelo, no en el techo. La pregunta ya no es '¿qué es vulnerable?', porque en una lista donde todo puntúa 9 o 10, esto no prioriza nada. La verdadera pregunta es '¿qué es realmente explotable contra nosotros, ahora mismo, con los controles que ya estamos ejecutando?' Encontrar la exposición nunca fue lo difícil. Demostrar la decisión correcta (parchear, mitigar, monitorear o aceptar) es la brecha crítica.

El documento de dos páginas recorre todo el pipeline de encadenamiento de TTPs. Muestra cómo Picus descompone cualquier CVE en su cadena de técnicas, prueba cada paso contra tus controles reales y devuelve un veredicto defendible sobre los activos que un exploit en vivo nunca puede alcanzar.

Tu pentest se ha vuelto más rápido. Aún no puede llegar a lo que importa.

La respuesta popular ha sido automatizar el pentest. Las herramientas de pentest automatizado toman la prueba de penetración manual que solía hacerse una vez al trimestre y la ejecutan continuamente, a escala, lanzando cadenas de exploits reales contra activos reales. Donde eso puede funcionar, es la prueba más sólida que existe: ves cómo el exploit tiene éxito. Picus también lo hace, con Autonomous Penetration Testing. No hay discusión. Pero, aunque automatizar el lanzamiento te hace más rápido, no cambia lo que el lanzamiento puede alcanzar. La explotación en vivo solo funciona donde disparar un exploit es seguro y donde existe un exploit funcional. Eso deja tres brechas que ninguna herramienta de pentest puede cerrar, y apilarlas no ayuda. ¿Por qué? Sin exploit, no hay nada que disparar. Una gran parte de los CVEs divulgados nunca obtienen un exploit público o seguro. Sin nada que lanzar, la ejecución no puede decirte si son explotables en tu entorno. Activos que no puedes arriesgar. Los sistemas críticos para el negocio, regulados y aislados son exactamente aquellos contra los que no puedes detonar un exploit de forma segura, y suelen ser los que más importan. La ventana del día uno. Convertir un exploit fresco en una herramienta lleva tiempo. Los atacantes ya se están moviendo mientras tu lanzamiento sigue en el banco. En una empresa típica, la parte que puedes explotar de forma segura en vivo suele ser solo el 10-15% de tu panorama de exposición total. Para el otro 85-90%, la ejecución no tiene respuesta.

Prueba en tierra el cohete que no puedes lanzar

La forma más segura de probar que un cohete volará es lanzarlo. Pero ningún programa espacial prueba así toda su flota. Algunos existen solo como diseño en papel, algunos tienen tripulación y son demasiado valiosos para arriesgarlos, y otros están aún en la línea de montaje. Así que los ingenieros los prueban en tierra: empuje del motor en un banco estático, probando el sistema de combustible a plena presión, el escudo térmico contra su carga térmica máxima. Si algún componente requerido falla, el cohete no puede volar, y lo saben sin salir de la plataforma. Esa es la misma brecha de tres partes que enfrentan los equipos de seguridad. El CVE sin exploit es el cohete que solo existe en papel. El activo fuera de límites es el cohete tripulado que no arriesgarás. El CVE del día uno es el fuselaje parcialmente construido mientras se acaba tu ventana de lanzamiento. El lanzamiento es la prueba a la que recurres cuando puedes; la prueba en tierra es la prueba en la que confías cuando no puedes.

Rompe la cadena, rompe el exploit

Un exploit no es magia. Es una cadena de técnicas específicas, los TTPs que un atacante debe ejecutar en secuencia: obtener ejecución, eludir una protección, escalar privilegios, volcar credenciales, moverse hacia el objetivo. Cada eslabón depende de condiciones en tu entorno, y cada uno puede probarse por separado contra tus controles reales desplegados, como un ingeniero prueba un motor en un banco estático sin tener que lanzar todo el vehículo. Eso es la validación de la cadena TTP. Mapeas un CVE a la cadena de técnicas que requiere su explotación, luego validas cada técnica contra tus controles existentes. Si tu entorno rompe cualquier eslabón necesario, el exploit no puede tener éxito allí, y lo sabes sin tener que disparar un exploit en vivo. Si cada eslabón se mantuviera, la exposición es realmente explotable, con evidencia. Cuatro cosas separan ese veredicto de una etiqueta CVSS o EPSS estática: Valida por inferencia, no por detonación. Por lo tanto, funciona donde la explotación en vivo sería insegura o imposible. Es consciente de los controles. El veredicto refleja tu EDR real, GPO, protección LSASS, listas blancas y firewall, no solo un número en una hoja de datos. Pesa la capacidad de alcance. Las exposiciones contenidas no se sobredimensionan. Genera evidencia. La cadena, los controles probados y el resultado: un rastro de auditoría que llega hasta la junta directiva.

Cómo se ve en un CVE real

Toma CVE-2025-29824, un use-after-free de Windows CLFS que escala a SYSTEM (visto en la naturaleza en actividad de Storm-2460 → RansomEXX). En lugar de disparar un exploit, lo descompones en la cadena que un atacante debe ejecutar y pruebas cada paso contra tu pila: certutil y ejecución de MSBuild – T1105 / T1127; omisión de KASLR / SysInfo – T1082; exploit CLFS UAF → ejecución en kernel – T1068; modificación de token e inyección en dllhost – T1134 / T1055; volcado de LSASS mediante dllhost enmascarado – T1003. Cada técnica se prueba contra la política de EDR, GPO/hardening, protección LSASS, listas blancas de aplicaciones y NGFW. Si tu lista blanca detiene la ejecución de MSBuild, o tu protección LSASS bloquea el volcado de credenciales, la cadena se rompe, el CVE no es explotable en ese activo, y puedes mostrar exactamente por qué. No se necesita un exploit certificado, y funciona en la caja aislada a la que nunca apuntarías un exploit en vivo. Y al hacerlo, has pasado de un ID de CVE nuevo a una decisión defendible en horas, el día de la divulgación, en lugar de semanas después. ¿Quieres profundizar en el encadenamiento de TTPs? Nuestro documento de dos páginas recorre todo el pipeline y el modelo de cobertura de principio a fin. >> Léelo aquí

Demuéstralo en todas partes, no solo donde puedas lanzar

El lanzamiento y la prueba en tierra no son rivales, son simbióticos. Los programas más sólidos ejecutan ambos, y siguen probando a medida que el entorno cambia con el tiempo y las configuraciones. Ese es el bucle que ejecuta Picus: cadenas de exploits en vivo donde disparar es seguro, encadenamiento de TTPs para los activos fuera de límites y los CVEs del día uno que un lanzamiento no puede alcanzar, y validación continua de controles para que el 'aceptar' del último trimestre se vuelva a probar, no se asuma. Una plataforma, y una respuesta a la única pregunta que importa: '¿Qué es realmente explotable aquí, ahora mismo?' Ponlo a prueba con el caso atascado en tu backlog: el CVE en la caja aislada que no puedes tocar, o el que apareció esta mañana sin exploit público aún. Solicita una demostración, y Picus lo mapeará a su cadena TTP y te mostrará, contra tus propios controles, si es explotable o no, y por qué, con la evidencia para llevar a tu junta directiva.

Solicita una demostración. Este artículo fue escrito por Sıla Özeren Hacıoğlu, Ingeniera de Investigación en Seguridad en Picus Security. Patrocinado y escrito por Picus Security.