From Default IIS Page to Critical SQL Injection

by

Ahmad Mugh33ra Dec 9, 2025

https://mugh33ra.medium.com/from-default-iis-page-to-critical-sql-injection-d0e9950c66fc

Why “boring” infrastructure often hides the most dangerous secrets

Sometimes the most dangerous vulnerabilities hide in plain sight, waiting for someone who refuses to give up.

Assalam-O-Alikum

My name is Ahmad Mugheera an Indivisual Security Researcher, Ethical Hacker and bug bounty hunter from Pakistan. Let’s Start

The Setup: Another Day, Another Program:

It was just another day on HackerOne’s private program. Like any seasoned hunter, I started with reconnaissance gathering subdomains using tools like Subfinder with all API keys enabled. After running httpx-toolkit to identify live hosts, I had my usual target list. I’d already reported two SQL injections before to this company.

The “Boring” Discovery That Changed Everything:

After hunting on three subdomains, I returned to my list looking for more interesting targets. As I reviewed the screenshots I’d taken of all subdomains, two of them with: default IIS pages.

example Default IIS page

Most hunters would scroll past these. Default pages? Boring. But then I remembered a piece of wisdom I’d read in a writup:

“No one will host blank or default pages because hosting costs money.”

Kudos to that hacker their words echoed in my mind as I decided to investigate further.

First Steps: Short Name Scanner and Initial Failure:

Before diving into fuzzing, I ran an IIS short name scanner. The result? Vulnerable. My excitement quickly turned to confusion I knew it was vulnerable, but I had no idea how to exploit it.

I began fuzzing with various wordlists. Hours passed. Zero results.

Frustrated, I took to X (formerly Twitter) with a simple post:

“Now what” accompanied by the scanner result screenshot.

shortname scanner result

A fellow hunter responded: “Try fuzzing with ‘@orwagodfather’ wordlists from GitHub.”

I shrugged. Why not? So I ran ffuf:

ffuf -u "https://target.com/FUZZ" -ac -fs 0 -w <(curl -s "https://raw.githubusercontent.com/orwagodfather/WordList/refs/heads/main/iis.txt")

Five minutes later: 200 OK.

https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fgiphy.com%2Fembed%2F5VKbvrjxpVJCM%2Ftwitter%2Fiframe&display_name=Giphy&url=https%3A%2F%2Fmedia.giphy.com%2Fmedia%2Fv1.Y2lkPTc5MGI3NjExMHE4NW9rOTcwcHMya2hsOWIzeWN6Y2ltdGMzdDJ6bWVndW9tdDl2NSZlcD12MV9naWZzX3NlYXJjaCZjdD1n%2F5VKbvrjxpVJCM%2Fgiphy.gif&image=https%3A%2F%2Fmedia0.giphy.com%2Fmedia%2Fv1.Y2lkPTc5MGI3NjExcjdpazNpNHMydTNmaGE3bG42bmpnN3U4Mmc5b2k5dGNzdWFsZjA3ZCZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw%2F5VKbvrjxpVJCM%2Fgiphy_s.gif&type=text%2Fhtml&schema=giphy

Not just any 200, but one with slightly increased content length. When I visited the endpoint, the “boring” IIS page transformed into a small website hiding behind the default facade.

The game was on. 🔥

Clicking Everything, Finding Nothing:

I clicked every link, button, and feature. Nothing. The site seemed secure. Then I remembered a presentation by one of my favorite hunter, 

HX007

, about pwning IIS websites. I reopened his slides and read until I reached a critical insight: “If fuzzing fails, try these extensions: xml, zip, txt, json, js, obj, asmx, xsl, dll…” etc E.G

ffuf -u "https://target.com/FUZZ.ext" -w wordlist.txt -ac -fs 0

Since FFUF’s extension fuzzing wasn’t working properly for me (it would test one extension and stop), IDK why 🤷‍♂️ I wrote a quick bash script for it.

#!/bin/bash

Default_WORDLIST="/usr/share/seclists/Discovery/Web-Content/big.txt"
EXTENSIONS="xml dll svc zip 7z htm html json js aspx asmx ashx debug"
url=$1
wordlist="${2:-$Default_WORDLIST}"
hostname=$(echo $url | cut -d "/" -f3)


if [[ -z "$url" ]]; then
    echo "[+] No url specified"
    exit 1
elif [[ ! "$url" =~ ^https?://([a-zA-Z0-9_.-]+\.)+[a-z].* ]]; then
        echo "[+] Url is not correct"
        exit 1
fi


if [[ -f "$wordlist" && -s "$wordlist" ]]; then
    echo "[+] Fuzzing with wordlist: "$wordlist""
    for ext in ${EXTENSIONS[@]}; do
        echo -ne "[+] Fuzzing Ext: "$ext"\n"
        ffuf -u "$url/FUZZ.$ext" -w "$wordlist" -ac -o "$hostname-ffuf.txt" #-rate 40
    done
else
    echo "[+] The file you specified does't exist or empty"
    exit 1
fi

The results were startling: inspection.aspx, research.aspx (SOAP API endpoints), and most importantly – build.xml

The Golden File: build.xml:

Opening build.xml was like finding a treasure map. It revealed:

  • Sensitive internal endpoints
  • DLL files
  • Hidden API routes
  • Infrastructure details

A snip from Build.xml:

<sources>
<include name=".\*.cs"/>
<include name=".\Admin\*.aspx.cs"/>
<include name=".\Admin\*.cs"/>    
<include name=".\test\*.aspx.cs"/>
</sources>

This was clearly an information disclosure, but I knew from experience: reporting it as-is would likely get marked “informative” with low priority. I needed impact.

The Chase Begins:

Analyzing the file, I found several endpoints. One of the Endpoint I tested /test – it redirected to an AWS test page (useless)😒. I checked every endpoint from the file. Nothing.

Disappointed, I closed my laptop and took a break.😣

The Hacker Mind:

The next day, I decided to move to another subdomain. But that little voice in my head: “Give it one more try. Just one.”

I argued back: “I’ve checked everything. Why waste more time?”

But the voice persisted.

So, I opened Burp Suite and started scrolling through HTTP history from the test page. That’s when One of the request looks weired and has: 5 parameters I’d missed earlier. One parameter caught my eye: group.

My mind raced: 🧠“What if this passes through a database?”

With nothing to lose, I injected a single quote: '

Boom. Database error.

😎 Error Based Sql injection

Confirmation and Exploitation:

I tested time-based payloads. They worked. This was real SQL injection.

I reached for Ghauri (my preferred SQL injection tool slightly better than sqlmap for its XOR-based payloads) and successfully exploited the vulnerability, extracting sensitive data from the database.

During that break, I thought: “Why not report the build.xml information disclosure anyway?”

I did. As expected: Closed as Informative (P5). The triager asked for proof of impact: “How can you access these DLL files and sensitive data?”

I tried but failed to demonstrate direct access.

Then came my moment of realization. On the SQL injection report, I added a note:

“You closed the build.xml report as informative, but I found this critical SQL injection by taking the endpoint from that file.”

One day later: They reopened the information disclosure report and resolved it. The SQL injection was triaged separately.

The Lessons That Matter:

  1. Default pages aren’t boring They’re often forgotten, unmaintained, and full of secrets.
  2. Community knowledge is gold That X reply saved the hunt.
  3. Persistence over talent The difference between finding nothing and finding critical bugs is often just one more attempt.
  4. Document everything HTTP history review saved this hunt.
  5. Connect the dots Relating findings can turn low-severity issues into high-priority fixes.

The Hacker’s Mindset:

When your hacker intuition tells you to give something “one last try” listen. That final attempt, that extra scroll through history, that one more parameter test that’s often where the gold is buried.

The infrastructure everyone ignored, the “boring” IIS page, the informative disclosure that “wasn’t exploitable” together, they formed a chain that led to a critical database compromise.

If you enjoyed this writeup, follow my journey:

Happy hunting, and remember:

Digging Deeper than automated scanners the gold is usually buried.👌

The most interesting targets are often hiding behind the most boring facades. ✌️

Leave a Comment