Qué importa primero: xmlrpc.php admite publicación remota, aplicaciones móviles, servicios de tipo Jetpack y pingbacks. Los atacantes se dirigen a métodos que multiplican los intentos de autenticación o hacen peticiones de salida.
Qué indica realmente este síntoma
Un bloque de manta es seguro solo cuando nada depende del punto final. El acceso a logs y la inspección a nivel de método muestran el impacto operativo.
Recopila pruebas antes de cambiar nada
- Medir la tasa de solicitudes XML-RPC, las redes de origen y el tiempo de respuesta.
- Inspecciona los organismos de solicitud o la aplicación logs para nombres de métodos abusados cuando sea legalmente apropiado.
- Inventario de aplicaciones móviles, Jetpack, edición remota e integraciones.
- Comprueba si los efectos de autenticación y pingback salientes han tenido éxito.
Causas más habituales
- system.multicall abuse: Una petición contiene muchos intentos de acceso.
- abuso de pingback.ping: El sitio se utiliza para enviar solicitudes a terceros.
- Relleno de credenciales: Los atacantes prueban nombres de usuario y contraseñas filtrados.
- Procesamiento sin límite: Seguridad o registro plugins hacen que cada solicitud XML-RPC sea costosa.
Secuencia segura de diagnóstico y reparación
- Bloquear o limitar la tasa solo los métodos no utilizados o abusados cuando las integraciones siguen siendo necesarias.
- Desactivar el punto final en el borde cuando el sitio no tiene dependencia XML-RPC.
- Añadir MFA y rotar credenciales si alguna autenticación ha tenido éxito.
- Monitoriza PHP, tráfico de salida y logs después de la restricción.
Cómo distinguir entre las causas probables
No trates system.multicall abuse y abuso de pingback.ping como causas equivalentes. Una petición contiene muchos intentos de acceso. En cambio, el sitio se utiliza para enviar solicitudes a terceros. Para distinguirlas, usa estas dos comprobaciones: Medir la tasa de solicitudes XML-RPC, las redes de origen y el tiempo de respuesta; y inspecciona los organismos de solicitud o la aplicación logs para nombres de métodos abusados cuando sea legalmente apropiado. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Bloquear o limitar la tasa solo los métodos no utilizados o abusados cuando las integraciones siguen siendo necesarias— 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 desactives XML-RPC sin comprobar Jetpack, aplicaciones móviles o publicación externa. Debe documentarse y probarse un bloque de emergencia.
Cómo verificar la reparación
- El tráfico de ataque ya no agota PHP o desencadena el abuso de salida.
- Las integraciones requeridas todavía funcionan o tienen un reemplazo aprobado.
- No queda ningúna cuenta comprometida ni sesión no autorizada.
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.