Este artículo tiene como objetivo combinar la automatización y metodologías de pentesting de forma práctica, utilizando inteligencia artificial y múltiples herramientas opensource. Más que un simple repaso de comandos, se trata de compartir una metodología replicable, flexible y accesible.
El enfoque que queremos mostrar es como con las herramientas que hoy en día son públicas y con ayuda de modelos de IA es posible mejorar procesos automáticos donde no se requiera tiempo manual y dedicarlo justamente a aspectos de explotación y, por que no, algo más divertido.
El enfoque del atacante
Lo ideal en esta primera parte, es pensar como un atacante. Partamos de una situación típica: tenemos el dominio de una empresa, por ejemplo evilcorp.com, y desde ahí, empecemos a ampliar nuestra superficie de ataque:
- Reconocimiento de subdominios
- Análisis de puertos
- Análisis de servicios
- Búsqueda de vulnerabilidades
- Reporte de lo identificado
El orden no es casual. Primero se amplía la superficie de ataque, después se avanza en técnicas más activas, y finalmente se buscan vulnerabilidades concretas que puedan ser explotadas.
Expansión de la superficie de ataque
Cuando comenzamos un nuevo proyecto, solemos estar a ciegas. Por eso, existen muchas herramientas que nos ayudan a hacer los primeros descubrimientos y nosotros usaremos buscador de activos:
Sigamos con el ejemplo de antes (tomando a nuestra compañía evilcorp), y entendemos que no solo tenemos que limitarlos a evilcorp.com, sino contemplar toda su superficie (subdominios, servicios, direcciones IP, registros DNS). El objetivo es ampliar lo máximo posible la superficie de ataque antes de pasar a etapas más activas.
Hay un sinfín de herramientas que podemos utilizar como por ejemplo bbot, buscador secundario, sublista3r entre otras, que resultan ideales para proyectos caja negra (donde tengo poco conocimiento del objetivo). Por ejemplo, bbot tiene la particularidad de retroalimentarse: va encontrando subdominios, luego IPs, y sigue ampliando automáticamente la información disponible.
En esta demo nos vamos a centrar en buscador de activos y usaremos el parámetro -sólo submarinos, lo que rápidamente arroja una larga lista de subdominios. Acá es donde podemos hacer nuestra primera observación:
Si bien hay nuevos subdominios, notamos que existen varios duplicados o registros que no resuelven correctamente. Por eso, es clave filtrar y quedarse solo con lo que realmente sirve.
Escaneo de puertos
Una vez identificados los subdominios, el siguiente paso es analizar qué servicios están expuestos a través de ellos. Tal como vimos antes existen varias herramientas que podemos usar:
Nosotros en nuestro caso vamos a usar Nmap con los parámetros:
- -top-puertos 100 (solo los 100 puertos más conocidos) de puertos más comunes
- -Pn (para que no solo haga pruebas por ICMP/ping)
- -iL [hosts.txt] (donde le pasamos una lista de alberga separados por saltos de línea)
- open (para ver solo resultados de puertos abiertos)
Nuevamente, como vemos en el video, tenemos errores que nos indican algunos puntos de mejora:
- Varios dominios no se resolvieron.
- Quizás sea mejor utilizar IPs en lugar de subdominios.
Entender qué estamos analizando
Un paso útil, por lo menos en esta etapa, es limitar la cantidad de falsos positivos al momento de querer analizar alguna aplicación web, donde podemos utilizar por ejemplo httpxpara validar si la URL que tenemos responde a un puerto web (80/443). Esto validará que las aplicaciones sean reales, y que en caso de querer analizarla sepamos con anticipación que el servicio está corriendo sin problemas.
También, podríamos plantear un escenario en el que nuestro escáner de puertos recibe una entrada de direcciones IP directamente, ya que en algunos casos no logra resolver o analizar los dominios asociados. Para eso, podemos usar un oneliner como el que mostramos debajo y donde a partir de un archivo txt de subdominios, podemos resolver las direcciones IP que resuelven (para luego ser pasadas por ejemplo a nmap).
¿Y ahora?
Ya teniendo una lista depurada de IPs, dominios, subdominios validados y confirmados, podemos pasar a la etapa de análisis de vulnerabilidades, donde de nuevo, muchas herramientas opensource nos pueden ayudar:
En nuestro caso, vamos a centrarnos por núcleos por la versatilidad que tiene, ya que permite ejecutar muchas pruebas (y variadas) en poco tiempo, utilizando plantillas que detectan desde configuraciones incorrectas de seguridad como vulnerabilidades específicas como paneles expuestos, versiones obsoletas de software o puntos finales con respuestas interesantes (por ejemplo, copias de seguridad expuestos).
Ahora bien, el problema aparece cuando el escaneo genera cientos de hallazgos. ¿Cómo priorizamos? ¿Cómo transformamos eso en algo útil para el equipo de seguridad o para la gerencia? Acá es donde la inteligencia artificial empieza a cumplir un rol 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 criticidad, generar explicaciones legibles para no técnicos e incluso proponer posibles soluciones.
Esto no es teoría: hoy ya se están generando informes automáticos que convierten 200 hallazgos técnicos en un resumen de dos páginas, con riesgos priorizados, impacto estimado y un lenguaje entendible para áreas de negocio. Incluso se pueden producir dos versiones del mismo informe: una técnica para el equipo de infraestructura, y otra ejecutiva para el CISO o el board.
El verdadero poder está en la automatización del flujo completo: desde la entrada con una lista de dominios, pasando por la resolución de IPs, el escaneo con Nuclei, el análisis de resultados con IA, hasta la generación automática del reporte final. Todo esto puede integrarse con scripts en Bash o Python, tareas programadas con cron, pipelines que corren al recibir una nueva lista de targets o tras una alerta en el SIEM. Lo importante no es solo que sea automático, sino que esté pensado para escalar sin perder contexto.
Y como toda buena automatización, siempre hay un espacio para la revisión manual. Porque la IA puede sugerir, pero quien decide es el analista. 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 aportando criterio humano.
Automatizar no es sustituir al analista, es permitirle centrarse en lo que realmente importa. ¿Qué parte de tu flujo podrías automatizar mañana mismo?
Gabriel Franco
Gabriel Franco, quien lidera el área de servicios de seguridad en Faraday, cuenta que su formación proviene del mundo técnico, específicamente desde el desarrollo. Su primer acercamiento al pentesting fue justamente desde ese ángulo: crear scripts y automatizaciones para ejecutar herramientas de análisis y ahorrar tiempo, con el foco puesto en obtener resultados más rápido y de forma más efectiva.
Con el tiempo, fue tomando roles de mayor gestión, pero sigue involucrándose en tareas técnicas, sobre todo cuando encuentra algo que se puede mejorar o automatizar. Explica que dentro del equipo siempre están atentos a los patrones que se repiten entre distintos proyectos. Cuando detectan tareas que se reiteran, buscan automatizarlas para concentrarse en lo que realmente agrega valor.
¿Formación, servicios de red teaming o escaneado continuo? Le tenemos cubierto. ⚡
