Hackers atacan sistemas F5 BIG-IP APM con un web shell de Linux sin archivos

Según se informa, actores de amenazas están comprometiendo sistemas en entornos F5 BIG-IP Access Policy Manager e instalando un rootkit de Linux capaz de manipular la carga de archivos PHP. El rootkit inyecta un web shell directamente en la memoria, lo que permite a los atacantes mantener un acceso encubierto sin dejar en el disco un archivo de web shell convencional.

La actividad se dio a conocer el 8 de septiembre de 2026. Sin embargo, la información inicial no identifica el vector de intrusión, una vulnerabilidad asociada, las versiones de software afectadas ni el número de organizaciones comprometidas.

Esta incertidumbre complica la remediación. Los equipos de defensa todavía no pueden determinar si la instalación de una actualización concreta cierra la vía de entrada utilizada por los atacantes, pero el comportamiento posterior al compromiso ofrece una base para iniciar una investigación de inmediato.

Una pasarela de seguridad se convierte en un punto de apoyo para los atacantes

El entorno afectado es F5 BIG-IP Access Policy Manager, que normalmente se sitúa delante de recursos empresariales sensibles para aplicar políticas de acceso. El compromiso de un sistema de este tipo tiene consecuencias más graves que una infección en un endpoint convencional.

Un atacante que controle un dispositivo de gestión de acceso puede obtener una posición persistente cerca de los flujos de autenticación y los servicios de red protegidos. Según la configuración y los privilegios del dispositivo, también podría convertirse en un punto de partida para intentar acceder a sistemas internos.

El malware identificado opera en el contexto de Linux subyacente al entorno BIG-IP. Sus principales capacidades documentadas son:

• Interceptar la carga de archivos PHP.
• Inyectar un web shell en la memoria del sistema.
• Evitar la creación de un archivo de web shell normal en el disco.
• Ocultar la ejecución maliciosa mediante funciones de rootkit.

No se ha hecho pública ninguna evidencia que demuestre el robo de datos, la interrupción de servicios, la interceptación de credenciales o el desplazamiento hacia redes posteriores. Esos escenarios siguen siendo posibles consecuencias, no hallazgos confirmados.

También se desconoce la escala de la actividad. No se ha publicado el número de dispositivos u organizaciones afectados, ni se ha identificado una orientación geográfica o sectorial concreta. Tampoco se han revelado los operadores, el nombre de la campaña ni el nombre del malware.

Cómo el web shell residente en memoria evade el análisis de archivos

Los web shells tradicionales suelen ser scripts del lado del servidor escritos en un directorio accesible desde la web. Después, el atacante envía solicitudes manipuladas al script para ejecutar comandos u otras acciones no autorizadas.

Este modelo deja un archivo en el sistema. Las herramientas de seguridad pueden detectarlo mediante la comparación de firmas, la supervisión de integridad, la identificación de nombres de archivo sospechosos, la inspección del contenido o la comparación con una instalación conocida y legítima.

La técnica identificada en los sistemas BIG-IP APM elimina esa dependencia. En lugar de guardar el componente PHP malicioso como un archivo normal, el rootkit intercepta la actividad de carga de PHP e inyecta el web shell en la memoria.

Esto genera una brecha entre lo que aparentemente contiene el sistema en el disco y lo que ejecuta durante el tiempo de ejecución. Un análisis del sistema de archivos puede no detectar ningún archivo PHP desconocido aunque la lógica maliciosa del web shell siga activa en la memoria.

El rootkit añade otra capa de sigilo. Los rootkits están diseñados para interferir con la visibilidad normal que ofrece el sistema operativo sobre procesos, archivos, actividad de red u otros recursos. No se han revelado los mecanismos exactos de ocultación utilizados en esta campaña, por lo que los equipos de defensa no deben asumir que la salida de las herramientas administrativas estándar ofrece una visión completa de un dispositivo afectado.

Del mismo modo, la información disponible no explica cómo sobrevive la persistencia a un reinicio, cómo se comunican los atacantes con el shell inyectado ni qué mecanismo de carga de PHP se intercepta. No se han publicado infraestructuras de comando y control, nombres de archivo, nombres de procesos, indicadores de red, hashes criptográficos ni firmas de detección.

Las versiones, las vulnerabilidades y la vía de entrada siguen sin conocerse

La familia de productos afectada es F5 BIG-IP, concretamente los entornos que utilizan Access Policy Manager. No se han identificado las versiones exactas de BIG-IP ni los modelos de dispositivos afectados.

No se ha vinculado ningún CVE a los compromisos. Por tanto, se desconoce si los atacantes explotaron una vulnerabilidad de software sin parchear, utilizaron credenciales administrativas robadas, abusaron de una interfaz de gestión expuesta u obtuvieron acceso por otra vía.

Esta distinción es importante para la contención. Una actualización de software puede eliminar una vulnerabilidad, pero no necesariamente elimina un rootkit de un dispositivo que ya ha sido comprometido. Del mismo modo, cambiar las credenciales por sí solo no cerraría una vulnerabilidad explotable cuya existencia aún no se ha determinado.

Tampoco se ha divulgado una versión corregida, un parche del proveedor o una solución alternativa confirmada específicamente para esta actividad. Las organizaciones deben seguir aplicando las actualizaciones de seguridad y las recomendaciones de hardening correspondientes de F5, pero no deben considerar la aplicación rutinaria de parches como una prueba de que el dispositivo está limpio.

Dado que no se ha proporcionado ningún identificador de vulnerabilidad, la actividad no puede vincularse a una entrada del catálogo Known Exploited Vulnerabilities de la Cybersecurity and Infrastructure Security Agency de Estados Unidos. Por consiguiente, no se ha comunicado ninguna fecha de inclusión en KEV ni ningún plazo de remediación asociado a este incidente.

La detección debe ir más allá del sistema de archivos

El análisis convencional de malware basado en archivos no es suficiente frente a esta amenaza. Los equipos de defensa deben combinar los registros del dispositivo, la telemetría de red, la inspección del tiempo de ejecución, la revisión de la configuración y el análisis forense de la memoria cuando dispongan de esas capacidades.

Las prioridades de la investigación son:

1. Revisar el acceso administrativo. Examinar los registros de gestión y del sistema de BIG-IP en busca de inicios de sesión no explicados, uso de privilegios, cambios de configuración, creación de cuentas o accesos desde fuentes inesperadas.

2. Inspeccionar el comportamiento de la ejecución de PHP. Buscar solicitudes inusuales, patrones inesperados de carga de PHP, rutas de ejecución que no correspondan a archivos presentes en el disco y discrepancias entre el contenido de la aplicación desplegada y el comportamiento observado durante el tiempo de ejecución.

3. Analizar la actividad residente en memoria. Investigar procesos y componentes cargados anómalos. Dado que, según los informes, el web shell se inyecta en la memoria, las pruebas volátiles pueden ser esenciales para determinar si el dispositivo está comprometido.

4. Examinar las conexiones de red. Identificar tráfico saliente inesperado, sesiones persistentes, destinos desconocidos y conexiones que no coincidan con la función operativa del dispositivo.

5. Buscar el comportamiento propio de un web shell, no solo archivos de web shell. La ejecución sospechosa de comandos o los patrones inusuales de solicitudes pueden seguir siendo visibles en los registros o en los datos de red aunque no exista ningún script malicioso en el disco.

6. Comprobar la integridad del sistema. Comparar la configuración y el estado del software del dispositivo con referencias fiables mediante procedimientos administrativos o forenses aprobados por F5.

La ausencia de indicadores publicados implica que estas comprobaciones requerirán análisis del comportamiento, en lugar de limitarse a comparar hashes o direcciones IP. Un análisis limpio del disco, por sí solo, no debe dar por cerrada la investigación.

Los dispositivos sospechosos requieren una contención que preserve las evidencias

Las organizaciones que identifiquen indicios creíbles de compromiso deben aislar el sistema BIG-IP afectado y preservar los registros y la memoria volátil. Reconstruir o reiniciar el dispositivo de inmediato puede alterar las evidencias necesarias para comprender el rootkit y su payload en memoria.

Los equipos de respuesta a incidentes deben determinar cuándo comenzó el acceso no autorizado, qué cuentas interactuaron con el dispositivo y qué sistemas internos o externos se comunicaron con él. La revisión debe extenderse más allá del dispositivo BIG-IP, ya que una pasarela de acceso comprometida podría haberse utilizado para llegar a infraestructura protegida.

Las credenciales accesibles desde el sistema afectado o utilizadas a través de él deben cambiarse después de la contención. Las cuentas privilegiadas, las credenciales de automatización, las cuentas de servicio y las vías de acceso administrativo requieren una atención especial.

Restablecer la confianza puede exigir algo más que eliminar archivos sospechosos, especialmente cuando no hay ninguno presente. Las organizaciones deben utilizar los procedimientos de recuperación y validación de integridad respaldados por el proveedor y verificar que las modificaciones maliciosas del tiempo de ejecución no puedan sobrevivir ni reaparecer después de la remediación.

Hasta que se divulguen las versiones de F5 afectadas, un método de acceso inicial y correcciones validadas, los equipos de defensa se enfrentan a dos tareas distintas: reducir la exposición mediante las actualizaciones de seguridad disponibles y determinar si los atacantes ya operan dentro de los dispositivos desplegados. La segunda tarea no puede resolverse únicamente aplicando parches.