Cómo enumerar un WordPress en un pentest real

Introducción

WordPress sigue siendo el CMS más atacado del mundo, y con razón — está en el 43% de todos los sitios web. En cualquier engagement de pentesting con scope web, hay una probabilidad alta de toparte con un WordPress.

Esta guía cubre lo que uso en cada pentest real.

Reconocimiento inicial

Lo primero es confirmar que es WordPress:

curl -s https://target.com | grep -i "wp-content\|wp-includes"

Si el output muestra esas rutas, es WordPress. Confirmado.

WPScan — tu mejor amigo

# Enumeración básica
wpscan --url https://target.com -e u,p,t --api-token TU_TOKEN
 
# Enumeración agresiva de plugins
wpscan --url https://target.com -e ap --plugins-detection aggressive --api-token TU_TOKEN

Qué buscar:

• Usuarios: permiten ataques de fuerza bruta o password spraying
• Plugins desactualizados: fuente del 90% de las vulns en WordPress
• Temas: también tienen CVEs, aunque menos frecuente

XML-RPC — la puerta trasera olvidada

curl -X POST https://target.com/xmlrpc.php \
  -d '<methodCall><methodName>system.listMethods</methodName></methodCall>'

Si responde con una lista de métodos, está habilitado. Esto permite:

• Fuerza bruta sin lockout (system.multicall)
• SSRF en algunos casos

Usuarios vía REST API

curl -s "https://target.com/wp-json/wp/v2/users" | python3 -m json.tool

Si no está protegida, te devuelve usuarios, IDs y slugs.

Archivos sensibles expuestos

Siempre revisa estos paths:

Conclusión

En cada WordPress que pruebo sigo este orden: WPScan → XML-RPC → REST API → archivos sensibles. En el 70% de los casos encuentro algo explotable en los primeros 20 minutos.

El reporte siempre incluye versión del core, plugins vulnerables específicos con su CVE, y recomendaciones de hardening.