Steam como centro de mando: el ataque que infectó casi 2.000 sitios WordPress con comentarios invisibles y backdoors

Una campaña desarrollada desde julio de 2025 ha afectado a cerca de 1.980 sitios WordPress, según el análisis publicado por los equipos de seguridad de GoDaddy, y destaca por el uso creativo de una plataforma pública para ocultar su centro de mando (C2). En lugar de levantar servidores propios y exponerse a detección, los atacantes esconden instrucciones dentro de comentarios en perfiles de la comunidad Steam y luego hacen que el código malicioso en las páginas web comprometidas lea y decodifique esos comentarios para construir la URL desde la que descargar scripts dañinos.

La técnica se basa en caracteres Unicode invisibles —entre ellos variantes de zero-width y otros símbolos no imprimibles— intercalados en texto inocuo que sirve de camuflaje. El decodificador alojado en el sitio afectado ignora las letras visibles, mapea esas marcas invisibles a números, genera una secuencia binaria y reconstruye bytes que conforman la dirección remota del código malicioso. El resultado final es la carga de JavaScript que se hace pasar por bibliotecas legítimas y que, a su vez, establece un mecanismo persistente y un backdoor en PHP.

El backdoor descrito por GoDaddy acepta peticiones POST autenticadas mediante una cookie específica y puede ejecutar código PHP enviado codificado en base64; además, los operadores emplean técnicas de camuflaje adicionales como nombres de funciones aleatorios, cadenas escapadas en octal/hex y el abuso de APIs estándar de WordPress para mezclarse con tráfico legítimo. Todo esto reduce las señales que alertan a defensores automatizados y administradores desprevenidos.

Usar un servicio de terceros muy popular como Valve/Steam para transportar señales C2 tiene implicaciones importantes: por un lado, dificulta que los escáneres que se basan en listas negras detecten las comunicaciones porque la infraestructura de Steam es legítima y masiva; por otro, facilita la supervivencia del atacante porque evita la necesidad de mantener una infraestructura propia. Para entender mejor la superficie utilizada por los atacantes puede consultarse la página de la comunidad de Steam en steamcommunity.com, y para el informe técnico de respuesta y mitigación consultar directamente el análisis publicado por GoDaddy en GoDaddy Security.

Para los administradores de sitios WordPress la recomendación principal y más segura es restaurar desde una copia de seguridad conocida buena anterior a la intrusión. Si esto no es viable, limpiar manualmente requiere extrema exhaustividad: hay que buscar e eliminar cualquier backdoor que acepte reimplantaciones, rotar todas las credenciales (paneles de administración, FTP/SFTP, bases de datos, tokens API), forzar la renovación de claves, habilitar autenticación multifactor y revisar los permisos de archivos y usuarios. También conviene bloquear a nivel de red las conexiones salientes hacia dominios relacionados con la campaña (por ejemplo hello-mywordl[.]info, identificado por los investigadores) y monitorizar peticiones con parámetros sospechosos como el uso de un parámetro new_code o la presencia de la cookie de control.

En términos preventivos es crucial reducir la superficie de ataque: mantener WordPress, temas y complementos actualizados; eliminar plugins y temas no utilizados; minimizar cuentas con privilegios administrativos; utilizar un WAF y monitorización de integridad de ficheros; y aplicar políticas de autenticación robustas y rotación periódica de contraseñas. La guía oficial para endurecer WordPress ofrece medidas prácticas y recomendadas por el propio proyecto en wordpress.org, y debe ser punto de partida para cualquier responsable de sitio.

En el plano operativo, hay indicadores simples de búsqueda que ayudan a detectar infecciones: referencias a URLs de Steam en el código, inyecciones de JavaScript externas en páginas front-end, entradas de caché anómalas (por ejemplo relacionadas con _transient_caption_), comprobaciones cURL con verificación SSL deshabilitada y registros de peticiones POST que incluyan la cookie de control o payloads codificados. Sin embargo, debido a la evasión y persistencia de estos artefactos, contar con respuesta profesional o con la asistencia del proveedor de hosting suele ser la opción más sólida cuando la limpieza manual supera las capacidades internas.

El ataque muestra cómo actores maliciosos combinan técnicas antiguas (credential stuffing, plugins vulnerables o compromisos en la cadena de suministro) con ingeniería creativa de canales C2. Para los responsables de seguridad esto confirma una lección recurrente: la visibilidad de las comunicaciones salientes y la higiene de credenciales son tan importantes como las defensas perimetrales; ignorarlas deja la puerta abierta a amenazas que se esconden donde menos se espera.