:quality(90):no_upscale()){kind=logo}
Cuatro ataques a puertas de enlace en cinco semanas ponen de manifiesto la falta de coordinación entre el ataque y la respuesta
ESTADO: Patrón de explotación activo GRAVEDAD: 8/10 DESTINATARIOS: Responsables de seguridad del Gobierno, la Defensa y las infraestructuras críticas
12 de octubre de 2026
·Blog
·Comunicaciones seguras
:quality(90):no_upscale())
En las últimas cinco semanas, los atacantes han aprovechado vulnerabilidades críticas en cuatro categorías de pasarelas ampliamente implantadas, entre las que se incluyen el correo electrónico, el acceso remoto, el intercambio seguro de contenidos y la conectividad mediante protocolos de tecnología operativa (OT). Tres de los incidentes estuvieron relacionados con vulnerabilidades que podían dar lugar a un control a nivel de root. En conjunto , estos sucesos ponen de manifiesto dos retos de coordinación distintos que la planificación de la respuesta rara vez distingue: la comunicación mientras un atacante puede que ya controle canales de confianza, y la comunicación después de que dichos canales hayan sido aislados intencionadamente para contener el ataque.
¿Qué pasó?
Estas vulnerabilidades generaron dos problemas de coordinación: la comunicación durante un ataque en curso y la comunicación durante el aislamiento destinado a detenerlo.
El 21 de agosto, la CISA añadió la vulnerabilidad de Zimbra CVE-2026-73570 a su catálogo de «Vulnerabilidades explotadas conocidas», después de que unos atacantes la aprovecharan antes de su divulgación pública.1 A finales de agosto, Shadowserver había confirmado 274 instancias comprometidas, en las que los atacantes utilizaban la propia identidad SSH de confianza de Zimbra para desplazarse entre los nodos del clúster,2 lo que ilustra el primer problema: la coordinación a través de un canal que el atacante ya controla.
Tres semanas después, Citrix confirmó dos vulnerabilidades de día cero, CVE-2026-88771 y CVE-2026-88772, ambas con una puntuación de 9,5, que estaban siendo explotadas activamente en los dispositivos NetScaler ADC y Gateway.3 Mandiant y el Grupo de Inteligencia sobre Amenazas de Google atribuyeron la explotación a presuntos actores vinculados a Estados.4 Ambas vulnerabilidades permiten obtener un control total a nivel de root del dispositivo.5
A finales de septiembre, un proveedor de intercambio seguro de contenidos desconectó los sistemas de atención al cliente tras recibir información que indicaba una amenaza creíble.7 El cierre preventivo duró aproximadamente nueve horas e ilustra el tipo de medida de aislamiento que suelen recomendar las directrices de defensa cuando no se puede descartar el riesgo de forma inmediata. Mientras duró esa medida, no estuvo disponible ninguna de las funciones de coordinación que normalmente se llevaban a cabo a través de esos sistemas.
El 2 de octubre, Moxa reveló dos vulnerabilidades en sus pasarelas de protocolo MGate, utilizadas en los sectores de la energía, el agua, la industria manufacturera y la administración pública.6 Una de ellas, con una puntuación de 9,4, permite a un usuario con permisos de solo lectura corromper la memoria del dispositivo, y la otra aún no cuenta con una corrección de firmware. Se trata precisamente de las pasarelas que la CISA y las directrices internacionales recomiendan a los operadores aislar ante el primer indicio de compromiso. Dichas directrices se limitan al perímetro de la red y no ofrecen instrucciones para mantener la coordinación una vez que este se cierra.
En los cuatro casos se repiten las mismas dos deficiencias. Cuando un atacante puede controlar el canal de confianza, como ocurre con Zimbra y NetScaler, la coordinación a través de ese canal conlleva el riesgo de que se realice a la vista del propio atacante. Una vez que una organización aísla un sistema comprometido o en riesgo —tal y como recomiendan las directrices de TI operativa para equipos del tipo Moxa—, cualquier coordinación que dependiera de ese sistema desaparece, a menos que ya exista un canal independiente.
Conclusión | Qué significa | Consecuencias operativas | Pregunta abierta |
Tres de los cuatro incidentes se debieron a vulnerabilidades que permitían obtener, o podían dar lugar a, un control de nivel root sobre la infraestructura crítica de la pasarela.7 | Un atacante con ese nivel de acceso puede supervisar o manipular todo lo que pasa por la pasarela, incluida cualquier coordinación que siga dependiendo de ella. | Utilizar los propios canales del sistema afectado para coordinar una respuesta conlleva el riesgo de que dicha coordinación se realice a la vista del atacante, que es quien los controla. | ¿Cuántas organizaciones que gestionan infraestructuras de pasarela cuentan con un plan de coordinación que contemple la posibilidad de que la propia pasarela pueda verse comprometida, y no solo que no esté disponible? |
Una organización que se enfrentó a una amenaza creíble optó por desconectar una infraestructura crítica durante varias horas, lo que pone de manifiesto cómo las estrategias defensivas habituales pueden generar su propio vacío de coordinación. | La estrategia defensiva habitual, que consiste en aislar el sistema sospechoso, genera su propio vacío de coordinación durante exactamente el tiempo que dura dicho aislamiento. | Una organización que solo cuenta con un canal de coordinación pierde dicho canal en el momento en que toma la medida defensiva adecuada y aísla el sistema en el que opera. | ¿Cuántas organizaciones cuentan con un canal de coordinación independiente y probado, listo para su uso antes incluso de que tengan que aislar un sistema, en lugar de improvisar uno durante ese periodo? |
Las vulnerabilidades de Moxa MGate afectan a las pasarelas de protocolo que, según las directrices conjuntas de la CISA y de organismos internacionales, los operadores de infraestructuras críticas ya tienen la obligación de aislar ante el primer indicio de compromiso. | Las directrices de aislamiento para entornos de TI abordan el límite de la red, pero no dicen nada sobre cómo debe coordinarse el personal una vez que se cierra ese límite. | Los equipos sobre el terreno, el personal de la sala de control y los socios de ayuda mutua necesitan un plan de coordinación que contemple la posibilidad de que sea la propia red OT la que se vea aislada, y no solo la red de TI. | ¿Los planes actuales de respuesta ante incidentes de seguridad informática especifican un canal de coordinación para el periodo de aislamiento, o solo la propia medida de aislamiento? |
Por qué es importante
La antigua Asunción | La realidad actual | Respuesta de BlackBerry |
Si se produce una brecha de seguridad en una pasarela, los canales de comunicación existentes de la organización pueden seguir utilizándose para coordinar la respuesta, ya que la brecha es un problema relacionado con los datos, no con los canales. | Dos de las cuatro vulnerabilidades de la pasarela proporcionaban a los atacantes control de nivel root, lo que significa que el canal existente es el mismo sistema que ahora controla el atacante. | BlackBerry® AtHoc® ofrece un canal de coordinación independiente de la infraestructura objeto de investigación, por lo que la respuesta no tiene por qué pasar por un sistema que ya pueda ser hostil. |
Desconectar un sistema comprometido o en situación de riesgo constituye, por sí misma, una medida defensiva completa. | Una parada preventiva reciente demuestra que, al aislar un sistema, también se aísla cualquier proceso de coordinación que antes dependiera de él durante el periodo de aislamiento. | BlackBerry AtHoc Está diseñado para funcionar específicamente durante los periodos de aislamiento, lo que proporciona a los equipos un canal de coordinación que no depende del sistema que se encuentra aislado. |
Las directrices de aislamiento de la red operativa (OT), que recomiendan desconectar la red en cuanto se sospeche que ha sido comprometida, constituyen por sí solas una respuesta completa. | La revelación de Moxa afecta precisamente al tipo de pasarela OT que estas directrices indican a los operadores que deben aislar, y dichas directrices se limitan al límite de la red, sin ofrecer instrucciones sobre cómo debe coordinarse el personal a partir de ahí. | BlackBerry AtHoc Además, BlackBerry® SecuSUITE® aplica el mismo principio de coordinación fuera de banda a los entornos de tecnología operativa (OT), por lo que aislar la red no implica aislar a las personas que dependen de ella. |
Medidas recomendadas
INMEDIATO | Comprueba el estado de las actualizaciones en todas las plataformas afectadas de tu entorno, incluidas las pasarelas de correo electrónico, la infraestructura de acceso remoto, los sistemas de intercambio seguro de contenidos y las pasarelas de protocolos de tecnología operativa (OT). Considera cualquier instancia sin actualizar y accesible desde Internet como una posible infección activa. |
INMEDIATO | Averigua si tu organización dispone de un canal de coordinación que siga estando disponible en caso de que tu correo electrónico o tu sistema de acceso remoto queden aislados sin previo aviso. |
A CORTO PLAZO | Desarrollar y probar de forma explícita un canal de coordinación fuera de banda para ambos escenarios: el funcionamiento mientras un sistema de confianza pueda estar comprometido y el funcionamiento una vez que dicho sistema haya sido aislado deliberadamente. |
A CORTO PLAZO | Ampliar la planificación del aislamiento y la coordinación específicamente a los entornos de tecnología operativa (OT), dado que las directrices actuales sobre aislamiento de la OT se centran en el perímetro de la red, pero no abordan qué ocurre con la coordinación una vez que este se cierra. |
EN CURSO | Considera el tiempo que un canal de coordinación necesita para seguir funcionando durante un periodo de aislamiento —ya sean horas o más— como una hipótesis de planificación y no como algo secundario. |
Puesto en BlackBerry
Cada uno de estos cuatro incidentes acaba resolviéndose, ya sea corrigiendo la vulnerabilidad o aislando el sistema afectado. Ninguna de estas medidas restablece por sí sola la coordinación. Un atacante con acceso de root a una pasarela de confianza puede vigilar todo lo que pasa por ella, y un sistema desconectado para detener a ese atacante deja de cumplir su función de coordinación. Ambos escenarios apuntan al mismo requisito: un canal diseñado para seguir funcionando independientemente de que el sistema esté comprometido o aislado, ya que el momento en que una organización más necesita ese canal puede ser precisamente cuando el habitual no está disponible.
Referencias:
1. Los atacantes aprovechan una vulnerabilidad de SNMP en Zimbra para ejecutar código de forma remota sin autenticación (The Hacker News, cobertura de la explotación activa de CVE-2026-73570, 20 de agosto de 2026).
2. Los hackers han violado más de 270 servidores Zimbra en una serie de ataques que aún continúan (BleepingComputer, cobertura de las intrusiones en servidores Zimbra registradas por Shadowserver, 25 de agosto de 2026).
3. Advertencia: dos vulnerabilidades de día cero sin parchear en Citrix NetScaler que permiten la ejecución remota de código (RCE) y que están siendo explotadas activamente (The Hacker News, «Citrix confirma la explotación de vulnerabilidades de día cero en NetScaler», 27 de septiembre de 2026).
4. Defensa contra la explotación activa de los dispositivos ADC y de puerta de enlace de Citrix NetScaler (Blog de Google Cloud, escrito por Mandiant, Google Threat Intelligence Group y Mandiant Services; análisis y recomendaciones defensivas relacionadas con la explotación activa de las vulnerabilidades CVE-2026-88772 y CVE-2026-88771 de Citrix NetScaler, 29 de septiembre de 2026).
5. Las vulnerabilidades de día cero de Citrix NetScaler ponen de relieve el riesgo recurrente de acceso root (TechTimes, análisis de los patrones recurrentes de vulnerabilidades de acceso de root en NetScaler, 30 de septiembre de 2026).
6. Las vulnerabilidades de Moxa MGate ponen en riesgo las pasarelas de protocolos industriales (SecurityOnline, cobertura y análisis de las vulnerabilidades de Moxa MGate CVE-2026-86325 y CVE-2026-86326, incluyendo los productos afectados, los niveles de gravedad y las recomendaciones de mitigación. 2 de octubre de 2026).
7. Kiteworks corrige una vulnerabilidad de inyección de código de máxima gravedad (BleepingComputer, informó sobre CVE-2026-54154, que afecta a Kiteworks Email Protection Gateway (EPG), 1 de octubre de 2026).
:quality(90):no_upscale())