Part of an upcoming series trying to shed the light on attacks targeting Microsoft Kerberos implementation in Active Directory Environments.
Introduction and Brief History
Table of Contents
According to myth, Cerberus guards the Gates to the Underworld. As It’s a big 3 headed dog with a snake’s tail. Back to our world, MIT Computer Scientists used the name and visual of Cerberus for their computer network authentication protocol. Kerberos uses symmetric key cryptography and requires trusted third-party authorization to verify user identities. Since Kerberos requires 3 entities to authenticate and has an excellent track record of making computing safer, the name really does fit. Still Continuing in our real-world Kerberos is the most widely deployed system for authentication and authorization in modern computer networks, Given Kerberos is the basis of Microsoft Windows security, which drives us to mention that Microsoft Windows is the front door to the network for many users especially in the corporate scene, for example Kerberos (through Windows) is often the first thought for achieving Single Sign On.
But before explaining “How Kerberos Works?” there are some general terms that you might not be familiar with, so let’s run through them quickly.
Service Principal Names (SPNs)
SPN Purpose
A service principal name (SPN) is the name by which a Kerberos client uniquely identifies an instance of a service for a given Kerberos target computer. If you install multiple instances of a service on computers throughout a forest, each instance must have its own SPN. A given service instance can have multiple SPNs if there are multiple names that clients might use for authentication. For example, an SPN always includes the name of the host computer on which the service instance is running, so a service instance might register an SPN for each name or alias of its host.
SPN Format
serviceclass/host:port servicename
serviceclass and host are required, but port and service name are optional. The colon between host and port is only required when a port is present.
See the following table for a description of each element in the command above:
| Element | Description |
| serviceclass | A string that identifies the general class of service; for example, “SqlServer”. There are well-known service class names, such as “www” for a Web service or “ldap” for a directory service. In general, this can be any string that is unique to the service class. Be aware that the SPN syntax uses a forward slash (/) to separate elements, so this character cannot appear in a service class name. |
| host | The name of the computer on which the service is running. This can be a fully-qualified DNS name or a NetBIOS name. Be aware that NetBIOS names are not guaranteed to be unique in a forest, so an SPN that contains a NetBIOS name may not be unique. |
| port | An optional TCP or UDP port number to differentiate between multiple instances of the same service class on a single host computer. Omit this component if the service uses the default port for its service class. |
| servicename | An optional name used in the SPNs of a replicable service to identify the data or services provided by the service or the domain served by the service. This component can have one of the following formats:
|
Examples of SPN registrations:
- HOST/SERVER7.corp.local– Any service running on the computer with hostname SERVER7.corp.local
- TERMSRV/WORKSTATION03.corp.local – The Remote Desktop Protocol (RDP) service running on the computer with hostname WORKSTATION03.corp.local
- MSSQLSvc/SQLSERVER2.corp. local:1433 – The SQL Server listening on SQLSERVER2.corp.local, port 1433.
Key Distribution Center
The Key Distribution Center (KDC) is implemented as a domain service. It uses the Active Directory as its account database and the Global Catalog for directing referrals to KDCs in other domains.
As in other implementations of the Kerberos protocol, the KDC is a single process that provides two services:
- Authentication Service (AS)
This service issues ticket-granting tickets (TGTs) for connection to the ticket-granting service in its own domain or in any trusted domain. Before a client can ask for a ticket to another computer, it must request a TGT from the authentication service in the client’s account domain. The authentication service returns a TGT for the ticket-granting service in the target computer’s domain. The TGT can be reused until it expires, but the first access to any domain’s ticket-granting service always requires a trip to the authentication service in the client’s account domain.
- Ticket-Granting Service (TGS)
This service issues tickets for connection to computers in its own domain. When clients want access to a computer, they contact the ticket-granting service in the target computer’s domain, present a TGT, and ask for a ticket to the computer. The ticket can be reused until it expires, but the first access to any computer always requires a trip to the ticket-granting service in the target computer’s account domain.
The KDC for a domain is located on a domain controller, as is the Active Directory for the domain. Both services are started automatically by the domain controller’s Local Security Authority (LSA) and run as part of the LSA’s process. Neither service can be stopped. If the KDC is unavailable to network clients, then the Active Directory is also unavailable—and the domain controller is no longer controlling the domain. The system ensures availability of these and other domain services by allowing each domain to have several domain controllers, all peers. Any domain controller can accept authentication requests and ticket-granting requests addressed to the domain’s KDC.
How Kerberos Works?
“Borrowed From Sean Metcalf” – Reference
User logs on with username & password.
- a. Password converted to NTLM hash, a timestamp is encrypted with the hash and sent to the KDC as an authenticator in the authentication ticket (TGT) request (AS-REQ).
b. The Domain Controller (KDC) checks user information (logon restrictions, group membership, etc) & creates Ticket-Granting Ticket (TGT). - The TGT is encrypted, signed, & delivered to the user (AS-REP). Only the Kerberos service (KRBTGT) in the domain can open and read TGT data.
- The User presents the TGT to the DC when requesting a Ticket Granting Service (TGS) ticket (TGS-REQ). The DC opens the TGT & validates PAC checksum – If the DC can open the ticket & the checksum check out, TGT = valid. The data in the TGT is effectively copied to create the TGS ticket.
- The TGS is encrypted using the target service accounts’ NTLM password hash and sent to the user (TGS-REP).
- The user connects to the server hosting the service on the appropriate port & presents the TGS (AP-REQ). The service opens the TGS ticket using its NTLM password hash.
What is the difference between Kerberos and NTLM?
Before Kerberos, Microsoft used an authentication technology called NTLM. NTLM stands for NT Lan Manager it’s a challenge/response-based authentication protocol that is the default authentication protocol of Windows NT 4.0 and earlier Windows versions. For backward compatibility reasons, Microsoft still supports NTLM in Windows Vista, Windows Server 2003 and Windows 2003 R2, Windows 2000, and Windows XP. Starting with Win2K, Microsoft implements Kerberos as the default authentication protocol for the Windows OS. This means that besides an NTLM authentication provider, every Windows OS since Win2K also includes a client Kerberos authentication provider.
The biggest difference between the two systems is the third-party verification and stronger encryption capability in Kerberos. This extra step in the process provides a significant additional layer of security over NTLM.
What is Kerberoast?
The Microsoft implementation of Kerberos can be a bit complicated, the attack takes advantage of legacy Active Directory support for older Windows clients and the type of encryption used and the key material used to encrypt and sign Kerberos tickets. Essentially, when a domain account is configured to run a service in the environment, such as MS SQL, a Service Principal Name (SPN) is used in the domain to associate the service with a login account. When a user wishes to use the specific resource, they receive a Kerberos ticket signed with NTLM hash of the account that is running the service. Remember that just requesting this ticket doesn’t grant access to the requesting user, as it’s up to the server/service to determine whether the user should be given access. Tim Medin (the researcher who discovered Kerberoast) realized that because of this, and because part of a TGS requested for an SPN instance is encrypted with the NTLM hash of a service account’s plaintext password. Therefore, the process of cracking Kerberos service tickets and rewriting them in order to gain access to the targeted service is called Kerberoast. at RedForce we use this attack often in our red team engagements as it doesn’t require any interaction with the service, we can request and export the service ticket which can be later cracked “OFFLINE” without fear of detection. in order to retrieve the plain-text password of the service. As service tickets are encrypted with the NTLM hash of the service account so any domain user without any special privileges you don’t have to be a domain admin neither local admin, just a domain user with the least possible privileges can dump hashes of services without even getting a shell into the system that is running the service.
Launching the Attack.
There are multiple ways to request a TGS, either by using the built-in Windows SetSPN.exe function or by using PowerShell and Python scripts. luckily and thanks to harmj0y The PowerShell Empire project contains a script called Invoke-Kerberoast.ps1, which at first identifies all SPNs using the PowerView function’s “Get-NetUser -SPN” then requests the associated TGS for each service account using Get-SPNTicket from PowerView . The TGS can be output directly in hashcat format for further offline cracking.
after dumping the hash we proceed with cracking it, using hashcat.
Now as we successfully cracked the previously obtained hash we can go ahead and perform more in depth reconnaissance on the compromised service account using BloodHound which revealed that it is already a privileged account in the domain and can be used to perform lateral movement leading to compromise more systems across the domain.
Conclusion
Kerberoast is an effective technique for a red teamer who have limited privileges of a domain user. Depending on the strength of the passwords and since people tend to create poor passwords, an attacker can quickly gain access to the service account and move laterally to launch additional attacks. The attack itself cannot be prevented, but selecting strong complex passwords will make it more difficult.
Refernces
[1] https://technet.microsoft.com/en-us/library/ee681663.aspx
[2] https://technet.microsoft.com/en-us/library/ff405676.aspx
[3] https://github.com/BloodHoundAD/SharpHound
[4] https://docs.microsoft.com/en-us/powershell/module/Microsoft.powershell.utility/convertfrom-sddlstring
[5] https://adsecurity.org/?p=2293
[6] https://medium.com/@robert.broeckelmann/kerberos-and-windows-security-series-59282e0f9465
[7] https://www.sans.org/cyber-security-summit/archives/file/summit-archive-1493862736.pdf
[8] https://www.youtube.com/watch?v=HHJWfG9b0-E
[9] https://blogs.technet.microsoft.com/askds/2008/03/06/kerberos-for-the-busy-admin/
[10] https://www.scip.ch/en/?labs.20181011
[11] https://www.beneaththewaves.net/Projects/Mimikatz_20_-_Brute-Forcing_Service_Account_Passwords.html
