FreePBX bajo ataque activo: qué deben priorizar los equipos de infraestructura tras la campaña de web shells

Más de 900 instancias de Sangoma FreePBX siguen comprometidas tras la explotación de CVE-2025-64328. Claves técnicas, riesgos reales y un plan de respuesta práctico para SysAdmin y DevOps.

Las plataformas de telefonía IP suelen quedar fuera del foco diario de muchos equipos de infraestructura, hasta que aparece una campaña real que demuestra su impacto operacional. Eso es exactamente lo que está ocurriendo con Sangoma FreePBX: distintos reportes de las últimas horas indican que todavía hay más de 900 instancias comprometidas con web shells activos, luego de la explotación de CVE-2025-64328.

El dato no es menor para equipos SysAdmin, DevOps y seguridad ofensiva/defensiva. FreePBX concentra servicios críticos de voz, integra credenciales, expone superficies web administrativas y, en muchas organizaciones, convive con infraestructura legacy difícil de parchear con rapidez. Cuando un atacante toma control de ese plano, no solo hay riesgo de fraude de llamadas o interrupción operativa: también puede abrirse una puerta de pivote hacia otros sistemas internos.

Qué vulnerabilidad se está explotando y por qué importa

El vector central es CVE-2025-64328, descrita como una inyección de comandos post-autenticación en el módulo Endpoint Manager de FreePBX, específicamente en la función testconnection -> check_ssh_connect(). Según el advisory del proyecto, un usuario autenticado con acceso al panel administrativo puede ejecutar comandos arbitrarios en el host subyacente con permisos del usuario asterisk.

Sobre el papel, “post-auth” puede sonar menos crítico que un RCE sin autenticación. En operaciones reales, no siempre es así: credenciales débiles, paneles expuestos a Internet, accesos heredados, reutilización de usuarios o segmentaciones laxas convierten este tipo de fallas en una vía altamente explotable. El CVSS base reportado para el caso es 8.6 (High), y la incorporación al catálogo KEV de CISA confirma que ya existe explotación en escenarios reales.

Qué muestran los reportes recientes

La cobertura de SecurityWeek y The Hacker News coincide en un punto clave: el volumen de sistemas comprometidos sigue siendo alto pese a que el parche está disponible. Además, ambas publicaciones referencian datos de Shadowserver que permiten dimensionar la exposición por país, con una concentración especialmente alta en América del Norte y presencia distribuida en otras regiones.

El problema ya no es teórico ni de laboratorio. En paralelo, análisis técnicos de Fortinet sobre la familia de web shell EncystPHP describen tácticas de persistencia y defensa evasiva que elevan la complejidad de remediación:

• Descarga de droppers secundarios y reinstalación periódica vía cron.
• Creación/modificación de cuentas para asegurar acceso persistente.
• Manipulación de archivos y marcas temporales para dificultar el análisis forense.
• Despliegue de múltiples copias del web shell en rutas alternativas.

En otras palabras: aplicar el parche es indispensable, pero no alcanza si el sistema ya fue comprometido. En ese escenario, la prioridad pasa a ser contención + erradicación + validación de integridad.

Impacto operativo para SysAdmin y DevOps

Desde una mirada de operación, este incidente pega en cuatro frentes:

1) Continuidad del servicio de voz

La degradación o secuestro parcial de PBX afecta atención al cliente, mesas de ayuda y procesos internos que dependen de IVR o extensiones. El costo de indisponibilidad puede ser superior al de muchos servicios web secundarios.

2) Riesgo de abuso financiero

Un PBX comprometido puede usarse para fraude de llamadas (toll fraud), consumo no autorizado de troncales y desvíos de tráfico. Esto se traduce en impacto económico directo y, en algunos casos, reputacional.

3) Puerta de entrada lateral

Si el host de telefonía comparte red con servicios internos sensibles, el atacante puede intentar reconocimiento lateral, extracción de credenciales o movimiento hacia sistemas de gestión y respaldo.

4) Complejidad de respuesta

La presencia de web shells con mecanismos de persistencia obliga a elevar el estándar de respuesta. No alcanza con “reiniciar y monitorear”; hay que tratar el incidente como una intrusión completa del sistema.

Plan de respuesta recomendado (primeras 24 horas)

Para equipos de infraestructura que necesiten una guía accionable, este orden ayuda a reducir riesgo rápidamente:

1. Inventario y exposición: identificar todas las instancias FreePBX/Elastix, versión, módulo Endpoint Manager y nivel de exposición externa del ACP.
2. Contención de acceso: restringir de inmediato el panel administrativo por IP/VPN, bloquear acceso desde redes no confiables y revisar ACL/firewall del propio producto y del perímetro.
3. Parcheo dirigido: actualizar a versiones corregidas del módulo/stack afectado según guidance del proveedor.
4. Búsqueda de compromiso: inspeccionar rutas web comunes para archivos PHP anómalos, tareas cron sospechosas, usuarios recién creados, claves SSH añadidas y cambios de permisos inesperados.
5. Rotación de credenciales: forzar cambio de contraseñas administrativas, claves SIP/troncales y secretos de integración.
6. Telemetría y retención: centralizar logs del host PBX, servidor web y autenticación para facilitar correlación e investigación posterior.
7. Segmentación: aislar la red de voz del resto de activos críticos, limitando puertos y flujos estrictamente necesarios.

Qué no hacer

• Asumir que “si ya está parcheado, ya está limpio”.
• Confiar solo en un escaneo superficial de IOC sin revisión de persistencia.
• Mantener paneles de administración abiertos a Internet por conveniencia operativa.
• Postergar hardening por tratarse de un servicio “secundario”.

Conclusión: de vulnerabilidad a disciplina operativa

La campaña sobre FreePBX recuerda una lección conocida pero vigente: en infraestructura real, las brechas más costosas no siempre nacen en el sistema más moderno, sino en el más expuesto y menos gobernado. Con CVE-2025-64328 ya explotada en la práctica y cientos de instancias comprometidas todavía visibles, el foco para equipos técnicos debe estar en una respuesta integral: parchear, contener, verificar compromiso y reforzar controles de acceso de forma permanente.

Acciones recomendadas para esta semana: (1) cierre de exposición externa del ACP, (2) validación de versiones y parcheo completo, (3) revisión forense mínima de persistencia, (4) rotación de credenciales administrativas y (5) actualización del runbook de respuesta para plataformas de voz. Si su organización depende del PBX para procesos de negocio, tratar este frente como prioridad de continuidad, no solo como una tarea de mantenimiento.

Fuentes consultadas: SecurityWeek, The Hacker News, NVD (NIST), CISA KEV Catalog y Fortinet FortiGuard Labs.