Using SPN to escalate to administrator account on Active Directory

8 min readFeb 24, 2021

In this post, I will be demonstrating a live attack on an outdated Windows server machine.

The machine I chose is a retired HackTheBox machine. It’s an easy machine, which is supposed to represent a poorly configured and outdated but authentic Windows server.

Before starting, we should mention that we purposely chose this machine to show the importance of keeping your Operating System up to date. It also shows the basics of Active Directory Attacks and the tools that can be used to gain access in such attacks.

Attacker OS:

Kali Linux.

Tools Used:

Nmap

nslookup

dnsrecon

smbclient

smbmap

gpp-decrypt

Impacket/GetADUsers.py

Impacket/GetUserSPN.py

Hashcat

Scanning:

Starting with an nmap scan, I usually scan for default nmap port but, since I’m working on CTF machine, I decided to scan for all ports:

Then, I scanned all the ports I found with default scripts and versions, I also saved the results inside folder I created called nmap:

sudo nmap -sC -sV -o nmap/nmap -p 53,88,135,139,389,445,464,593,636,3268,3269,5722,9389,49152,49153,49154,49155,49157,49158,49159,49169,49171,49182 10.10.10.100

We can see quite few ports open, but most of them are msrpc ports, which immediately makes me think that this machine is a Windows server that’s poorly configured.

We see that we have DNS version 6.1.7601, which usually runs on windows server 2008 R2 SP1.

This is important: a lot of companies still run their servers on old operating systems. They usually don’t notice any problems with it as long as it’s running well. This walk-through is designed to show people why that assumption is wrong.

Back to our scan result. we see that port 88 is open which represent Microsoft Kerberos Server.

Kerberso is an authentication protocol used by Microsoft. it was first introduced in Windows server 2003 and uses a ticket system.

At high level, Kerberos client authenticate to a service in active directories involving the use of a domain controller in the role of key distribution center (KDC). The scope of Kerberos is large but I hope at least I explained a little bit to get the idea of what that port is doing. Since we immediately see on open, we usually look for ldap ports if it’s open.

Continuing with the scan result, we see ports 135,139 open, which usually are RPC protocols, we will see later how to enumerate these protocol and take advantage of them.

We also see port 445 port is open, which is the default port for SMB.

Port 389 was also open, which the default port for the active directory, ‘LDAP’. We can see it’s leaking the domain name, which is ‘active.htb’.

We can ignore the reset of the ports because it’s just RPC ports

Enumerating

Now that we have our scan ports and we know a little bit about the server, we can start enumerating each port individually.

We will start with port 53 DNS:

The basic DNS enumeration would be nslookup and then we’ll set the server up with the victim IP address:

after we’ve set the server up, we ask who is ‘127.0.0.1’ we get the result as ‘localhost’, Then, we ask it who ‘active.htb’ is and get the IP address, but when we ask for the hostname by typing the public IP address or 10.10.10.100 we get timed out, so I canceled the request.

Now we move to different tool and use dnsrecon, which is default tool that comes with Kali. We perform a dnsrecon with -d flag for the domain and we set the domain IP address with the range 10.0.0.0/8 with -r flag. Note that this tool will take some time to run, especially if you’re running Kali on VM with little RAM. In this case, we didn’t get any result anyway.

Now, we move to look at SMB port since we didn’t see any share folders in the nmap scan result. Knowing that this server is running on an old and outdated OS, we should look more into this service. Windows has a bad history with SMB in general, so we’re going to use nmap to use vuln scripts against it:

We don’t really get much information from this, so we move on and try safe smb scripts. I used an nmap — script safe -p 445 10.10.10.100, but unfortunately we don’t get much more from this. The results also indicate that we should run nmap with -d to debug these errors but we didn’t think that will help so we moved on:

moving forward we will use smbclient tool to see if we can get more information from that port because it’s usually really good attack target. We can gain lots of information if we can find a way to expose it:

We used the smbclient with -L flag to list shares then we entered the target IP address, without using a password. By hitting enter after the password prompt, we get a list of shares as expected from SMB service. We also get SMB1 disabled, which explained why nmap didn’t get any results back to us.

We also wanted to see the permissions on those shares and if we can read or write on it, so we used smbmap to poke further:

We used -H flag to set the host, which is 10.10.10.100. We saw that we don’t have any access on ADMIN share or C share, but what’s interesting is that we have read access to a share folder called Replication.

Most of the time in real life engagements we see a lot of administrators keeping password or sensitive data in shared folders thinking that no one can access these folder unless they know it exists. It’s legitimate excuse I’ve personally encountered many times.

Now, since we know we can read this folder let’s see what’s in inside.

We are going to use smbmap again but we will add -R flag to list file inside folder called ‘Replication’:

We discover a lot of files inside. Normally and depending on the client, we’d download all of them for inspections but, since we’re only doing CTF box, we will focus on what’s important to us. From the results, we can tell that this is an active directory back-up or group policy back-up. From the results we see Groups, which usually contains Groups.xml and that is where user accounts informations can be found in windows server before 2012. Since this is 2008, we assumed we would find something good.We download this:

smbclient -H //10.10.10.100/Replications

We go to the location:

smb: \active.htb\Policies\{31B2F340–016D-11D2–945F-00C04FB984F9}\MACHINE\Preferences\Groups\

and we download the file:

get Groups.xml

Reading the file:

When reading the file, we see user active.htb\SVC_TGS and we also find encrypted password: edBSHOwhZLTjt/QS9FeIcJ83mjWA98gw9guKOhJOdcqh+ZGMeXOsQbCpZ3xUjTLfCuNH8pG5aSVYdYw/NglVmQ

We immediately decrypt this password using gpp-decrypt tool:

And, we get the password GPPstillStandingStrong2k18

Now that we have credentials, we can look at smb port with the credential we have:

smbmap -u ‘SVC_TGS’ -p ‘GPPstillStandingStrong2k18’ -H 10.10.10.100

Now, we have access to more folders: NETLOGON, Replication, SYSVOL and Users,

Let’s look at Users because it sounds really interesting.

Again we see results that contain a lot of files and folders inside.

Now, we know we have a valid credentials and have multiple options for how to proceed. So, let’s see if we can get shell to the server.

Personally I like using impacket tools just because they work well but, since we have no access to write on that machine, we actually can’t use psexec.py. This could have saved by getting us an immediate shell.

So, let’s see if we can get more users.

GetADUsers.py -all active.htb/svc_tgs -dc-ip 10.10.10.100

We can see there is administrator account that shows last login. The two users that logged on are Guest and krbtgt. We also see the user SVC_TGS and the login time,

Right now, all we have is our low privileged user and an administrator account we don’t have password for.

In the beginning of our scan, we found that this server runs Kerberos authentication protocol and we talked a little bit about how it uses Ticket system. Can we take advantage of this??

Exploiting

With all the information we gathered, let’s try exploiting the administrator account. The one way that comes to mind would checking for SPN or “Service Principal Name”

we can easily do that using tool GetUserSPN.py which is part of impacket tool set:

We receive an error saying KYB_AP_ERR_SKEY(clock skew too great), which means our box time has more than one-minute difference with the server. so let’s change the time and try again

using nmap -sC -sV -p 88 10.10.10.100 to check the exact time for the server. Then, we set our time using sudo date — “the same time” — and try again: