Un atacante manipuló archivos JavaScript confiables utilizados por los sitios de WordPress que ejecutan EmpujarEngage, OptinMonstery ConfianzaPulseconvirtiendo esos archivos en una forma de ingresar a los sitios.
Cuando un administrador del sitio iniciaba sesión mientras se cargaba el archivo, el código creaba una cuenta de administrador bajo el control del atacante e instalaba un complemento oculto que abría un camino de regreso. Los visitantes comunes no lo activaban.
Cualquier sitio afectado debe tratarse como comprometido. Los tres complementos son administrados por una empresa, Awesome Motive, que no había comentado sobre los dos complementos más grandes hasta el 15 de junio.
Empresa de seguridad sansec reveló la campaña más amplia el 13 de junio y encontró el mismo código malicioso en JavaScript servido para los tres complementos.
PushEngage siguió un día después con el suyo propio. aviso de incidenteconfirmando que un atacante había entregado copias manipuladas de su script y que los sitios que las cargaban podrían ser secuestrados.
PushEngage, adquirida por Awesome Motive hace años, es hasta ahora el único de los tres que publica orientación; Los usuarios de OptinMonster y TrustPulse no han escuchado nada oficial.
La ventana no era la misma para cada complemento. Sansec vio el código malicioso en OptinMonster y TrustPulse durante solo unos 25 minutos el 12 de junio, primero alrededor de las 22:17 UTC y desapareció a las 22:42. La exposición de PushEngage duró más: varias horas el 12 de junio, y su script todavía estaba siendo servido desde algunos de los servidores de CDN hasta el 14 de junio.
Entonces, los dos complementos con más sitios tenían la ventana más pequeña 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, la mayor parte de OptinMonster, que por sí solo tiene más de un millón de instalaciones activas. PushEngage complemento de WordPress Tiene más de 9.000. Esa cifra es alcance, no daño: cuenta los sitios que ejecutan los complementos, no los sitios en los que fueron pirateados.
Cómo funcionó el ataque
El script envenenado no hizo nada en una vista de página normal. Actuó solo cuando un administrador de WordPress que había iniciado sesión lo cargó y luego usó la sesión de ese administrador para tomar el control.
Ese diseño también es la razón por la que el panel de WordPress no puede decirle si fue atacado: la puerta trasera está diseñada para permanecer fuera de las pantallas de administración, por lo que la única verificación confiable está en el servidor.
En el caso de PushEngage, los archivos manipulados eran sus incrustaciones normales, pushengage-web-sdk.js y pushengage-subscription.js, servidos desde clientcdn.pushengage.com, la red de entrega de contenido que envía el script de PushEngage a los sitios de los clientes. OptinMonster y TrustPulse se vieron afectados a través de puntos finales separados de Awesome Motive CDN.
PushEngage dice que el resto de sus sistemas permanecieron intactos: no encontró señales de que su aplicación principal o los servidores que contienen datos de los clientes hubieran sido alcanzados.
Según la propia cuenta de PushEngage, una vez que el script se ejecutó con un administrador conectado,:
- usó la sesión de ese administrador para actuar con permisos completos,
- creó una nueva cuenta de administrador bajo el control del atacante,
- instaló un complemento que no aparece en el panel de control y
- Envié los nuevos detalles de inicio de sesión y la información del sitio a tidio.[.]cc, un dominio falso creado para parecerse al tidio.com real.
Sansec encontró la misma secuencia en los tres complementos. el tidio[.]El dominio cc se registró el 28 de abril, semanas antes del ataque, lo que apunta a una operación planificada en lugar de un ataque rápido.
El complemento oculto es el verdadero premio. Abre lo que se conoce como un shell web, un canal de comando remoto: cualquiera que conozca la URL correcta puede ejecutar código en el servidor sin iniciar sesión. Desde allí, el atacante puede leer o cambiar cualquier archivo, copiar la base de datos, instalar más puertas traseras, inyectar código de robo de tarjetas, redirigir a los visitantes o robar datos.
La cuenta de administrador adicional es una forma sencilla de regresar si elimina el complemento pero pierde la cuenta. Y debido a que el atacante puede ejecutar código libremente, eliminar el complemento y la cuenta nombrados puede no ser suficiente; Tanto Sansec como PushEngage dicen asumir que podrían quedar otras puertas traseras.
Cómo entró el atacante
Ésta es la parte en la que los dos relatos no están de acuerdo. PushEngage dice que el atacante primero irrumpió en el servidor que ejecuta su sitio web de marketing, a través de una falla conocida en UpdraftPlusun complemento de copia de seguridad de WordPress. 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 que contenía: una clave CDN API. Con esa clave, el atacante no necesitaba ingresar a los sistemas principales de PushEngage. Simplemente podría cambiar los archivos que la CDN ya estaba entregando a los sitios de los clientes.
Sansec no está convencido de que el punto de entrada esté resuelto. Dice que el sistema violado aún se desconoce, siendo los propios servidores de Awesome Motive el lugar más probable, la cuenta CDN posible y el proveedor de CDN, BunnyNet, poco probable.
El análisis público de Sansec no examina ni respalda la teoría UpdraftPlus; esa cuenta proviene únicamente de PushEngage, sobre su propio entorno. UpdraftPlus tiene un error de omisión de autenticación independiente, CVE-2026-10795que Wordfence tiene una puntuación de 8,1 (alta gravedad); ahora está parcheado y Wordfence ha informado de ataques en su contra, por lo que cualquiera que ejecute UpdraftPlus debería actualizar pase lo que pase.
No se ha confirmado si ese error tuvo algo que ver con este robo. Trate el punto de entrada como inestable.
Qué comprobar y hacer
Según la línea de tiempo de Sansec, los archivos OptinMonster y TrustPulse estaban limpios el 13 de junio, mientras que el script de PushEngage permaneció en algunos servidores CDN hasta el 14 de junio. PushEngage dice que todavía está trabajando en la ventana exacta y desde entonces reemplazó los archivos defectuosos, borró el caché CDN, cambió la clave CDN y todas las credenciales relacionadas, y trasladó el sitio de marketing a una nueva infraestructura.
Nada de eso limpia un sitio que ya fue tomado.
 |
| Indicadores de compromiso (IoC) de Sansec |
Debido a que la puerta trasera se esconde del tablero, no se puede descartar un compromiso al mirar WordPress. Si su sitio ejecutó alguno de los tres complementos durante la ventana de amenaza, la única respuesta confiable es un análisis del lado del servidor.
No intente resolverlo adivinando si inició sesión; la mayoría de los propietarios no pueden probarlo de ninguna manera. Trate los pasos siguientes 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. Una verificación del navegador o del panel de control perderá una carga útil que solo se ejecutó para los administradores que iniciaron sesión. (Sansec vio la misma carga útil en los tres complementos, pero no confirmó que OptinMonster y TrustPulse se entregaran de la misma manera o en la misma ventana que PushEngage).
- Verifique el sistema de archivos, no el tablero. En wp-content/plugins, busque carpetas denominadas content-delivery-helper («Ayuda 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 desarrollador_api1 o cualquier cuenta que coincida con dev_xxxxxx.
- Revisa tus registros. Revise los registros de acceso al servidor web del 12 al 14 de junio UTC para ver el tráfico saliente a tidio.cc, incluidas sus rutas /cdn-cgi/, y al servidor del atacante en 84.201.6.54.
- Si encuentra algo, asuma lo peor. Gire todo: contraseñas de administrador, claves API, credenciales de base de datos y claves secretas (sales) en wp-config.php. Con la ejecución del código en el servidor, es posible que quede más persistencia.
