Kerberoasted Lab
Scenario Overview
During a proactive threat hunting engagement, a hypothesis was established based on recent industry trends indicating an increase in Kerberoasting attacks against Active Directory environments.
The objective was to investigate Domain Controller logs to determine whether the CYBERCACTUS.LOCAL environment had been targeted by a Kerberoasting attack and to identify the attack chain, compromised accounts, persistence mechanisms, and post-exploitation activities performed by the attacker.
The environment provided Security Event Logs and Sysmon logs collected from the Domain Controller (DC01).
Q1 ) To mitigate Kerberoasting attacks effectively, we need to strengthen the encryption Kerberos protocol uses. What encryption type is currently in use within the network?
The investigation began by reviewing Kerberos Service Ticket requests (Event ID 4769) to identify the encryption algorithms used within the Active Directory environment. Kerberoasting attacks commonly target service tickets encrypted using weaker algorithms because the retrieved tickets can be cracked offline.
index="kerberoasted" event.code=4769
| stats count by winlog.event_data.TicketEncryptionType
The results showed that all observed service tickets were using encryption type 0x17, which corresponds to RC4-HMAC. This encryption scheme is considered weaker than modern AES-based implementations and is frequently leveraged during Kerberoasting attacks due to its susceptibility to password-cracking techniques.
So the answer is : RC4-HMAC
Q2) What is the username of the account that sequentially requested Ticket Granting Service (TGS) for two distinct application services within a short timeframe?
To identify suspicious Kerberos activity, I first searched for accounts that requested service tickets for multiple services.
index="kerberoasted" event.code=4769
| stats values(winlog.event_data.ServiceName) as Services count by winlog.event_data.TargetUserName
| where count > 1
The query returned several accounts that requested more than one service ticket, including :
janesmith@CYBERCACTUS.LOCAL
johndoe@CYBERCACTUS.LOCAL
At this stage, it was not possible to determine which account was responsible for the suspicious activity because both users appeared to have requested tickets for multiple services.
To verify which account requested tickets for two application services within a very short timeframe, I examined the timeline of TGS requests for the targeted services.
index="kerberoasted" event.code=4769
(winlog.event_data.ServiceName="SQLService" OR winlog.event_data.ServiceName="FileShareService")
| table _time winlog.event_data.TargetUserName winlog.event_data.ServiceName
| sort _time
Look for John account requested tickets for two different services within milliseconds. This behavior is highly suspicious and is commonly observed during Kerberoasting attacks, where an attacker quickly requests multiple service tickets in order to extract and crack them offline.
So the answer is : john.doe@CYBERCACTUS.LOCAL
Q3) We must delve deeper into the logs to pinpoint any compromised service accounts for a comprehensive investigation into potential successful kerberoasting attack attempts. Can you provide the account name of the compromised service account?
After identifying johndoe@CYBERCACTUS.LOCAL as the user performing suspicious Kerberoasting activity, the next step was determining whether any of the targeted service accounts had been successfully compromised.
To accomplish this, I reviewed successful logon events (Event ID 4624) that occurred after the Kerberos ticket requests. The goal was to identify which service account was subsequently used to authenticate within the environment, indicating that its credentials had likely been recovered through offline password cracking.
index="kerberoasted" AND event.code=4624 AND "@timestamp">"2023-10-16T07:37:34.000Z"
| stats count by winlog.event_data.TargetUserName
Since the account appeared in successful logon events after the Kerberoasting activity, this strongly suggests that the attacker successfully obtained its credentials and used them to authenticate within the environment.
This behavior represents the transition from Credential Access (Kerberoasting) to Valid Account Abuse, confirming that the attack was successful.
So the answer is : SQLService
Q4) To track the attacker’s entry point, we need to identify the machine initially compromised by the attacker. What is the machine’s IP address?
I correlated the TGS requests generated by the suspicious account with the source IP addresses recorded in the Kerberos logs. By grouping the requested services by source IP, it became possible to identify the host responsible for the Kerberoasting activity.
index="kerberoasted" event.code=4769
winlog.event_data.TargetUserName="johndoe@CYBERCACTUS.LOCAL"
| stats values(winlog.event_data.ServiceName) as Services by winlog.event_data.IpAddressThe results showed that all suspicious service ticket requests originated from a single IP address:
So the answer is : 10.0.0.154
Q5) To understand the attacker’s actions following the login with the compromised service account, can you specify the service name installed on the Domain Controller (DC)?
After confirming that the attacker successfully authenticated using the compromised SQLService account, the next objective was to identify the actions performed on the Domain Controller.
A common post-exploitation technique involves installing a Windows service to execute commands, maintain access, or establish persistence. To investigate this activity, I reviewed Windows Event ID 7045, which records newly installed services.
index="kerberoasted" event.code=7045
@timestamp>"2023-10-16T07:37:34.000Z"
| table _time winlog.event_data.ServiceName winlog.event_data.ImagePath
| sort _time
The search revealed the installation of suspicious services shortly after the successful compromise of the service account. i0OEDsXjWeGRAYgJ
The service executed an obfuscated PowerShell payload through cmd.exe, which strongly indicates malicious activity. The randomly generated service name is another indicator of attacker-created persistence rather than a legitimate administrative service.
So the answer is : i0OEDsXjWeGRAYgJ
Q6) To grasp the extent of the attacker’s intentions, What’s the complete registry key path where the attacker modified the value to enable Remote Desktop Protocol (RDP)?
Following the installation of the malicious service on the Domain Controller, the next step was to identify how the attacker obtained interactive access to the system.
Get ahmed alaa’s stories in your inbox
Join Medium for free to get updates from this writer.
A common post-exploitation technique involves enabling Remote Desktop Protocol (RDP) on a server to provide persistent remote access. To investigate this activity, I reviewed Sysmon Event ID 13, which records Registry Value Set operations.
index="kerberoasted" event.code=13
("Terminal Server" OR "fDenyTSConnections")
| table _time winlog.event_data.TargetObject winlog.event_data.Details
The attacker modified this value to allow incoming Remote Desktop connections, enabling direct remote access to the Domain Controller.
Why is this important?
Enabling RDP is a common attacker technique after obtaining privileged credentials because it provides a reliable interactive access method and allows the attacker to continue operating on the target system without relying on the original compromise vector.
The registry modification clearly indicates the transition from credential compromise to hands-on-keyboard access.
So the answer is : HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\fDenyTSConnections
Q7) To create a comprehensive timeline of the attack, what is the UTC timestamp of the first recorded Remote Desktop Protocol (RDP) login event?
After identifying that the attacker enabled Remote Desktop Protocol (RDP) through a registry modification, the next step was to determine when the attacker first established an interactive session on the Domain Controller.
To investigate this activity, I reviewed successful logon events (Event ID 4624) and filtered for Logon Type 10, which represents a Remote Interactive Logon performed through RDP.
index="kerberoasted" event.code=4624 winlog.event_data.LogonType=10
| table @timestamp winlog.event_data.TargetUserName winlog.event_data.IpAddress
| sort @timestampThe results revealed two successful RDP authentication events associated with the compromised SQLService account originating from the attacker’s workstation.
So the answer is : 2023–10–16 07:50
Q8) To unravel the persistence mechanism employed by the attacker, what is the name of the WMI event consumer responsible for maintaining persistence?
Attackers frequently use WMI Event Subscriptions because they provide a stealthy persistence mechanism that does not rely on common startup locations such as Run Keys, Scheduled Tasks, or Windows Services. A WMI subscription consists of three primary components:
- WMI Event Filter
- WMI Event Consumer
- WMI Filter-to-Consumer Binding
To identify the persistence mechanism, I investigated Sysmon Event ID 20, which records the creation of WMI Event Consumers.
index="kerberoasted" event.code=20
| table _time winlog.event_data.Name winlog.event_data.Destination
The results revealed a WMI Event Consumer named: Updater
Why is this suspicious?
Legitimate WMI consumers are rarely created on Domain Controllers during normal operations. Additionally, the consumer was linked to an encoded PowerShell payload, which is a common technique used by attackers to conceal malicious commands and maintain persistent access.
This behavior confirms that the attacker established a WMI-based persistence mechanism on the compromised system.
So the answer is : Updater
Q9) Which class does the WMI event subscription filter target in the WMI Event Subscription you’ve identified?
After identifying the malicious WMI Event Consumer Updater, the final step was to examine the associated WMI Event Filter to understand what condition would trigger the persistence mechanism.
A WMI Event Subscription consists of three components:
- Event Filter (Trigger)
- Event Consumer (Action)
- Filter-to-Consumer Binding
To identify the trigger condition, I reviewed Sysmon Event ID 19, which records the creation of WMI Event Filters.
index="kerberoasted" event.code=19
| table _time winlog.event_data.Name winlog.event_data.Query
This indicates that the attacker configured the persistence mechanism to watch for specific Windows Event Log entries and execute a predefined action when the condition was met.
Note: __InstanceCreationEvent defines the event subscription mechanism, while Win32_NTLogEvent is the actual WMI class being monitored. Since the question asks which class is targeted by the filter.
So the answer is Win32_NTLogEvent
Conclusion
This investigation confirmed a successful Kerberoasting attack against the CYBERCACTUS.LOCAL Active Directory environment. Through the analysis of Kerberos Service Ticket requests (Event ID 4769), suspicious ticket-granting activity was identified originating from the user account johndoe@CYBERCACTUS.LOCAL, which requested service tickets for multiple services within a very short timeframe.
Further investigation revealed that the attacker successfully compromised the SQLService account by abusing Kerberos service tickets encrypted with RC4-HMAC (0x17), a legacy encryption method commonly targeted during Kerberoasting attacks due to its susceptibility to offline password cracking. The attack originated from the workstation 10.0.0.154, which was identified as the initial compromised host within the environment.
After obtaining valid service account credentials, the attacker authenticated successfully, installed malicious services on the Domain Controller, enabled Remote Desktop Protocol (RDP) by modifying the fDenyTSConnections registry value, and established an interactive RDP session to gain direct access to the system. Persistence was later achieved through a malicious WMI Event Subscription, utilizing the Updater consumer and targeting the Win32_NTLogEvent class to execute actions when specific Windows events occurred.
Overall, the findings demonstrate a complete attack chain progressing from Credential Access (Kerberoasting) to Privilege Abuse, Persistence, and Remote Access. This incident highlights the risks associated with weak service account passwords and legacy Kerberos encryption. To mitigate similar attacks in the future, organizations should enforce strong service account passwords, migrate to AES-based Kerberos encryption, continuously monitor Event ID 4769 activity for abnormal TGS requests, and regularly hunt for unauthorized service installations, registry modifications, and WMI-based persistence mechanisms within the environment.
References
CyberDefenders — Kerberoasted Lab
https://cyberdefenders.org/blueteam-ctf-challenges/kerberoasted/
