Investigadores de Palo Alto Networks Unit 42 han documentado el uso de PEERSTITCH, un malware ARM64 que no deja binarios persistentes en disco, en una cadena de ataque que aprovechó una vulnerabilidad en Fortinet FortiOS para desplegar el implante en dispositivos de red.
Qué es PEERSTITCH y cómo opera
PEERSTITCH es un ejecutable de 64 bits para Linux ARM64 escrito en C que permanece íntegramente en memoria. Según Unit 42, el malware no crea archivos persistentes, no abre puertos ni establece conexiones salientes tradicionales; en su lugar, se comunica mediante tráfico generado por procesos legítimos del sistema, lo que dificulta su detección por soluciones convencionales de endpoint y de red.
Vector de implantación: vulnerabilidad en FortiOS
La campaña descrita usa la explotación de CVE-2025-61624, una vulnerabilidad de traversal de rutas en el intérprete de línea de comandos de FortiOS, FortiPAM, FortiProxy y FortiSwitchManager que puede permitir a un atacante con privilegios escribir o eliminar archivos de forma arbitraria mediante argumentos especialmente construidos. Fortinet parcheó el fallo en abril de 2026.
Fases del ataque y técnicas de ocultación
Los investigadores relatan que la operación forma parte de una intrusión más amplia (seguida por Unit 42 como CL-STA-0954) que comenzó con un compromiso de un gestor de Fortinet (FortiManager) mediante otra vulnerabilidad crítica. Tras obtener acceso, los atacantes exfiltraron configuraciones, material criptográfico y bases de datos de más de 500 firewalls gestionados, y usaron esos datos para movimiento lateral y persistencia.
El despliegue de PEERSTITCH incluye la descarga de varios componentes desde un servidor externo y la ejecución, tras un retardo, de un orquestador que lanza un inyectador de memoria. Ese inyector parchea en tiempo de ejecución dos daemons centrales de FortiOS —/bin/miglogd y /bin/iked— usando ptrace para detener los procesos, asignar memoria ejecutable y escribir código malicioso que redirige la ejecución.
Los hooks instalados buscan marcadores específicos en el tráfico manejado por miglogd y pasan identificadores de sesión a iked. Cuando iked detecta ese identificador en el buffer de una sesión VPN, altera la ruta de ejecución para omitir validaciones de seguridad normales, lo que permite a los atacantes establecer sesiones SSL/VPN no autorizadas y actuar encubiertos dentro del flujo legítimo de los procesos.
Consecuencias y acciones observadas
Además de desplegar PEERSTITCH, los atacantes montaron un canal de mando y control aprovechando el módulo mod_md de Apache en FortiGate para generar shells reversos SSH y suplantaron a FortiManager para extraer datos de firewalls gestionados. Unit 42 también documentó medidas para borrar artefactos forenses: interrupción de syslog, limpieza de crash logs, alteración de la telemetría y eliminación automática de cuentas administrativas y objetos de auto-script tras la ejecución.
Qué cambia y qué deben hacer administradores
Esta actividad evidencia una tendencia: la instrumentación de gestores centralizados de dispositivos de borde (edge) para comprometer redes downstream. Para administradores y responsables de infraestructura web y de red, las recomendaciones prácticas son:
- Verificar que los dispositivos Fortinet afectados recibieron las actualizaciones que corrigen CVE-2025-61624 y otros fallos ya parchados.
- Revisar accesos y credenciales de FortiManager y FortiGate, y rotar claves o certificados que puedan haber sido comprometidos.
- Auditar configuraciones y búsquedas de indicios de compromiso: procesos inyectados, cambios en miglogd/iked, objetos auto-script eliminados, y anomalías en logs de VPN y gestión.
- Habilitar y revisar telemetría centralizada y copias seguras de logs fuera del entorno gestionado para evitar su manipulación.
Unit 42 subraya la complejidad técnica de los atacantes y la importancia de asegurar tanto los gestores centralizados como los dispositivos administrados para evitar que una sola brecha permita compromisos a gran escala.
Lee también:
- Verisign aboga por modernizar OCSP para evitar la ‘confianza obsoleta’ en certificados
- ConnectWise suspende Cloud Backup tras acceso no autorizado a identidades de aplicación de Microsoft 365
Fuente: The Hacker News
