> For the complete documentation index, see [llms.txt](https://h05am10.gitbook.io/h05am10/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://h05am10.gitbook.io/h05am10/write-ups/cyberdefenders/threat-hunting/kerberoasted.md).
# Kerberoasted
#### Scenario:
As a diligent cyber threat hunter, your investigation begins with a hypothesis: 'Recent trends suggest an upsurge in Kerberoasting attacks within the industry. Could your organization be a potential target for this attack technique?' This hypothesis lays the foundation for your comprehensive investigation, starting with an in-depth analysis of the domain controller logs to detect and mitigate any potential threats to the security landscape.
Note: Your Domain Controller is configured to audit Kerberos Service Ticket Operations, which is necessary to investigate kerberoasting attacks. Additionally, Sysmon is installed for enhanced monitoring.
#### Incident Walkthrough:
This lab is about the Kerberoasting attack. To answer the questions, first you need to understand what it is.
**Kerberoasting** is a post-exploitation attack technique that attempts to obtain a password hash of an Active Directory account that has a Service Principal Name (“SPN”).
How do **Kerberoasting** attacks work?
**Kerberoasting** attacks exploit a combination of weak encryption techniques and simple or low-complexity passwords. These attacks typically follow the below process:
1. A threat actor compromises the account of a Domain User.
2. The threat actor uses the Domain User context to request a Kerberos service ticket from the ticket granting service (TGS) using tools like GhostPack’s Rubeus or SecureAuth Corporation’s GetUserSPNs.py.
3. The threat actor receives a ticket from the Kerberos key distribution center (KDC). The ticket is encrypted with a hashed version of the account’s password.
4. The threat actor captures the TGS ticket and takes it offline.
5. The threat actor attempts to crack the SPN credential hash to obtain the service account’s plaintext password using brute force techniques or tools like Hashcat or JohnTheRipper.
6. With the service account password in hand, the threat actor attempts to authenticate as the service account and is granted access to any service, network or system associated with the compromised account.
7. The attacker is then able to steal data, escalate privileges or set backdoors on the network to ensure future access.
You can read more about **kerberoasting** attack from [here](https://www.crowdstrike.com/en-us/cybersecurity-101/cyberattacks/kerberoasting/).
Let's go back to answer the questions.
`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 encryption type affects security by determining resistance to brute-force attacks and replay attacks.
To answer this question, we need to filter on the event ID **4769**, which is a **Kerberos service ticket request**. This event contains the encryption type and is generated only on domain controllers.
Using the query, we will get the encryption type.
```spl
index="kerberoasted" "event.code"=4769
| dedup winlog.event_data.TicketEncryptionType winlog.event_data.ServiceName winlog.event_data.TargetUserName
| table _time winlog.event_data.TicketEncryptionType winlog.event_data.ServiceName winlog.event_data.TargetUserName
```
* **`_time`**: The timestamp of the event, indicating when it occurred.
* **`winlog.event_data.TicketEncryptionType`**: The encryption algorithm used to protect the Kerberos ticket.
* **`winlog.event_data.ServiceName`**: The name of the service that the Kerberos ticket was requested for.
* **`winlog.event_data.TargetUserName`**: The username of the account for which the Kerberos ticket was issued.
**RC4-HMAC** is weak encryption; using it will make cracking the password much faster than **AES**.
By default, the Group Policy Object for Kerberos encryption types is undefined. This allows attackers to downgrade encryption when requesting a ticket for an associated Service Principal Name (SPN).
`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 answer the following question, we will use the same query as above.
`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?`
**`winlog.event_data.Status`**: The status code that indicates the result of an action or request.
We can see the status code is **0x0**, which indicates the TGS issue didn't fail.
Now, let's check if the attacker accessed the services.
We can see that a user accessed the **SQL** service after a short period of time following the TGS, but didn't access **FileShareService**.
`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?`
We can answer the following question by checking who accessed the **SQLService** as we did on the above screenshot.
`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)?`
We can determine the installed services by checking **event ID 7045**.
```spl
index="kerberoasted" event.code=7045
| table _time winlog.event_data.AccountName winlog.event_data.ServiceName
```
* **`event.code=7045`**: Filters for events with event code `7045`, which corresponds to the installation of a new service in Windows Event Logs.
* **`| table _time winlog.event_data.AccountName winlog.event_data.ServiceName`**: Outputs the results in a table displaying:
* `winlog.event_data.AccountName`: The name of the account that installed the service.
* `winlog.event_data.ServiceName`: The name of the newly installed service.
`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)?`
The value responsible for enabling and disabling the RDP 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?`
To solve this, I used the following query:
```spl
index="kerberoasted" event.code=4624 "winlog.event_data.LogonType"=10 "winlog.event_data.IpAddress"="10.0.0.154"
| table _time
```
* **`event.code=4624`**: Filters for events with event code `4624`, which corresponds to successful logon events in Windows.
* **`"winlog.event_data.LogonType"=10`**: Filters for logon events with logon type `10`, which represents a remote interactive logon (e.g., Remote Desktop Protocol, RDP).
* **`"winlog.event_data.IpAddress"="10.0.0.154"`**: Filters for logons from the specific IP address `10.0.0.154`.
* **`| table _time`**: Outputs the results as a table, showing only the `_time` field.
`Q8) To unravel the persistence mechanism employed by the attacker, What is the name of the WMI event consumer responsible for maintaining persistence?`
`Windows Management Instrumentation (WMI)` is the infrastructure for management data and operations on Windows-based operating systems. Although you can write WMI scripts or applications to automate administrative tasks on remote computers, WMI also supplies management data to other parts of the operating system and products.
You can read more about it [here](https://learn.microsoft.com/en-us/windows/win32/wmisdk/wmi-start-page).
WMI (Windows Management Instrumentation) can be used by attackers to maintain persistence through the creation of **event consumers**, which trigger actions when specific events occur on the system. The most commonly used event consumer for this purpose is the **WMI Event Consumer** itself, often configured to run a script or executable upon certain system events, such as logon or system startup. This method allows attackers to re-establish their presence even after system reboots or user logouts, making it a stealthy and effective persistence mechanism.
To check, we can use the following query:
```
index="kerberoasted" event.code=20
| table _time winlog.event_data.Name
```
`event.code=20`: Filter events with event code 20, which typically corresponds to WMI (Windows Management Instrumentation) consumer events. `winlog.event_data.Name`: Display the `Name` field from `winlog.event_data` in a table format.
`Q9) Which class does the WMI event subscription filter target in the WMI Event Subscription you've identified?`
```spl
index="kerberoasted" event.code=19
| table _time winlog.event_data.Query
```
When a WMI event filter is registered, which is a method used by malware to execute, this event logs the WMI namespace, filter name and filter expression.
**`event.code=19`**: When a WMI event filter is registered, which is a method used by malware to execute, this event logs the WMI namespace, filter name and filter expression.
I hope you enjoyed it :)
**Lab Link:** [Kerberoasted Lab](https://cyberdefenders.org/blueteam-ctf-challenges/kerberoasted/)
