El cronograma sobre el que se construyó la gestión de vulnerabilidades ha desaparecido silenciosamente. Durante décadas, los defensores podían contar con semanas o meses entre la divulgación de una falla y la creación de un ataque funcional. Dos fuerzas cerraron esa brecha al mismo tiempo.

La primera es el volumen: nuevas fallas se acumulan mucho más rápido que antes. Solo en el primer semestre de 2026 se registraron más CVE que en cualquier año completo previo a 2024, a una tasa de aproximadamente uno cada 7,4 minutos. La segunda es la velocidad: la IA ha borrado lo que quedaba del colchón. El Zero Day Clock, que mide el tiempo hasta la explotación, sitúa la mediana para 2026 en menos de un día, frente a semanas hace unos años.

Lamentablemente, las defensas no se han movido a esa velocidad, y ningún equipo puede parchear un backlog que crece minuto a minuto. Pero solo una fracción mínima de esos CVE se convierte en un ataque real. Se abre un período donde los atacantes actúan libremente y los defensores son impotentes. El problema se agrava: separar las pocas amenazas reales de las decenas de miles que nunca lo serán requiere prueba.

El riesgo vive donde no puedes disparar

Ejecutar pruebas de penetración continuas en lugar de trimestrales reduce esa brecha, pero tiene un límite: un exploit vivo solo puede lanzarse donde sea seguro y exista un exploit utilizable, lo que en la mayoría de las empresas cubre solo entre el 10 y el 15% de la superficie de ataque real. El resto queda sin probar: fallas sin exploit público, sistemas regulados o aislados, y bugs recién divulgados que los atacantes ya usan mientras las herramientas defensivas se ponen al día.

Sin embargo, probar la explotabilidad no requiere un exploit público ni un disparo real contra un sistema crítico. Una cadena es tan fuerte como su eslabón más débil, y no necesitas cargar toda la cadena para saber qué eslabón se rompería. Picus Platform prueba la explotabilidad de ambas formas: con exploit en mano o sin él.

Esta brecha de cobertura es la razón por la que los CISO están moviendo presupuesto de velocidad de parcheo a validación. La guía más reciente presenta el caso completo con números para defenderlo ante un consejo directivo.

Prueba la cadena, no el exploit

Puedes probar si un exploit funciona contra ti sin tener que apretar el gatillo. Cada exploit es una secuencia de pasos dependientes: ejecución inicial, evasión de defensas, escalada de privilegios, robo de credenciales, movimiento lateral. El atacante necesita que cada paso aterrice, y un paso solo aterriza si tu entorno lo permite. Mapea una vulnerabilidad a los pasos que requiere su explotación, luego prueba cada uno contra las defensas que has implementado. Si un paso necesario no tiene una vía viable a través de tus controles, la cadena no se completa y el exploit falla en ese activo, aunque la vulnerabilidad siga ahí. Lo contrario también es cierto: si cada paso requerido tendría éxito, la exposición es genuinamente explotable, y puedes respaldar ese veredicto con evidencia.

Es la lógica de la ingeniería de cohetes: los ingenieros califican el motor, el sistema de combustible y el escudo térmico uno a uno antes de intentar un lanzamiento. Si un componente crítico falla, saben que el vehículo no puede volar sin arriesgar un lanzamiento.

La IA rompió la gestión de vulnerabilidades: el caso del CISO para mover presupuesto a BAS

Un nuevo CVE llega cada 7,4 minutos y la IA convierte avisos en exploits funcionales en menos de un día. Ningún programa de parcheo mantiene ese ritmo. Esta guía muestra por qué los CISO están moviendo presupuesto de velocidad de parcheo a validar lo que sus defensas realmente detienen, con los números para defenderlo ante un consejo.

Ejemplo práctico: Nightmare-Eclipse

El caso de un bug recién divulgado se vuelve concreto cuando una persona publica una serie de zero-days de Windows y el ecosistema criminal los recoge. Eso ocurrió con Nightmare-Eclipse. El código del exploit estuvo público en GitHub en una semana, pero ejecutar el malware real contra tu propio controlador de dominio para saber si aterriza no es una prueba que nadie debería firmar.

Nightmare-Eclipse (también conocido como Chaotic Eclipse, Dead Eclipse) no es un grupo de ransomware ni patrocinado por un estado. Es, según toda la evidencia disponible, un investigador de seguridad con profundo conocimiento interno de Windows y un rencor personal contra Microsoft. A partir de principios de abril de 2026, publicó una serie de exploits zero-day de Windows como divulgaciones no coordinadas, sin cronograma y, en la mayoría de los casos, sin CVE ni parche en el momento de la publicación.

  • BlueHammer: escalada local de privilegios mediante una lectura privilegiada de archivos, explotando una condición de carrera en Windows Defender. Un archivo señuelo EICAR empuja a Defender a un flujo de trabajo de remediación que crea una instantánea de Volume Shadow Copy, exponiendo brevemente los hives SAM, SYSTEM y SECURITY. BlueHammer utiliza devoluciones de llamada de Cloud Files y bloqueos oportunistas para ganar esa carrera, lee los hives, extrae los hashes NTLM locales y escala a SYSTEM.
  • RedSun: el mismo primitivo invertido en una escritura privilegiada de archivos. En lugar de leer el hive SAM, RedSun redirige una escritura a nivel SYSTEM a C:\Windows\System32, sobrescribe TieringEngineService.exe con un binario atacante y luego activa el objeto COM de Storage Tiers Management para ejecutarlo como SYSTEM.
  • UnDefend: una herramienta de interrupción de Defender. Bloquea los archivos de firmas de Defender (mpavbase.vdm, mpavbase.lkg), impide las actualizaciones de definiciones y evita que la base de firmas se recargue al reiniciar el servicio, todo mientras reporta un estado saludable y actualizado a la consola EDR.

Encadenados, el resultado es una máquina sin barrera de privilegios y una pila de seguridad que miente sobre su propia salud.

Replicar comportamiento: construyendo la cadena TTP

Convertir la intrusión en una prueba segura significa transformar cada comportamiento del atacante en una acción discreta que Picus pueda ejecutar y medir sin disparar el exploit real. Varias acciones forman la cadena, pero tres llevan la mayor parte del peso:

  • Crear un nuevo servicio, "Evilsvc" (Ejecución). La escalada de BlueHammer termina registrando un servicio temporal de Windows con CreateService para que su payload se ejecute como SYSTEM. La acción emulada instala un servicio de prueba inofensivo, representando ese paso final de ejecución sin lanzar nada malicioso.
  • Volcar el hive SAM mediante Volume Shadow Copy (Acceso a Credenciales). Este es el primitivo central de BlueHammer. En lugar de tocar el registro bloqueado en vivo, el atacante lee los hives SAM, SYSTEM y SECURITY de la instantánea creada por Defender y descifra los hashes NTLM fuera de línea. La acción emulada reproduce ese acceso VSS al hive, el comportamiento exacto que un control de robo de credenciales debería detectar.
  • Deshabilitar el servicio de Windows Defender (Evasión de Defensas). En la cadena real, UnDefend bloquea las actualizaciones de Defender y evita que su base de firmas se recargue, todo mientras reporta engañosamente un estado saludable a la consola. Picus no necesita ese malware para validar el paso; emula la técnica con unDefender, una acción de la Threat Library que detiene de forma segura el servicio de Windows Defender, probando si tu protección contra manipulaciones se mantiene independientemente de qué herramienta intente evadirla.

Cuando se ejecutan en secuencia contra tus controles en vivo, estos pasos muestran si la cadena completa (acceso SYSTEM, robo de credenciales y Defender cegado) tendría éxito en tu entorno, o si una de tus defensas la rompe primero. Así puedes priorizar parcheo y endurecimiento donde la cadena se completaría, y llegar a esa decisión sin disparar un solo exploit, incluso en sistemas que nunca podrías probar en vivo.

Cubre toda la superficie y sigue probando

La explotación en vivo y el encadenamiento de TTP nunca fueron métodos competidores; encajan de forma simbiótica. Los programas más sólidos ejecutan ambos, y los repiten cada vez que el entorno cambia, porque un control que rompió la cadena el mes pasado puede no sobrevivir al próximo cambio de configuración. La explotabilidad es una pregunta que debe hacerse continuamente, no una casilla que marcar una vez.

Este es el bucle que Picus cierra. Donde existe un exploit y dispararlo es seguro, Autonomous Pentesting detona la cadena real para la prueba más sólida disponible. Donde no lo es (activos restringidos, aislados o críticos para el negocio, o el CVE que cayó esta mañana sin nada weaponizado), el encadenamiento de TTP prueba la explotabilidad por inferencia. Breach and Attack Simulation luego reexplica cada veredicto, para que el "aceptar" del trimestre pasado no se convierta silenciosamente en una brecha este trimestre.

El resultado es una plataforma, una respuesta bajo demanda: "¿Qué se puede explotar realmente aquí, ahora mismo?" Toma el caso que aún está en tu backlog: el próximo lanzamiento de Nightmare-Eclipse sin parche aún, el equipo aislado contra el que nunca lanzarás, el aviso que llegó hace unas horas. Solicita una demostración y observa cómo Picus prueba tu entorno único contra exploits en vivo y cadenas TTP.

Patrocinado y escrito por Picus Software.