Kerberoasted
Last updated
Last updated
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.
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:
A threat actor compromises the account of a Domain User.
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.
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.
The threat actor captures the TGS ticket and takes it offline.
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.
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.
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 .
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.
_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.
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:
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.
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:
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?
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 :)
You can read more about it .
Lab Link:
