[HackTheBox] Administrator

[Machine Details]

🧩About Administrator

Administrator is an assumed-breached Active Directory machine (Windows) that focuses on privilege escalation within an Active Directory environment.

The challenge begins with a low-privileged user account provided to the attacker. This account has GenericAll permissions over another user, allowing the attacker to take control of that account. The newly compromised account then has ForceChangePassword rights over a third user, enabling the attacker to reset that user’s password and gain access.

This third user has access to an FTP server, where a backup of a Password Safe database is stored. Inside the database, multiple user credentials are found. One of the credentials is still valid leading to the discovery of GenericWrite permission and is used to perform a Kerberoasting attack or AS-REP Roasting attack.

The recovered hash from the attack is cracked and used to access another user who holds DCSync rights. With DCSync access, the attacker can dump all password hashes from the domain, leading to full domain compromise.

👩‍💻Provided Credential

To simulate a real-world Windows penetration test, Hack The Box provides us with a starting set of user credentials:

• Username: Olivia
• Password: ichliebedich

These credentials give us initial access to the target machine and allow us to start exploring the environment. In real-life scenarios, such credentials might be obtained through phishing attacks, leaked password dumps, or guessing weak passwords.

[Reconnaissance]

💻 NMAP Scan

A targeted NMAP scan against the machine administrator.htb revealed multiple open ports:

Nmap scan report for administrator.htb (10.129.127.184)
Host is up (0.37s latency).

PORT      STATE SERVICE       VERSION
21/tcp    open  ftp           Microsoft ftpd
| ftp-syst: 
|_  SYST: Windows_NT
53/tcp    open  domain        Simple DNS Plus
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-04-17 01:55:17Z)
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: administrator.htb0., Site: Default-First-Site-Name)
445/tcp   open  microsoft-ds?
464/tcp   open  kpasswd5?
593/tcp   open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp   open  tcpwrapped
3268/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: administrator.htb0., Site: Default-First-Site-Name)
3269/tcp  open  tcpwrapped
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
9389/tcp  open  mc-nmf        .NET Message Framing
47001/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49664/tcp open  msrpc         Microsoft Windows RPC
49665/tcp open  msrpc         Microsoft Windows RPC
49666/tcp open  msrpc         Microsoft Windows RPC
49667/tcp open  msrpc         Microsoft Windows RPC
49668/tcp open  msrpc         Microsoft Windows RPC
51166/tcp open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
51171/tcp open  msrpc         Microsoft Windows RPC
51193/tcp open  msrpc         Microsoft Windows RPC
51196/tcp open  msrpc         Microsoft Windows RPC
51229/tcp open  msrpc         Microsoft Windows RPC
58330/tcp open  msrpc         Microsoft Windows RPC
Service Info: Host: DC; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
| smb2-time: 
|   date: 2025-04-17T01:56:20
|_  start_date: N/A
|_clock-skew: 7h00m01s

It reveals that the target is running an Active Directory (AD) environment. The open ports and service banners give us strong clues:

• Port 88 (Kerberos): Handles authentication in AD environments.
• Port 389 (LDAP): Used to query AD objects like users and computers.
• Port 445 (SMB): Enables file sharing and remote management—common in Windows networks.
• Port 464 (kpasswd): Used for Kerberos password changes, specific to AD setups.
• LDAP banner reveals:
  • Domain name: administrator.htb
  • Site name: Default-First-Site-Name

These details point to a default Active Directory setup, which is often seen in lab environments like this one.

📌 Key Ports to Focus On

📦 FTP Enumeration

Testing Credential

We attempted to log in to the FTP service using the provided credentials olivia:ichliebedich. The connection to the server was successful, and the banner confirmed that Microsoft FTP Service is running.

However, the login attempt failed with a 530 error: "User cannot log in, home directory inaccessible".

This confirms that FTP is enabled on the system, but the current account doesn't have the necessary permissions or home directory setup to access it.

📂 SMB Enumeration

Testing Credentials and Gathering System Info

We used NetExec to test the credentials olivia:ichliebedich against the SMB service on port 445. The authentication was successful, confirming that we have valid domain user access.

This confirms we have a working foothold within the domain which is an important starting point for further enumeration.

Enumerating Users

After confirming SMB access, we used NetExec to enumerate domain users. The command successfully retrieved a list of 10 local users, which gives us useful insight into the environment.

Discovered Accounts:

• Built-in Accounts: Administrator, Guest, krbtgt
• Regular Users: olivia, michael, benjamin, emily, ethan, alexander, emma

The presence of these user accounts, especially service-related ones like krbtgt, is typical in an Active Directory environment.

Enumerating Shares

Using the same credentials, we ran a share enumeration against the SMB service to identify accessible file shares.

Discovered Shares:

• ADMIN$ – Remote Admin (no access)
• C$ – Default share (no access)
• IPC$ – Read access
• NETLOGON – Read access
• SYSVOL – Read access

The NETLOGON and SYSVOL shares are commonly used in Active Directory environments to store logon scripts, group policy files, and sometimes even hardcoded credentials from misconfigurations.

We accessed each share using smbclient, but no sensitive files or credentials were found.

Enumerating Domain Computers

Next, we queried the domain for a list of computers using the same valid credentials. The output returned a single entry: administrator.htb\dc$

This confirms that the machine is part of the domain and is functioning as the Domain Controller (DC). Since no other domain-joined systems were listed, this appears to be a minimal lab environment, with the DC likely being the main target.

Enumerating Groups with Users

Using the --groups flag with NetExec, along with some command-line filtering, we enumerated domain groups and their members. This provided valuable insight into how users are distributed across the domain and which ones hold elevated privileges.

Key Findings:

• administrator.htb\Administrator is a member of several powerful groups:
  • Domain Admins
  • Enterprise Admins
  • Schema Admins
  • Administrators
• Regular users such as olivia, michael, emily, and ethan are part of Remote Management Users. This confirms they have standard user-level access, with the potential to interact with remote services like WinRM.
• Another regular user benjamin is a member of Share Moderators. This could indicate access to or control over specific file shares which worth exploring further.

Scan for Coerce Vulnerabilities

During our research, we learned that we can scan for vulnerabilities using NetExec:

Scan for Vulnerabilities | NetExec

Check if host is vulnerable

Logo

So we set up Responder on our attacker machine with all necessary poisoners enabled, including SMB, LDAP, and others. This allowed us to listen for incoming authentication attempts from the target.

Next, we launched a coercion-based scan using NetExec's coerce_plus module, authenticated as olivia. The goal was to force the Domain Controller (administrator.htb) to authenticate back to us, allowing us to capture valuable NTLMv2 hashes.

NetExec returned multiple Exploit Success results across various RPC interfaces.

Responder on the other hand successfully captured an NTLMv2 hash over SMB from the Domain Controller. Even though some duplicates were skipped, the log confirms that the coercion worked and the target is vulnerable.

Unfortunately, we encountered some limitations:

• NTLMv2 hashes are extremely hard to crack offline due to their challenge-response nature and are practically infeasible to brute-force without weak passwords.
• Pass-The-Hash (PTH) is not possible with NTLMv2.
• SMB relay is blocked because SMB signing is enabled and enforced (signing:True).
• LDAP relay attempts also failed.

📚 LDAP Enumeration

Testing Credentials

We tested Olivia's credentials against LDAP (port 389) using NetExec, and authentication was successful. This confirms that Olivia has valid domain access and that the LDAP service is open and responsive.

Enumerating Active Users

With LDAP access confirmed, we used NetExec’s --active-users module to enumerate all currently enabled domain accounts.

• Administrator (built-in domain admin account)
• olivia (provided user)
• michael
• benjamin
• emily
• ethan

This list helps narrow down our focus to accounts that are actually usable within the environment. These active users will be our primary targets for further enumeration, password attacks, or potential privilege escalation techniques.

💻 WinRM Access

Testing Credentials and Running Command

We tested Olivia's credentials against WinRM (port 5985) using NetExec, and the authentication was successful. This confirms that Olivia has remote command execution capability on the Domain Controller via PowerShell over WinRM. Additionally, no files were found in Olivia's folders.

📊 Initial Recon Analysis

Based on the recon performed so far, we've confirmed the following:

• 📦 FTP (Port 21)
  • Login attempt with Olivia's credential failed as the server responded with 530 User cannot login error.
• 📂 SMB (Port 445)
  • Login with Olivia's credentials was successful. We were able to enumerate domain users, groups, and file shares.
• emily, michael, and olivia are members of the Remote Management Users group, indicating possible WinRM access.
• benjamin is part of the Share Moderators group, suggesting potential access to FTP or SMB shares.
• Administrator is a member of multiple high-privilege groups, including Domain Admins, Enterprise Admins, and Schema Admins.
• We have read access to the following shares: NETLOGON, SYSVOL, and IPC$, but no sensitive or useful data was found in these shares during manual review.
• SMB Signing is enabled and SMBv1 is disabled
• The target is vulnerable to coerce-based attacks. We successfully coerced the Domain Controller to authenticate back using NetExec and captured an NTLMv2 hash via Responder. However, we encountered limitations.
• 📚 LDAP (Port 389)
  • Successfully authenticated with Olivia’s credentials.
• Discovered that there are only 6 active users out of 10 users and these are: Administrator, olivia, michael, benjamin, emily, and ethan.
• 💻 WinRM (Port 5985)
  • Successfully authenticated with Olivia’s credentials.
• Confirmed remote command execution via PowerShell using NetExec.
• No files were found in Olivia's folders.

Given the level of access obtained, we will proceed with further domain enumeration using BloodHound, authenticated as olivia, to map out trust relationships and privilege paths within the domain.

[Exploitation]

🧠 BloodHound - Olivia

To identify potential privilege escalation paths within the domain, we used BloodHound with Olivia’s credentials to gather Active Directory data.

We ran bloodhound-python with the following command to collect all relevant data and generate a ZIP archive for import:

bloodhound-python -d administrator.htb -c All -u 'olivia' -p 'ichliebedich' -ns 10.129.117.131 --zip

After importing the collected data into the BloodHound GUI, we set OLIVIA@ADMINISTRATOR.HTB as our starting node for analysis. BloodHound revealed that Olivia has GenericAll permissions over the user MICHAEL@ADMINISTRATOR.HTB.

This means Olivia has full control over the Michael user object in Active Directory. Such control allows us to reset Michael's password, modify his account attributes, or manipulate his group memberships, essentially giving us complete ownership of that account.

🔥 Escalate to Michael

Since BloodHound showed that Olivia has GenericAll rights over Michael, we leveraged that privilege to reset Michael’s password. This gives us full access to his account and allows us to continue our enumeration with potentially higher privileges.

To change the password, we used Samba’s net tool with the following command:

net rpc password "michael" "motoh4ck3r" -U "administrator.htb"/"olivia"%"ichliebedich" -S 10.129.117.131

We then confirmed access via WinRM, running a whoami /all command:

🧠 BloodHound - Michael

After gaining access to Michael’s account, we accessed BloodHound again to see if this user had any additional privileges that could help us escalate further.

BloodHound revealed that Michael has ForceChangePassword rights over BENJAMIN@ADMINISTRATOR.HTB. This permission allows Michael to change Benjamin’s password without knowing the original one, effectively granting us full access to Benjamin’s account.

🔥 Escalate to Benjamin

Since BloodHound confirmed that Michael has ForceChangePassword rights over Benjamin, we used this privilege to reset Benjamin’s password giving us control over his account without needing to know the original password.

To perform the password reset, we used Samba’s net tool with the following command:

net rpc password "benjamin" "motoh4ck3r" -U "administrator.htb"/"michael"%"motoh4ck3r" -S 10.129.117.131

The password change was successful. We attempted accessing Benjamin’s account in two ways:

1. WinRM Access
   The WinRM login attempt failed, which aligns with our earlier recon where we discover that Benjamin is not a member of the Remote Management Users group, so he lacks the permission required for remote PowerShell execution.
2. SMB Access
   We authenticated successfully to SMB using benjamin:motoh4ck3r, confirming valid credentials and domain user access.

🗄️ Discovering Backup File

Since Benjamin cannot access WinRM due to not being in the Remote Management Users group, we revisited our earlier recon and noted that he is a member of the Share Moderators group. This suggests he may have access to shared resources such as FTP.

We also confirmed Benjamin's group in BloodHound:

We tested FTP access using Benjamin’s credentials:

The login was successful, and we discovered a file named Backup.psafe3. This file is a Password Safe database used to store encrypted credentials, secure notes, and other secrets.

We spent a long time searching on how to access the contents of the file and discovered the email shown below from Openwall, where they discussed cracking Password Safe databases.

john-users - Re: Cracking “Password Safe” files with JtR

Re: Cracking "Password Safe" files with JtR

Recognizing the potential value, we downloaded the file for local analysis.

Using offline cracking tool with specified hash type, we were able to successfully recover the password for the backup password database: tekieromucho

🔥 Escalate to Emily

To access the contents of the Password Safe backup file, we first downloaded the Password Safe application to our local machine. After loading the decrypted .psafe3 file (using the password tekieromucho), we extracted a list of stored credentials.

Earlier during recon, we had already enumerated a list of active domain users, and Emily was one of them. Additionally, Emily is a member of the Remote Management Users group, meaning she is eligible for WinRM access.

With this in mind, we didn’t need to perform any password spraying. Instead, we directly tested the credentials via WinRM:

The login was successful.

🧠 BloodHound - Emily

After gaining access to Emily's account, we accessed BloodHound again to identify any additional privilege relationships that could help us escalate further within the domain.

BloodHound revealed that Emily has GenericWrite permissions over ETHAN@ADMINISTRATOR.HTB.

The GenericWrite permission allows Emily to modify non-protected attributes of the Ethan user object. This includes attributes like:

• servicePrincipalName (used for Kerberoasting)
• member (to add users to groups)
• Other writable fields (adding property flags to alter user object; usually used for AS-REP Roasting)

This discovery gives us a clear path to further exploitation specifically by performing a targeted Kerberoast attack or AS-REP Roasting attack to obtain a crackable hash.

🔥 Escalate to Ethan

Based on the help section in BloodHound, we learned that the GenericWrite permission over a user object like Ethan can be abused through targeted Kerberoasting. This involves adding or modifying the servicePrincipalName (SPN) attribute to enable ticket extraction for offline cracking.

We used the targetedKerberoast tool to extract a Kerberos TGS hash for Ethan:

Initially, it failed due to a time skew error, which we resolved by syncing the system clock with ntpdate. After correction, the tool successfully extracted the hash.

Then we used Hashcat with mode 13100 (Kerberos 5 TGS-REP) to crack the password:

The password was cracked successfully: limpbizkit.

In NetExec, we have to manually set an SPN to ethan using bloodyAD before we can successfully retrieve TGS ticket:

We also tried AS-REP Roasting by using bloodyAD to set DONT_REQ_PREAUTH for Ethan then we used hashcat with mode 18200 to crack the password:

To continue the exploitation, we tested the cracked credentials for Ethan:

Based on the result:

• WinRM access failed confirming Ethan is not a member of Remote Management Users, just as observed during our initial recon.
• SMB access was successful, confirming the credentials are valid.

🧠 BloodHound - Ethan

After gaining access to Ethan's account, we accessed BloodHound again to identify any additional privilege relationships that could help us escalate further within the domain.

Ethan has the following permissions on the domain object ADMINISTRATOR.HTB:

• GetChanges
• GetChangesAll
• GetChangesInFilteredSet
• DCSync

These are the exact permissions required to perform a DCSync attack. DCSync is a technique where an attacker impersonates a Domain Controller and requests replication data from the domain. This includes:

• NTLM password hashes
• Kerberos keys
• Sensitive credential material of any user, including Domain Admins

With these privileges, Ethan can essentially dump all domain password hashes, including that of the administrator leading to full domain compromise!

🔥 Escalate to Administrator

As confirmed earlier in BloodHound, Ethan holds the critical permissions allowing us to impersonate a Domain Controller and request replication data from the domain.

To perform the attack, we used Impacket’s secretsdump.py tool with Ethan’s credentials:

We could also use the --ntds drsuapi flag in NetExec smb:

The command successfully dumped all domain NTLM hashes, including the Administrator account.

To confirm the credentials, we authenticated via WinRM by performing Pass-The-Hash:

Access granted! We now have full domain control with the Administrator account.

[Appendixes]

Appendix A - Attack Flow

Appendix B - MITRE ATT&CK Mapping and Tools