Cómo elegir herramientas de pentesting adecuadas para el trabajo

Sun Aug 16 2026

Todos los ejemplos aquí asumen una autorización por escrito, un alcance definido, un objetivo controlado y límites de velocidad explícitos. Esta es una guía práctica de seguridad para un laboratorio o una operación autorizada, nunca un permiso para escanear o explotar sistemas arbitrarios.

Usa Nmap para los servicios expuestos, ffuf para el contenido web accesible y Burp Suite para el comportamiento de las solicitudes. Usa sqlmap para investigar una hipótesis creíble de inyección SQL. Usa Metasploit para validar vulnerabilidades conocidas y realizar post-explotación autorizada. El objetivo es la transferencia: llevarás el XML de Nmap a Metasploit, pasarás los descubrimientos de ffuf a Burp y conservarás una solicitud de Burp para realizar pruebas acotadas con sqlmap.

Un pentest no es un recorrido por Kali Linux. La herramienta útil responde a la siguiente pregunta planteada por tu evidencia. Esta guía sigue una pequeña operación desde el alcance y el reconocimiento hasta el descubrimiento web, la validación manual, las pruebas acotadas de inyección SQL y la validación de vulnerabilidades conocidas.

En este artículo

Empieza por el alcance, no por un comando

Antes de abrir un terminal, aclara la ventana de pruebas, las clases de exploits permitidas, los límites de tráfico y el tratamiento de la evidencia en las reglas de intervención. Después, define el éxito en términos observables. Identifica los servicios expuestos, mapea la superficie web accesible, valida los hallazgos relevantes y produce evidencia reproducible.

ShieldOperations estructura una operación en reconocimiento, explotación, post-explotación y elaboración de informes. Úsalo como un modelo mental útil y vincula cada comando a uno de esos trabajos. Mantén juntas las solicitudes sin procesar, la salida de los escaneos, las marcas de tiempo y las notas. Detente cuando termine el alcance o cuando la siguiente acción lo exceda.

Elige las herramientas según la pregunta que necesites responder

Las herramientas de pruebas de penetración funcionan como una cadena. Cada una deja un artefacto que responde a la siguiente pregunta.

PreguntaPrimera herramientaLo que te proporcionaLo que no demuestra
¿Qué hosts y servicios están expuestos?NmapPuertos, observaciones de servicios/versiones y resultados de scripts seleccionadosQue un servicio sea explotable
¿Qué rutas o archivos web son accesibles?ffufDirectorios, rutas, parámetros o archivos candidatosQue una ruta descubierta sea vulnerable
¿Cómo se comporta la aplicación?Burp SuiteSolicitudes capturadas, respuestas, parámetros y observaciones de autorizaciónQue una alerta automatizada sea válida
¿Es posible inyectar SQL mediante un parámetro?Burp, después sqlmapUna solicitud entendida manualmente y una confirmación acotada de SQLiPermiso para volcar datos o acceder al sistema operativo
¿Se aplica una vulnerabilidad conocida?MetasploitComprobaciones de módulos y, cuando está autorizado, explotación repetible o flujos de trabajo de sesiónSigilo o una vía de explotación universal

Pero esta cadena no cubrirá todas las operaciones. La identidad en la nube, Active Directory, las aplicaciones móviles y el escaneo autenticado de vulnerabilidades necesitan herramientas diferentes. Yo mediría la cobertura frente al alcance antes de considerar suficientes estas cinco herramientas.

Nmap te dice qué está expuesto, no qué es explotable

Haz primero la pregunta menos invasiva. ¿Qué responde el objetivo aprobado?

Para la operación ficticia que aparece a continuación, el host de staging dentro del alcance es staging.acme.test, y también están incluidos app.acme.test y una red interna de pruebas aprobada. Comienza con la detección de servicios y versiones, los scripts predeterminados y un artefacto XML que puedas reutilizar:

nmap -sV -sC -oX /tmp/acme-nmap.xml staging.acme.test

-sC significa --script=default. El archivo XML de Nmap se convierte en la transferencia estructurada para las herramientas posteriores. Una cadena de versión sigue siendo evidencia que debe verificarse, no una identidad definitiva del producto.

El NSE de Nmap está basado en Lua, ejecuta scripts en paralelo y admite descubrimiento, detección de versiones, detección de vulnerabilidades y explotación, según la documentación oficial de NSE. Ese alcance es útil y precisamente por eso es importante actuar con moderación. Nmap es principalmente una herramienta de reconocimiento y, en segundo lugar, un verificador ligero. Ejecutar --script "all" porque es fácil es una prueba descuidada: la documentación oficial indica que esa categoría incluye scripts de explotación, fuerza bruta y denegación de servicio.

Usa un script específico cuando tengas una pregunta específica. Para inspeccionar los scripts HTTP disponibles y sus argumentos sin ejecutarlos:

nmap --script-help "http-*"

Después, selecciona deliberadamente el script y el puerto:

nmap -p 443 --script <script-name> --script-args <key=value> staging.acme.test

El portal de documentación de Nmap NSE enumera los argumentos de los scripts. Revisa el script antes de ejecutarlo; Nmap advierte que “Los scripts no se ejecutan en un entorno aislado y, por tanto, podrían dañar accidental o maliciosamente tu sistema o invadir tu privacidad”.

Supón que el escaneo identifica HTTP, HTTPS y un servicio adicional. Esto plantea tres preguntas distintas: qué aplicación web está escuchando, qué rutas son accesibles y si el servicio adicional presenta un problema específico de versión. ffuf y Burp se ocupan de las preguntas web. Un script NSE seleccionado de forma limitada puede ayudar con la pregunta sobre el servicio.

La importación del XML de Nmap completa los hosts, servicios y hallazgos relacionados en Metasploit; no demuestra que se aplique un módulo de Metasploit. Si necesitas una cobertura amplia de vulnerabilidades autenticadas, utiliza un escáner específico bajo su propio alcance. NSE sigue siendo una herramienta de verificación dirigida.

ffuf amplía la superficie web antes de que la pruebes

Un servidor web puede exponer una ruta de administración, un endpoint de API, un directorio de informes o una copia de seguridad olvidada que la página de inicio nunca enlaza. Encuentra esa superficie antes de pasar una hora probando el punto de entrada equivocado.

Para una ejecución acotada de descubrimiento de contenido, coloca FUZZ donde deba ir cada entrada de la wordlist:

ffuf -u https://staging.acme.test/FUZZ \
  -w /path/to/approved-wordlist.txt \
  -mc 200,204,301,302,307,401,403 \
  -fs <baseline-size> \
  -rate 10

Los marcadores de posición importan. Mide primero la respuesta normal de una ruta inexistente, sustituye <baseline-size> por el tamaño de su respuesta y usa una wordlist aprobada para la operación. -mc busca códigos de estado seleccionados, -fs filtra un tamaño de respuesta conocido y -rate 10 limita la velocidad de solicitudes a diez solicitudes por segundo. Comprueba la versión instalada de ffuf con ffuf -h; los flags y los detalles de salida deben coincidir con la versión que vayas a ejecutar.

Registra las rutas candidatas, los códigos de estado, los tamaños de respuesta, las redirecciones y las marcas de tiempo. Si la ejecución encuentra /reports/, conserva esa URL y envíala a Burp. La existencia de la ruta es un resultado de descubrimiento. Su relevancia para la seguridad depende de lo que haga la aplicación con ella.

No hagas fuzzing fuera del alcance permitido de hosts y rutas. Una wordlist no es una licencia para probar todos los hosts virtuales que puedas adivinar.

Burp convierte un endpoint descubierto en una solicitud comprobable

El momento útil en las pruebas web es disponer de una solicitud normal que puedas reproducir y explicar. A modo de ilustración, trata el valor siguiente como un marcador de posición:

GET /reports/view?id=<record-id> HTTP/1.1
Host: staging.acme.test
Cookie: <authorized-session>

Captura la ruta descubierta a través del proxy de Burp y después envía una copia a Repeater. Cambia una entrada cada vez. Observa la validación, el acceso a objetos, los límites de autorización, el tratamiento de errores y las diferencias en las respuestas. Conserva la solicitud, la respuesta y las notas de sesión como evidencia.

Pentest.ae identifica el proxy de interceptación de Burp, Repeater, Intruder, el active scanner y la tienda de extensiones BApp como sus componentes principales. Esa combinación es la razón por la que prefiero Burp cuando el análisis manual de solicitudes es el cuello de botella: el criterio permanece cerca de la solicitud.

Burp Pro merece la pena cuando el análisis manual de solicitudes es tu cuello de botella. Si tu trabajo consiste principalmente en DAST programado en CI, pagar por un entorno de trabajo interactivo es una optimización equivocada; usa ZAP y destina el presupuesto a la revisión.

OWASP ZAP es software gratuito bajo la licencia Apache 2.0 y encaja en los pipelines automatizados de DAST. El proyecto suele llamarse OWASP ZAP y ahora se informa de que está bajo la tutela de Checkmarx. Las comparaciones suelen favorecer a Burp Pro para el trabajo manual interactivo y la precisión del escáner. La ventaja de ZAP es la automatización gratuita y la integración con CI/CD; considéralo un juicio comparativo, no un benchmark.

Un active scanner puede mostrar una respuesta interesante. La lógica de autorización, la lógica de negocio y la confirmación manual siguen requiriendo tu intervención.

sqlmap automatiza la confirmación después de que entiendes la solicitud

Primero identifica manualmente un candidato creíble. Entiende el parámetro, la respuesta normal, los requisitos de autenticación y el límite de impacto. El soporte de bases de datos para MySQL, PostgreSQL, Microsoft SQL Server, Oracle y SQLite no hace que todas las aplicaciones o técnicas de inyección sean igualmente comprobables. Identifica el comportamiento de la solicitud antes de escalar.

Guarda la solicitud capturada como /tmp/request.txt y usa la sintaxis de sqlmap para archivos de solicitud:

sqlmap -r /tmp/request.txt -p <parameter> --batch

-r lee la solicitud HTTP completa desde un archivo, mientras que -p limita las pruebas al parámetro que seleccionaste. Comprueba que el archivo contenga el host, la ruta, las cookies, el método y el tipo de contenido correctos. Elimina las credenciales no relacionadas cuando sea posible y confirma que la solicitud siga apuntando al sistema autorizado.

Una secuencia acotada tiene este aspecto:

  1. Prueba un parámetro entendido manualmente.
  2. Confirma si la inyección es reproducible.
  3. Enumera nombres de bases de datos o tablas únicamente cuando las reglas lo permitan.
  4. Extrae la cantidad mínima de datos necesaria para demostrar el impacto.
  5. Detente antes de acceder al sistema operativo, a menos que esa capacidad esté autorizada explícitamente y sea necesaria.

EthicalHacking.ai documenta opciones como --dbs, --tables y --dump. Trata los valores más altos de --level y --risk como controles de escalada deliberados, nunca como una configuración inicial predeterminada.

Opciones como --os-shell y --file-read pueden acceder a sistemas o datos que van más allá del parámetro original. Úsalas únicamente con aprobación explícita y una necesidad demostrada. Una respuesta de WAF también necesita interpretación: los tamper scripts como space2comment, between, randomcase, charunicodeencode, equaltolike y greatest responden a comportamientos de filtrado concretos. Probar uno no establece un bypass ni demuestra el problema subyacente.

sqlmap puede probar el parámetro que le proporciones; no puede decidir si ese parámetro representa un fallo de autorización, un error de lógica de negocio o un límite de prueba aceptable. Detente cuando la evidencia sea reproducible y el informe tenga suficientes datos sobre el impacto.

Metasploit sirve para una validación fiable, no para un sigilo mágico

Metasploit entra en escena después de que el reconocimiento produzca un servicio, una versión o una hipótesis de vulnerabilidad que merezca ser probada. Asigna a cada operación su propio workspace. Importa el mismo artefacto de Nmap:

workspace -a <client_name>
db_import /tmp/acme-nmap.xml
hosts
services
vulns

Selecciona un módulo únicamente cuando coincida con la evidencia. Los módulos de explotación intentan aprovechar una vulnerabilidad. Los módulos auxiliares realizan comprobaciones o respaldan otras acciones. Los módulos post operan mediante una sesión establecida. Los payloads definen qué se ejecuta después de la explotación; los encoders transforman la representación del payload. Inspecciona las opciones y la descripción del módulo y, cuando esté disponible, ejecuta check antes de exploit. Ese paso adicional es aburrido y puede evitar que una versión supuesta desencadene un intento innecesario.

Los módulos post pueden recopilar hashes o credenciales, sugerir exploits locales o ampliar una sesión. Trata la recopilación de credenciales y la extracción de hashes como acceso a datos, con aprobación explícita, un límite de recopilación y un tratamiento seguro de la evidencia.

Metasploit Framework es útil para la validación repetible, la gestión de sesiones y la post-explotación autorizada. Metasploit Pro es un producto comercial independiente; material secundario de planificación sitúa su coste aproximado en torno a $15,000 al año, así que considéralo una estimación y no un precio universal.

RingSafe informa de que los AV modernos detectan las firmas predeterminadas de Meterpreter en un plazo de 24 horas y que el encoding por sí solo es insuficiente. Es una guía de profesionales, no una estadística universal de detección verificada de forma independiente. Usa ese hallazgo para rechazar los payloads predeterminados como evidencia de una debilidad del endpoint; no conviertas esta guía en una receta de evasión.

Metasploit es especialmente eficaz para vulnerabilidades conocidas, comprobaciones repetibles, infraestructura de gestión de sesiones y automatización de post-explotación. El sigilo de vanguardia requiere un enfoque autorizado y revisado por separado.

Las transferencias importan más que las herramientas individuales

Una pequeña ejecución autorizada podría producir esta cadena:

  1. Nmap identifica HTTP, HTTPS y un servicio adicional en staging.acme.test. Escribe el resultado en /tmp/acme-nmap.xml.
  2. ffuf encuentra /reports/. Conservas la URL exacta, la marca de tiempo, el estado, el tamaño de la respuesta y el comportamiento de redirección.
  3. Burp captura una solicitud a esa ruta y muestra un parámetro cuyo comportamiento merece ser probado. Conservas la solicitud sin procesar, la respuesta y las notas de sesión.
  4. sqlmap recibe esa solicitud únicamente si el parámetro respalda una hipótesis creíble de inyección SQL. Puede confirmar el problema o no producir ningún resultado útil.
  5. Metasploit importa el XML de Nmap únicamente si la evidencia del servicio coincide con una vulnerabilidad conocida que merezca validarse. Puede que nunca sea apropiado.

La secuencia puede retroceder. Una respuesta de Burp puede devolverte a ffuf para buscar una ruta de API relacionada. Una versión del servicio puede justificar un NSE dirigido antes de Metasploit. Un resultado limpio de sqlmap puede cerrar por completo esa línea de investigación.

Mantén conectados los artefactos: salida del escaneo, URL descubierta, solicitud capturada, resultado de la confirmación y módulo validado. Esta continuidad hace que la evaluación sea defendible.

Elige el stack más pequeño que responda a la siguiente pregunta

Necesidad de pruebaEligeSiguiente artefacto
Inventario de redNmapLista de servicios y salida XML
Verificación de servicios dirigidaScripts NSE seleccionados de NmapResultado del script vinculado a una hipótesis
Contenido web ocultoffufURL candidata y metadatos de respuesta
Comportamiento web manualBurp SuiteSolicitud reproducible, respuesta y notas de sesión
Pruebas web automatizadas gratuitas y CIZAPResultado de DAST para revisión manual
Inyección SQL sospechadaBurp primero, sqlmap despuésResultado de confirmación acotado
Validación de CVE conocidaMetasploitComprobación del módulo y evidencia de validación autorizada
Evasión de endpoints modernosUn método autorizado y revisado por separadoAlcance documentado y resultado de la prueba

Antes de cada comando, escribe cuatro cosas: la pregunta, el alcance, el artefacto esperado y la condición de parada. Si no puedes completar las cuatro, no lo ejecutes.