Pov HTB
POV HTB Overview Summary POV is a Windows-based Hack The Box machine that focuses heavily on: Local File Inclusion (LFI) ASP.NET ViewState deserialization credential extraction Windows privilege escalation The attack began with subdomain enumeration, which revealed a hidden development virtual host. A vulnerable file download functionality allowed arbitrary file reads through a Local File Inclusion vulnerability. This was leveraged to access the application's web.config file and extract sensitive ASP.NET machine keys. Using the leaked: validationKey decryptionKey a malicious ViewState payload was generated using ysoserial.net, resulting in Remote Code Execution on the IIS server. After obtaining an initial PowerShell shell as the sfitz user, local enumeration revealed a PowerShell credential export file (connection.xml) containing encrypted credentials for another user. Since the shell already existed on the target machine, the credentials were decrypted directly using PowerShell's Import-Clixml functionality. The recovered credentials belonged to the alaading user. Using RunasCs, a new shell was spawned successfully under this account. Finally, privilege escalation was achieved by abusing the dangerous Windows privilege: SeDebugPrivilege A Meterpreter payload was executed, followed by process migration into lsass.exe, resulting in a full NT AUTHORITY\SYSTEM compromise. The machine demonstrates a realistic attack chain involving: web exploitation ASP.NET deserialization abuse credential harvesting Windows privilege escalation SYSTEM process migration --- Attack Path Enumerate the target using Nmap Discover dev.pov.htb through subdomain fuzzing Exploit Local File Inclusion (LFI) Read web.config and extract ASP.NET machine keys Abuse ViewState deserialization using ysoserial.net Gain PowerShell reverse shell as sfitz Recover stored credentials from connection.xml Switch to alaading user using RunasCs Abuse SeDebugPrivilege Migrate into lsass.exe Obtain NT AUTHORITY\SYSTEM Enumeration} Initial Nmap Scan} The first step was to perform a service and version scan against the target machine to identify exposed services and possible attack surfaces. Nmap Scan Analysis From the Nmap scan, only a single port was exposed externally: | Port | Service | |---|---| | 80 | Microsoft IIS HTTP Server | Important observations: Microsoft IIS 10.0 Windows Server backend HTTP TRACE method enabled no additional externally exposed services Since only the web server was accessible, the web application became the primary attack surface. --- Enumerating the Website Opening the website in the browser displayed the following page: image From the webpage, the domain name was identified as: To ensure proper hostname resolution during further testing, the domain was added to the local hosts file. --- Subdomain Enumeration Since IIS environments commonly host multiple virtual hosts and development environments, subdomain fuzzing was performed using ffuf. A valid subdomain was discovered: The new subdomain was added to /etc/hosts: Exploring the Development Site Opening: redirected automatically to: Scrolling through the website revealed a downloadable CV section: image Since downloadable file functionality often introduces: file inclusion issues path traversal vulnerabilities insecure file handling this became an interesting target for further testing. Capturing the Request with Burp Suite} Burp Suite was started to intercept the request generated when clicking the download button. image The request revealed a file parameter controlling which file was downloaded. At this point, Local File Inclusion testing became possible. Testing for Local File Inclusion (LFI)} For Windows-based LFI payloads, the following SecLists payload collection was used: The original filename: was replaced with the following traversal payload: After sending the modified request, the response successfully returned the contents of the Windows hosts file: image This confirmed that the application was vulnerable to: Local File Inclusion (LFI) arbitrary file read path traversal At this stage, arbitrary file disclosure on the target system had been achieved. Reading Sensitive Configuration Files} Since the vulnerable endpoint was located inside the: directory, the next step was to attempt reading the IIS ASP.NET configuration file: The following payload was used: The request succeeded successfully: image The response revealed the contents of the ASP.NET configuration file: --- Interesting Findings from web.config Several important pieces of information were extracted from the configuration file: ASP.NET Machine Keys ASP.NET machine keys are highly sensitive because they are used for: ViewState signing ViewState encryption authentication token validation application integrity verification If exploitable conditions exist, leaked machine keys can sometimes lead to: ViewState deserialization attacks Remote Code Execution authentication bypasses Internal Development Port Another important discovery: Exploiting ASP.NET ViewState Deserialization After obtaining the ASP.NET machine keys from the web.config file, the next step was to determine whether the application was vulnerable to: ViewState deserialization signed ViewState tampering Remote Code Execution through ASP.NET gadget chains ASP.NET applications use: validationKey decryptionKey to protect ViewState integrity and encryption. If an attacker gains access to these keys and ViewState MAC protection is enabled improperly, it becomes possible to generate malicious signed ViewState payloads that the server will trust and deserialize. This can ultimately lead to Remote Code Execution. --- Using ysoserial.net} To generate a malicious ASP.NET ViewState payload, ysoserial.net was used. ysoserial.net is a well-known exploitation framework used for: .NET deserialization attacks ViewState exploitation gadget chain generation Remote Code Execution payload generation It supports multiple gadget chains capable of executing arbitrary commands when deserialized by vulnerable .NET applications. --- Preparing ysoserial.net The binary was downloaded and executed on a Windows machine. Since many payload generators are flagged by antivirus products due to their offensive functionality, Windows Defender realtime protection was temporarily disabled before execution. The following command was used to generate a signed malicious ViewState payload: Breakdown of Important Parameters | Option | Description | |---|---| | -p ViewState | Generates a ViewState payload | | -g WindowsIdentity | Uses the WindowsIdentity gadget chain | | --decryptionkey | AES decryption key extracted from web.config | | --validationkey | ViewState signing key | | --path | Valid application path | | -c | Command to execute remotely | The payload attempted to: download a file named test.txt from the attacker machine into C:\Windows\Temp\ If the server requested the file successfully, Remote Code Execution would be confirmed. Generated ViewState Payload ysoserial.net generated a large encoded ViewState payload: The output needed to be inserted into the vulnerable request inside Burp Suite. Testing for Remote Code Execution Burp Suite was reopened and the original CV download request was captured again. image The intercepted request was sent to: Burp Repeater The original ViewState value was then replaced with the malicious payload generated by ysoserial.net. Hosting the Test File Before sending the request, a local HTTP server was started to verify outbound connectivity and command execution: --- Confirming Remote Code Execution After clicking Send in Burp Repeater: image the local HTTP server received an inbound request from the target machine: This confirmed: successful ViewState deserialization arbitrary command execution outbound connectivity from the server At this point, Remote Code Execution had been achieved successfully. --- Generating a Reverse Shell Payload To obtain an interactive shell, a PowerShell reverse shell payload was generated using: The PowerShell #3 payload was selected. image The payload was saved locally as: Hosting the Reverse Shell Script A Python web server was started again to host shell.ps1: Generating Final ViewState Payload ysoserial.net was executed again, this time using a command that downloaded and executed the PowerShell reverse shell script: A new malicious ViewState payload was generated successfully. Starting the Reverse Shell Listener A Netcat listener was started locally: Triggering the Reverse Shell The newly generated ViewState payload was inserted into Burp Repeater again. image After sending the request, the Netcat listener received an inbound connection: A fully interactive PowerShell reverse shell had been obtained successfully. Enumerating User Files After obtaining the initial PowerShell shell, the next step was to enumerate: user directories documents configuration files stored credentials While exploring the sfitz user's Documents folder, an interesting XML file was discovered: The filename connection.xml immediately stood out because: PowerShell credential exports automation scripts scheduled task credentials are commonly stored in XML format using: Export-Clixml serialized PowerShell objects This became a high-value target for credential hunting. --- Reading the XML File The file contents were displayed using: Important findings: stored PowerShell credential object username: alaading encrypted password blob The password was stored as a: SecureString DPAPI-protected credential Understanding PowerShell SecureString PowerShell's Export-Clixml serializes credentials using: Windows DPAPI user-specific encryption keys This means: only the same user on the same machine can decrypt the password successfully Since command execution already existed on the target machine, the credential could be decrypted directly. Extracting the SecureString The encrypted blob was first saved into a text file: However, instead of cracking it manually, PowerShell itself could decrypt the credential automatically. Decrypting the Credentials The XML credential file was imported using: The password was then recovered using: The username was confirmed: At this point, valid credentials had been recovered successfully: | Username | Password | |---|---| | alaading | f8gQ8fynP44ek1m3 | Privilege Escalation via RunasCs Since valid credentials were available, the next step was to execute commands as the alaading user. For this purpose, RunasCs.exe was used. RunasCs is a tool that: works similarly to Windows runas supports password-based execution bypasses some interactive restrictions allows spawning reverse shells under another user context --- Downloading RunasCs The binary was downloaded from: A Python HTTP server was started locally to transfer the file: Transferring RunasCs to the Target Inside the compromised PowerShell session, the binary was downloaded into the Windows temp directory: Verifying the file: The transfer succeeded successfully. Preparing the Reverse Shell Listener A Netcat listener was started locally: Executing Commands as alaading RunasCs.exe was executed with the recovered credentials: Command Breakdown | Component | Purpose | |---|---| | alaading | target user | | f8gQ8fynP44ek1m3 | recovered password | | cmd.exe | process to launch | | -r | reverse shell mode | The tool authenticated successfully and connected back to the attacker's listener. Receiving the Shell Checking the listener: The shell context was verified: A new shell as the alaading user had been obtained successfully. User Flag Navigating to the user's desktop: Privilege Escalation After obtaining a shell as the alaading user, the next step was to enumerate the user's privileges to identify possible privilege escalation vectors. Using: returned: One particularly important privilege was enabled: Understanding SeDebugPrivilege SeDebugPrivilege is a powerful Windows privilege that allows a user to: debug processes inspect protected process