Una sola intrusión puede abrir la puerta a toda una red

Las organizaciones invierten recursos en proteger sus firewalls, controlar los accesos remotos y supervisar el tráfico que circula por sus redes. Sin embargo, existe una pieza que puede concentrar un nivel de acceso especialmente sensible: la plataforma desde la que se administran esos dispositivos.

Cuando un sistema centralizado gestiona decenas o cientos de firewalls, su función va mucho más allá de simplificar tareas operativas. También mantiene configuraciones, relaciones de confianza, información de red y datos necesarios para administrar los dispositivos conectados.

Esto lo convierte en un objetivo de alto valor para los atacantes. Comprometer esa plataforma puede proporcionar información útil para extender una intrusión hacia otros segmentos de la infraestructura.

Un caso reciente investigado por Palo Alto Networks Unit 42 ilustra este escenario. Los investigadores analizaron una intrusión prolongada contra un proveedor de servicios gestionados de telecomunicaciones, en la que los atacantes obtuvieron acceso inicial a un dispositivo FortiManager mediante la explotación de CVE-2024-47575, una vulnerabilidad conocida como FortiJump.

A partir de ese acceso, extrajeron un archivo que contenía configuraciones, información criptográfica y bases de datos relacionadas con más de 500 firewalls FortiGate administrados. Posteriormente, utilizaron parte de esa información para realizar reconocimiento, establecer sesiones VPN no autorizadas y desplegar mecanismos de acceso persistente.

Durante las fases posteriores de la intrusión, los investigadores identificaron PEERSTITCH, un malware diseñado para operar en la memoria de los dispositivos FortiOS y modificar el comportamiento de procesos legítimos.

El caso deja una lección importante para las organizaciones: la seguridad de una infraestructura también depende de la protección de los sistemas que la administran.

¿Qué es PEERSTITCH y por qué resulta difícil de detectar?

PEERSTITCH es un implante malicioso para sistemas Linux ARM64 que fue identificado durante la investigación de Unit 42. Su característica más relevante es que opera directamente en la memoria de procesos legítimos de FortiOS, en lugar de depender de un archivo malicioso que permanezca almacenado en el dispositivo.

El malware utiliza técnicas de inyección de código para intervenir dos procesos del sistema: miglogd, relacionado con el registro de actividad, e iked, asociado con las funciones de negociación de VPN IPsec.

Al modificar el comportamiento de estos procesos, PEERSTITCH crea un mecanismo de comunicación encubierto entre ellos. De esta forma, puede reconocer determinados patrones dentro del tráfico que ya están procesando y alterar el tratamiento de sesiones VPN que coinciden con las condiciones implantadas por los atacantes.

La investigación señala que el implante no necesita mantener un ejecutable persistente en el disco, abrir puertos de escucha ni iniciar sus propias conexiones de red salientes para realizar esa comunicación. En su lugar, aprovecha procesos y tráfico legítimos del dispositivo.

Esta característica dificulta su detección mediante mecanismos que dependen principalmente de archivos conocidos, conexiones externas sospechosas o indicadores tradicionales de compromiso.

Sin embargo, operar en memoria no significa ser completamente invisible. La integridad de los procesos, los permisos de memoria, los registros de actividad y los cambios anómalos en las configuraciones pueden proporcionar señales útiles para una investigación especializada.

El desafío para los equipos de seguridad consiste en reconocer comportamientos que se apartan del funcionamiento esperado del dispositivo, incluso cuando no existe un archivo malicioso evidente que analizar.

La cadena de ataque: del acceso inicial al control de la infraestructura

Para comprender el alcance del incidente, es necesario distinguir las distintas etapas observadas por los investigadores.

La primera estuvo relacionada con el compromiso de FortiManager mediante CVE-2024-47575. Esta vulnerabilidad permitió a los atacantes obtener acceso al sistema centralizado de administración y extraer información de los dispositivos gestionados.

Entre los datos obtenidos se encontraban configuraciones de firewalls, direcciones IP públicas, mapas de topología, tablas de enrutamiento, credenciales y material criptográfico asociado a las relaciones de confianza entre los equipos.

Esta información puede proporcionar a un atacante una visión detallada de la infraestructura, reducir el trabajo necesario para identificar objetivos y facilitar el acceso a otros componentes de la red.

Posteriormente, los atacantes utilizaron credenciales y material de confianza para establecer sesiones VPN no autorizadas y continuar sus actividades. La investigación también documentó acciones orientadas a interceptar tráfico, desplegar puertas traseras y manipular dispositivos administrados.

En una etapa posterior, los investigadores observaron la explotación de CVE-2025-61624 para elevar privilegios y desplegar PEERSTITCH. Esta vulnerabilidad permite a un atacante con privilegios administrativos realizar operaciones arbitrarias de escritura o eliminación de archivos mediante argumentos especialmente diseñados en el intérprete de comandos de los productos afectados.

La diferencia entre ambas vulnerabilidades es relevante: CVE-2024-47575 estuvo asociada con el acceso inicial a FortiManager, mientras que CVE-2025-61624 se utilizó posteriormente para facilitar la ejecución de acciones privilegiadas y el despliegue del implante.

Por tanto, el incidente no debe interpretarse como una única vulnerabilidad que, por sí sola, permitió realizar todas las acciones observadas. Se trató de una cadena de ataque en la que el acceso inicial, la extracción de información, el uso de credenciales y la explotación posterior desempeñaron funciones diferentes.

El riesgo de centralizar la administración de cientos de dispositivos

La administración centralizada ofrece ventajas importantes: permite aplicar políticas, mantener configuraciones coherentes y gestionar infraestructuras distribuidas desde un punto común.

El riesgo aparece cuando esa concentración de capacidades no está acompañada por controles proporcionales a su impacto.

En el incidente investigado, la información extraída de FortiManager incluía configuraciones y datos relacionados con más de 500 firewalls FortiGate. Estos dispositivos protegían tanto la infraestructura del proveedor como redes de sus clientes.

Esto no significa que los más de 500 firewalls hayan sido comprometidos individualmente. La investigación describe la exposición de información de configuración y las actividades observadas en el entorno afectado, pero no confirma una intrusión en todas las redes de clientes cuyos dispositivos estaban administrados por el proveedor.

Aun con esa distinción, el caso evidencia el potencial de propagación de un compromiso de gestión. Una plataforma central puede concentrar información suficiente para facilitar ataques posteriores contra múltiples sistemas, incluso cuando cada dispositivo cuenta con sus propias medidas de protección.

Para los proveedores de servicios gestionados, este riesgo adquiere una dimensión adicional: la seguridad de su infraestructura administrativa está directamente relacionada con la protección de los entornos que operan para terceros.

Por eso, los sistemas de administración requieren controles de acceso estrictos, segmentación de red, supervisión independiente y una revisión continua de las relaciones de confianza que mantienen con los dispositivos gestionados.

Qué medidas pueden ayudar a reducir la exposición

La respuesta ante incidentes como este requiere una combinación de prevención, detección y recuperación. Aplicar una actualización es un paso esencial, pero puede resultar insuficiente si una plataforma ya ha sido comprometida y sus credenciales o relaciones de confianza han quedado expuestas.

Mantener los dispositivos actualizados. Fortinet corrigió CVE-2025-61624 en abril de 2026. Las organizaciones deben revisar los avisos oficiales del fabricante, identificar las versiones afectadas y aplicar las correcciones correspondientes a cada producto. También es importante verificar el estado de FortiManager y de los demás componentes involucrados en la administración.

Aislar las interfaces de gestión. El acceso administrativo debe limitarse a redes, equipos y usuarios expresamente autorizados. Evitar la exposición innecesaria de interfaces de administración a Internet y aplicar controles de acceso basados en el principio de mínimo privilegio reduce las oportunidades de acceso no autorizado.

Revisar credenciales y material criptográfico. Cuando existe evidencia de compromiso, es necesario evaluar qué credenciales, certificados y claves pudieron quedar expuestos. La rotación debe planificarse para los elementos afectados, junto con la revisión de sesiones VPN, cuentas administrativas y relaciones de confianza entre plataformas y dispositivos.

Supervisar los cambios de configuración. La creación de cuentas inesperadas, las modificaciones de políticas, los cambios en objetos de automatización y las alteraciones de la configuración de VPN pueden ayudar a identificar actividad sospechosa. Estos eventos deben correlacionarse con los registros de administración y con la actividad de red.

Investigar comportamientos anómalos en los dispositivos. Cuando existe sospecha de un implante residente en memoria, una revisión convencional de archivos puede no ser suficiente. La investigación puede requerir análisis especializado de memoria, integridad de procesos, telemetría disponible y registros del sistema. En dispositivos de seguridad, estas acciones deben realizarse mediante procedimientos compatibles con el fabricante y con la continuidad operativa.

Preparar una respuesta que contemple a terceros. Los proveedores que administran infraestructura de clientes necesitan procedimientos para determinar el alcance de una exposición, notificar a las partes afectadas cuando corresponda y coordinar la recuperación. La respuesta debe contemplar tanto la plataforma central como las relaciones de confianza y los dispositivos que dependen de ella.

Estas medidas no garantizan que una intrusión sea imposible, pero ayudan a limitar el alcance de un compromiso, detectar cambios no autorizados y recuperar el control de la infraestructura de forma más ordenada.

Conclusión: proteger la infraestructura también significa proteger su administración

El caso PEERSTITCH demuestra cómo una intrusión puede evolucionar desde el compromiso de una plataforma de gestión hasta el uso de credenciales, la manipulación de dispositivos y la implantación de malware diseñado para operar dentro de procesos legítimos.

Su relevancia no reside únicamente en la sofisticación técnica del implante. También está en la cantidad y sensibilidad de la información que puede concentrarse en un sistema encargado de administrar otros dispositivos.

Para las organizaciones, esto implica revisar la seguridad de sus plataformas de gestión con el mismo rigor que aplican a sus firewalls, sistemas críticos y accesos remotos. La segmentación, el mínimo privilegio, la actualización continua, la supervisión y la gestión de credenciales deben formar parte de una estrategia integrada.

En entornos administrados por terceros, además, es fundamental comprender qué dispositivos dependen de cada plataforma y cómo se puede contener una intrusión sin perder visibilidad sobre la infraestructura.

La seguridad de una red no depende solamente de los dispositivos que la protegen, sino también de quién puede administrarlos, qué información concentran y cómo se supervisan sus relaciones de confianza.


Fuentes y referencias

Diego Soto