Threat Research

Kerberos Tickets on Linux Red Teams

At FireEye Mandiant, we conduct numerous red team engagements within Windows Active Directory environments. Consequently, we frequently encounter Linux systems integrated within Active Directory environments. Compromising an individual domain-joined Linux system can provide useful data on its own, but the best value is obtaining data, such as Kerberos tickets, that will facilitate lateral movement techniques. By passing these Kerberos Tickets from a Linux system, it is possible to move laterally from a compromised Linux system to the rest of the Active Directory domain.

There are several ways to configure a Linux system to store Kerberos tickets. In this blog post, we will introduce Kerberos and cover some of the various storage solutions. We will also introduce a new tool that extracts Kerberos tickets from domain-joined systems that utilize the System Security Services Daemon Kerberos Cache Manager (SSSD KCM).

What is Kerberos

Kerberos is a standardized authentication protocol that was originally created by MIT in the 1980s. The protocol has evolved over time. Today, Kerberos Version 5 is implemented by numerous products, including Microsoft Active Directory. Kerberos was originally designed to mutually authenticate identities over an unsecured communication line.

The Microsoft implementation of Kerberos is used in Active Directory environments to securely authenticate users to various services, such as the domain (LDAP), database servers (MSSQL) and file shares (SMB/CIFS). While other authentication protocols exist within Active Directory, Kerberos is one of the most popular methods. Technical documentation on how Microsoft implemented Kerberos Protocol Extensions within Active Directory can be found in the MS-KILE standards published on MSDN. 

Short Example of Kerberos Authentication in Active Directory

To illustrate how Kerberos works, we have selected a common scenario where a user John Smith with the account ACMENET.CORP\sa_jsmith wishes to authenticate to a Windows SMB (CIFS) file share in the Acme Corporation domain, hosted on the server SQLSERVER.ACMENET.CORP.

There are two main types of Kerberos tickets used in Active Directory: Ticket Granting Ticket (TGT) and service tickets. Service tickets are obtained from the Ticket Granting Service (TGS). The TGT is used to authenticate the identity of a particular entity in Active Directory, such as a user account. Service tickets are used to authenticate a user to a specific service hosted on a system. A valid TGT can be used to request service tickets from the Key Distribution Center (KDC). In Active Directory environments, the KDC is hosted on a Domain Controller.

The diagram in Figure 1 shows the authentication flow.

Figure 1: Example Kerberos authentication flow

In summary:

  1. The user requests a Ticket Granting Ticket (TGT) from the Domain Controller.
  2. Once granted, the user passes the TGT back to the Domain Controller and requests a service ticket for cifs/SQLSERVER.ACMENET.CORP.
  3. After the Domain Controller validates the request, a service ticket is issued that will authenticate the user to the CIFS (SMB) service on SQLSERVER.ACMENET.CORP.
  4. The user receives the service ticket from the Domain Controller and initiates an SMB negotiation with SQLSERVER.ACMENET.CORP. During the authentication process, the user provides a Kerberos blob inside an “AP-REQ” structure that includes the service ticket previously obtained.
  5. The server validates the service ticket and authenticates the user.
  6. If the server determines that the user has permissions to access the share, the user can begin making SMB queries.

For an in-depth example of how Kerberos authentication works, scroll down to view the appendix at the bottom of this article.

Kerberos On Linux Domain-Joined Systems

When a Linux system is joined to an Active Directory domain, it also needs to use Kerberos tickets to access services on the Windows Active Directory domain. Linux uses a different Kerberos implementation. Instead of Windows formatted tickets (commonly referred to as the KIRBI format), Linux uses MIT format Kerberos Credential Caches (CCACHE files). 

When a user on a Linux system wants to access a remote service with Kerberos, such as a file share, the same procedure is used to request the TGT and corresponding service ticket. In older, more traditional implementations, Linux systems often stored credential cache files in the /tmp directory. Although the files are locked down and not world-readable, a malicious user with root access to the Linux system could trivially obtain a copy of the Kerberos tickets and reuse them.

On modern versions of Red Hat Enterprise Linux and derivative distributions, the System Security Services Daemon (SSSD) is used to manage Kerberos tickets on domain-joined systems. SSSD implements its own form of Kerberos Cache Manager (KCM) and encrypts tickets within a database on the system. When a user needs access to a TGT or service ticket, the ticket is retrieved from the database, decrypted, and then passed to the remote service (for more on SSSD, check out this great research from Portcullis Labs).

By default, SSSD maintains a copy of the database at the path /var/lib/sss/secrets/secrets.ldb. The corresponding key is stored as a hidden file at the path /var/lib/sss/secrets/.secrets.mkey. By default, the key is only readable if you have root permissions.

If a user is able to extract both of these files, it is possible to decrypt the files offline and obtain valid Kerberos tickets. We have published a new tool called SSSDKCMExtractor that will decrypt relevant secrets in the SSSD database and pull out  the credential cache Kerberos blob. This blob can be converted into a usable Kerberos CCache file that can be passed to other tools, such as Mimikatz, Impacket, and smbclient. CCache files can be converted into Windows format using tools such as Kekeo.

We leave it as an exercise to the reader to convert the decrypted Kerberos blob into a usable credential cache file for pass-the-cache and pass-the-ticket operations.

Using SSSDKCMExtractor is simple. An example SSSD KCM database and key are shown in Figure 2.


Figure 2: SSSD KCM files

Invoking SSSDKCMExtractor with the --database and --key parameters will parse the database and decrypt the secrets as shown in Figure 3.


Figure 3: Extracting Kerberos data

After manipulating the data retrieved, it is possible to use the CCACHE in smbclient as shown in Figure 4. In this example, a domain administrator ticket was obtained and used to access the domain controller’s C$ share.


Figure 4: Compromising domain controller with extracted tickets

The Python script and instructions can be found on the FireEye Github.

Conclusion

By obtaining privileged access to a domain-joined Linux system, it is often possible to scrape Kerberos tickets useful for lateral movement. Although it is still common to find these tickets in the /tmp directory, it is now possible to also scrape these tickets from modern Linux systems that utilize the SSSD KCM.

With the right Kerberos tickets, it is possible to move laterally to the rest of the Active Directory domain. If a privileged user authenticates to a compromised Linux system (such as a Domain Admin) and leaves a ticket behind, it would be possible to steal that user's ticket and obtain privileged rights in the Active Directory domain.

Appendix: Detailed Example of Kerberos Authentication in Active Directory

To illustrate how Kerberos works, we have selected a common scenario where a user John Smith with the account ACMENET.CORP\sa_jsmith wishes to authenticate to a Windows SMB (CIFS) file share in the Acme Corporation domain, hosted on the server SQLSERVER.ACMENET.CORP.

There are two main types of Kerberos ticket types used in Active Directory: Ticket Granting Ticket (TGT) and service tickets. Service tickets are obtained from the Ticket Granting Service (TGS). The TGT is used to authenticate the identity of a particular entity in Active Directory, such as a user account. Service tickets are used to authenticate a user to a specific service hosted on a domain- joined system. A valid TGT can be used to request service tickets from the Key Distribution Center (KDC). In Active Directory environments, the KDC is hosted on a Domain Controller.

When the user wants to authenticate to the remote file share, Windows first checks if a valid TGT is present in memory on the user's workstation. If a TGT isn't present, a new TGT is requested from the Domain Controller in the form of an AS-REQ request. To prevent password cracking attacks (AS-REP Roasting), by default, Kerberos Preauthentication is performed first. Windows creates a timestamp and encrypts the timestamp with the user's Kerberos key (Note: User Kerberos keys vary based on encryption type. In the case of RC4 encryption, the user's RC4 Kerberos key is directly derived from the user's account password. In the case of AES encryption, the user's Kerberos key is derived from the user's password and a salt based on the username and domain name). The domain controller receives the request and decrypts the timestamp by looking up the user's Kerberos key. An example AS-REQ packet is shown in Figure 5.

Figure 5: AS-REQ

Once preauthentication is successful, the Domain Controller issues an AS-REP response packet that contains various metadata fields, the TGT itself, and an "Authenticator". The data within the TGT itself is considered sensitive. If a user could freely modify the content within the TGT, they could impersonate any user in the domain as performed in the Golden Ticket attack. To prevent this from easily occurring, the TGT is encrypted with the long term Kerberos key stored on the Domain Controller. This key is derived from the password of the krbtgt account in Active Directory.

To prevent users from impersonating another user with a stolen TGT blob, Active Directory’s Kerberos implementation uses session keys that are used for mutual authentication between the user, domain, and service. When the TGT is requested, the Domain Controller generates a session key and places it in two places: the TGT itself (which is encrypted with the krbtgt key and unreadable by the end user), and in a separate structure called the Authenticator. The Domain Controller encrypts the Authenticator with the user's personal Kerberos key.

When Windows receives the AS-REP packet back from the domain controller, it caches the TGT ticket data itself into memory. It also decrypts the Authenticator with the user's Kerberos key and obtains a copy of the session key generated by the Domain Controller. Windows stores this session key in memory for future use. At this point, the user's system has a valid TGT that it can use to request service tickets from the domain controller. An example AS-REP packet is shown in Figure 6.

Figure 6: AS-REP

After obtaining a valid TGT for the user, Windows requests a service ticket for the file share service hosted on the remote system SQLSERVER.ACMENET.CORP. The request is made using the service's Service Principal Name (“SPN”). In this case, the SPN would be cifs/SQLSERVER.ACMENET.CORP. Windows builds the service ticket request in a TGS-REQ packet. Within the TGS-REQ packet, Windows places a copy of the TGT previously obtained from the Domain Controller. This time, the Authenticator is encrypted with the TGT session key previously obtained from the domain controller. An example TGS-REQ packet is shown in Figure 7.

Figure 7: TGS-REQ

Once the Domain Controller receives the TGS-REQ packet, it extracts the TGT from the request and decrypts it with the krbtgt Kerberos key. The Domain Controller verifies that the TGT is valid and extracts the session key field from the TGT. The Domain Controller then attempts to decrypt the Authenticator in the TGS-REQ packet with the session key. Once decrypted, the Domain Controller examines the Authenticator and verifies the contents. If this operation succeeds, the user is considered authenticated by the Domain Controller and the requested service ticket is created.

The Domain Controller generates the service ticket requested for cifs/SQLSERVER.ACMENET.CORP. The data within the service ticket is also considered sensitive. If a user could manipulate the service ticket data, they could impersonate any user on the domain to the service as performed in the Silver Ticket attack. To prevent this from easily happening, the Domain Controller encrypts the service ticket with the Kerberos key of the computer the user is authenticating to. All domain-joined computers in Active Directory possess a randomly generated computer account credential that both the computer and Domain Controller are aware of. The Domain Controller also generates a second session key specific to the service ticket and places a copy in both the encrypted service ticket and a new Authenticator structure. This Authenticator is encrypted with the first session key (the TGT session key). The service ticket, Authenticator, and metadata are bundled in a TGS-REP packet and forwarded back to the user. An example TGS-REP packet is shown in Figure 8.

Figure 8: TGS-REP

Once Windows receives the TGS-REP for cifs/SQLSERVER.ACMENET.CORP, Windows extracts the service ticket from the packet and caches it into memory. It also decrypts the Authenticator with the TGT specific session key to obtain the new service specific session key. Using both pieces of information, it is now possible for the user to authenticate to the remote file share. Windows negotiates a SMB connection with SQLSERVER.ACMENET.CORP. It places a Kerberos blob in an "ap-req" structure. This Kerberos blob includes the service ticket received from the domain controller, a new Authenticator structure, and metadata. The new Authenticator is encrypted with the service specific session key that was previously obtained from the Domain Controller. The authentication process is shown in Figure 9.

Figure 9: Authenticating to SMB (AP-REQ)

Once the file share server receives the authentication request, it first extracts and decrypts the service ticket from the Kerberos authentication blob and verifies the data within. It also extracts the service specific session key from the service ticket and attempts to decrypt the Authenticator with it. If this operation succeeds, the user is considered to be authenticated to the service. The server will acknowledge the successful authentication by sending one final Authenticator back to the user, encrypted with the service specific session key. This action completes the mutual authentication process. The response (contained within an “ap-rep” structure) is shown in Figure 10.

Figure 10: Final Authenticator (Mutual Authentication, AP-REP)

A diagram of the authentication flow is shown in Figure 11.

Figure 11: Example Kerberos authentication flow