sqlmap, burp, and the simple injection I nearly missed
If you’ve done any CTF or lab, you know web attacks are the bread and butter. CEH Practical is no different. Web applications show up repeatedly—login forms, search boxes, file uploads, admin panels. It’s the easiest place to lose time, and the easiest place to find a flag hiding in plain sight.
I learned that the hard way. Let me tell you about a login form that nearly wasted 20 minutes of my life.
From the attacker terminal#
The scenario: I found a web app on a target. It had a login page. Username, password, a “Sign In” button. Classic.
My brain immediately went: SQL injection. Bypass authentication. Dump the database.
I fired up sqlmap like it was going out of style:
sqlmap -u "http://target/login.php" --data="user=admin&pass=test" --level=5 --risk=3 --dump
That --level=5 --risk=3 is the nuclear option. It tries every vector, every encoding, every delay. It’s also slow. Painfully slow. I sat there watching the output crawl, convinced the flag was hidden deep in some database table and I needed to be thorough.
Ten minutes later, nothing. No injection. I stared at the screen. Was I missing a parameter? Was the form protected? I re-ran the scan with a different user-agent. Still nothing.
Then I paused. Took a breath. Opened the browser’s dev tools and looked at the page source. Inside a comment, right above the login form, the developer had left a beautiful little note:
<!-- TODO: remove test account: guest / guest123 -->I typed guest / guest123 into the form. Logged in. Flag on the dashboard.
I’d overcomplicated it. The vulnerability wasn’t SQL injection—it was an information disclosure in the page source. The exam had hidden the flag in plain sight, and I’d been too busy running sqlmap on full-auto to notice.
Now, sometimes SQLi is the answer. And when it is, manual testing is often faster than sqlmap. For a simple authentication bypass:
Username: admin' OR '1'='1
Password: admin' OR '1'='1Or in the URL:
http://target/dashboard.php?id=1' OR 1=1 -- -
If there’s an error, you might see a MySQL error message, which itself can be a flag. One lab had me trigger an error that contained a path disclosure—flag was the full server path.
XSS in the exam is usually straightforward: find a field that reflects your input (search box, comment form, profile name), inject a basic payload like <script>alert('XSS')</script>, and confirm the popup. The challenge is recognising where the reflection happens. Sometimes it’s in the response body; sometimes it’s in a hidden input field that you need to break out of with a "> first.
The trick I settled into: test manually first. If it’s clearly SQLi, try ', ", OR 1=1, and errors before even opening sqlmap. If it’s XSS, <script>alert(1)</script> is your first probe. Don’t overthink it. The exam isn’t asking for a sophisticated XSS chain. It’s testing recognition, not advanced exploitation.
From the SOC side#
Web attacks are the most common thing in a SOC’s queue. SQLi and XSS attempts show up in WAF logs, proxy logs, and SIEM alerts all day.
SQLi from sqlmap has a dead giveaway: the default User-Agent string sqlmap/1.6#stable (http://sqlmap.org). A good WAF or SIEM rule catches that instantly. Even if an attacker changes the user-agent, the request patterns—repeating ' OR, UNION SELECT, -- -—trigger signature matches. In Splunk, a query like:
index=web_logs sourcetype=access_combined "* OR 1=1*" OR "* UNION SELECT *" OR "*sqlmap*"
…will light up.
If the SQLi is manual and error-based, you’ll see HTTP 500 responses with SQL error messages in the body (e.g., “You have an error in your SQL syntax”). A SIEM rule monitoring response codes and patterns can catch these, but many organisations don’t log response bodies. That’s a gap. The attacker’s error is hidden in the response, and if you’re only logging status codes, you might only see a 500 and not the “Access denied for user” message that confirms the injection.
XSS is trickier to detect on the server side. The malicious payload (<script>alert(1)</script>) might be in the request, but it’s just a string. If the WAF doesn’t have a rule for <script> tags, it passes through. The reflection happens in the browser, not on the server. So the SOC might see the request but have no idea the payload actually executed. That’s why content security policy (CSP) headers and client-side monitoring are critical—they catch what server logs miss.
If you’re a defender, this domain is your daily bread. Tune your WAF. Log request bodies. Look for sqlmap’s fingerprints. And for the love of everything, don’t leave test credentials in HTML comments. I will find them.
How this played out in the exam#
That login form with the guest credentials? That was a real moment. I laughed at myself after. 10 minutes of sqlmap on maximum aggression, and the flag was in the page source the whole time. It’s the perfect metaphor for the whole exam: stay curious, but stay simple.
I had another task that was clearly SQLi. I tried admin' OR '1'='1 in the username field, and suddenly I was logged in as the admin. Flag on the user profile page. That took 30 seconds. Manual testing saved me from another sqlmap time-sink.
The exam doesn’t want you to be a hacker genius. It wants you to recognise the pattern and not overcomplicate. I almost failed that test.
The two-sides takeaway#
Web attacks work because they target the logic layer, not the infrastructure. As an attacker, your best tool is your eyes—read the page source, check the response headers, try the dumbest thing first. As a defender, your best defense is comprehensive logging and a WAF that’s actually tuned. And please, audit your HTML comments.
Next post: the surprise domain—stego and crypto. Hiding data in images, cracking weak encryption, and why it matters more than you think.
Tools used
sqlmap→ automated SQLi detection and exploitation (signatured by default User-Agent, heavy request patterns, easy WAF detection)- Manual SQLi payloads →
' OR 1=1 --(fewer requests, still detectable in URI/body patterns) - Browser dev tools → page source inspection (no network noise, but flags in plain sight are a developer error, not an attack)
Burp Suite→ intercept and modify requests (normal HTTP traffic unless payloads are malicious, may trigger WAF if aggressive)- WAF/SIEM detection → signature-based rules for
<script>,UNION SELECT, sqlmap User-Agent; error-based SQLi leaks database info in response bodies - XSS detection gap → often only visible client-side; server logs may not confirm execution without CSP reporting or client-side monitoring
