Authority HTB
Authority Box Summary Authority is a medium-difficulty Active Directory machine that focuses on credential discovery, configuration analysis, and Active Directory Certificate Services (ADCS) abuse. The attack begins with anonymous access to an SMB share containing an Ansible automation repository, where encrypted Ansible Vault secrets are recovered and cracked to reveal credentials for the PWM password management application. Access to the PWM Configuration Manager allows manipulation of the LDAP configuration, resulting in the disclosure of cleartext LDAP service account credentials and initial access to the target as svc_ldap. During privilege escalation, Active Directory Certificate Services enumeration reveals an ESC1 vulnerable certificate template that can be abused by members of the Domain Computers group. By leveraging the default MachineAccountQuota, a new computer account is created and used to request a certificate for the Administrator account. Although direct certificate-based Kerberos authentication is unavailable, the certificate can still be abused through a PassTheCert attack to grant DCSync privileges to the controlled service account. Finally, a DCSync attack is performed to recover the Domain Administrator hash, which is then used through Pass-the-Hash authentication to obtain full administrative access to the Domain Controller. --- Attack Overview The attack began with anonymous access to the Development SMB share, where an Ansible automation repository was discovered. Encrypted Ansible Vault secrets were extracted and cracked, revealing credentials for the PWM application running on port 8443. After authenticating to the PWM Configuration Manager, the LDAP configuration was modified to point to an attacker-controlled listener, resulting in the disclosure of the svc_ldap credentials in cleartext. Using these credentials, WinRM access to the target was obtained. During privilege escalation, ADCS enumeration revealed an ESC1 vulnerable certificate template. By abusing the default MachineAccountQuota, a new computer account was created and used to request a certificate for the Administrator account. Although certificate-based Kerberos authentication was unavailable, the certificate was successfully leveraged through a PassTheCert attack to grant DCSync privileges to svc_ldap. Finally, a DCSync attack was performed to extract the Domain Administrator hash, which was then used via Pass-the-Hash authentication to obtain full administrative access to the Domain Controller. Enumeration NMAP SCANNING Analyzing the Nmap Results The Nmap scan reveals several interesting services running on the target. | Port | Service | |--------|---------| | 53 | DNS | | 80 | HTTP (IIS) | | 88 | Kerberos | | 389 | LDAP | | 445 | SMB | | 5985 | WinRM | | 8443 | HTTPS (Tomcat) | We can also identify the domain name as: Let's add it to our /etc/hosts file. DNS Enumeration Using dig to enumerate DNS records: We discovered another hostname: Let's add that to /etc/hosts as well. Screenshot 2026-06-20 at 18-21-53 HTTP Enumeration (Port 80) Browsing to port 80 reveals the default IIS landing page. Screenshot 2026-06-20 at 18-25-04 Nothing particularly interesting here, so let's move on. HTTPS Enumeration (Port 8443) Port 8443 is much more interesting. Browsing to the application reveals a PWM (Password Self Service) portal. PWM is an open-source password management solution that integrates with LDAP and Active Directory, allowing users to manage their passwords through a web interface. Screenshot 2026-06-20 at 18-27-06 Attempting to authenticate with random credentials results in the following error: Screenshot 2026-06-20 at 18-28-24 For now, we'll leave PWM aside and continue enumerating other services. SMB Enumeration Let's start by enumerating SMB shares using NetExec. We're receiving a STATUS_USER_SESSION_DELETED error. Let's try using smbclient instead. This worked much better. Out of all available shares, the Development share immediately stands out as the most interesting. Development Share Enumeration Connecting to the share: Listing its contents: Inside the Automation directory we find: This looks very promising. The presence of: ADCS LDAP PWM suggests infrastructure automation files, which often contain credentials or configuration secrets. Downloading the Automation Directory To avoid manually browsing every directory, let's download everything. The download retrieves the entire Ansible project structure, including: Along with numerous: files. We now have a full copy of the organization's automation repository locally, which is exactly the kind of place where credentials, secrets, and misconfigurations are often exposed. Time to start digging through the downloaded files. Investigating the PWM Configuration The PWM directory immediately caught my attention because earlier we discovered that a PWM instance was running on port 8443. Let's inspect the contents of the directory and see if anything useful is exposed. Directory listing: While reviewing the configuration files, I found the following credentials. Screenshot 2026-06-20 at 18-43-28 Interesting. Let's validate these credentials using NetExec. Screenshot 2026-06-20 at 18-45-27 Unfortunately, the credentials are invalid. No worries — let's keep digging. Ansible Vault Secrets While reviewing main.yml, I noticed several AES256 encrypted Ansible Vault blobs. Screenshot 2026-06-20 at 18-46-28 I saved each encrypted secret into a separate file. Now it's time to crack them. Cracking the Vault Password Using ansible2john to convert the vaults into a John-compatible format: Output: Now let's crack them using john. Nice! We have recovered the vault password: Decrypting the Vaults To decrypt the secrets we need ansible-vault. Installing it: This installs several utilities, including: Now we can decrypt each file. LDAP Admin Password PWM Admin Username PWM Admin Password Output: Recovered credentials: Now things are getting interesting. Accessing PWM Configuration Manager Let's return to the PWM application running on port 8443. Screenshot 2026-06-20 at 19-20-14 Clicking on Configuration Manager reveals the username. Screenshot 2026-06-20 at 19-20-45 Let's try the credentials we just recovered. Success! Screenshot 2026-06-20 at 19-29-10 We now have access to the PWM Configuration Manager. Stealing LDAP Credentials While reviewing the configuration, I noticed that PWM authenticates users through LDAP. Screenshot 2026-06-20 at 19-32-42 This gives us an interesting opportunity. Instead of pointing the LDAP server to the legitimate domain controller, we can replace it with our own machine and trick PWM into authenticating against us. I modified the LDAP URL to point to my attacker machine. Screenshot 2026-06-20 at 19-38-00 Then I started a listener on port 389. After clicking Test LDAP Profile, PWM attempts to authenticate to our listener. The web application displays an error: Screenshot 2026-06-20 at 19-36-48 But our listener receives something much more valuable. Boom Boom We just captured the LDAP service account credentials in cleartext. Recovered credentials: Credential Validation Let's verify the credentials. The credentials are valid. Now let's check whether the account has WinRM access. Perfect. We have remote shell access. Initial Access Connecting with Evil-WinRM: Output: We are now inside the target machine as svc_ldap. User Flag Reading the user flag: User access obtained successfully. Privilege Escalation After obtaining a shell as svc_ldap, our next objective is to compromise the Administrator account. Looking inside C:\Users, we only find three user profiles. Screenshot 2026-06-20 at 21-41-57 This suggests that our path to Administrator will likely involve Active Directory rather than local privilege escalation. ADCS Enumeration Since we discovered references to ADCS during our earlier share enumeration, let's check for vulnerable certificate templates. Using Certipy: After reviewing the output, one template immediately stands out. Perfect. We have discovered an ESC1 vulnerable certificate template. Why is ESC1 Dangerous? The CorpVPN template has the following dangerous configuration: This means a user who can enroll in the template can request a certificate for any identity they choose. In other words: However, there is one problem. The template can only be enrolled by: And currently we are only: So first we need to become a member of Domain Computers. MachineAccountQuota Abuse Let's check whether regular users can create machine accounts. Interesting. The domain allows users to create up to 10 machine accounts. This is the default Active Directory behavior and can often be abused. Since newly created computer accounts automatically become members of: we can simply create our own machine account. Using impacket-addcomputer: Awesome. We now control: which is automatically a member of: and therefore eligible to enroll in the vulnerable template. Requesting an Administrator Certificate Now comes the fun part. Because the template is vulnerable to ESC1, we can request a certificate while specifying the Administrator UPN. The request will be made using our newly created machine account. Certificate Request Breakdown Requests a new certificate. Authenticates as our machine account. Specifies the Certificate Authority. Uses the vulnerable template. Requests a certificate for Administrator. Targets the Domain Controller. Executing the request: Success. We now possess a certificate that identifies us as: Certificate Authentication Failure Naturally, the next step is to request a TGT using the certificate. Unfortunately we receive: This error typically occurs when the Domain Controller is not configured for certificate-based Kerberos authentication. In short: Luckily, we still have another option. Pass-The-Certificate Attack Even though Kerberos authentication fails, we can still use the certificate to authenticate over LDAP using PassTheCert. First we need to split the .pfx into separate certificate and private key files. Extract Private Key Extract Certificate Now we have: which can be used with PassTheCert. Granting DCSync Rights Instead of trying to directly become Administrator, we'll take a slightly different approach. We'll use the Administrator certificate to grant DCSync privileges to svc_ldap, an account whose password we already know. Executing PassTheCert: Perfect. We have now granted DCSync privileges to our controlled account. DCSync Attack With DCSync rights assigned, we can now replicate password hashes directly from Active Directory. Using secretsdump: And there it is. Administrator's NTLM hash: Administrator Shell Using Pass-the-Hash with Evil-WinRM: Success. We now have a shell as: Root Flag Reading the final flag: And with that, the box is fully compromised. Final Thoughts Authority was an excellent Active Directory machine that combined several realistic attack paths into a smooth and rewarding compromise chain. The box started with simple service enumeration and share discovery, but quickly shifted into source code and configuration analysis, demonstrating how exposed infrastructure files can become a major security risk. My favorite part of the machine was discovering the Ansible automation repository inside the SMB share. Finding encrypted Ansible Vault secrets, cracking the vault password, and recovering valid application credentials felt very realistic and mirrors situations that frequently occur during internal penetration tests. The PWM misconfiguration that exposed the LDAP bind credentials was another great example of how administrative interfaces can inadvertently leak highly privileged service account credentials. The privilege escalation phase introduced Active Directory Certificate Services (ADCS), specifically the ESC1 attack path. Rather than directly abusing the certificate for Kerberos authentication, the box required understanding why certificate authentication failed and adapting the att