microsoft

Kerberoasting

David Johnson

David Johnson

— 4 min read

Mitre ATT&CK technique T1558.003 or more commonly known as Kerberoasting, is a technique that allows a malicious actor to brute force Kerberos TGS(ticket-granting service) tickets offline. This technique requires Active Directory and a user with an SPN(service principal name). Here I will not be covering how to set up Active Directory. However, I will go over creating a user with an SPN and how to use Impacket to get the TGS tickets

What will not be covered

I will not be covering how to set up Active Directory or Impacket. Nor will I be covering how to brute force the TGS ticket.

What will be covered

I will go over creating a user with an SPN and how to use Impacket to get the TGS tickets. I will also cover how to detect Kerberoasting with Windows Event Logs.

Adding a new user

To add a new user, open Active Directory Users and Computers click on the
server and scroll down to and right-click on Users navigate to New and
Users. Fill in the information and click on Next. Add the password and click on Password never expires then click Next. Finally, click on Finish. Right-click on the user you just created, scroll down to, and click Properties. Click on the Delegation tab then click on Trust this user for delegation to any service (kerberos only). Click on Apply then OK.

With the new user created and proper delegations set, you can set the SPN.

Set SPN

To set the SPN for a user open a PowerShell window or cmd prompt and enter the following.

 setspn.exe -s http/<Machine Name>.<Domain Name> <User>

Kerberosting

After installing Impacket on a separate machine, most commonly a Linux box, we will use GetUserSPNs.py to retrieve a Kerberos ticket. Allowing for an offline brute-forcing attack, which is out of scope in this instance but worth noting.

GetUserSPNs.py <Domain Name>/<User Name>:<Password> -dc-ip <Domain IPAddress> -target-domain <Domain Name> -request

Note: Select a user with Administrator Privileges

Detection

Windows Security Event Logs is a treasure trove of information. The hard part is knowing what to look for and how to digest the information. For Kerberos, we are going to look for event ID 4769. These can be rather popular in an enterprise environment and not a sign of compromise in its self. The event will need closer scrutiny. Take a close look at the following two examples. Can you see the difference?

Standard Event.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
    <System>
        <Provider Name='Microsoft-Windows-Security-Auditing' Guid='{54849625-5478-4994-A5BA-3E3B0328C30D}'/>
        <EventID>4769</EventID>
        <Version>0</Version>
        <Level>0</Level>
        <Task>14337</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8020000000000000</Keywords>
        <TimeCreated SystemTime='2016-08-30T20:53:14.813029200Z'/>
        <EventRecordID>27434</EventRecordID>
        <Correlation/>
        <Execution ProcessID='540' ThreadID='2916'/>
        <Channel>Security</Channel>
        <Computer>Beylix.FIREFLY.local</Computer>
        <Security/>
    </System>
    <EventData>
        <Data Name='TargetUserName'>Administrator@WIN2012R2.LOCAL</Data>
        <Data Name='TargetDomainName'>WIN2012R2.LOCAL</Data>
        <Data Name='ServiceName'>BEYLIX$</Data>
        <Data Name='ServiceSid'>S-1-5-21-1665023642-4283655525-2352456853-1003</Data>
        <Data Name='TicketOptions'>0x40810000</Data>
        <Data Name='TicketEncryptionType'>0x12</Data>
        <Data Name='IpAddress'>::1</Data>
        <Data Name='IpPort'>0</Data>
        <Data Name='Status'>0x0</Data>
        <Data Name='LogonGuid'>{5139023C-F349-460E-5CCA-5C9F855EDDA3}</Data>
        <Data Name='TransmittedServices'>-</Data>
    </EventData>
</Event>

Kerberoasting Event.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Events>
  <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    <System>
      <Provider Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" Name="Microsoft-Windows-Security-Auditing"></Provider>
      <EventID>4769</EventID>
      <Version>0</Version>
      <Level>0</Level>
      <Task>14337</Task>
      <Opcode>0</Opcode>
      <Keywords>0x8020000000000000</Keywords>
      <TimeCreated SystemTime="2020-07-09T16:26:04.520291100Z"></TimeCreated>
      <EventRecordID>9538</EventRecordID>
      <Correlation></Correlation>
      <Execution ProcessID="468" ThreadID="1112"></Execution>
      <Channel>Security</Channel>
      <Computer>DevBox12.win2012r2.local</Computer>
      <Security></Security>
    </System>
    <EventData>
      <Data Name="TargetUserName">Administrator@WIN2012R2.LOCAL</Data>
      <Data Name="TargetDomainName">WIN2012R2.LOCAL</Data>
      <Data Name="ServiceName">kerby</Data>
      <Data Name="ServiceSid">S-1-5-21-2223642951-2156564808-3888146919-1109</Data>
      <Data Name="TicketOptions">0x40810010</Data>
      <Data Name="TicketEncryptionType">0x17</Data>
      <Data Name="IpAddress">::ffff:192.168.1.49</Data>
      <Data Name="IpPort">53398</Data>
      <Data Name="Status">0x0</Data>
      <Data Name="LogonGuid">{8970B74C-4E7B-AE25-79C3-45538A86FA3C}</Data>
      <Data Name="TransmittedServices">-</Data>
    </EventData>
  </Event>
</Events>

The first thing to look for is TicketOptions with the value of 0x40810010. Alone this is not suspicious; however, it is a good starting point. Next, look for TicketEncryptionType of 0x17. Having both of these, its time to start to take a closer look. The next thing to look at is ServiceName does it end with $? If not, it's starting to look suspicious. However, ensure the TargetUserName is not $@ because this could be a normal Kerberos ticket. Another suspicious indicator would be an empty ServiceSid. If you do have an event that matches these criteria, further investigation is needed. Look for things like lateral movement using credentials from users with an SPN.

References

Read more