Qué importa primero: Una campaña de relleno con fuerza bruta o credencial envía grandes volúmenes a wp-login.php, XML-RPC o rutas de acceso personalizadas. Incluso los intentos fallidos consumen recursos web y PHP.
Qué indica realmente este síntoma
Bloquear una IP rara vez es suficiente porque los ataques se distribuyen. Las tasas de solicitud, los nombres de usuario específicos y los costos de respuesta muestran dónde aplicar los controles.
Recopila pruebas antes de cambiar nada
- Medir volumen de solicitud, rutas, redes de origen y agentes de usuario.
- Separar wp-login.php, xmlrpc.php y tráfico normal en logs.
- Comprueba la saturación de PHP-FPM y las consultas de la base de datos durante el ataque.
- Confirma si algún acceso tuvo éxito o si las cuentas cambiaron.
Causas más habituales
- Ataque de contraseña distribuido: Muchas IP intentan credenciales comunes o filtradas.
- Amplificación XML-RPC: system.multicall envuelve muchos intentos en menos solicitudes.
- bypass del bot: Los atacantes rotan agentes, direcciones cookies o IPv6.
- Manejo costoso de la seguridad: Cada intento desencadena un trabajo pesado de registro, geolocalización o base de datos.
Secuencia segura de diagnóstico y reparación
- Limitar o desafiar la ruta de acceso a nivel CDN, proxy o servidor web.
- Desactivar los métodos XML-RPC no utilizados o el punto final cuando el sitio no lo necesite.
- Requiere contraseñas fuertes y MFA para cuentas privilegiadas.
- Revisar los inicios de sesión con éxito, rotar las credenciales expuestas e invalidar sesiones.
Cómo distinguir entre las causas probables
No trates Ataque de contraseña distribuido y Amplificación XML-RPC como causas equivalentes. Muchas IP intentan credenciales comunes o filtradas. En cambio, system.multicall envuelve muchos intentos en menos solicitudes. Para distinguirlas, usa estas dos comprobaciones: Medir volumen de solicitud, rutas, redes de origen y agentes de usuario; y separar wp-login.php, xmlrpc.php y tráfico normal en logs. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Limitar o desafiar la ruta de acceso a nivel CDN, proxy o servidor web— o si debes conservar el estado actual y ampliar la investigación.
En una web comprometida, contener y limpiar son decisiones distintas. Conserva el archivo sospechoso y los registros de acceso antes de eliminar la persistencia, y rota las credenciales solo después de cerrar la vía activa. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.
Qué no debes hacer
No ocultes la URL de inicio de sesión como la única defensa. Los bots pueden descubrirlo, y las integraciones legítimas pueden romperse sin reducir el riesgo de credencial.
Cómo verificar la reparación
- La CPU y el uso del trabajador PHP permanecen establas bajo el tráfico de ataque.
- Los administradores legítimos pueden autenticarse de manera fiable.
- No hay acceso exitoso no autorizado, cambio de rol o nuevos restos de sesión.
Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.