Kerberos Tickets on Linux Red Teams

Read the original article: 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:

The user requests a Ticket Granting Ticket (TGT) from the
Domain Controller.
Once granted, the user passes the TGT
back to the Domain Controller and requests a service ticket for
cifs/SQLSERVER.ACMENET.CORP.
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.
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.
The server
validates the service ticket and authenticates the user.
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

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,
Aut

[…]