La noche anterior, mientras la web seguía en silencio, algo empezó a golpear la puerta.

No era una persona. No había un individuo sentado frente a una pantalla, probando contraseñas con la paciencia torpe de quien cree haber encontrado una rendija. Era otra cosa. Una secuencia. Un automatismo. Un martillo invisible cayendo una y otra vez sobre el mismo punto.

En el correo de Sofía comenzaron a entrar avisos del plugin de seguridad de WordPress. El sistema informaba de que alguien había sido bloqueado por intentar acceder con un nombre de usuario inexistente. Una de esas medidas aparentemente discretas, casi burocráticas, que solo se vuelven importantes cuando el buzón empieza a llenarse de alertas cada pocos segundos.

Sofía me escribió al día siguiente. El ataque había empezado de madrugada y, aunque su web no era una tienda online ni una plataforma con miles de usuarios, la sensación era la misma: alguien estaba intentando entrar. Ella misma lo resumía con una mezcla de incredulidad y nerviosismo: “pero si solo tengo noticias, no existirán blogs y cosas más candentes para romper…”. Poco después añadía algo todavía más claro: “qué miedo”. En aquel momento, además, venía de sufrir cierta presión en redes y no tardó en preguntarse si aquello tendría relación con sus haters. La amenaza técnica se había convertido, de golpe, en una sospecha personal.

La primera pista: demasiados golpes para una sola mano

Accedí al sitio y revisé el registro de actividad del plugin de seguridad. La escena era bastante reconocible: intentos repetidos de acceso, nombres de usuario que no existían en la base de datos y direcciones IP que cambiaban cada pocos intentos. Esa rotación de IPs complicaba cualquier lectura sencilla. Hoy parecía venir de un país; unos segundos después, de otro. El mapa no señalaba a un atacante concreto, sino a una red automatizada.

La web, además, no estaba desprotegida. El acceso convencional ya contaba con medidas de seguridad: formularios con reCAPTCHA, señuelos para bots y una URL nativa de WordPress modificada. En otras palabras, si alguien intentaba entrar por la puerta habitual, iba a encontrarse con varias trampas antes de llegar al pomo.

Pero los avisos seguían llegando.

Ahí estaba la clave. Si el acceso normal estaba protegido y aun así el bot insistía con tanta frecuencia, lo más probable era que no estuviera llamando a la puerta visible. Estaba golpeando otra entrada, más antigua, más técnica y muchas veces olvidada: el archivo xmlrpc.php.

Qué es XML-RPC y por qué lo atacan los bots

XML-RPC es una interfaz de WordPress pensada originalmente para permitir comunicaciones remotas con el sitio. Durante años fue útil para publicar desde aplicaciones externas, gestionar contenido o permitir ciertos servicios conectados. El problema es que esa misma puerta también puede ser aprovechada para lanzar ataques automatizados.

En un ataque de fuerza bruta, el objetivo es simple: probar combinaciones de usuario y contraseña hasta acertar. No hay detrás la  sofisticación de una novela de espías. Hay volumen. Hay insistencia. Hay una máquina lanzando intentos como quien arroja gravilla contra una ventana esperando que una piedra, por pura estadística, termine rompiendo el cristal.

La particularidad de XML-RPC es que puede permitir intentos de autenticación por una vía distinta al formulario de acceso normal. Algunos análisis de seguridad han documentado que este endpoint puede ser utilizado para ataques automatizados contra credenciales y, en ciertos casos, incluso para amplificar los intentos mediante métodos como system.multicall, lanzando muchas comprobaciones dentro de una sola petición.

Por eso, aunque cambiar la URL de acceso, añadir reCAPTCHA y bloquear usuarios inexistentes son buenas medidas, no siempre bastan si el bot está atacando por una ruta paralela. La puerta principal puede estar blindada, pero si el sótano conserva una trampilla oxidada, el ruido seguirá viniendo de abajo.

El momento de cerrar la trampilla

Tras revisar el patrón de intentos, la frecuencia de las alertas y la rotación de IPs, apliqué el bloqueo de XML-RPC desde All In One WP Security and Firewall. El resultado fue inmediato: los avisos cesaron.

No hubo persecución internacional. No hubo un villano con capucha en una habitación iluminada por monitores. Hubo una explicación más prosaica y, precisamente por eso, más inquietante: un bot había encontrado un endpoint expuesto y estaba probando suerte.

La web de Sofía no cayó. Nadie accedió al panel. No hubo pérdida de contenido. El plugin de seguridad había hecho su trabajo: detectar, bloquear y dejar rastro suficiente para investigar. Esa es la diferencia entre un susto y una incidencia grave. En seguridad web, muchas veces no se trata de que nunca llamen a tu puerta. Se trata de saber quién llama, cuántas veces, por dónde intenta entrar y qué mecanismo lo detiene antes de que llegue al salón.

El caso de Clave7: cuando el correo empieza a latir demasiado rápido

Un tiempo después, la escena se repitió en la web de Clave7.

Esta vez los avisos no le llegaron a una clienta. Me llegaron a mí. Decenas de correos en cuestión de minutos. Una notificación tras otra. El buzón empezó a comportarse como un detector de humo en una cocina cerrada: insistente, incómodo, imposible de ignorar.

Y ahí entendí mejor lo que Sofía había sentido.

Quienes trabajamos con WordPress podemos explicar estos ataques con cierta distancia técnica. Podemos hablar de endpoints, bots, XML-RPC, fuerza bruta, IPs rotatorias y registros de auditoría. Pero cuando el correo empieza a llenarse de alertas cada pocos segundos, hay una reacción más humana, más primitiva. Algo está pasando. Alguien está intentando entrar. La web está bajo ataque.

En mi caso, la detección fue rápida. Revisé el patrón, reconocí el comportamiento y apliqué la misma medida: bloqueo de XML-RPC desde el plugin de seguridad. Igual que en el caso de Sofía, el ataque se detuvo.

No era personal, pero sí era real

Una de las cosas más importantes que conviene entender sobre este tipo de ataques es que, en la mayoría de los casos, no son personales. El bot no sabe quién eres. No le importa si tienes un blog de cine, una web profesional, una emisora online o una tienda con cientos de pedidos. Va barriendo internet en busca de instalaciones WordPress con puntos de entrada conocidos.

Pero que no sea personal no significa que no sea peligroso.

Un ataque de fuerza bruta puede terminar comprometiendo una cuenta si las contraseñas son débiles, si se usan nombres de usuario evidentes o si no existen límites de acceso. También puede generar carga innecesaria en el servidor, llenar registros, saturar el correo de administración y crear una sensación de alarma difícil de gestionar para quien no vive todos los días entre paneles de hosting, plugins y logs.

Por eso es tan importante contar con una configuración de seguridad sólida. No basta con instalar WordPress, elegir un tema bonito y publicar contenido. Una web también necesita cerraduras, sensores y alguien que sepa interpretar las huellas cuando aparece barro en la alfombra.

La importancia de un buen plugin de seguridad

En ambos casos, la solución llegó gracias a tener instalado y configurado un plugin de seguridad capaz de detectar intentos sospechosos, bloquear accesos fraudulentos y registrar actividad. Sin esas alertas, el ataque habría podido pasar desapercibido durante mucho más tiempo.

All In One WP Security and Firewall permitió aplicar medidas concretas como el bloqueo de XML-RPC, el control de intentos de acceso con usuarios inexistentes y la monitorización de actividad sospechosa. Ese tipo de herramientas no convierten una web en una fortaleza inexpugnable, porque esa fortaleza no existe, pero sí levantan una muralla razonable entre un bot automatizado y el panel de administración.

Y, sobre todo, ofrecen algo que vale mucho cuando una web empieza a recibir golpes: información.

Porque en seguridad, el miedo suele vivir en la niebla. Cuando sabes qué está ocurriendo, por dónde llega el ataque y qué medida lo detiene, la niebla empieza a disiparse.

Conclusión: WordPress no se protege solo

El caso de Sofía terminó bien. El de Clave7 también. Pero ambos dejaron una lección clara: una web en WordPress, por pequeña que parezca, puede ser objetivo de ataques automatizados. No porque sea famosa. No porque alguien la odie. O porque contenga secretos de Estado. Simplemente porque existe, está online y usa una tecnología ampliamente extendida.

XML-RPC es un vector de ataque conocido en WordPress. Si tu sitio no necesita esa funcionalidad, bloquearla puede reducir exposición y evitar intentos de acceso por fuerza bruta. Varios recursos de seguridad recomiendan desactivarlo o limitarlo cuando no se utiliza, especialmente para reducir ataques automatizados y abusos contra xmlrpc.php. Si tienes una web en WordPress y no sabes si está protegida frente a este tipo de intentos, puedo revisarla sin compromiso. Comprobaré si XML-RPC está expuesto, si el acceso al panel está protegido, si hay registros de intentos sospechosos y qué medidas conviene aplicar en tu caso. A veces, la diferencia entre un susto y un problema serio está en una casilla bien marcada.