HTB Authority Write-up
#HTB #MediumðŸŸ
|
Hello everyone, in this new post, we will explore Authority Box from HackTheBox.
Authority is a medium-difficulty Windows machine that showcases common security pitfalls within Active Directory environments. It emphasizes the risks associated with misconfigurations, password reuse, careless credential storage, and default domain settings. The machine is a great learning opportunity to understand how seemingly minor weaknesses can be chained together to achieve full domain compromise.
Reconnaissance
To begin, we'll run an Nmap scan to see which ports are open and reachable.
┌──(vincent㉿kali)-[~/pentest/exploit]
└─$ sudo nmap -sS -Pn -n -A 10.10.11.222
Starting Nmap 7.95 ( https://nmap.org ) at 2025-05-02 18:45 CEST
Nmap scan report for 10.10.11.222
Host is up (0.028s latency).
Not shown: 986 closed tcp ports (reset)
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
80/tcp open http Microsoft IIS httpd 10.0
|_http-server-header: Microsoft-IIS/10.0
|_http-title: IIS Windows Server
| http-methods:
|_ Potentially risky methods: TRACE
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2025-05-02 20:45:14Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: authority.htb, Site: Default-First-Site-Name)
| ssl-cert: Subject:
| Subject Alternative Name: othername: UPN:AUTHORITY$@htb.corp, DNS:authority.htb.corp, DNS:htb.corp, DNS:HTB
| Not valid before: 2022-08-09T23:03:21
|_Not valid after: 2024-08-09T23:13:21
|_ssl-date: 2025-05-02T20:46:16+00:00; +3h59m58s from scanner time.
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: authority.htb, Site: Default-First-Site-Name)
| ssl-cert: Subject:
| Subject Alternative Name: othername: UPN:AUTHORITY$@htb.corp, DNS:authority.htb.corp, DNS:htb.corp, DNS:HTB
| Not valid before: 2022-08-09T23:03:21
|_Not valid after: 2024-08-09T23:13:21
|_ssl-date: 2025-05-02T20:46:16+00:00; +3h59m58s from scanner time.
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: authority.htb, Site: Default-First-Site-Name)
| ssl-cert: Subject:
| Subject Alternative Name: othername: UPN:AUTHORITY$@htb.corp, DNS:authority.htb.corp, DNS:htb.corp, DNS:HTB
| Not valid before: 2022-08-09T23:03:21
|_Not valid after: 2024-08-09T23:13:21
|_ssl-date: 2025-05-02T20:46:16+00:00; +3h59m58s from scanner time.
3269/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: authority.htb, Site: Default-First-Site-Name)
|_ssl-date: 2025-05-02T20:46:16+00:00; +3h59m58s from scanner time.
| ssl-cert: Subject:
| Subject Alternative Name: othername: UPN:AUTHORITY$@htb.corp, DNS:authority.htb.corp, DNS:htb.corp, DNS:HTB
| Not valid before: 2022-08-09T23:03:21
|_Not valid after: 2024-08-09T23:13:21
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
8443/tcp open ssl/http Apache Tomcat (language: en)
|_http-title: Site doesn't have a title (text/html;charset=ISO-8859-1).
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=172.16.2.118
| Not valid before: 2025-04-30T20:24:14
|_Not valid after: 2027-05-03T08:02:38
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.95%E=4%D=5/2%OT=53%CT=1%CU=34899%PV=Y%DS=2%DC=T%G=Y%TM=6814F6DA
OS:%P=x86_64-pc-linux-gnu)SEQ(SP=100%GCD=1%ISR=108%TI=I%CI=I%II=I%SS=S%TS=U
OS:)SEQ(SP=101%GCD=1%ISR=107%TI=I%CI=I%II=I%SS=S%TS=U)SEQ(SP=101%GCD=1%ISR=
OS:10F%TI=I%CI=I%II=I%SS=S%TS=U)SEQ(SP=103%GCD=1%ISR=109%TI=I%CI=I%II=I%TS=
OS:U)SEQ(SP=FE%GCD=1%ISR=10B%TI=I%CI=I%II=I%SS=S%TS=U)OPS(O1=M53CNW8NNS%O2=
OS:M53CNW8NNS%O3=M53CNW8%O4=M53CNW8NNS%O5=M53CNW8NNS%O6=M53CNNS)WIN(W1=FFFF
OS:%W2=FFFF%W3=FFFF%W4=FFFF%W5=FFFF%W6=FF70)ECN(R=Y%DF=Y%T=80%W=FFFF%O=M53C
OS:NW8NNS%CC=Y%Q=)T1(R=Y%DF=Y%T=80%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R
OS:=Y%DF=Y%T=80%W=0%S=A%A=O%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=80%W=0%S=Z%A=S+%F=
OS:AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=80%W=0%S=A%A=O%F=R%O=%RD=0%Q=)T7(R=N)U1(R=Y%
OS:DF=N%T=80%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=
OS:80%CD=Z)
Network Distance: 2 hops
Service Info: Host: AUTHORITY; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
| smb2-time:
| date: 2025-05-02T20:46:09
|_ start_date: N/A
|_clock-skew: mean: 3h59m57s, deviation: 0s, median: 3h59m57s
| smb2-security-mode:
| 3:1:1:
|_ Message signing enabled and required
TRACEROUTE (using port 1723/tcp)
HOP RTT ADDRESS
1 13.37 ms 10.10.14.1
2 29.50 ms 10.10.11.222
From the scan results, we can see that several ports are open, including those commonly associated with LDAP, Kerberos, SMB, and others.
I will run a second scan for every ports of the remote server.
┌──(vincent㉿kali)-[~/pentest/exploit]
└─$ sudo nmap -sS -Pn -n -T4 -p- 10.10.11.222
Starting Nmap 7.95 ( https://nmap.org ) at 2025-05-02 18:48 CEST
Nmap scan report for 10.10.11.222
Host is up (0.024s latency).
Not shown: 65506 closed tcp ports (reset)
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
88/tcp open kerberos-sec
135/tcp open msrpc
139/tcp open netbios-ssn
389/tcp open ldap
445/tcp open microsoft-ds
464/tcp open kpasswd5
593/tcp open http-rpc-epmap
636/tcp open ldapssl
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
5985/tcp open wsman
8443/tcp open https-alt
9389/tcp open adws
47001/tcp open winrm
49664/tcp open unknown
49665/tcp open unknown
49666/tcp open unknown
49667/tcp open unknown
49673/tcp open unknown
49690/tcp open unknown
49691/tcp open unknown
49693/tcp open unknown
49694/tcp open unknown
49703/tcp open unknown
49714/tcp open unknown
54580/tcp open unknown
54644/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 777.31 seconds
I’m also performing a scan on the SNMP port to check if it’s open and potentially leaking useful information.
┌──(vincent㉿kali)-[~/pentest/exploit]
└─$ sudo nmap -sU -Pn -n -T4 -p 161 10.10.11.222
[sudo] password for vincent:
Starting Nmap 7.95 ( https://nmap.org ) at 2025-05-02 19:06 CEST
Nmap scan report for 10.10.11.222
Host is up (0.013s latency).
PORT STATE SERVICE
161/udp closed snmp
Nmap done: 1 IP address (1 host up) scanned in 0.20 seconds
After nmap scans, as a first step, I usually check whether SMB is accessible without credentials and explore what it might be hosting.
The development share is publicly accessible, even for guest users. I'll download its contents to look for anything of interest.
Before diving into the SMB share content, we will initiate other commands in parallel to enumerate more information about the system. This will involve using Kerbrute for user enumeration, LDAP enumeration, ASREProasting and exploring the web server, which may have vulnerabilities.
The HTTP server hosts an instance of PWM, an application specifically designed for managing LDAP configuration.
After trying out multiple login attempts, we can dive deeper into the application, especially its configuration area.
In the Configuration Editor section, we can spot some DN-related information. We can add the identified user to our list of known users, which could come in handy later during password spraying. Additionally, there's an option to log in again to manage LDAP settings.
After extensive investigation of the server, including login brute-forcing, SQL injections, exploring potential CVEs, etc, I didn’t find anything of real interest. We can now proceed with a more in-depth analysis of the SMB share content we downloaded earlier.
Within the Ansible 'PWM' directory, multiple subfolders contain YAML configuration files. In the 'Defaults' directory, the main.yml file appears to hold encrypted data, including a username and two password entries.
Ansible is an open-source automation tool used for configuration management, application deployment, and task automation. It’s widely adopted for managing infrastructure at scale, but it can be vulnerable to exploitation if not properly configured.
In order to decrypt the content, we need to obtain the password used to encrypt these blobs. To achieve this, a specific naming convention must be adhered to so that ansible2john can extract the passwords. An example is provided below.
After processing the three blobs, we can pass them to ansible2john, which will generate hashes that we can attempt to crack in order to recover the password.
We can now begin the brute force attacks on each newly created file.
We can see that John has successfully recovered the passwords. Perfect! Now, we’ll be able to retrieve the content of each blob.
To do this, we just need to run the ansible-vault command with the decrypt option as we can see bellow.
After obtaining the content from the three blobs, we can test the newly discovered passwords on the website.
And it was a success!
We can see that there are various LDAP settings available, and we can also test LDAP connections to other servers. I’ll attempt to capture LDAP credentials during the connection using Responder. To achieve this, I'll launch Responder and configure my server as a new LDAP instance.
And BOOM! We've got another password!
Now, we can test this new password against all the users we collected previously.
Awesome, we’ve obtained new credentials. We can also connect to the remote machine via WinRM!
Privilege Escalation
After performing a standard enumeration on the machine and using BloodHound, I couldn’t find any clear exploitation path. I’ve decided to focus on enumerating the ADCS part.
Upon reviewing the vulnerability report, we identify a typical exploitation path in ADCS. ESC1 points out a vulnerability with the 'CorpVPN' certificate template, which allows machines to request certificates on behalf of any user. This means that we can after authenticate ourselves as any user in the domain, including privileged accounts.
To achieve this, we'll create a machine account in Active Directory that we can use later for the request.
Once the new machine account has been created using impacket-addcomputer, we can proceed to make the request in its name.
Unfortunately, we encountered an error. We can retry the command with the -debug option to troubleshoot and get more details about what went wrong.
This time, it worked!!
At this stage, all that’s left is to authenticate with the PFX certificate, and the job will be done.
Unfortunately, Certipy throws an error when requesting the TGT: the KDC does not support the provided padata type. The KDC_ERR_PADATA_TYPE_NOSUPP error often occurs when there's an issue with the PKINIT configuration on the DC, typically due to the absence of the necessary certificates. This can happen if the domain controller doesn't have the required certificate for PKI-based authentication, such as a Domain Controller Authentication certificate or a certificate compatible with smart card authentication.
Since the 'unsupported padata type' error is commonly due to Smart Card Login or PKINIT not being enabled or properly configured on the KDC, we can try to bypass this by authenticating through the LDAP service using the -ldap-shell option which will enable us to execute commands with administrative privileges.
From this point, we simply need to add our user svc_ldap to the Domain Admins group, and that’s it!
We can confirm the change by returning to our remote shell and verifying the group memberships of our user.
Perfect! Our user now has Domain Administrator privileges. We just need to log out and back in to refresh the user token.
Conclusion :
Authority was a great Active Directory machine for anyone wanting to get hands-on with the fundamentals of ADCS exploitation. It presents a well-structured and fun chain of vulnerabilities that’s both educational and rewarding to work through!