Cómo debe ser la respuesta a vulnerabilidades de día cero en la era post-Mythos

Por Sila Ozeren Hacioglu, ingeniera de investigación de seguridad en Picus Security. Si ejecuta PaperCut NG o MF, la última semana de agosto mostró cómo se ve la respuesta a vulnerabilidades cuando la IA acelera el descubrimiento.

El 27 de agosto, el aviso urgente de PaperCut indicó que los atacantes ya estaban explotando servidores. Sin CVE, sin exploit, sin parche. El primer parche de emergencia llegó un día después y fue eludido ese mismo día. El tercero llegó el 1 de septiembre. Seis días sin un parche que funcionara o un exploit para probar, mientras los atacantes ya explotaban en la naturaleza.

Y la ventana se está cerrando. El tiempo medio entre divulgación y explotación fue de 21,5 días el año pasado. Ahora se mide en horas. PaperCut no es la excepción. Es la plantilla.

A continuación se presenta un día en la vida de un equipo de seguridad, contado a través de un CVE hipotético. El CVE es inventado. El día no lo es: es lo que vivieron los clientes de PaperCut en agosto. Recorramos hora por hora.

08:00 – Aparece un CVE. Sin parche.

Te despiertas y el CVE-2026-1001 está en tu feed: RCE no autenticado, sin parche. Ejecutas una verificación de versión. Veinte activos coinciden. Antes de que puedas terminar de leer la lista, suena el teléfono. Es la dirección. Ya lo han visto, ya les han preguntado al respecto y quieren una respuesta en los próximos quince minutos: ¿estamos expuestos y qué estamos haciendo al respecto?

Elimina el pánico y hay exactamente dos preguntas que responder:

1. ¿Son estos 20 activos realmente explotables en mi entorno?
2. ¿Detendrían mis controles de seguridad el ataque, ahora mismo?

Los datos de versión dicen "afectado". Los datos de versión no son una respuesta. Ambas preguntas comienzan el día como desconocidas. Parchear no es una opción, porque no hay parche. Apagar los servicios resolvería la pregunta, pero el negocio depende de ellos. Nadie va a negociar eso. Necesitas un veredicto, no un apagón.

08:05 – Tu primer instinto no puede actuar

El movimiento natural es recurrir a tu herramienta automatizada de pentesting. Tomar el exploit, lanzarlo contra los 20 activos, ver qué cae. Así que buscas el exploit. No hay ninguno. No hay PoC público, nada que ejecutar. La herramienta que daría la respuesta está esperando munición, y tú también. El atacante no. La weaponización solía llevar semanas; ahora lleva horas, y el reloj empezó a las 08:00. Si esperas a un exploit público, el primero que funcione puede ser el que te golpee.

08:15 – El exploit es una cadena, no un payload

Aquí está el cambio. Un exploit no es solo un payload. Es una cadena: el payload debe entregarse, debe ejecutarse y luego el atacante debe escalar privilegios, inyectarse en un proceso y extraer credenciales para que el punto de apoyo valga algo. Cada paso es una técnica conocida, y las técnicas se pueden simular de forma segura contra tus controles antes de que alguien haya escrito el payload.

No puedes probar el exploit, porque no hay ninguno. Pero puedes probar la cadena que el exploit necesitaría. Mapea el CVE a las técnicas que debe ejecutar: entrega, ejecución, escalada de privilegios, inyección, acceso a credenciales, y ejecútalas contra tu stack en vivo: NGFW, WAF, hardening de endpoints, EDR, SIEM. Por activo. La salida es un veredicto: ¿tendría éxito esta cadena en tu entorno? La pregunta "¿es explotable aquí?" se vuelve comprobable diez minutos después de la divulgación.

Explicamos cómo funciona esto en detalle en nuestra publicación sobre validación de CVE sin un exploit funcional.

08:30 – Simulado, probado, con tickets

A las 08:30 la cadena se ha ejecutado. Los resultados no son cómodos, y eso es lo importante. El NGFW no detectó el paso de entrega. El WAF lo detectó pero no lo bloqueó. El hardening de endpoints marcó la ejecución. El EDR no generó ninguna alerta. El SIEM no generó ninguna alerta.

Ahora las dos incógnitas tienen respuesta. Los 20 activos están expuestos a esta cadena, y nada en el stack la detendría. Pero las brechas tienen nombres y responsables. Se crea un plan de acción: una regla de detección para el NGFW, una regla de prevención para el WAF, hardening por GPO para los endpoints, una regla IOA para el EDR, una regla de detección para el SIEM. Las reglas del EDR y del SIEM se despliegan automáticamente. El resto se envían como tickets y se trabajan durante la mañana, junto con un ticket de parche para cada activo afectado, en espera hasta que exista un parche.

A las 08:45 se vuelve a ejecutar la cadena. Esta vez: detectado, bloqueado, bloqueado, alertado, alertado. No has parcheado nada. Has roto la cadena en cada activo afectado antes de que exista un exploit funcional.

Aprende a construir un programa de seguridad contra atacantes con IA

En The Validation Summit '26, una vulnerabilidad aparece sin parche y sin exploit funcional. Vívelo validado el primer día, luego probado con el exploit real contra controles en vivo cuando llegue, y revalidado después de la corrección. En vivo en el producto.

12:00 – La amenaza recibe un nombre

Llega inteligencia de amenazas. Un grupo de amenazas iraní está ejecutando una campaña que weaponiza el CVE-2026-1001. Todavía no hay exploit público, pero los ataques han comenzado. A las 08:00 tenías una vulnerabilidad. A las 12:00 tienes un adversario. Eso cambia la pregunta. El CVE es ahora un eslabón en una cadena de muerte completa: acceso inicial, movimiento lateral, persistencia, exfiltración. Validaste la vulnerabilidad esta mañana. ¿Sobrevivirías a la campaña?

12:30 – Toda la campaña, ensayada

Tomas el nuevo informe, extraes el comportamiento pasado del grupo de informes anteriores y ensamblas la campaña completa como una simulación de ataque. La ejecutas de principio a fin contra tus controles.

– Acceso inicial: bloqueado. Las correcciones de las 08:30 se mantienen, y la mañana da frutos dos veces.
– Movimiento lateral: detectado, alerta disparada.
– Persistencia: omitida. Esta es una técnica que el trabajo centrado en el CVE nunca podría haber surfaced, porque no tiene nada que ver con el CVE.
– Exfiltración: bloqueada, controles de salida resistiendo.

La brecha de persistencia sigue el mismo bucle que la mañana: regla entregada, desplegada, re-probada. Cerrada antes de que termine el almuerzo. Recuerda este ensayo.

16:00 – El exploit se hace público

Se publica un exploit funcional. Ahora, y solo ahora, las pruebas en vivo tienen munición. El pentesting automatizado puede disparar el exploit real. Pero surgen dos restricciones de inmediato.

Primero, es posible que no tengas permitido hacerlo. Las políticas a menudo prohíben lanzar exploits en vivo contra activos de producción o críticos, y los servidores de impresión, controladores de dominio y sistemas OT son exactamente donde esa política muerde.

Segundo, el alcance: con un exploit real, un pentest puede tocar de forma segura quizás 5 de los 20 activos. Los otros 15 solo eran respondibles de la forma en que los respondiste a las 08:15.

16:30 – Verdad sobre el terreno, de dos maneras

Los cinco activos alcanzables se prueban con el exploit real. Tres no son explotables: los controles endurecidos esta mañana se enfrentan al ataque real y resisten. Esa es una confirmación en vivo de que los veredictos simulados eran correctos. Dos son explotables. Necesitan el parche, y todavía no hay ninguno, así que los tickets de parche abiertos a las 08:30 se elevan a críticos, con el PoC funcional y la evidencia de explotación adjuntos. Sin debate de severidad. La prueba está en el ticket. Hasta que llegue el parche, los dos quedan detrás de la regla de prevención del WAF con acceso web restringido a IPs de confianza.

18:00 – Llega el atacante. No pasa nada.

La campaña golpea tu organización. Bloqueada. Alertada. Brechas ya cerradas. El ataque fracasa contra controles validados a las 08:15, corregidos a las 08:30 y probados a las 08:45. Diez horas antes de que el atacante tuviera un exploit funcional, tu entorno ya no tenía esta exposición. Eso es lo que compra la validación a velocidad de máquina: terminas antes de que ellos empiecen.

Lo que este día requirió

Mira lo que realmente se usó. No una capacidad, sino tres, y ninguna es una bala de plata por sí sola:

– Validación de explotabilidad sin un exploit en vivo, para veredictos del primer día y para los activos que ningún ataque debería tocar.
– Validación de controles de seguridad, para probar que los controles compensatorios resisten y para detectar la brecha de persistencia que el CVE nunca señaló.
– Pentesting agéntico, para la verdad sobre el terreno donde existe un exploit real y se puede disparar de forma segura.

Y tenían que funcionar juntas, ante una señal, en horas. La campaña de las 12:30 reutilizó las correcciones de las 08:30. El pentest de las 16:30 confirmó los veredictos de las 08:15. Los hallazgos de uno alimentaron al siguiente. Ejecútalos como tres herramientas en silos con tres calendarios y este día lleva seis semanas, no diez horas.

Eso es lo que la plataforma Picus está diseñada para hacer: validación de explotabilidad, validación de controles de seguridad y pentesting autónomo en una sola plataforma, compartiendo una única fábrica de datos, activada por cambios en lugar de por calendario.

Ve el día completo, en vivo

Vamos a ejecutar este escenario exacto, en vivo en el producto, en The Validation Summit '26 el 14 de octubre a la 1 PM ET y el 15 de octubre a las 11 AM BST. Mikko Hyppönen abre con lo que cambió después de Mythos. Nuestro CTO Volkan Erturk muestra cómo la validación a velocidad de máquina cierra la brecha de parches y la brecha de velocidad. Líderes de seguridad de Chanel, Atlassian y Kraft Heinz hablan sobre cómo se están preparando realmente. Ron Eddings de Hacker Valley presenta. Una pregunta respondida: ¿cómo se ve realmente estar listo para Mythos? Dos horas. Gratis. Ve el flujo de trabajo en vivo.

Patrocinado y escrito por Picus Security.