Durante treinta años, la gestión de vulnerabilidades ha operado sobre la base de un margen temporal que hoy parece un lujo inalcanzable: varios meses entre el descubrimiento de una vulnerabilidad y el momento en que alguien podría convertirla en un arma. Este período permitía clasificar por gravedad, programar la solución, validar y continuar. Ese amortiguador fue lo que permitió que todo el sistema funcionara.
La inteligencia artificial ha eliminado el proceso manual que hacía lenta la creación y utilización de armas. Leer el aviso, encontrar el camino, estructurar la cadena, probar qué funciona: ninguno de estos pasos puede permitirse el lujo de moverse a velocidad humana. En la actualidad, los tiempos 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 registra un promedio de alrededor de 8 horas para 2026, en comparación con aproximadamente 53 días hace apenas dos años. La cifra se actualiza conforme llegan nuevos datos, pero en este punto se sitúa firmemente por debajo de las 24 horas.
El reflejo habitual es simplemente aplicar parches más rápido. Sin embargo, la remediación no es un interruptor binario. Los parches requieren cumplir con diversas contingencias: pruebas de regresión, ventanas de cambio y compromisos de tiempo de actividad. Desafortunadamente, en la actualidad todos los números relevantes se mueven en la dirección equivocada.
El Informe de investigaciones de vulneración de datos de 2026 de Verizon, elaborado a partir de datos de 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 anterior. La proporción de organizaciones que las parchean completamente se redujo del 38% al 26%. Incluso las organizaciones de mejor desempeño cierran solo 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 ocurre en el medio. Y la ventana se hace cada vez más larga.
El volumen garantiza esta realidad: 48.185 CVE en 2025, de los cuales menos del 0,6% jamás son parcheados. La estrategia de «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 permanecido oculta en OpenBSD, ampliamente considerado 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: se puede ver cómo el exploit tiene éxito. Aunque automatizar el lanzamiento hace más rápido el proceso, 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. Esto deja tres espacios en la herramienta de pentesting que se pueden cerrar, pero apilarlos juntos tampoco ayuda.
Sin exploit, no hay 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 indicar si son explotables en un entorno específico. Los activos críticos para el negocio, regulados e isolados, 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. Armar un nuevo exploit y conectarlo a las herramientas lleva tiempo. Los atacantes ya se están moviendo mientras el lanzamiento todavía está en preparación.
En una empresa típica, la porción que puede explotarse de forma segura en vivo suele ser solo 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.
La forma más segura de demostrar que un cohete volará es lanzarlo. Pero ningún programa espacial demuestra que su flota lo haga de esta manera. Algunos existen solo 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. Los ingenieros los prueban en tierra: el motor empuja en una posición estática, se 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 lo saben sin abandonar la plataforma.
Esta es la misma brecha de tres partes que enfrentan los equipos de seguridad. El CVE sin exploits es el cohete que solo existe en papel. El activo prohibido es el cohete tripulado que no se arriesgará. 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 se llega cuando se puede; la prueba sobre el terreno es la prueba en la que confía cuando no puede.
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, obtener credenciales, avanzar hacia el objetivo.
Cada eslabón depende de las condiciones del entorno, y cada uno puede probarse individualmente con los controles implementados reales, de la misma manera que un ingeniero prueba un motor en un soporte estático sin tener que poner en marcha todo el vehículo.
Esa es la validación de la cadena TTP. Se asigna un CVE a la cadena de técnicas que requiere su explotación y luego se valida cada técnica con los controles existentes. Si el entorno rompe algún vínculo requerido, el exploit no podrá tener éxito allí y se sabrá sin tener que activar un exploit activo. Si todos los vínculos se mantienen, la exposición sería genuinamente explotable, con evidencia.
Esto proporciona cuatro cosas distintas al veredicto de una etiqueta CVSS o EPSS estática: valida por inferencia, no por detonación, por lo que funciona donde la explotación en vivo sería insegura o imposible. Es consciente del control, reflejando EDR, GPO, protección LSASS, lista de permitidos y firewall reales, no solo un número en una hoja de datos. Pesa la accesibilidad, de modo que las exposiciones contenidas no se cuentan en exceso. Proporciona pruebas: la cadena, los controles probados y el resultado, una pista de auditoría que llega hasta la junta directiva.
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, se descompone en la cadena que un atacante debe ejecutar y se prueba cada paso con la pila de controles. Esta incluye ejecución de certutil y MSBuild, bypass KASLR/SysInfo, explotación CLFS UAF hacia ejecución del kernel, modificación de token e inyección de dllhost, y volcado de LSASS a través de dllhost enmascarado.
Cada técnica se prueba con respecto a la política de EDR, GPO/refuerzo, protección LSASS, lista de aplicaciones permitidas y firewall de nueva generación. Si la lista de permitidos detiene el ejecutable de MSBuild, o la protección LSASS bloquea el volcado de credenciales, la cadena se rompe, el CVE no es explotable en ese activo y puede mostrarse exactamente por qué. No se necesita un exploit certificado y funciona en el activo aislado al que nunca se apuntaría un exploit en vivo. Al hacerlo, se 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.
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 continua para que la «aceptación» del trimestre anterior se vuelva a probar, no se asuma.
Esto da una respuesta a la única pregunta que importa: «¿Qué es realmente explotable aquí y ahora?»
Con Información de blog.segu-info.com.ar
