Me hackearon un subdominio: el agujero no era WordPress, era el DNS

Hace unos días abrí Google Search Console para revisar cómo iba la indexación de mi blog y me encontré con algo que no esperaba: treinta páginas de casinos online, en polaco, ruso, azerí, checo e italiano, publicadas dentro de uno de mis propios subdominios. Mostbet, 1xbet, Pin-Up, Vavada. Ninguna la había creado yo.

Escribo sobre seguridad WordPress. Tengo una herramienta forense propia y una guía publicada sobre cómo detectar un sitio comprometido. Y aun así, esto me pasó a mí. Lo cuento porque el diagnóstico final terminó siendo bastante más interesante que el incidente en sí: el problema real no estaba en WordPress ni en un plugin desactualizado. Estaba en una configuración de DNS que llevaba meses ahí, a la vista, y que yo mismo había dejado pasar.

Cómo lo detecté (y por qué no fue un plugin)

No me avisó ningún sistema de monitoreo. No saltó una alerta. El subdominio comprometido no tenía instalado ningún plugin de seguridad, ni Wordfence ni ningún otro, porque era un proyecto abandonado que en mi cabeza “no existía”.

Lo detecté en Google Search Console, revisando el informe de páginas no indexadas. Ahí, mezcladas entre mis páginas legítimas marcadas con noindex, aparecían decenas de URLs con títulos como “Najpopularniejsze promocje Mostbet” o “Aktual’noe zerkalo Vavada na segodniashnii den'”, todas colgando de un subdominio mío.

Ese detalle es la primera lección del incidente: el sistema que me avisó no fue una herramienta de seguridad, sino una de SEO. Google rastreó, indexó y me reportó contenido que yo no había publicado. Si no hubiera estado revisando Search Console por otro motivo, ese spam podría haber seguido creciendo durante meses sin que nadie lo notara.

El método que uso y recomiendo para verificar esto en cualquier sitio es el más simple que existe: buscar en Google site: seguido del dominio. Si aparecen páginas que tú nunca creaste, hay una inyección de contenido activa. Toma diez segundos y no requiere instalar nada.

Qué era ese subdominio (y por qué eso importa)

El subdominio comprometido alojaba un SaaS que había empezado a construir hacía meses y que nunca llegué a usar. Un WordPress levantado para prototipar, sin tráfico, sin usuarios, sin datos de clientes, sin plugins de seguridad y —lo más relevante— sin nadie mirándolo.

Esto encaja con un patrón que veo constantemente en las auditorías que hago: el problema casi nunca está en el sitio principal, el que el dueño revisa todos los días. Está en el proyecto paralelo, el entorno de pruebas, la versión antigua que quedó arriba “por si acaso”, el subdominio de una campaña que terminó hace dos años.

Y hay algo que conviene entender sobre este tipo de ataques: al atacante no le interesaba mi contenido. No buscaba robarme información ni tumbarme el sitio. Buscaba un servidor con reputación de dominio donde publicar enlaces de casino para posicionarlos en Google. Es un ataque de Blackhat SEO puro, automatizado, indiscriminado, y el objetivo era usar mi infraestructura como plataforma de publicación.

Por eso da lo mismo que un proyecto “no tenga nada valioso”. El valor no está en lo que guardas: está en que el servidor existe, responde y tiene un dominio con historial.

El diagnóstico real: el problema no era WordPress

Acá es donde el caso se pone interesante, y donde encontré algo que la mayoría de las guías sobre sitios hackeados no cubre.

Mi primer instinto fue el de siempre: revisar la versión de WordPress, buscar plugins vulnerables, auditar usuarios administradores. Todo eso es correcto y hay que hacerlo. Pero cuando fui a revisar la configuración de DNS en Cloudflare, encontré la causa estructural.

Mis registros DNS se veían así:

Subdominio	Estado
Dominio principal	Redirigido mediante proxy ✅
WordPress principal	Redirigido mediante proxy ✅
Subdominio del SaaS	Solo DNS ❌
Otro subdominio antiguo	Solo DNS ❌

En Cloudflare, cada registro DNS puede estar en dos modos. “Redirigido mediante proxy” (la nube naranja) significa que todo el tráfico pasa primero por la red de Cloudflare: se aplica el firewall de aplicación, el límite de peticiones, la protección contra ataques automatizados, y —crucialmente— la dirección IP real de tu servidor queda oculta detrás de la de Cloudflare.

“Solo DNS” (la nube gris) significa que Cloudflare únicamente resuelve el nombre y se aparta. No filtra nada. El visitante —o el bot— llega directo a tu servidor.

Mi subdominio comprometido estaba en “Solo DNS”. Sin firewall, sin filtro, sin límite de peticiones. Un WordPress desatendido, expuesto de forma directa a internet.

La consecuencia que casi nadie considera

Pero el problema de fondo es peor que eso, y me tomó un momento darme cuenta.

Cuando un solo subdominio está en modo “Solo DNS”, su registro revela públicamente la dirección IP real de tu servidor de origen. Cualquiera puede consultarlo con una herramienta pública de DNS en segundos.

Y si ese servidor aloja además otros sitios que sí están protegidos por proxy, esa protección se puede saltar por completo: basta con atacar la IP directamente, ignorando el nombre de dominio. Todo el trabajo de configurar el firewall, las reglas de seguridad y el proxy queda anulado por un único registro mal configurado en un proyecto que ya no usabas.

En mi caso, en ese mismo servidor conviven otros dos sitios, uno de ellos de un cliente. Un subdominio olvidado no solo se comprometió a sí mismo: expuso la infraestructura completa.

⚠️ ¿Tienes subdominios que ya no usas? Si tienes entornos de prueba, versiones antiguas o proyectos abandonados apuntando a tu servidor, escríbeme por WhatsApp y revisamos juntos cuáles están expuestos. Es una revisión de quince minutos que puede ahorrarte un incidente completo.

Qué hice: contención en cuatro pasos

Apliqué el mismo protocolo que recomiendo en mi guía sobre qué hacer en las primeras horas tras un hackeo, con una diferencia importante que explico más abajo.

Paso 1: Respaldo forense antes de tocar nada. Descargué una copia completa del estado infectado —archivos y base de datos— a mi computador local. Aunque contenga malware, ese respaldo es la única evidencia disponible para analizar después cómo se produjo la intrusión. Borrar primero y preguntar después destruye información que no se recupera.

Paso 2: Revisión del resto de la infraestructura. Antes de limpiar el sitio comprometido, verifiqué si el atacante había saltado lateralmente a los otros sitios del mismo servidor. Cuando varios proyectos comparten un servidor, una intrusión en uno puede escalar a los demás según cómo estén configurados los permisos. Esta revisión es más urgente que limpiar el sitio afectado: si hay propagación, limpiar solo uno es inútil.

Paso 3: Eliminación completa. Acá tomé una decisión que va contra el instinto: no limpié el sitio, lo borré entero. Panel de control, base de datos, usuario del sistema y archivos.

Paso 4: Rotación de credenciales. Cambié las contraseñas de todo el panel de administración del servidor, los accesos SSH, y las credenciales de los otros sitios alojados. Cuando un servidor se compromete, hay que asumir que el atacante pudo ver más de lo que dejó a la vista.

Por qué borré en vez de limpiar

Esta es la parte que suele generar discusión, así que la explico con criterio.

Limpiar un WordPress comprometido bien hecho toma horas: hay que reemplazar el núcleo, auditar la base de datos tabla por tabla buscando inyecciones ofuscadas, revisar los archivos de configuración, verificar que no quedaron puertas traseras en la carpeta de cargas. Y aun haciéndolo con rigor, siempre queda la duda. Los ataques de Blackhat SEO suelen dejar varios puntos de reentrada, y basta que sobreviva uno para que el sitio se reinfecte en días.

Ese esfuerzo se justifica cuando el sitio tiene valor: contenido, historial de posicionamiento, usuarios, datos de clientes. En mi caso, no tenía nada de eso. Era un prototipo abandonado.

La regla que aplico es simple: si el costo de reconstruir es menor que el costo de limpiar con certeza, se reconstruye. Cuando el sitio sí tiene valor —una tienda con historial de ventas, un sitio corporativo con años de posicionamiento— la ecuación se invierte y ahí sí corresponde el trabajo forense completo.

Lo que cambié después (y lo que deberías revisar tú)

El incidente cerró con un inventario que debí haber hecho hace mucho:

Auditoría completa de registros DNS. Revisé los catorce registros del dominio uno por uno y respondí tres preguntas para cada uno: ¿esto sigue vivo?, ¿está en proxy o expuesto directo?, ¿alguien lo está mirando? Los que no pasaron el filtro, se eliminaron.

Eliminación de subdominios huérfanos. Encontré un segundo subdominio apuntando al servidor sin ningún sitio asociado, probablemente residuo de una configuración antigua. Cada registro DNS que no cumple una función activa es superficie de ataque gratuita.

Proxy obligatorio. Todo subdominio que apunte a mi servidor va con proxy activado. Sin excepciones, aunque sea un entorno de pruebas.

Restricción a nivel de firewall. El servidor ahora acepta tráfico web únicamente desde los rangos de IP de Cloudflare. Aunque alguien conozca la dirección de origen, no puede llegar al puerto web saltándose el proxy.

Retirada de URLs en Search Console. Solicité la eliminación del índice de todas las URLs de spam. Google las retira solo con el tiempo, pero la solicitud acelera bastante el proceso.

Sobre la Ley 21.719: por qué en este caso no aplicó

Vale la pena aclarar este punto, porque en la mayoría de los incidentes sí aplica.

La Ley 21.719 de Protección de Datos Personales establece que, ante una vulneración que comprometa datos personales, existe la obligación de notificar a la Agencia de Protección de Datos Personales en un plazo máximo de 72 horas desde que se toma conocimiento del hecho. El Artículo 34 quáter califica la omisión intencional de reportar como infracción gravísima, con multas de hasta 20.000 UTM.

En este caso concreto no se activó esa obligación, y la razón es una sola: el subdominio comprometido no almacenaba datos personales de terceros. Era un prototipo sin usuarios, sin formularios activos y sin base de clientes.

Si el mismo ataque hubiera ocurrido en un sitio con formularios de contacto, una tienda con clientes registrados o una base de suscriptores, la situación sería completamente distinta: además del trabajo técnico de contención, habría que evaluar el alcance de la exposición y cumplir con el deber de notificación dentro del plazo legal.

Es un matiz que conviene tener claro antes de que la fiscalización comience en diciembre de 2026. La obligación no depende de la gravedad técnica del ataque, sino de si había datos personales involucrados.

Lo que no sé (y por qué lo digo)

Hay algo que este artículo no puede responder: no tengo certeza del vector exacto de entrada.

Sé que era un WordPress desatendido, sin proxy, sin plugins de seguridad y sin actualizaciones recientes. Cualquiera de esas condiciones basta para explicarlo, y probablemente fue una combinación. Pero no puedo afirmar con precisión forense por dónde entraron ni cuánto tiempo estuvieron dentro antes de que Google indexara el primer contenido.

Lo digo explícitamente porque encontrarás muchas guías que reconstruyen ataques con un nivel de certeza que rara vez se tiene en la práctica. Cuando un sitio no tiene registros de acceso conservados ni monitoreo previo, buena parte del análisis posterior es inferencia razonable, no evidencia.

Y esa es, quizás, la lección más incómoda del incidente: no tener visibilidad no solo te impide prevenir el ataque, también te impide entenderlo después.

Preguntas frecuentes

¿Puede pasarme esto si mi sitio no tiene nada valioso? Sí, y de hecho es el escenario más frecuente. Los ataques de Blackhat SEO no buscan tu información: buscan un servidor con dominio activo donde publicar contenido. Un sitio sin tráfico y sin datos es igual de útil para ese propósito, y suele estar peor protegido.

¿Qué significa exactamente que un subdominio esté en “Solo DNS”? Significa que Cloudflare resuelve el nombre pero no filtra el tráfico. No se aplica el firewall de aplicación ni la protección contra bots, y la dirección IP real de tu servidor queda visible públicamente. Es equivalente a tener el servidor conectado directamente a internet.

¿Un plugin de seguridad habría evitado esto? Probablemente habría ayudado a detectarlo antes, pero no era el problema de fondo. Un plugin de seguridad opera dentro de WordPress; la exposición estaba en la capa de red, por debajo. Ninguna cantidad de plugins compensa una infraestructura mal configurada.

¿Cómo reviso si tengo subdominios expuestos? Entra al panel de DNS de tu proveedor y revisa el estado de cada registro. En Cloudflare, los que aparecen como “Solo DNS” o con la nube gris están expuestos directo. Para cada uno, pregúntate si sigue cumpliendo una función: los que no, se eliminan.

¿Es necesario borrar un sitio comprometido o basta con limpiarlo? Depende del valor de lo que hay dentro. Si el sitio tiene contenido, posicionamiento, usuarios o datos de clientes, corresponde una limpieza forense completa. Si es un proyecto sin uso, reconstruir suele ser más rápido y más seguro que limpiar con certeza.

Cómo revisar tu propia infraestructura hoy

Para auditar el estado real de un sitio uso cinco herramientas gratuitas y públicas: PageSpeed Insights, Mozilla Observatory, SSL Labs, SecurityHeaders y Sucuri SiteCheck. Cualquiera puede correrlas y te dan una radiografía inicial del nivel de riesgo técnico.

A eso agrégale dos revisiones que la mayoría no hace y que en este caso fueron determinantes: buscar site:tudominio.cl en Google para detectar contenido inyectado, y auditar tus registros DNS uno por uno verificando cuáles están expuestos directo y cuáles corresponden a proyectos que ya no existen.

Si prefieres ahorrarte la interpretación de métricas, construí un escáner en mi sitio que consolida el análisis de rendimiento y los requisitos técnicos de la Ley 21.719 en un solo informe, con los datos que Google usa para evaluar tu sitio en conexiones móviles.

Y si al revisar tus subdominios encuentras algo que no te cuadra —un entorno de pruebas que quedó arriba, una versión antigua que nadie mira, un registro que no sabes de dónde salió— escríbeme por WhatsApp o agenda una sesión de diagnóstico. Esa revisión toma menos de lo que uno cree, y es exactamente el tipo de problema que solo se ve cuando alguien se sienta a mirarlo.