El martes de parches corrigió 622 fallos. Pero no arregló el movimiento lateral.
El lanzamiento de seguridad de Microsoft en julio de 2026 estableció un nuevo récord. La compañía corrigió 622 fallos, triplicando el récord anterior de 200 que se solucionó apenas un mes antes.
Dos ya estaban bajo ataque, y Microsoft reveló ambos como fallos de día cero:
- CVE-2026-56155 en Active Directory Federation Services. Un atacante que ya tiene acceso local en un servidor AD FS puede acceder a privilegios de administrador. Microsoft le dio un 7,8.
- CVE-2026-56164 en SharePoint Server. Un atacante no autenticado puede escalar privilegios a través de la red, sin necesidad de credenciales. Microsoft le dio una calificación de 5,3, o Moderada, y CISA confirmó la explotación activa ese mismo día.
El volumen de vulnerabilidades es solo un síntoma del problema mayor. A medida que Mythos y otros sistemas de IA pioneros avanzan, la IA está ayudando a los equipos de seguridad a encontrar fallos ocultos más rápido y a una escala mucho mayor. Cada uno de esos fallos acabará siendo parcheado. Pero el parcheo no hace nada con un atacante que ya está dentro de la red.
Microsoft advirtió que este progreso aumentará las demandas operativas para los equipos de seguridad. Más fallos encontrados significan más actualizaciones para evaluar, probar, clasificar y desplegar.
Encontrar vulnerabilidades más rápido es, sin duda, bueno para la seguridad. Pero eso no significa que los equipos puedan arreglar todos los sistemas a la misma velocidad de máquina.
"Los ciclos de parches existentes ya no igualaban el ritmo de descubrimiento y explotación de vulnerabilidades antes de Mythos", dijo Michael Adjei, director de ingeniería de sistemas en Illumio. "Desde luego no lo igualará ahora."
El parche puede cerrar el punto de entrada, pero el verdadero riesgo comienza cuando los atacantes logran un punto de apoyo — cuando encadenan debilidades, roban credenciales, escalan privilegios, se mueven lateralmente y acceden a sistemas críticos.
Esa es una distinción crucial. Una brecha no se define por la vulnerabilidad que usó un atacante para penetrar, sino por la distancia que recorre después. El parche es algo que los defensores no pueden ganar, y ganarlo no cambiaría el resultado de todos modos. La única variable que realmente controlan los defensores es la distancia que puede recorrer un intruso una vez dentro. Y esa distancia se determina por la visibilidad, la segmentación y la contención.
La ventana de parcheo se está cerrando
Como explicamos en La carrera para evitar que la IA convierta vulnerabilidades en brechas, los atacantes tienen mucho menos tiempo para esperar y los defensores mucho menos para responder.
El Reloj del Día Cero muestra que el tiempo medio desde la revelación hasta la explotación confirmada bajó de unos 10 meses en 2021 a solo tres horas en 2026.
Un parche más rápido sigue siendo importante porque reduce la ventana. Pero no la cierra.
Los equipos deben priorizar vulnerabilidades explotadas conocidas, automatizar cuando sea posible y acortar los ciclos de pruebas y aprobaciones para actualizaciones urgentes.
Pero los parches tienen límites.
"Muchas organizaciones tienen deuda heredada", dijo Adjei. "No pueden simplemente derribar sistemas críticos para aplicar un parche. El parche requiere adquisición, pruebas de regresión, comprobaciones de integridad, despliegue y validación."
Esos pasos llevan tiempo. Los sistemas críticos no siempre pueden desconectar, y las actualizaciones deben probar antes de llegar a producción. Parchear más rápido no es toda la solución.
Eso deja un vacío inevitable entre el día que se lanza un parche y el día en que se despliega.
Cuando los atacantes llegan primero
La advertencia de CISA de julio incluía una vulnerabilidad de Microsoft SharePoint ya explotada, lo que plantea una gran pregunta: ¿Qué ocurre cuando un atacante llega al sistema vulnerable antes de que se despliegue un parche?
Un serial de ataques un año antes, la campaña de SharePoint de ToolShell de julio de 2025, muestra lo que puede ocurrir. Los atacantes explotaron fallos de SharePoint en servidores locales y orientados a Internet.
Microsoft identificó tres actores amenazantes con base en China que explotan las vulnerabilidades:
- Tifón de lino: Un grupo de espionaje respaldado por el Estado chino que empleó los fallos de SharePoint para el acceso inicial. Históricamente, el grupo confió en exploits existentes para comprometer organizaciones y robar propiedad intelectual.
- Tifón Violeta: Un grupo de espionaje respaldado por el Estado chino que explotó las fallas de SharePoint contra servidores expuestos. El grupo es conocido por escanear infraestructuras orientadas a Internet, explotar debilidades e instalar webshells.
- Tormenta-2603: Un actor con sede en China que explotó las fallas de SharePoint e intentó robar KeyMachines de SharePoint. Microsoft observó que el grupo empleaba el acceso para desplegar el ransomware Warlock y ya lo vio usar LockBit.
Los reportes de Microsoft muestran que la explotación no se detuvo en el vulnerable servidor SharePoint. Storm-2603 empleó su acceso para descubrimiento, robo de credenciales, movimiento lateral con herramientas como PsExec e Impacket, y finalmente para el despliegue de ransomware.
La campaña de ToolShell muestra por qué explotar una vulnerabilidad es solo el principio. Los defectos daban a los atacantes una vía de entrada. Lo que hicieron tras acceder determinó hasta dónde podría extender el ataque.
Cómo una vulnerabilidad se convierte en acceso
Una vulnerabilidad es solo una debilidad. Los atacantes aún deben encontrar la manera de usarlo.
Un atacante encuentra un fallo y construye o adapta un exploit. Si el exploit funciona, puede permitir que el atacante ejecute código dentro del programa vulnerable. Ese código puede abrir una conexión remota, dando al atacante el control del sistema. A partir de ahí, el atacante puede instalar malware, aumentar privilegios o preparar para avanzar más en el entorno.
No todos los exploits siguen exactamente estos pasos. Algunos ataques emplean credenciales robadas, herramientas integradas o comandos directos en lugar de shellcode y un reverse shell. Pero el objetivo es el mismo: convertir un fallo de software en acceso.
"Hay dos cosas principales que un atacante debe hacer", dijo Adjei. "Primero, explota una vulnerabilidad para ganar un punto de apoyo. Segundo, usa ese punto de apoyo para expandirte por el entorno y alcanzar un objetivo."
Un camino común es el siguiente:
- Descubre la vulnerabilidad. Los atacantes encuentran debilidades mediante ingeniería inversa, fuzzing o análisis de código y dependencias.
- Aprovecha el programa vulnerable. Emplean o adaptan un exploit para aprovechar el fallo. Esto puede permitir la ejecución remota de código, eludir controles de seguridad, aumentar privilegios o exponer información.
- Toma el control del flujo del programa. En algunos ataques, el código shellcode u otro código malicioso permite al atacante controlar cómo se correr el programa vulnerable.
- Establece acceso remoto. El atacante puede abrir una shell inversa u otra conexión a su infraestructura, dándole control remoto del sistema comprometido.
- Despliega malware o exploits adicionales. Con el acceso establecido, el atacante puede instalar malware, aumentar privilegios y preparar para el movimiento lateral.
El punto de apoyo no es el objetivo final
Entrar no significa que los atacantes llegaron a lo que buscaban.
Empiezan aprendiendo cómo funciona el entorno. Pueden buscar usuarios, credenciales, sistemas, servicios y conexiones de red. Ese descubrimiento los ayuda a encontrar un camino más allá del primer sistema comprometido.
Los atacantes pueden entonces mover lateralmente con credenciales robadas, protocolos de confianza, herramientas de administración remota o más vulnerabilidades. También pueden establecer mando y control para mantener el acceso y dirigir el ataque.
El objetivo final puede ser el robo de datos, la interrupción, el control de dominios o el ransomware.
"En ese momento, los defensores deben asumir la intrusión de la violación", dijo Adjei. "Los atacantes rara vez aterrizan directamente en el sistema que quieren."
"Pueden comprometer una interfaz sitio web o un punto final, pero su verdadero objetivo puede ser una base de datos crítica, un servidor de laboratorio, una aplicación de alto valor o un sistema conectado a algo más útil."
El riesgo es a qué pueden llegar los atacantes a continuación
Adjei ve una diferencia clave entre una vulnerabilidad y una brecha.
"La vulnerabilidad es el medio para entrar; El objetivo es a qué pueden llegar a continuación", dijo.
Por eso los puntajes de severidad y el estado del parche no son el marcador adecuado. Una calificación CVSS describe un defecto aislado; No dice nada sobre si el sistema vulnerable está expuesto, a qué puede conectarse o qué activos críticos están a un salto de distancia. Esas son las preguntas que determinan si una intrusión permanece como incidente o se convierte en una brecha.
Parchear cierra el defecto. La contención de brechas detiene la propagación.
El parcheo sigue siendo esencial, pero no siempre puede ocurrir antes de que actúen los atacantes — y no puede eliminar el acceso que ya obtuvieron.
Ahí es donde importan la visibilidad, la segmentación y la contención de brechas. La visibilidad muestra cómo un sistema comprometido se conecta con el resto del entorno. La segmentación limita caminos innecesarios. La contención de brechas ayuda a evitar que los atacantes se adentren más.
"Eso no significa que el parche no sea importante", dijo Adjei. "Significa reducir la capacidad de un atacante para explotar una posición y mover por el entorno mientras se está realizando un parcheo — o cuando aún se desconoce una vulnerabilidad."
Descubre por qué la visibilidad y la segmentación son esenciales para la contención de brechas. Programa hoy una demostración de contención de brechas.
.webp)
.webp)
