Unclaimed HTB Walkthrough

I just solved Unclaimed from Hack the Box!

Unclaimed Machine Summary

Unclaimed is a medium difficulty level machine on Hack the Box

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.