Media HTB
MEDIA HTB Box Overview Media is a Windows Server 2022 machine that revolves around abusing an automated media review process. The attack begins by leveraging a file upload feature intended for job applicants and abusing a legacy Windows Media Player playlist file to trigger outbound SMB authentication. Capturing and cracking the leaked NTLMv2 hash provides valid user credentials and initial access through SSH. The privilege escalation path requires a deeper understanding of the application's internal workflow. By analyzing how uploaded files are processed, it becomes possible to predict upload locations, abuse NTFS junction points, gain remote code execution through a PHP web shell, and ultimately leverage Windows token privileges to escalate from LOCAL SERVICE to NT AUTHORITY\SYSTEM. Attack Path Enumeration Nmap Scans Analyzing Nmap Scans From the Nmap scan, we can identify the following services: | Port | Service | |--------|---------| | 22 | SSH | | 80 | HTTP | | 3389 | RDP | Some important observations: The target is running Windows Server 2022. SSH access is enabled through OpenSSH for Windows. Apache is hosting a website called ProMotion Studio. RDP is exposed on port 3389. No SMB or Active Directory-related services are exposed. Adding Hostname to /etc/hosts The hostname discovered during enumeration was: Adding it to the hosts file: Enumerating the Web Application Browsing the HTTP service in the browser revealed the following website: Screenshot 2026-05-30 at 00-52-15 Scrolling down revealed a file upload functionality. Screenshot 2026-05-30 at 00-53-05 To understand how the application handled uploads, I submitted a test file. Screenshot 2026-05-30 at 00-57-59 The application responded with: This confirms that uploaded files are reviewed by the HR team. At first, nothing looked particularly interesting. However, one line immediately stood out: Upload a brief introduction video (compatible with Windows Media Player) This looked like a deliberate hint. Since uploaded files are reviewed using Windows Media Player, I started researching potential attack vectors related to Windows Media Player. Researching Windows Media Player NTLM Leaks During research, I came across the following article: Screenshot 2026-05-30 at 01-12-18 Reference: https://www.morphisec.com/blog/5-ntlm-vulnerabilities-unpatched-privilege-escalation-threats-in-microsoft/ The article discusses how legacy Windows Media Player playlist files can be abused to trigger outbound SMB authentication and leak NTLM hashes. Creating a Malicious .WAX File The article provided an example payload that could be adapted for this attack. Creating a malicious .wax file: Screenshot 2026-05-30 at 01-15-35 Setting Up Responder Before uploading the malicious .wax file, I started Responder to capture any incoming NTLM authentication requests. Now I uploaded the virus.wax file that I had created earlier. Screenshot 2026-05-30 at 01-20-28 After uploading the file and waiting for HR to review it, I received an NTLMv2 hash in Responder. Success! The uploaded .wax file was opened using Windows Media Player, which attempted to access the remote SMB resource and leaked the NTLMv2 hash of the user enox. Cracking the Hash I saved the captured hash into a file named enox-hash. Using John the Ripper: Recovered credentials: Validating the Credentials First, I validated the credentials against RDP. The credentials were valid successfully. Although the credentials worked for RDP authentication, interactive RDP access was not allowed. Next, I tested SSH access. The user had SSH access to the target. SSH as enox Successfully obtained a shell as the enox user. User Flag Privilege Escalation Enumeration While enumerating the user's profile, I checked the Documents directory and discovered an interesting PowerShell script named review.ps1. The presence of a script named review.ps1 looked interesting, especially since the application involved HR reviewing uploaded files. Inspecting review.ps1 Let's inspect the contents of the script. After reading the script, we can understand how uploaded files are processed. The script continuously monitors: Whenever a new upload appears, it: Reads the filename and random folder name from todo.txt Opens the uploaded file using Windows Media Player Waits 15 seconds Kills the media player process Removes the processed entry This explains how our malicious .wax file was reviewed automatically. Inspecting the Uploads Directory Let's inspect the uploads directory: Checking the contents of todo.txt: Interesting. The application stores uploaded files inside a folder named using a random value. Inspecting that directory: This confirms that uploaded files are stored under: Investigating the Upload Mechanism Next, I wanted to understand how the folder names were generated. The web application files were located in: Reading index.php revealed the upload logic: This was the key finding. The upload directory name is generated using: Since we control all three fields, we can predict the upload directory before uploading a file. Calculating a Predictable Upload Folder Using the values: Calculating the MD5 hash: The application will therefore store our upload in: Abusing Junction Points Since the enox user has write permissions on the uploads directory, we can create a junction point that redirects the upload location to the web root. Creating a junction: The junction was created successfully. Now any file uploaded into that folder will actually be written into: Uploading a PHP Web Shell Creating a simple PHP web shell: When uploading the file, the following values were used: This ensures that the generated MD5 hash matches the junction point we created. Uploading the PHP shell: Screenshot 2026-06-01 at 01-01-34 --- Confirming the Upload Checking the web root: Success! The uploaded PHP file was written directly into the web root. Testing the Web Shell Browsing to: Screenshot 2026-06-01 at 01-05-19 The command executed successfully, confirming remote code execution through the uploaded PHP shell. Getting a Shell as Local Service Now that we had a working web shell, the next step was to obtain a more stable interactive shell. I generated a PowerShell reverse shell payload from: and selected URL Encoding. Screenshot 2026-06-01 at 01-07-56 Before executing the payload, I started a Netcat listener: Executing the reverse shell through the web shell: Screenshot 2026-06-01 at 01-08-39 After visiting the URL, I received a connection on my listener: Checking the current user: The shell was running as NT AUTHORITY\LOCAL SERVICE. Privilege Enumeration Checking the available privileges: The most interesting privilege here was: Although it was marked as Disabled, it was still assigned to the account. While researching privilege escalation paths, I came across the following guide: The guide explains how to restore a full service token using FullPowers. Using FullPowers Download: I downloaded FullPowers.exe to my attacker machine and started a temporary web server: Downloading the binary onto the target: Verifying the file: Obtaining a Full Service Token I generated another PowerShell reverse shell payload and started a new listener: Executing FullPowers: After a few seconds: A new shell was obtained. Checking privileges again: Perfect. The important privilege now available was: This opens the door for several token impersonation attacks, including GodPotato. Exploiting SeImpersonatePrivilege with GodPotato Download: I downloaded the binary and hosted it using the Python web server: Downloading it onto the target: Verifying the file: Getting a SYSTEM Shell I generated another PowerShell reverse shell payload and started a listener: Executing GodPotato: Catching the SYSTEM Shell A few moments later: Checking the current user: Success! We now have a SYSTEM shell on the target. Root Flag Navigating to the Administrator desktop: Final Thoughts Media was an excellent example of how multiple low-to-medium severity issues can be chained together into a full system compromise. None of the individual findings were particularly devastating on their own, but when combined, they created a realistic attack path from an unauthenticated user to SYSTEM access. The standout aspect of the machine was the abuse of Windows Media Player playlist files to leak NTLM credentials through an automated review process. The privilege escalation phase was equally rewarding, requiring source code analysis, an understanding of NTFS junction points, and knowledge of modern Windows token abuse techniques. Overall, Media provides a well-balanced challenge that blends web application testing, credential attacks, Windows internals, and privilege escalation into a smooth and realistic attack chain. See you in the next writeup, Untill keep Hacking!!!! ```