Kerberos is a protocol that attempts to eliminate the need to send plaintext across the net by authenticating users with tickets. I’ll touch on what attributes these tickets have later that are valuable to us, but they contain a lot of juicy information we, the attackers, can exploit in order to gain access to network resources and networks themselves.

Kerberos was developed as a part of Project Athena, a 1983 initiative to create a campus-wide distributed computing environment for use by MIT’s students [1]. The protocol grew from there to become “one of the most widely deployed systems for authentication and authorization [2].” Most major operating systems have adopted it to assist in aiding network applications to securely identify peers in federated enterprises and peer-to-peer network[2][3]. After, it’s open source release in 1987, the IETF (Internet Engineering Task Force) caught wind of it and made it a standard in 1993[1]. That same year, Microsoft bought into the protocol and adopted it into their products. The first release of Windows Server 2000 in 1999 used Kerberos as the default authentication protocol[4]. Since then, MIT and Microsoft have worked together to make improvements on the protocol, releasing several new versions of it that include improvements upon the encryption scheme, adding checksums, etc. Also, as a side note, in 2007, MIT created the MIT Kerberos & Internet Trust (KIT) Consortium to maintain the protocol in an open manner[2].

“But Brian why do we need to care about this?” To beast on some fools when they disrespect your knowledge chops, obviously. Realistically, it’s good to have a historical perspective to take into consideration the developer’s mind set in updating the protocol should you ever choose to attempt to find vulnerabilities in newer versions.

Vicious
“The name of the Kerberos protocol suggests its solution to the problem of key distribution. Kerberos (or Cerberus) was a figure in classical Greek mythology—a fierce, three-headed dog who kept living intruders from entering the Underworld. Like the mythical guard, the Kerberos protocol has three heads: a client, a server, and a trusted third party to mediate between them. The trusted intermediary in this protocol is the Key Distribution Center (KDC)[6].”

The KDC is a network service that supplies session tickets and temporary session keys used in the Kerberos V5 authentication protocol. It runs as a privileged process on all domain controllers. On Windows Server, the KDC contains two main services: the Authentication Service (AS) and the Ticket Granting Service (TGS). The AS ensures the user is valid and has the proper permissions to access the service or resource they’re requesting while the TGS creates and issues Ticket Granting Tickets. Only after the user receives a TGT can they be given a service ticket by the Ticket Granting Service (TGS), which finally gives them the access to whatever service they originally requested.

I worked too hard on this graphic for you to not click on that link below...

I made a pretty dope graphic [CLICK RIGHT HERE]  for an awesome step by step of the entire Windows Kerberos. NOTE: this info was straight copy and pasted from the Win32 Developer documentation (link at the end). Feel free to reproduce, I really don't care what you do with it. Just stop asking me to hack your girlfriends' phones...

So what does a ticket look like? In a basic form we can use the command "klist" to show the locally cached tickets of services the current user has authenticated with since they logged on.

This is what a service ticket looks like

Above shows two service tickets where we can see the fields included. Service tickets have a time limit on them. On expiration, the user then needs to reauthenticate with the KDC. Don't worry, it can happen in the background of your session, so you're session won't be interrupted. For the second ticket, the RC4 algorithm is used as the encryption type, which is bad.  The admin pizza'd when they should've French fried and the user is now in for a bad time as it means a hash of the service account associated with the service principal name (SPN) is the private key. Since it's the private key, it can be vulnerable to offline brute force attacks[9]. If we can get ahold of a service ticket before the time is expired, we can do a Pass the Ticket attack where we just hand off the ticket to the service to gain access. This can be used to move laterally throughout the realm (domain) or gain access to a resource. There's also the Silver Ticket attack where we can forge a service ticket if we have the service account's password hash. A service account is a user account that is created explicitly to provide a security context for services running on Windows Server operating systems[8]. It can be useful in a pinch or in an environment where you don't want to create a lot of noise, but the TGT is a better target as this is limited in the scope of the effect.

This is what a TGT looks like

Now this ticket is where big money can be made. If an attacker can crack the TGT, the attacker can request as many TGS's as they want since it's essentially the stamp of approval from the KDC. Next to the ServiceName and SPN is the KRBTGT. KRBTGT is the service account for the KDC as well as the SPN used by the KDC for the domain. It's password is used to encrypt all tickets, so only the domain controller can open them. This password is set on creation of the domain controller (important later) and pretty much doesn't change. If the password is changed, both the current and previous accounts can be used to for signing/encrypting tickets[10]. This is the name of the service that generates and validates tickets. The ticket also has a time limit on it like the service ticket to attempt at preventing ticket reuse. Not a very good attempt, but an attempt was made.


Knowing how protocols work is a must before attacking them, unless you want to be a skid **SCOFF**. Like I've mentioned before, you have to know what your tools are doing before you use them. Otherwise you're trusting some random person out there with your freedom should you not choose to make your own tools. Kerberos is one of the first steps into the big kid's room for active directory attacks. Exploiting it can be fairly quiet, yet extremely useful for bouncing around networks. In a later article, I'll implement the following attacks:  Silver ticket, Golden ticket, kerberoasting, and I'll give a shot at AS-REP roasting. I chose not to go too deep into these attacks since this is an introduction.  Till next time.

Stay filthy.

1.https://www.kerberos.org/about/FAQ.html#:~:text="Kerberos is the name of,way back in the 1980s.&text=MIT released its Kerberos software,been enhancing it ever since.
2.https://kit.mit.edu/about/history
3.http://www.cs.fsu.edu/~awang/courses/cop5611_s2006/kerberos.pdf
4.https://devopedia.org/kerberos
5.https://docs.microsoft.com/en-us/windows/win32/secauthn/key-distribution
6.https://docs.microsoft.com/en-us/windows/win32/secauthn/key-distribution#:~:text=The name of the Kerberos,intruders from entering the Underworld.
7.https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/klist
8.https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/service-accounts#:~:text=A service account is a,access local and network resources.
9.https://attack.mitre.org/techniques/T1558/
10.https://www.blackhat.com/docs/us-15/materials/us-15-Metcalf-Red-Vs-Blue-Modern-Active-Directory-Attacks-Detection-And-Protection-wp.pdf