Playing with Kerberos, Kerberoasting, Kinit, Ticket Granting Ticket (TGT)

There has been a number of technical blog posts, demonstrations  about Kerberoasting/SPNs and how widely abused attack vector against windows enterprise network infrastructure (AD) i will try to minimize background info on SPNs and kerberoating as much as possible and provide links at the end to all that i know about.

My focus on this post is to demonstrate how to perform all your attack on a Linux OS as opposed to windows based operating system, the advantages with this approach is your attacking system do not require to be domain joined, all you need is basic (AD) username and password to perform a successful attack.

Attack advantages:

  • Linux OS as attacking machine
  • No windows domain join hassle and permissions etc
  • Can use majority of red team and penetration tools
  • Stealth avoid detection specify DC IP address and the user authenticate with.

Figure 1  List Services Accounts IIS_003 and IIS_002 assigned to servers.   -request parameter and the DC IP address to request Kerb TGT service tickets.


Figure 2  -request parameter to capture kerberos ticket granting ticket on IIS_002, IIS_003 in hashcat format.

Hashcat password cracking tool to crack the TGT response on the IIS_002 and IIS_003 service accounts.   (Hashcat -m  130100  tgtkerberosticket.txt  dictionaryword.txt)


Figure 3  IIS_002 TGT Response ticket password successfully cracked.

Now that we know the domain controller FQDN we send 2 pings to the host.


Figure 4  sec-pr1-01 DC Netbios name identified.

In order to reduce and avoid detection (Red team)  in the target network we can utilize the use of Heimdal implementation of Kerberos 5 client to receive valid TGT session ticket and use Kerberos post exploitation as opposed password equivalent NTLM hash. The idea is to blend in to the target network and reduce the risk of been identified by security operation team (SOC) and security conscious system administrators.

Steps to configure Heimdal clients on Linux OS:

Vi /etc/krb5.conf 

  • default_relam set that  to a target domain controller CRYPTOAMBIENT.COM
  •  realms set that to a target KDC to Fully qualified domain controller e.g. my target domain controller is set to and the admin_server and default_domain to FQDN target server.


Figure 5 Heimdal Krb5 client configuration

We also must add the following entries in to the /etc/resolv.conf and point our nameserver to the domain controller. Almost 99% of time DNS is the root cause of kerberos authentications problems/issue. “My own personal experience”


Figure 6 resolve configuration file added with the target domain entries.

Kinit obtains and caches an initial ticket-granting ticket for ambientuser and klist is used to list the valid ticket issued by domain controller KRBTGT. Armed with valid TGT ticket we can tools from our Linux attacking machine and interact with accessible hosts within the domain controller forest.


Figure 7 TGT Ticket Granting Ticket for valid ambientuser received.

smbclient with –kerberos flag to use ambinetuser ticket to authenticate a hosts IPC$.


Figure 8 smbclient to use kerberos ticket as opposed to traditional clear text/NTLM authentication hash.

rpcclient  -k flag is to use kerberos to authenticate windows host joined domain forest.


Figure 9 rpclient can be used to enumerate SID,RID Password policy etc.

wmiexec with -k flag and –nopass used to gain remote shell against the domain joined host using kerberos ticket – user must be part of local admin or domain admin group to be able spawn a cmd.exe process. WMI is still widely used/abused and difficult challenge for good guys to identify slow planned WMI attack.


Figure 10 wmiexec to gain remote administrative level shell on the target host.

psexec i will not and never will use it in real engagement but just for demonstration  i thought it’s a good idea to show different attack tool(s) that supports kerberos to interact with target domain joined hosts.


Figure 11 psexe to gain code execution with the SYSTEM privilege the disadvantages with psexec creates a service executable, writes to a share and finally execute/start the service.

Moral of the story:  Kerberos is the way to go in a locked down enterprise network to avoid detection and operate without the use of NTLM hash in windows environment.


  • Use Group managed security groups for service accounts
  • Use 28 or more password character for service accounts
  • Make sure service accounts are not delegated rights to domain admin or any other groups in fact.
  • Monitor and enable kerberos auditing
  • Investigate incidents do not just assume


What is SPNs


Hemidal Kerberos

Windows Service Privilege Escalation

Now you have gained initial foot hold on the network and you almost certain the end user is low privilege user. Yes, you need to elevate the privilege to local administrator or maybe to system level or if you in luck domain admin.

So what we talk about here you may ask? Privilege escalation; a privilege escalation happens when a low level user requires access to a user or a service to increase privilege on compromised workstation/server etc.

Hacker thoughts and Post exploitation Assumptions:

  • Initial intrusion could start from anywhere, a phishing attack, a guest account a local authenticated user?
  • Living of the land, build in windows tools such as windows binary and PowerShell to come rescue?
  • Windows Services & Third party applications leverage and exploit it to our advantage and escalate low user to admin and or system.
  • Exploiting Weak Folder Permissions and mount and redirect  folder.
  • Classic dll hijacking and gain elevated privilege.

Steps to exploit weak services and binary implants

Assume we compromised an end user windows 10 fully patched workstation and the compromised user is as expected low level user (Authenticated user) no special permissions or rights.

There are different and easy ways to elevate privilige from low level user to all the way to  domain admins in less security conscious environment e.g The GPP Vulnerability  extracting cpassword filed in SYSVOL Groups.xml file etc

Here, we will be looking at different attack vector often overlooked  (Windows and third party services) often windows/third party service binary run under the System or high integrity level, any vulnerability in a service could result in privilege escalation.

Windows Services is  vast subject link for your further unsupervised read  here

Naturally, i go for quick powershell one liner to list all the potential vulnerable services in C:\ drive.  Get-WMIobject win32_service to look for services running outside of c:\windows folder   and the -eq “auto” is to check if the services out started, finally we check the  if the services running under the localsystem privilege account and we output the path is located.



Figure 1 we identified  c:\Users\lowuser\Desktop\AwesomeService\Secure.exe  path sits on user desktop with localsystem intergity level.

Icacls Microsoft  native binary to list  security descriptors on folders and files –  (F) indicates lowuser has full control over the Secure.exe binary. Obvious fail but this does happen all the time.

Service_1Figure 2    Lowuser has full control of the folder

Security descriptor definition language (SDDL) in windows world used to define access and protect objects for example, folders, shares, active directory objects, windows event logs etc.   SC sdshow lists access list against AwesomeService a.k.a to identify which user groups have access and make etc

service_03Figure 3 AwesomeService a.k.a Secure.exe SDDL

Brilliant description with SDDL breakdown here:

You might have notices you from SDDL output Authenticated User is not part of the SDDL,we can add our lowuser account to specific access.




Figure 4 Interactive user but not Authenticated User e.g. lowuser account

In order to add lowuser account to the list of SDDL we need the user Security Descriptor, we can identify user SID in the following locations:



Figure 5 low user sid

Whoami /all is also another way to list user SID


Figure 6  whoami /all cmd.exe

SC sdset to set the Authenticated User Read Property and Write Property


Figure 6 SetServiceObjectSecurity successfully set.


Figure 7 authenticated user is set and part of sddl.

Privilge escalation steps:

  • Lowuser has full control of the t C:\Users\lowuser\Desktop\AwesomeService\ folder
  • We can modify ,change, delete, replace
  • Build empire executable and replace the Secure.exe with our own call back agent
  • Reboot the service
  • Elevate Privillige from lowuser to SYSTEM integrity level


Compiled Empire agent executable and named it Secure.exe and copied to our Target Service location ( Replaced the legitimate Secure.exe service with our own executable)


Figure 8 compiled Empire callback and named it Exactly the same as Secure.exe


As expected we got shell from the victim machine with SYSTEM privilege successfully elevated from lowuser to SYSTEM user.


Figure 9 Secure Process Shell with integrity level SYSTEM.


Final couple of words,  log log log everything from your end user workstations, ensure third party services not running under HIGH/SYSTEM integrity.

I hope this has been informative