By Tyler Kline | Research conducted with Nathan Kirk | October 6, 2026
During a recent engagement where the client heavily leveraged macOS, we identified a way to extract Kerberos Ticket Granting Tickets (TGTs) using the built-in kcc utility via an undocumented function. We utilized the kcc utility to copy the TGT from the user's Kerberos Credential Manager (kcm), a daemon managed cache, into a file and convert the TGT via Bifrost into a portable ticket format to be utilized to authenticate as the target user on an attacker-controlled Windows machine equipped with offensive tooling such as Rubeus. This provides a practical credential extraction path after an attacker has already compromised the user's execution context, whether it be from physically accessing the device or via C2 operations.
We submitted the research to Apple on September 14, 2026. Apple responded on September 21 that the copy operation is an intended functionality, and that a user accessing their own tickets does not cross a security boundary.
In the Kerberos authentication protocol, TGTs are small, encrypted blobs of data that are leveraged by users to acquire additional tickets from a Key Distribution Center (KDC). They serve as the fundamental basis for Single Sign-On (SSO) functionality in services such as Active Directory (AD), allowing users to authenticate once rather than providing credentials for every individual network service they wish to access. Enterprise macOS systems leverage TGTs in a similar manner to enterprise Windows systems, allowing users access to corporate resources such as printers, file shares, and the like.
On modern macOS systems, Kerberos TGTs are stored in a secure area of memory using a background user space daemon known as the Kerberos Credential Manager (kcm). The man page for Apple's kcm binary that is designed to interact with the Kerberos Credential Manager is shown below:
The kcm replaces the previous method used for managing TGTs, where they were stored in a file on disk, typically with the prefix "krb5cc" in the filename. By storing TGTs in memory instead of on disk, access is controlled via a secure API, and limited by the System Integrity Protection (SIP) security control. SIP prevents unauthorized processes from accessing TGTs that are stored using kcm. In the screenshot below, an attempt to access a TGT stored using kcm with a custom tool (klist-export) is rejected by the system, because klist-export is not an official, Apple-signed binary:
During our engagement we were investigating how to access Kerberos credentials and whether tickets available to the current user could be extracted for use outside the kcm, much like a tester would in a Windows engagement. After an initial attempt at using a custom exporter, it failed to acquire credentials from the API. This was due to the custom exporter not having the proper Apple signature to run on the system. We started with this approach to test if custom code could be utilized for this task. The failure was worth investigating because the cached ticket was visible through the native macOS klist command as well as in the ticket manager application native to Mac devices. During our research we then found that there is a built in kcc utility, a signed binary provided by Apple that interacts with the kcm to facilitate viewing ticket information for the current user. Within this tool it has the functionality to copy tickets from the secure kcm. The copy operation was also absent from the kcc man page we reviewed. That omission made the behavior less apparent from the manual. Examples of the kcc man page and kcm man pages are shown below.
The credential cache contains more than the encrypted ticket alone. It holds the API in which the cache stores the tickets as well as the user and domain information. For this reason, exporting a usable credential cache has different implications from simply displaying a ticket's principal name or expiration time. The system we used for testing, which is discussed in detail below, used native tools such as klist to display the cache with an API: prefix. macOS has historically used this naming for its native kcm. Moving storage behind a daemon limits access to the cache but does not by itself establish that credentials are not exportable. The question became: how can we access the kcm and export a ticket?
Initial testing and data was collected between December 8 and December 12, 2025, on a MacBook Pro running macOS Tahoe 26.1. We performed follow up testing on September 14, 2026, and confirmed that the technique remained effective on macOS Tahoe 26.6.2. For testing we used a test Active Directory realm, CONTOSO.COM, then configured the Mac to locate the lab KDC through /etc/krb5.conf, and acquired a test TGT using kinit.
The lab authentication configuration was specific to our test environment. The extraction scenario assumes execution as the domain joined user who owns the cache and the presence of a TGT in that cache. Supplying a password to acquire the lab ticket was a setup step. The subsequent export operated on the cached credentials provided by using the kinit command.
We used klist to confirm that the kinit command worked and the test account had a cached TGT. The output showed an API: cache identifier and a krbtgt principal for the lab realm. This established that the source did cache the TGT for the next step.
We then used the undocumented kcc copy command to copy the credentials from the API cache into a file-backed cache. The following example uses a placeholder for the cache identifier.
kcc copy API:<cache-identifier> FILE:/tmp/lab-krb5.cc
The result was the transition from a kcm cache to a file that could be utilized separately. We did not need to supply the test account's password again for this operation.
To inspect and convert the exported credentials, we used Bifrost, directing it to the file backed cache. The output included the TGT and associated session key information, along with a kirbi representation.
The immediate result was a usable export path for a TGT belonging to the affected user. An attacker must already have execution in that user's context, so this technique does not provide the initial foothold. Its significance is what the attacker may be able to take away from that foothold.
During client testing, we successfully transferred an extracted ticket to a separate attacker-controlled machine and used it to authenticate as the affected account. As with the cross-device methodology of extracting Entra PRT tokens, this moves authenticated activity onto an unmanaged endpoint, reducing the organization's endpoint visibility while the activity still appears to originate from a legitimate account. To protect the privacy of our client, screenshots and identifying details are not included.
That outcome demonstrates why ticket export matters operationally. Access is still governed by the account's permissions, ticket validity, and the requirements of the destination environment. Exporting a ticket does not automatically grant privileges beyond those associated with the user whose credentials were extracted.
The following recommendations address the exposure demonstrated by the research. They are defensive measures to evaluate in the environment, rather than a vendor issued fix for kcc.
Consider monitoring use of kcc that copies credentials into file backed caches, particularly when it follows unusual shell or remote execution activity. Investigate the account, parent process, destination path, and surrounding authentication activity before drawing a conclusion. Legitimate credential management workflows should inform any detection logic.
Review which accounts are acquiring Kerberos tickets on standard workstations and whether privileged credentials are necessary for those workflows. The impact of an exported credential depends heavily on what the account can access. Separating administrative activity from routine work can reduce the consequences of a workstation compromise.
When investigating execution as a user with Kerberos credentials, consider whether tickets may have been exported. Coordinate the response with the identity team, examine authentication from unexpected systems, and verify how existing tickets are handled in the affected environment. Removing the exported file from the original Mac does not remove copies that have already been transferred elsewhere.
Use a dedicated test account to evaluate export, off device authentication, and the visibility available to defenders. Document ticket lifetime, account permissions, network access, and any authentication restrictions that affect the result. This produces evidence of the actual exposure in the tested environment and a way to assess defensive changes.
This research shows that kcc can assist in exporting credentials from the current user's native API Kerberos cache into a file backed cache. The lab walkthrough documents extraction and conversion, while Apple's response establishes its position that the operation is intended functionality. We disagree, because the fundamental purpose of a kcm is to limit the ability to extract TGTs from memory, given the effect of using a TGT on an attacker-controlled box that has access to offensive tooling.
For an assessment, the useful question is what an attacker can do with the credentials after gaining execution as a user. Our testing illustrates why a kcm should not be assumed to make those credentials impossible to extract and use elsewhere. Understanding that behavior helps testers describe the impact accurately and gives defenders a concrete workflow to evaluate.
[1] MIT Kerberos Documentation. Credential cache. https://web.mit.edu/kerberos/krb5-latest/doc/basic/ccache_def.html
[2] MIT Kerberos K5Wiki. Projects/KCM client. Historical implementation background. https://k5wiki.kerberos.org/wiki/Projects/KCM_client
