Kerberoasting
Level: Hard
Challenge: Kerberoasting
Hello, I’m excited to be back with a new LetsDefend challenge. I found it engaging and decided to write a writeup to share my experience. This challenge involves Kerberos, which is the default authentication service in Active Directory (AD) environments on Microsoft Windows domains. Understanding Kerberos is essential in enterprise environments. If you’re not yet familiar with it, please take a moment to review this course or this link for more details.
Summary
After reviewing the course above, you’ll see that kerberoasting activity can be detected through Security logs. You can also refer to this additional link for more information.
To hunt for Kerberoasting activity, we need to pay attention to two key Event IDs: 4768 and 4769.
When filtering by these two Event IDs, you’ll notice a large number of logs, which is normal in day to day activity. What’s important to focus on are the Service Name and the Ticket Encryption Type fields.
Under normal conditions, the Ticket Encryption Type is typically 0x12, indicating AES-256 encryption. The Service Name field should show requests from accounts ending with ‘$’, which represent computer name or other service accounts that Windows uses as part of its normal operations.
When reviewing the filtered events, we can see an Event ID 4768 with Ticket Encryption Type 0x17, which indicates the ticket was encrypted using the RC4 algorithm. This is immediately followed by an Event ID 4769, also with encryption type 0x17, where the Service Name is SQLService, a domain user account. This combination is a red flag and requires further investigation.
Once we’ve narrowed our focus to the two Event IDs above, we can move on to the questions: Q1, Q2, Q3, and Q4.
Q1: Kerberoasting activity occurred within a specific timeframe. What is the exact date and time of the attack?
From the image above, we can see that a Kerberos service ticket was requested for SQLService . The Key Distribution Center (KDC) responds with a Ticket Granting Service (TGS) ticket encrypted using the service account’s password hash. An attacker can extract this encrypted ticket and attempt to crack it offline.
This activity is a clear indicator of Kerberoasting.
Q2: What service name did the attacker target during the Kerberoasting attempt?
This is ServiceName.
Q3: Sarah notices that the attacker requested a Kerberos service ticket. Which account was used to make this request?
This is TargetUserName.
Q4: While investigating further, Sarah identifies the IP address and port of the login session during the attack. What are the source IP address and port for this login?
This is IpAddress:IpPort.
Q5: As Sarah discovered that the attacker created a new user account for persistence. Can you determine the name of this newly created account?
To identify newly created users, we can filter for Event ID 4720. In this case, the event was logged around the same time as the Kerberoasting activity, suggesting that the attacker may have created this account.
Q6: The attacker then created a scheduled task to ensure persistence. What is the exact timestamp when the task was created?
This question took me some time to answer. Initially, I tried looking in the Task Scheduler and Security logs but couldn’t find any tasks created around that time. Then I realized that scheduled tasks can also be checked directly in the file system, not just in event logs, at the path C:\Windows\System32\Tasks.
We noticed a Task Scheduler entry with the same name as the newly created user, which is highly suspicious. Upon inspection, it appears this task was used to add the new user to the domain, representing a common persistence technique.
We can obtain the answer from the file’s Properties.
Q7: Afterwards, the attacker logged in successfully using the newly created account. What source port was used for this login?
We can track successful logins using Event ID 4624. The logs show that the attacker used the newly created account to log into the compromised machine.
Finally, we reach the two questions that gave me the most trouble in this challenge.
Q8: Sarah traced the attacker's steps back to the first interaction with a compromised machine. When did the attacker first interact with this machine?
Hint: Filter the Tonylogs’ event logs for the attacker's IP to identify the initial contact.
To solve the last two questions, I used a third party tool called EvtxECmd. After extracting the security logs into a CSV file, I opened it with Timeline Explorer.
As shown in the image above, using the attacker IP from Q7, we can see that the attacker attempted to log into the compromised machine before succeeding, as indicated by Event IDs 4625 (failed login) and 4624 (successful login).
By examining the payload in the first row, we can see that the attacker attempted to log in using the Corrado account, marking their first interaction with this machine. Additionally, the LogonType is 3, which indicates that the user or computer logged on from the network.
Q9: After pivoting through the compromised machine, Sarah identifies the account name used for the initial successful login. What account name was used by the attacker?
After several failed login attempts, the attacker finally gained access to the account, as shown by the first successful login recorded in Event ID 4624.
Thank you for your watching ~~.
I’m grateful that solving this challenge helped me review my Kerberos knowledge, which I had studied a long time ago and nearly forgot. Writing this writeup also helped me consolidate what I’ve learned.
Cheer !!
Last updated