Se ha detectado un rootkit de Linux diseñado para mantener el control de servidores F5 BIG-IP Access Policy Manager comprometidos. A diferencia de otros métodos, este ataque es especialmente sigiloso ya que no deja archivos PHP maliciosos visibles, sino que inyecta un web shell directamente en la memoria del proceso del servidor en ejecución. Esta actividad afecta específicamente a los entornos de webtop de BIG-IP APM. 

Un sigiloso rootkit de Linux está dando a los atacantes una nueva forma de mantener el control de los servidores F5 BIG-IP Access Policy Manager comprometidos.

En lugar de dejar un archivo PHP malicioso obvio, coloca una web shell únicamente en la memoria utilizada por el proceso del servidor en ejecución. La actividad está vinculada a entornos webtop de BIG-IP APM que ejecutan Apache y PHP.

F5 ha asociado la actividad relacionada con el CVE-2025-53521, un fallo de ejecución remota de código no autenticado que ya ha sido explotado, un riesgo ya resaltado en la cobertura de dispositivos BIG-IP APM expuestos.

Analistas de Sophos identificaron el implante mientras examinaban sistemas comprometidos. Los investigadores afirmaron que su diseño apunta a una carga útil de segunda etapa dirigida, en lugar de un ataque generalizado contra instalaciones ordinarias de Apache o de gestión de contenidos, y señalaron que no hay pruebas suficientes para atribuirlo a un actor de amenazas específico.

El impacto es grave porque los escaneos de archivos tradicionales pueden mostrar scripts PHP limpios incluso mientras Apache ejecuta versiones alteradas en la memoria.

Para una empresa que utiliza BIG-IP APM para proporcionar acceso remoto, esa brecha puede otorgar a un intruso un control duradero en el lado del servidor y una ruta silenciosa hacia la infraestructura protegida.

Sophos dijo en un informe compartido con Cyber Security News (CSN) que el implante combina un cargador personalizado, ganchos de proceso (process hooks) y parches en tiempo de ejecución para ocultar su operación.

Rootkit de Linux Inyecta Web Shells de PHP Sin Archivos

El malware se inicia antes de que el programa anfitrión llegue a su función principal normal. Abre su propia imagen, carga manualmente el ejecutable original e intercepta una rutina de inicio central de Linux.

Ese acceso temprano le permite tender trampas antes de que comience la actividad normal de Apache y hace que el monitoreo de inicio convencional sea menos confiable. Luego vigila el cargador de módulos de Apache y se activa solo cuando aparece el componente PHP, libphp.

El implante cambia operaciones seleccionadas de archivos y memoria dentro de ese componente, lo que le permite controlar cómo se abren y mapean scripts específicos. Este comportamiento selectivo ayuda a explicar por qué puede permanecer oculto dentro de un servicio web legítimo.

Tres scripts de webtop de APM son los objetivos. Cuando PHP mapea uno en la memoria, el rootkit construye una copia modificada que contiene el contenido original más su web shell.

El archivo en el disco permanece sin cambios, por lo que las comprobaciones basadas solo en archivos de la raíz web pueden pasar por alto la intrusión, a diferencia de los patrones vistos en ataques anteriores de RCE de BIG-IP. El código inyectado acepta solicitudes especialmente formadas, descifra su contenido y lo ejecuta en el servidor.

Devuelve una respuesta HTTP 201 mientras se presenta como un recurso CSS, una combinación inusual que puede mezclarse con el tráfico de activos ordinario. Esto hace que los registros web, los encabezados de respuesta y los patrones de solicitud sean evidencia importante junto con las comprobaciones del sistema de archivos.

El Backdoor de Socket Eleva el Riesgo de la Respuesta

El implante también crea un socket Unix local y puede entregar una conexión autenticada a una shell de Bash. Debido a que este canal no abre un puerto de escucha TCP normal, el monitoreo exclusivo de red podría no detectarlo.

Este hallazgo añade contexto a los informes de atacantes que utilizan un dispositivo BIG-IP para acceso SSH y se mueven más profundamente en las redes empresariales.

Los investigadores creen que el rootkit es parte de una operación por etapas. Un componente instalador relacionado parece infectar el binario del servidor HTTP, preservar el acceso a través de imágenes de actualización de BIG-IP, modificar la configuración de SELinux y desplegar la carga útil en tiempo de ejecución.

Por lo tanto, reiniciar un servicio por sí solo no es un paso de recuperación confiable, ya que podría no eliminar el mecanismo de persistencia previo.

Las organizaciones que sospechen de un compromiso deben preservar la evidencia volátil antes de modificar el anfitrión, incluyendo la memoria del proceso y los detalles del proceso en ejecución.

Deben investigar los trabajadores de Apache que leen mapas de memoria de procesos, cambios temporales de escritura y ejecución alrededor de libphp, sockets locales inesperados y procesos hijos que lancen Bash.

Los administradores deben seguir la guía de remediación y evaluación de compromiso de F5 para las versiones afectadas de APM antes de aplicar cambios genéricos de Apache o PHP.

Cuando sea operativamente seguro y revisado, desactivar la ejecución de PHP heredado no necesaria puede reducir la exposición. Los equipos también deben comparar el contenido del disco y la memoria, inspeccionar los puntos finales de PHP que devuelven respuestas 201 etiquetadas como CSS y utilizar la guía de parches más reciente de BIG-IP para priorizar el trabajo correctivo.

También deben verificar las imágenes de actualización y revisar los cambios de SELinux, ya que la persistencia fuera del proceso Apache activo puede sobrevivir a un reinicio rutinario del servicio.