Panorama#

La Parte 3 recorre la explotación en detalle —web, exploit-dev binario, C2, evasión, escalada—, pero ninguna de esas técnicas rinde sin un método que las encadene. Este capítulo inaugural aporta ese método: no una técnica más, sino el marco que ordena a todas las demás. Un intrusión real casi nunca se gana con un solo exploit espectacular; se gana enlazando hallazgos modestos —un fichero legible, una credencial reutilizada, un servicio mal configurado— en una cadena que va del perímetro al objetivo. La metodología es la disciplina de construir esa cadena de forma sistemática y repetible, no por golpes de suerte.

Dos textos cimentan el capítulo desde ángulos complementarios. Uno es la mentalidad del examen práctico: la regla de que no se puede atacar lo que se pasó por alto, la naturaleza cíclica de la enumeración, y la observación de que cada credencial es la llave de la cerradura siguiente. El otro es el encuadre profesional del red team: la distinción entre buscar vulnerabilidades y medir la capacidad de detección del cliente, el concepto de assumed breach, y la idea —contraintuitiva para quien viene del pentest clásico— de que ser descubierto es parte de la evaluación. Entre ambos definen qué es hacer esto bien.

El capítulo avanza así: primero, qué separa un pentest de un red team, porque el objetivo cambia todo lo demás. Después, las fases del engagement como un ciclo de vida, mapeadas a los marcos estándar. Luego, los dos principios operativos que sostienen la ejecución —enumeración exhaustiva y cíclica, y el encadenamiento de credenciales—, ilustrados con una cadena completa del perímetro a Domain Admin. A continuación, el andamiaje que hace profesional al trabajo: scoping, reglas de enganche, infraestructura y el reporte como entregable. Y al cierre, la vuelta púrpura: por qué esta misma metodología es el mapa que el defensor usa para saber dónde instrumentar.

Pentest y red team: dos objetivos, dos métodos#

La distinción no es de herramientas sino de pregunta. Un pentest responde: «¿qué vulnerabilidades tiene este sistema y hasta dónde se puede llegar explotándolas?». Optimiza por cobertura: mapear la superficie de ataque completa, encontrar y demostrar el mayor número de fallos accionables dentro del alcance. Un red team responde una pregunta distinta: «¿detecta y contiene esta organización a un adversario real que ya está dentro?». Optimiza por sigilo y realismo: emula a un actor concreto, y su métrica de éxito no es cuántas vulnerabilidades encontró, sino qué pasos del ataque pasaron inadvertidos para el equipo defensivo.

De esa diferencia de objetivo nace el assumed breach exercise. El red team moderno parte de un supuesto incómodo pero honesto: siempre habrá un 0-day, y por tanto la prevención perfecta del acceso inicial es una meta inalcanzable. En vez de gastar la evaluación intentando cruzar el perímetro, el ejercicio asume que el adversario ya entró —se le entrega al equipo un punto de apoyo o un payload custom a ejecutar— y mide lo que importa de verdad: si el cliente detecta y mitiga los pasos secundarios y terciarios (el reconocimiento interno, la escalada, el movimiento lateral, la exfiltración). Bajo este encuadre, que una defensa queme la infraestructura del atacante al descubrirlo no es un fracaso del ejercicio: es exactamente el resultado que demuestra que las defensas funcionan.

Esta filosofía —asumir la brecha y medir la respuesta— es el puente conceptual entre la ofensiva y la defensa que recorre todo este manual. Es la misma tesis que ordena 4.9 · Defensa de AD: un ataque no es un evento aislado sino una historia que se detecta por correlación. El red team construye esa historia; el blue team la lee. Por eso un capítulo de metodología ofensiva es, leído al revés, un capítulo de estrategia defensiva.

Las fases del engagement como ciclo de vida#

Todo compromiso, sea pentest o red team, recorre una secuencia de fases que los marcos de la industria —el Cyber Kill Chain de Lockheed Martin, el PTES (Penetration Testing Execution Standard), las tácticas de MITRE ATT&CK— formalizan con nombres distintos pero estructura equivalente. Reducida a su esqueleto operativo:

flowchart TD
  PRE["Pre-engagement\nscoping · reglas de enganche · autorización"] --> RECON["Reconocimiento\n(externo → P2 OSINT)"]
  RECON --> FOOT["Acceso inicial\n(foothold: web/phishing/servicio)"]
  FOOT --> ENUM["Enumeración local\n(el ciclo — se reinicia con cada acceso)"]
  ENUM --> PRIV["Escalada de privilegios\n(→ 3.9)"]
  PRIV --> CRED["Acceso a credenciales\n(cada secreto es una llave)"]
  CRED --> LAT["Movimiento lateral\n(→ 4.8 / P4)"]
  LAT --> ENUM
  LAT --> IMPACT["Objetivo / impacto\n(exfiltración · DA · datos)"]
  IMPACT --> REP["Reporte\n(el entregable real)"]
  REP -.->|"lecciones aprendidas\nrealimentan la postura"| PRE

El rasgo esencial del diagrama es el lazo de retorno de movimiento lateral hacia enumeración: las fases no son una escalera lineal que se sube una vez, sino un ciclo que se reinicia con cada nuevo acceso. Cada máquina comprometida es un punto de observación nuevo desde el que enumerar la red otra vez, y ese bucle —no un exploit lineal— es lo que lleva del perímetro al dominio. El reconocimiento externo que abre el ciclo pertenece a su propia disciplina y se desarrolla en la Parte 2 (OSINT y recon, 2.1 · Metodología OSINT); la escalada local en 3.9 · Escalada de privilegios; el movimiento lateral, ya en el dominio, en 4.8 · Movimiento lateral.

Principio operativo I: enumeración exhaustiva y cíclica#

Si hay una sola regla que la metodología no permite saltar, es la enumeración completa. La formulación canónica es tajante: no se puede atacar lo que se pasó por alto, y por tanto hay que mapear la superficie de ataque entera de cada máquina y servicio accesible dentro del alcance antes de sacar conclusiones. La consecuencia práctica choca con el instinto: encontrar un vector accionable no interrumpe la enumeración. Se recolecta toda la información, se la prioriza, y recién entonces se atacan los vectores en orden de rentabilidad. El quick win que detiene el barrido es una trampa: la máquina sin vector directo puede ser, más adelante, el pivote dual-homed que conecta dos redes o la fuente de las credenciales cacheadas que abren el dominio.

El segundo filo del mismo principio es su naturaleza cíclica. Obtener privilegios administrativos en un sistema no es la señal para saltar de inmediato al siguiente objetivo, sino para volver a empezar la enumeración: con privilegios elevados se pueden examinar áreas antes inaccesibles —memoria de procesos, ficheros de configuración protegidos, historiales, sesiones de otros usuarios— que suelen contener el material del salto siguiente. La enumeración local, con herramientas de reconocimiento automatizado como linpeas/winPEAS, no es un paso único sino el estado por defecto entre cada acción.

La automatización de la enumeración (linpeas, winPEAS, BloodHound) acelera pero no exime de leer la salida. La disciplina es verificar cada hallazgo del tool, no confiar ciegamente: el falso negativo de un script —un permiso que no marcó, un fichero que no listó— es exactamente el vector que el operador cuidadoso encuentra a mano y el descuidado pierde.

Principio operativo II: las credenciales encadenan el ataque#

El segundo principio es que un compromiso completo rara vez es un exploit, sino una composición de secretos: cada credencial obtenida es la llave de la cerradura siguiente, y el reuso de contraseñas entre cuentas y máquinas es lo que hace posible el encadenado. Gestionar ese material de forma estructurada —un registro de credenciales como parte de la infraestructura del engagement, no como trámite— es lo que permite ver la ruta cuando aparece.

La cadena documentada contra un objetivo corporativo típico ilustra el principio de punta a punta. Cada eslabón es una técnica que vive en su propio capítulo; lo que la metodología aporta es el encadenado:

  1. Recon del perímetro revela un WordPress con un plugin vulnerable (un LFI no autenticado, familia de 3.2 · Inyección web).
  2. El LFI lee una clave SSH privada; su passphrase se crackea offline y da acceso al host.
  3. Sobre el host, la enumeración encuentra un sudo NOPASSWD sobre git —una escalada por GTFOBins (3.9 · Escalada de privilegios)— que da root; y el historial de git (git log / git show) recupera un script borrado con las credenciales de otra cuenta.
  4. Esa cuenta resulta válida en el dominio: un usuario sin privilegios en ningún host, pero credencial de dominio al fin, que habilita el reconocimiento de AD con BloodHound.
  5. BloodHound revela tres hechos que definen el resto: una cuenta kerberoastable (4.2 · Kerberos), un administrador de dominio con sesión activa en un servidor concreto (dónde cosechar), y un administrador local con la contraseña reutilizada entre dos hosts (la base de un relay).
  6. El Kerberoasting entrega la contraseña de la cuenta de servicio; el relay NTLM —posible por SMB signing desactivado y la contraseña de admin local reutilizada— salta de «cero privilegios» a SYSTEM en el host donde la sesión del Domain Admin está cacheada (4.3 · NTLM).
  7. El volcado de credenciales de esa sesión (4.5 · Credential dumping) entrega el hash del Domain Admin, y un Pass-the-Hash al controlador de dominio cierra el objetivo.

Ningún eslabón es letal por sí solo. El LFI sin la clave SSH no lleva a ningún lado; la cuenta de dominio sin BloodHound es ruido; el relay sin los tres hallazgos previos (signing off, reuso de contraseña, coerción de auth) no es posible. La metodología es, precisamente, el arte de reconocer que esos hallazgos independientes componen una ruta —y el git history como almacén de secretos borrados es un recordatorio de que el material del siguiente salto muchas veces ya está a la vista, en un lugar que nadie limpió.

El andamiaje profesional: scoping, reglas de enganche e infraestructura#

Lo que separa un engagement profesional de una intrusión es el marco que lo rodea. Antes de tocar un solo sistema, el scoping define qué está dentro y fuera del alcance, y las reglas de enganche (rules of engagement) fijan qué técnicas se permiten, en qué ventana horaria, con qué límites de impacto y a quién notificar ante un hallazgo crítico. La autorización por escrito no es burocracia: es la línea que distingue el trabajo autorizado de un delito, y su ausencia invalida todo lo demás.

Del lado técnico, el red team monta una infraestructura desechable y resiliente por diseño. La filosofía —VPS baratos y reemplazables, provisionados de forma repetible y endurecidos, con redirectores que desacoplan el dominio de mando del servidor real— existe para sobrevivir al descubrimiento: si toda la campaña depende de uno o dos puntos de contacto, el equipo defensivo la desmonta de un golpe al quemar el primero. El detalle de esa infraestructura —los frameworks de command and control, los perfiles que imitan tráfico legítimo, la comunicación entre agentes por canales laterales— es materia propia de 3.10 · C2 e infraestructura ofensiva, donde la OPSEC se trata a fondo; aquí basta con fijar el principio: la infraestructura es parte de la metodología, no un accesorio, porque su diseño determina si la operación sobrevive al primer contacto con la defensa.

El reporte es el entregable real del trabajo —no el shell en el controlador de dominio—. Un compromiso sin un informe que reconstruya la cadena, priorice los hallazgos por riesgo y proponga remediaciones concretas no tiene valor para el cliente. Y su última sección, las lecciones aprendidas, cierra el ciclo del diagrama: alimenta directamente la mejora de la postura defensiva, que es, en un red team, el propósito entero del ejercicio.

La metodología como mapa del defensor#

Un capítulo de metodología ofensiva es, invertido, la hoja de ruta del defensor —y esa es la lectura púrpura que lo cierra—. Cada fase del ciclo de vida deja telemetría, y el equipo azul que conoce la secuencia del atacante sabe dónde instrumentar y qué correlacionar. La cadena del ejemplo se ilumina entera desde el otro lado: el LFI deja peticiones con traversal en los logs de acceso web; el acceso a credenciales por Kerberoasting deja el Event ID 4769 con cifrado RC4; el relay NTLM deja un logon de red con NTLM donde se esperaba Kerberos; el Pass-the-Hash al controlador deja el acceso a los recursos administrativos y a LSASS. El detalle de esas firmas y su correlación vive en 4.9 · Defensa de AD y, a escala de SIEM, en la Parte 5.

La consecuencia estratégica es la del assumed breach: como ningún eslabón es letal por sí solo y la prevención perfecta del acceso inicial es ilusoria, la defensa eficaz no apuesta todo al perímetro, sino que instrumenta cada fase interna del ciclo para que la cadena se rompa en algún punto. El atacante necesita que todos los eslabones funcionen; el defensor, que falle uno. Conocer la metodología ofensiva es lo que le dice al defensor cuáles son esos eslabones y en qué orden esperarlos.

Referencias#

  • red-infra/pen200/cap-07 — «Assembling the Pieces»: la cadena OSCP completa (LFI → SSH → sudo git → validación en dominio → Kerberoasting → relay NTLM → DCSync) como ilustración integrada de la metodología; el mindset de enumeración exhaustiva y cíclica y el encadenamiento de credenciales.
  • red-infra/hacker-playbook3/cap-01 — «Pregame»: la distinción pentest vs red team, el assumed breach exercise («ser descubierto es parte de la evaluación»), y la filosofía de infraestructura desechable/resiliente (el detalle de C2 se desarrolla en 3.10).
  • MITRE ATT&CK — el catálogo de tácticas como formalización de las fases del ciclo de vida (acceso inicial, ejecución, escalada, acceso a credenciales, movimiento lateral, exfiltración, impacto).
  • Cyber Kill Chain (Lockheed Martin) y PTES (Penetration Testing Execution Standard) — los dos marcos clásicos de fases de un engagement, complementarios a ATT&CK.