Vulnerabilidades explotadas: ya no puedes salir de esto con parches

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

Suscríbete a nuestro Boletín