PEERSTITCH infecta FortiGate en memoria tras comprometer FortiManager

Unit 42 ha descrito PEERSTITCH, un implante ARM64 que vive solo en la memoria de los firewalls FortiGate y que los atacantes desplegaron después de robar, desde un único FortiManager, la configuración, las credenciales y las claves privadas de más de 500 firewalls. La intrusión arrancó en septiembre de 2024 con CVE-2024-47575 (FortiJump) y escaló a root en FortiOS con CVE-2025-61624, un path traversal cuyo parche publicó Fortinet el 14 de abril de 2026.

Qué ha pasado

El equipo Unit 42 de Palo Alto Networks publicó el 14 de octubre de 2026 el informe de la intrusión, firmado por Daniel Gott y Shawn Westfall. La víctima es un proveedor de servicios gestionados de telecomunicaciones cuya red sufrió una intrusión prolongada que comenzó en septiembre de 2024. El laboratorio sigue al grupo como CL-STA-0954 y lo identifica con UNC5820, el mismo cluster que Mandiant asoció en octubre de 2024 a la explotación de FortiJump.

La entrada fue el FortiManager central del proveedor. Los atacantes registraron en él un FortiGate virtual falso llamado localhost, con número de serie FMG-VMTM23017412, desde la dirección 45.32.41.202 (después cambiada a 198.199.122.22). Nada más registrarse generaron un archivo oculto llamado .tm en el sistema de ficheros del FortiManager y lo exfiltraron. Dentro iban las configuraciones completas de más de 500 FortiGate gestionados, las bases de datos global.db y revinfo.db, un inventario con los números de serie y las IP públicas de cada firewall, mapas de topología y tablas de rutas, credenciales de administración y de VPN SSL cifradas de forma reversible y certificados con sus claves privadas. Esos firewalls protegían la red del propio proveedor y las de sus clientes.

El diagrama con el que Unit 42 abre su informe resume la cadena completa, desde el registro del FortiGate falso en el FortiManager hasta el implante en memoria y el canal de mando y control montado sobre Apache.

Unit 42 lo resume así en sus conclusiones, «That compromise also does not end when the platform is patched» (ese compromiso tampoco termina cuando se parchea la plataforma). El laboratorio aclara que solo examinó el entorno del proveedor, no las redes de sus clientes, y que para ellas describe una exposición de configuración y credenciales, no una intrusión confirmada. Unit 42 tampoco relaciona esta operación con FortiBleed, la campaña de credenciales robadas que el FBI dio por activa el 6 de octubre, aunque las dos terminan con contraseñas y claves de FortiGate en manos ajenas.

Detalles técnicos

FortiJump es una falta de autenticación en el demonio fgfmd de FortiManager, el que atiende el protocolo FGFM por el puerto TCP 541 con el que los FortiGate hablan con su gestor. Fortinet la publicó el 23 de octubre de 2024 en el aviso FG-IR-24-423 con un CVSS de 9,8, la misma puntuación que le asigna NVD, y CISA la incorporó ese mismo día a su catálogo KEV. Cualquier atacante que alcance el puerto 541 puede registrar un dispositivo falso y ejecutar comandos.

CVE-2025-61624 es otra historia. Fortinet la publicó el 14 de abril de 2026 en el aviso FG-IR-26-122 como un path traversal (CWE-22) en el intérprete de la línea de comandos que permite a un administrador con permisos de lectura y escritura crear o borrar ficheros arbitrarios. El fabricante le da un CVSS de 6,0 con vector local, mientras que NVD la puntúa con 6,5 y vector de red. Las dos fuentes coinciden en lo demás y el aviso de Fortinet la marca como explotada. Unit 42 explica el mecanismo. El nombre de un objeto auto-script no se sanea, así que un nombre con secuencias ../ coloca el cuerpo del script en cualquier ruta del sistema de ficheros, y el motor de auto-scripts lo ejecuta como root. Un super_admin de FortiOS trabaja en una consola restringida sin shell, pero los demonios que implementan FortiOS corren como root por debajo, y este fallo salta esa barrera.

La cadena, tal y como la reconstruye Unit 42, tiene siete pasos.

1. Acceso inicial por FGFM. Con FortiJump, el grupo registró el FortiGate falso en el FortiManager y generó el archivo .tm con las configuraciones y claves de los 500 firewalls. Mandiant ya había documentado en 2024 ese mismo fichero en /tmp/.tm en otras víctimas de UNC5820.
2. Reconocimiento desde el gestor. Tras un periodo de latencia, el grupo usó el FortiManager para empujar configuraciones de captura de tráfico a los FortiGate gestionados. Interceptaba tráfico HTTP sin cifrar y once servicios en los puertos TCP 3696 a 3706. En una segunda fase añadió reglas en los firewalls perimetrales para TFTP (UDP 69), RADIUS y su contabilidad (UDP 1812 y 1813) y LDAP (TCP 389), con el fin de capturar credenciales y mapear la red interna.
3. Descifrado de credenciales. Las configuraciones robadas guardaban las contraseñas como texto cifrado reversible. Unit 42 confirmó que recuperó contraseñas de administración y de VPN SSL a partir de esos ficheros.
4. Reentrada por VPN. Con esas credenciales, los atacantes abrieron sesiones de VPN SSL contra los firewalls perimetrales desde su infraestructura (23.240.77.233 y 47.18.167.159) y entraron en los segmentos internos de gestión.
5. Escalada a root. Ya dentro, explotaron CVE-2025-61624 para pasar de administrador de FortiOS a root y colocar el cargador de PEERSTITCH.
6. Implante en memoria. Desplegaron PEERSTITCH en una selección de firewalls.
7. Mando y control e impersonación. Montaron un canal de mando y control abusando del módulo Apache mod_md y después suplantaron al propio FortiManager para descargar configuraciones de más firewalls.

El registro de FortiOS que publica Unit 42 muestra la creación del objeto auto-script con la ruta ../../../../setup, el paso con el que CVE-2025-61624 deja caer el cargador del implante.

PEERSTITCH es un ejecutable ELF de 64 bits para Linux ARM64, escrito en C y enlazado estáticamente contra glibc. Funciona como inyector de un solo uso que parchea la memoria de dos demonios de FortiOS, /bin/miglogd (el de registro) y /bin/iked (el de la VPN). El cargador recorre /proc para localizar sus PID, lee /proc/<pid>/maps para conocer su mapa de memoria, se engancha con ptrace, reserva un buffer de 16 KB con permisos de lectura, escritura y ejecución mediante una llamada mmap y escribe en él la carga a través de /proc/<pid>/mem. Lo que define al implante es dónde vive, no qué técnica usa, y por eso Unit 42 subraya que «leaves no persistent binary on disk, opens no listening ports» (no deja binario persistente en disco ni abre puertos a la escucha) y que tampoco inicia conexiones salientes propias. En su lugar aprovecha el tráfico de procesos legítimos, lo que, en palabras del laboratorio, lo hace «resistant to conventional endpoint and network detection» (resistente a la detección convencional de endpoint y red).

En vez de sockets o ficheros, el implante crea un puente de comunicación en memoria entre miglogd e iked. El diagrama de Unit 42 muestra cómo los ganchos inyectados escanean el tráfico que ya manejan esos demonios, buscan unos marcadores concretos y reenvían las etiquetas al otro proceso a través de un buffer en anillo.

Para esconderse, PEERSTITCH sobrescribe con instrucciones NOP (0xAA0003E0, el MOV X0, X0 de ARM64) tres posiciones fijas del segmento de código de cada demonio y escribe un pequeño salto de 20 bytes que desvía la ejecución hacia su buffer. El mapa de memoria de ese buffer de 16 KB, con sus zonas de código, datos y estado, es la referencia que el propio laboratorio usa para la búsqueda forense.

El canal de mando y control es igual de discreto. Los atacantes crearon un fichero md-acme.conf que redirige el protocolo ACME del módulo Apache mod_md a su propio servidor y mapea el reto DNS-01 al binario /bin/node, de modo que cada renovación de certificado ejecuta Node.js con los parámetros que manda el servidor remoto y levanta un shell inverso por SSH. El ajuste MDRenewMode fuerza al demonio de Apache a repetir ese ciclo sin parar, lo que mantiene el canal abierto.

Para borrar huellas, el grupo ejecutó killall -9 contra miglogd y syslogd antes de actuar, limpió los registros de caída con diagnose debug crashlog clear, eliminó las cuentas de administrador, los grupos de VPN y los objetos auto-script que había creado, y sobrescribió md-acme.conf con contenido señuelo. El cargador, además, borra su propio binario del disco. Unit 42 estima con confianza media que las caídas intermitentes de telemetría en la interfaz de gestión fueron provocadas para cegar a las consolas centrales, posiblemente con CVE-2024-26008 sobre el puerto 541.

El informe aporta los hashes SHA-256 de los artefactos. El del inyector ARM64 es b9fb0b27ddd59b58d3ae53c7227298a3e0de1e6f868b9429ae21533bb9cd1e70. Estos son los indicadores de red y de fichero que conviene cargar en el SIEM y el EDR.

A quién afecta

A dos perfiles distintos. El primero, cualquier organización que exponga a Internet un FortiManager sin parchear o la administración de sus FortiGate, porque ahí empieza la cadena. El segundo, y más incómodo, los clientes de un proveedor gestionado cuyo FortiManager caiga, aunque ellos hayan parcheado todo, porque de ese único equipo salieron las claves y las credenciales de más de 500 firewalls ajenos. Unit 42 lo resume al decir que el compromiso «is not contained by the boundary of the organization that owns it» (no se queda dentro de la frontera de la organización que lo posee).

Quien administre estos equipos en un laboratorio de FortiGate sabe lo fácil que es dejar la gestión abierta por descuido. La consola de FortiManager que Mandiant publicó en 2024 ilustra el primer eslabón, el dispositivo no autorizado que el atacante da de alta para ejecutar comandos.

En España, INCIBE-CERT calificó FortiJump de importancia crítica en su aviso INCIBE-2024-0530, del 24 de octubre de 2024, y Fortinet es un fabricante con mucha presencia en el parque español de perímetro, como ya vimos con la campaña FortiBleed. CVE-2025-61624 llegó con las tandas de parches de Fortinet de abril de 2026. El número exacto de FortiManager expuestos en España no aparece en las fuentes consultadas, así que no lo damos.

Qué hacer

Si gestionas FortiManager o FortiGate, por orden de urgencia.

1. Actualiza FortiManager a 7.6.1, 7.4.5, 7.2.8, 7.0.13, 6.4.15 o 6.2.13 o superior, y FortiOS a 7.6.5 o 7.4.10 o superior, según la rama. Estas versiones cierran CVE-2024-47575 y CVE-2025-61624.
2. Saca de Internet la administración del FortiManager y el puerto FGFM (TCP 541), y trata esa interfaz con el aislamiento de una arquitectura Zero Trust. Si no puedes, restringe con local-in policies qué FortiGate pueden conectarse por 541 y bloquea los dispositivos desconocidos con set fgfm-deny-unknown enable, el workaround que recomienda Fortinet en FG-IR-24-423.
3. Si tu FortiManager pudo estar comprometido, trata como filtradas todas las credenciales y el material criptográfico que custodia, y rótalos en cada FortiGate gestionado, porque el parche no los invalida. Eso incluye contraseñas de administración y de VPN SSL, PSK de VPN, secretos TACACS, LDAP y RADIUS, SNMP y claves de HA.
4. Busca en los FortiManager los indicios que publicó Fortinet, las entradas de registro con «Unregistered device localhost add succeeded» y el serial FMG-VMTM23017412, y los ficheros /tmp/.tm y /var/tmp/.tm.
5. En los FortiGate, caza el implante con las técnicas de Unit 42. Revisa el mapa de memoria de miglogd e iked en busca de regiones anónimas de 16.384 bytes con permisos rwxp, comprueba la integridad del segmento de código en las posiciones que señala el informe, consulta diagnose debug crashlog read por caídas con señal 11 en miglogd, iked o syslogd, y revisa los objetos system.auto-script que contengan secuencias ../.

La regla YARA del informe busca el binario ELF con la plantilla de shellcode o con cuatro o más de sus cadenas operativas. Unit 42 la publica para que la cargues en tu plataforma de análisis.

rule u42_apt_linux_PEERSTITCH_fortigate_implant
{
  meta:
    author = "Unit 42 - PaloAltoNetworks"
    description = "Identifies FortiGate process memory patching implant (ptrace injector targeting miglogd/iked)"
    malware_family = "PEERSTITCH_fortigate_implant"
  strings:
    $s_miglogd = "/bin/miglogd"
    $s_iked = "/bin/iked"
    $s_match_ip = "169.254.0.1"
    $s_cover_path = "/tmp/apache2/conf/md-acme.conf"
    $s_cover_content = "#0 certs managed by ACME"
    $s_proc_mem = "/proc/%d/mem"
  condition:
    uint32(0) == 0x464C457F and (4 of ($s_*))
}

En España, las empresas pueden notificar el incidente a INCIBE-CERT y el sector público al CCN-CERT. Si confirmas el implante, da el firewall por comprometido, aíslalo e investiga el alcance antes de reconstruirlo, porque PEERSTITCH no deja nada en disco que limpiar.

Análisis

Este caso cambia el foco. Durante años hemos tratado el perímetro como la última línea, pero un FortiManager es el gestor de decenas o cientos de perímetros a la vez, y comprometerlo entrega todo el conjunto de golpe. Para un proveedor gestionado, su plataforma de administración es el activo más goloso de la red, y una intrusión ahí se propaga a clientes que han hecho los deberes.

Lo segundo que deja claro el informe es que parchear no cierra el incidente. Las claves y los certificados que salieron del FortiManager siguen siendo válidos hasta que alguien los rota, y mientras tanto el atacante puede volver a hacerse pasar por el gestor. Es el mismo patrón que vimos en FortiBleed y en los zero-days de Ivanti Connect Secure, donde parchear el dispositivo de borde no cerraba del todo el incidente. La lección operativa es incómoda pero simple, tras un compromiso de la plataforma de gestión hay que rotar todo el material de confianza, porque aplicar la actualización no basta.

Sobre la autoría conviene la cautela. Unit 42 dice que parte de la actividad posterior «overlap with intrusions attributed to suspected nation-state actors» (coincide con intrusiones atribuidas a supuestos actores estatales) e identifica el cluster con el UNC5820 de Mandiant, pero ni el laboratorio ni Mandiant ponen nombre ni país. Lo dejamos como lo dejan ellos, un cluster con solapamientos, sin atribución firme. Para entender por qué un implante que vive en memoria da tanta guerra, ayuda repasar las técnicas con las que el malware evade sandboxes y análisis.

Preguntas frecuentes

¿Estoy a salvo si ya parcheé mis FortiGate y mi FortiManager?

El parche evita nuevas explotaciones de CVE-2024-47575 y CVE-2025-61624, pero no revoca lo que ya se robó. Si tu FortiManager estuvo expuesto antes de actualizar, las credenciales y los certificados que custodiaba pueden estar en manos del atacante y seguirán sirviendo hasta que los rotes uno a uno en cada firewall gestionado.

¿Cómo detecto PEERSTITCH si no deja ficheros?

Con búsqueda en memoria, no con antivirus de disco. Unit 42 recomienda inspeccionar el mapa de memoria de los procesos miglogd e iked en busca de una región anónima de 16.384 bytes con permisos de lectura, escritura y ejecución, revisar la integridad del segmento de código de esos demonios y buscar caídas con señal 11 en los registros de diagnóstico. El informe incluye una regla YARA para el binario inyector.

¿Tiene esto que ver con la campaña FortiBleed?

Son operaciones distintas. FortiBleed, que el FBI dio por activa el 6 de octubre de 2026, roba credenciales de VPN SSL de FortiGate a gran escala y las vende a bandas de ransomware. PEERSTITCH es una intrusión dirigida contra un proveedor gestionado que empezó por su FortiManager. Unit 42 no vincula las dos, aunque ambas acaban con secretos de FortiGate expuestos.

¿Qué papel juega CVE-2025-61624 en el ataque?

Es la pieza de escalada. Por sí sola es una vulnerabilidad media que exige ser ya administrador de FortiOS, pero encadenada con las credenciales robadas vía FortiJump permitió a los atacantes pasar de la consola restringida de FortiOS a root en el sistema operativo del firewall y, con ese nivel, instalar el implante. Fortinet la marca como explotada en su aviso del 14 de abril de 2026.

Para profundizar en cómo aislar y vigilar un perímetro bajo esta premisa, nuestro artículo sobre la era post-perímetro y la ciberseguridad del endpoint explica por qué la confianza en un único dispositivo de borde ya no se sostiene.