Durante treinta años, la gestión de vulnerabilidades se ha basado en lo que
ahora parece un lujo imposible: un margen de meses entre el momento en que se
encontró una vulnerabilidad y el momento en que alguien pudo descubrir cómo
convertirla en un arma. Clasificar por gravedad, programar la solución,
validar y seguir adelante.
Ese generoso amortiguador es lo que hizo que todo el sistema funcionara.
La IA ha eliminado el arrastre manual que hacía que la creación y utilización
de «armas» fuera lenta. Leer el aviso, encontrar el camino, dar forma a la
cadena, probar qué funciona: nada de eso puede darse el lujo de moverse a la
velocidad humana.
Hoy en día, los plazos desde la divulgación hasta la explotación son de
horas, no de meses.
El Zero Day Clock, que rastrea esto en tiempo real, actualmente tiene un promedio de
alrededor de 8 horas para 2026, frente a aproximadamente 53 días hace apenas
dos años. La cifra cambia a medida que llegan nuevos datos, pero en este punto
se sitúa firmemente por debajo de las 24 horas.
No puedes salir de esto con parches
El reflejo suele ser simplemente parchear más rápido. Pero la remediación no
es simplemente un interruptor que se activa. Los parches esperan una serie de
contingencias: pruebas de regresión, ventanas de cambio y compromisos de
tiempo de actividad. Y hoy, lamentablemente, todos los números que importan
van en la dirección equivocada.
El
Informe de investigaciones de vulneración de datos de 2026 de Verizon, elaborado en más de 13.000 organizaciones, encontró que:
-
El tiempo medio de reparación de vulnerabilidades conocidas y explotadas es
ahora de 43 días, frente a los 32 del año pasado. -
La proporción de organizaciones que los parchean completamente se redujo del
38% al 26%. -
Incluso los que tienen mejor desempeño cierran sólo entre el 30 y el 40% de
estas vulnerabilidades en la primera semana, una tasa que apenas ha variado
en años.
Cuando la infracción se desarrolla en horas y la reparación en semanas, la
infracción se produce en el medio. Y la pista cada vez es más larga.
El volumen lo garantiza: 48.185 CVE en 2025,
menos del 0,6% jamás parcheados. «Parchear para salir» ha dejado de ser una matemática viable.
Mythos es el umbral en el que los modelos de IA fueron capaces de encontrar y
convertir en armas vulnerabilidades por sí solos, y no es teórico: el
modelo de clase Mythos de Anthropic
encontró una falla que había estado oculta en OpenBSD, ampliamente considerado
como uno de los sistemas operativos más seguros del mundo, durante 27 años.
La línea de base para 2025 se ha convertido en el piso, no en el techo.
La pregunta ya no es «¿qué es vulnerable?» porque en una lista donde todo
tiene una puntuación de 9 o 10, esto efectivamente no prioriza nada. La
verdadera pregunta es: «¿Qué es realmente explotable contra nosotros en este
momento, con los controles que ya estamos aplicando?». Encontrar la exposición
nunca fue la parte difícil. Demostrar la decisión correcta (parchear, mitigar,
monitorear o aceptar) es la brecha crítica.
Las herramientas de pentesting automatizados toman la prueba de penetración
manual que solía realizarse una vez por trimestre y la ejecutan continuamente,
a escala, activando cadenas de exploits reales contra activos reales.
Donde se puede ejecutar eso, es la prueba más fuerte que existe: ves cómo el
exploit tiene éxito. Pero, aunque automatizar el lanzamiento te hace más
rápido; no cambia lo que puede alcanzar la explotación.
La explotación en vivo solo funciona cuando es seguro activar un
exploit y cuando existe un exploit funcional. Eso deja tres
espacios en la herramienta pentest que se pueden cerrar, y apilarlos juntos
tampoco ayuda. ¿Por qué?
-
Sin exploit, nada que ejecutar. Una gran parte de los CVE divulgados
nunca obtienen un exploit público o seguro. Sin nada que iniciar, la
ejecución no puede indicarle si son explotables en su entorno. -
Activos que no puedes arriesgar. Los sistemas críticos para el negocio,
regulados y aislados son exactamente aquellos contra los que no se puede
detonar un exploit de forma segura y, por lo general, son los que más
importan. -
La ventana del primer día. Armar un nuevo exploit y conectarlo a sus
herramientas lleva tiempo. Los atacantes ya se están moviendo mientras tu
lanzamiento todavía está en el banco.
En una empresa típica, la porción que puede explotar de forma segura en vivo
suele ser sólo del 10 al 15% de su imagen de exposición total. Para el 85% o
90% restante, la ejecución no tiene respuesta que dar.
Probar en tierra un cohete que no se puede lanzar
La forma más segura de demostrar que un cohete volará es lanzarlo. Pero ningún
programa espacial demuestra que su flota sea así.
Algunos existen sólo como un diseño en papel, otros cuentan con tripulación y
son demasiado valiosos para arriesgarlos, y otros todavía están en la línea de
ensamblaje. Así que los ingenieros los prueban en tierra: el motor empuja en
una posición estática, prueba el sistema de combustible bajo presión total y
el escudo térmico contra su carga térmica máxima. Si algún componente
requerido falla, el cohete no puede volar y ellos lo saben sin abandonar la
plataforma.
Ésa es la misma brecha de tres partes que enfrentan los equipos de seguridad.
- El CVE sin exploits es el cohete que sólo existe en el papel.
- El activo prohibido es el cohete tripulado que no arriesgarás.
-
El CVE del primer día es el fuselaje parcialmente construido mientras se
agota la ventana de lanzamiento. -
El lanzamiento es la prueba a la que llegas cuando puedes; la prueba sobre
el terreno es la prueba en la que confías cuando no puedes.
Romper la cadena, rompe el exploit
Un exploit no es mágico. Es una cadena de técnicas específicas, los TTP que un
atacante tiene que ejecutar en secuencia: obtener ejecución, eludir una
protección, escalar privilegios, deshacerse de credenciales, avanzar hacia el
objetivo.
Cada enlace depende de las condiciones de su entorno, y cada uno puede
probarse por sí solo con los controles implementados reales, de la misma
manera que un ingeniero prueba un motor en un soporte estático sin tener que
arrancar todo el vehículo.
Esa es la validación de la cadena TTP. Usted asigna un CVE a la cadena de técnicas que requiere su explotación y
luego valida cada técnica con sus controles existentes. Si su entorno rompe
algún vínculo requerido, el exploit no podrá tener éxito allí y usted
lo sabrá sin tener que activar un exploit activo. Si todos los vínculos
se mantuvieran, la exposición sería genuinamente explotable, con evidencia.
Cuatro cosas distintas que 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 del control. El veredicto refleja su EDR, GPO, protección
LSASS, lista de permitidos y firewall reales, no solo un número en una hoja
de datos. -
Pesa la accesibilidad. Las exposiciones contenidas no se contabilizan en
exceso. -
Envía pruebas. La cadena, los controles probados y el resultado: una pista
de auditoría que llega hasta la junta directiva.
Cómo se ve en un CVE real
Tomemos como ejemplo CVE-2025-29824, un uso después de la liberación de CLFS
de Windows que escala a SYSTEM (visto en estado salvaje en la actividad
Storm-2460 o RansomEXX).
En lugar de activar un exploit, lo descompones en la cadena que un
atacante debe ejecutar y prueba cada paso con tu pila:
- Ejecución de certutil y MSBuild – T1105 / T1127
- Bypass KASLR / SysInfo – T1082
- Explotación CLFS UAF → ejecución del kernel – T1068
- modificación de token e inyección de dllhost – T1134 / T1055
- Volcado de LSASS a través de dllhost enmascarado – T1003
Cada técnica se prueba con respecto a la política de EDR, GPO/refuerzo,
protección LSASS, lista de aplicaciones permitidas y NGFW.
Si su lista de permitidos detiene el ejecutivo de MSBuild, o su protección
LSASS bloquea el volcado de credenciales, la cadena se rompe, el CVE no es
explotable en ese activo y puede 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, ha pasado de una nueva
identificación CVE a una decisión defendible en horas, el día de la
divulgación, en lugar de semanas después.
Pruébelo en todas partes, no sólo donde pueda lanzarlo
El lanzamiento y la prueba en tierra no son rivales, son simbióticos. Los
programas más potentes ejecutan ambos y siguen probando a medida que el
entorno avanza a través del tiempo y las configuraciones.
Se pueden ejecutar cadenas de exploits en vivo donde el disparo es
seguro, encadenamiento TTP para los activos fuera de los límites y CVE del
primer día que un lanzamiento no puede alcanzar, y validación de control
continuo para que la «aceptación» del último trimestre se vuelva a probar, no
se asuma.
Esto da una respuesta a la única pregunta que importa:
«¿Qué es realmente explotable aquí y ahora?»
Fuente:
BC