De una falla en VPN al control root: hackers usaron webshells y software legítimo para saquear bases de datos de millones de abonados

Un error en la configuración de la infraestructura atacante reveló casi toda la cadena de intrusión de un gran proveedor de Internet. Hunt.io descubrió un servidor del atacante abierto con 298 archivos en 30 directorios que indicaban la intrusión en la red del operador tailandés 3BB, el establecimiento de persistencia en máquinas internas y la caza dirigida de credenciales de suscriptores.

Hunt.io relacionó la operación con un FortiGate 60F que atendía el servicio SSL‑VPN de 3BB. El atacante primero determinó el modelo y la versión del firmware y luego comprobó el gateway frente a CVE-2024-21762. El fallo crítico de desbordamiento de escritura obtuvo 9,8 puntos según CVSS 3.1 y permite ejecutar código arbitrario sin autenticación mediante una petición HTTP especialmente formada al servicio SSL‑VPN.

El conjunto encontrado conservaba la cadena completa de explotación. Los scripts preparaban la memoria del dispositivo, lanzaban una cadena ROP y abrían una conexión inversa al servidor del atacante. Para ajustar con precisión el exploit al FortiGate 60F, el atacante intentó obtener el firmware FortiOS 7.2.5 adecuado usando el número de serie del dispositivo objetivo en peticiones a la infraestructura de Fortinet.

Tras el acceso inicial, el ataque se extendió hacia el interior de la red. Uno de los archivos registraba la ejecución de comandos con privilegios root en un servidor Linux de 3BB, y herramientas separadas estaban diseñadas para elevar privilegios, instalar una puerta trasera SUID oculta y robar claves SSH, configuraciones de aplicaciones y contraseñas. Un tránsito similar desde el FortiGate perimetral hacia sistemas internos ya se había analizado en el ejemplo de otros ataques.

Para el control a largo plazo, el atacante eligió MeshCentral, una herramienta legítima de administración remota de código abierto. En la configuración del agente figuraba el grupo TH-3BB y un servidor de control externo, y la exportación de dispositivos mostraba varias máquinas activas con agentes ejecutados como root. Ese canal parece una herramienta de administración habitual y resulta menos detectable entre el tráfico legítimo.

Paralelamente, el atacante desplegó accesos alternativos y preparó la ampliación de privilegios. Scripts de MySQL podían escribir web‑shells PHP en directorios de servidores web, añadir claves SSH y cambiar permisos en bases de datos. Otras utilidades probaban contraseñas en más de 55 nodos internos y buscaban acceso a FTP, MySQL, MongoDB y Redis ya desde un segmento de red de confianza.

Una infraestructura objetivo separada fue el sistema RADIUS, por el que el operador verifica las credenciales de los suscriptores. En el paquete había un script para extraer datos de las bases radius_corp, radiusinfo y job_radius con una contraseña root de MySQL codificada. Hunt.io no confirmó una extracción masiva de datos de suscriptores, por lo que está demostrada la intención del ataque, pero no la fuga de datos de millones de clientes.

El atacante preparó borrado de rastros con antelación. cleanup_target.sh eliminaba registros, el historial de comandos, componentes de elevación de privilegios y web‑shells, pero conservaba intencionadamente MeshCentral y la puerta trasera SUID oculta. Ese esquema permitía ocultar acciones ya realizadas sin perder el acceso persistente. Fortinet anteriormente advirtió que las consecuencias del compromiso pueden persistir incluso después de actualizar el FortiGate.

Hunt.io detectó el directorio de trabajo abierto el 3 de junio de 2026, cuando la operación aún continuaba, y publicó el informe el 14 de septiembre. Antes de la publicación, la empresa notificó a las partes afectadas y al CERT correspondiente, pero no informó sobre las acciones de respuesta que tomaron. A los propietarios de FortiGate se les recomendó comprobar los firmware, buscar agentes MeshCentral desconocidos y cambiar credenciales privilegiadas, certificados VPN y claves.