Los atacantes modificaron archivos JavaScript confiables utilizados por los sitios de WordPress que ejecutan PushEngage, OptinMonster y TrustPulse, convirtiéndolos en un medio de entrada al sitio.
Si un administrador del sitio inicia sesión cuando se carga el archivo, el código crea una cuenta de administrador bajo el control del atacante e instala un complemento oculto que abre un camino de regreso. Los visitantes generales no activaron el complemento.
Los sitios afectados deben tratarse como comprometidos. Los tres complementos son operados por una empresa, Awesome Motive, pero hasta el 15 de junio, la empresa no había comentado sobre los dos complementos principales.
La empresa de seguridad Sansec reveló una campaña más amplia el 13 de junio cuando descubrió que los tres complementos contenían el mismo código malicioso en JavaScript.
Al día siguiente, PushEngage emitió su propia notificación de incidente confirmando que el atacante había proporcionado una copia modificada del script, lo que permitió que los sitios que lo cargaban se vieran comprometidos.
PushEngage, que fue adquirida por Awesome Motive hace muchos años, es actualmente la única empresa de las tres que publica directrices. Los usuarios de OptinMonster y TrustPulse no han escuchado nada oficialmente.
Las ventanas no eran las mismas para cada complemento. Sansec vio el código malicioso en OptinMonster y TrustPulse durante aproximadamente 25 minutos el 12 de junio, primero alrededor de las 22:17 UTC y desapareció a las 22:42 UTC. La exposición de PushEngage duró aún más, varias horas el 12 de junio, y el guión se entregó desde algunos de los servidores de CDN hasta el 14 de junio.
Por lo tanto, los dos complementos con más sitios tenían las ventanas más pequeñas y PushEngage tenía la más grande.
Sansec estima que los tres complementos llegan a más de 1,2 millones de sitios entre ellos, lo que representa la mayoría de los sitios donde OptinMonster por sí solo tiene más de 1 millón de instalaciones activas. PushEngage tiene más de 9000 complementos de WordPress. Este número no es daño sino alcance. Cuente los sitios que ejecutan complementos, no los sitios comprometidos.
Cómo funciona el ataque
El script envenenado no hizo nada en las páginas vistas normales. Esto solo funciona si lo carga un administrador de WordPress que ha iniciado sesión y luego usa la sesión de ese administrador para tomar el control.
Este diseño es también la razón por la que el panel de WordPress no puede indicarle si ha sido atacado. La única verificación confiable está en el servidor mismo, ya que las puertas traseras están diseñadas para evitar las pantallas de administración.
En el caso de PushEngage, los archivos comprometidos eran pushengage-web-sdk.js y Pushengage-subscription.js, archivos incrustados regulares proporcionados por clientcdn.pushengage.com, una red de entrega de contenido que envía los scripts de PushEngage a los sitios de los clientes. OptinMonster y TrustPulse se vieron afectados por otro punto final de Awesome Motive CDN.
PushEngage dijo que el resto de sus sistemas estaban intactos y no encontró evidencia de que se hubiera accedido a sus principales aplicaciones o servidores que contienen datos de clientes.
Cuando un administrador inicia sesión y ejecuta el script en la propia cuenta de PushEngage, se ve así:
Operando con privilegios completos usando la sesión de ese administrador, creó una nueva cuenta de administrador bajo el control del atacante, instaló un complemento que no estaba visible en el tablero y envió nuevos detalles de inicio de sesión e información del sitio a un dominio falso, tidio(.)cc, que se hizo para parecerse al tidio.com real.
Sansec encontró la misma secuencia en los tres complementos. El dominio tidio(.)cc se registró el 28 de abril, varias semanas antes del ataque, lo que indica una operación planificada en lugar de un ataque rápido.
Los complementos ocultos son los verdaderos tesoros. Esto abre el llamado web shell o canal de comando remoto. Cualquiera que conozca la URL correcta puede ejecutar código en su servidor sin iniciar sesión. Desde allí, el atacante puede leer o modificar archivos arbitrarios, copiar bases de datos, instalar más puertas traseras, inyectar código de robo de tarjetas, redirigir a los visitantes o robar datos.
Las cuentas de administrador adicionales se pueden restaurar fácilmente si elimina el complemento pero pierde su cuenta. Además, eliminar el complemento y la cuenta especificados puede no ser suficiente, ya que el atacante puede ejecutar el código libremente. Tanto Sansec como PushEngage dicen que esperan que queden otras puertas traseras.
¿Cómo entró el atacante?
Aquí es donde las dos versiones no están de acuerdo. PushEngage dijo que los atacantes primero explotaron una falla conocida en UpdraftPlus, un complemento de respaldo de WordPress, para comprometer los servidores que ejecutan el sitio web de marketing de la compañía. Ese servidor está separado de los sistemas que ejecutan el producto y almacenan los datos del cliente.
Lo que importaba no era el servidor en sí, sino la clave en el servidor: la clave API de CDN. Con esta clave, un atacante ya no necesitaba comprometer el sistema principal de PushEngage. Puede simplemente modificar los archivos que la CDN ya entrega a los sitios de los clientes.
Sansek no está convencido de que se haya resuelto el punto de entrada. Dice que aún no está claro dónde se vio comprometido el sistema, probablemente en los propios servidores de Awesome Motive, posiblemente en una cuenta CDN, y menos probablemente en el proveedor de CDN BunnyNet.
El análisis público de Sansec no verifica ni respalda la teoría de UpdraftPlus. Esa cuenta es únicamente de PushEngage para su propio entorno. UpdraftPlus tiene otro error de omisión de autenticación, CVE-2026-10795, que Wordfence califica con 8.1 (alta gravedad). Ahora está parcheado y Wordfence también ha informado de ataques en su contra, por lo que cualquiera que ejecute UpdraftPlus debería actualizarlo pase lo que pase.
No se ha confirmado si el error está relacionado con la última intrusión. Los puntos de entrada se considerarán no resueltos.
Qué comprobar y qué hacer
Según el cronograma de Sansec, los archivos OptinMonster y TrustPulse se limpiaron el 13 de junio, pero el script PushEngage permaneció en algunos servidores CDN hasta el 14 de junio. PushEngage dice que todavía está funcionando dentro del marco de tiempo correcto y desde entonces reemplazó los archivos defectuosos, borró el caché de CDN, cambió las claves de CDN y todas las credenciales asociadas y migró el sitio de marketing a la nueva infraestructura.
No hay nada que limpiar un sitio que ya ha sido comprometido.
Las puertas traseras están ocultas en su panel de control, por lo que no puede examinar WordPress y descartar una infracción. Si su sitio tenía alguno de los tres complementos ejecutándose durante la ventana de amenaza, la única solución confiable es un análisis del lado del servidor.
No intentes resolver el problema adivinando si has iniciado sesión o no. La mayoría de los propietarios no pueden probarlo de ninguna manera. Trate los siguientes pasos como base.
Ejecute un análisis del lado del servidor. Cualquiera que haya tenido PushEngage, OptinMonster o TrustPulse activos durante la ventana debería escanear el servidor directamente. Las comprobaciones del navegador o del panel de control omitirán las cargas útiles que se ejecutan solo para los administradores que han iniciado sesión. (Sansec vio la misma carga útil en los tres complementos, pero no vio OptinMonster y TrustPulse entregados de la misma manera o en la misma ventana que PushEngage). Verifique el sistema de archivos, no el panel. En wp-content/plugins, busque una carpeta llamada content-delivery-helper (‘Ayudante de entrega de contenido’) o optimizador de base de datos (‘Optimizador de base de datos’). Confía en lo que hay en el disco. Elimine cualquier cuenta de administrador que no haya creado, especialmente aquellas que coincidan con desarrollador_api1 o dev_xxxxxx. Por favor revise el registro. Examine los registros de acceso al servidor web del 12 al 14 de junio (UTC) para detectar tráfico saliente a tidio.cc (que contiene la ruta /cdn-cgi/) y al servidor del atacante (84.201.6.54). Si encuentras algo, asume lo peor. Rote todo, incluidas las contraseñas de administrador, las claves API, las credenciales de la base de datos y las claves privadas (sales) en wp-config.php. Ejecutar su código en el servidor puede generar más persistencia.
Source link
