Monteverde (HTB)

HackTheBox – Monteverde Write-Up

topics: Azure Active Directory, Windows Privilege Escalation (Azure AD Connect), SMB password spraying, lateral movement

1. Enumeration

2. Local Privilege Escalation

3. Domain Administrator Privilege Escalation

tools: nmap, autorecon, enum4linux, smbclient, powershell, winPEAS, msfvenom, kerbrute, msfconsole (smb_login), evil-winrm, AzureADConnect.ps1

Enumeration

Initial nmap and autorecon scans:

From the initial scans, the target appears to be a Windows Server in an Active Directory environment, the services DNS, Kerberos, MSRPC, SMB, and LDAP are characteristic of such a device. While autorecon finished, I enumerated DNS with assetfinder and amass which failed to list additional subdomains.

enum4linux returned a list of users that we can veify with kerbrute. Analyzing information retrieved for the domain's password policy, specifically last set time, all accounts contain the same value except for mhope which could be information to utilize later. This account password was changed a day before all others

kerbrute confirmed the unusual number of service accounts, which indicates the need to find credentials for authenticated enumeration. Of all service accounts listed, each of them are unique to this particular box and searching for them online will spoil the methodology.

Regardless, at this point it is clear we need to find a password or hash to enumerate the SMB share users$. As service accounts commonly reuse their username as a password, we can begin spraying using the username list as a password list.

SMB

We can begin password spraying with smb_login via msfconsole

And it successfully confirmed the credentials SABatchJobs:SABatchJobs as valid for the megabank.local domain.

SABatchJobs has read permission for the share users$ and immediately, I checked mhope which from the initial scans, observed this account had the unique date/time for last password changed. This share coincidentally contained a file titled azure.xml

Checking the contents of azure.xml revealed a cleartext password for mhope giving us the credentials mhope:4n0therD4y@n0th3r$

Local Privilege Escalation

Utilizing mhope's credentials we can attempt to login via evil-winrm

whoami /priv reveals mhope is a member of the Azure Admins domain group

Domain Admin Privilege Escalation

Listing what we know so far, the compromised account mhope is a member of the Azure Admins group and contained a file azure.xml on the SMB share with a cleartext password. There might be a way to escalate privileges using this group permission, let's transfer winPEAS and enumerate locally.

winPEAS lists MS SQL and Azure AD Connect within the executable and PSModule path. Additionally, they are listed in the write permissions PATH and Installed Program Files folder.

Initial scans did not return any public facing MS SQL server, perhaps this is a deprecated service that was not properly decommissioned and we can use it to leverage our Azure Admin privileges.

While this was my initial thought, there seems to be more of a hint towards privilege escalation via Azure so I focused on this rather than MS SQL. As I would come to learn, Azure AD Connect creates a new MS SQL database by default. Searching "azure ad connect and aad sync pentesting/redteam" leads to an article titled "Azure AD Connect for Red Teamers." This tutorial explains in great detail common exploits for Azure AD Connect and Sync, including the extraction of the domain admin's password.

As the author explains:

..if you are able to compromise a server containing the Azure AD Connect service, and gain access to either the ADSyncAdmins or local Administrators groups, what you have is the ability to retrieve the credentials for an account [domain admin] capable of performing a DCSync.

Based on the article and info from PayloadAlltheThings, we can conclude this instance of Azure AD Connect is vulnerable to a password hash synchronization (PHS) attack. As the account mhope is a member of the Azure Admins group, it enables us to decrypt and extract the domain admin password.

In an effort to avoid importing obscure python modules from the recommendation, I found a pure PowerShell script that did not require modification. The script follows the methodology outlined in the article; automatically retrieving the Instance and KeySet IDs, as well as the entropy value needed to fetch and decrypt the password of the account that syncs AD and Azure, in this case the domain admin.

-s flag allows us to upload PS scripts locally and execute from memory

The PS module was able to successfully retrieve and decrypt the Domain Admin's password, which we can use to login with evil-winrm once more for privilege escalation