Saltar a contenido
Intermedio Tiempo estimado: "16 min" Categoría: Ciberseguridad Publicado

Pentesting Básico (auditoría propia)

Resumen

Esta guía explica la metodología de un test de intrusión (pentest) desde la óptica de un equipo DevOps que quiere auditar su propia infraestructura. No es un recetario de exploits: es el método por el que un atacante mira tus sistemas, para que tú lo hagas primero y te defiendas mejor. Cubre las fases del pentest, reconocimiento pasivo y activo, y el uso legítimo de Nmap, Burp Suite y Metasploit sobre labs propios, terminando en lo que de verdad se entrega: el informe.

Esto es el complemento ofensivo de la documentación defensiva de esta sección. El escaneo de vulnerabilidades automatiza la búsqueda de CVEs en tus imágenes; un pentest va más allá y valida si esas debilidades son explotables en tu contexto real. El modelo de amenazas predice por dónde te atacarán; el pentest lo comprueba. Y todo lo que hagas aquí genera exactamente los eventos que responde el playbook de respuesta a incidentes.

Esta es la sección más importante del documento y va primero por una razón: un pentest sin autorización escrita es un delito, no una zona gris. En España encaja en los artículos 197 bis y 264 del Código Penal (acceso no consentido a sistemas y daños informáticos); en otros países existen equivalentes (Computer Fraud and Abuse Act en EE. UU., Computer Misuse Act en Reino Unido). Escanear puertos de un tercero "solo para mirar" ya puede constituir acceso ilícito. La diferencia entre un profesional de seguridad y un delincuente no es la herramienta: es el permiso.

Sin autorización escrita, no se toca

No hay excepción de buena intención. "Iba a avisarles del fallo" no es una defensa legal. Antes de lanzar una sola herramienta contra un sistema, necesitas por escrito: quién autoriza (con potestad para hacerlo), qué sistemas entran en alcance, qué técnicas se permiten y en qué ventana de tiempo. Si no lo tienes, el único objetivo legítimo es infraestructura tuya o un laboratorio diseñado para ello.

El documento que recoge todo eso se llama Rules of Engagement (RoE) y scope. El scope define qué está dentro y qué está fuera: rangos de IP y dominios concretos, sistemas explícitamente excluidos (a menudo los más frágiles: SCADA, sistemas médicos, producción crítica), y ventanas horarias. Las Rules of Engagement fijan las reglas del juego: qué técnicas se permiten (¿ingeniería social sí o no?, ¿denegación de servicio nunca?), a quién avisar si encuentras un compromiso ya existente de otro atacante, y un contacto de emergencia para parar si algo se rompe.

Por eso se practica en entornos diseñados para ello, nunca contra terceros:

  • Laboratorios propios: máquinas virtuales que levantas tú, aisladas en una red interna, para reproducir tu infraestructura o un servicio concreto que quieres auditar.
  • Plataformas de práctica legal: Hack The Box, TryHackMe y similares te dan objetivos vulnerables que eres bienvenido a atacar porque para eso existen.
  • Aplicaciones deliberadamente vulnerables para montar en tu lab: DVWA (Damn Vulnerable Web Application) para web, y Metasploitable como diana de red completa.

Tu propia infraestructura también tiene reglas

Auditar tus sistemas no te exime de coordinar. Un escaneo agresivo en producción puede tumbar un servicio; una fuerza bruta puede bloquear cuentas reales. Avisa a tu equipo, hazlo en ventana acordada y ten un plan de vuelta atrás. Autoridad para atacar no es lo mismo que permiso para causar una caída no planificada.

Metodología: las cinco fases

Un pentest es un proceso ordenado, no una sucesión de trucos. Las fases se encadenan y a menudo se realimentan: lo que descubres explotando te manda de vuelta a enumerar.

graph LR
    A[Reconocimiento] --> B[Enumeración]
    B --> C[Explotación]
    C --> D[Post-explotación]
    D --> E[Informe]
    C -.nuevo objetivo.-> B
    D -.pivote.-> A
    style A fill:#264653,color:#fff
    style E fill:#7f5539,color:#fff
  • Reconocimiento: reunir información sobre el objetivo. Cuanto mejor sea esta fase, más fácil es todo lo demás.
  • Enumeración: pasar de "existe este host" a "corre esta versión concreta de este servicio en este puerto". Es reconocimiento activo y detallado.
  • Explotación: usar una debilidad para obtener acceso o demostrar impacto. En una auditoría honesta, muchas veces se queda en "esto es explotable" sin llegar a hacer daño.
  • Post-explotación: una vez dentro, ¿hasta dónde se llega? Escalada de privilegios, alcance de los datos accesibles, posibilidad de pivotar a otros sistemas. Aquí se mide el impacto real.
  • Informe: la entrega. Todo lo anterior no vale nada si no se traduce en algo accionable. Le dedicamos su propia sección porque es lo que casi nadie hace bien.

Reconocimiento

El reconocimiento se divide en pasivo y activo, y la diferencia importa tanto legal como técnicamente.

El reconocimiento pasivo no toca el objetivo: consultas fuentes de terceros. Como no envías tráfico a sus sistemas, es la parte menos intrusiva y donde empieza cualquier auditoría seria.

  • OSINT (Open Source Intelligence): información pública. Registros WHOIS, filtraciones de credenciales conocidas, metadatos de documentos publicados, repositorios de código con secretos olvidados, ofertas de empleo que revelan qué tecnología usas.
  • DNS: los registros DNS de un dominio revelan subdominios, servidores de correo (MX), y a veces infraestructura interna mal expuesta. dig y host consultan servidores DNS públicos, no tu objetivo.
  • Certificate Transparency: cada certificado TLS emitido se registra en logs públicos y auditables. Buscar en crt.sh por tu dominio revela subdominios que ni recordabas que existían, porque cada uno necesitó un certificado en algún momento.
# Reconocimiento pasivo — SOLO consulta fuentes públicas, no toca el objetivo
# Registros DNS de un dominio propio
dig +short frikiteam.example ANY
dig +short frikiteam.example MX
dig +short frikiteam.example TXT

# Transferencia de zona (casi siempre denegada; si funciona, es un hallazgo)
dig AXFR frikiteam.example @ns1.frikiteam.example

# Certificate Transparency: subdominios via certificados emitidos
# crt.sh devuelve JSON; se filtran nombres únicos
curl -s 'https://crt.sh/?q=%25.frikiteam.example&output=json' | jq -r '.[].name_value' | sort -u

El reconocimiento activo sí envía tráfico al objetivo: escaneo de puertos, sondeo de servicios, peticiones a la aplicación web. Es más ruidoso, deja rastro en logs y requiere estar dentro del scope. Aquí es donde entra Nmap.

El reconocimiento pasivo también es defensa

Haz sobre ti mismo lo que haría un atacante. Buscar tu propia superficie expuesta en Certificate Transparency y en buscadores de dispositivos suele revelar servicios que no sabías que estaban públicos. Es de lo más barato y efectivo que puede hacer un equipo DevOps.

Nmap: enumeración de red

Nmap es la herramienta estándar para descubrir hosts, puertos abiertos y qué servicios corren detrás. Lo relevante no es memorizar flags, sino entender qué hace cada tipo de escaneo y por qué eliges uno u otro.

Los tipos de escaneo más usados:

  • -sS (SYN scan): envía el SYN inicial pero no completa el handshake TCP. Es el escaneo por defecto cuando tienes privilegios (requiere root/CAP_NET_RAW). Rápido y relativamente discreto.
  • -sT (TCP connect): completa el handshake usando la pila del sistema operativo. Es el que se usa sin privilegios; deja más rastro en los logs del objetivo.
  • -sU (UDP scan): escanea puertos UDP (DNS, SNMP, NTP). Es lento por naturaleza porque UDP no confirma como TCP, pero servicios críticos viven ahí.
  • -sn (ping scan): descubre qué hosts están vivos sin escanear puertos. Útil para mapear un rango antes de profundizar.

La detección de servicios y versiones es donde Nmap aporta más valor para una auditoría:

  • -sV: sondea los puertos abiertos para identificar el servicio y su versión exacta. Saber que corres "OpenSSH 8.9" en lugar de "algo en el 22" es la diferencia entre poder cruzarlo con CVEs conocidos o no.
  • -O: intenta identificar el sistema operativo por su huella de pila TCP/IP.
  • -sC: ejecuta el conjunto de scripts NSE por defecto (comprobaciones seguras y comunes). -A combina -sV -O -sC y traceroute en un solo flag agresivo.

Los tiempos (-T0 a -T5) controlan la agresividad. -T3 es el valor por defecto. -T4 acelera y es razonable en redes rápidas; -T5 es tan agresivo que puede perder resultados. Los lentos (-T0, -T1) reducen el impacto y el ruido.

# Descubrimiento de hosts en tu propia subred de laboratorio
nmap -sn 192.168.56.0/24

# Escaneo SYN + detección de versión de un host de tu lab (Metasploitable)
sudo nmap -sS -sV -T4 192.168.56.101

# Escaneo completo con scripts por defecto y detección de SO
sudo nmap -sS -sV -sC -O -T4 -p- 192.168.56.101

# Guardar en todos los formatos para el informe (normal, grepable, XML)
sudo nmap -sS -sV -T4 -oA recon-lab-101 192.168.56.101

Un escaneo agresivo tumba servicios frágiles

-T5, -A o -p- (los 65535 puertos) contra un servicio delicado —una impresora de red, un dispositivo IoT, un SCADA, una base de datos vieja— puede saturarlo hasta hacerlo caer. No es teórico: hay equipos que se cuelgan con un simple escaneo de versión. Por eso el scope excluye sistemas frágiles y por eso, contra producción propia, empiezas con -T2 y subes con cuidado. Un pentest que tira el servicio que auditaba ha fracasado.

Burp Suite: auditar tu propia app web

Burp Suite es la herramienta de referencia para auditar aplicaciones web. Su idea central es actuar como proxy de interceptación: se sitúa entre tu navegador y la aplicación, y ve (y deja modificar) cada petición y respuesta HTTP. Existe una edición Community gratuita, suficiente para aprender y para auditar tu propia app; la Professional añade el escáner automático.

El flujo de trabajo conceptual, contra tu propio DVWA o tu app en un entorno de pruebas:

  1. Configurar el proxy: apuntas el navegador al proxy de Burp (por defecto 127.0.0.1:8080) e instalas su certificado CA para poder ver el tráfico HTTPS. A partir de ahí, todo lo que hace el navegador pasa por Burp.
  2. Navegar para poblar el árbol del sitio: usas la aplicación con normalidad. Burp va construyendo un mapa de endpoints, parámetros y flujos en su pestaña Target.
  3. Interceptar (Proxy → Intercept): pausas una petición antes de que salga, ves sus cabeceras, cookies y cuerpo, y decides si la dejas pasar o la editas. Aquí entiendes de verdad qué envía tu app.
  4. Repeater: envías una petición a Repeater para modificarla y reenviarla cuantas veces quieras, observando cómo cambia la respuesta. Es la herramienta manual por excelencia para probar, por ejemplo, si un parámetro que debería ser tuyo acepta el ID de otro usuario (un control de acceso roto, del modelo de amenazas).
  5. Intruder: automatiza el envío de muchas variantes de una petición, útil para probar sistemáticamente un conjunto de entradas sobre un mismo parámetro. En la edición Community está limitado en velocidad, pero sirve para tu propio lab.

Repeater e Intruder solo contra lo tuyo

Estas herramientas envían tráfico real y potencialmente dañino. Un Intruder mal apuntado es indistinguible de un ataque. Úsalas exclusivamente contra aplicaciones que controlas o que están dentro de un scope autorizado. Confirma la ruta exacta de cada función en tu versión de Burp: la interfaz cambia entre ediciones.

Metasploit: validar un CVE en tu lab

Metasploit es un framework de explotación. Su valor legítimo para un equipo DevOps no es "hackear": es validar que una vulnerabilidad concreta te afecta de verdad. El escaneo de vulnerabilidades te dice "esta imagen tiene el CVE-X"; Metasploit, contra una copia en tu lab, te confirma si ese CVE es realmente explotable en tu configuración o si un mitigante lo hace inofensivo. Eso convierte una lista de cientos de CVEs teóricos en una lista corta de riesgos reales que priorizar.

Su estructura:

  • Módulos: el catálogo de capacidades, organizado por tipo. Los exploit aprovechan una vulnerabilidad; los auxiliary hacen tareas de apoyo (escáneres, fuzzers, fuerza bruta); los post actúan tras conseguir acceso.
  • Payloads: el código que se ejecuta si el exploit tiene éxito. Un payload puede ser tan simple como abrir un puerto, o una sesión interactiva completa como Meterpreter, la shell avanzada de Metasploit.
  • Handlers: el componente que espera y recibe la conexión de vuelta de un payload. Un exploit lanza el payload; el handler recoge la sesión resultante.

El flujo típico en la consola msfconsole, contra Metasploitable en tu red aislada:

# Dentro de msfconsole — objetivo: una copia vulnerable EN TU LAB
# Buscar módulos relacionados con un servicio concreto
search type:exploit name:vsftpd

# Seleccionar un módulo y ver qué opciones necesita
use exploit/unix/ftp/vsftpd_234_backdoor
show options

# Fijar el objetivo (RHOSTS es tu VM de laboratorio, nunca un tercero)
set RHOSTS 192.168.56.101

# Comprobar sin explotar cuando el módulo lo soporta
check

# Ejecutar contra tu propio lab y confirmar si el CVE aplica
run

Confirma nombres de módulo en tu versión

Los nombres de módulos, sus opciones y su disponibilidad cambian entre versiones de Metasploit. El módulo del ejemplo (vsftpd_234_backdoor) es un caso histórico y muy conocido, usado aquí solo con fines ilustrativos sobre un objetivo de laboratorio diseñado para ser vulnerable. Verifica siempre con search y show options lo que existe en tu instalación; no des por buenos nombres de memoria.

Escaneo de credenciales débiles en tu infraestructura

Este es el caso de uso más directamente útil para un equipo DevOps, porque las credenciales débiles y por defecto siguen siendo una de las vías de entrada más comunes (encaja en Identification and Authentication Failures del modelo de amenazas). Auditar tu propia flota buscando contraseñas triviales, cuentas por defecto sin cambiar y claves reutilizadas encuentra problemas reales antes que un atacante.

La idea no es descifrar contraseñas ajenas, sino comprobar tu postura: ¿queda algún admin/admin en un panel interno?, ¿alguna base de datos con la contraseña de ejemplo?, ¿algún servicio que aceptaría un diccionario básico?

# Auditoría de credenciales débiles — SOLO contra servicios propios y autorizados
# hydra: prueba una lista corta de credenciales contra un SSH de tu lab
# Hazlo en ventana acordada: un fallo masivo puede bloquear cuentas reales
hydra -L usuarios.txt -P passwords-comunes.txt ssh://192.168.56.101 -t 4

# Nmap trae scripts NSE para detectar credenciales por defecto de forma más suave
sudo nmap --script ssh-auth-methods,ssh-brute -p 22 192.168.56.101

# Verificar hashes filtrados de TU propio volcado con John the Ripper
# (por ejemplo, tras rotar y querer comprobar que las nuevas son robustas)
john --wordlist=passwords-comunes.txt hashes-propios.txt

El bloqueo de cuentas es un efecto colateral real

Una prueba de fuerza bruta, aunque sea contra ti mismo, puede disparar políticas de bloqueo y dejar sin acceso a usuarios legítimos, o incluso generar una denegación de servicio. Limita la concurrencia (-t), usa diccionarios cortos y dirigidos, y coordina con quien opera el servicio. El objetivo es medir tu exposición, no auto-infligirte un incidente.

El informe: la entrega real

Aquí está el trabajo de verdad, y es lo que casi nadie documenta bien. Un pentest sin informe es una anécdota: "encontré cosas". El informe es lo que convierte horas de terminal en decisiones y arreglos. Un hallazgo que no se puede reproducir, no se puede arreglar; un hallazgo sin impacto explicado, no se prioriza.

Cada hallazgo debe llevar cinco elementos, siempre los mismos:

  1. Hallazgo: qué es, en una frase clara. "El panel de administración interno acepta las credenciales por defecto admin/admin."
  2. Evidencia reproducible: los pasos exactos para que otra persona lo confirme, con el comando o la petición literal y la respuesta obtenida. Sin esto, el equipo de desarrollo no puede ni verificar ni saber cuándo lo ha corregido.
  3. Impacto: qué consigue un atacante con esto en tu contexto. No "es un XSS", sino "un atacante puede robar la sesión de cualquier administrador y tomar control del panel". El impacto es lo que traduce el hallazgo técnico a lenguaje de negocio.
  4. Remediación: cómo se arregla, concreto y accionable. "Forzar cambio de contraseña en el primer login y deshabilitar la cuenta por defecto", no "mejorar la seguridad".
  5. Severidad: una etiqueta acordada (Crítica / Alta / Media / Baja / Informativa) que combine impacto y facilidad de explotación, usando idealmente un marco común como CVSS para que sea comparable entre informes.
### Hallazgo PT-003 — Credenciales por defecto en el panel de administración

**Severidad:** Alta (CVSS 8.8) · **Estado:** Abierto

**Descripción:** El panel interno en `https://admin.lab.local` acepta las
credenciales de fábrica `admin/admin`, nunca cambiadas tras el despliegue.

**Evidencia (reproducible):**
1. Navegar a `https://admin.lab.local/login`
2. Introducir usuario `admin`, contraseña `admin`
3. Resultado: sesión de administrador válida (captura adjunta ev-003.png)

**Impacto:** Cualquier persona con acceso de red al panel obtiene control
total: crear usuarios, leer datos de clientes y modificar configuración.

**Remediación:** Rotar la credencial de inmediato, forzar cambio en el primer
acceso, deshabilitar la cuenta por defecto y añadir MFA al panel.

**Referencias:** OWASP A07:2021 — Identification and Authentication Failures.

Un buen informe abre con un resumen ejecutivo de una página (legible por alguien no técnico: qué se auditó, qué riesgo global hay, qué es urgente), sigue con la metodología y el alcance realmente cubierto, y luego los hallazgos ordenados por severidad. Lo urgente arriba; lo informativo, al final.

El lado defensivo: qué vería tu SIEM

Cerrar el círculo es lo que convierte un pentest en aprendizaje defensivo. Cada acción ofensiva de este documento deja rastro, y ese rastro es exactamente lo que tu monitorización debería detectar. Si haces el pentest y tu SIEM no se entera de nada, tienes un segundo hallazgo tan grave como el primero: estás ciego.

Contrasta cada fase con lo que debería saltar, y usa el resultado para afinar las reglas que alimentan el playbook de respuesta a incidentes:

  • Escaneo de Nmap: un pico de conexiones a muchos puertos desde una sola IP en poco tiempo es la firma clásica de un escaneo. Tu IDS/IPS o Falco/Wazuh deberían alertar de ello. Si el escaneo completo pasó inadvertido, tu detección de reconocimiento no funciona.
  • Fuerza bruta de credenciales: decenas de logins fallidos contra el mismo servicio deberían disparar una alerta (y una política de bloqueo). Es de lo más fácil de detectar; si no salta, revisa tu logging de autenticación.
  • Explotación con Metasploit: un exploit exitoso suele producir un proceso o una conexión saliente inesperada (la sesión de vuelta hacia el handler). Terminal shell in container o una conexión saliente a un puerto raro son justo las reglas de Falco que abren un caso en el playbook de incidentes.
  • Actividad en la app web: peticiones anómalas, parámetros manipulados y volúmenes inusuales desde Burp deberían aparecer en los logs del WAF y de la aplicación.

Este ejercicio —atacarte para comprobar que te detectas— se llama a veces purple teaming, y es la forma más honesta de validar que tu inversión en detección sirve para algo. El pentest no termina cuando encuentras el fallo; termina cuando confirmas que, la próxima vez que alguien lo intente de verdad, te vas a enterar.

Enlaces relacionados