Unclaimed HTB Writeup

I just solved Unclaimed from Hack the Box!

Unclaimed Machine Summary

Unclaimed is a medium-difficulty Windows machine on Hack The Box that focuses on web application enumeration, chatbot-assisted SQL query execution, Microsoft SQL Server misconfigurations, privilege escalation through SQL Server impersonation, credential decryption, and Windows Backup Operators privilege abuse.

The attack begins with Nmap enumeration, revealing several exposed services, including HTTP, SMB, and WinRM. After configuring hostname resolution for unclaimed.htb, I performed web application enumeration and explored an airline baggage-tracking portal featuring an interactive chatbot called TracerBot. By testing the chatbot's functionality and enumerating baggage records, I discovered that the application exposed sensitive database information through its /ask API endpoint.

Further interaction with the chatbot disclosed a support override code, which allowed me to execute SQL queries against the underlying Microsoft SQL Server database. I used this functionality to enumerate MSSQL server principals and impersonation permissions, discovering that svc_tracer_ro could impersonate svc_reports, an account with sysadmin privileges. By leveraging this misconfiguration, I escalated my SQL Server permissions, enabled xp_cmdshell, and achieved operating system command execution.

After verifying PowerShell execution through xp_cmdshell, I prepared a PowerShell reverse shell payload, encoded it using UTF-16LE Base64, and verified its contents before execution. Triggering the payload through the SQL-backed API established my initial foothold as UNCLAIMED\svc_sql. I then enumerated the account's Windows privileges and successfully captured the user flag.

During post-exploitation, I enumerated local Windows accounts, MSSQL services, and SQL Server Agent jobs. Further investigation of SQL Agent permissions, stored credentials, and proxy configurations revealed a credential named WTArchiveCred, associated with the Windows account UNCLAIMED\svc_wtbackup. I also examined the SQL Server instance configuration, registry entropy, and encryption key metadata to understand how the stored credential was protected.

To recover the password, I prepared a custom PowerShell credential decryption script and transferred it to the target using a Python HTTP server. The script leveraged Windows DPAPI, SQL Server encryption key material, and AES decryption to recover the plaintext password associated with svc_wtbackup. I subsequently validated the recovered credentials using NetExec and established an interactive remote PowerShell session through Evil-WinRM.

Finally, Windows privilege and group enumeration revealed that svc_wtbackup belonged to the Backup Operators group and possessed enabled SeBackupPrivilege and SeRestorePrivilege permissions. I exploited SeBackupPrivilege using Robocopy's backup mode to bypass normal file access restrictions, copy the Administrator's protected root.txt file, and retrieve the root flag, completing the machine without requiring an Administrator shell.

Overall, Unclaimed demonstrates how multiple security weaknesses can be chained together, beginning with excessive information disclosure through a chatbot, progressing through MSSQL impersonation and credential decryption, and culminating in privilege abuse through Windows Backup Operators. The machine highlights the security risks associated with overly permissive database configurations, improperly protected service credentials, and powerful Windows privileges assigned to service accounts.

Unclaimed - HackTheBox - Writeup - Season 12 Aero Machine HTB Walkthrough

Protected Page

asdf

The first step in owning the Unclaimed 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 Unclaimed machine and I was assigned an IP address (10.129.91.0).

Nmap Enumeration

I started by running an Nmap scan against the target IP 10.129.91.0 to identify open ports, running services, and potential attack surfaces.

The scan revealed five open TCP ports: 80 (HTTP), 135 (RPC), 139 (NetBIOS), 445 (SMB), and 5985 (WinRM), indicating a Windows-based machine.

I noticed that port 80 redirected to http://unclaimed.htb/, revealing the target's hostname, which I would need to resolve locally for further web enumeration.

Additionally, SMB signing was enabled and required, making traditional SMB relay attacks less viable. Port 5985 also suggested that WinRM could potentially provide remote access if valid credentials were obtained.

With these findings, I decided to focus my initial enumeration on the web application and SMB services to identify possible entry points.

Hostname Resolution

After discovering that the web server redirected to unclaimed.htb, I added the target's IP address and hostname to my local /etc/hosts file.

This allowed my machine to resolve unclaimed.htb to 10.129.91.0 without relying on DNS. With hostname resolution configured, I could access the web application using its intended domain and continue my enumeration.

Web Application Enumeration

I continued my enumeration by sending an HTTP request to unclaimed.htb using curl to inspect the server's response headers and HTML source code.

The server returned an HTTP 200 OK response, confirming that the web application was accessible and responding successfully.

I identified the application as HTB Airlines - Baggage Services, running behind Microsoft-HTTPAPI/2.0, which further supported the earlier Windows fingerprint. The response contained a large HTML document with embedded CSS and a chat-style interface, suggesting that the application provided an interactive baggage assistance service.

Based on these findings, I decided to investigate the application's functionality and underlying requests for potential vulnerabilities or interesting endpoints.

Web Application Exploration

Next, I navigated to http://10.129.91.0 through my browser and was automatically redirected to http://unclaimed.htb.

The application presented an HTB Airlines Baggage Services Desk interface featuring an interactive chatbot named TracerBot, designed to retrieve lost or delayed baggage records.

I noticed that the chatbot provided example queries for checking baggage status and scan history using specific baggage tag identifiers. The footer also revealed HTB Airlines Baggage Tracking System v2.4, marked for internal use, along with a reference to WorldTracer/PIR.

Since the application relied on a chatbot to process user input, I decided to investigate its responses and functionality for potential information disclosure or input-handling vulnerabilities.

Chatbot Functionality Testing

I started testing the TracerBot chatbot by submitting the two example baggage tag identifiers provided on the application's welcome page.

For HTB0012345, the chatbot returned a generic response stating that my input did not contain a specific question or request.

When I submitted HTB0067890, the chatbot responded differently, identifying it as a reference number rather than a specific baggage record.

I noticed that the chatbot appeared to interpret user input contextually instead of automatically retrieving baggage information from standalone identifiers.

Since neither query returned actual baggage details, I decided to investigate whether more specific, natural-language requests would trigger the application's baggage lookup functionality.

Baggage Records Enumeration

I continued testing the chatbot by submitting a broader query to determine whether I could retrieve all stored baggage records without specifying an individual tag number.

Surprisingly, the chatbot returned a table containing 10 baggage records, including PIR references, baggage tag numbers, passenger booking references (PNRs), flight details, baggage statuses, and internal notes.

I noticed that the records included sensitive operational information, such as baggage contents, storage locations, and incident reports, which were accessible without authentication.

The response also exposed database-style column names, including pir_id, pir_ref, tag_number, and notes, suggesting that the chatbot could retrieve structured records from its backend.

This indicated a potential unauthorized information disclosure vulnerability, so I decided to investigate whether the chatbot could be manipulated into accessing additional internal data.

API Endpoint Enumeration

After retrieving baggage records through the chatbot, I decided to interact directly with the backend API using curl to inspect the raw HTTP response.

The /ask endpoint returned an HTTP 200 OK response containing JSON data, confirming that the chatbot accepted POST requests with a msg parameter.

I noticed that the response exposed three important fields: reply, sql, and result, revealing both the chatbot's response and the underlying database query.

Interestingly, the sql field contained SELECT * FROM dbo.PIR, indicating that the application was querying a Microsoft SQL Server-style database.

The result field also exposed the complete query output, including column names and all 10 baggage records, confirming that internal database information was being returned directly to unauthenticated users.

This discovery suggested a potential text-to-SQL attack surface, so I decided to investigate whether the chatbot could be manipulated into executing other SQL queries.

Support Override Code Disclosure

I continued probing the /ask endpoint by asking the chatbot directly for the support override code to determine whether it would disclose internal information.

Surprisingly, the chatbot responded with the support override code HTB-OPS-4471 without requiring any authentication or additional verification.

I noticed that both the sql and result fields were null, indicating that no SQL query was exposed for this request.

This suggested that the chatbot could reveal internal operational information directly through natural-language queries, potentially exposing sensitive configuration details.

With the support override code obtained, I decided to investigate whether it could be used to unlock additional functionality or access restricted information within the application.

SQL Query Execution via Support Override Code

After obtaining the support override code, I tested whether it could be used to execute SQL queries through the chatbot by combining it with SELECT @@version.

The chatbot successfully executed the query and returned the database server's version information, confirming that the override code enabled direct SQL query execution.

I identified the database as Microsoft SQL Server 2025 (RTM), version 17.0.1000.7, running on Windows 10 Pro (Build 26100).

The response also exposed the executed SQL statement in the sql field and its output in the result field, confirming that my input reached the database engine.

This revealed a significant SQL execution vulnerability, allowing me to interact with the backend database through the chatbot using the disclosed override code.

With SQL execution confirmed, I decided to enumerate the database further to identify accessible tables, permissions, and potential privilege escalation opportunities.

MSSQL Server Principal Enumeration

After confirming SQL query execution, I continued enumerating the MSSQL server by querying sys.server_principals to identify available logins, server roles, and their account status.

The query executed successfully and returned a list of SQL Server principals, including built-in server roles and configured SQL login accounts.

I noticed that the default sa account was disabled, while two service accounts, svc_tracer_ro and svc_reports, were enabled.

The results also exposed several privileged server roles, including sysadmin, securityadmin, and serveradmin, although their presence did not necessarily indicate that my current session had those privileges.

These findings revealed potentially interesting service accounts, so I decided to investigate their permissions and determine whether either account could provide additional database access or privilege escalation opportunities.

MSSQL Impersonation Privilege Enumeration

I continued investigating SQL Server permissions by querying sys.server_permissions to identify accounts with the IMPERSONATE privilege, which could potentially allow privilege escalation.

The query successfully returned a permission entry showing that svc_tracer_ro had been granted IMPERSONATE privileges over svc_reports.

This meant that svc_tracer_ro could potentially execute SQL statements under the security context of svc_reports, depending on the application's execution context.

I identified this as a promising privilege escalation opportunity, since impersonation could provide access to permissions unavailable to the original account.

With this finding, I decided to investigate the privileges assigned to svc_reports and determine whether impersonating it could provide elevated database access.

MSSQL Privilege Escalation via Impersonation

After discovering that svc_tracer_ro had IMPERSONATE privileges over svc_reports, I attempted to switch my SQL execution context to svc_reports and check its server-level privileges.

The query executed successfully, and SYSTEM_USER confirmed that I was operating under the svc_reports security context.

More importantly, IS_SRVROLEMEMBER('sysadmin') returned 1, confirming that svc_reports was a member of the SQL Server sysadmin role.

This demonstrated a successful MSSQL privilege escalation, allowing me to execute queries with administrative database privileges through login impersonation.

The REVERT statement restored the original security context after execution.

With sysadmin privileges confirmed, I could now investigate additional server-level capabilities and potential paths toward operating system command execution.

Enabling xp_cmdshell for OS Command Execution

After confirming that svc_reports had sysadmin privileges, I attempted to enable xp_cmdshell to allow operating system commands to be executed through MSSQL.

I first impersonated svc_reports using EXECUTE AS LOGIN to execute the configuration changes with administrative privileges.

Next, I enabled show advanced options and xp_cmdshell using sp_configure, applying both changes with RECONFIGURE.

The server returned a successful execution response with no result rows, indicating that the configuration commands completed without reported errors.

Finally, I used REVERT to restore the original login context after making the changes.

With xp_cmdshell potentially enabled, my next step was to verify whether I could execute Windows commands through the database and establish a foothold on the target system.

Remote Code Execution via xp_cmdshell

After enabling xp_cmdshell, I tested whether I could execute operating system commands through MSSQL by running whoami under the svc_reports security context.

The query executed successfully, and the server returned unclaimed\svc_sql, confirming that I had achieved operating system command execution through the database.

I noticed that commands were running under the Windows service account svc_sql, rather than the impersonated SQL login svc_reports.

This confirmed that xp_cmdshell was enabled and functioning, providing a path from SQL Server administrative access to Remote Code Execution (RCE) on the Windows host.

The additional null row was simply part of the xp_cmdshell output and did not indicate an execution failure.

With command execution confirmed, I decided to enumerate the svc_sql account's privileges and investigate potential paths to further compromise the target.

Reverse Shell Preparation

After confirming remote code execution through xp_cmdshell, I started preparing my attack machine to establish a reverse shell connection from the target.

I first checked whether Netcat was installed on my Kali machine, and the output confirmed that it was available at /usr/bin/nc.

Next, I identified my HTB VPN interface (tun0), which revealed my assigned IP address as 10.10.15.120.

This address would serve as the callback destination for the reverse shell, allowing the target machine to connect back to my Netcat listener.

With Netcat available and my VPN IP identified, I was ready to configure a listener and attempt to obtain an interactive shell on the target.

PowerShell Execution via xp_cmdshell

After confirming operating system command execution, I tested whether PowerShell was available on the target by executing a simple command through xp_cmdshell.

I used EXECUTE AS LOGIN to impersonate svc_reports and launched PowerShell with the -NoProfile option to avoid loading user-specific profiles.

The command executed successfully and returned PowerShell-works, confirming that PowerShell commands could be executed through the MSSQL server.

This demonstrated that I could run more advanced Windows commands beyond basic utilities such as whoami.

With PowerShell execution verified, I could now proceed with establishing a reverse shell to obtain interactive access to the target machine.

PowerShell Reverse Shell Payload Encoding

After confirming that PowerShell commands could be executed through xp_cmdshell, I prepared a PowerShell reverse shell payload and encoded it using Python to simplify execution through MSSQL.

I configured the payload to connect back to my HTB VPN IP address, 10.10.15.120, on port 4444.

The PowerShell script used System.Net.Sockets.TCPClient to establish a connection, receive commands, execute them using iex, and return their output.

I encoded the payload using Base64 with UTF-16LE encoding, making it compatible with PowerShell's -EncodedCommand parameter.

This also helped avoid quoting and special-character issues when passing complex PowerShell commands through the JSON API and MSSQL.

With the encoded payload generated successfully, I was ready to start a Netcat listener and attempt to establish an interactive reverse shell on the target.

PowerShell Reverse Shell Payload Verification

After generating the Base64-encoded PowerShell payload, I decoded it locally to verify that the original script had been encoded correctly before executing it on the target.

I used base64 -d to decode the payload and iconv to convert it from UTF-16LE into readable UTF-8 text.

The output successfully revealed the original PowerShell script, confirming that the encoding process had preserved the payload.

I verified that the script contained the correct callback IP address, 10.10.15.120, and listening port 4444.

I also confirmed that the script used TCPClient to establish a connection and iex to execute received commands.

With the payload verified, I was ready to execute it through xp_cmdshell and attempt to establish an interactive reverse shell.

Initial Foothold – PowerShell Reverse Shell

After verifying my encoded PowerShell payload, I started a Netcat listener on port 4444 to receive the reverse shell connection.

Next, I executed the encoded payload through the /ask endpoint using xp_cmdshell under the impersonated svc_reports SQL login.

Although the API returned an Execution Timeout Expired error, I noticed that my Netcat listener had received an incoming connection from 10.129.91.0.

The PS C:\Windows\System32> prompt confirmed that I had successfully established an interactive PowerShell reverse shell on the target.

The timeout occurred because the reverse shell process remained active rather than completing within the API's execution timeout.

With my initial foothold established, I could now begin enumerating the Windows environment for potential privilege escalation opportunities.

Windows Privilege Enumeration

After obtaining an interactive PowerShell reverse shell, I started enumerating the current user's identity and assigned privileges to identify potential privilege escalation opportunities.

The whoami command confirmed that my shell was running as unclaimed\svc_sql, the Windows service account associated with MSSQL.

I then executed whoami /priv to inspect the privileges assigned to the current security token.

The output revealed that SeChangeNotifyPrivilege and SeCreateGlobalPrivilege were enabled, while SeIncreaseWorkingSetPrivilege was disabled.

I noticed that high-risk privileges such as SeImpersonatePrivilege and SeDebugPrivilege were absent, making common token-based privilege escalation techniques less promising.

With no obvious privilege escalation path through the current token, I decided to investigate the system's configuration, accessible files, and service permissions for alternative escalation opportunities.

User Flag Capture

After obtaining a PowerShell shell as svc_sql, I navigated to the user's Desktop directory and attempted to retrieve the user flag.

The command executed successfully and revealed the contents of user.txt, confirming that I had access to the user flag. This marked the successful completion of the initial foothold and user-level compromise of the Unclaimed machine.

With the user flag captured, I continued enumerating the Windows environment to identify a potential privilege escalation path to NT AUTHORITY\SYSTEM and retrieve the root flag.

asdf