Kerberoasting with Jupyter Notebook
Tags: Mitre Attack, Threat Hunting, Cyber, Jupyter Notebook, Kerberoasting

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.

TGS request flow (the picture taken from ADsecurity.org)

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 :