PentAGI: Automatización avanzada de penetration testing con agentes AI autónomos

En los últimos años, el pentesting ha evolucionado desde procesos manuales altamente especializados hacia flujos híbridos donde la automatización y la inteligencia artificial ayudan a acelerar descubrimientos, correlacionar hallazgos y priorizar vectores de ataque. En ese contexto surge PentAGI, una plataforma diseñada para coordinar agentes autónomos de IA capaces de ejecutar tareas complejas de penetration testing de forma iterativa y contextual.

Para pentesters, red teams y equipos de security automation, PentAGI resulta interesante por varias razones:

  • Permite orquestar múltiples herramientas de seguridad bajo una capa de inteligencia que toma decisiones.
  • Mantiene memoria semántica del objetivo y del entorno de ataque.
  • Automatiza cadenas completas de ataque (reconocimiento → enumeración → explotación → post-explotación).
  • Reduce el tiempo necesario para correlacionar resultados de diferentes herramientas.

En entornos reales de pentesting —especialmente durante evaluaciones internas o pruebas continuas de seguridad— el problema habitual no es la falta de herramientas, sino la coordinación entre ellas y la interpretación del contexto. PentAGI aborda este problema mediante agentes especializados que analizan resultados, actualizan una base de conocimiento y planifican los siguientes pasos del ataque.

Contexto técnico y arquitectura de PentAGI

PentAGI sigue una arquitectura multi-agente orientada a tareas, donde cada agente tiene responsabilidades específicas dentro del flujo de pentesting.

Téneis toda la info en https://pentagi.com/ pero si queréis probarlo rápido os recomendamos montar un entorno rápido como el siguiente.

Escenario de laboratorio reproducible para pruebas con PentAGI

Para evaluar correctamente el funcionamiento de PentAGI es fundamental trabajar en un entorno controlado y reproducible. En esta sección construiremos un laboratorio de pentesting interno con servicios vulnerables reales que permitirán observar cómo los agentes autónomos toman decisiones durante un ataque.

El objetivo del laboratorio es simular una pequeña red corporativa vulnerable que contenga múltiples vectores de ataque explotables. El laboratorio se ejecutará completamente dentro de Docker para facilitar la reproducibilidad.

Arquitectura del laboratorio

                      Red de laboratorio
                       172.19.0.0/24
                           
        ┌───────────────────────────────────┐
        │                                   │
        │           PentAGI Node            │
        │       (Orquestador + Agents)      │
        │           172.18.0.5              │
        │                                   │
        └───────────────┬───────────────────┘
                        │
                        │
        ┌───────────────┼──────────────────────────┐
        │               │                          │
        │               │                          │
        ▼               ▼                          ▼
  172.18.0.10     172.18.0.11                172.18.0.12
  Web Server      FTP Server                 Windows SMB
  Vulnerable      Weak Credentials           Lateral Movement

Requisitos de hardware recomendados

Para ejecutar el laboratorio con fluidez:

  • CPU: 4 cores mínimo
  • RAM: 8 GB mínimo
  • RAM recomendada: 16 GB
  • Disco: 20 GB libres

Preparación del entorno base

Primero crearemos una red Docker dedicada al laboratorio. Esto permitirá que PentAGI interactúe con los sistemas vulnerables como si estuviera dentro de una red corporativa real.

docker network create \
--subnet 172.18.0.0/24 \
pentest-lab
Verificar la red:
docker network inspect pentest-lab

Servidor Web vulnerable

Este host simula una aplicación web corporativa expuesta internamente. Incluye vulnerabilidades típicas que PentAGI puede detectar.

Servicios activos:

  • HTTP (puerto 80)
  • Aplicación web vulnerable
  • Panel de login

Vulnerabilidades esperadas:

  • SQL Injection
  • Credenciales débiles
  • Directory discovery

Software utilizado:

Apache 2.4.x
DVWA (Damn Vulnerable Web Application)
PHP
MySQL
Para el despliegue lanzaremos un contenedor con una aplicación vulnerable.
docker run -d \
--name lab-web \
--network pentest-lab \
--ip 172.18.0.10 \
-p 8081:80 \
vulnerables/web-dvwa
Verificación:
curl http://localhost:8081
Resultado esperado:
DVWA Login Page
Credenciales por defecto:
admin : password

Servidor FTP vulnerable

Este host permite validar cómo PentAGI intenta comprometer servicios expuestos con configuraciones débiles.

Características:

  • FTP accesible desde la red interna.
  • Credenciales débiles.
  • Posible exploit disponible.

Software:

vsftpd vulnerable version
anonymous login disabled
weak credentials enabled
Despliegue:
docker run -d \
--name lab-ftp \
--network pentest-lab \
--ip 172.18.0.11 \
-p 2121:21 \
-e FTP_USER=test \
-e FTP_PASS=test \
-e PASV_ADDRESS=127.0.0.1 \
fauria/vsftpd
Probar conexión:
ftp localhost 2121
Credenciales débiles configuradas para el laboratorio:
test : test

Servidor Windows para movimiento lateral

Este sistema representa un objetivo típico dentro de una red interna corporativa. Una vez comprometido otro host, PentAGI intentará pivotar hacia este sistema.

Servicios:

  • SMB
  • RPC
  • WinRM (opcional)

Configuración vulnerable:

  • Credenciales reutilizadas.
  • Comparticiones accesibles.
  • Enumeración SMB posible.

Para reproducibilidad rápida en laboratorio, podemos usar una imagen de SMB vulnerable o un contenedor con Samba configurado de forma insegura. 

docker run -d \
--name lab-smb \
--network pentest-lab \
--ip 172.18.0.12 \
-p 4455:445 \
dperson/samba \
-p \
-u "admin;admin" \
-s "share;/shared;yes;no;yes"
Esto crea:
  • Usuario SMB vulnerable
  • Share accesible
  • Credenciales reutilizadas

Validación de la topología

Desde el host atacante: 
nmap 172.18.0.0/24
Resultado esperado aproximado: 
$ nmap 172.18.0.0/24
Starting Nmap 7.94SVN ( https://nmap.org ) at 2026-02-20 23:44 CET
Nmap scan report for 172.18.0.10
Host is up (0.0000090s latency).
Not shown: 999 closed tcp ports (reset)
PORT   STATE SERVICE
80/tcp open  http
MAC Address: 02:42:AC:13:00:0A (Unknown)

Nmap scan report for 172.18.0.11
Host is up (0.0000090s latency).
Not shown: 999 closed tcp ports (reset)
PORT   STATE SERVICE
21/tcp open  ftp
MAC Address: 02:42:AC:13:00:0B (Unknown)

Nmap scan report for 172.18.0.12
Host is up (0.0000090s latency).
Not shown: 998 closed tcp ports (reset)
PORT    STATE SERVICE
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds
MAC Address: 02:42:AC:13:00:0C (Unknown)
Esto confirma que el laboratorio está listo para PentAGI.

Escenario de ataque que se espera reproducir

Ruta de ataque típica dentro del laboratorio:
Recon → Web discovery
        ↓
FTP credential attack
        ↓
Shell access
        ↓
Credential reuse
        ↓
SMB lateral movement 

Integración del laboratorio con PentAGI

Por si no habéis instalado todavía PentAGI:
mkdir -p pentagi && cd pentagi

wget -O installer.zip https://pentagi.com/downloads/linux/amd64/installer-latest.zip

unzip installer.zip
./installer

Ahora conectaremos PentAGI a la misma red. Editar docker-compose: 
networks:
  pentest-lab:
    external: true
Luego iniciar el sistema: 
docker compose up -d
Verificar conectividad desde PentAGI: 
docker exec -it pentagi-backend ping 172.18.0.10

Configuración del objetivo dentro de PentAGI

Si todo ha ido bien ya podemos configurar y lanzar el pentest dentro del panel de PentAGI: 

Objetivo: 172.18.0.0/24
Modo: Autonomous Pentest
Nivel de exploración: Medium
Profundidad de ataque: 5


Cuando PentAGI inicia el análisis ocurre esta secuencia: 
Subtask 1
Scope Confirmation & Environment Setup
Verify that the target network 172.18.0.0/24 is correctly defined, ensure the Kali container has an interface in that subnet or can reach it, and start required services (e.g., nmap). Include checking that no conflicting IPs exist and confirming that work is authorized.

Subtask 2
Live Host Discovery with Ping Sweep
Execute an ICMP ping sweep across 172.18.0.0/24 using nmap -sn to list all active hosts. Save output to 'live_hosts.txt'. This identifies reachable machines for further scanning.

Subtask 3
Comprehensive TCP Port Scanning
Run nmap -sS -p- -T4 on each discovered host to enumerate all open ports. Output to 'ports_scan.txt'. This reveals potential attack surface.

Subtask 4
Service and Version Detection with Vulnerability Scripting
Perform nmap -sV --script=vuln -T4 on the target hosts to detect service versions and known CVEs. Save as 'service_version.txt'. This provides exploitation candidates.

Subtask 5
Exploit Research and Path Selection
Use the search tool to query CVE details for detected services/versions, and select up to two high‑impact exploits. Document exploit identifiers and required payloads.

Subtask 6
Exploit Execution via Metasploit
Load the selected exploits in msfconsole, configure payloads (e.g., meterpreter/reverse_tcp), set targets, and run the exploits to gain session access. Capture session IDs.

Subtask 7
Post‑Exploitation – Information Gathering and Privilege Escalation
On each compromised session, run meterpreter commands to collect user list, hash dump, and attempt kernel exploits for privilege escalation. Record successful escalations.

Subtask 8
Report Compilation and Recommendations
Consolidate findings, including discovered hosts, open ports, services, exploited vulnerabilities, and post‑exploitation outcomes. Provide remediation suggestions and an executive summary. Save as 'pentest_report.pdf'.
Y empezaremos a ver una salida inicial como esta: 
Recon Agent started
Scanning subnet 172.18.0.0/24
3 hosts discovered
Enumerating services
FTP vulnerable detected...
Enjoy!

Comentarios

Publicar un comentario