Este artículo pretende combinar de forma práctica las metodologías de automatización y pentesting, utilizando inteligencia artificial y múltiples herramientas de código abierto. Más que una lista de comandos, se trata de compartir una metodología replicable, flexible y accesible.
El enfoque que queremos mostrar es cómo, con las herramientas disponibles hoy en día y la ayuda de modelos de IA, es posible mejorar los procesos automatizados, reduciendo la necesidad de esfuerzo manual y dejando más tiempo para centrarse en la explotación y, por qué no, en las partes más divertidas.
El enfoque del atacante
Lo ideal en esta primera fase es pensar como un atacante. Partamos de un escenario típico: tenemos un dominio de empresa, por ejemplo evilcorp.com, y a partir de ahí, empezamos a ampliar nuestra superficie de ataque:
- Reconocimiento de subdominios
- Exploración de puertos
- Análisis de servicios
- Descubrimiento de vulnerabilidades
- Comunicación de resultados
El orden no es aleatorio. Primero se amplía la superficie de ataque, luego se introducen técnicas más activas y, por último, se identifican vulnerabilidades específicas que pueden explotarse.
Ampliación de la superficie de ataque
Continuemos con el ejemplo anterior (utilizando nuestra empresa ficticia, evilcorp), y comprendamos que no debemos limitarnos únicamente a evilcorp.com. Debemos considerar toda la superficie de ataque: subdominios, servicios, direcciones IP y registros DNS. El objetivo es ampliar la superficie de ataque tanto como sea posible antes de pasar a fases más activas.
Hay innumerables herramientas que podemos utilizar, como bbot, buscador secundarioproyectos de sublista3r, que son ideales para proyectos de caja negra (en los que tenemos un conocimiento limitado del objetivo). Por ejemplo, bbot tiene la característica única de autorreforzarse: encuentra subdominios, luego IPs, y sigue ampliando la información disponible automáticamente.
En esta demostración, nos centraremos en buscador de activos y utilizar el e --sólo-subs que rápidamente arroja una larga lista de subdominios. Aquí es donde podemos hacer nuestra primera observación clave:
Aunque encontramos nuevos subdominios, observamos que hay varios duplicados o registros que no se resuelven correctamente. Por eso es crucial filtrar y conservar sólo las entradas que son realmente útiles.
Exploración de puertos
Una vez identificados los subdominios, el siguiente paso es analizar qué servicios están expuestos a través de ellos. Como vimos anteriormente, hay varias herramientas que podemos utilizar:
- masscan
- naabu
- nmap
En nuestro caso, utilizaremos Nmap con los siguientes parámetros:
--top-ports 100(sólo los 100 puertos más comunes)-Pn((para omitir las comprobaciones ICMP/ping)-iL [hosts.txt]((donde pasamos una lista de hosts separados por saltos de línea)abra( (para ver sólo los resultados con puertos abiertos)
Una vez más, como vemos en el vídeo, hay algunos errores que ponen de manifiesto áreas de mejora:
- Varios dominios no se resolvieron.
- Sería mejor utilizar IPs en lugar de subdominios.
Comprender lo que analizamos
Un paso útil, al menos en esta fase, es limitar el número de falsos positivos al intentar analizar una aplicación web, donde podemos utilizar, por ejemplo, httpx para validar si la URL que tenemos responde en un puerto web (80/443). Esto verificará que las aplicaciones son reales, y si queremos analizarlas, sabremos de antemano que el servicio está funcionando sin problemas.
También podríamos considerar un escenario en el que nuestro escáner de puertos reciba la entrada de direcciones IP directamente, ya que en algunos casos falla al resolver o analizar los dominios asociados. Para ello, podemos utilizar un one-liner como el que se muestra a continuación, donde a partir de un txt de subdominios, podemos resolver las direcciones IP a las que resuelven (para pasarlas después, por ejemplo, a nmap).
¿Y ahora?
Con una lista depurada de IP, dominios y subdominios validados y confirmados, podemos pasar a la fase de análisis de vulnerabilidades, en la que, de nuevo, muchas herramientas de código abierto pueden ayudarnos:
En nuestro caso, nos centraremos en nuclei debido a su versatilidad, ya que permite ejecutar muchas (y variadas) pruebas en poco tiempo, utilizando plantillas que detectan desde configuraciones de seguridad incorrectas hasta vulnerabilidades específicas como paneles expuestos, versiones de software desactualizadas o endpoints con respuestas interesantes (por ejemplo, copias de seguridad expuestas).
Ahora bien, el problema surge cuando la exploración genera cientos de hallazgos. ¿Cómo establecemos prioridades? ¿Cómo lo convertimos en algo útil para el equipo de seguridad o la dirección? Aquí es donde la inteligencia artificial empieza a desempeñar un papel clave. Utilizando modelos como GPT -ya sea a través de servicios como OpenAI o ejecutando modelos locales como los que ofrece Ollama- podemos analizar esos resultados, agruparlos por gravedad, generar explicaciones legibles para personas no técnicas e incluso proponer posibles soluciones.
Esto no es teoría: hoy en día ya se generan informes automáticos que convierten 200 conclusiones técnicas en un resumen de dos páginas, con riesgos priorizados, impacto estimado y lenguaje comprensible para las áreas de negocio. Incluso es posible producir dos versiones del mismo informe: una técnica para el equipo de infraestructuras y otra ejecutiva para el CISO o el consejo de administración.
La verdadera potencia reside en la automatización de todo el flujo de trabajo: desde la entrada con una lista de dominios, pasando por la resolución de IP, el escaneado con Nuclei, el análisis AI de los resultados, hasta la generación automática del informe final. Todo esto puede integrarse con scripts Bash o Python, tareas programadas con cron, pipelines que se ejecutan cuando se recibe una nueva lista de objetivos o tras una alerta en el SIEM. Lo importante no es sólo que sea automático, sino que esté diseñado para escalar sin perder el contexto.
Y como en toda buena automatización, siempre hay lugar para la revisión manual. Porque la IA puede sugerir, pero el analista decide. Lo valioso no es solo el código o las herramientas, sino cómo diseñamos el flujo, cómo elegimos qué automatizar y dónde seguimos aplicando el juicio humano.
Automatizar no es sustituir al analista, sino permitirle centrarse en lo que realmente importa. Qué parte de su flujo de trabajo podría automatizar mañana?
Gabriel Franco
Gabriel Franco, es la persona que lidera el área de servicios de seguridad en Faraday explica que su formación proviene del mundo técnico, concretamente del desarrollo. Su primera aproximación al pentesting fue precisamente desde ese ángulo: creando scripts y automatizaciones para ejecutar herramientas de análisis y ahorrar tiempo, con el foco puesto en obtener resultados de forma más rápida y efectiva.
Con el tiempo, asumieron más funciones de gestión, pero siguen participando en tareas técnicas, sobre todo cuando encuentran algo que puede mejorarse o automatizarse. Explican que, dentro del equipo, siempre están atentos a los patrones que se repiten en distintos proyectos. Cuando detectan tareas recurrentes, tratan de automatizarlas para centrarse en lo que realmente aporta valor.
¿Formación, servicios de red teaming o escaneado continuo? Le tenemos cubierto. ⚡
