SOC Alert Walkthrough | LetsDefend · Blue Team · Web Attack Analysis
A full investigation walkthrough of SOC165 - a web application attack alert involving a URL-encoded SQL injection payload targeting an internal web server. Covers alert triage, IP reputation analysis, URL decoding, log analysis, attack outcome determination, and playbook closure.
🌐 LetsDefend platform: app.letsdefend.io
SQL injection remains one of the most consistently exploited web application vulnerabilities - and one of the most preventable. What makes SOC165 a useful learning case isn't just the attack technique itself. It's the response process: how you distinguish a true positive from a false positive when the traffic was allowed by the firewall, how URL encoding is used to obfuscate payloads, and how HTTP response codes become critical evidence in determining whether an attack succeeded.
The 1=1 tautology in this alert is textbook SQLi - but knowing that is different from knowing how to prove it, trace it, and close it correctly. That's what this walkthrough documents.
| Field | Value |
|---|---|
| Alert Name | SOC165 - Possible SQL Injection Payload Detected |
| Event ID | 115 |
| Alert Type | Web Attack |
| Severity | High |
| Verdict | ✅ True Positive |
| Attack Successful? | ❌ No - payload blocked by server error |
| Field | Value |
|---|---|
| Source IP | External (internet-facing attacker) |
| Destination IP | Internal - identified as WebServer1001 |
| Traffic Direction | Internet → Company Network |
| HTTP Method | GET |
| Device Action | Allowed (reached the web server) |
| HTTP Response Status | 500 Internal Server Error |
| HTTP Response Size | 948 bytes |
Checked via VirusTotal:
- 6 out of 94 security vendors flagged the source IP as malicious
- GeoLocation identified - external threat actor origin confirmed
- No evidence this was an internal user or authorized tester
The requested URL contained a URL-encoded SQL injection payload. Decoded using urldecoder.org:
' OR 1=1 --
Why this payload matters:
OR 1=1 is a tautology - it is always true. In a SQL query vulnerable to injection, this condition causes the database to return all rows from the queried table rather than filtering by the intended parameter. The -- comment sequence terminates the rest of the original query, preventing syntax errors that might indicate the injection failed.
A regular user would have no reason to submit URL-encoded SQL syntax in a web request. The encoding itself - using %27 for single quote, %20 for space - is a deliberate attempt to bypass basic input filters that block plaintext SQL keywords.
No. Two pieces of evidence confirm the attack did not succeed:
-
HTTP 500 Internal Server Error - The server returned an error rather than data. A successful SQLi that dumped database contents would typically return HTTP 200 with an unexpectedly large response body. The 500 response indicates the payload caused a server-side error rather than executing successfully.
-
No evidence of compromise on the endpoint - Endpoint analysis of WebServer1001 showed no indicators of post-exploitation activity, data exfiltration, or persistence mechanisms.
The attack was real, the payload was malicious, and the intent was data extraction - but the execution failed.
Assign the alert and open a formal case before beginning investigation. This creates a timestamp, establishes chain of custody, and ensures the incident is tracked by severity. For web attacks, note immediately: source IP, destination IP, HTTP method, and requested URL.
The playbook ensures consistent, step-by-step investigation regardless of analyst experience. For web attack alerts, the playbook routes through: traffic verification → IP reputation → URL analysis → log analysis → endpoint check → artifact collection → close.
Pull the alert metadata and confirm:
- Source and destination IP addresses
- HTTP request method and URL
- Device action (was the traffic allowed or blocked?)
- HTTP response status and size
Finding: Traffic was allowed - the request reached the web server. This immediately elevates severity; a blocked request is far less concerning than one that landed.
Use VirusTotal to check the reputation of the source IP address.
Finding: 6/94 vendors flagged the IP as malicious. GeoLocation confirmed external origin. This is not an internal scan, a pentest, or a misconfigured monitoring tool - it's an external attacker.
URL encoding (%27, %20, %3D, etc.) is commonly used to obfuscate attack payloads and bypass WAF rules that look for plaintext SQL keywords. Always decode the full URL before making a determination.
Tool: urldecoder.org or browser developer tools.
Finding: Decoded URL reveals ' OR 1=1 -- - a classic SQL injection tautology designed to dump database table contents.
Search Log Management for the source IP and review the raw log entry.
Finding: HTTP response status 500, response size 948 bytes, device action allowed, traffic direction Internet → Company. The 500 status is the critical data point - it indicates the server errored out rather than returning database content.
Search email exchange logs for any mention of authorized security testing scheduled around the time of the alert.
Finding: No evidence of a planned test. This is a genuine external attack, not a sanctioned penetration test.
Confirm whether traffic originated inside or outside the network.
Finding: External → Internal. An attacker on the internet attempted to exploit a web-facing application.
Check WebServer1001 for signs of post-exploitation: unusual processes, outbound connections, file modifications, privilege escalation attempts.
Finding: No evidence of compromise. The 500 response and absence of endpoint indicators confirm the attack failed at the payload execution stage.
Document all indicators of compromise for threat intelligence and future correlation. Close the alert as True Positive - attack attempted but unsuccessful.
| Type | Value | Notes |
|---|---|---|
| Source IP | [Flagged by 6/94 VT vendors] | External attacker, malicious reputation confirmed |
| Destination | WebServer1001 | Internal web server targeted |
| Attack payload | ' OR 1=1 -- |
Classic SQL tautology - table dump attempt |
| HTTP method | GET | Payload delivered via URL parameter |
| HTTP response | 500 Internal Server Error | Attack did not succeed |
| URL encoding | %27 OR 1%3D1 -- |
Encoded form of the SQLi payload |
| Technique | ID | Description |
|---|---|---|
| Exploit Public-Facing Application | T1190 | SQL injection targeting internet-exposed web application |
| Data from Information Repositories | T1213 | Intended outcome - database table exfiltration via SQLi |
| Obfuscated Files or Information | T1027 | URL encoding used to evade basic input filters |
On the attack technique:
OR 1=1is a tautology-based SQLi payload designed to bypass WHERE clause filtering and return all rows from a database table. The--terminates the original query to prevent syntax errors.- URL encoding (
%27=',%20= space) is a standard evasion technique against WAFs and filters that look for plaintext SQL keywords. Always decode URLs before analysis. - A 500 Internal Server Error on an SQLi attempt typically indicates the payload caused a backend error - the database received the malformed query but threw an exception rather than returning data. This is the difference between "attempted" and "successful."
On the investigation process:
- Device Action: Allowed means the traffic reached the application. Don't mistake firewall pass-through for a blocked attack.
- HTTP response status is your primary evidence for determining attack success. 200 with a large response body = suspicious. 500 = server error, payload likely failed.
- Always check email exchange for planned test authorization before closing as True Positive. A pentest without documentation is indistinguishable from a real attack in the logs.
- Endpoint analysis closes the loop. Log evidence tells you the attack was allowed. Endpoint analysis tells you whether it had any effect.
On the broader lesson:
- Parameterized queries and prepared statements eliminate SQL injection entirely - this class of vulnerability is preventable, not just detectable. Every confirmed SQLi should prompt a question: why wasn't input sanitized here?
| Tool | Purpose |
|---|---|
| LetsDefend SIEM | Alert triage, log management, endpoint security |
| VirusTotal | Source IP reputation and geolocation |
| URL Decoder | Decoding obfuscated attack payload |
| LetsDefend Playbook | Structured investigation workflow |
Written by Ron Mercier - Cloud & Cybersecurity Engineer. Technical Support Engineer at Verint (Fraud & Security Solutions). Previously Cloud Support Specialist at Akamai Technologies. MSc Cybersecurity · CySA+ · PenTest+ · ISC2 CC · AWS CCP.
🌐 securebydefault.io · 📬 Newsletter · 💼 LinkedIn · 🐙 GitHub
Add the following to the About section of this repo (gear icon next to About):
Description:
SOC alert walkthrough: SQL injection payload detected on an internal web server - IP reputation analysis, URL decoding, HTTP response analysis, and playbook closure. LetsDefend SOC165.
Topics:
soc cybersecurity blue-team incident-response sql-injection
web-security letsdefend dfir siem threat-analysis
Part of an ongoing series of SOC alert walkthroughs documenting detection, analysis, and response methodology across real attack scenarios.