Kerberos does not only live on Windows domain controllers. Linux and macOS hosts joined to a realm keep tickets in a credential cache, and anything that can read the cache can borrow the identity. Ccache Files (T1558.005) is a Credential Access technique for Linux and macOS, a subtechnique of Steal or Forge Kerberos Tickets.
How attackers use it
MITRE explains that ccache files hold a user's active session credentials for short-term use. The cache is created at authentication and lets the user reach many services without typing a password again.
The location is set by the /etc/krb5.conf configuration file and the KRB5CCNAME environment variable. On Linux, credentials are typically in the /tmp directory, named krb5cc_ followed by the user ID, or krb5.ccache. On macOS, entries are stored in memory by default with an API-prefixed naming scheme. Users work with them through kinit, which obtains a ticket-granting ticket, and klist, which lists tickets in the cache.
An adversary who collects tickets from ccache files can authenticate as the current user without the password, a Pass the Ticket attack, and may use them to impersonate users with elevated privileges. MITRE says tools like Kekeo can convert ccache files to Windows format for further lateral movement, and that on macOS, open-source tools or the Kerberos framework can extract tickets through lower-level APIs.
How to detect it
MITRE's analytics cover both platforms:
- On Linux, unauthorized access, copying or modification of ccache files in
/tmpor custom paths set byKRB5CCNAME, correlated with suspicious processes and with unusual Kerberos authentication from non-standard processes. - On macOS, abnormal interaction with the memory-based cache, and processes trying to enumerate or extract tickets outside built-in utilities.
How to reduce the risk
MITRE lists two mitigations.
- Audit. Use
auditdto audit access to hashes, machine tickets and/tmpfiles. If you use sssd and Vintela, make sure Kerberos is disabled when it is not in use. - Credential access protection. Protect resources with SELinux by defining entry points, process types and file labels.
Why a file in the temp folder matters
On Linux, the default cache location in a temporary directory is convenient and risky. Anything running as the same user can read it, and so can root. That is the nature of the credential cache: it is designed to be used by the logged-in user's programs without asking for a password. An adversary who runs code as that user, or as root, has the same access.
So the controls are about narrowing who can run code as that user, and about watching access. Short ticket lifetimes limit how long a stolen cache stays useful. Keeping the cache in a protected location is possible through configuration, and SELinux labels, as MITRE suggests, restrict which processes can touch the files.
On macOS the cache lives in memory by default, which removes the file but not the risk. MITRE says adversaries can use open-source tools or the Kerberos framework to extract tickets through lower-level APIs. Detection there depends on process behavior, not file access.
Check your own environment
These are read-only.
# Linux or macOS: where does this session keep its cache, and what is in it?
echo $KRB5CCNAME
klist
# Linux: list cache files and their owners and modes
ls -l /tmp/krb5cc_*
# Linux: show loaded audit rules (as root)
auditctl -l
Cache files should be readable only by their owner. Check that your audit rules cover the cache path, and that nobody has pointed KRB5CCNAME at a shared directory.
Secrets can leak in other ways too, such as keys and tokens committed to code. The demo below walks through how that kind of exposure gets found.
Click through it at your own pace, or open it full screen.
Quick check
What permissions should a ccache file have?
Owner-only access. A cache readable by other users or processes lets them replay its tickets as that user.
