[FireEye]Kerberos Tickets on Linux Red Teams

[igor51]

Kerberos Tickets on Linux Red Teams

At     href="/content/fireeye-www/en_US/mandiant/incident-response.html">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     href="https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/2a32282e-dd48-4ad9-a542-609804b02cc9">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.

 
   
     

src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/kerberostickets/Picture1.png"       alt="" />

 

  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     href="https://labs.portcullis.co.uk/presentations/where-2-worlds-collide-bringing-mimikatz-et-al-to-unix/#more-6806">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   href="https://github.com/fireeye/SSSDKCMExtractor">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,   href="https://github.com/SecureAuthCorp/impacket">Impacket, and   href="https://www.samba.org/samba/docs/current/man-html/smbclient.1.html">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.

 

      src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/kerberostickets/Picture2.png" alt="" />
 
 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.

 

      src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/kerberostickets/Picture3.png" alt="" />
 
 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.

 

      src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/kerberostickets/Picture4.png" alt="" />
 
 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 (    href="https://www.harmj0y.net/blog/activedirectory/roasting-as-reps/">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.

 
   
     

src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/kerberostickets/Picture5.png"       alt="" />

 

  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     href="https://adsecurity.org/?p=1515">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.

 
   
     

src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/kerberostickets/Picture6.png"       alt="" />

 

  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.

 
   
     

src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/kerberostickets/Picture7.png"       alt="" />

 

  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     href="https://adsecurity.org/?p=1515">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.

 
   
     

src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/kerberostickets/Picture8.png"       alt="" />

 

  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.

 
   
     

src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/kerberostickets/Picture9.png"       alt="" />

 

  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.

 
   
     

src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/kerberostickets/Picture10.png"       alt="" />

 

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

 

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

 
   
     

src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/kerberostickets/Picture11.png"       alt="" />

 

  Figure 11: Example Kerberos authentication flow

Source: Kerberos Tickets on Linux Red Teams