Una cartera de 130 sitios WordPress parecía limpia. Google Ads Sabía que algo andaba mal.

La situación

Un cliente nos trajo después de hacerse cargo de una cartera de 130 sitios WordPress de una agencia anterior. Todos los sitios del portafolio estaban ejecutando Google Ads. A las pocas semanas de la transferencia, las cuentas publicitarias comenzaron a ser marcadas y suspendidas por violaciones de políticas, una tras otra. Para el propietario de una agencia que intentaba ganarse la confianza de 130 clientes desde el primer día, el momento no podría haber sido peor. Los sitios se cargaron perfectamente. Los patrones de tráfico parecían normales. No hubo mensajes de error, ni quejas de visitantes, ni alertas del servidor. Sin embargo, todas y cada una de las propiedades se vieron comprometidas. La infección había estado funcionando completamente sin ser detectada.

Por qué nadie lo pilló

La mayoría del malware se anuncia solo. Este fue construido para hacer lo contrario.

El complemento oculto

La infección se produjo en forma de un complemento PHP con un nombre genérico y corriente. Se instaló solo como cualquier otro complemento, pero usó un filtro WordPress para eliminarse de la pantalla de complementos de administración. No había nada que encontrar en el tablero. La única forma de detectarlo era a través de FTP o acceso directo al servidor. Las auditorías de complementos estándar, del tipo que realizan la mayoría de las agencias, resultaron limpias.

El servidor de entrega solo entregó JavaScript real a los navegadores que llegaron con señales de sesión Google Ads activas. Los escáneres de seguridad obtuvieron un archivo en blanco. Los rastreadores automatizados obtuvieron un archivo en blanco. Cualquiera que abriera la URL del script en una pestaña del navegador obtuvo un archivo en blanco. Cada escaneo decía limpio porque, en cada escaneo, lo era. Las únicas personas que vieron lo que realmente estaba haciendo el malware fueron las que hicieron clic en los anuncios pagados.

Acceso de administrador oculto

Integrada en el complemento había una puerta trasera codificada. Pasar un parámetro GET específico en una URL registraría inmediatamente al atacante como el primer administrador del sitio, sin contraseña, sin solicitud de dos factores, nada. Una petición. Acceso completo. Esto significaba que el atacante podía regresar a cualquier sitio en cualquier momento, independientemente de cuántas veces se hubieran restablecido las contraseñas.

Escrituras de archivos no autorizadas

El complemento registró un punto final API REST abierto a cualquier persona en Internet. No se requirió autenticación. A través de este punto final, un atacante podría insertar código PHP arbitrario directamente en archivos de temas del sitio. El complemento también borraba activamente todos los complementos de almacenamiento en caché principales después de cada escritura, por lo que el código inyectado estaría activo y serviría a visitantes reales en cuestión de segundos.

Redirecciones de solo clic en anuncios

En cada carga de página, el complemento realizó una llamada del lado del servidor a un servidor externo, recuperó una URL codificada en base64, la decodificó e inyectó una etiqueta de secuencia de comandos en la parte superior de la página antes de enviar cualquier otro contenido al visitante.

Cada visitante cargó este script en cada página. La lógica de redireccionamiento interna solo se activaba para los visitantes que acababan de hacer clic en un anuncio de Google. Los visitantes directos, el tráfico orgánico, cualquiera que navegara normalmente no vio nada malo.

La URL de destino nunca se almacenó en el sitio. Fue extraído del servidor del atacante en cada carga de página. El dominio de entrega rotaba cada uno o dos días. Entonces, el ciclo transcurrió así: Google marca una URL y suspende la cuenta, el cliente pasa por el restablecimiento, la cuenta vuelve a estar activa, los anuncios se ejecutan nuevamente, Google marca el nuevo dominio, la cuenta se suspende nuevamente. La infección siguió propagándose en cada reinstalación porque nadie sabía cómo buscarla.

El data-cfasync='false' El atributo en la etiqueta del script no fue accidental. Le indica al Rocket Loader de Cloudflare que deje el script en paz, lo que significa que el código malicioso se ejecutó antes de que cualquier procesamiento de Cloudflare pudiera tocarlo.

Mecanismo de reinfección incorporado

Aprendimos desde el principio que simplemente eliminar el complemento no era suficiente. El malware ya había incorporado un reinstalador en wp-cron.php que podía recrear una copia nueva de sí mismo con un nombre de directorio diferente. También había incrustado cargas útiles PHP cifradas con AES-256 dentro de archivos en el directorio /patterns/ del tema, archivos que parecían archivos de plantilla comunes para cualquiera que navegara por la carpeta. Esas cargas útiles solo se ejecutarían si el atacante pasara la clave de descifrado correcta a través de los parámetros de URL.

Limpiamos un sitio y lo dejamos deliberadamente sin la capa de seguridad adicional para ver qué pasaba. Se volvió a infectar a las 24 horas. Esa prueba marcó todo lo que siguió.

De dónde vino la infección

La evidencia apuntaba a una herramienta de gestión WordPress comprometida utilizada en toda la cartera. Como la misma herramienta estaba conectada a los 130 sitios, la exposición se extendió a toda la cartera. Varios de los sitios tenían Wordfence instalado y activo en todo momento. No detectó la infección ni evitó la reinfección.

La infraestructura de entrega reveló una operación con más alcance que un solo mal actor con un servidor barato. Los dominios rotativos que alojan los archivos JavaScript maliciosos no pertenecían al atacante. Eran otros sitios WordPress comprometidos que pertenecían a organizaciones no relacionadas que no tenían idea de que se estaban utilizando sus servidores. Un dominio de entrega que identificamos se resolvió en el mismo servidor que una conocida organización sin fines de lucro internacional. El atacante agregó su dominio como host virtual, plantó el archivo, lo usó durante un par de días y luego siguió adelante. Cuando cualquier investigación llegó a un dominio en particular, el archivo ya había desaparecido.

lo que hicimos

Trabajamos en cada sitio individualmente, completando la secuencia completa en cada uno antes de pasar al siguiente. El trabajo parcial en una obra no era una opción, dado lo que había demostrado la prueba de reinfección. La secuencia en cada sitio fue la corrección del sistema de archivos, la limpieza de la base de datos, la rotación de credenciales y el fortalecimiento. 130 sitios en 15 días.

Remediación del sistema de archivos

WordPress se reinstalaron los archivos principales a partir de sumas de verificación verificadas en cada sitio. Los directorios no principales se inspeccionaron manualmente y se eliminaron archivos PHP no autorizados, incluidas las cargas útiles cifradas en los directorios de patrones temáticos y cualquier otra cosa que no tuviera por qué estar allí. La edición de archivos a través del administrador WordPress se deshabilitó en el nivel de configuración para cerrar esa ruta para escrituras futuras.

Remediación de base de datos

Las cadenas de JavaScript inyectadas se ubicaron y eliminaron de las tablas wp_posts y wp_options en la base de datos de cada sitio. Esto requirió cuidado para eliminar el contenido malicioso sin corromper los datos legítimos. Los ganchos de redireccionamiento condicional aparecieron en la fuente.

Rotación y endurecimiento de credenciales

Se finalizaron todas las sesiones activas, se eliminaron las cuentas de administrador no autorizadas y se rotaron las credenciales en todas las propiedades. Luego se aplicó una configuración de seguridad consistente a cada sitio para cerrar las superficies de ataque que había utilizado el malware: protecciones de inicio de sesión, cambios de permisos de archivos, reducción de la superficie de ataque en toda la configuración WordPress e invalidación de todas las sesiones existentes. La configuración que faltaba en el sitio de prueba de reinfección estaba finalmente implementada en los 130.

El resultado

Tres meses después, los 130 sitios siguen limpios. Sin reinfecciones, sin redireccionamientos, sin cuentas de administrador fraudulentas.

Proporcionamos la evidencia de remediación técnica que el cliente necesitaba para avanzar en el proceso de reinstalación Google Ads. Una vez verificados los dominios limpios y presentada la documentación, las cuentas regresaron sin las suspensiones recurrentes que habían definido las semanas anteriores.

Ahora existe un compromiso continuo que cubre toda la cartera. Los sitios de alto perfil reciben una auditoría manual semanal: verificaciones de integridad de archivos, revisión de registros de seguridad, monitoreo de cuentas de usuario y validación de copias de seguridad, con un informe escrito después de cada sesión. La cartera más amplia recibe un ciclo de revisión mensual.

La razón por la que el cliente quería una cobertura continua es sencilla. La infección transcurrió sin un solo indicador visible durante semanas. Lo único que lo marcó fue que Google retiró las cuentas publicitarias. Una vez que haya visto un ataque ejecutarse tan silenciosamente durante tanto tiempo, la pregunta de si su configuración actual detectaría algo similar se vuelve mucho más difícil de responder con confianza.

Qué significa esto para las carteras gestionadas por agencias

Si administra WordPress sitios para clientes que publican publicidad paga, las mismas condiciones que permitieron esta infección son comunes en todas las carteras administradas por agencias.

No hay señal visible

El administrador WordPress puede parecer limpio. El sitio puede cargarse normalmente. Es posible que los escáneres no informen ningún problema. El tráfico pago aún puede verse comprometido. Infecciones como ésta suelen aparecer durante semanas antes de que aparezca algo, y cuando lo hacen, suele ser una suspensión Google Ads lo que las revela, no una alerta de seguridad.

Su herramienta de gestión puede convertirse en un único punto de fallo

La administración centralizada es eficiente, pero si la herramienta se ve comprometida, la exposición puede extenderse a todos los sitios conectados simultáneamente. Asumir que una plataforma confiable es segura de usar no es lo mismo que saber que lo es.

La limpieza sin endurecer crea un bucle.

Eliminar el malware no es lo mismo que cerrar el punto de entrada. En este caso, un sitio limpio sin la capa endurecida añadida se volvió a infectar en 24 horas. Hay que cerrar los puntos de entrada o el ciclo comienza de nuevo.

Las herramientas automatizadas no son suficientes

Esta infección fue diseñada para ocultarse de los escáneres y del administrador WordPress. Encontrarlo requirió una revisión directa del sistema de archivos, una inspección de la base de datos y pruebas de comportamiento. Los complementos de seguridad activos en varios sitios no detectaron nada durante todo el período de infección.