SQL Injection in a PCAP: Find the Probe and the Leak
The web team says the shop at shop.example logged a burst of 500 errors late last night. A tap in front of the web server was already recording, so you have a few minutes of plain-HTTP traffic from around that time.
Your job: decide whether the errors were a bug or an attack, and if an attack, whether it got anything. The web server is 10.50.0.20 in the DMZ; visitors arrive from the internet through the gateway. Everything in this file is synthetic: documentation IP ranges, .example names and made-up customer records.
What you will find in the capture
- Two customers shopping normally over plain HTTP
- A visitor who browses, then switches to scripted requests against one page
- A run of server errors, and one response that is very different from the rest
SQL Injection in a PCAP: Find the Probe and the Leak
The web team says the shop at shop.example logged a burst of 500 errors late last night. A tap in front of the web server was already recording, so you have a few minutes of plain-HTTP traffic from around that time.
Your job: decide whether the errors were a bug or an attack, and if an attack, whether it got anything. The web server is 10.50.0.20 in the DMZ; visitors arrive from the internet through the gateway. Everything in this file is synthetic: documentation IP ranges, .example names and made-up customer records.
You will practise
- Separate ordinary browsing from scripted requests in the same capture
- Read URL-encoded query strings and recognise SQL injection test strings
- Use error responses as evidence of how the application handles input
- Find the response that shows an injection worked, and what it exposed
- Turn the finding into containment and a fix the web team can act on
7 questions. Each hint costs 25% of that question’s points; a wrong try costs a little. Your score is out of 100.
Loading the capture…
Loading…
Sample report · illustrative data
Sample result: Cleartext HTTP Login case
Example run of the starter case on a synthetic capture (documentation and private IP ranges, .example names, a made-up account).
Scoring
- Score
- 82/100 (example)
- Grade
- B, solid analysis
- Hints used
- 2 (example)
- Time
- 6m 40s (example)
Findings in the example run
| Question | Filter that finds it | Read |
|---|---|---|
| Where is the login submitted? | http.request.method == "POST" | One POST to the intranet over port 80 |
| What crossed the wire? | http.file_data contains "username=" | Username and password readable as typed |
| Did it work? | http.response.code == 302 | Redirect plus a session cookie without Secure |
Recommended next steps (example)
- Serve the intranet over HTTPS only, with HSTS and Secure cookies
- Reset the exposed password and end the account's sessions
- Search wider captures for other cleartext logins
Made-up example data. Your own run uses your inputs. Downloads of the full report need Pro.
Downloads
Take the capture into Wireshark or your own tools, and keep the analyst report with the answer key.
14.0 kB · 89 packets · SHA-256 603c64aeb014924713d186b8d8e7d175aebb86fd636f113f0e377bd0ba970366
Sample of the debrief
This capture shows a SQL injection attack that worked. A client that first browsed like a customer switched to a script and sent a short series of requests that changed one query-string parameter, moving from a stray quote to UNION SELECT probes, and the server finally returned customer records in a product page.
The full debrief, with next steps and the MITRE ATT&CK mapping, appears when you finish the case.
What you will learn
- Separate ordinary browsing from scripted requests in the same capture
- Read URL-encoded query strings and recognise SQL injection test strings
- Use error responses as evidence of how the application handles input
- Find the response that shows an injection worked, and what it exposed
- Turn the finding into containment and a fix the web team can act on
Frequently asked questions
How do you find SQL injection in a PCAP with Wireshark?
Filter HTTP requests and read the URIs and bodies: http.request.uri contains "%27" finds URL-encoded quotes, and http.request.uri contains "UNION" finds UNION SELECT probes. Then look at the matching responses for 500 errors and for a 200 that returns unexpected data.
What does %27 mean in a URL?
It is a URL-encoded single quote. A quote added to a numeric parameter is a classic first test for SQL injection, because an application that pastes the value into a SQL string will break.
How can you tell if a SQL injection attempt succeeded?
Compare the responses. Errors show the input reached the query; a normal-looking 200 whose body contains data the page should never show (customer names, emails, table contents) shows the injection returned rows.
Why does the attacker try UNION SELECT with different numbers of columns?
A UNION only works when both queries return the same number of columns. The database error tells the attacker when the count is wrong, so they add columns until it fits.
Is this real attack traffic?
No. PlayCISO generated it from a fixed seed with documentation IP ranges, .example names and made-up records. The requests are shaped like the technique so you can practise, not taken from a real tool.