Automatización y Pentesting: Usa la IA y herramientas Open-Source

Este artículo tiene como objetivo combinar la automatización y metodologías de pentesting de forma práctica, usando 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.

Lo ideal en esta primera parte, es pensar como un atacante. Partamos desde 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 busca vulnerabilidades concretas que puedan ser explotadas. 

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 assetfinder:

Sigamos con el ejemplo de antes (tomando a nuestra compañía evilcorp), y entendamos 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, subfinder, sublist3r entre otras, que resultan ideales para proyectos blackbox (donde tengo poco conocimiento del objetivo). Por ejemplo, bbot tiene la particularidad de retroalimentarse: va encontrando subdominios, luego IPs, y sigue expandiendo automáticamente la información disponible. 

En esta demo nos vamos a centrar en assetfinder y usaremos el parámetro –subs-only, 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.

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::

• masscan

• naabu

• nmap

Nosotros en nuestro caso vamos a usar Nmap con los parámetros:

•  –top-ports 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 hosts 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 resolvieron.
• Quizás sea mejor utilizar IPs en lugar de subdominios.

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 httpx para 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 scanner de puertos reciba 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 IPs que resuelven (para luego ser pasadas por ejemplo a nmap).

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:

• OpenVAS (mas centrado en infraestructura)
• nuclei 
• nikto (mas centrado en web)

En nuestro caso, vamos a centrarnos por nuclei por la versatilidad que tiene, ya que permite ejecutar muchas pruebas (y variadas) en poco tiempo, utilizando templates que detectan desde configuraciones incorrectas de seguridad como vulnerabilidades específicas como paneles expuestos, versiones obsoletas de software o endpoints con respuestas interesantes (por ejemplo, backups expuestos). 

Ahora bien, el problema aparece cuando el escaneo genera cientos de findings. ¿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 findings 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 reporte: 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 reemplazar al analista, es permitirle enfocarse en lo que realmente importa. ¿Qué parte de tu flujo podrías automatizar mañana mismo?

Mirá la charla completa acá

Gabriel Franco, quien lidera el área de servicios de seguridad en Faraday, cuenta que su formación viene 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.

Trainings, red teaming services, or continuous scanning? We’ve got you covered. 🚀⚡ 

Reach out for more information.