Un parche cierra el agujero, pero no dice nada de los días anteriores
Cuando se ataca un fallo antes de que exista una corrección, instalar la corrección te dice que el agujero está cerrado. No te dice si alguien ya entró por él.
Ilustración conceptual de los 47 días transcurridos entre el primer ataque y la divulgación en el caso de BeyondTrust. Un parche cierra el fallo, pero no demuestra que el dispositivo esté limpio.
Un dispositivo perimetral es un sistema situado en el borde de tu red y expuesto a internet. Las pasarelas VPN, las herramientas de soporte remoto, las pasarelas de correo electrónico, los firewalls y los balanceadores de carga son dispositivos perimetrales. Son accesibles desde fuera, tienen accesos con muchos privilegios y muchos equipos apenas pueden ver lo que ocurre dentro de ellos.
Una vulnerabilidad de día cero (zero-day) es un fallo que los atacantes usan antes de que el fabricante haya publicado una corrección. Este artículo usa dos casos recientes para mostrar qué resuelve un parche y qué no. Termina con un método que puedes seguir con cualquier dispositivo perimetral explotado y con una regla para decidir cuándo reconstruirlo en lugar de confiar en él.
Por qué vale la pena atacar los dispositivos perimetrales
Un dispositivo perimetral es un buen objetivo por tres razones sencillas. Está expuesto a internet por diseño. A menudo guarda credenciales almacenadas u ocupa una posición de confianza dentro de tu red. Y suele ejecutar un sistema operativo cerrado, así que no es fácil instalar en él tus propias herramientas de supervisión.
Ese último punto importa más de lo que parece. Si no puedes inspeccionar el dispositivo por dentro, las comprobaciones del fabricante y tus registros (logs) se convierten en tus únicas pruebas. Ambos pueden fallar, como muestran los dos casos siguientes. Nuestro artículo anterior sobre qué significa una ventana de intrusión de 72 minutos (en inglés) explica por qué importa tanto el tiempo que pasa antes de que te des cuenta.
Caso 1: Ivanti Connect Secure, donde parte de la cadena sigue abierta
Ivanti Connect Secure es una pasarela VPN. El 13 de octubre, Ivanti publicó un aviso de seguridad sobre CVE-2026-104935, un fallo que permite a un atacante eludir la autenticación y ejecutar comandos en el dispositivo. CISA lo añadió ese mismo día a su catálogo Known Exploited Vulnerabilities. Ese catálogo es una lista de fallos que CISA ha confirmado que se están usando en ataques reales, y las agencias federales deben corregirlos antes de una fecha fijada, que en este caso era el 16 de octubre.
La empresa de seguridad Volexity informó de que el atacante empezó a usar el fallo el 3 de octubre contra el appliance de un cliente. Volexity describió ese appliance como actualizado con todos los parches: ejecutaba 22.8R2.4, la compilación más reciente disponible antes de la corrección. Se trata de un único incidente, así que demuestra que el fallo se usó antes de la divulgación. No nos dice hasta qué punto se usó, e Ivanti solo afirma que se vio afectado un número limitado de clientes. Entre las versiones corregidas están 22.8R2.5, 25.1.1.2, 25.1.3.0 y 25.1.3.1, según el resumen del aviso publicado por Rapid7.
Dos detalles hacen de este caso una buena lección. En primer lugar, la cadena de ataque tiene más de un paso. Volexity informó de un paso independiente de escalada de privilegios, que eleva el acceso a root y que la corrección no cubría en el momento de la divulgación. Según la cobertura del informe, no tiene un identificador CVE público. Volexity dijo que la corrección llegaría en una versión futura «en las próximas semanas». Así que, por ahora, «con parches» solo es verdad en parte.
En segundo lugar, el ataque dejó pocos rastros. Volexity no encontró ninguna puerta trasera ni ninguna web shell. El código del exploit y el paso a root se ejecutaron sobre todo en memoria, y los datos de configuración alterados se restauraron después, por lo que la Integrity Checker Tool de Ivanti no detectó los cambios. Ivanti sigue recomendando a sus clientes que ejecuten la herramienta con regularidad. Volexity también descubrió que el atacante eliminó de forma selectiva entradas de los registros de depuración y de auditoría del appliance, y afirma que no está del todo establecido hasta qué punto funcionó esa limpieza. Ivanti afirma que en el momento de la divulgación solo había disponibles unos indicadores de compromiso (IoC) limitados, y Volexity publicó algunos del único incidente que investigó.
La lección es sencilla. Un número de versión corregido te dice qué ejecuta el dispositivo ahora. No puede decirte qué ocurrió antes, y un resultado limpio de la herramienta de comprobación del fabricante o de los propios registros del dispositivo no basta por sí solo.
Texto alternativo accesible para esta figura
Ambos fallos se explotaron antes de divulgarse. La línea de tiempo va del 29 de agosto al 15 de octubre de 2026 en una misma escala, con marcas el 29 de agosto, el 29 de septiembre y el 15 de octubre.
BeyondTrust Remote Support: la explotación empezó el 29 de agosto, se publicó un parche el 8 de octubre y el fallo se divulgó el 15 de octubre. Son 47 días de explotación antes de la divulgación.
Ivanti Connect Secure: la explotación empezó el 3 de octubre y el fallo se divulgó el 13 de octubre, 10 días después. El paso de escalada de privilegios a root seguía sin parche en el momento de la divulgación.
Caso 2: BeyondTrust Remote Support, donde la búsqueda de rastros empieza en agosto
BeyondTrust Remote Support permite al personal de soporte controlar las computadoras de otras personas. Guarda credenciales en un almacén (vault) para que el personal pueda iniciar sesión en sistemas en nombre de un usuario, lo que lo hace valioso para un atacante. CVE-2026-102764 es un fallo de carga de archivos sin autenticación: alguien de fuera puede colocar un archivo en el dispositivo sin iniciar sesión. Afecta a las versiones hasta la 26.2.3.
BeyondTrust afirma que el primer ataque se produjo el 29 de agosto. Publicó el parche el 8 de octubre, con sus clientes SaaS actualizados automáticamente, y divulgó el fallo el 15 de octubre. Según nuestro cálculo, son 47 días entre el primer ataque y la divulgación. BeyondTrust dice que tiene constancia de dos clientes afectados, así que aquí también se trata de un número reducido de casos conocidos.
Google atribuye la actividad a un grupo al que llama ARMORY CASTLE, que según Google antes se rastreaba como UNC5221, y lo describe como un presunto actor de espionaje vinculado a China. Es la valoración que hace Google de las pruebas, no una conclusión que podamos confirmar nosotros.
Lo útil es lo que hicieron los atacantes después de entrar. Según Google, instalaron una web shell unos once minutos después de la primera solicitud del exploit. Crearon una puerta trasera con privilegios de root, intentaron recopilar credenciales del almacén, añadieron un script de persistencia que sobrevive a un reinicio y borraron los registros del appliance, del servidor web y de la aplicación. Google afirma que una persistencia de este tipo también sobrevive a un restablecimiento de la configuración.
De ahí se deriva el consejo de Google. Conserva las pruebas antes de cambiar nada. Si la vulneración está confirmada o no puedes descartarla, vuelve a desplegar desde una imagen limpia y con todos los parches, porque los clientes no pueden auditar el sistema de archivos del propio appliance. Rota las credenciales solo después del parche o de la reconstrucción, ya que las credenciales nuevas introducidas en un dispositivo que el atacante sigue controlando también quedan expuestas.
Recopila los registros de los sistemas que rodean al dispositivo, como el firewall y el proxy inverso, porque los registros del propio dispositivo pueden haberse borrado. BeyondTrust hace la misma advertencia: las copias guardadas fuera del appliance suelen ser el único registro que queda.
La lección: tu ventana de investigación empieza en la primera fecha de explotación, no en la fecha en que se publicó el parche. Los registros del propio dispositivo son pruebas débiles si el atacante tuvo el control.
Los casos menores dejan lecciones menores
Un primer parche no siempre es completo. AhsayCBS, un producto de servidor de copias de seguridad, tenía dos fallos que los atacantes encadenaron: una elusión de la autenticación y una inyección de comandos que se ejecuta como SYSTEM. Help Net Security informó de que las correcciones anteriores estaban incompletas y de que las compilaciones corregidas son la v10.3.4.45 y la v9.15.2.70. Si aplicaste una compilación anterior y pasaste a otra cosa, comprueba que tienes la corregida. Según se informó, los atacantes instalaron web shells y criptomineros en servidores expuestos, y Huntress documentó los ataques el 8 de octubre.
Otros fallos perimetrales recientes muestran por qué los números exactos de compilación y la rapidez siguen importando, incluso cuando no hay indicios de una vulneración anterior. Citrix es un caso recurrente, y nuestro artículo sobre los zero-days de NetScaler de septiembre (en inglés) trata los fallos anteriores.
| Producto | Qué ocurrió | Qué conclusión sacar |
|---|---|---|
| Citrix NetScaler (CVE-2026-107406) | Un fallo crítico de desbordamiento de memoria en configuraciones SAML, con una puntuación CVSS v4 de 9.5, publicado el 8 de octubre. Corregido en 14.1-73.46 y 13.1-64.29 o posteriores. El boletín indica como afectadas de la 14.1-73.37 a la 14.1-73.41 y de la 13.1-64.23 a la 13.1-64.28, y no dice si el fallo se está explotando. | Una compilación reciente puede seguir estando afectada. Compara tu compilación exacta con el boletín más reciente. |
| Cisco Secure Email Gateway (CVE-2026-76519) | CVSS 9.8, sin solución alternativa, explotado. Corregido en AsyncOS 16.5.0-780 en la rama 16.5. CISA lo incluyó en su catálogo el 14 de octubre. El aviso de Cisco dice que un atacante con acceso root puede ocultar pruebas en el dispositivo, así que revisa los registros del firewall y de la red fuera de él y conserva los datos forenses antes de actualizar. Para un appliance virtual vulnerado, indica que hay que desplegar una VM nueva con una versión corregida sin importar la configuración antigua. | El propio fabricante recomienda primero las pruebas, después la reconstrucción y después las credenciales nuevas. |
| Palo Alto PAN-OS (CVE-2026-0322) | CVSS 8.6, se ha observado una «explotación muy limitada», sin solución alternativa conocida. Afecta a la interfaz de administración, y Palo Alto recomienda limitar el acceso a direcciones internas de confianza o a un jump box. | Mantén las interfaces de administración fuera de internet. |
Un método que puedes seguir
Cuando un dispositivo perimetral que administras aparece en un aviso sobre un fallo explotado, sigue estos pasos en orden.
- Aplica el parche o aísla el dispositivo. Instala la versión corregida. Si todavía no existe una corrección, restringe el acceso al dispositivo y sigue la mitigación del fabricante.
- Conserva las pruebas antes de cambiar nada. Haz una instantánea o una copia del disco y de la memoria si puedes. Recopila los registros del firewall, del proxy y de cualquier servidor de registros.
- Averigua la primera fecha de explotación. Lee los informes del fabricante y de los investigadores. Tu ventana de búsqueda va desde esa fecha hasta hoy.
- Busca hacia atrás en esa ventana. Revisa los registros guardados fuera del dispositivo. Busca los indicadores que publicaron los investigadores. Trata cualquier hueco en el reenvío de registros como una señal de alerta.
- Decide: confiar o reconstruir. Consulta la regla que aparece a continuación.
- Rota las credenciales cuando el dispositivo esté limpio. Empieza por las propias cuentas de administrador del dispositivo. Después rota todo lo que almacenaba o gestionaba como intermediario, incluidos los secretos de API, las cuentas de servicio y cualquier contraseña que se haya escrito en él.
Cuándo reconstruir y cuándo confiar
Reconstruir todos los dispositivos después de cada aviso no es realista. Esta es la regla que proponemos. Es nuestro criterio, basado en las indicaciones de Google sobre BeyondTrust, y no un estándar publicado.
Reconstruye desde una imagen limpia si se confirma que el dispositivo está vulnerado. Reconstruye también si la explotación empezó antes de la fecha en que aplicaste el parche y no puedes demostrar que no se llegó a tu dispositivo. La segunda condición importa sobre todo en los appliances que no puedes inspeccionar por dentro.
Puedes confiar razonablemente en el dispositivo tras aplicar el parche si se cumplen tres condiciones. No estuvo expuesto a internet durante la ventana, o tienes registros independientes que no muestran actividad coincidente. Ni el fabricante ni los investigadores informan de accesos que sobrevivan al parche. Y rotas las credenciales que guardaba el dispositivo.
Lo que sabemos y lo que no
| Etiqueta | Afirmación |
|---|---|
| Hecho | CISA incluye como explotados el fallo de Ivanti (13 de octubre) y el de BeyondTrust (16 de octubre). BeyondTrust confirmó la explotación desde el 29 de agosto y publicó un parche el 8 de octubre. |
| Informe de investigadores | Volexity afirma que el ataque a Ivanti se ejecutó sobre todo en memoria, eludió el comprobador de integridad y eliminó entradas de los registros. Google afirma que los atacantes de BeyondTrust borraron registros e instalaron mecanismos de persistencia. |
| Nuestra inferencia | Cualquier appliance expuesto durante una ventana de explotación debe tratarse como posiblemente alcanzado hasta que se demuestre lo contrario. |
| Desconocido | Si Ivanti ya ha corregido el paso de escalada de privilegios. Cuántas organizaciones se vieron afectadas más allá de los casos que describen los fabricantes. |
¿Hasta qué punto deberías aprender esto?
Conocer: La mayoría de los desarrolladores y responsables solo necesitan la idea. Un parche cierra un fallo, pero no deshace una intrusión. Pregunta a tu equipo de seguridad si los fallos explotados se revisan retrocediendo hasta la primera fecha de ataque.
Usar: Si administras VPN, pasarelas, herramientas de soporte remoto o servidores de copias de seguridad, necesitas el método anterior. Deberías poder leer un aviso, encontrar la primera fecha de explotación, conservar las pruebas, revisar los registros guardados fuera del dispositivo y decidir si hay que reconstruirlo.
Dominar: Si eres responsable de la respuesta a incidentes o de la arquitectura, también tienes que diseñar pensando en esto. Reenvía los registros de cada dispositivo perimetral fuera de él casi en tiempo real. Mantén las interfaces de administración fuera de internet. Ten imágenes limpias y procedimientos de restauración probados para que una reconstrucción lleve horas, no semanas.
Qué puedes ignorar por ahora
No necesitas memorizar nombres de malware, nombres de grupos ni rutas de archivos de estos informes. Cambian con cada incidente, y los indicadores publicados son útiles para un equipo de búsqueda de amenazas, pero no para un lector general. Lo que perdura es la forma de la respuesta.
Un siguiente paso práctico
Elige un dispositivo perimetral que administres y responde a tres preguntas. ¿Adónde van sus registros y se guardan en algún lugar al que no pueda llegar un atacante que esté en el dispositivo? ¿Con qué rapidez podrías reconstruirlo desde una imagen limpia? ¿Qué credenciales guarda? Si hoy no puedes responder a las tres, ese hueco es más importante que el próximo parche.
Para profundizar
- Volexity sobre la cadena de zero-days de Ivanti Connect Secure, para los pasos del atacante, la manipulación de los registros y los indicadores.
- La publicación de Ivanti sobre su actualización de seguridad de octubre de 2026, para la declaración del fabricante y el enlace a su aviso.
- Rapid7 sobre CVE-2026-104935 de Ivanti Connect Secure, para las versiones corregidas y la inclusión en el catálogo de CISA.
- Aviso de seguridad BT26-05 de BeyondTrust y su entrada de blog, para las versiones, las fechas y el parche.
- Google Threat Intelligence: ARMORY CASTLE exploits BeyondTrust, para los pasos de la intrusión y las indicaciones sobre reconstrucción y rotación.
- Aviso de Cisco sobre CVE-2026-76519, para la comprobación de vulneración y los pasos de recuperación.
- Aviso de Palo Alto Networks sobre CVE-2026-0322, para las versiones corregidas y las mitigaciones parciales.
- Boletín CTX697191 de Citrix, para las compilaciones exactas de NetScaler afectadas y corregidas.
- Help Net Security sobre las incorporaciones de CISA, para los detalles de Ahsay y las fechas del catálogo KEV.
- Catálogo Known Exploited Vulnerabilities de CISA, para el estado actual y los plazos de cada fallo.
Los datos de este artículo se comprobaron el 18 y el 19 de octubre de 2026. Los fabricantes pueden publicar nuevas correcciones y detalles, así que consulta las fuentes anteriores antes de actuar.