Kerberoasting with Jupyter Notebook
By Elkayam Harel And Azrati Lee
Introduction
We have conducted several research projects in the threat hunting field and many times we have said to ourselves “we have done great research and we wrote an advanced detection notebook regarding the topic, why don't we share it with our community?!”
So after a very long time, we have decided to share some of our work with the community and this blog will be the beginning of our analytic sharing series.
In this blog, we will cover the process of creating a threat hunting notebook for the Kerberoasting technique. We recommend reviewing the great blog post “Cracking Kerberos TGS Tickets Using Kerberoast – Exploiting Kerberos to Compromise the Active Directory Domain” to gain a bit of knowledge about Kerberos terminology and Kerberoasting fundamentals.
Kerberoasting (T1558.003) by MITRE :
“Adversaries may abuse a valid Kerberos ticket-granting ticket (TGT) or sniff network traffic to obtain a ticket-granting service (TGS) ticket that may be vulnerable to Brute Force.”
The Research Process of Kerberoasting
The process was as follows:
- Set up a dedicated lab that simulates an enterprise network including Active Directory Domain Controller, SQL and web servers(registered as SPNs), and several windows 10 hosts.
- Deploying sensors, in this case, we chose: Sysmon for endpoint visibility, Windows Event Logs(Security Channel) for Kerberos ticketing visibility, and SilkETW for LDAP queries visibility.
- Ingesting sensors data to the HELK threat hunting platform, which enables an analysis framework using Jupyter notebooks with Spark and ELK stack.
- Create a Kerberoasting tool and gather up some of the very known tools (like Rubeus and Impacket and etc).
- Simulate the technique by the attack tools of phase 4 and observe how the attack reflects on the sensors’ data.
Attack Artifacts :
We assume that our attacker already has access to our network and has a valid domain user. Specifically for this blog, we assume the attacker does all steps on the same endpoint(even though it is not in the code— the notebook concepts are relevant also to distributed attack version or attack which spread on multiple endpoints).
We will review the attack steps, mention the relevant loggings(visibility), and view the different steps as they were reflected by our sensors :
- Step 1- Reconnaissance, the attacker discovers who are the service accounts in the domain, can be observed by ETW Microsoft-Windows-LDAP-Client provider.
- Step 2- The attacker requests service tickets for each service account, can be observed by Windows Event Logs, Security log (event_id: 4769)
- Step 3- Extracting tickets from memory and storing them on the local disk, can be observed by Sysmon events (event_id: 11). This step doesn't occur in every attack implementation.
- Step 4- Bruteforcing the tickets and crack the TGS-REP hashes.
STEP 1
The common initial step on the Kerberoasting - is the AD enumeration. An adversary tries to collect data on service accounts via the LDAP query mechanism. In many cases the LDAP query will look like :
samAccountType=805306368 — which means that this is a user account object.
servicePrincipleName=* — get all the SPN available in the domain.
The combination of those objects retrieves all service accounts in the domain.
STEP 2
After the enumeration step, the adversary chooses its targets and requests a TGS service(TGS-REQ) ticket for each targeted service account.
By observing Event log 4769, we can already see some indication of an anomaly — the encryption level of RC4 (0x17). Attackers may downgrade the encryption level in order to enable the capability of bruteforcing the TGS ticket and extracting the holy grail — The TGS-REP hash.
STEP 3
The TGS tickets are stored in memory, therefore they should be exported to the local disk (There are some tools that already extract the Kerberos TGS-REP etype 23 hash and output it to the terminal or file)
STEP 4
Extract and crack the Kerberos5 TGS-REP etype 23 hashes from the TGS tickets stored on the file system.
We have finished the research stage including attack simulations with a wide variety of tools and observed how the attack artifacts reflected on the sensor’s data.
Armed with all this valuable information — we are ready to create our threat hunting notebook 💪
The Notebook Concept
The practical detection part - for each step we observe the attack artifacts on sensor data and correlate between them to generate a lead. By correlating multi-sensor events we detect multiple stages of the attack and enrich the evidence.
First, we search for LDAP reconnaissance with suspicious query including service principal names, we used Microsoft-Windows-LDAP-Client provider {099614A5–5DD7–4788–8BC9-E29F43DB28FC} from silkETW sensor.
We extract the PID and Hostname fields and try to correlate this information with the Sysmon sensor eventID 3 (Network connection)
With this correlation, we have valuable information — User account name, process name, and process GUID which may give us an indication about malicious activity.
Using process GUID in Sysmon, we can enrich our data by registry and file creation events and have a better understanding of the attacker’s actions.
Eventually, we would like to know which of the service accounts have been cracked, so we would seek this information about the ticketing DC event logs (4769)
To sum things up, the notebook logic flow described in the following illustration :
We have created a complete threat hunting notebook that generates a lead for this technique. You can find the notebook with an execution example here :
Hope you enjoyed the post 🤟 and we will keep updating the TH-Notebooks repo with more content.
*The next step is to correlate Kerberos.log with the network Zeek sensor in order to detect step 2 encryption downgrade tickets.
