Linux Active Directory
Theory
Linux systems can be integrated into an Active Directory environment in several different ways. The most common stacks are:
realmdfor joining the host to the domainsssdfor identity, authentication, and cache managementSamba / Winbind for SMB integration and AD-aware name and auth handling
Kerberos client utilities such as
kinit,klist, andlibkrb5host and service keytabs such as
/etc/krb5.keytab
These components solve different problems, and each one may create different credential artifacts worth looting.
realmd
realmd is usually the onboarding layer. It helps a Linux host join an AD domain and writes the configuration needed for tools such as sssd or Samba to use the domain.
realmd is not usually the credential source you loot directly, but it is useful because it confirms that the machine is domain-joined, helps reveal which backend was chosen for integration, and shows where to pivot next for secrets, caches, and key material.
sssd
sssd stands for System Security Services Daemon. In AD-backed Linux environments it commonly handles user lookup, identity resolution, domain authentication, offline credential caching, policy caching, and Kerberos cache management through KCM. From an exploitation perspective, sssd matters because it can centralize sensitive material under /var/lib/sss/, including secret databases and Kerberos-related cache data that may not appear as ordinary files in /tmp.
Samba
Samba is the Linux implementation of SMB/CIFS and several Microsoft-compatible directory and authentication components. In AD environments, Samba may be used in two very different roles:
as a member server integrated into an existing Windows AD
as a Samba AD Domain Controller storing directory data locally
This distinction is critical because on a member server you are mostly interested in local machine secrets and integration artifacts, while on a Samba AD DC local compromise can expose domain directory data and have DC-level impact.
Winbind
winbindd is Samba's AD-aware identity and authentication service. It maps domain users and groups to the local UNIX system and helps the host interact with AD identities.
From an operator perspective, Winbind is useful because it shows that the host is AD-aware even if sssd is not used, that Samba private directories may contain useful machine-account material, and that SMB-oriented integration paths may be more relevant than SSSD-specific ones.
Keytabs
A keytab is a file containing Kerberos keys for a host or service principal. It is the Kerberos equivalent of storing a reusable secret for non-interactive authentication.
From an exploitation perspective, a keytab may allow requesting a TGT as the host or service, authenticating to Kerberos-aware services without a password prompt, or extracting key material that can sometimes be transformed into reusable credentials.
From a post-exploitation perspective, this matters because the credential material is not stored in a single place. Depending on the integration stack, a compromised Linux host may expose:
Kerberos ticket caches for logged-in users or services
host and service keytabs
SSSD-managed secret databases
Samba private databases with machine-account or trust-related secrets
directory data if the Linux host is running as a Samba AD Domain ControllerIn other words, do not limit triage to
/tmp/krb5cc_*. A Linux host joined to AD can hold user-scoped, service-scoped, and host-scoped authentication material.
Practice
Tip: convert ticket to UNIX <-> Windows format
To convert tickets between UNIX/Windows format with ticketConverter.py.
Tools
linikatz is a tool to attack AD on UNIX. It allow you to dump credentials and kerberos cached tickets.
KrbNixPwn is useful when you want a single workflow to target several Linux Kerberos cache backends. It is relevant when tickets may be stored as FILE, DIR, KEYRING, or KCM.
CCACHE ticket reuse from /tmp
Kerberos tickets are often stored in file-backed CCACHE files. These caches are usually tied to a specific user session, but if you can read the file you can often reuse the ticket without knowing the user's password.
These files are commonly stored in /tmp with permissions such as 600, and the ticket name often follows the format krb5cc_%{uid}.
List the current ticket used for authentication with env | grep KRB5CCNAME. The format is portable and the ticket can be reused by setting the environment variable with export KRB5CCNAME=/tmp/ticket.ccache.
You may use this ticket using Pass The Ticket techniques
CCACHE ticket reuse from DIR caches
Some Linux systems use a directory-backed cache instead of a single krb5cc_* file. In that configuration, the cache name may point to a directory that contains multiple ticket cache entries.
This matters because a quick search for /tmp/krb5cc_* may miss all valid Kerberos material.
Look for DIR: values in environment variables and Kerberos configuration, then inspect the target directory.
If the cache name resolves to a DIR: backend, inspect the directory contents and point KRB5CCNAME to the correct cache target.
CCACHE ticket reuse from keyring
Some Linux systems store Kerberos tickets in a kernel keyring-backed cache instead of a plain file. In that case, there may be no obvious krb5cc_* file even though the host is actively using Kerberos.
Processes may store kerberos tickets inside their memory, the tickey tool can be useful to extract those tickets
ptrace protection should be disabled in the machine /proc/sys/kernel/yama/ptrace_scope = 0
CCACHE ticket reuse from SSSD KCM (Kerberos Cache Manager)
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.
Invoking SSSDKCMExtractor with the --database and --key parameters will parse the database and decrypt the secrets.
Extract Accounts From Keytab Files
The service keys used by services that run as root are usually stored in the keytab file /etc/krb5.keytab. This service key is the equivalent of the service's password, and must be kept secure.
On Linux you can use KeyTabExtract to extracts Key values from .keytab files
You can also use the .keytab file to request a TGT directly.
References
Last updated