Auditoría autorizada de WordPress con Nmap y WPScan: procedimiento reproducible

Estado de la evidencia: procedimiento técnico para un laboratorio local. No es un informe de cliente ni demuestra resultados sobre un WordPress público.

Una auditoría de WordPress debe comenzar por la autorización y terminar con evidencias revisables. Nmap y WPScan ayudan a inventariar una superficie autorizada, pero una exploración no es por sí sola un hallazgo.

Escenario y reglas de compromiso

La referencia a Mr. Robot es únicamente narrativa y ficticia, no una fuente de evidencia. El trabajo técnico se limita a un WordPress levantado por el equipo en un entorno aislado.

• Objetivo exacto: http://127.0.0.1:8080 o una red privada del laboratorio.
• Ventana horaria, límite de peticiones y criterio de parada definidos.
• Sin escaneo de Internet, credenciales reales, fuerza bruta ni explotación.
• Logs y salidas conservados sin secretos ni datos personales.

Inventario de servicio con Nmap

La primera fase comprueba el servicio, sin explotar nada:

nmap -Pn -sV --version-light -p 8080 127.0.0.1 -oA evidence/nmap-wordpress

Una comprobación HTTP acotada puede conservar título y cabeceras:

nmap -Pn -p 8080 --script http-title,http-headers 127.0.0.1 -oN evidence/nmap-http.txt

Un banner incompleto no demuestra una vulnerabilidad. La salida debe revisarse manualmente.

Enumeración con WPScan

WPScan debe apuntar exclusivamente al WordPress incluido en la autorización:

wpscan --url http://127.0.0.1:8080 --enumerate vp,vt --plugins-detection passive --output evidence/wpscan-enumeration.txt

La enumeración de plugins y temas es inventario, no confirmación de fallo. Para una revisión basada en la API se usa un token protegido, nunca publicado:

wpscan --url http://127.0.0.1:8080 --api-token "$WPSCAN_API_TOKEN" --enumerate vp,vt --plugins-detection passive --output evidence/wpscan-vulnerability-review.txt

Los avisos se validan por versión, configuración y exposición. No se incluyen comandos de explotación ni acceso a cuentas.

Validación y evidencia

Cada observación debe conservar identificador, fecha, objetivo, comando, salida original o hash, interpretación, nivel de confianza, impacto posible y recomendación. Si una herramienta no está instalada o no se ejecuta, el resultado es “no ejecutado”, no una métrica inventada.

La revisión defensiva puede incluir actualización controlada, eliminación de plugins no usados, privilegios mínimos, copias verificadas, protección del panel, registros y recuperación. No se modifica el sistema auditado sin autorización y plan de reversión.

Qué se puede publicar

Una publicación atribuible conserva alcance, versión del laboratorio, comandos, salidas anonimizadas, hashes, fecha y limitaciones. El laboratorio de red team autorizado de SECRON demuestra alcance verificable y eventos registrados, pero no ejecuta Nmap ni WPScan; este artículo no presenta resultados que aún no se hayan generado.

Referencias públicas atribuidas

La pieza continúa la línea pública atribuida a Jesús Amorós y SECRON sobre protección de aplicaciones, automatización y respuesta a incidentes: perfil profesional, GitHub, WAPPAF Community en GitLab y ponencia sobre WAF y ModSecurity.

Estas referencias documentan continuidad temática y autoría pública. No son acreditación de un engagement, certificación, despliegue en producción ni resultado de Anthropic.

Responsable declarado: SECRON es la marca comercial de JSJ Consultoría 23, S.L.