Unit 42 vincula intrusión en MSP de telecomunicaciones con PEERSTITCH en memoria y Fortinet

Investigadores de Palo Alto Networks Unit 42 han vinculado una intrusión dirigida contra un proveedor de servicios gestionados de telecomunicaciones a una cadena de ataques que culminó con la implantación de un malware residente en memoria para Linux ARM64 llamado PEERSTITCH. Según el análisis, los atacantes combinaron el compromiso previo de una consola de administración centralizada con la explotación de una falla en el intérprete de comandos de productos Fortinet para insertar código directamente en la memoria de procesos legítimos, evitando así artefactos en disco y conexiones de red evidentes.

Hechos confirmados: Unit 42 describe que la campaña, rastreada como CL-STA-0954 / UNC5820, comenzó con el aprovechamiento de la vulnerabilidad conocida como FortiJump (CVE-2024-47575) contra un FortiManager en septiembre de 2024, lo que permitió la exfiltración de configuraciones, bases de datos y material criptográfico de más de 500 FortiGate gestionados. Posteriormente los atacantes abusaron de una vulnerabilidad de path traversal (CVE-2025-61624, puntaje CVSS 5.4) en el intérprete de comandos de varios productos Fortinet —parcheada por Fortinet en abril de 2026— para desplegar PEERSTITCH. El informe técnico de Unit 42 resume estas observaciones y las técnicas de implantación; puede consultarse en el sitio de Unit 42 para detalles adicionales https://unit42.paloaltonetworks.com/. Fortinet publicó avisos y parches en su portal de seguridad de productos https://www.fortinet.com/support/product-security/security-advisories.

Técnicamente, PEERSTITCH es un binario nativo ARM64 escrito en C que se despliega mediante un orquestador que descarga varios componentes (módulos JavaScript/WebAssembly y un “core” nativo). La etapa crítica no deja binarios persistentes: un inyector nativo se adjunta a dos demonios de FortiOS —miglogd e iked— y modifica su espacio de memoria en ejecución. El método reportado usa ptrace con interrupción de ejecución (PTRACE_INTERRUPT), asigna páginas ejecutables, escribe código malicioso y redirige la ejecución del proceso hacia ese código inyectado. El resultado es una puerta de comunicación encubierta entre procesos legítimos, que permite a los atacantes marcar y reconocer sesiones VPN específicas para saltarse controles y mantener acceso discreto. Para contexto técnico sobre ptrace y cómo permite manipular procesos en ejecución, consulte la documentación de sistema: https://man7.org/linux/man-pages/man2/ptrace.2.html.

La implantación descrita incluye marcas incrustadas en el tráfico procesado por miglogd (por ejemplo, un identificador que contiene una referencia tipo puerto “8550” y la cadena “169.254.0.1” como patrón; estos no son puertos abiertos ni direcciones asignadas, sino signaturas en tráfico). Cuando iked procesa sesiones VPN, busca esos identificadores y toma rutas de ejecución alternativas que evaden las validaciones normales. Además, los atacantes habrían usado módulos nativos de Apache en FortiGate para establecer un canal de comando y control basado en SSH y llegaron a suplantar la consola FortiManager para extraer configuraciones desde dispositivos gestionados.

Lo que está confirmado es la metodología técnica y las metas: exfiltración de material sensible (configuraciones, claves y bases de datos), establecimiento de persistencia encubierta en memoria, y abuso de la confianza en la gestión centralizada. Lo que sigue siendo estimación o abierto a verificación es la identidad definitiva del actor y si se explotaron otras vulnerabilidades específicas para alcanzar ciertas fases del ataque; Unit 42 menciona otras fallas posibles, pero señala requerimientos adicionales de inscripción en FortiCloud para su explotación en ciertos vectores.

Consecuencias prácticas: la combinación de acceso a configuraciones y claves con un implante en memoria permite a los atacantes crear sesiones VPN no autorizadas, interceptar tráfico cifrado, y moverse dentro de redes internas sin dejar rastro fácil en disco o en los controles de red convencionales. La exposición de certificados y claves privadas compromete la confianza criptográfica de perímetros enteros y obliga a acciones de respuesta intensivas (rotación de certificados, reemisión de claves, revisión de sesiones VPN). Además, la manipulación de registros y la eliminación de artefactos —terminación de syslog, borrado de registros de caída, eliminación automática de cuentas administrativas y objetos de auto-script— complica la investigación forense.

Recomendaciones concretas e inmediatas para administradores y empresas que usan Fortinet o dependen de proveedores gestionados: parchee cuanto antes todos los dispositivos Fortinet afectados y aplique las actualizaciones publicadas por el fabricante (FortiOS, FortiManager, FortiPAM, FortiProxy, FortiSwitchManager). Asuma compromiso cuando existan consolas de administración expuestas: realice una respuesta a incidentes que incluya adquisición de memoria volátil de las máquinas potencialmente afectadas, análisis forense de memoria y limpieza o reinstalación de appliances comprometidos. Rote claves privadas y certificados que hayan estado almacenados en FortiManager o exportados por el atacante; revoque y vuelva a emitir credenciales administrativas y de VPN. Restrinja el acceso a consolas de gestión con controles de acceso con lista blanca de IP, MFA y segmentación de red.

Para detección y mitigación operativa, considere activar y revisar inmediatamente integridad de procesos y auditoría de llamadas al sistema que detecten ptrace o cambios de memoria inusuales; despliegue reglas específicas en EDR para monitorizar la modificación de procesos críticos (miglogd, iked y equivalentes) y supervise anomalías en la generación de logs o en la telemetría de registros. Busque indicadores como eliminación de objetos auto-script o cuentas administrativas recién creadas y borradas, así como patrones en cargas útiles que podrían contener las marcas mencionadas, aun cuando su detección es compleja porque se esconden dentro de tráfico legítimo.

Si usted es cliente final de un proveedor de servicios gestionados, solicite evidencia de integridad del gestor central que administra su perímetro (logs de gestión, registros de actualizaciones y auditorías de cuentas). Considere realizar auditorías independientes de configuración y gestión de certificados. En casos de sospecha, active la coordinación con un equipo de respuesta a incidentes y, si procede, con las autoridades competentes para manejo de brechas.

En resumen, esta intrusión ilustra el riesgo añadido de centralizar la gestión de borde: un único punto comprometido puede convertir configuraciones y secretos en una palanca para comprometer múltiples redes. La técnica de inyección en memoria y la comunicación encubierta entre procesos legítimos elevan significativamente la dificultad de detección tradicional. Parcheo inmediato, rotación de material criptográfico y análisis forense de memoria son pasos no opcionales para cualquier organización afectada o con dispositivos Fortinet expuestos.