{
	"id": "0dff8c15-a77b-4b8a-872a-bd212a83c76f",
	"created_at": "2026-04-06T02:12:30.955303Z",
	"updated_at": "2026-04-10T03:21:17.782562Z",
	"deleted_at": null,
	"sha1_hash": "13ff765aaa58f033ca954a14463a2c4c1d020aad",
	"title": "Kerberos Tickets on Linux Red Teams | Mandiant",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2853969,
	"plain_text": "Kerberos Tickets on Linux Red Teams | Mandiant\r\nBy Mandiant\r\nPublished: 2020-04-01 · Archived: 2026-04-06 02:04:37 UTC\r\nWritten by: Trevor Haskell\r\nAt FireEye Mandiant, we conduct numerous red team engagements within Windows Active Directory\r\nenvironments. Consequently, we frequently encounter Linux systems integrated within Active Directory\r\nenvironments. Compromising an individual domain-joined Linux system can provide useful data on its own, but\r\nthe best value is obtaining data, such as Kerberos tickets, that will facilitate lateral movement techniques. By\r\npassing these Kerberos Tickets from a Linux system, it is possible to move laterally from a compromised Linux\r\nsystem to the rest of the Active Directory domain.\r\nThere are several ways to configure a Linux system to store Kerberos tickets. In this blog post, we will introduce\r\nKerberos and cover some of the various storage solutions. We will also introduce a new tool that extracts Kerberos\r\ntickets from domain-joined systems that utilize the System Security Services Daemon Kerberos Cache Manager\r\n(SSSD KCM).\r\nWhat is Kerberos\r\nKerberos is a standardized authentication protocol that was originally created by MIT in the 1980s. The protocol\r\nhas evolved over time. Today, Kerberos Version 5 is implemented by numerous products, including Microsoft\r\nActive Directory. Kerberos was originally designed to mutually authenticate identities over an unsecured\r\ncommunication line.\r\nThe Microsoft implementation of Kerberos is used in Active Directory environments to securely authenticate\r\nusers to various services, such as the domain (LDAP), database servers (MSSQL) and file shares (SMB/CIFS).\r\nWhile other authentication protocols exist within Active Directory, Kerberos is one of the most popular methods.\r\nTechnical documentation on how Microsoft implemented Kerberos Protocol Extensions within Active Directory\r\ncan be found in the MS-KILE standards published on MSDN.\r\nShort Example of Kerberos Authentication in Active Directory\r\nTo illustrate how Kerberos works, we have selected a common scenario where a user John Smith with the account\r\nACMENET.CORP\\sa_jsmith wishes to authenticate to a Windows SMB (CIFS) file share in the Acme\r\nCorporation domain, hosted on the server SQLSERVER.ACMENET.CORP.\r\nThere are two main types of Kerberos tickets used in Active Directory: Ticket Granting Ticket (TGT) and service\r\ntickets. Service tickets are obtained from the Ticket Granting Service (TGS). The TGT is used to authenticate the\r\nidentity of a particular entity in Active Directory, such as a user account. Service tickets are used to authenticate a\r\nhttps://www.fireeye.com/blog/threat-research/2020/04/kerberos-tickets-on-linux-red-teams.html\r\nPage 1 of 12\n\nuser to a specific service hosted on a system. A valid TGT can be used to request service tickets from the Key\r\nDistribution Center (KDC). In Active Directory environments, the KDC is hosted on a Domain Controller.\r\nThe diagram in Figure 1 shows the authentication flow.\r\nFigure 1: Example Kerberos authentication flow\r\nIn summary:\r\n1. The user requests a Ticket Granting Ticket (TGT) from the Domain Controller.\r\n2. Once granted, the user passes the TGT back to the Domain Controller and requests a service ticket for\r\ncifs/SQLSERVER.ACMENET.CORP.\r\n3. After the Domain Controller validates the request, a service ticket is issued that will authenticate the user to\r\nthe CIFS (SMB) service on SQLSERVER.ACMENET.CORP.\r\n4. The user receives the service ticket from the Domain Controller and initiates an SMB negotiation with\r\nSQLSERVER.ACMENET.CORP. During the authentication process, the user provides a Kerberos blob\r\ninside an “AP-REQ” structure that includes the service ticket previously obtained.\r\n5. The server validates the service ticket and authenticates the user.\r\n6. If the server determines that the user has permissions to access the share, the user can begin making SMB\r\nqueries.\r\nFor an in-depth example of how Kerberos authentication works, scroll down to view the appendix at the bottom of\r\nthis article.\r\nKerberos On Linux Domain-Joined Systems\r\nhttps://www.fireeye.com/blog/threat-research/2020/04/kerberos-tickets-on-linux-red-teams.html\r\nPage 2 of 12\n\nWhen a Linux system is joined to an Active Directory domain, it also needs to use Kerberos tickets to access\r\nservices on the Windows Active Directory domain. Linux uses a different Kerberos implementation. Instead of\r\nWindows formatted tickets (commonly referred to as the KIRBI format), Linux uses MIT format Kerberos\r\nCredential Caches (CCACHE files).\r\nWhen a user on a Linux system wants to access a remote service with Kerberos, such as a file share, the same\r\nprocedure is used to request the TGT and corresponding service ticket. In older, more traditional implementations,\r\nLinux systems often stored credential cache files in the /tmp directory. Although the files are locked down and not\r\nworld-readable, a malicious user with root access to the Linux system could trivially obtain a copy of the Kerberos\r\ntickets and reuse them.\r\nOn modern versions of Red Hat Enterprise Linux and derivative distributions, the System Security Services\r\nDaemon (SSSD) is used to manage Kerberos tickets on domain-joined systems. SSSD implements its own form of\r\nKerberos Cache Manager (KCM) and encrypts tickets within a database on the system. When a user needs access\r\nto a TGT or service ticket, the ticket is retrieved from the database, decrypted, and then passed to the remote\r\nservice (for more on SSSD, check out this great research from Portcullis Labs).\r\nBy default, SSSD maintains a copy of the database at the path /var/lib/sss/secrets/secrets.ldb. The corresponding\r\nkey is stored as a hidden file at the path /var/lib/sss/secrets/.secrets.mkey. By default, the key is only readable if\r\nyou have root permissions.\r\nIf a user is able to extract both of these files, it is possible to decrypt the files offline and obtain valid Kerberos\r\ntickets. We have published a new tool called SSSDKCMExtractor that will decrypt relevant secrets in the SSSD\r\ndatabase and pull out the credential cache Kerberos blob. This blob can be converted into a usable Kerberos\r\nCCache file that can be passed to other tools, such as Mimikatz, Impacket, and smbclient. CCache files can be\r\nconverted into Windows format using tools such as Kekeo.\r\nWe leave it as an exercise to the reader to convert the decrypted Kerberos blob into a usable credential cache file\r\nfor pass-the-cache and pass-the-ticket operations.\r\nUsing SSSDKCMExtractor is simple. An example SSSD KCM database and key are shown in Figure 2.\r\nhttps://www.fireeye.com/blog/threat-research/2020/04/kerberos-tickets-on-linux-red-teams.html\r\nPage 3 of 12\n\nFigure 2: SSSD KCM files\r\nInvoking SSSDKCMExtractor with the --database and --key parameters will parse the database and decrypt the\r\nsecrets as shown in Figure 3.\r\nhttps://www.fireeye.com/blog/threat-research/2020/04/kerberos-tickets-on-linux-red-teams.html\r\nPage 4 of 12\n\nFigure 3: Extracting Kerberos data\r\nAfter manipulating the data retrieved, it is possible to use the CCACHE in smbclient as shown in Figure 4. In this\r\nexample, a domain administrator ticket was obtained and used to access the domain controller’s C$ share.\r\nFigure 4: Compromising domain controller with extracted tickets\r\nThe Python script and instructions can be found on the FireEye Github.\r\nConclusion\r\nBy obtaining privileged access to a domain-joined Linux system, it is often possible to scrape Kerberos tickets\r\nuseful for lateral movement. Although it is still common to find these tickets in the /tmp directory, it is now\r\npossible to also scrape these tickets from modern Linux systems that utilize the SSSD KCM.\r\nWith the right Kerberos tickets, it is possible to move laterally to the rest of the Active Directory domain. If a\r\nprivileged user authenticates to a compromised Linux system (such as a Domain Admin) and leaves a ticket\r\nbehind, it would be possible to steal that user's ticket and obtain privileged rights in the Active Directory domain.\r\nAppendix: Detailed Example of Kerberos Authentication in Active Directory\r\nhttps://www.fireeye.com/blog/threat-research/2020/04/kerberos-tickets-on-linux-red-teams.html\r\nPage 5 of 12\n\nTo illustrate how Kerberos works, we have selected a common scenario where a user John Smith with the account\r\nACMENET.CORP\\sa_jsmith wishes to authenticate to a Windows SMB (CIFS) file share in the Acme\r\nCorporation domain, hosted on the server SQLSERVER.ACMENET.CORP.\r\nThere are two main types of Kerberos ticket types used in Active Directory: Ticket Granting Ticket (TGT) and\r\nservice tickets. Service tickets are obtained from the Ticket Granting Service (TGS). The TGT is used to\r\nauthenticate the identity of a particular entity in Active Directory, such as a user account. Service tickets are used\r\nto authenticate a user to a specific service hosted on a domain- joined system. A valid TGT can be used to request\r\nservice tickets from the Key Distribution Center (KDC). In Active Directory environments, the KDC is hosted on\r\na Domain Controller.\r\nWhen the user wants to authenticate to the remote file share, Windows first checks if a valid TGT is present in\r\nmemory on the user's workstation. If a TGT isn't present, a new TGT is requested from the Domain Controller in\r\nthe form of an AS-REQ request. To prevent password cracking attacks AS-REP Roasting, by default, Kerberos\r\nPreauthentication is performed first. Windows creates a timestamp and encrypts the timestamp with the user's\r\nKerberos key (Note: User Kerberos keys vary based on encryption type. In the case of RC4 encryption, the user's\r\nRC4 Kerberos key is directly derived from the user's account password. In the case of AES encryption, the user's\r\nKerberos key is derived from the user's password and a salt based on the username and domain name). The\r\ndomain controller receives the request and decrypts the timestamp by looking up the user's Kerberos key. An\r\nexample AS-REQ packet is shown in Figure 5.\r\nFigure 5: AS-REQ\r\nOnce preauthentication is successful, the Domain Controller issues an AS-REP response packet that contains\r\nvarious metadata fields, the TGT itself, and an \"Authenticator\". The data within the TGT itself is considered\r\nsensitive. If a user could freely modify the content within the TGT, they could impersonate any user in the domain\r\nhttps://www.fireeye.com/blog/threat-research/2020/04/kerberos-tickets-on-linux-red-teams.html\r\nPage 6 of 12\n\nas performed in the Golden Ticket attack. To prevent this from easily occurring, the TGT is encrypted with the\r\nlong term Kerberos key stored on the Domain Controller. This key is derived from the password of the krbtgt\r\naccount in Active Directory.\r\nTo prevent users from impersonating another user with a stolen TGT blob, Active Directory’s Kerberos\r\nimplementation uses session keys that are used for mutual authentication between the user, domain, and service.\r\nWhen the TGT is requested, the Domain Controller generates a session key and places it in two places: the TGT\r\nitself (which is encrypted with the krbtgt key and unreadable by the end user), and in a separate structure called\r\nthe Authenticator. The Domain Controller encrypts the Authenticator with the user's personal Kerberos key.\r\nWhen Windows receives the AS-REP packet back from the domain controller, it caches the TGT ticket data itself\r\ninto memory. It also decrypts the Authenticator with the user's Kerberos key and obtains a copy of the session key\r\ngenerated by the Domain Controller. Windows stores this session key in memory for future use. At this point, the\r\nuser's system has a valid TGT that it can use to request service tickets from the domain controller. An example\r\nAS-REP packet is shown in Figure 6.\r\nFigure 6: AS-REP\r\nAfter obtaining a valid TGT for the user, Windows requests a service ticket for the file share service hosted on the\r\nremote system SQLSERVER.ACMENET.CORP. The request is made using the service's Service Principal Name\r\n(“SPN”). In this case, the SPN would be cifs/SQLSERVER.ACMENET.CORP. Windows builds the service ticket\r\nrequest in a TGS-REQ packet. Within the TGS-REQ packet, Windows places a copy of the TGT previously\r\nhttps://www.fireeye.com/blog/threat-research/2020/04/kerberos-tickets-on-linux-red-teams.html\r\nPage 7 of 12\n\nobtained from the Domain Controller. This time, the Authenticator is encrypted with the TGT session key\r\npreviously obtained from the domain controller. An example TGS-REQ packet is shown in Figure 7.\r\nFigure 7: TGS-REQ\r\nOnce the Domain Controller receives the TGS-REQ packet, it extracts the TGT from the request and decrypts it\r\nwith the krbtgt Kerberos key. The Domain Controller verifies that the TGT is valid and extracts the session key\r\nfield from the TGT. The Domain Controller then attempts to decrypt the Authenticator in the TGS-REQ packet\r\nwith the session key. Once decrypted, the Domain Controller examines the Authenticator and verifies the contents.\r\nIf this operation succeeds, the user is considered authenticated by the Domain Controller and the requested service\r\nticket is created.\r\nThe Domain Controller generates the service ticket requested for cifs/SQLSERVER.ACMENET.CORP. The data\r\nwithin the service ticket is also considered sensitive. If a user could manipulate the service ticket data, they could\r\nimpersonate any user on the domain to the service as performed in the Silver Ticket attack. To prevent this from\r\neasily happening, the Domain Controller encrypts the service ticket with the Kerberos key of the computer the\r\nuser is authenticating to. All domain-joined computers in Active Directory possess a randomly generated computer\r\naccount credential that both the computer and Domain Controller are aware of. The Domain Controller also\r\ngenerates a second session key specific to the service ticket and places a copy in both the encrypted service ticket\r\nand a new Authenticator structure. This Authenticator is encrypted with the first session key (the TGT session\r\nkey). The service ticket, Authenticator, and metadata are bundled in a TGS-REP packet and forwarded back to the\r\nuser. An example TGS-REP packet is shown in Figure 8.\r\nhttps://www.fireeye.com/blog/threat-research/2020/04/kerberos-tickets-on-linux-red-teams.html\r\nPage 8 of 12\n\nFigure 8: TGS-REP\r\nOnce Windows receives the TGS-REP for cifs/SQLSERVER.ACMENET.CORP, Windows extracts the service\r\nticket from the packet and caches it into memory. It also decrypts the Authenticator with the TGT specific session\r\nkey to obtain the new service specific session key. Using both pieces of information, it is now possible for the user\r\nto authenticate to the remote file share. Windows negotiates a SMB connection with\r\nSQLSERVER.ACMENET.CORP. It places a Kerberos blob in an \"ap-req\" structure. This Kerberos blob includes\r\nthe service ticket received from the domain controller, a new Authenticator structure, and metadata. The new\r\nAuthenticator is encrypted with the service specific session key that was previously obtained from the Domain\r\nController. The authentication process is shown in Figure 9.\r\nhttps://www.fireeye.com/blog/threat-research/2020/04/kerberos-tickets-on-linux-red-teams.html\r\nPage 9 of 12\n\nFigure 9: Authenticating to SMB (AP-REQ)\r\nOnce the file share server receives the authentication request, it first extracts and decrypts the service ticket from\r\nthe Kerberos authentication blob and verifies the data within. It also extracts the service specific session key from\r\nthe service ticket and attempts to decrypt the Authenticator with it. If this operation succeeds, the user is\r\nconsidered to be authenticated to the service. The server will acknowledge the successful authentication by\r\nsending one final Authenticator back to the user, encrypted with the service specific session key. This action\r\ncompletes the mutual authentication process. The response (contained within an “ap-rep” structure) is shown in\r\nFigure 10.\r\nhttps://www.fireeye.com/blog/threat-research/2020/04/kerberos-tickets-on-linux-red-teams.html\r\nPage 10 of 12\n\nFigure 10: Final Authenticator (Mutual Authentication, AP-REP)\r\nA diagram of the authentication flow is shown in Figure 11\r\nFigure 11: Example Kerberos authentication flow\r\nPosted in\r\nThreat Intelligence\r\nSecurity \u0026 Identity\r\nhttps://www.fireeye.com/blog/threat-research/2020/04/kerberos-tickets-on-linux-red-teams.html\r\nPage 11 of 12\n\nSource: https://www.fireeye.com/blog/threat-research/2020/04/kerberos-tickets-on-linux-red-teams.html\r\nhttps://www.fireeye.com/blog/threat-research/2020/04/kerberos-tickets-on-linux-red-teams.html\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.fireeye.com/blog/threat-research/2020/04/kerberos-tickets-on-linux-red-teams.html"
	],
	"report_names": [
		"kerberos-tickets-on-linux-red-teams.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775441550,
	"ts_updated_at": 1775791277,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/13ff765aaa58f033ca954a14463a2c4c1d020aad.pdf",
		"text": "https://archive.orkl.eu/13ff765aaa58f033ca954a14463a2c4c1d020aad.txt",
		"img": "https://archive.orkl.eu/13ff765aaa58f033ca954a14463a2c4c1d020aad.jpg"
	}
}