4.1 · Reconocimiento de Active Directory

10 min de lectura · active-directory / recon / discovery / bloodhound / deteccion · ⎙ PDF

Panorama#

El reconocimiento de Active Directory (AD) no busca vulnerabilidades: busca relaciones. A diferencia de un escaneo de red clásico, que enumera puertos y versiones para encontrar un servicio explotable, el recon de un dominio reconstruye el grafo de identidad — quién es administrador de qué, quién tiene sesión iniciada dónde, qué dominio confía en qué otro — porque en AD el camino hacia el control total casi nunca es un exploit de software, sino una cadena de permisos legítimos mal configurados. Una sola cuenta de usuario sin privilegios, con la relación correcta a su favor, puede llegar a Domain Admin en un salto, sin desbordar ningún búfer ni disparar ninguna alerta de antivirus. Mapear esas relaciones es, por lo tanto, la fase que define todas las rutas posteriores: la enumeración no explota nada, pero decide qué se va a explotar.

Ese cambio de mentalidad —de “encontrar el bug” a “encontrar la arista”— es lo que hace del recon de AD una disciplina propia. El dominio se modela como un grafo dirigido donde cada nodo es un objeto (usuario, equipo, grupo, GPO, unidad organizativa) y cada arista es un permiso que puede abusarse (MemberOf, AdminTo, GenericAll, HasSession, CanRDP). Una arista peligrosa aislada es un hallazgo; el grafo entero es la historia del ataque. Este capítulo cubre las tres herramientas con las que se levanta ese grafo, la técnica de user hunting que lo convierte en una ruta hacia el administrador, y el catálogo de primitivas de abuso que el recon deja identificadas para las fases siguientes —el abuso de Kerberos de 4.2 · Kerberos, el credential dumping de 4.5 · Credential dumping y el abuso de delegación y ACLs de 4.6 y 4.7. El recon externo previo —descubrir la superficie del dominio desde Internet, antes de tener siquiera una cuenta— vive en 2.5 · Recon ofensivo.

flowchart TD
  A["Cuenta de dominio\n(sin privilegios)"] --> B["Colección del grafo"]
  B -->|"SharpHound / bloodhound-python"| C["BloodHound\n(Neo4j)"]
  B -->|"Get-Net* / Get-Domain*"| D["PowerView\n(potente, ruidoso)"]
  B -->|"Get-AD* (API firmadas)"| E["AD Module\n(sigiloso)"]
  C --> F["Análisis del grafo:\naristas a Tier Zero"]
  D --> F
  E --> F
  F --> G["User hunting:\ndónde tiene sesión un DA"]
  F --> H["Catálogo de aristas abusables"]
  H -->|"SPN + RC4"| I["Kerberoasting (ver 4.2)"]
  H -->|"GetChanges + GetChangesAll"| J["DCSync (ver 4.5)"]
  H -->|"GenericAll / WriteDacl"| K["Abuso de ACL (ver 4.7)"]
  H -->|"Constrained / RBCD"| L["Delegación (ver 4.6)"]
  G --> M["Robo de token → DA"]

El grafo: BloodHound y sus colectores#

BloodHound es la herramienta que materializó el modelo de grafo y redefinió el recon de AD. Ingiere los datos crudos del dominio en una base Neo4j y los presenta como un grafo navegable donde la consulta central —"¿cuál es el camino más corto desde esta cuenta que controlo hasta Domain Admins?"— se resuelve con un clic. El grafo se alimenta de un colector que barre el directorio; cuál se use depende del entorno: SharpHound para AD local (el caso clásico), AzureHound para Entra ID (el antiguo Azure AD), y RustHound como alternativa a SharpHound, más rápida y a veces menos detectable. Desde Linux, sin tocar una máquina Windows, bloodhound-python cumple el mismo rol contra el controlador de dominio por LDAP.

# Recolección remota desde Linux (bloodhound-python)
bloodhound-python -u usuario -p 'contraseña' -d corp.local -dc dc1.corp.local -c All -ns <IP-DC>
# BloodHound Community Edition — levantar el grafo (Docker)
docker run -p7474:7474 -p7687:7687 -e NEO4J_AUTH=neo4j/bloodhound neo4j

El colector produce un conjunto de archivos JSON (comprimidos en un .zip) que se importan al grafo. El valor del recon no está en la recolección en sí, sino en las consultas que se corren sobre el resultado: además de las incluidas, la comunidad mantiene colecciones de custom queries (de @hausec, CompassSecurity, Exegol, Certipy) que se cargan reemplazando customqueries.json en ~/.config/bloodhound/ (Linux) o %AppData%\Roaming\BloodHound\ (Windows). Esas consultas encapsulan patrones de abuso conocidos —“cuentas kerberoastables con ruta a Tier Zero”, “equipos con delegación sin restringir”— y convierten el grafo en un catálogo priorizado de rutas de ataque.

La gravedad de un hallazgo se mide en saltos hasta Tier Zero: cuántas aristas hay que recorrer desde la cuenta controlada hasta un objeto que controla la identidad del dominio. Una arista GenericAll directa sobre el grupo Domain Admins es un salto; una ruta que pasa por una GPO mal permisada puede ser cuatro o cinco. La priorización del ataque es, punto por punto, la priorización de la remediación: mismas aristas críticas.

Enumeración manual: PowerView y el AD Module#

BloodHound da el panorama; la enumeración manual da el detalle y el control fino. PowerView es el catálogo de cmdlets de PowerShell (Get-Net*, Get-Domain*) que enumera cada clase de objeto del dominio sin depender del módulo oficial de Microsoft. Un barrido típico recorre, en orden de generalidad decreciente, el dominio y su política, los controladores, los usuarios, los equipos, los grupos, los shares, las GPO, las OU, las ACL y los trusts — sin explotar nada, pero definiendo toda la superficie posterior.

# Dominio, SID y política Kerberos
Get-NetDomain ; Get-DomainSID
(Get-DomainPolicy)."kerberos policy"
# Secretos en descripciones (un clásico: contraseñas en el campo Description)
Find-UserField -SearchField Description -SearchTerm "pass"
# Sesiones activas y shares accesibles con la cuenta actual
Get-NetSession -ComputerName <equipo>
Find-DomainShare -CheckShareAccess
# ACE interesantes y trusts
Invoke-ACLScanner -ResolveGUIDs
Get-NetDomainTrust ; Get-NetForestTrust

El AD Module oficial de Microsoft (Get-AD*) cubre buena parte del mismo terreno, pero con una diferencia que es táctica antes que funcional: usa API firmadas por Microsoft y se camufla mejor con la actividad administrativa legítima, mientras que PowerView a veces dispara consultas LDAP con una firma más reconocible. La elección de herramienta es también una decisión de evasión: cuando el sigilo importa más que la exhaustividad, Get-ADUser -Filter * -Properties *, Get-ADComputer, Get-ADTrust y sus pares son la opción preferible. Para ubicar los controladores de dominio sin depender de ninguna de las dos, bastan utilidades nativas: nltest /dclist:<dominio>, nslookup -type=srv _ldap._tcp.dc._msdcs.<dominio> o la variable de entorno $Env:LOGONSERVER.

User hunting: del grafo a la ruta hacia Domain Admin#

El recon culmina en una pregunta operativa concreta: ¿en qué máquina hay un Domain Admin con sesión iniciada y, a la vez, tengo yo derechos de administrador local? Esa intersección es el user hunting, y es la ruta canónica desde una cuenta común hasta el control del dominio. Si en una máquina donde soy administrador local un DA tiene una sesión activa, su token de acceso reside en memoria y puede robarse e impersonarse — sin craquear ninguna contraseña. PowerView resuelve las dos mitades de la pregunta: primero las máquinas donde tengo acceso, después dónde está el objetivo.

# Máquinas donde la cuenta actual es admin local
Find-LocalAdminAccess -Verbose
# Máquinas donde un usuario objetivo (p. ej. un DA) tiene sesión
Invoke-UserHunter -CheckAccess # marca dónde además tengo acceso
Invoke-UserHunter -Stealth # menos consultas, menos ruido

El robo del token y la impersonación posterior son ya movimiento lateral, y se detallan en 4.8 · Movimiento lateral. Lo que importa aquí es que el user hunting transforma el grafo estático en una ruta accionable: no “quién es admin de qué” en abstracto, sino “en esta máquina concreta, ahora mismo, hay un token de DA esperando”.

El catálogo de aristas: qué deja identificado el recon#

La mayoría de las rutas a Domain Admin no son exploits sino misconfiguraciones de ACL — pequeños permisos excesivos que se encadenan. Por eso el grafo importa más que cualquier CVE. El recon deja identificadas las aristas abusables, cada una de las cuales es el punto de entrada a una técnica desarrollada en otro capítulo. El catálogo de primitivas que BloodHound resalta sobre un dominio real se agrupa en cuatro familias:

Primitivas de Kerberos. Cuentas con un SPN registrado son kerberoastables (se les puede pedir un Service Ticket y craquearlo offline); cuentas con la pre-autenticación deshabilitada son vulnerables a AS-REP Roasting. El grafo las marca directamente; su abuso está en 4.2 · Kerberos.
Derechos de replicación. Una cuenta común que posea a la vez GetChanges y GetChangesAll sobre el objeto de dominio puede ejecutar un DCSync y volcar todos los hashes del directorio, incluido el de krbtgt, sin ser controlador de dominio. La combinación exacta de esos dos derechos es la firma del hallazgo; la técnica está en 4.5 · Credential dumping.
Abuso de ACL. GenericAll, WriteDacl, WriteOwner, AddSelf y ForceChangePassword son rutas distintas hacia el mismo fin —el control del objeto— y por eso son intercambiables: sobre un grupo, cualquiera de ellas habilita agregarse (AddMember); sobre un equipo, AllExtendedRights incluye leer su contraseña LAPS de administrador local. Casos límite: escribir en msDS-KeyCredentialLink de un objetivo son Shadow Credentials (autenticación por PKINIT y extracción del hash), y GenericAll sobre AdminSDHolder es un backdoor auto-reparable, porque el proceso SDProp propaga su DACL a todas las cuentas protegidas cada 60 minutos. Todo esto se abusa en 4.7 · ACLs y persistencia.
Delegación. Los tres tipos —constrained (impersonar a un servicio si el principal es craqueable), unconstrained (un host no-DC que cachea el TGT de todo el que se autentica es un objetivo de primer orden) y RBCD (el objetivo guarda quién puede delegar en msDS-AllowedToActOnBehalfOfOtherIdentity, de modo que una entrada pre-sembrada ahí es un backdoor listo)— convierten un compromiso lateral en impersonación del administrador. Se desarrollan en 4.6 · Delegación y trusts.

El objetivo final del análisis del grafo es caracterizar el Tier Zero: el conjunto de objetos que controlan la identidad del dominio (los Domain Admins, los controladores de dominio, krbtgt, AdminSDHolder). Todo lo demás es un medio para alcanzarlo; comprometer cualquier objeto de Tier Zero es comprometer el dominio entero.

Defensa y detección#

El recon de AD es, de todo el ciclo de ataque, una de las fases más difíciles de detectar en tiempo real, porque en su mayor parte consiste en consultas LDAP legítimas que cualquier cuenta autenticada tiene derecho a hacer. La defensa combina, por eso, dos planos: la detección de la anomalía en runtime y —más determinante— la corrección de postura del grafo.

Volumen de consultas LDAP por cuenta. La firma de SharpHound o de un barrido de PowerView es un único principal que consulta masivamente usuarios, grupos, ACL y trusts en poco tiempo. Un usuario común no enumera todo el directorio; monitorear el volumen de consultas LDAP por cuenta y, en particular, las lecturas en bloque del atributo servicePrincipalName (el precursor del Kerberoasting) es la base de la detección.
Auditoría de acceso a objetos del directorio (Event ID 4662). Con la auditoría fina activada, las lecturas de derechos de replicación y el acceso a objetos sensibles quedan registrados; un 4662 sobre el objeto de dominio desde una cuenta que no es un DC es especialmente sospechoso (precede al DCSync).
Honey objects. Sembrar una cuenta señuelo con un SPN atractivo y sin uso legítimo, y alertar sobre cualquier Service Ticket pedido para ella (Event ID 4769 hacia ese SPN), convierte el Kerberoasting en una alarma de alta fidelidad: nadie legítimo pide nunca ese ticket.
Defensa de postura: correr BloodHound uno mismo. Como casi todas las primitivas del catálogo son abusos de permisos legítimos que dejan poca o ninguna telemetría en el momento del abuso, la defensa más eficaz es preventiva: ejecutar BloodHound desde el lado defensor, identificar las aristas críticas a Tier Zero y eliminarlas — quitar GetChanges/GetChangesAll de toda cuenta que no sea DC, revocar GenericAll sobre AdminSDHolder y sobre Domain Admins, corregir los permisos sobre GPO enlazadas al dominio. La misma arista que rankea el ataque rankea la remediación.

El endurecimiento estructural completa la postura: aplicar el principio de mínimo privilegio sobre las ACL, fijar MachineAccountQuota = 0 para que un usuario común no pueda crear cuentas de máquina, y tratar todo controlador de dominio como Tier 0. El mapeo defensivo consolidado de toda la superficie de Active Directory, con las reglas SIEM y los playbooks de respuesta, se desarrolla en 4.9 · Defensa de AD.

Referencias#

red-infra/ad-attacks/cap-01 — Recon de Active Directory: BloodHound, PowerView, el AD Module y user hunting.
red-infra/ad-cluster/cap-06 — BloodHound: catálogo de primitivas de ataque (edges, ACL, delegación, Tier Zero).
MITRE ATT&CK — T1087 Account Discovery, T1069 Permission Groups Discovery y T1482 Domain Trust Discovery.
BloodHound Community Edition — documentación oficial.

Mencionado en

0.1 · Principios: los invariantes que todo presuponeEl capítulo que abre la Parte 0 y, con ella, cierra el manual. La Parte 0 se lee primera —es el cimiento— pero se escribió última, y por eso puede hacer algo que ninguna otra puede: nombrar los invariantes que las otras nueve Partes dieron por supuestos sin enunciarlos. Este capítulo los reúne. Empieza por el objetivo que toda la disciplina persigue —la tríada CIA de confidencialidad, integridad y disponibilidad, y su extensión Parkeriana— y sigue con los ocho principios de diseño de Saltzer y Schroeder, el conjunto de axiomas de ingeniería que en cincuenta años no envejeció: economía de mecanismo, valores por defecto seguros, mediación completa, diseño abierto, separación de privilegio, mínimo privilegio, mecanismo común mínimo y aceptabilidad psicológica. Sobre esa base recoge los hilos conductores que el manual tejió Parte a Parte —separar los datos del código, la defensa en profundidad, la frontera de confianza, no confiar en la entrada, verificar la procedencia, dejar al humano la decisión irreversible— y muestra que cada uno es la aplicación de esos axiomas a una capa concreta. La tesis que ancla la Parte y el libro entero: la seguridad no es un producto que se compra ni una suma de herramientas, sino una propiedad que emerge de aplicar con disciplina un puñado de principios a cada capa del sistema.
0.5 · Arquitectura de seguridad: modelar la amenaza y confiar con criterioEl capítulo que compone los tres sustratos anteriores —la red, el sistema operativo y la criptografía— en un sistema que se puede defender. La seguridad no se agrega al final como una capa de pintura: se diseña, y diseñarla empieza por una pregunta que casi nadie hace a tiempo, ¿contra qué, exactamente, estamos defendiéndonos? El modelado de amenazas (con STRIDE como marco de referencia) es la disciplina de hacerse esa pregunta de forma estructurada, sobre un dibujo del sistema, antes de que el atacante la haga por uno. De ahí salen los dos conceptos que organizan todo el capítulo: la superficie de ataque, que hay que ver para poder reducir, y la frontera de confianza, que deja de ser un accidente para convertirse en un artefacto de diseño explícito —la línea, dibujada a propósito, donde algo confiable recibe algo que no lo es y por lo tanto hay que validar—. El capítulo muestra cómo el modelo de perímetro tradicional —duro por fuera, blando por dentro— fracasó, y cómo el zero trust lo reemplaza aplicando a toda la red el principio de mediación completa: nunca confiar por ubicación, verificar en cada acceso, con la identidad convertida en el nuevo perímetro. Cierra con el diseño seguro por defecto como la forma de no repetir el error. No rehace la gobernanza de la Parte 7 ni el detalle operativo del zero trust: da el marco de diseño que la gobernanza dirige.
0.6 · Síntesis: el manual en una ideaEl capítulo que cierra la Parte 0 y, con ella, el manual entero. Después de recorrer diez Partes —la explotación, el Active Directory, el reconocimiento, la defensa azul, la inteligencia de amenazas, la validación púrpura, la gobernanza, el factor humano, la inteligencia artificial y estos fundamentos— la pregunta que queda es la más difícil y la más importante: ¿cuál es el hilo único que atraviesa todo? Este capítulo lo responde destilando las diez Partes en una sola idea. Muestra que las técnicas cambian —cambia el intérprete que se inyecta, cambia el protocolo que se abusa, cambia la superficie que aparece con cada tecnología nueva— pero los principios no: separar los datos del código, otorgar el mínimo privilegio, apilar la defensa en profundidad, reconocer que el humano es una superficie y que la máquina cambia la escala pero no los fundamentos, todo bajo una gobernanza que lo ejerce y una inteligencia que lo orienta. Recapitula la travesía como un solo movimiento y llega a la tesis que corona el libro: la seguridad no es un producto que se compra ni una técnica que se domina, sino una propiedad que se cultiva —un puñado de invariantes aplicados con disciplina a cada capa, sostenidos en el tiempo—. Y cierra volviendo al principio: esta Parte se lee primera porque es el cimiento, pero se escribió última porque solo desde el edificio terminado se ve sobre qué se paró cada piso.
2.1 · Metodología OSINT y OPSEC del investigadorEl capítulo-marco que abre P2: OSINT es una disciplina antes que un conjunto de herramientas. Dos pilares convierten el dato público en inteligencia defendible —el método (el ciclo intake→triage→colección→reporte, donde «la información no es inteligencia hasta que tiene contexto» y cada dato sirve para saltar al siguiente identificador) y el OPSEC (la máquina limpia por caso, la identidad no atribuible, la cadena de custodia)—, y sobre ambos la ética que gobierna cuándo y cómo aplicarlos (proporcionalidad, intención, decepción articulable). Encuadre dual-use: el mismo tradecraft alimenta el recon ofensivo, la investigación blue/CTI y la reducción de la huella propia.
2.5 · Recon ofensivo: superficie de ataque, subdominios y monitoreo continuoEl capítulo bisagra de P2: reorienta todo el mapa OSINT hacia el ataque. Las ramas anteriores coleccionaban inteligencia sobre personas, contenido e infraestructura; aquí el mismo instrumental se dirige a la superficie de ataque de una organización, y dos ejes lo ordenan —pasivo frente a activo (el reconocimiento que el objetivo nunca percibe frente al que deja huella) y puntual frente a continuo (la ventaja real del atacante es el tiempo: vigilar la superficie y capturar la ventana en que algo se expone)—. La nube rompió el escaneo por rango y los certificados SSL lo resolvieron; GitHub filtra los secretos «borrados»; un bucket mal permisado escala de lectura a ejecución. El resultado es la lista de objetivos que alimenta la explotación (3.1) y el recon interno de Active Directory (4.1).
3.1 · Metodología de pentest: del scoping al reporteEl capítulo que abre la Parte 3 y enmarca todo lo que sigue: qué distingue un pentest de un red team (y qué es un assumed breach), las fases del engagement como ciclo de vida, el mindset de enumeración exhaustiva y cíclica, cómo las credenciales encadenan el ataque, y por qué la metodología del atacante es también el mapa del defensor.
3.4 · Web III — Autenticación, sesión, acceso y lógicaLa cadena de identidad de una aplicación web bajo una sola tesis: en cada request la app responde tres preguntas encadenadas —¿quién es? (autenticación), ¿sigue siendo el mismo? (gestión de sesión), ¿puede hacer esto? (control de acceso)— y romper el eslabón más débil colapsa el resto. Sobre esos tres, la lógica de negocio es el tejido conectivo que falla cuando el desarrollador asume algo que el usuario controla. Recorre el brute-force y la enumeración de usuarios, los tokens con significado/predecibles/cifrados y su secuestro, el IDOR y el bypass por método HTTP, y los logic flaws sin firma, cada uno con la defensa que lo niega: respuestas genéricas, tokens sin significado desde un CSPRNG, un componente central default-deny, y decidir toda identidad desde la sesión.
3.19 · Cloud red team: identidad, IAM y la nube como perímetroEl red team en la nube, donde el modelo mental del atacante cambia de raíz. En un centro de datos clásico el objetivo es una máquina en una red; en la nube no hay una 'adentro' de red que conquistar, hay un plano de control gobernado por identidades y políticas, y el atacante no explota memoria ni servicios sino que abusa de permisos mal puestos. El capítulo desarrolla la tesis que lo ordena —en la nube la identidad es el perímetro— y la recorre en los dos grandes proveedores de identidad y cómputo. En el plano de la identidad corporativa (Entra ID, el antiguo Azure AD) trata el phishing de código de dispositivo, el consentimiento ilícito de aplicaciones, el robo de tokens de sesión y los principales de servicio como persistencia. En el plano de la infraestructura (AWS) trata la enumeración de IAM, la escalada por políticas mal configuradas, el abuso del servicio de metadatos de instancia como puente desde una vulnerabilidad web, y las cadenas de asunción de roles. Cubre la persistencia propia de la nube y los puentes entre el dominio local y la nube en entornos híbridos. Y cierra, como siempre, con el mapeo púrpura: la telemetría de la nube (los registros de actividad de la API), la gestión de identidades y los controles de acceso condicional son donde el defensor recupera la ventaja. Es material de dominio actual, sin base destilada, y el complemento cloud del Active Directory de la Parte 4.
4.2 · Kerberos: Kerberoasting, AS-REP y tickets forjadosCómo se abusa de Kerberos en Active Directory: Kerberoasting, AS-REP Roasting, Pass-the-Ticket/Hash y la familia de tickets forjados Golden/Silver/Diamond/Sapphire, con su detección. Incluye los internals del protocolo —la clave RC4 como NT hash, la estructura del PAC y sus firmas, y la validación del PAC que faltaba— que explican por qué la familia entera funciona y que anclan la mitigación estructural (PAC signature enforcement, noPac).
4.3 · NTLM: captura, relay y coerciónLa debilidad estructural de NTLM en la red: captura de Net-NTLMv1/v2, relay a LDAP/SMB sin craquear nada, coerción con PetitPotam/SpoolSample y las variantes que sortean el signing (Drop the MIC, mitm6), con su detección. Incluye los internals de SSPI —el intercambio de tres tokens, la disociación entre la capa lógica y la de red como causa raíz del relay, el MIC que protege integridad pero no dirección, el double-hop problem y el channel binding/target name opt-in— que explican por qué el relay es estructural y no un bug parcheable.
4.4 · AD CS: escalada por certificados (ESC1–ESC11)La PKI del dominio como ruta limpia a Domain Admin: la familia ESC1–ESC11, el SAN arbitrario como falla central, la ruta sin credenciales por coerción y relay (ESC8/ESC11), Certifried, y las técnicas PKINIT transversales —Pass-the-Certificate, UnPAC-the-Hash y Shadow Credentials— con su detección.
4.5 · Credential dumping: LSASS, NTDS.dit y DCSyncLa extracción de credenciales tras el compromiso: el volcado de LSASS en memoria (remoto y local, con su evasión), el saqueo de la base entera del dominio por DCSync o copia de NTDS.dit, el regalo de la reversible encryption y el crackeo offline — con la detección que cada vía delata.
4.6 · Delegación y trusts: cruzar los límites del bosqueLas dos maneras de cruzar un límite de seguridad en Active Directory: las relaciones de confianza entre dominios y bosques (SID History, Trust Ticket, PAM trust) y la delegación Kerberos (unconstrained, constrained/S4U, RBCD y el Bronze Bit) — el terreno donde el compromiso de un host se vuelve compromiso del bosque, con la detección de cada vía.
4.7 · ACLs, grupos privilegiados y persistencia en ADEl modelo de permisos de Active Directory como superficie de escalada: el catálogo de aristas de ACE (GenericAll, WriteDACL, ForceChangePassword…) que convierten un control parcial en dominio, los grupos built-in que dan SYSTEM sin ser administradores, y la persistencia que se repara sola — AdminSDHolder/SDProp y el SSP malicioso — con su detección. Incluye los internals del SRM —la estructura del descriptor de seguridad, el WriteDac inalienable del dueño, el algoritmo de access-check en tres fases (mandatory/token/discrecional), el orden canónico y la brecha entre permisos declarados y acceso efectivo— que explican por qué el abuso de ACE funciona y qué auditar más allá de la membresía.
4.9 · Defensa de Active Directory: detección, hardening y respuestaEl capítulo azul que cierra la Parte 4: consolida en un sistema coherente el mapeo defensivo que 4.1–4.8 vinieron enlazando. La telemetría que hay que tener antes de que sirva, el diccionario de Event IDs de AD por fase, la correlación que convierte alertas sueltas en una historia de ataque, el hardening que quita cada técnica de raíz y el playbook de respuesta —incluido el doble reset de krbtgt—.
6.5 · Gestión de exposición: de la vulnerabilidad al camino de ataqueEl capítulo que cierra la Parte 6. Sostiene una tesis doble: un escáner sin ciclo de remediación no produce seguridad sino ruido con apariencia de diligencia, y el salto de madurez no es escanear mejor sino dejar de puntuar hallazgos aislados para empezar a evaluar caminos de ataque —una vulnerabilidad media en un host que da acceso a las credenciales de dominio importa más que una crítica en un equipo aislado, y el CVSS no lo puede ver porque no conoce la topología—. Recorre el ciclo de gestión de vulnerabilidades, la velocidad como variable dominante, la priorización por explotación activa frente al CVSS estático, y la gestión de caminos de ataque como generalización de lo que BloodHound hizo para Active Directory. Cierra la Parte devolviendo el foco a la validación: el parche que se cree aplicado también es un supuesto.