Kerberoasting
KERBEROASTING :
WALKTHROUGH , DETECTION AND MITIGATION
Welcome to a new blog in our series on Active Directory attacks and exploitations!
In this blog, I’ll simplify the concept of Kerberoasting exploitation by explaining the fundamental concepts and conducting some proof of concept, as always. So let the hunt begin!!
OVERVIEW
When attacker compromises a machine within an Active Directory environment, they attempt to request service tickets from a domain controller to obtain service account credentials and escalate their privileges
FUNDAMENTALS
Before presenting the proof of concept, we must clarify some necessary concepts so that we can delve deeply into the details of this exploitation.
TGS : Ticket Granting service , it’s a ticket generated by the KDC ( key distribution center) ,this ticket enables user to acces a specified service. The TGS is encrypted using a key derived from the Service Owner Hash which is the user or machine account that the service runs under.
To dive into the details of kerberos Authentication I recommend you to check out MO72 blog
SPN: Service principal Name , is an account used to o run services and they are usually granted the least privilege necessary to perform their function.
How this can be exploited by attacker to maintien kerberoatsing
As seen in the fundamental part, the TGS ticket is encrypted with the password hash of the service account assigned to the requested SPN as the key. This means that an attacker who captures TGS tickets in network traffic or extracts them from memory can obtain the password hash of the service account and perform an offline brute force attack to recover the plaintext password.
LAB SET UP
To accomplish this exploitation i’ve used an AD LAB featuring an SPN to run SQL Service, there are the command i used to create an SPN :
EXPLOITATION
To maitien this attack i’ve used two tools: Impacket and Rubeus.
1-Impacket: This tool consist the use of the python script GetUserSPNs , which can perform all the necessary steps to request a ST for a service given its SPN and valid domain credentials. Learn more
2-Rubeus: The Kerberoasting attack that leverages Rubeus involves enumerating the SPN accounts and then execute Rubeus.exe executable file. Lean more
other techniques can be found here
Let’s proceed with the Impacket tool.
After compromising the USER1 machine and obtaining its credentials, we will use them to execute the following command and retrieve the SPN password hashes:
1
GetUserSPNs.py DOMAIN/USER:PASSWORD -dc-ip @DC_IP -request
Then we will crack this hash using hashcat or John The Ripper and obtain the SPN credentials.
Now, let’s attempt to achieve the same task using Rubeus. In this scenario, we assume that we have obtained an interactive shell with the USER1 machine, so we will leverage this to execute the necessary scripts to perform kerberoasting.
Firstly, we enumerate the SPN accounts using the following script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
$ldapFilter =
"(&(objectClass=user)(objectCategory=user)(servicePrincipalName=*))"
$domain = New-Object System.DirectoryServices.DirectoryEntry
$search = New-Object System.DirectoryServices.DirectorySearcher
$search.SearchRoot = $domain
$search.PageSize = 1000
$search.Filter = $ldapFilter
$search.SearchScope = "Subtree"
#Execute Search
$results = $search.FindAll()
#Display SPN values from the returned objects
$Results = foreach ($result in $results)
{
$result_entry = $result.GetDirectoryEntry()
$result_entry | Select-Object @{
Name = "Username"; Expression = { $_.sAMAccountName }
}, @{
Name = "SPN"; Expression = { $_.servicePrincipalName | Select-Object
-First 1 }
}
}
$Results
After obtaining a shell on the USER1 machine, we initiate a PowerShell session to upload and execute the required scripts.
When attempting to run the enumeration script, I encountered a problem. The language mode was set to constrained language mode, which prohibits running these kinds of scripts.
Constrained language mode :
PowerShell Constrained Language is a language mode of PowerShell designed to support day-to-day administrative tasks, yet restrict access to sensitive language elements that can be used to invoke arbitrary Windows APIs.
To bypass this issue, I explored several blogs to understand how this mode works and how it can be evaded. I found that one method involves ensuring that the path from which the script is being executed contains the string “system32”. Another approach is to rename the script to “system32.ps1”.
So let’s try it
After enumrating the SPN we run the Rubeus.exe to get the password hashes:
Finally, after obtaining SPN credentials, the attacker can access network resources and further their objectives. This can include exfiltrating data, moving laterally within the network, or escalating their privileges.
DETECTION
When the attacker requests a TGS, certain event IDs are generated within the Windows Event Logs depending on the response to the request:
4769(S, F) A Kerberos service ticket was requested;
4770(S) A Kerberos service ticket was renewed;
4773(F) A Kerberos service ticket request failed.
Here is the Windows Event ID I received on the domain controller when the TGS was requested:
This proves that the TGS was successfully requested.
MITIGATIONS
1-Password Policies
Adopting strong password hygiene practices for service accounts Service account passwords should be randomly generated, have a minimum length of 30 characters, and be changed frequently.
2-Flexible Authentication Secure Tunneling (FAST)
This is also known as Kerberos Armoring,is a security feature in Active Directory Domain Services that was introduced with Windows Server 2012. This new feature solves common security problems with Kerberos and also makes sure clients do not fall back to less secure legacy protocols or weaker cryptographic methods.It provides a protected channel between the client and the Key Distribution Center (KDC).
Enabling Kerberos Armoring
We will enable Kerberos Armoring using Group Policy.
We start by creating a new GPO (Group Policy Object) :
Then we edit this GPO :
In the left navigation pane of the Group Policy Management Editor window, expand Computer Configuration, then Administrative Templates, System and finally Kerberos.
By double-clicking on the “Kerberos client support for claims, compound authentication and Kerberos armoring” policy setting:
And we successfully completed the task by selecting the “Enabled” option
Then we create another GPO where we configure the KDC to force Kerberos armoring :
And with that, we come to the end of this article. Thank you for reading! Catch you in the next blog!