Hay una pregunta que separa a un pentester de alguien que simplemente ha instalado Kali Linux: no es «¿qué herramientas utilizas?», sino «¿por qué has elegido esa herramienta, qué intentas demostrar y qué haces con el resultado?».
El instrumental ofensivo es hoy enorme, potente y, en buena parte, gratuito. Ahí reside también la trampa: disponer de las herramientas no equivale a saber utilizarlas, interpretar sus resultados ni encadenar sus hallazgos dentro de una intrusión realista.
El informe Annual Penetration Testing Review 2025 de Blaze Information Security analizó 660 pruebas realizadas sobre 145 organizaciones, en las que se confirmaron 3.294 vulnerabilidades pertenecientes a 206 categorías CWE diferentes. Los datos procedían de pruebas manuales y ejercicios de red team, no de simples exportaciones generadas por escáneres.
Esa diferencia importa. Un escáner puede señalar una versión vulnerable; un pentester debe determinar si realmente se puede explotar, qué impacto tendría y cómo se conecta con otros fallos. Las vulnerabilidades de autorización, los errores de lógica de negocio y muchas cadenas de ataque solo aparecen cuando una persona entiende cómo debería funcionar el sistema y prueba qué ocurre al romper esas expectativas.
En Hard2bit, las herramientas se utilizan para ampliar cobertura y acelerar tareas repetitivas, pero la validación final recae en consultores especializados. Son ellos quienes descartan falsos positivos, reproducen los hallazgos, construyen rutas de ataque y determinan si una debilidad técnica puede convertirse en un impacto real para el negocio.
Este artículo no es otra lista de «las mejores herramientas de hacking». Es un recorrido por el instrumental que se utiliza en un encargo profesional, fase por fase: qué pregunta responde cada familia de herramientas, qué permite validar, cuáles son sus límites y qué señales debería observar el equipo defensor.
Para entender primero el objetivo, el alcance y las modalidades de una prueba, puedes consultar nuestra guía sobre qué es un pentesting y cómo se realiza.
Cómo se encadenan las herramientas en un pentest
Las herramientas no se eligen por popularidad, sino según la fase del trabajo y la hipótesis que se pretende validar.
Metodologías como PTES, la OWASP Web Security Testing Guide o NIST SP 800-115 ayudan a estructurar el ejercicio. En la práctica, el trabajo empieza por descubrir la superficie expuesta, continúa con la identificación de servicios y tecnologías, profundiza en la enumeración y la validación manual, y solo después avanza hacia la explotación, la escalada de privilegios y el movimiento lateral, siempre dentro del alcance acordado.
El proceso termina cuando el pentester puede explicar con evidencias qué ruta de ataque era posible, qué activos quedaban expuestos y qué debe corregirse primero.
«Ejecutar Nmap» no es una metodología. La herramienta aporta datos. El valor está en decidir qué preguntar después.
1. Reconocimiento y OSINT: reconstruir la superficie visible
Antes de enviar tráfico directo al objetivo se intenta reconstruir lo que un atacante puede conocer desde Internet.
El propósito no es simplemente encontrar un puerto abierto, sino identificar dominios, subdominios, rangos de direcciones IP, servicios publicados, tecnologías, repositorios, entornos olvidados, proveedores y posibles credenciales filtradas.
Gran parte de este trabajo puede realizarse de forma pasiva, utilizando fuentes externas sin interactuar directamente con los sistemas de la organización. Por eso, muchas actividades de reconocimiento no dejan rastro en los registros internos.
Amass, Subfinder y transparencia de certificados
OWASP Amass y Subfinder recopilan subdominios a partir de DNS, registros históricos, motores de búsqueda y fuentes de transparencia de certificados.
Servicios como crt.sh permiten localizar nombres que han aparecido en certificados TLS públicos. Esto ayuda a descubrir entornos de desarrollo, subdominios antiguos, servicios no enlazados y, en algunos casos, nombres internos expuestos accidentalmente.
Ningún resultado debe aceptarse sin validación. Un subdominio histórico puede haber dejado de existir, apuntar a un tercero o no pertenecer al alcance. El analista debe resolverlo, comprobar su propiedad y confirmar si continúa activo.
dnsx, httpx y naabu
Las herramientas de ProjectDiscovery son especialmente útiles cuando el volumen de activos es elevado.
dnsx permite validar y resolver nombres; httpx comprueba qué servicios web responden y obtiene metadatos; y naabu agiliza el descubrimiento de puertos.
Su función no es emitir un veredicto, sino reducir miles de candidatos a una lista manejable sobre la que profundizar manualmente.
Shodan, Censys y FOFA
Shodan, Censys y FOFA indexan servicios accesibles desde Internet y permiten localizar activos mediante banners, certificados, productos, puertos, ASN, títulos web o incluso hashes de favicon.
Son útiles para descubrir interfaces de administración, infraestructura no inventariada o servicios publicados desde proveedores cloud que no aparecen en el inventario oficial.
El matiz importante es temporal: estos motores pueden conservar datos históricos. Encontrar un servicio indexado no demuestra que siga accesible en el momento de la prueba.
TruffleHog y Gitleaks
TruffleHog y Gitleaks buscan secretos en repositorios, historiales y otros orígenes. Pueden detectar claves de API, tokens, contraseñas, claves privadas, credenciales cloud o cadenas de conexión.
La coincidencia de un patrón no demuestra que la credencial continúe activa. En un pentest autorizado, cualquier validación debe estar expresamente contemplada en las reglas de enfrentamiento y realizarse de forma controlada.
Hard2bit Scanner: visibilidad inicial sobre la superficie expuesta
Además de las herramientas de terceros, Hard2bit utiliza tecnología propia para acelerar la fase inicial de reconocimiento y exposición.
Hard2bit Scanner analiza de forma pasiva y no intrusiva la postura pública de un dominio. Revisa aspectos como TLS, DNS, cabeceras HTTP, tecnologías expuestas, configuración de correo, subdominios, certificados, cookies, security.txt, robots.txt y otras señales visibles desde Internet.
Sirve para identificar rápidamente candidatos, inconsistencias y superficies que después deben ser revisadas por un analista.
Es un buen ejemplo del papel correcto de la automatización: ampliar cobertura y reducir trabajo repetitivo para que el consultor pueda concentrarse en la validación manual, las cadenas de ataque y el impacto real.
Qué valida esta fase
El reconocimiento mide la distancia entre el inventario oficial y la superficie de ataque real.
Es la misma base de un servicio de gestión de la superficie de ataque, aunque en un pentest se utiliza para orientar las pruebas posteriores.
La defensa no puede depender únicamente de detectar el reconocimiento, porque buena parte es pasivo. La respuesta eficaz consiste en reducir lo que un atacante puede descubrir: retirar servicios obsoletos, eliminar DNS abandonado, revisar certificados, proteger repositorios, rotar secretos filtrados y mantener actualizado el inventario externo.
2. Escaneo y enumeración: saber qué hay y cómo está configurado
Una vez delimitada la superficie, el pentester comienza a interactuar con los activos para identificar hosts, puertos, protocolos, versiones y configuraciones.
Aquí conviene distinguir entre escaneo y enumeración. El escaneo busca cobertura y candidatos; la enumeración profundiza en servicios concretos. Es una diferencia parecida a la que existe entre un escaneo de vulnerabilidades y un programa de gestión de vulnerabilidades.
Nmap
Nmap sigue siendo la herramienta de referencia para el descubrimiento de hosts, el análisis de puertos TCP y UDP, la identificación de servicios, la estimación de versiones y la ejecución de scripts NSE.
Opciones como -sV ayudan a identificar servicios, pero el banner detectado no debe tratarse como verdad absoluta. Los servicios pueden ocultar, modificar o falsificar su versión.
El motor NSE permite realizar comprobaciones y tareas de enumeración muy precisas, aunque ejecutar categorías completas de scripts sin criterio puede generar ruido, bloqueos o efectos no deseados.
La habilidad no está en conocer muchas opciones de Nmap, sino en interpretar correctamente sus respuestas y adaptar la siguiente prueba.
Masscan y Naabu
Masscan y Naabu permiten realizar barridos rápidos cuando el alcance incluye grandes rangos o muchos activos.
Normalmente se utilizan como primera criba. Los puertos identificados se validan después con Nmap u otras herramientas más precisas.
La velocidad debe ajustarse al entorno. Un escaneo demasiado agresivo puede saturar enlaces, afectar a sistemas frágiles, activar bloqueos o distorsionar los resultados.
Nuclei
Nuclei ejecuta comprobaciones basadas en plantillas para identificar exposiciones, configuraciones inseguras y vulnerabilidades conocidas.
Es especialmente útil para revisar rápidamente muchos activos, buscar una CVE concreta, detectar paneles expuestos o repetir comprobaciones durante un retest.
Sus resultados dependen de la calidad y actualidad de las plantillas. Una coincidencia debe verificarse, y la ausencia de coincidencias no demuestra que el activo sea seguro.
Nessus, Greenbone/OpenVAS y Qualys
Los escáneres de vulnerabilidades proporcionan cobertura sistemática sobre versiones afectadas, parches ausentes, software obsoleto, cifrados débiles y configuraciones inseguras.
La diferencia entre un escaneo autenticado y uno no autenticado es fundamental. Sin credenciales se observa la superficie accesible para un tercero. Con credenciales se obtiene una imagen más completa de la deuda técnica interna.
Aun así, ningún escáner debe utilizarse como veredicto final. Puede generar falsos positivos, duplicidades, severidades descontextualizadas y también falsos negativos. Además, no entiende la lógica de negocio ni puede demostrar por sí solo que una debilidad sea explotable en ese entorno concreto.
En los pentests de Hard2bit, los resultados automáticos se revisan antes de incorporarse al informe. Un hallazgo no se considera válido únicamente porque aparezca en la salida de una herramienta: debe confirmarse, contextualizarse y, cuando resulte seguro, reproducirse.
Por eso una gestión de vulnerabilidades basada en riesgo real necesita validación, priorización y seguimiento, no solo exportar un informe automático.
Wireshark y tshark: entender qué ocurre realmente
Wireshark y su versión de línea de comandos, tshark, son herramientas transversales dentro de un pentest.
Permiten analizar protocolos, negociaciones TLS, autenticaciones, retransmisiones, tráfico en claro, respuestas inesperadas y diferencias entre lo que una herramienta interpreta y lo que realmente circula por la red.
Muchas veces Wireshark no descubre la vulnerabilidad por sí solo, pero explica por qué una técnica funciona o demuestra que la conclusión automática de otra herramienta es incorrecta.
Qué debería detectar el defensor
Un escaneo rápido suele dejar señales en firewalls, IDS, NetFlow, WAF y registros de servicios. Sin embargo, un atacante puede distribuir las peticiones, reducir la velocidad o imitar tráfico legítimo.
No detectar un escaneo no significa que nadie esté observando la organización.
3. Aplicaciones web y APIs: donde el contexto supera a la automatización
Las aplicaciones web y las APIs son uno de los ámbitos donde más se aprecia la diferencia entre una herramienta y un analista.
La automatización puede localizar patrones conocidos, pero los problemas de mayor impacto suelen requerir contexto. La autorización horizontal o vertical rota, los IDOR o BOLA, el abuso de flujos de negocio, las condiciones de carrera o la separación insuficiente entre clientes no se comprenden observando únicamente una respuesta HTTP.
La OWASP Top 10:2025 mantiene Broken Access Control como la primera categoría de riesgo e incorpora Software Supply Chain Failures entre sus categorías principales.
Burp Suite Professional
Burp Suite es el proxy de interceptación de referencia en muchas auditorías web.
Proxy permite interceptar y modificar tráfico; Repeater facilita repetir solicitudes con variaciones controladas; Intruder automatiza fuzzing dirigido; Sequencer analiza tokens; y Collaborator detecta interacciones fuera de banda útiles para validar SSRF, XXE ciega y otras vulnerabilidades.
Las extensiones de BApp Store amplían sus capacidades. Autorize ayuda a comparar respuestas entre usuarios con distintos permisos; JWT Editor facilita el análisis de tokens; Param Miner busca parámetros ocultos; y Logger++ mejora el registro del tráfico.
Estas extensiones pueden señalar diferencias, pero no deciden si existe una vulnerabilidad real. Esa conclusión sigue dependiendo del analista.
Caido
Caido es un proxy moderno orientado a pruebas manuales, con gestión de proyectos, una interfaz ágil y automatización mediante flujos y complementos.
Se ha convertido en una alternativa relevante para pentesters y bug bounty hunters. Burp mantiene un ecosistema más maduro de extensiones y formación, pero la elección depende del flujo de trabajo y no de una superioridad absoluta.
OWASP ZAP
OWASP ZAP es una alternativa de código abierto que puede utilizarse como proxy manual y como herramienta DAST automatizada.
Encaja especialmente bien en pruebas recurrentes, CI/CD y validaciones controladas sobre entornos de preproducción.
Sus escaneos activos deben configurarse con cuidado, porque algunas pruebas pueden crear datos, modificar estados o generar carga.
ffuf, Feroxbuster y sqlmap
ffuf y Feroxbuster ayudan a descubrir directorios, ficheros, endpoints, parámetros, virtual hosts y rutas no enlazadas.
Su eficacia depende más de las listas, filtros y conocimiento de la aplicación que de ejecutar un diccionario genérico.
sqlmap automatiza la detección y explotación de inyecciones SQL. Es útil para validar un hallazgo y medir su impacto, pero algunas opciones pueden extraer grandes cantidades de datos, modificar información o afectar a la estabilidad del sistema. En muchos pentests basta con una demostración mínima y controlada.
mitmproxy y herramientas para APIs
mitmproxy resulta especialmente útil para automatizar, transformar y analizar tráfico HTTP mediante scripts.
En APIs también se utilizan especificaciones OpenAPI, clientes como Postman o Bruno, herramientas para GraphQL, analizadores de JWT, clientes gRPC y scripts desarrollados por el propio equipo.
Sin embargo, la herramienta más importante suele ser el modelo de permisos construido por el analista: qué rol puede ejecutar cada operación y sobre qué objetos.
Donde realmente aporta valor el análisis manual
Esta es una de las áreas donde más valor aporta un equipo experto.
Las herramientas pueden señalar respuestas distintas, parámetros sospechosos o controles inconsistentes, pero solo un analista que entiende los roles, los flujos y la lógica de la aplicación puede confirmar si existe una vulnerabilidad real y hasta dónde puede explotarse.
En los pentests de Hard2bit, la automatización se utiliza como capa de cobertura, mientras que las pruebas de autorización, lógica de negocio, encadenamiento de vulnerabilidades y abuso de procesos se realizan manualmente.
Una auditoría web o de API debe responder preguntas que un escáner no puede contestar: si un cliente puede consultar los datos de otro, si un usuario puede saltarse una aprobación, si una operación puede repetirse indebidamente o si una función legítima puede utilizarse para causar un impacto no previsto.
Por eso una auditoría de seguridad de aplicaciones web o una auditoría de seguridad de APIs debe combinar automatización, análisis manual y conocimiento del negocio.
Un WAF puede bloquear patrones conocidos. No puede decidir por sí solo si una operación válida debería estar permitida para ese usuario y ese objeto.
4. Explotación: demostrar impacto sin convertir la prueba en un incidente
Explotar una vulnerabilidad durante un pentest no consiste en causar daños ni en «romper por romper».
El objetivo es demostrar, dentro de las reglas acordadas, que el fallo es real, qué acceso permite, qué activos expone y si puede encadenarse con otras debilidades.
La prueba debe aplicar el principio de mínima evidencia: demostrar lo necesario sin aumentar innecesariamente el riesgo.
SearchSploit y Exploit-DB
Exploit-DB y SearchSploit permiten localizar pruebas de concepto públicas.
Una PoC nunca debería ejecutarse directamente en producción sin revisar su código. Antes hay que entender qué modifica, qué comunicaciones realiza, si introduce dependencias, si puede causar denegación de servicio y para qué versión fue diseñada.
Que una prueba de concepto exista no significa que sea segura ni que funcione sobre el objetivo real.
Metasploit Framework
Metasploit proporciona módulos de explotación, enumeración, post-explotación, pivoting y gestión de sesiones.
Su valor en un pentest es la reproducibilidad. Permite confirmar determinados impactos de forma controlada y documentar con precisión las opciones utilizadas.
No elimina la necesidad de criterio. El operador sigue teniendo que verificar versiones, precondiciones y consecuencias.
Marcos de C2
En ejercicios avanzados pueden utilizarse plataformas de mando y control como Cobalt Strike, Sliver, Mythic, Havoc o AdaptixC2.
Estas plataformas gestionan agentes, comunicaciones, tareas, pivoting y post-explotación. También aparecen en intrusiones reales, por lo que existen detecciones específicas para payloads, configuraciones y patrones de tráfico conocidos.
No todos los pentests necesitan un C2. Su uso tiene más sentido en ejercicios de adversary simulation o red team donde también se evalúa la capacidad defensiva.
Qué debería detectar el defensor
Esta fase puede generar telemetría en EDR, XDR, AMSI, Sysmon, PowerShell, DNS, proxy, firewall, NDR y SIEM.
Los fingerprints TLS, la periodicidad del tráfico, el comportamiento de los procesos y la infraestructura de destino pueden aportar señales, pero ningún indicador aislado debe considerarse concluyente. JA3 o JARM son útiles como contexto, no como veredicto.
Un servicio de threat hunting busca precisamente combinaciones de señales que no han generado una alerta determinista.
Un red team va un paso más allá del pentest tradicional: no solo comprueba si el ataque es posible, sino si la organización puede detectarlo, investigarlo y contenerlo.
5. Active Directory e identidad: el campo de batalla empresarial
Hasta este punto, muchas pruebas se centran en servicios, aplicaciones y configuraciones concretas. En Active Directory cambia la lógica: el riesgo rara vez está en un fallo aislado, sino en la combinación de permisos, identidades, sesiones y relaciones de confianza acumuladas durante años.
En muchas organizaciones, el camino hacia privilegios elevados no depende de una vulnerabilidad crítica sin parchear. Depende de permisos heredados, grupos mal diseñados, cuentas de servicio, protocolos antiguos, delegaciones inseguras y certificados mal configurados.
BloodHound Community Edition
BloodHound CE representa identidades, equipos, grupos, sesiones y permisos como un grafo.
SharpHound recopila información de Active Directory y AzureHound hace lo propio en Entra ID.
BloodHound no «hackea el dominio». Ayuda a descubrir rutas de control entre cuentas, equipos y grupos, y convierte miles de relaciones difíciles de interpretar en caminos que pueden revisarse y corregirse.
NetExec
NetExec, sucesor mantenido de CrackMapExec, permite trabajar sobre protocolos como SMB, WinRM, LDAP, MSSQL, SSH y RDP.
Se utiliza para validar credenciales, enumerar sistemas y ejecutar acciones autorizadas a escala.
Debe configurarse con cuidado. Una prueba mal diseñada puede provocar bloqueos de cuentas o parecer un password spraying real.
Impacket
Impacket contiene implementaciones de protocolos y numerosos scripts empleados en pruebas de seguridad.
GetUserSPNs.py se utiliza para solicitar tickets asociados a cuentas con SPN; GetNPUsers.py, para identificar cuentas sin preautenticación Kerberos; secretsdump.py, para obtener material de credenciales cuando existe acceso suficiente; y ntlmrelayx.py, para validar ataques de retransmisión NTLM.
Otros scripts como psexec.py, wmiexec.py o smbexec.py permiten ejecución remota controlada.
Son herramientas potentes y deben utilizarse únicamente dentro del alcance acordado.
Responder, Rubeus, Certipy y Kerbrute
Responder permite analizar y, cuando está autorizado, responder a protocolos de resolución de nombres como LLMNR, NBT-NS y mDNS. Se utiliza para demostrar el riesgo de autenticaciones NTLM automáticas y ataques de retransmisión.
Rubeus reúne técnicas relacionadas con Kerberos; Certipy analiza configuraciones de Active Directory Certificate Services; y Kerbrute facilita pruebas controladas sobre Kerberos.
La herramienta puede identificar una condición potencialmente insegura, pero la explotabilidad depende de la posición del atacante, los permisos disponibles y la arquitectura concreta.
PingCastle y Purple Knight
PingCastle y Purple Knight se orientan más a la evaluación de postura que a la explotación.
Ayudan a identificar protocolos heredados, cuentas privilegiadas, delegaciones, configuraciones peligrosas y problemas generales de higiene del directorio.
Son un punto de partida útil, pero no sustituyen la evaluación manual de rutas de ataque.
El valor está en la cadena, no en el hallazgo aislado
Una herramienta puede indicar que una cuenta posee un permiso excesivo o que una plantilla de certificado parece vulnerable.
El trabajo del pentester consiste en determinar si ese permiso puede explotarse desde la posición actual, qué acceso previo requiere, si conduce a un activo crítico y qué impacto tendría completar la ruta.
En Hard2bit, esta fase se centra en construir y validar rutas de ataque reales, no en entregar una lista de configuraciones teóricas.
El objetivo es demostrar hasta dónde puede avanzar un atacante desde una cuenta, un equipo o un punto de acceso inicial concreto.
Detección en Active Directory
Las técnicas ofensivas pueden dejar señales en consultas LDAP, solicitudes Kerberos, autenticaciones NTLM, creación de servicios, acceso remoto administrativo, cambios en grupos y solicitudes de certificados.
Los eventos 4769 con cifrado RC4 pueden ser una señal útil en determinados entornos, especialmente cuando el servicio debería utilizar AES. Sin embargo, no todo ticket RC4 implica Kerberoasting y un atacante también puede solicitar tickets AES.
La detección debe combinar cuenta, volumen, origen, SPN y comportamiento histórico.
Las identidades señuelo pueden añadir visibilidad si están correctamente instrumentadas, pero no detectan automáticamente toda recolección de BloodHound.
Para profundizar en estas rutas, consulta nuestro análisis sobre Kerberoasting, AD CS y Golden Ticket en Active Directory híbrido.
MITRE ATT&CK proporciona además un lenguaje común para relacionar técnicas ofensivas con detecciones y controles defensivos.
6. Contraseñas y crackeo offline
Muchas cadenas de ataque producen hashes o material cifrado que puede analizarse fuera de línea.
En ese escenario no existe bloqueo de cuenta ni interacción repetida con el servicio. La resistencia depende del algoritmo, el coste computacional, la longitud de la contraseña y, sobre todo, de su previsibilidad.
Hashcat y John the Ripper
Hashcat es la herramienta de referencia para crackeo acelerado mediante GPU. Su eficacia no reside únicamente en probar millones de combinaciones, sino en utilizar reglas, máscaras y diccionarios que reflejan cómo crean contraseñas las personas.
John the Ripper admite una gran variedad de formatos y complementa bien este flujo, especialmente cuando hay que identificar hashes, convertir formatos o procesar archivos protegidos.
Diccionarios y reglas
rockyou.txt es conocido, pero un diccionario genérico suele ser menos eficaz que uno adaptado a la organización.
En una auditoría autorizada pueden construirse candidatos basados en el nombre de la empresa, marcas, ubicaciones, productos, años y convenciones observadas.
El objetivo no es recuperar todas las contraseñas, sino demostrar si las políticas y hábitos reales permiten comprometer cuentas de alto impacto.
Qué valida esta fase
El crackeo offline permite comprobar la robustez real de las contraseñas, la reutilización, los patrones organizativos y la exposición de cuentas de servicio.
Las defensas más efectivas siguen siendo las contraseñas largas, los gestores de contraseñas, el bloqueo de credenciales comprometidas, las cuentas de servicio gestionadas y la eliminación de algoritmos débiles.
7. Wireless, móvil, cloud y Kubernetes
El instrumental cambia cuando cambia la superficie.
Las técnicas útiles en una aplicación web no sirven necesariamente para una red Wi-Fi, una aplicación móvil o una plataforma cloud. En estos entornos, el valor del especialista está también en saber adaptar la metodología y no aplicar el mismo conjunto de herramientas a todos los encargos.
Seguridad Wi-Fi
En auditorías inalámbricas se utilizan herramientas como aircrack-ng, hcxdumptool, hcxtools, Wireshark y EAPHammer.
Permiten revisar redes WPA2 y WPA3, configuraciones empresariales 802.1X, métodos EAP, segmentación, aislamiento de clientes, redes invitadas y posibles puntos de acceso maliciosos.
Capturar un PMKID no implica que la contraseña pueda recuperarse. El impacto depende de la fortaleza de la clave y de la configuración.
Estas pruebas forman parte de una auditoría de seguridad Wi-Fi.
Aplicaciones móviles
MobSF se utiliza para análisis estático y dinámico; Frida y Objection permiten instrumentar la aplicación en ejecución; y jadx, apktool o Ghidra facilitan la ingeniería inversa.
Estas herramientas ayudan a revisar almacenamiento local, secretos embebidos, comunicaciones, validación de certificados, autenticación, autorización y controles de integridad.
Sin embargo, saltarse una protección local no demuestra necesariamente un impacto si el servidor aplica correctamente los controles.
La evaluación completa debe relacionar aplicación, backend e identidad dentro de una auditoría de seguridad de aplicaciones móviles.
Cloud e identidad
En entornos cloud se utilizan herramientas como Prowler, ScoutSuite, Steampipe, Pacu, CloudFox, ROADtools, AzureHound, Monkey365 y MicroBurst.
Ayudan a revisar configuraciones, identidades, permisos, recursos públicos, logging, roles y rutas de escalada.
Una herramienta de postura cloud no equivale a un pentest cloud. Detectar que un rol contiene un permiso amplio es distinto de demostrar cómo ese permiso puede combinarse con una identidad gestionada, una función o un recurso concreto.
Contenedores y Kubernetes
En entornos Kubernetes y de contenedores pueden utilizarse Trivy, Kubescape, kube-bench, kube-hunter, Peirates y las propias herramientas nativas como kubectl.
Estas soluciones ayudan a revisar imágenes vulnerables, configuraciones inseguras, cumplimiento con benchmarks, permisos RBAC, service accounts, secretos, admission policies y exposición del API Server.
La revisión manual sigue siendo imprescindible. Un permiso amplio puede ser irrelevante en un pod aislado o convertirse en una ruta crítica si permite leer secretos, crear workloads privilegiados o utilizar la identidad cloud del nodo.
En Kubernetes, como en Active Directory, el riesgo suele estar en la cadena de permisos, no en una única configuración.
8. Escalada local, pivoting y post-explotación
Una vez obtenido acceso a un sistema, el pentester debe determinar qué puede hacer realmente desde él.
winPEAS, linPEAS y Seatbelt automatizan la enumeración local y ayudan a localizar servicios inseguros, permisos débiles, credenciales almacenadas, tareas programadas, rutas modificables o software vulnerable.
Generan una gran cantidad de información, pero muchos resultados son solo candidatos. El analista debe determinar cuáles son realmente explotables.
Para acceder a segmentos no alcanzables directamente pueden utilizarse herramientas como Ligolo-ng, Chisel y Proxychains.
Ligolo-ng facilita la creación de túneles hacia redes internas; Chisel transporta conexiones sobre HTTP o WebSocket; y Proxychains permite forzar el tráfico de determinadas aplicaciones a través de un proxy.
El pivoting debe estar autorizado expresamente, porque una mala configuración puede enviar tráfico fuera del alcance.
La post-explotación debe responder preguntas concretas: si una estación comprometida puede alcanzar servidores críticos, si la segmentación es efectiva, si existen credenciales reutilizables o si el atacante puede acceder a sistemas de backup e hipervisores.
El objetivo no es permanecer oculto indefinidamente, sino demostrar impacto con la menor intervención necesaria.
9. El informe también es una herramienta
La parte más valiosa del pentest no es la consola del atacante. Es el resultado que permite a la organización corregir sus riesgos.
Plataformas como PlexTrac, Ghostwriter, Dradis, Faraday, AttackForge o SysReptor ayudan a organizar hallazgos, evidencias, activos, recomendaciones y revisiones.
La plataforma, sin embargo, no garantiza un buen informe.
Un hallazgo útil debe explicar qué se observó, cómo se reprodujo, qué activo afecta, qué precondiciones requiere, qué impacto tiene, cómo debe corregirse y cómo validar después la corrección.
Un informe lleno de capturas y puntuaciones CVSS, pero sin contexto de negocio, tiene poco valor operativo.
El equipo de Hard2bit revisa cada hallazgo para que el entregable no sea una exportación de herramientas, sino una explicación clara de qué puede hacer un atacante, qué riesgo representa y qué debe corregirse primero.
Kali Linux, Parrot OS y Exegol no son el pentest
Kali Linux, Parrot OS y Exegol agrupan herramientas y dependencias en entornos preparados para trabajar.
Aportan comodidad, consistencia y rapidez de despliegue. No sustituyen metodología, experiencia, conocimiento de protocolos, capacidad de programación, prudencia ni criterio de negocio.
Tener cientos de herramientas instaladas no convierte a nadie en pentester, igual que disponer de un quirófano no convierte a nadie en cirujano.
Automatización e inteligencia artificial con criterio
La automatización tiene un lugar claro en seguridad. Sirve para ampliar cobertura, repetir comprobaciones, detectar cambios, verificar exposiciones conocidas y acelerar los retests.
No debe decidir por sí sola si un hallazgo es explotable, qué impacto tiene, si dos debilidades pueden encadenarse ni qué debe priorizar el negocio.
Ese es también el enfoque de Hard2bit: automatizar lo repetible para que el tiempo del consultor se concentre en lo que realmente valida el servicio.
Nuestro equipo revisa manualmente cada hallazgo relevante, elimina falsos positivos, reproduce la explotación cuando es seguro hacerlo y analiza cómo puede encadenarse con otras debilidades del entorno.
El resultado no es una exportación de herramientas, sino una evaluación técnica interpretada por especialistas y traducida a riesgos y acciones concretas.
El papel de la IA en el pentesting de 2026
En 2026, los asistentes basados en inteligencia artificial también se han incorporado al flujo de trabajo ofensivo.
Pueden ayudar a resumir documentación técnica, analizar grandes volúmenes de resultados, preparar scripts auxiliares, revisar fragmentos de código, transformar consultas, clasificar evidencias y proponer nuevas hipótesis de prueba.
También pueden acelerar la comprensión de protocolos, SDK o APIs poco conocidos.
Sin embargo, sus respuestas deben tratarse como sugerencias, no como evidencia. Un modelo puede inventar parámetros, proponer funciones inexistentes, interpretar mal una respuesta, generar código inseguro u omitir precondiciones críticas.
Tampoco conoce necesariamente las reglas de enfrentamiento, la criticidad del servicio o las consecuencias operativas de una acción.
En un pentest profesional, la IA puede aportar velocidad, pero la autorización, la ejecución, la interpretación y la validación siguen dependiendo del consultor.
Para valorar qué ejercicio necesita una empresa, también conviene distinguir entre pentesting, red team y BAS.
Cuándo el pentest deja de ser opcional
La elección de herramientas es una decisión técnica, pero el motivo por el que se realiza el pentest puede ser contractual, regulatorio o de gestión del riesgo.
En esos casos, no basta con ejecutar pruebas. También hay que demostrar alcance, metodología, independencia, trazabilidad y remediación.
PCI DSS 4.0.1
PCI DSS 4.0.1 incluye requisitos específicos de pruebas de penetración dentro del requisito 11.4.
De forma general, exige pruebas internas y externas al menos cada doce meses y después de cambios significativos. También exige pruebas sobre los controles de segmentación cuando se utilizan para reducir el alcance.
La frecuencia y los requisitos concretos dependen del entorno y de la función que desempeñe la organización.
NIS2
NIS2 exige a las entidades incluidas en su ámbito aplicar medidas proporcionadas de gestión de riesgos y evaluar la eficacia de dichas medidas.
No obliga literalmente a todas las organizaciones a contratar el mismo pentest anual. Sin embargo, en muchos entornos una prueba técnica independiente constituye una evidencia razonable sobre exposición, eficacia de controles, segregación y capacidad de detección.
Puedes ampliar este contexto en nuestra guía práctica de NIS2 en España.
DORA y TLPT
DORA exige programas de pruebas de resiliencia operativa digital a las entidades financieras incluidas en su ámbito.
Las pruebas TLPT no son obligatorias para todas ellas. Las autoridades competentes identifican qué entidades deben realizarlas aplicando criterios de impacto, riesgo y relevancia sistémica.
Las entidades seleccionadas deben realizar TLPT, con carácter general, al menos cada tres años, aunque la autoridad puede ajustar la frecuencia.
Un TLPT tampoco es un pentest convencional. Es un ejercicio basado en inteligencia de amenazas, dirigido a funciones críticas o importantes y con una metodología próxima a TIBER-EU.
La normativa no prescribe que se utilice Nmap, Burp o BloodHound. Exige rigor, control del riesgo, independencia, evidencia y capacidad de remediación.
Lo esencial
El instrumental ofensivo es amplio, especializado y cada vez más accesible.
Eso facilita el trabajo técnico, pero también crea una falsa sensación de competencia. Saber ejecutar una herramienta no significa saber cuándo utilizarla, qué riesgo introduce, cómo interpretar sus resultados, cuándo detenerse ni cómo traducir el resultado a una decisión empresarial.
El valor de una prueba no está en la cantidad de herramientas ejecutadas ni en el número de páginas del informe.
Está en el criterio que decide dónde mirar, en la capacidad de demostrar rutas de ataque reales y en las mejoras que la organización aplica después.
Las herramientas aportan cobertura. La inteligencia artificial puede aportar velocidad. El equipo experto aporta criterio, validación e impacto real.
La herramienta es el medio. El pentest es el juicio.
¿Necesitas un pentest que vaya más allá del escaneo?
Hard2bit realiza pruebas de penetración sobre aplicaciones web, APIs, redes internas, infraestructura, Active Directory, cloud, contenedores, Wi-Fi y aplicaciones móviles.
Nuestros consultores combinan automatización con pruebas manuales para validar cada hallazgo, descartar falsos positivos, identificar fallos de lógica y autorización, construir rutas de ataque reales y medir el impacto sobre activos críticos.
El resultado no es una lista de vulnerabilidades generada por una herramienta, sino una evaluación técnica realizada por especialistas, con evidencias reproducibles y recomendaciones priorizadas.
Solicita una evaluación de pentesting adaptada a tu entorno y objetivos.
Última revisión técnica: julio de 2026.