I just solved Touch from Hack the Box!
Touch Machine Summary
Touch is an easy-difficulty Windows machine on Hack The Box that focuses on web application enumeration, information disclosure, insecure authentication mechanisms, Windows kiosk escape techniques, credential reuse, and privilege escalation through MySQL User-Defined Functions (UDFs).
I began by performing Nmap enumeration, which revealed several open ports, including RPC (135), RDP (3389), WinRM (5985), and a web application running on port 8443. After configuring my local hosts file to resolve touch.htb, I investigated the Nexion DeviceHub web application and discovered a password-protected login interface. Using ffuf for directory and API endpoint enumeration, I identified the /api and /api/status endpoints. Although the main API required authentication, the status endpoint was publicly accessible and disclosed sensitive device information, including its serial number.
I exploited this information disclosure and weak authentication mechanism by using the exposed device serial number as the login password, successfully gaining access to the Nexion DeviceHub dashboard. Further enumeration revealed a credential disclosure vulnerability that exposed the KioskUser username and password. I reused these credentials to establish an RDP session on the Windows workstation, which presented a restricted HTB Airways self-check-in kiosk.
Inside the kiosk, I explored the booking lookup functionality, entered the provided passenger details, and encountered a session countdown mechanism that required completing the process quickly. After successfully retrieving the booking, I reached the passport verification stage, where repeated scanning attempts failed. I returned to the DeviceHub dashboard and powered off the scanner, causing the kiosk to display a different error containing a troubleshooting hyperlink. Clicking this link launched Microsoft Edge, exposing a potential kiosk escape vector.
I leveraged the browser's Ctrl + O file selection functionality to navigate to C:\Windows\System32\cmd.exe, download a copy of the executable, and launch an interactive Windows Command Prompt. This allowed me to escape the restricted kiosk interface and obtain command-line access as KioskUser. After confirming my identity using whoami, I navigated to the user's Desktop and successfully retrieved the user flag.
To improve my access, I generated a Windows x64 Meterpreter reverse TCP payload using msfvenom, configured a Metasploit multi-handler, and hosted the executable using a Python HTTP server. I transferred the payload to the target using the Windows Certutil utility and executed it to establish a Meterpreter session. Subsequent system enumeration confirmed that the workstation was running Windows 11 24H2+ and belonged to a local workgroup.
During further enumeration, I discovered hardcoded MySQL credentials within the HTB Airways application's TypeScript source code. These credentials allowed me to authenticate to the htb_airways database and retrieve employee records containing email addresses, authentication codes, and staff roles. I also examined the current user's Windows privileges and group memberships, identifying membership in the custom Printer Administrators group.
I continued investigating the application's configuration files and MySQL installation. Although some sensitive configuration files were inaccessible, a readable maintenance batch script exposed the MySQL root password. Using these credentials, I authenticated as the database root user and confirmed that the account possessed elevated privileges, including FILE and GRANT permissions. Further inspection with icacls revealed that the MySQL plugin directory granted Modify permissions to Authenticated Users, introducing another significant security weakness.
I exploited this misconfiguration by uploading the lib_mysqludf_sys_64.dll library into the writable MySQL plugin directory through Meterpreter. After re-establishing my Meterpreter session and preparing an additional reverse shell payload, I registered the sys_eval() User-Defined Function using the MySQL root account. Executing whoami through this function returned NT AUTHORITY\SYSTEM, confirming that the MySQL service executed operating system commands with SYSTEM-level privileges.
Finally, I leveraged the registered MySQL UDF to execute a command that read C:\Users\Administrator\Desktop\root.txt, successfully retrieving the root flag and completing the machine.
Overall, Touch demonstrates how multiple security weaknesses can be chained together to achieve full system compromise. The attack path progresses from unauthenticated API information disclosure and credential reuse to kiosk escape, database credential exposure, and ultimately SYSTEM-level command execution through an insecure MySQL configuration.
Protected Page
The first step in owning the Touch 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 Touch machine and I was assigned an IP address (10.129.54.50).
Touch – Initial Target Information
I started the Touch machine on Hack The Box and noted that it is a Easy-rated Windows target. The machine provides a hint and credentials, which I can use during the first stage of enumeration.
I recorded the assigned target IP as 10.129.54.50 and confirmed that the machine was online. Since credentials are provided from the beginning, I will use them against any discovered authentication services during enumeration. My next step is to run an Nmap scan to identify the exposed ports and services before deciding where to authenticate.
Nmap Enumeration
I started by running an aggressive Nmap scan against the target to identify open ports, running services, and the underlying operating system.
The scan revealed four open TCP ports: 135 (RPC), 3389 (RDP), 5985 (WinRM), and 8443 (HTTP). The service fingerprints indicated that the target was running Windows, although Nmap couldn't determine the exact version. Port 5985 suggested that Windows Remote Management was enabled, potentially providing remote access if valid credentials were obtained.
More interestingly, port 8443 hosted a web application titled Nexion DeviceHub, which redirected to a /login page. Since this appeared to be a custom web application, I decided to focus my initial enumeration on port 8443 to investigate its functionality and identify potential attack vectors.
Hosts File Configuration
After identifying the target's open services, I added the target IP address to my local /etc/hosts file, mapping it to the hostname touch.htb for easier access during enumeration.
I used sudo to obtain the necessary privileges to modify the hosts file, while tee -a appended the entry without overwriting existing records. This allowed me to access the target using touch.htb instead of its IP address. Configuring the hostname also ensured that any web applications relying on hostname-based routing could resolve correctly during further enumeration.
Web Application Enumeration
After identifying port 8443 as an HTTP service, I opened the target's web application in my browser to investigate its functionality and look for potential entry points.
I was redirected to a login page for Nexion DocReader, identified as DeviceHub DH-100 - Gate B7. The application required a device password to authenticate, indicating that access to its functionality was restricted.
I also noticed a Scan Staff Badge option and a Forgot your password? link, suggesting additional authentication or recovery mechanisms. Since I didn't have valid credentials, I decided to investigate these features further and look for potential weaknesses in the authentication process.
Directory and Endpoint Enumeration
After discovering the Nexion DocReader login page, I used ffuf to enumerate hidden directories and endpoints that might expose additional functionality or potential attack surfaces.
I used the raft-small-words.txt wordlist to fuzz the web application's root directory, while -fs 0 filtered out empty responses. The scan revealed two interesting endpoints: /login, which returned 200 OK, and /api, which returned 403 Forbidden.
The /login endpoint confirmed the authentication page I had previously discovered, while /api suggested the presence of a restricted API. Since the API endpoint was accessible but denied unauthenticated requests, I decided to investigate it further for potential misconfigurations or authentication weaknesses.
API Endpoint Enumeration
After discovering the /api endpoint during directory fuzzing, I manually accessed it through my browser to investigate its response and determine whether it exposed any useful information.
The application returned a JSON response containing {"error":"Authentication required"}, confirming that the endpoint existed but required authentication. This also explained the 403 Forbidden status code observed during the ffuf scan.
The response suggested that the application implemented access controls to protect its API functionality. Since unauthenticated access was restricted, I decided to investigate the authentication mechanism further to identify potential weaknesses or alternative ways to interact with the API.
API Endpoint Fuzzing
After confirming that the /api endpoint required authentication, I performed additional fuzzing using a custom API endpoint wordlist to discover potentially accessible routes.
I used the api-endpoints.txt wordlist containing 295 potential API paths, while -fs 0 filtered out empty responses. The scan revealed an interesting endpoint, /api/status, which returned 200 OK with a response size of 116 bytes.
Unlike the restricted /api endpoint, this route appeared to be accessible without authentication. This suggested that certain API functionalities might be publicly exposed, so I decided to investigate /api/status further to determine whether it disclosed useful information about the application or underlying system.
API Status Enumeration
After discovering the /api/status endpoint through fuzzing, I accessed it directly in my browser to investigate what information it exposed without authentication.
The endpoint returned a JSON response containing information about the device, including its model, serial number, firmware version, operational status, and uptime. I identified the device as Nexion DeviceHub DH-100, with serial number NX-DH-2024-B7042, running firmware version 1.4.2.
The response also confirmed that the device was online, with an uptime value of 219. Since this information was accessible without authentication, I considered it a potential information disclosure and decided to investigate whether the exposed firmware version or serial number could help identify additional attack vectors.
Authentication Bypass Using Exposed Device Serial Number
After discovering the device serial number through the /api/status endpoint, I attempted to access the dashboard directly to determine whether authentication was required.
I was redirected to the /login page, where I entered the previously exposed serial number NX-DH-2024-B7042 as the device password.
Surprisingly, the application accepted it, and I was successfully authenticated and redirected to the Nexion DeviceHub dashboard. The dashboard exposed several administrative features, including Scanner, Printer, Activity Log, and Settings, along with masked device credentials.
This revealed a significant authentication weakness, as a publicly accessible device serial number could be reused as a valid password. With access to the management interface, I proceeded to enumerate its features for potential privilege escalation and further exploitation.
Credential Disclosure Through Dashboard
After successfully authenticating to the Nexion DeviceHub dashboard, I examined the connected scanner and printer devices and noticed that both displayed masked usernames and passwords with a Show option.
I clicked the Show buttons beside the credential fields, which revealed the username and password stored for both devices. The exposed credentials were:
- Username:
KioskUser - Password:
K!0sk2026#
Both devices used the same credentials, indicating potential credential reuse. Since the target also exposed RDP (3389) and WinRM (5985), I decided to investigate whether these credentials could provide remote access to the underlying Windows system.
Initial Access via Remote Desktop (RDP)
After obtaining the KioskUser credentials from the Nexion DeviceHub dashboard, I attempted to authenticate to the target through RDP (port 3389) using xfreerdp.
I used /dynamic-resolution to enable automatic screen resizing, +clipboard for clipboard sharing, and /cert:ignore to bypass certificate verification. Although FreeRDP displayed several warnings, including SSL_NOT_ALLOWED_BY_SERVER, the connection was successfully established. I was authenticated as KioskUser and gained access to the HTB Airways self-check-in workstation, displaying a kiosk interface with a Staff Login option.
This confirmed that the credentials exposed through the web dashboard were also valid for Windows remote access. With an active RDP session, I proceeded to investigate the kiosk environment for potential escape techniques and further access to the underlying system.
HTB Airways Kiosk Enumeration and Booking Lookup
After gaining RDP access as KioskUser, I began exploring the HTB Airways self-check-in kiosk to understand its functionality and identify potential entry points. I clicked the Touch Screen to Begin button, which opened the passenger check-in interface and prompted me to select my preferred language.
I selected English, which redirected me to the Find Your Booking page, where the application requested a booking reference and passenger's last name.
The Hack The Box machine information provided two values that I could use to test the booking lookup functionality.
Booking Reference: KS7X2MLast Name: CRAWFORD
I entered the provided details into their respective fields using the kiosk's on-screen keyboard.
After entering both values, I clicked GO to finish the input and prepare the booking lookup. The interface also displayed a Find Booking button, which appeared to initiate the booking verification process.
I proceeded with the booking lookup to investigate the next stage of the check-in workflow and identify any additional functionality that could be useful during further enumeration.
Booking Lookup and Session Timeout
After entering the provided booking reference and last name, I clicked Find Booking to retrieve the passenger's reservation details.
However, the application returned an error message stating "Booking not found. Please check your details and try again." I noticed that the kiosk had a session countdown timer, which limited the time available to complete the check-in process.
If the timer expired before I completed the booking lookup, the application could reject the request and display the error message. To avoid this issue, I restarted the check-in process and entered the provided booking details as quickly as possible.
This highlighted the importance of completing the booking lookup within the allocated session time before proceeding to the next stage of the check-in workflow.
Passport Scanner Enumeration
After successfully entering the provided booking reference and last name, I was redirected to the Document Verification page, where the kiosk required me to scan my passport before proceeding.
The application displayed a virtual Nexion DocReader SR-4200 scanner with a Scan Passport button. I clicked Scan Passport to initiate the document verification process, but the application returned the following error:
I clicked Try Again several times, attempting to complete the scanning process, but the same error appeared each time. Despite the scanner being marked as online in the DeviceHub dashboard, the kiosk was unable to read the document successfully.
Since I couldn't proceed past the document verification stage, I decided to investigate alternative ways to interact with the kiosk and potentially bypass the scanning restriction.
Passport Scanner Bypass Attempt
Since the passport scanner repeatedly failed to read the document, I returned to the Nexion DeviceHub management interface to investigate whether changing the scanner's operational status would affect the verification process.
I navigated to the Scanner section, which displayed the Nexion DocReader SR-4200 device information, including its firmware version, connection status, and management controls.
I clicked the Power Off button to disable the scanner, changing its status from ONLINE to OFFLINE. The dashboard confirmed that the scanner was successfully powered off, while the printer remained online.
I then returned to the HTB Airways kiosk through my RDP session and attempted the passport verification process again. My goal was to determine whether the application would handle an offline scanner differently, potentially allowing me to bypass the document verification stage.
Kiosk Escape via Scanner Error Hyperlink
After disabling the passport scanner through the DeviceHub dashboard, I returned to the HTB Airways kiosk and attempted to scan the passport again.
This time, the application displayed an error stating that the Nexion DocReader SR-4200 had stopped responding, along with error code SCN-ERR-4092. The error dialog also contained a clickable troubleshooting hyperlink:
I clicked the hyperlink, which launched Microsoft Edge inside the remote Windows session and attempted to open the support page.
Although the browser displayed a "You're not connected" error, Microsoft Edge remained accessible outside the kiosk interface. This revealed a potential kiosk escape vulnerability, as the scanner's error dialog allowed me to launch an external application despite the restricted environment.
With access to Microsoft Edge, I decided to investigate whether its features could provide further access to the underlying Windows operating system.
Kiosk Escape via Microsoft Edge - Command Prompt Access
After launching Microsoft Edge through the scanner's troubleshooting hyperlink, I investigated whether the browser could be used to escape the restricted kiosk environment and access the underlying Windows system.
I pressed Ctrl + O to open the browser's file selection dialog, which allowed me to browse the local filesystem.
I navigated to the Windows System32 directory and located the Command Prompt executable. I selected cmd.exe and clicked Open, which caused Microsoft Edge to save a copy of the executable to the Downloads directory.
I then opened the browser's Downloads panel and clicked Open file to execute the downloaded cmd.exe.
This successfully launched a Windows Command Prompt, providing me with an interactive shell under the KioskUser account.
At this point, I had successfully escaped the kiosk's restricted interface and gained command-line access to the underlying Windows operating system. With an interactive shell available, I could now begin enumerating the system, checking user privileges, and identifying potential privilege escalation opportunities.
Current User Enumeration
After successfully escaping the kiosk environment and obtaining an interactive Windows Command Prompt, I began enumerating the system to identify the account under which my shell was running.
I executed the whoami command to determine my current username and domain or computer name.
The command returned the following output:
This confirmed that I was operating as KioskUser on the Windows machine KIOSK-042. Although I had successfully obtained command-line access, I was still running under the kiosk user account rather than an administrator account.
With my current user context confirmed, I proceeded to investigate the account's privileges and look for potential privilege escalation opportunities.
User Flag Enumeration
After confirming that I was operating as KioskUser, I navigated from the Downloads directory to the user's Desktop to search for the user flag. I used the following commands to navigate to the Desktop, list its contents, and read the flag file.
The dir command revealed a file named user.txt in C:\Users\KioskUser\Desktop.
I executed type user.txt to display the contents of the file, successfully retrieving the user flag. Although the terminal displayed several Windows message-text errors, they did not prevent me from accessing the file.
With the user flag obtained, I proceeded to enumerate the system further to identify potential privilege escalation paths and gain administrative access.
Reverse Shell Payload Preparation
After obtaining the user flag, I prepared a Meterpreter reverse TCP payload to establish a more flexible session with the target Windows machine. I first ran ip a to identify my Hack The Box VPN interface (tun0) and confirmed that my attacker IP address was 10.10.15.250.
I created a temporary directory at /tmp/share to store the payload and files intended for transfer. Using msfvenom, I generated a 64-bit Windows Meterpreter reverse TCP executable named shell.exe, configured to connect back to my VPN IP on port 4444.
The payload was generated successfully, producing a 7,680-byte executable. Finally, I started a Python HTTP server on port 8000 to make the executable accessible from the target machine. With the payload hosted, I was ready to transfer it to the Windows workstation and attempt to establish a reverse Meterpreter session.
Metasploit Reverse Shell Listener Setup
After generating the Meterpreter payload, I launched Metasploit Framework to configure a reverse TCP listener that would receive the incoming connection from the target Windows machine.
I used the exploit/multi/handler module and configured it with the same Windows x64 Meterpreter reverse TCP payload generated earlier. I set LHOST to my Hack The Box VPN IP address, 10.10.15.250, and LPORT to 4444, ensuring both settings matched the payload configuration.
The output confirmed that the reverse TCP handler had successfully started and was listening on 10.10.15.250:4444. At this stage, no Meterpreter session had been established, as the handler was waiting for the target to initiate a connection.
With the listener running, I proceeded to transfer and execute the payload on the Windows workstation to establish a Meterpreter session.
Payload Transfer Using Certutil
After setting up the Metasploit reverse TCP listener, I returned to the Windows Command Prompt and used the built-in certutil utility to download the Meterpreter payload from my Kali Linux HTTP server.
I used -urlcache to retrieve the file, -split to process the downloaded content, and -f to force the download, saving the executable as shell.exe. The command retrieved the payload from my attacker machine at 10.10.15.250:8000 and saved it to the current working directory, C:\Users\KioskUser\Desktop.
The output confirmed that the transfer completed successfully with the message "CertUtil: -URLCache command completed successfully." This demonstrated that I could transfer files from my Kali Linux machine to the compromised Windows workstation using a native Windows utility.
With the payload successfully downloaded, I was ready to execute shell.exe and attempt to establish a Meterpreter session through my waiting Metasploit listener.
Meterpreter Reverse Shell Execution
After successfully transferring shell.exe to the Windows workstation, I executed the payload through the KioskUser Command Prompt to establish a reverse Meterpreter connection.
I had already configured the Metasploit multi/handler to listen on 10.10.15.250:4444, using the windows/x64/meterpreter/reverse_tcp payload.
Once I executed shell.exe, the Windows machine initiated a reverse TCP connection to my Kali Linux listener, triggering the Meterpreter payload. Metasploit successfully delivered the 232,006-byte Meterpreter stage and reported that Meterpreter sessions 1 and 2 had been opened from 10.129.54.50.
This confirmed that I had successfully established Meterpreter access to the Windows target, providing an interactive session for further system enumeration. With the Meterpreter session established, I proceeded to investigate the current user's privileges and identify potential paths toward administrative access.
Meterpreter System Enumeration
After establishing a Meterpreter session, I began enumerating the compromised Windows workstation to identify its operating system, architecture, and system configuration.
I executed the sysinfo command to retrieve detailed information about the target, then used shell to spawn a native Windows Command Prompt.
The output identified the target as KIOSK-042, running Windows 11 24H2+ (Build 26100) on an x64 architecture. I also confirmed that the machine belonged to the WORKGROUP rather than an Active Directory domain, with one user currently logged on.
After executing shell, Meterpreter successfully created Process 6508 and Channel 1, providing access to a native Windows command shell. The shell reported Windows version 10.0.26100.9457, confirming the underlying OS build. With the system information gathered and a Windows shell available, I proceeded to enumerate local privileges, installed software, and potential privilege escalation vectors.
Database Credential Enumeration
After obtaining a Windows shell, I continued enumerating the HTB Airways application files to identify sensitive configuration details and potential privilege escalation opportunities.
I discovered a TypeScript database configuration file and used the type command to inspect its contents.
The source code revealed that the application used MySQL and contained hardcoded fallback database credentials.
I also identified that the application attempted to load its configuration from C:\ProgramData\HTB Airways\db-config.ini, falling back to the hardcoded credentials if the file could not be read. This exposed a potential hardcoded credentials vulnerability, although the active database credentials still needed to be verified.
With the database connection details identified, I decided to investigate the configuration file and determine whether these credentials could provide access to the application's MySQL database.
MySQL Database Enumeration
After discovering the hardcoded MySQL credentials, I authenticated to the htb_airways database using the kiosk_app account to enumerate sensitive employee information.
I ran the following command to retrieve employee IDs, email addresses, authentication codes, roles, and account statuses from the _htb_staff table.
The query executed successfully, confirming that the hardcoded credentials provided access to the MySQL database. I retrieved 32 employee records, including staff email addresses, authentication codes, and roles such as Duty Manager, Operations Manager, and Aviation Security Lead.
I also noticed that every account had an active value of 1, indicating that all retrieved employee accounts were enabled. The exposed auth_code values were particularly interesting, as they could potentially be used for staff authentication or further exploitation of the HTB Airways application.
Windows Privilege and Group Enumeration
After enumerating the MySQL database, I investigated the KioskUser account's privileges and group memberships to identify potential privilege escalation opportunities.
I executed the following commands to list my assigned Windows privileges and security groups.
The whoami /priv output revealed that SeChangeNotifyPrivilege was the only enabled privilege, with no obvious high-risk privileges such as SeImpersonatePrivilege or SeDebugPrivilege available. However, the whoami /groups output revealed that KioskUser belonged to a custom local group named KIOSK-042\Printer Administrators.
I also confirmed that the account belonged to Remote Desktop Users and operated at a Medium Mandatory Integrity Level, indicating that I did not currently have elevated administrative privileges. The Printer Administrators membership caught my attention because it suggested that the account might have additional permissions related to Windows printer management.
I decided to investigate the printer configuration and associated permissions further, as this custom group could potentially provide a path toward privilege escalation.
MySQL Configuration and Sensitive File Enumeration
After identifying the Printer Administrators group membership, I continued enumerating application configuration files to look for additional credentials and potential privilege escalation opportunities.
I listed the contents of C:\ProgramData\HTB Airways and attempted to inspect the database configuration and MySQL settings.
I discovered several interesting files, including db-config.ini, db-sync-replica.ps1, and refresh-dates.bat, which suggested automated database maintenance tasks. However, attempting to read db-config.ini returned Access is denied, indicating that my current account lacked the necessary permissions.
I then examined C:\MySQL\my.ini and confirmed that MySQL was configured to listen on 127.0.0.1:3306, restricting direct database connections to the local machine. Although the MySQL configuration did not expose additional passwords, the database synchronization PowerShell script caught my attention as a potential avenue for further enumeration and privilege escalation.
MySQL Privilege Enumeration and Root Credential Discovery
After identifying the database configuration files, I investigated the kiosk_app account's MySQL privileges and examined the application's maintenance scripts for additional credentials.
I executed the following commands to inspect database permissions and review the scheduled maintenance files.
I confirmed that kiosk_app had full privileges over the htb_airways database but could not access the protected mysql.user table. While inspecting refresh-dates.bat, I discovered a hardcoded MySQL root password, HTB@irw4ys_DB!2026, used to execute the maintenance SQL script.
The refresh-dates.sql file contained queries that updated flight schedules, booking timestamps, synchronization metadata, and Nexion device information. Interestingly, the script also reset all devices to an online state, potentially explaining changes to the scanner's operational status.
With the MySQL root credentials exposed, I decided to verify whether they provided elevated database access and could reveal additional privilege escalation opportunities.
MySQL Root Access and Plugin Directory Permissions
After discovering the hardcoded MySQL root password, I authenticated to the database as root to verify its privileges and identify potential privilege escalation opportunities.
I also examined the permissions assigned to the MySQL plugin directory using the following commands.
The query executed successfully, confirming that I had obtained MySQL root access, with both Grant_priv and File_priv enabled. I also identified additional database accounts, including nexion_app and repl_kiosk_b7, which could be useful for further enumeration.
The icacls output revealed that Authenticated Users had Modify (M) permissions on C:\MySQL\lib\plugin, while administrators and SYSTEM had full control. This was particularly interesting because the directory could potentially allow a low-privileged user to place malicious MySQL plugin files.
Combining MySQL root privileges with a writable plugin directory suggested a potential path toward privilege escalation through MySQL User-Defined Functions (UDFs).
MySQL UDF DLL Upload via Meterpreter
After identifying that the MySQL plugin directory was writable, I attempted to upload a MySQL User-Defined Function (UDF) DLL to explore potential privilege escalation.
I initially ran the upload command inside the Windows CMD shell, but it failed because upload is a Meterpreter command rather than a native Windows command. I pressed Ctrl + Z and entered y to background the Windows shell and return to the Meterpreter prompt.
The upload completed successfully, transferring the 7.00 KiB DLL into C:\MySQL\lib\plugin\. This confirmed that my current session had sufficient permissions to write files into the MySQL plugin directory. With the DLL uploaded, I could investigate whether MySQL would load the UDF library and potentially execute operating system commands through the database service account.
Re-establishing Meterpreter Session
After successfully uploading the MySQL UDF DLL, I opened a fresh terminal to establish a new Meterpreter session on the target machine.
I configured a Metasploit multi-handler to listen for incoming reverse TCP connections on 10.10.15.250:4444.
Once the listener was running, I returned to the Windows CMD shell and executed the previously uploaded payload.
The payload successfully connected back to my Metasploit listener, which transferred the Meterpreter stage and opened Meterpreter session 1.
The output confirmed a successful reverse connection from 10.129.54.50:54532 to 10.10.15.250:4444.
With a fresh Meterpreter session established, I could continue investigating the MySQL UDF configuration and potential privilege escalation opportunities.
Generating a New Meterpreter Payload
After establishing a fresh Meterpreter session, I generated another Windows x64 reverse TCP payload using msfvenom to prepare for the next stage of privilege escalation.
I ran the following command to create a new executable named sys_shell.exe.
I configured the payload to connect back to my Kali machine at 10.10.15.250 on port 4444, using the same reverse TCP connection settings as my Metasploit handler. The -f exe option generated a Windows executable, while -o /tmp/sys_shell.exe specified the output file location.
The output confirmed that msfvenom successfully generated a 64-bit Windows executable with a payload size of 510 bytes and a final file size of 7,680 bytes. With sys_shell.exe generated, I was ready to transfer it to the target machine for the next stage of my privilege escalation attempt.
Uploading Meterpreter Payload to Windows
After generating the new Meterpreter payload, I used my existing Meterpreter session to transfer the executable to the target Windows machine.
I ran the following command to upload sys_shell.exe into the Windows temporary directory.
The command successfully transferred the payload from my Kali machine to C:\Windows\Temp\sys_shell.exe on the target. The output confirmed that 7.50 KiB of data was uploaded, reaching 100% completion without errors.
I chose the Windows Temp directory as a staging location because it is commonly writable by standard user accounts. With the payload successfully uploaded, I had the executable in place for the next stage of my privilege escalation attempt, although it had not yet been executed.
MySQL UDF Registration for Privilege Escalation
After uploading sys_shell.exe, I opened a Windows shell through Meterpreter and attempted to execute the payload using the MySQL sys_eval() function.
I initially ran the following command using the previously discovered MySQL root credentials.
However, MySQL returned ERROR 1046 (3D000): No database selected, preventing the command from executing successfully. I opened another Meterpreter shell and registered the sys_eval function using the previously uploaded UDF DLL.
This time, the command completed without errors, indicating that sys_eval was successfully registered as a MySQL User-Defined Function. With the UDF registered, I could proceed to test whether it allowed operating system command execution under the MySQL service account, potentially providing a path to elevated privileges.
MySQL UDF Privilege Escalation to SYSTEM
After successfully registering the sys_eval User-Defined Function, I tested whether it could execute operating system commands with elevated privileges.
I authenticated to MySQL as root and executed the whoami command through the newly registered UDF.
The command executed successfully and returned the following output:
This confirmed that the MySQL service was running as NT AUTHORITY\SYSTEM, allowing commands executed through sys_eval() to inherit SYSTEM-level privileges. By combining the exposed MySQL root credentials, writable plugin directory, and malicious UDF library, I successfully achieved arbitrary command execution as SYSTEM.
With SYSTEM-level command execution confirmed, I could proceed to establish an elevated reverse shell and retrieve the root flag.
Root Flag Retrieval via MySQL UDF
After confirming that the MySQL sys_eval() function executed commands with NT AUTHORITY\SYSTEM privileges, I attempted to retrieve the root flag from the Administrator's Desktop.
I authenticated to MySQL as root and used the UDF to execute a Windows type command against the protected flag file.
The command executed successfully, allowing me to read the contents of root.txt despite operating from the lower-privileged KioskUser shell. The output revealed the root flag:
This confirmed that I had successfully leveraged the MySQL UDF vulnerability to execute commands with SYSTEM privileges and access protected administrator files. With both the user and root flags retrieved, I successfully completed the Touch HTB machine, demonstrating a privilege escalation path involving exposed database credentials, insecure plugin directory permissions, and SYSTEM-level MySQL execution.
asdf
Keywords:
HackTheBox - Stream Season 12 Complete CTF Solution
Scaffold - HackTheBox Machine Writeup
KS7X2M - Jenny Crawford
HTB Writeup - Scaffold
BlockSynergy - HackTheBox
TrustFall - HackTheBox Season 11 Writeup
HackTheBox - Scaffold
Management HTB Writeup
Trustfall-htb
blocksynergy htb season 11 machine writeup
I just solved Touch from Hack the Box
blocksynergy-htb exploit
Management - HTB Walkthrough Season 11 HTB Writeup
blocksynergy complete writeup (user and root flag)
BlockSynergy HTB Writeup - Insane Linux Box Walkthrough
Layover HTB Writeup
BlockSynergy Machine HackTheBox
HTB BlockSynergy Complete Writeup - Season 11 Machine
htb-s11-blocksynergy
BlockSynergy Writeup - HackTheBox
I just solved Layover from Hack the Box
Owned BlockSynergy from Hack The Box
KioskUser
layover.htb
trustfall hack the box writeup
Beginners Guide to Conquering BlockSynergy on HackTheBox
K!0sk2026#
HackTheBox - Scaffold
HTB Blocksynergy Challenges-Walkthroughs
Touch HTB Writeup
trustfall hack the box walkthrough
stream.htb
Touch - HackTheBox Machine Writeup
I just solved DarkZeroReturns from Hack the Box
Touch HTB Walkthrough
HackTheBox Stream Writeup - Aero Season 12 HTB Machine Walkthrough
Touch Machine Season 12 Aero HTB Writeups
Stream HTB Walkthrough
Touch HTB Season 12 Aero Walkthrough
Stream HTB Writeup
HTB Writeup - Touch
touch.htb
Hack The Box Scaffold - Hard Windows Machine






















.jpg)





























0 Comments