General Introduction to Kerberos on Linux
Kerberos is a well-known option for authentication on Windows networks,
but it can also be used on Linux networks using Linux-specific
Key Distribution Center servers.
Alternatively, Linux clients can authenticate to Active Directory servers via Kerberos
just as a Windows machine would.
Let’s explore this scenario in this section.
As before, we’ll begin by demonstrating standard Kerberos usage.
This demonstration will help us understand potential exploits.
In our lab setup, the linuxvictim lab machine is domain joined to corp1.com.
Active Directory users can log in to the linuxvictim machine with their
Active Directory credentials.
Let’s imagine a scenario in which the corp1.com domain admin
logs in to our linuxvictim host using their AD password.
In order to use Kerberos, the administrator
can log in to the system using their AD credentials
and then request Kerberos tickets.
Although a Domain Administrator would likely be doing these actions
from a Windows machine,
for simplicity, we will log in to the linuxvictim system
from our Kali VM.
Active Directory members using Kerberos authentication
are assigned a credential cache file
which contains their requested Kerberos tickets.
The file’s location is set through an environment variable.
In the linuxvictim VM, we can find the administrator’s credential cache file
by examining the list of environment variables
with env and filtering out the one we want with grep.
We’ll make a note of this credential cache file location for later use.
Kerberos tickets expire after a period of time.
As a result, in order to practice exploiting them,
we’ll walk through how to request them from the server
using an Active Directory account.
We will use the kinit[^kinit] command, which is used to acquire a
Kerberos ticket-granting ticket for the current user.
To request a TGT, we just need to call kinit without parameters
and enter the user’s AD password.
The klist command is used to list tickets
currently stored in the user’s credential cache file.
If we run it,
we find that we now have our TGT set in the Administrator user’s credential cache.
This means we have a ticket-granting ticket
for the Administrator user of the CORP1 domain.
We can now access Kerberos services as the domain administrator.
We can get a list of available Service Principal Names,
from the domain controller using ldapsearch
with the -Y GSSAPI parameter to force it to use Kerberos authentication.
This command may ask for an LDAP password,
but if we just hit enter at the prompt, it will continue
and use Kerberos for authentication.
Let’s request a service ticket from Kerberos for the MSSQL SPN.
We can do this using the kvno utility.
Our ticket should now be in our credential cache.
We’ll again use klist for confirmation.
We can now access the MSSQL service and perform authenticated actions.
Now that we’ve covered how Kerberos works in legitimate scenarios,
let’s discuss a few attack vectors.