Cuando pensamos en un ataque contra WordPress, solemos imaginar una web caída, una página modificada por un hacker o un aviso evidente de malware.
Sin embargo, una parte importante de la actividad maliciosa o automatizada no produce señales tan claras.
Muchos bots trabajan de forma silenciosa: realizan peticiones repetitivas, prueban formularios, intentan iniciar sesión, crean usuarios, consultan endpoints de la API o generan pequeñas cargas constantes sobre el servidor.
La web continúa funcionando.
Y precisamente por eso el problema puede pasar desapercibido durante semanas o incluso meses.
Estas son algunas de las señales menos evidentes de que un WordPress puede estar recibiendo tráfico automatizado, flood o intentos de abuso por bots.
1. Tu WordPress consume más recursos sin haber aumentado las visitas
Una de las primeras señales puede aparecer en el servidor y no en la propia web.
El consumo de CPU aumenta, PHP ejecuta más procesos, aparecen más peticiones o la base de datos empieza a trabajar más de lo habitual.
Pero cuando consultas Analytics, Search Console u otra herramienta de estadísticas, el crecimiento de visitantes reales no parece justificarlo.
Esto puede ocurrir porque no todo el tráfico que llega a WordPress representa una visita humana.
Un bot puede realizar cientos o miles de peticiones sin comportarse como un usuario convencional y, dependiendo de cómo actúe, parte de esa actividad puede no aparecer claramente en tus herramientas habituales de analítica.
Por eso existe una diferencia importante entre tráfico web y actividad real del servidor.
Cuando ambos datos dejan de guardar relación, merece la pena investigar.
2. La web está más lenta en determinados momentos
Otra señal habitual es una degradación aparentemente aleatoria del rendimiento.
Durante buena parte del día la web funciona correctamente, pero en determinados momentos empieza a responder más lentamente.
No necesariamente estamos ante un ataque DDoS masivo.
Puede tratarse de pequeñas ráfagas de peticiones automatizadas contra determinados puntos de WordPress.
Por ejemplo:
wp-login.phpxmlrpc.php- endpoints de la REST API
- formularios
- registro de usuarios
- recuperación de contraseña
- comentarios
- checkout de WooCommerce
Cada petición individual puede parecer insignificante.
El problema aparece cuando se repite decenas, cientos o miles de veces.
3. Aparecen registros de usuarios que nadie reconoce
Una tienda o web que permite el registro de usuarios puede empezar a acumular cuentas extrañas.
Nombres aparentemente aleatorios, emails poco habituales, usuarios que nunca realizan ninguna acción posterior o varias cuentas creadas siguiendo patrones similares.
No todos esos registros tienen necesariamente una intención maliciosa, pero una creación anormal de usuarios puede indicar automatización.
Los bots pueden utilizar formularios de registro para comprobar emails, probar sistemas anti-spam, preparar cuentas para acciones posteriores o simplemente explotar formularios sin protección suficiente.
La señal importante no es un usuario extraño aislado.
Es el patrón repetitivo.
4. WooCommerce recibe pedidos falsos o intentos extraños de checkout
En WooCommerce existe otra superficie especialmente interesante para los bots: el checkout.
Una tienda puede empezar a recibir:
- pedidos que nunca se pagan;
- nombres aparentemente aleatorios;
- teléfonos inexistentes;
- emails con patrones extraños;
- múltiples intentos consecutivos;
- combinaciones diferentes de datos desde un mismo origen;
- repetición de operaciones en intervalos muy cortos.
En algunos casos puede ser simplemente spam.
En otros, el checkout puede estar siendo utilizado de manera automatizada para probar formularios, cuentas, datos o incluso métodos de pago.
Cuando existe repetición, el análisis del comportamiento suele ser más útil que analizar cada pedido individualmente.
5. Los logs muestran muchas peticiones repetidas
Los logs del servidor pueden revelar una realidad completamente diferente a la que vemos navegando normalmente por la web.
Una señal típica es encontrar muchas solicitudes similares dirigidas repetidamente hacia las mismas URLs.
Por ejemplo:
/wp-login.php/xmlrpc.php/wp-json/- rutas relacionadas con formularios y WooCommerce.
También podemos encontrar User-Agents repetitivos, direcciones IP realizando muchas solicitudes o secuencias de peticiones con intervalos extremadamente regulares.
Un visitante humano navega de una manera relativamente irregular.
Los sistemas automatizados suelen dejar patrones.
Y encontrar esos patrones es una de las claves para diferenciar actividad legítima de abuso automatizado.
6. Hay intentos constantes contra wp-login.php
Que alguien intente acceder a /wp-login.php no significa automáticamente que exista un ataque.
El problema aparece cuando encontramos decenas o cientos de intentos utilizando diferentes usuarios, contraseñas o direcciones IP.
Los ataques de fuerza bruta y credential stuffing pueden distribuirse además entre múltiples IPs.
Esto significa que limitar únicamente una dirección IP concreta no siempre resuelve el problema.
También conviene observar otro detalle: los usuarios inexistentes.
Si aparecen intentos continuos de autenticación contra nombres de usuario que nunca han existido en nuestra instalación, es muy probable que alguien esté realizando pruebas automatizadas.
7. XML-RPC recibe actividad aunque tú no lo utilices
xmlrpc.php forma parte de WordPress y permite determinadas comunicaciones remotas.
Dependiendo de la configuración y de los servicios utilizados por la web, puede ser necesario.
Pero también ha sido históricamente un objetivo frecuente de automatizaciones y abusos.
Por eso resulta interesante comprobar si XML-RPC está recibiendo peticiones repetitivas, especialmente cuando sabemos que nuestro proyecto no utiliza ninguna funcionalidad que justifique ese volumen de actividad.
No se trata de bloquear componentes de WordPress indiscriminadamente.
Se trata de preguntarnos: ¿esta actividad tiene sentido para mi web?
8. La REST API recibe muchas solicitudes inesperadas
La REST API de WordPress es completamente legítima y forma parte del funcionamiento moderno del CMS.
Plugins, aplicaciones y el propio WordPress pueden utilizarla.
Por eso bloquear /wp-json/ sin analizar previamente sus dependencias puede provocar problemas.
Pero legítimo no significa inmune al abuso.
Un bot también puede consultar endpoints repetidamente, buscar información pública, enumerar determinados recursos o generar un volumen innecesario de peticiones.
Aquí vuelve a ser importante analizar el contexto:
- ¿Qué endpoint recibe las solicitudes?
- ¿Con qué frecuencia?
- ¿Desde dónde?
- ¿Existe alguna funcionalidad de la web que justifique esa actividad?
La seguridad efectiva en WordPress no consiste simplemente en bloquear todo, sino en diferenciar comportamiento legítimo de comportamiento anómalo.
9. No encuentras malware, pero sabes que algo no funciona como antes
Esta probablemente sea la señal invisible más interesante.
Ejecutas un antivirus.
No aparece malware.
Los archivos principales de WordPress parecen correctos.
Los plugins están actualizados.
Pero continúan apareciendo consumo excesivo, registros extraños, spam, intentos de login o peticiones repetitivas.
Esto sucede porque un ataque contra WordPress no necesita infectar WordPress.
Un bot puede abusar de funcionalidades perfectamente legítimas sin modificar un solo archivo.
Puede utilizar el login, XML-RPC, consultar la REST API, enviar formularios, crear cuentas o intentar realizar pedidos.
Por eso buscar malware es solamente una parte de una auditoría de seguridad.
Malware y bots no son el mismo problema
Es importante diferenciar ambos conceptos.
Un malware implica normalmente código malicioso presente en archivos, base de datos o algún componente del sistema.
Un ataque automatizado puede producirse completamente desde fuera.
En ese caso WordPress puede estar técnicamente “limpio” y, aun así, estar soportando continuamente actividad hostil.
Por eso una revisión completa debería observar no solamente archivos sospechosos, sino también configuración, usuarios, endpoints expuestos, plugins, logs y comportamiento anómalo.
Si sospechas que tu instalación puede estar recibiendo este tipo de actividad, puedes realizar un análisis de seguridad WordPress para revisar la situación del sitio y detectar posibles puntos débiles o señales que normalmente pasan desapercibidas.
El verdadero problema es la repetición
Una petición a wp-login.php no es un ataque.
Un registro extraño tampoco.
Un pedido fallido tampoco.
La señal aparece cuando encontramos repetición.
- 1 intento: probablemente irrelevante.
- 20 intentos en pocos minutos: merece atención.
- 500 intentos distribuidos durante horas: existe claramente un patrón que debemos analizar.
Por eso una estrategia de protección contra bots debería tener en cuenta variables como:
- dirección IP;
- User-Agent;
- frecuencia de peticiones;
- usuarios utilizados;
- emails;
- dominios de email;
- teléfonos;
- endpoint solicitado;
- número de intentos;
- reincidencia.
Analizar varias señales simultáneamente permite tomar decisiones mucho mejores que bloquear únicamente por IP.
Bloquear todo tampoco es una buena estrategia
Existe una tentación comprensible cuando aparecen bots: endurecer todas las reglas posibles.
Pero podemos terminar perjudicando al usuario legítimo.
Una protección excesivamente agresiva puede bloquear clientes, integraciones, APIs, pasarelas de pago o servicios externos que necesita WordPress.
Especialmente en WooCommerce.
Por eso es preferible utilizar límites, ventanas temporales, análisis de reincidencia, listas blancas y bloqueos temporales antes que convertir la web en una fortaleza imposible de utilizar.
La protección debe adaptarse al comportamiento real del proyecto.
Cómo proteger WordPress frente a flood y bots
No existe una única medida capaz de resolver todos los escenarios.
Una estrategia razonable puede combinar:
- WordPress, plugins y temas actualizados.
- Contraseñas seguras y protección de usuarios administradores.
- Limitación de intentos repetitivos.
- Protección de formularios y registros.
- Supervisión de
wp-login.php. - Control de XML-RPC cuando corresponda.
- Monitorización de la REST API.
- Análisis de logs.
- Blacklists y whitelists.
- Bloqueos temporales ante comportamientos anómalos.
- Protección específica del checkout cuando utilizamos WooCommerce.
Para proyectos donde este tipo de actividad es recurrente, desarrollé Huuguu Flood Blocker, una capa adicional para WordPress y WooCommerce orientada precisamente a detectar y controlar flood, bots, spam, registros automatizados, intentos repetitivos y abuso de áreas sensibles.
La idea no es simplemente bloquear IPs.
El objetivo es observar el comportamiento, registrar señales y actuar cuando aparece un patrón suficientemente sospechoso.
La seguridad también consiste en observar
Uno de los errores más frecuentes es pensar: “Mi web funciona, por lo tanto no está siendo atacada.”
En Internet prácticamente cualquier WordPress público recibe tráfico automatizado.
Una parte corresponde a buscadores y servicios legítimos.
Otra puede ser spam.
Otra intenta descubrir vulnerabilidades.
Y otra simplemente prueba puertas esperando encontrar alguna abierta.
La cuestión no es conseguir una web que nunca reciba bots. Eso es prácticamente imposible.
El objetivo es conseguir que la actividad automatizada no pueda convertirse fácilmente en un problema de seguridad, rendimiento u operación.
Y para conseguirlo hay algo tan importante como bloquear: tener visibilidad sobre lo que realmente está ocurriendo dentro y alrededor de WordPress.
