DanglingTree - HackTheBox

I just solved DanglingTree from Hack the Box

DanglingTree Machine Summary

DanglingTree is a hard-difficulty Windows machine on Hack The Box that features an intricate Active Directory exploitation chain, combining credential harvesting via DPAPI, custom ACL abuse, and advanced Certificate Services (AD CS) vulnerabilities (ESC1) to achieve full domain takeover. The machine begins with standard reconnaissance, where Nmap enumeration reveals the available services, followed by hosts file configuration to resolve the target domain correctly. Initial web enumeration of the landing page is followed by SMB enumeration and share enumeration, where Server Message Branch services are queried to inspect accessible shares. Subsequent SMB authentication and share access, along with SMB file enumeration and PDF document analysis, help inspect sensitive file structures and review retrieved documentation for internal naming conventions. Further reconnaissance includes domain user enumeration and RID brute-forcing to map out user accounts, culminating in stored credential enumeration to identify cached credential blobs and DPAPI artifacts left on the system for offline processing.

The DPAPI exfiltration and credential recovery phase starts with DPAPI artifact exfiltration, where Netcat listeners are set up and PowerShell one-liners are executed to exfiltrate encrypted credential blobs and DPAPI master keys from the target host. Next, DPAPI master key decryption is performed using Impacket's dpapi.py module alongside known domain user credentials and SID to decrypt the retrieved master key. Credential blob decryption is then carried out to parse and decrypt the target Windows Credential Manager blob using the derived master key, revealing plaintext user credentials (alex.o:SunsetMountainPeak@2025).

For lateral movement, bloodhound data collection and bloodhound path analysis are conducted by importing enumeration data into BloodHound to map out domain privileges, revealing that alex.o belongs to the SUPPORT-IT group, which possesses ForceChangePassword rights over jake.h. This is followed by a targeted password reset, where bloodyAD is executed authenticated as alex.o to forcefully update and reset the password for jake.h, and domain user authentication validates the newly reset credentials to establish a foothold for subsequent enumeration.

The AD CS and certificate template abuse phase (ESC1) begins with certificate services enumeration to query the domain's certificate authority configurations using certipy-ad to locate management rights and template permissions. Active directory configuration enumeration is performed to check write privileges within the configuration partition, identifying CREATE_CHILD permissions over certificate templates and OID containers. Published certificate templates enumeration inspects the enrollment services container via secure LDAP to list all active certificate templates, while ghost certificate template verification scripts an LDAP query loop that confirms several published templates are "ghost templates" missing entirely from the directory database. Rogue certificate template creation is then executed by authoring and running a custom Python script to programmatically inject a rogue certificate template (EmployeeAuthTemplate) and a corresponding OID into the configuration partition with permissive DACLs.

Following ghost template exploitation, which verifies the successful creation of the template and confirms that Authenticated Users received full control over the object, malicious template configuration uses certipy-ad template to apply default vulnerable settings, ensuring the template explicitly permits arbitrary Subject Alternative Names (SANs). Vulnerable certificate verification scans the AD CS environment to verify that the injected template is properly registered and recognized as an ESC1 attack vector. Domain SID enumeration retrieves the core domain SID using rpcclient to construct precise certificate requests, and time synchronization synchronizes the attacking machine's clock with the domain controller using ntpdate to prevent Kerberos validation errors. An administrator certificate request is then submitted to request and obtain an administrative certificate (administrator.pfx) on behalf of the built-in domain administrator using the vulnerable template and arbitrary UPN mapping, followed by kerberos time verification to perform a final time check against the domain controller to ensure complete stability before ticket generation.

The final domain takeover and flag extraction phase commences with PKINIT authentication & hash extraction, where authentication via Kerberos PKINIT using the generated PFX file secures a TGT and extracts the Administrator's raw NT hash. System shell access via pass-the-hash is then executed using impacket-psexec with the recovered Administrator hash against the domain controller, bypassing plaintext authentication to spawn an interactive nt authority\system command prompt. Finally, flag retrieval is performed to locate and read root.txt from the Administrator's desktop and recursively search the file system to locate and extract user.txt from noah.b's profile directory, completing all objectives for the machine.

Protected Page

The first step in owning the DanglingTree machine like I have always done in my previous writeups is to connect my Kali Linux terminal with Hack the Box server. To establish this connection, I ran the following command in the terminal:

Once the connection between my Kali Linux terminal and Hack the Box server has been established, I started the DanglingTree machine and I was assigned an IP address (10.129.26.248).

Nmap Enumeration

I began the enumeration by running an aggressive Nmap scan against the target to identify open ports, running services, and information about the underlying operating system.

The scan revealed several services commonly associated with a Windows Active Directory Domain Controller, including DNS (53), Kerberos (88), LDAP/LDAPS (389/636), SMB (445), Global Catalog LDAP (3268/3269), and RDP (3389). LDAP and RDP enumeration identified the domain as danglingtree.htb, with the target hostname dc.danglingtree.htb and NetBIOS domain DANGLINGTREE. The server also exposed IIS 10.0 over ports 80 and 443, providing an additional web-based attack surface for further enumeration. SMB signing was enabled and required, while the reported clock skew of approximately seven hours was also noteworthy because accurate time synchronization can become important when interacting with Kerberos.

Hosts File Configuration

After identifying the domain and Domain Controller hostname from the Nmap results, I added them to my local /etc/hosts file so they would resolve correctly to the target IP address.

This mapped DC.danglingtree.htb, danglingtree.htb, and the short hostname DC to 10.129.26.248. With local name resolution configured, I could access services using their expected hostnames instead of relying solely on the IP address. This is particularly useful when enumerating Active Directory, Kerberos, LDAP, and hostname-dependent web services.

Web Enumeration

After configuring local name resolution, I visited the target IP address in my browser to investigate the HTTP service discovered on port 80.

The server returned the default Microsoft Internet Information Services (IIS) Windows Server landing page, confirming that IIS was actively serving web content. Since the default page did not expose any immediately useful functionality or application-specific information, I continued with further web enumeration to identify potentially hidden directories, files, or additional endpoints.

SMB Enumeration

I continued the enumeration by using NetExec against the SMB service on port 445 to gather additional information about the target and generate the corresponding hosts file entries.

The results identified the machine as DC within the danglingtree.htb domain, running Windows Build 26100 on a 64-bit architecture. SMB signing was enabled, while SMBv1 was unavailable, reducing the usefulness of several legacy SMB attacks. More importantly, NetExec reported Null Auth:True, indicating that the SMB service accepts unauthenticated connections, making anonymous SMB enumeration a promising next step.

Guest SMB Authentication

Since the previous SMB enumeration indicated that null authentication was permitted, I tested whether the built-in guest account could authenticate without supplying a password.

NetExec successfully authenticated as danglingtree.htb\guest with an empty password, confirming that guest access was enabled on the SMB service. This provided me with valid low-privileged access to the target and opened the possibility of enumerating accessible SMB shares, files, and other domain resources using the guest account.

SMB Share Enumeration

After successfully authenticating as the guest user, I enumerated the available SMB shares to determine which resources were accessible with the current privileges.

The enumeration revealed several standard Windows shares, including ADMIN$, C$, IPC$, NETLOGON, and SYSVOL. While most privileged shares were inaccessible, the guest account had READ permissions on both IPC$ and the custom IT share. The presence of a readable non-standard share named IT was particularly interesting, so I proceeded to inspect its contents for potentially useful files or information.

Accessing the IT SMB Share

After identifying that the IT share was readable, I connected to it using smbclient to manually inspect its contents.

The -N option instructed smbclient not to prompt for a password, allowing me to connect using the available guest/null authentication. The connection succeeded and returned an interactive smb: \> prompt, confirming that I could access the share. From here, I proceeded to enumerate the directories and files stored within the IT share.

SMB Share File Enumeration

Once connected to the IT share, I enumerated its contents and discovered a directory named Security, which appeared particularly relevant to the assessment.

Inside the directory, I found a file named DanglingTree_RoE_Assessment.pdf. Since the guest account had read access, I downloaded the PDF to my local machine using the get command. With the document retrieved successfully, I proceeded to inspect its contents for information that could assist with further enumeration.

Credential Discovery

After downloading the PDF from the IT share, I opened DanglingTree_RoE_Assessment.pdf on my Linux machine and reviewed its contents for information that could assist with further enumeration.

While reviewing the document, I discovered a Provided Credentials section containing credentials for the anderson.w account in the danglingtree.htb domain. The document identified this account as a low-privileged standard domain user intended for the security assessment. With a valid domain username and password available, I could now authenticate to exposed services and continue enumerating the Active Directory environment as an authenticated user.

Domain User Authentication

After discovering the anderson.w credentials in the assessment document, I tested them against the SMB service using NetExec to verify whether they were valid.

The authentication attempt succeeded, confirming that anderson.w was a valid user within the danglingtree.htb domain and that the recovered password was correct. This gave me authenticated domain access through SMB with the privileges assigned to the account. With valid credentials confirmed, I proceeded with authenticated enumeration to identify additional resources and potential attack paths.

Authenticated SMB Share Enumeration

After confirming the anderson.w credentials, I enumerated the SMB shares again to determine whether authenticated access exposed additional resources.

The enumeration showed that anderson.w had READ access to IPC$, NETLOGON, and SYSVOL, while the administrative ADMIN$ and C$ shares remained inaccessible. Compared to the earlier guest access, the account could now read the domain's NETLOGON and SYSVOL shares. Since these shares commonly contain domain scripts, policies, and configuration files, I proceeded to enumerate them for potentially useful information.

SMB User Enumeration

With valid domain credentials, I used NetExec to enumerate users exposed through the SMB service and identify additional accounts within the environment.

The authentication succeeded, but the enumeration returned only the anderson.w account rather than a broader list of domain users. NetExec also revealed that the account's password was last changed on 2026-04-05 and showed no recorded failed password attempts. Since SMB enumeration provided limited user information, I continued exploring other Active Directory services for additional domain data.

RID Brute-Force Enumeration

Since the standard SMB user enumeration returned limited results, I performed RID brute-forcing to enumerate additional users and groups from the domain.

The enumeration successfully resolved multiple RIDs and exposed several domain accounts, including jake.h, svc_mail, noah.b, alex.o, and anderson.w. I also identified several interesting groups such as Cert_Managers, Helpdesk_Cert_Support, Template_Editors, DevOps_PKI, and support-it. These PKI-related groups stood out as potentially important, suggesting that Active Directory Certificate Services (AD CS) could play a role in the attack path.

Windows Admin Center Enumeration

During further web enumeration, I identified an additional HTTPS service running on TCP port 6600, so I accessed it through the target domain to determine what application was exposed.

The service presented a Microsoft Windows Admin Center login page, confirming that the server exposed a web-based Windows administration interface. Unlike the default IIS page discovered earlier, this application required authentication with a username and password. Since I had already obtained valid domain credentials for anderson.w, this interface became an interesting target for further authenticated enumeration.

Windows Admin Center Authentication

After discovering the Windows Admin Center portal, I authenticated using the anderson.w domain credentials previously recovered from the DanglingTree_RoE_Assessment.pdf document.

The credentials were accepted successfully, and I was redirected to the Windows Admin Center dashboard. The interface also revealed that the installed Windows Admin Center version was 2511 and displayed the dc gateway connection. With authenticated access to the management interface, I could now enumerate its available functionality and investigate potential attack paths.

Windows Admin Center Connection Attempt

After authenticating to Windows Admin Center, I selected the dc [Gateway] server and attempted to establish a management connection using my current anderson.w session.

The connection attempt failed with the message This operation was blocked by role based access control settings. 

This confirmed that although anderson.w could authenticate to the Windows Admin Center portal, the account did not have sufficient RBAC permissions to manage the server. I therefore needed to continue enumerating the environment for another privilege or access path.

Windows Admin Center Version Enumeration

Since my current account lacked sufficient privileges to manage the server, I continued enumerating Windows Admin Center and opened the help (?) menu to identify the exact version in use.

The application reported Windows Admin Center version 2511, running build 2.6.4.11. Identifying the precise version was important because it allowed me to investigate whether this particular release contained any known vulnerabilities or security weaknesses. With the version information confirmed, I proceeded to research potential vulnerabilities affecting Windows Admin Center 2511.

CVE-2026-26119 Vulnerability Research

After identifying the Windows Admin Center version, I researched the release for known security issues and discovered that the target was potentially affected by CVE-2026-26119.

Further research led me to a detailed Semperis analysis describing the vulnerability as a Windows Admin Center remote privilege-escalation issue involving authentication reflection. Semperis — Windows Admin Center Remote Privilege Escalation (CVE-2026-26119) Since I already had authenticated access as the low-privileged anderson.w user, this vulnerability became a promising path for escalating my privileges through Windows Admin Center.

Invoke-Command API Analysis

Although the Windows Admin Center version on the target was patched against CVE-2026-26119, I continued studying the vulnerability to understand how WAC exposes PowerShell execution through its Invoke-Command functionality.

The target identifies dc as its Windows Admin Center gateway, making the identity trusted by that gateway an important security boundary. Under normal conditions, commands submitted through the PowerShell endpoint execute within the authenticated user's context. The vulnerability itself was not the Invoke-Command endpoint; rather, the vulnerable authentication chain could cause WAC to trust the gateway's computer account instead of the low-privileged user, turning the endpoint into the final execution primitive.

Session Cookie Parser Preparation

To interact with the Windows Admin Center API using my authenticated session, I first prepared a Python script named parse_request.py to extract and format the required session cookies from a captured HTTP request.

The script parses the captured Host and Cookie headers, separates each cookie, and associates them with the correct WAC hostname. It then stores the resulting cookies in artifacts/wac/session_cookies.json, which can be reused by the second script when making authenticated API requests. It also checks for the XSRF-TOKEN, allowing me to verify that the required anti-CSRF token was successfully captured before continuing.

Burp Suite Request Capture

I launched Burp Suite, enabled Proxy Intercept, and authenticated to the web application using the provided anderson.w credentials. After logging in successfully, I monitored the HTTP traffic to identify the authenticated API requests generated by the application.

I captured the authenticated request in Burp, which included the active session cookie and XSRF token required by the application. I then saved the complete request as raw_request.http so I could reuse it during further endpoint enumeration and testing.

Session Cookie Extraction

I proceeded to execute parse_request.py, passing the previously saved raw_request.http file as an argument to extract the authenticated session information.

The script successfully extracted four cookies for the danglingtree.htb domain and confirmed that an XSRF-TOKEN was present. It then saved the extracted authentication data to artifacts/wac/session_cookies.json, which I verified by listing the contents of the directory.

PowerShell Command Execution Script

I created a Python script named user.py to interact with the Windows Admin Center API using the authenticated session cookies extracted earlier.

The script loads session_cookies.json, retrieves the XSRF-TOKEN, and recreates the required authenticated HTTP headers. It then targets the WinREST PowerShell invokeCommand endpoint and allows me to supply either an individual PowerShell command or a script file. Finally, it sends the request and prints the returned results, warnings, or PowerShell errors, providing a convenient way to test command execution through the authenticated API.

PowerShell Payload Creation

To establish a reverse shell connection back to my attacking machine via our exploit script, I created a custom PowerShell payload file.

I wrote a standard TCP reverse shell script configured to connect back to my local IP address on port 4444. This payload reads commands from the socket, executes them locally using Invoke-Expression, and streams the output back to my listener to provide interactive system access.

Reverse Shell Execution

To catch the incoming connection from our PowerShell payload, I started a local Netcat listener on port 4444.

After setting up the listener, I ran our custom exploit script to execute the payload against the Windows Admin Center API endpoint.

The script successfully posted the payload and triggered execution on the target server. Within seconds, my Netcat listener caught the incoming connection from 10.129.26.248, dropping me into an interactive PowerShell session as the user anderson.w and granting me initial foothold access to the system.

Initial System Enumeration

After obtaining a PowerShell session on the target, I first confirmed the account associated with my current shell and then enumerated the system’s active network connections.

The whoami output confirmed that I was authenticated as danglingtree\anderson.w. Reviewing netstat showed established connections to my attacking host (10.10.14.2), including the active session on port 4444. I also identified several local connections involving LDAP (389) and SMB (445), with multiple connections communicating with the host dc. These results indicated that the compromised machine was actively communicating with the domain controller, making the internal AD-related services relevant for further enumeration.

Listening Port Enumeration

I enumerated the listening TCP ports on the compromised Windows host to identify services that were not immediately apparent from the initial external enumeration.

The output revealed several Active Directory-related services, including Kerberos (88), LDAP/LDAPS (389/636), SMB (445), Global Catalog (3268/3269), and AD Web Services (9389). I also identified RDP (3389), WinRM (5985), and unusual services listening on ports 6600–6602 and 17017. Additionally, several mail-related services such as SMTP (25/587), POP3 (110), and IMAP (143) were bound only to localhost. These internally exposed services provided additional targets for further enumeration from my existing foothold.

Chisel Setup

To prepare for tunneling traffic and accessing internal network services, I downloaded the Windows binary of Chisel onto my attacking machine.

I grabbed the release package and extracted the archive to obtain chisel.exe. Having this tunneling utility prepared locally allowed me to stage the binary for transfer to the target host and establish an encrypted pivot connection.

Chisel Reverse Port Forwarding

To access a service bound only to the target’s localhost, I used Chisel to create a reverse tunnel. I first hosted the Windows Chisel binary from my Kali machine using Python’s HTTP server.

I opened another fresh netcat listener and download the chisel.exe:

From the target, I downloaded chisel.exe into C:\Windows\Temp using PowerShell’s Net.WebClient. 

I spun up a listener on my attacking machine and downloaded chisel.exe into the target's temporary directory. Next, I launched a reverse Chisel server on my Kali machine and executed the client binary from the target prompt to establish an encrypted tunnel.

I ran the Chisel client configured for reverse port forwarding, successfully mapping internal service traffic back through our active foothold session.

SmarterMail Enumeration

I opened the locally forwarded SmarterMail service in my browser and navigated directly to its login interface.

The page revealed a SmarterMail instance and presented the standard “Welcome to SmarterMail” authentication portal. From my earlier RID brute-force enumeration, I had identified the account svc_mail, which appeared likely to be associated with the mail service. Since CVE-2026-23760 targets SmarterMail’s system-administrator password-reset process, this discovery provided a potential path for further investigation. I therefore focused my next enumeration on determining whether svc_mail could be associated with an administrative SmarterMail account.

SmarterMail Password Reset

To exploit the administrative password reset vulnerability and take over the mail service account, I sent a crafted API request via our local port tunnel.

I ran the curl command against the local SmarterMail API endpoint, forcing a password reset for the svc_mail account with system administrator privileges. The server responded with a success status and debug trace confirming that the password had been successfully updated to Boltech@123.

SmarterMail Authentication

To verify our newly reset administrative credentials and access the internal mail management console, I browsed to the local SmarterMail dashboard via our Chisel tunnel.

I authenticated using the svc_mail:Boltech@123 credentials and successfully logged into the system administrator portal. I enumerated the available options and domain configurations, confirming full administrative access over the mail service infrastructure.

SmarterMail Version Enumeration

After gaining access to the SmarterMail administrative interface, I navigated to the About SmarterMail section to identify the exact version running on the target. The application disclosed both its edition and build number directly through the interface.

I confirmed that the server was running SmarterMail Free Edition Build 9504, which provided an important lead for further vulnerability research. I then correlated this specific build with publicly documented security issues and identified CVE-2026-23760 as potentially applicable to the installed version. This gave me a clear direction for the next exploitation phase of the CTF.

Exploit Research

To find a working proof-of-concept for the identified vulnerability, I searched online repositories for exploit code targeting the SmarterMail flaw.

I reviewed the available public research and repository details for CVE-2026-23760, confirming the mechanics behind the password reset authentication bypass. This documentation verified how the endpoint permits unauthenticated requests to reset system administrator accounts, providing the final piece needed for full system exploitation.

PowerShell Reverse Shell Payload Encoding

I prepared a PowerShell reverse-shell payload configured to connect back to my attacking machine at 10.10.14.2 on TCP port 5555. I then converted the payload to UTF-16LE and Base64-encoded it so it could be supplied as an encoded PowerShell command.

The command returned a long Base64 string representing the complete PowerShell payload. The script creates a TCP connection back to my listener, receives commands through the network stream, executes them with Invoke-Expression, and returns the resulting output. I saved this encoded value for use during the next exploitation stage against the CTF target.

Netcat Listener Setup

To catch the incoming reverse shell connection from our encoded PowerShell payload execution, I started a new local Netcat listener on port 5555.

I ran the listener to wait for the incoming connection triggered by our exploit script. This setup prepared my attacking machine to receive the incoming socket stream and provide interactive administrative access once the target executed our payload.

SmarterMail Volume Mount Command Execution

After accessing the SmarterMail administrative interface, I navigated to Settings → Volume Mounts and created a new volume mount. I configured the mount path to use a temporary Windows directory and supplied the PowerShell payload as the mount command.

The -enc option instructs PowerShell to decode and execute the supplied Base64-encoded command, which in this case contains a reverse-shell payload configured to connect back to my attacking machine on 10.10.14.2:5555. By abusing the Volume Mount functionality to execute the supplied command, I attempted to turn the legitimate SmarterMail administrative feature into a command-execution primitive. With a listener running on the corresponding port, successful execution would establish an interactive PowerShell session from the target back to my machine.

I saved and mounted the volume, which forced the underlying service to immediately execute our payload command with system-level privileges.

Within a second, my Netcat listener successfully caught the incoming connection from 10.129.26.248, dropping me into an interactive PowerShell session inside the SmarterMail service directory as a high-privileged user and completing the final path to system compromise.

SmarterMail Domain Backup Enumeration

After gaining access as the danglingtree\svc_mail service account, I enumerated the SmarterMail domain storage directory to identify potentially useful configuration or backup data.

The enumeration revealed the active danglingtree.htb domain alongside a backup directory named danglingtree.htb.bak. I inspected the backup and discovered several configuration files, including accounts.json, settings.json, and gal.json, as well as Users and Archived Data directories. Since backup directories can retain historical account information or configuration data that is no longer present in the active installation, I identified danglingtree.htb.bak as an interesting target for further enumeration.

Noah's SmarterMail Backup Enumeration

I enumerated the local user profiles and identified noah.b as both a Windows user and a user represented within the backed-up SmarterMail domain data.

I then inspected Noah's backup directory, which contained FileStore, Mail, folders.json, and settings.json. The presence of the Mail directory was particularly interesting because it indicated that Noah's historical mailbox data had been preserved in the domain backup. This provided a logical next step to enumerate the archived emails for potentially useful information.

SmarterMail Credential Discovery

I inspected Noah's backed-up SmarterMail configuration for password-related entries, as the settings.json file contained the account's historical authentication settings.

The output confirmed the account as noah.b@danglingtree.htb and revealed a populated password_encrypted field containing 66e7ppLOBF7UdzDv7zK6MJ1rmyUb1Cby. I also observed that two-step authentication was not configured for the account. Since this value represents an encrypted credential rather than plaintext, I noted it for further analysis to determine how SmarterMail protects and recovers stored passwords.

SmarterMail DLL Transfer

After gaining access to the target, I inspected the SmarterMail installation and identified the SmarterMail.Standard.dll assembly. I first verified that the DLL existed and checked its size before transferring it to my attacking machine for further analysis.

The output confirmed that SmarterMail.Standard.dll was present in the SmarterMail service directory with a size of approximately 36 MB. Since the assembly could contain useful application logic and implementation details, I decided to copy it locally for offline inspection.

On my Kali machine, I started a Netcat listener on TCP port 60001 and redirected anything received through the connection into a local DLL file.

The target connected back from 10.129.26.248, allowing the DLL data to be written directly to SmarterMail.Standard.dll on my machine. Once the transfer completed, I verified the resulting file using:

The transferred file was approximately 35 MB, consistent with the size reported on the Windows target. With the SmarterMail assembly now available locally, I could proceed with offline analysis of its internal classes and application functionality.

SmarterMail DLL Exfiltration

After starting the Netcat listener on my attacking machine, I transferred the SmarterMail.Standard.dll assembly directly from the target using a PowerShell TCP connection.

I first read the DLL into a byte array using PowerShell and then established a TCP connection to my machine on port 60001. I wrote the complete byte array directly to the network stream before closing both the stream and TCP client. This provided me with a local copy of the SmarterMail assembly that I could inspect without modifying the original file on the target.

DES Credential Decryption

After extracting the encrypted value and identifying the DES key and IV pairs, I created a Python script to test the available keymaps and recover the plaintext value.

I Base64-decoded the ciphertext and iterated through both candidate key/IV combinations using DES in CBC mode. For each attempt, I removed the expected PKCS-style padding and decoded the resulting bytes as text. Invalid combinations were ignored, allowing the script to print only a successfully decrypted plaintext value for use.

Python Environment Setup

Before running my DES decryption script, I created a dedicated Python virtual environment to keep the required dependencies isolated from my system-wide Python installation.

I activated the newly created environment and installed the pycryptodome package, which provides the Crypto.Cipher.DES and padding functionality required by my script. The installation completed successfully with pycryptodome 3.23.0, allowing me to proceed with decrypting the previously obtained ciphertext.

Credential Extraction

I ran the custom crack.py script to recover the credential stored or derived from the data I had previously collected during enumeration.

The script successfully processed the data and revealed the plain-text password RiverDragon#Storm25 using keymap2, providing the credentials needed for our next phase of access.

RunasCs Preparation and Compilation

To prepare for the next stage of the CTF, I cloned the RunasCs repository, a C# implementation of runas that can be used with explicit credentials. I then inspected the repository to identify the available source files and confirmed that RunasCs.cs was the primary C# source code.

I verified that the Mono C# compiler (mcs) was installed before compiling the source code into RunasCs.exe. The compilation completed successfully without errors and produced a 51 KB executable. Finally, I used the file command to inspect the generated binary, which confirmed that it was a PE32 Windows console executable and a Mono/.NET assembly. This provided me with a Windows-compatible build of RunasCs that I could use during the subsequent stages.

Lateral Movement to noah.b Using RunasCs

After compiling RunasCs.exe, I needed to transfer the executable from my Kali machine to the compromised Windows host. I started a Python HTTP server on port 80 from the directory containing the executable, allowing the target to retrieve it over HTTP.

From my existing svc_mail shell, I downloaded RunasCs.exe into C:\Windows\Temp and verified that the file had been successfully transferred. I then used the recovered credentials for noah.b with RunasCs and instructed it to launch cmd.exe with a remote connection back to my machine on port 6666.

Before executing the payload, I started a Netcat listener on my Kali machine to receive the incoming connection.

The target connected back successfully from 10.129.26.248, providing me with a new Windows command shell. To confirm the security context of the newly established session, I ran whoami.

The output returned danglingtree\noah.b, confirming that I had successfully moved from the svc_mail context into an authenticated shell running as noah.b.

BloodHound Enumeration with RustHound-CE

To map out the Active Directory environment and identify potential privilege escalation paths, I gathered domain data using rusthound-ce. Before running the collector, I synchronized my system clock with the target domain controller to prevent time-skew authentication errors.

I authenticated with the compromised noah.b credentials and enumerated all available objects and ACLs across the domain. I ran the tool to collect the full dataset over LDAPS, compressing the output directly into a zip archive ready for visual analysis in BloodHound.

BloodHound Path Analysis

To identify potential privilege escalation vectors within Active Directory, I imported the collected archive into BloodHound and mapped out my current user's permissions.

I enumerated Noah's valid certificate registration scope, noting that his Domain Users membership grants enrollment rights to four distinct certificate templates, while his implicit Authenticated Users status allows registration with the enterprise CA.

I further expanded on these inheritance group relationships, which mapped out his access to the Certificate Service DCOM Access group.

Finally, I inspected the default domain controller policy GPO {6AC1786C-016F-11D2-945F-00C04FB984F9} and highlighted an AddKeyCredentialLink relationship originating from the Privileged Key Management group.

Because my compromised user had no access to these administrative groups and lacked write permissions over the GPO, I concluded this specific branch did not provide a viable privilege escalation path and shifted my focus to other vectors.

Switching to alex.o

After gaining control of the noah account, I checked whether the compromised session contained any credentials that could help me pivot to another user. I ran the Windows cmdkey utility to enumerate credentials currently stored on the system.

The output revealed a stored Domain Password credential associated with PC01.danglingtree.htb. More importantly, the credential belonged to the domain user alex.o, giving me a potential path to switch from noah to this account. Since Windows can use credentials stored in Credential Manager when authenticating to their associated target, I noted PC01 as the system tied to these credentials. This provided a clear lead for investigating whether I could leverage the cached alex.o credential to authenticate to PC01 without knowing the user's plaintext password.

DPAPI Credential and Master Key Enumeration

Since cmdkey revealed a stored credential for alex.o, I investigated Noah’s profile for the underlying Windows DPAPI credential material. I first enumerated the Credential Manager directory to identify any encrypted credential blobs.

I found the credential blob 57FFB67D684C67F09E7153B9C7CC3940 inside Noah’s Microsoft\Credentials directory. I then enumerated the Microsoft\Protect directory and identified Noah’s SID-specific DPAPI folder containing the master key f53fcaba-f057-48e8-8f92-0180d274bf0f. The directory also contained CREDHIST, SYNCHIST, Preferred, and the domain backup-related BK-DANGLINGTREE file. These artifacts indicated that the stored alex.o credential was protected using Windows DPAPI, giving me the necessary files to investigate decrypting the credential in the next stage.

Transferring DPAPI Credential Files

After identifying Noah’s DPAPI master key and encrypted credential blob, I needed to transfer both artifacts to my attacker machine for offline analysis. I started two Netcat listeners on separate ports and redirected the incoming data into their respective files.

From the target, I used PowerShell to read each file as raw bytes and establish TCP connections back to my machine at 10.10.14.2. The master key was sent over port 6001, while the encrypted Credential Manager blob was transferred over 6002. With both DPAPI artifacts now available locally, I could proceed with offline recovery of the key material and investigate the stored alex.o credential.

DPAPI Master Key Decryption

With Noah’s DPAPI master key available locally, I used Impacket’s dpapi.py utility with Noah’s domain password and SID to decrypt the protected master key.

The tool successfully parsed the DPAPI master key file and identified its GUID as f53fcaba-f057-48e8-8f92-0180d274bf0f. Using the supplied password, Impacket reported Decrypted key with User Key (MD4 protected), confirming that the master key was successfully recovered. The resulting decrypted key could now be supplied to dpapi.py against the previously extracted Credential Manager blob. This gave me the next step toward recovering the stored credentials associated with the alex.o account.

Credential Blob Decryption

With the master key successfully recovered, I could finally parse and decrypt the target credential blob stored in the Windows Credential Manager.

I ran Impacket's dpapi.py credential module against the exfiltrated blob file, supplying the raw hexadecimal master key we obtained in the previous step. The tool successfully processed the encrypted structure and revealed the plain-text domain password SunsetMountainPeak@2025 for the account alex.o. I enumerated the parsed output, confirming these credentials were saved specifically for accessing PC01.danglingtree.htb, giving me the exact leverage needed for my next lateral movement.

BloodHound Enumeration - Alex.O

After obtaining another set of valid credentials, alex.o:SunsetMountainPeak@2025, I authenticated as alex.o and returned to BloodHound to investigate what privileges this account had within the domain.

I enumerated the outbound relationships for alex.o and discovered that the account is a member of the SUPPORT-IT Active Directory group. BloodHound revealed that this group has a ForceChangePassword relationship over the user jake.h. This means members of SUPPORT-IT have delegated permission to reset jake.h's password without knowing his current password. Therefore, compromising alex.o provides a clear privilege path from alex.o → SUPPORT-IT → jake.h, making jake.h the next logical account to target in the attack chain.

ForceChangePassword Abuse - Jake.H

After BloodHound revealed that alex.o could force a password change on jake.h, I used bloodyAD to abuse this delegated Active Directory permission.

I authenticated to the domain controller as alex.o and instructed bloodyAD to replace jake.h's password with a password I controlled. The [+] Password changed successfully! response confirmed that the ForceChangePassword privilege identified in BloodHound was exploitable. With the password reset completed, I now had valid credentials for jake.h, allowing me to continue enumerating the domain from this newly compromised account.

AD CS Certificate Permissions Enumeration

After gaining control of jake.h, I authenticated with the new credentials and used Certipy to enumerate Active Directory Certificate Services (AD CS) for potentially interesting certificate permissions.

I filtered the enumeration output for ManageCertificates and discovered that DANGLINGTREE.HTB\Helpdesk_Cert_Support holds this permission. This privilege allows the group to manage certificate requests on the associated Certificate Authority. The finding therefore identifies Helpdesk_Cert_Support as an important group to investigate further, especially if jake.h can obtain membership or influence over it.

Certificate Template Permissions Enumeration

After compromising jake.h, I authenticated with the account and used bloodyAD to enumerate writable objects within the Active Directory Configuration partition.

I specifically checked for CREATE_CHILD permissions to determine where jake.h could create new directory objects. The enumeration revealed that I had CREATE_CHILD rights on the Certificate Templates container, including the pKICertificateTemplate object class. It also showed similar rights within the OID container for msPKI-Enterprise-Oid objects. These permissions are significant because they indicate that jake.h can potentially create certificate-related objects in the AD CS configuration, providing another avenue to investigate for privilege escalation.

AD CS Published Certificate Templates Enumeration

After identifying certificate-related permissions for jake.h, I authenticated over LDAPS and queried the danglingtree-DC-CA enrollment service to determine which certificate templates were currently published by the CA.

I enumerated the certificateTemplates attribute and found several enabled templates, including RemoteAccessVPN, EmployeeAuthTemplate, VPNUserTemplate, User, and Administrator. This confirmed which templates the CA was actively configured to issue rather than merely which template objects existed in Active Directory. Combined with the previously discovered certificate permissions, these published templates provided useful targets for further AD CS privilege-escalation analysis.

Ghost Certificate Template Verification

To verify if the custom templates published by the Certificate Authority actually existed in the Active Directory database, I scripted a loop to query their specific distinguished names.

I ran the ldapsearch loop, authenticating with Jake's credentials to look up the RemoteAccessVPN, EmployeeAuthTemplate, and VPNUserTemplate objects. I enumerated the Configuration partition and found that the queries returned absolutely no data. This confirmed a critical misconfiguration: these were "ghost templates" that were published by the CA but completely missing from the directory. Since I previously discovered that Jake has CREATE_CHILD rights over the Certificate Templates container, I knew I could forge one of these missing templates with malicious parameters (like allowing arbitrary Subject Alternative Names) and the CA would immediately trust and issue it.

Rogue Certificate Template Creation

To exploit the missing ghost template and our CREATE_CHILD privileges, I authored a custom Python script to forge the EmployeeAuthTemplate directly over LDAPS.

I wrote this script utilizing the ldap3 and impacket libraries to programmatically inject the new template and its corresponding OID into the Active Directory configuration partition. I authenticated to the domain controller within the script and configured the object's DACL to grant the Authenticated Users (SID S-1-5-11) group full control. Crucially, I set the msPKI-Certificate-Name-Flag attribute to 1, which explicitly permits the enrollee to specify an arbitrary Subject Alternative Name (SAN). By saving and preparing this payload, I constructed a reliable method to embed a highly vulnerable template that would allow me to request a Client Authentication certificate on behalf of any domain administrator.

Ghost Template Exploitation

To actively exploit the missing template vulnerability we discovered, I executed our custom Python script to inject the rogue configuration into the domain.

I ran the script against the domain controller, authenticating with Jake's credentials to authorize the LDAP modifications. The payload successfully generated a new OID and injected the EmployeeAuthTemplate object directly into the Active Directory configuration partition. I enumerated the script's output to verify the object creation and confirm that the DACL was updated to grant Authenticated Users full control. This seamlessly replaced the phantom template with my maliciously crafted version, successfully setting the stage to request a privileged certificate with an arbitrary Subject Alternative Name.

Malicious Template Configuration

To finalize the exploitation setup for our injected template, I needed to ensure it possessed the exact parameters required to request a privileged Client Authentication certificate.

I ran the certipy-ad template module against the domain controller, authenticating with Jake's credentials to automatically modify our newly created EmployeeAuthTemplate. By using the -write-default-configuration flag, I forced the tool to overwrite the object's properties with known vulnerable settings. I enumerated the successful output, which confirmed that the Client Authentication application policy and permissive security descriptors were applied. This guaranteed the template was primed for an ESC1-style attack, allowing me to request a certificate on behalf of any domain administrator.

Vulnerable Certificate Verification

To confirm that my injected template was properly registered and recognized as a valid attack vector by the domain, I scanned the Active Directory Certificate Services environment again.

I ran the certipy-ad find module with the -vulnerable flag to specifically filter for templates susceptible to known ESC attacks. I authenticated against the domain controller using Jake's credentials and queried the CA configuration via remote registry (RRP). I enumerated the scan results, which successfully identified our active template among the 12 enabled configurations and automatically saved the detailed findings into text and JSON files. This final check verified that my malicious template was perfectly positioned to request administrative certificates.

Domain SID Enumeration

I ran rpcclient using the credentials for jake.h to query the target domain’s Local Security Authority (LSA) information.

I authenticated successfully against dc.danglingtree.htb, and the lsaquery command returned information about the Active Directory domain. The response confirmed that the domain name was DANGLINGTREE and revealed its domain SID as S-1-5-21-4220238332-57023728-1129110646. This SID uniquely identifies the domain and forms the base portion of the SIDs assigned to domain users and groups. I noted the domain SID because it could be useful during subsequent Active Directory enumeration when resolving or constructing security principals.

Time Synchronization

Before requesting administrative certificates or interacting further with Active Directory, I needed to ensure my local system clock was perfectly synced with the domain controller to prevent Kerberos authentication failures.

I ran the ntpdate utility against the target domain to directly adjust my attacking machine's time settings. I authenticated with my local system password to apply these administrative changes. I enumerated the synchronization output, which revealed my clock was stepped forward by over 25,000 seconds to perfectly match the domain environment. This crucial adjustment guaranteed that my upcoming certificate enrollments and ticket requests would not be rejected due to time skew errors.

Administrator Certificate Request

To execute the final phase of our ESC1 attack and fully compromise the domain, I leveraged our newly crafted template to forge a privileged administrative certificate.

I ran the certipy-ad req utility over RPC, authenticating with Jake's valid credentials to interface with the target certificate authority. By specifying our injected EmployeeAuthTemplate, I abused its permissive Subject Alternative Name (SAN) configuration to explicitly request a certificate on behalf of administrator@danglingtree.htb. I enumerated the resulting console output, which confirmed the CA successfully processed my request and issued a valid certificate mapped directly to the built-in Administrator's SID ending in -500. The tool automatically saved the complete certificate and private key pair into administrator.pfx, successfully granting me the cryptographic material required to request a Kerberos Ticket Granting Ticket (TGT) and achieve full domain takeover.

Kerberos Time Verification

To ensure my upcoming Kerberos authentication would succeed without any issues, I performed a final time synchronization against the target domain controller.

I ran the ntpdate utility one last time to guarantee my attacking machine's clock was still perfectly aligned with the target network environment. I authenticated using my local system password to authorize the background time adjustment process. I enumerated the synchronization output, which showed a minuscule negative offset of just seven milliseconds. This successfully verified that my system time was strictly locked in and stable. With this confirmation, I knew I was completely ready to leverage the forged certificate for a Kerberos Ticket Granting Ticket without risking any time skew rejections.

PKINIT Authentication & Hash Extraction

To finalize the domain takeover and weaponize the forged certificate, I needed to authenticate via Kerberos PKINIT to request a Ticket Granting Ticket (TGT) and extract the Administrator's NT hash.

I ran the certipy-ad auth module, supplying the administrator.pfx file we just generated alongside the domain controller's IP. I authenticated against the domain, which successfully validated the Subject Alternative Name and SID extensions mapped to the built-in Administrator account. I enumerated the successful output, noting that Certipy secured a TGT and saved it locally to the administrator.ccache credential cache. Using this ticket, the tool automatically performed a Kerberos U2U request to decrypt and retrieve the Administrator's raw NT hash 8cacb3a97e460c65d105ca7cd9913925, successfully granting me full, unrestricted access to the entire Active Directory environment.

System Shell Access via Pass-the-Hash

To finalize the domain takeover and establish an interactive remote session, I utilized the extracted NT hash to perform a Pass-the-Hash attack against the domain controller.

I ran the impacket-psexec utility to connect directly to the target machine over SMB. I authenticated using the Administrator account alongside the raw NT hash, completely bypassing the need for a plaintext password. The script enumerated the available network resources, located the writable ADMIN$ share, and created a temporary service to execute the payload. This successfully dropped me into a high-privileged Windows command prompt. I ran the whoami command to verify my current context, confirming that I had achieved ultimate control over the target with nt authority\system access.

Flag Retrieval

To conclude the exploitation phase and secure my points for this target machine, I needed to locate and extract both the user and root flags from the file system.

With my newly established nt authority\system shell, I ran the type command against the Administrator's desktop to immediately read the root.txt flag. Because I escalated privileges without securing a standard user shell first, I enumerated the C:\ drive recursively using the dir /s /b command to hunt down the initial objective. The search results revealed the file was located in noah.b's profile directory. I ran the type command one last time to capture the user.txt hash, successfully completing all objectives and fully owning the machine.

a

Keywords:

dangling tree htb

HTB - DanglingTree

DanglingTree - HackTheBox

I just solved DanglingTree from Hack the Box

danglingtree.htb

DC.danglingtree.htb

DanglingTree Hack the Box Writeup

DanglingTree Hack the Box Walkthrough

DanglingTree_RoE_Assessment.pdf

anderson.w

DanglingTree - HackTheBox Season 11 HTB Machine Complete Walkthrough

R3dT3am@Acc3ss#01

HackTheBox - DanglingTree HTB Season 11 Machine Complete Writeup

CVE-2026-26119

WAC's invokeCommand API abuse

Improper authentication in Windows Admin Center

SmarterMail Build 9504 vulnerability

smartermail-CVE-2026-23760

C:\SmarterMail\Domains

danglingtree.htb.bak

noah.b danglingtree hack the box

RiverDragon#Storm25

danglingtree\noah.b

DanglingTree Walkthrough: Beginner's Writeup from Hack the Box

HTB Season 11 Lab Walkthrough: DanglingTree

DanglingTree | HTB (Full Walkthrough)

HTB Season 11 Labs - DanglingTree from Hack the Box

HTB DanglingTree (Medium Windows)

HTB Writeup - DanglingTree

HTB Walkthrough – DanglingTree

Pwned DanglingTree from Hack The Box

DanglingTree on HackTheBox

Danglingtree HTB Season 11 root flag hint

htb-DanglingTree

user flag danglingtree hackthebox solution

DanglingTree - (Hard) Windows Season 11 HTB Machine

danglingtree-htb complete writeup

danglingtree htb complete walkthrough season 11 hackthebox machines

DanglingTree - Hack The Box CTF Walkthrough

Danglingtree htb writeup github

Hackthebox DanglingTree writeup

Hack The Box DanglingTree Writeup - Complete HTB Walkthrough SmartMail

Hercules - HackTheBox

hercules htb writeup

Hercules - (Insane) Windows HTB Machine

Hercules HTB Walkthrough

Hercules HTB-Writeups

PC01.danglingtree.htb