VulnCicada HTB
VulnCicada HTB Box Overview VulnCicada is a Windows Active Directory machine that focuses on modern AD CS abuse and domain compromise techniques. The attack begins with an exposed NFS share containing user profile data, leading to credential disclosure through improperly exposed files. Further enumeration reveals an Active Directory Certificate Services (AD CS) deployment vulnerable to ESC8, allowing NTLM authentication to be relayed to the certificate authority. By combining Machine Account Quota (MAQ) abuse, DNS record manipulation, authentication coercion, and certificate-based authentication, it becomes possible to obtain a certificate for the Domain Controller machine account, dump NTDS secrets, and ultimately gain Domain Administrator access. The machine provides an excellent introduction to modern AD CS attack paths and real-world Active Directory privilege escalation techniques. Enumeration Nmap Scanning Starting with a full Nmap scan against the target. Nmap Scan Analysis The Nmap scan reveals several interesting services. | Port | Service | |--------|---------| | 53 | DNS | | 80 | HTTP | | 88 | Kerberos | | 111 | RPCBind | | 389 | LDAP | | 445 | SMB | | 636 | LDAPS | | 2049 | NFS | | 3268 | Global Catalog | | 3269 | Global Catalog SSL | | 3389 | RDP | | 5985 | WinRM | From the LDAP, Kerberos, SMB, and Global Catalog ports we can immediately identify that this machine is acting as an Active Directory Domain Controller. The ports that immediately caught my attention were: These are commonly associated with NFS. NFS is not something we commonly see exposed on a Windows Domain Controller, so this looked like a promising place to start. At this stage my primary areas of interest were: Since NFS often contains accessible files and user data, I decided to investigate it first. Adding the Domain Names Adding the discovered hostnames to /etc/hosts. --- Enumerating NFS Shares Listing exported NFS shares: Interesting. The /profiles share is accessible by everyone. Let's mount it locally and inspect the contents. Mounting the NFS Share After mounting: These look like domain user profile directories. To get a better view of the share: Most folders are inaccessible, but two image files are visible: Let's inspect them. --- Inspecting vacation.png Opening the image: Screenshot 2026-06-10 at 00-55-55 Nothing particularly interesting here. It appears to be a normal vacation photograph and doesn't reveal any useful information. --- Inspecting marketing.png The second image turned out to be much more interesting. Screenshot 2026-06-10 at 00-57-40 A sticky note can be seen on the desk containing: This immediately looks like a password. Since the image belongs to the Rosie.Powell profile, my first thought was: Time to verify that assumption. Validating the Credentials Using NetExec: Success. We now have valid domain credentials. --- Generating a Kerberos Ticket To make further enumeration easier, I generated a TGT for Rosie. Exporting the ticket: Verifying: Now we can use Kerberos authentication for further enumeration. Enumerating SMB Shares Connecting with Impacket's SMB client: Listing shares: Most of these are expected in an Active Directory environment. However, one share immediately stood out: That name is a huge hint. Whenever I see a CertEnroll share, my mind immediately goes to: Let's investigate further. Inspecting the CertEnroll Share Switching into the share: The share contains several Certificate Revocation Lists (CRLs). This confirms that AD CS is deployed in the environment. At this point I strongly suspected that the intended attack path would involve certificate services. The next step was to enumerate AD CS using Certipy. Enumerating Active Directory Certificate Services Running Certipy: The output is quite large, but the important section is: And there it is. Understanding ESC8 Before exploiting it, it's worth understanding what ESC8 actually is. ESC8 is an Active Directory Certificate Services attack where NTLM authentication can be relayed to the AD CS Web Enrollment endpoint. The attack flow looks like this: In simple terms, if we can force a privileged system (such as the Domain Controller) to authenticate to us, we can relay that authentication to AD CS and request a certificate on its behalf. That certificate can then be used to obtain Kerberos tickets and impersonate the target account. At this point the attack path started becoming clear: The next step is determining whether we have the required permissions to carry out the relay attack. Machine Account Quota (MAQ) Before moving forward with the ESC8 attack, we need a way to coerce the Domain Controller to authenticate to our machine. A common technique is abusing Machine Account Quota (MAQ). By default, Active Directory allows any authenticated user to create up to 10 computer accounts. This behavior is controlled by the attribute: Let's verify the value in this environment. The result confirms that standard domain users are allowed to create machine accounts. This becomes useful because machine accounts can be abused in several AD attacks, including NTLM relay scenarios. Reference: https://www.packetlabs.net/posts/the-overlooked-danger-how-ms-ds-machine-account-quota-fuels-ad-attacks --- Understanding the DNS Record Trick For this attack we need the Domain Controller to initiate an outbound authentication request to our attacker machine. A special DNS record can be created that abuses how Windows resolves hostnames during authentication. The record format is: For this box the hostname becomes: Adding the record using BloodyAD: The DNS record now points back to our attacker machine: This will later allow us to receive NTLM authentication from the Domain Controller. Setting up the NTLM Relay Now that the environment is prepared, we can start the relay server. The goal is simple: Starting Certipy relay: Certipy is now waiting for incoming NTLM authentication requests. Finding a Coercion Method Next we need to force the Domain Controller to authenticate to us. The coerce_plus module checks multiple known coercion techniques. Several methods are available. For this attack I chose: because it is reliable and commonly used in AD CS relay attacks. Relaying the Domain Controller Authentication After triggering PetitPotam, the Domain Controller authenticates to our relay server. Certipy captures the NTLM authentication and forwards it to the vulnerable AD CS Web Enrollment endpoint. Success. We now possess a valid certificate for the Domain Controller machine account. This is effectively equivalent to controlling the machine account itself. Authenticating with the Certificate Using the newly obtained certificate: Certipy successfully obtains: A Kerberos TGT The machine account NTLM hash --- Exporting the Ticket Verifying: At this point we are operating as the Domain Controller machine account. --- Dumping NTDS With the DC machine account ticket loaded, we can dump the NTDS database. Several hashes are extracted. The most interesting one: Administrator NTLM Hash: --- Requesting a TGT as Administrator Using the Administrator hash: Exporting the ticket: We are now ready to authenticate as Administrator. Shell as Administrator Using PsExec with Kerberos authentication: Shell obtained: We now have full Domain Administrator access. --- Flags Checking the Administrator desktop: Reading the flags: Both flags are located on the Administrator desktop. Attack Path Final Thoughts VulnCicada was an excellent Active Directory machine that showcased how multiple seemingly harmless misconfigurations can be chained together into a full domain compromise. The box started with a simple NFS share enumeration that exposed user profile data and valid credentials. From there, the challenge shifted towards AD CS, where identifying and exploiting ESC8 became the key to compromising the domain. The most interesting part of the machine was understanding how Machine Account Quota, DNS record manipulation, authentication coercion, and NTLM Relay could be combined to obtain a certificate for the Domain Controller account. Rather than relying on a single vulnerability, VulnCicada rewarded careful enumeration and a solid understanding of modern Active Directory attack paths. It also highlights the importance of securing AD CS, reviewing default domain configurations, and restricting relay opportunities within enterprise environments. A very enjoyable and realistic Active Directory machine that provides great exposure to modern certificate-based attacks. Thanks for reading, and I'll see you in the next writeup. ```