Kerberos
after AD users log in to the victim linux machine with AD credentials
Last updated
after AD users log in to the victim linux machine with AD credentials
Last updated
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:
Request service ticket (from listed SPN): kvno MSSQLSvc/DC01.corp1.com:1433
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.
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.
check with last to see if other user logined to the machine
then echo {kali id_rsa} >> /home/theuser/.ssh/authorized_keys
ssh into that account to view its /tmp/krb5cc and copy it out to kali
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.
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.
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.
kvno ldap/dmzdc01.complyedge.com@COMPLYEDGE.COM
need ldap ticket before bloodhound collection
