Investigadores de ciberseguridad han revelado detalles de un compromiso en WordPress en el que actores de amenazas desplegaron múltiples mecanismos de persistencia para asegurar que el payload final siguiera reapareciendo sin necesidad de reinfectar el sitio.
El backdoor ha sido denominado SC por los marcadores 'SC_' presentes en el contenido inyectado. Sucuri ha descrito el malware como una 'malla autorreparable' controlada por blockchain.
El payload reside en al menos ocho lugares a la vez, distribuidos entre archivos, la base de datos y la memoria compartida, y cada uno de esos lugares puede reconstruir todos los demás. Elimina el plugin y un drop-in lo reescribe. Elimina el drop-in y el tema lo reescribe. Limpia cada archivo en disco y la siguiente carga de página restaurará todo el conjunto desde la base de datos o desde un segmento de memoria compartida. El resultado es un sistema circular sin un único punto que puedas eliminar para detenerlo.
Según Sucuri, el malware no tiene nombres de funciones legibles, sino que emplea un decodificador para descifrar el código mediante un cifrado por sustitución. Un resumen de los ocho componentes es el siguiente:
- .user.ini, que establece 'auto_prepend_file' para ejecutar un cargador antes de cada petición PHP en ese árbol de directorios.
- wp-content/c1b12371.php, el cargador que incluye un archivo oculto con prefijo de punto si existe en la misma ubicación.
- wp-content/.c1b12371.php, el archivo oculto con prefijo de punto que actúa como cargador de primera etapa para localizar un plugin falso y reconstruirlo en mu-plugins desde tres fuentes: una copia existente en la carpeta de plugins, un stub codificado en el directorio de caché y un paquete ZIP de restauración con un nombre hexadecimal aleatorio.
- wp-content/db.php, que se carga durante el arranque y contiene todo el payload del backdoor en formato comprimido y codificado en Base64. Decodifica y vuelve a desplegar el plugin cada vez que falta o es demasiado pequeño.
- wp-content/advanced-cache.php, que WordPress carga antes de los plugins ordinarios cuando la caché está habilitada, y reconstruye el plugin desde cinco fuentes independientes: un mu-plugin existente, una copia del plugin existente, un segmento de memoria compartida System V que contiene PHP, un paquete ZIP y la base de datos. Luego engancha plugins_loaded y lo incluye.
- wp-content/themes/khorshidi/functions.php, un gemelo residente en el tema de db.php que presenta el mismo backdoor y reescribe el plugin cada vez que no está presente.
- wp-content/mu-plugins/hyper-engine-kit.php, el malware real que se instala tanto como plugin must-use como plugin normal.
- wp-content/plugins/hyper-engine-kit/hyper-engine-kit.php, un duplicado del mismo payload de backdoor por redundancia.
Independientemente del método utilizado para lanzar el backdoor, este lleva a cabo varias acciones, como ocultarse de la pantalla de plugins del administrador o en las comprobaciones de actualización, comunicarse con un servidor de mando y control (C2) utilizando la blockchain de Ethereum, tomar huellas del sitio infectado y recuperar payloads adicionales, crear una cuenta de administrador oculta y ejecutar el bucle de reinfección.
Las capacidades del backdoor permiten al operador tomar el control del sitio WordPress, obtener JavaScript arbitrario para inyectar y atacar a los visitantes del sitio con skimmers (u otro malware), ejecutar código PHP y desactivar o eliminar plugins específicos.
En servidores que soportan memoria compartida System V, el payload se escribe en un segmento identificado por una clave numérica fija. Ese segmento vive en RAM, por lo que sobrevive tanto a la eliminación de archivos como a la limpieza de la base de datos, e incluso en alojamiento compartido puede ser propiedad de una cuenta diferente. La infección registra hooks de cron, incluidos nombres aleatorizados junto con un hook de recuperación conocido. El cron del sistema ejecuta el archivo cron de WordPress, no el tráfico de visitantes, y luego activa el redespliegue según lo programado.
Actualmente no se sabe cómo se entrega el malware al sitio WordPress. Sin embargo, los vectores típicos de acceso inicial incluyen fallos de seguridad conocidos en WordPress, plugins y temas; credenciales de inicio de sesión débiles; ataques a la cadena de suministro de software dirigidos a plugins populares; y la explotación de funciones inseguras de carga de medios o formularios para introducir webshells PHP en directorios del servidor.
SC es un recordatorio de que una infección moderna de WordPress puede ser un sistema en lugar de un archivo. Este conjunto de herramientas propaga copias idénticas de un backdoor a través de drop-ins, el tema, un plugin falso en dos ubicaciones, la base de datos y la memoria compartida, oculta su canal de mando dentro de infraestructura blockchain legítima y se reescribe desde cualquier copia superviviente en la siguiente petición.
Vulnerabilidad en el plugin wpForo Forum explotada
La divulgación se produce mientras una vulnerabilidad de inyección SQL no autenticada de alta severidad en el plugin wpForo Forum de WordPress (CVE-2026-1581, puntuación CVSS: 7.5) ha sido explotada activamente. El fallo afecta a todas las versiones del plugin hasta la 2.4.14 inclusive.
Según datos de telemetría de Previdian, se han observado menos de 20 intentos de explotación dirigidos a la vulnerabilidad desde el 3 de julio de 2026. La actividad se ha originado desde cinco direcciones IP de atacantes únicas ubicadas en Bulgaria, Suiza, Francia, EE. UU. y Yemen.
Deja una respuesta