Splunk Detection Rules for Common Web Attacks: A Practical SOC Guide
A practical SOC guide to building and tuning Splunk detection rules for common web attack patterns using the right log sources, triage logic, MITRE mapping, and incident handoff workflows.
The web server logs saw it three hours before anyone filed a ticket: a single source running GET requests against /admin, /.git/config, /wp-login.php and forty other paths the application never serves, each one a clean 404. By the time engineering noticed the odd 500s on the login endpoint, the reconnaissance was long finished and the source had moved on to trying credentials. The signal was sitting in Splunk the whole time. Nobody had written the rule that would have surfaced it.
That is the gap this guide is about. Your SOC sees credential abuse, path scanning, malformed API calls and bot noise before engineering knows there is a problem — but only if the detections exist and only if an analyst can triage them without spending twenty minutes reconstructing what the alert means. The examples here are deliberately given as logic, not copy-paste SPL. A query you paste without understanding is a query you cannot tune, and an untunable rule becomes noise the first time your traffic shifts.
Building Splunk Detection Rules for Web Attacks
Follow this workflow and you’ll build detections analysts can actually triage quickly — not a wall of alerts that gets muted by week two.
1) Why Your SOC Should Care About Web Attacks
- Your web apps and APIs are probed continuously, not just during the quarterly pentest. The background noise of the internet is a rolling scan of every public endpoint you own.
- Your SOC sits at the intersection of endpoints, identities, networks and applications, so you can correlate a failed login against a suspicious source IP against an endpoint process — patterns no single team sees alone.
- Catching probing before it turns into access keeps the blast radius small. The cost of a detection is analyst time; the cost of missing one is an incident.
The catch: web detection competes for the same analyst hours as everything else in the queue. Every rule you add is a rule someone has to tune, own and eventually retire. Coverage that nobody maintains decays into false positives, and false positives train analysts to close alerts without reading them — which is worse than having no rule at all.
2) Get Your Data In Shape First
You can’t build good detection rules on messy logs, and no amount of clever SPL rescues a field that is inconsistently named across three log sources. Clean, normalised data beats fancy logic every time — most of the effort in a detection programme is spent here, not on writing rules. The failure mode is subtle: a detection that references src_ip on a source where the field is actually called clientip returns zero results silently. No error. It just never fires, and the dashboard shows a healthy green while the coverage you think you have does not exist.
Log Sources You Need
- Web server logs (nginx, Apache, ingress controllers)
- WAF logs (cloud-managed or your own)
- Application authentication logs
- Reverse proxies and load balancers
- API gateways
- Server telemetry (what’s running on the actual web servers)
- Firewall and network security logs
Fields You Must Have
| Log Type | Fields You Need | Why |
|---|---|---|
| Web/HTTP | timestamp, src_ip, method, uri_path, status, user_agent | Tells you what traffic came, from where, and what the app said |
| Authentication | user, auth_result, src_ip, session_id, target_app | Catch brute force and account abuse |
| WAF | rule_id, action, matched_pattern, host, uri | Understand what attacks your WAF blocked |
| API Gateway | api_route, client_id, latency, response_code, rate_limit_signal | Spot API abuse and performance issues |
| Endpoint | host, process, network_connection, destination | Connect web activity to what’s actually happening on the server |
Normalise field names to a common schema — the Common Information Model if you are on Splunk — before you write a single detection. It is unglamorous work and it is the difference between a rule you can reuse across sources and a rule that quietly covers one log source and no others.
3) Which Web Attacks to Detect First
Start with patterns that give good signal and that an analyst can reason about without a web-security background. Resist the urge to detect everything at once — a smaller set of high-confidence rules that people trust beats broad coverage that nobody believes.
Attack Patterns Worth Detecting Now
- SQL injection: Request patterns that look like SQLi (
UNION SELECT,' OR 1=1, encoded variants) or WAF blocks tagged as SQLi. Remember a WAF block is a blocked attempt — the interesting question is whether anything got through. - XSS: Script-like payloads in request parameters, or a reflected parameter appearing verbatim in a 200 response.
- Path traversal:
../sequences and access attempts to/etc/passwd,/.git/,/.envand other files that should never be web-reachable. - Brute force and password spraying: Many failed logins from one source (brute force) or one credential failing across many accounts (spraying) — different shapes, different thresholds.
- Anomalous user-agents: Randomised, empty or tool-like agents (
sqlmap,nikto,python-requests) hitting the app. Cheap to spoof, so treat it as corroboration, not a standalone verdict. - 404 scanning: A burst of “not found” errors walking through sensitive paths, which is what content discovery tooling looks like.
- HTTP method abuse:
DELETE,PATCHorPUTon routes that only expectGET/POST. - API abuse: Clients exceeding documented rate policies, calling endpoints out of sequence, or presenting token anomalies.
Detection engineering table
| Use Case | Log Source | Fields Needed | Triage Question | Tuning Notes |
|---|---|---|---|---|
| SQLi Indicators | WAF + Web logs | uri, query_string, rule_id, status | Is this blocked probing or successful backend impact signal? | Add baseline by app path and expected parameter formats |
| XSS Indicators | Web + WAF + App logs | uri, param_key, status, action | Did payload reach app logic or get blocked at edge? | Suppress known safe test routes and QA traffic |
| Path Traversal Attempts | Web + Reverse proxy logs | uri_path, status, src_ip, host | Are restricted file paths being targeted repeatedly? | Threshold by source + target sensitivity |
| Auth Brute Force | Auth + WAF + Identity logs | user, auth_result, src_ip, session | Is this user lockout noise or coordinated credential attack? | Tune by tenant/user behaviour baseline and MFA context |
| Suspicious User-Agent | Web logs | user_agent, src_ip, uri_path, request_rate | Is agent behaviour consistent with approved scanners/monitors? | Maintain allowlist for legitimate monitoring systems |
| High 404 Recon Signal | Web + CDN logs | status, uri_path, src_ip, host | Is this normal broken-link traffic or endpoint discovery activity? | Exclude known crawler ranges where appropriate |
| Unusual HTTP Methods | Web + API gateway | method, route, status, client_id | Is method valid for this route in production behaviour? | Route-method allowlist based on API specs |
| API Abuse Signal | API gateway + Auth logs | client_id, token_id, route, latency, code | Is this legitimate burst traffic or abuse pattern? | Tune per client tier and documented rate policies |
4) MITRE ATT&CK mapping for SOC context
Mapping detections to ATT&CK helps with coverage reporting and gives incident communication a shared vocabulary. Treat it as a label, not a promise — a WAF block tagged “Initial Access” tells you someone tried a public-facing application exploit, not that the application was compromised. The mapping describes what the technique would be if successful, and conflating the two is how coverage reports end up overstating what the SOC can actually see.
| Detection Theme | Example ATT&CK Tactic | Example ATT&CK Technique (High-Level) |
|---|---|---|
| Credential abuse patterns | Credential Access | Brute Force |
| Web path and endpoint probing | Discovery | Network Service Discovery / Application Discovery context |
| Web command-like input abuse signals | Initial Access / Execution context | Public-facing application abuse context |
| Data access anomaly through API | Collection | Data from Information Repositories context |
Use ATT&CK mapping as communication metadata, not as proof that an attack stage is complete.
5) How to Design a Splunk Detection Rule
A good rule answers exactly one question an analyst needs to ask, and answers it clearly enough that they can decide escalate-or-close from the alert alone. Rules that try to catch three things at once are the ones nobody can tune, because you can never isolate which condition is producing the noise.
Before You Write Any SPL
- Know what you’re looking for: Write it down. What behaviour is suspicious?
- Check your fields: Make sure you have the data you need.
- Pick a time window: How fast does this attack happen? Use that for your window.
- Set your threshold: Don’t just guess—use historical data to set your baseline.
- Decide severity: When this fires, how serious is it?
- Add context: Criticality, owner, environment—things that help triage.
- Write the triage steps: What should an analyst check when this alert comes in?
The Logic Pattern (In Plain English)
- Look at the apps and HTTP patterns you care about
- Count things by source, target, and time bucket
- Compare what you’re seeing now to normal historical patterns
- Tag it with context (is it critical, who owns it, what environment)
- Only alert when the volume is abnormal AND something else looks wrong
This keeps your rules understandable for analysts and makes them easier for engineering teams to help tune.
6) Kill False Positives Without Going Blind
Every suppression you add to quieten a rule is also a hole you have cut in it. That is the trade the whole section turns on: tune aggressively enough that analysts stop drowning, and you eventually suppress the one source that mattered. The goal is not zero false positives — it is a false-positive rate low enough that analysts still read the alerts, with every suppression documented so you know exactly what you have chosen not to see.
How to Reduce Noise
- Dynamic thresholds: A static “50 failed logins” fires constantly on a high-traffic tenant and never on a low-traffic one. Baseline per app and alert on deviation from that app’s normal, not an absolute number.
- Allowlists: Document your own scanners, uptime monitors and vulnerability tooling — and put an expiry on every entry, because an allowlist with no review date is where an attacker’s source IP hides once someone adds it “temporarily”.
- Route sensitivity: An anomaly on
/admindeserves a faster, louder alert than the same pattern on a static asset path. Weight by what the route can do, not just by request volume. - Criticality: Bump severity on production and crown-jewel systems; loosen dev and staging. Just make sure “dev” is actually isolated — a loosely-tuned rule on a dev box that shares an identity provider with prod is a blind spot with a login page.
- Talk to developers: Half of what looks like an attack is a health check, a batch job or a mobile client retrying. Ask the app team what normal looks like before you spend a week tuning against your own infrastructure.
Keep Tuning On Schedule
| What to Do | How Often | Who Does It |
|---|---|---|
| Review alert quality | Weekly | SOC detection engineer |
| Dig into false positives | Weekly | SOC + App Security |
| Update allowlists and baselines | Every two weeks | SOC platform owner |
| Review rule logic and thresholds | Monthly | Detection lead |
| Look for coverage gaps | Quarterly | SOC manager + security architecture |
7) Dashboard ideas that support real triage
A dashboard nobody opens during an incident is a dashboard that exists to look good in a steering-committee slide. Build widgets that answer a triage question, and be honest that a wall of pretty time-series charts is worse than three panels an analyst actually reaches for at 2 a.m.
Useful SOC dashboard widgets
- Top attacked endpoints by count and trend
- HTTP status code spikes by application/environment
- Authentication failure heatmap by user/source
- WAF block vs allow trend by rule category
- Suspicious parameter pattern frequency
- Source geography and ASN clustering for attack campaigns
- API route abuse rate by client identity
Pair each dashboard widget with an associated triage question so analysts know what to do next.
8) How to Hand Off an Alert to Incident Response
The handoff is where most detection value leaks out. A rule can fire perfectly and still waste an hour of the responder’s time if the alert says “investigate this” and nothing else. The responder then re-runs the search, re-establishes the timeline and re-derives the scope the detection engineer already knew — every time. Write the alert so the next person can act on it cold.
What to Include in the Handoff
- One-sentence summary: What happened?
- Rule name and why it fired: Which detection caught this and why?
- Timeline: Exact UTC timestamps of key events, in order
- What’s affected: Specific endpoints, servers, environment
- Source context: Where did the traffic come from? Who was it?
- Related signals: WAF blocks, auth failures, endpoint activity, anything correlated
- What to do about it: Disable a token? Block a source? Lock a route?
- Open questions: What does engineering need to check?
Handoff Quality Check
| Part of the Alert | Should Sound Like This | Not Like This |
|---|---|---|
| Timeline | “2024-05-22 14:32:15Z: Failed auth from 203.0.113.45. 2024-05-22 14:33:00Z: Successful auth from same IP” | “Failed logins happened today” |
| What’s Broken | “Endpoint /api/v2/admin on web-prod-01 in the prod environment” | “Something in the web app” |
| Evidence | “Query returned 42 events. See event IDs 1234–1276 for full details” | “Here’s a screenshot” |
| What to Do | “Block 203.0.113.45 at the firewall and reset the compromised account” | “Please investigate this” |
9) Mistakes That Break Your Detection Program
- Dumping logs without parsing them: Raw, unparsed logs mean every rule does its own field extraction at search time — slow, brittle and inconsistent. Parse and normalise at ingest.
- Alerting on a static number: A fixed threshold is wrong on every host except the one you tuned it against. Baseline per app and alert on deviation.
- Watching web servers but not API gateways: Modern attacks target the API directly, bypassing the web tier entirely. If your only source is nginx access logs, you are blind to a whole class of abuse.
- Rules with no owner: When an unowned rule starts misfiring after an app change, nobody fixes it — it gets muted, and a muted rule is coverage you have on paper and not in reality.
- Trusting WAF block counts alone: The WAF tells you what it stopped, not what it missed. Treat WAF logs as one signal to correlate, never the whole verdict.
- Not tuning after incidents: Every false positive that burned an analyst and every real attack that slipped through is free tuning data. Feed both back into the rule.
- Undocumented rules: Six months on, an undocumented rule is a black box nobody dares change, so it lives forever regardless of whether it still works. Write down purpose, data sources and triage steps at creation time.
10) 30-Day Plan to Build Web Detection Right
| Week | What to Do | What You End Up With |
|---|---|---|
| Week 1 | Check your web logs for quality and missing fields | Report on field consistency + list of gaps |
| Week 2 | Deploy your first high-signal rules (auth abuse, 404 scanning, HTTP method misuse) | Baseline set of working rules |
| Week 3 | Reduce false positives by tuning + add owner and criticality metadata | Cleaner alerts + context for triage |
| Week 4 | Fix your incident handoff format and build a web detection dashboard | Standard template + visibility into detection quality |
Numbers to Track
- How many alerts are actually worth investigating?
- False-positive rate for each rule
- How long does it take analysts to triage a web alert?
- How many detections actually turn into incidents?
- Are you covering your critical apps and APIs?
When your SOC treats web detection as engineering rather than a one-off project — owned rules, baselines, documented triage steps — you get faster triage, tighter containment, and development teams that actually trust your alerts instead of treating them as background noise.
Detection operations worksheet for SOC teams
| Workstream | Owner | First Action | Validation Signal |
|---|---|---|---|
| Data quality | SIEM engineer | Validate required fields by log source | Reduced null/parse failure rate |
| Use-case ownership | Detection lead | Assign owner to each detection use case | Clear escalation point for tuning updates |
| Triage readiness | SOC lead | Add triage questions to alert metadata | Faster analyst decision consistency |
| Tuning governance | Detection engineer | Schedule weekly false-positive review | Alert quality improves without blind spots |
SOC execution checklist
- Ensure every rule answers one clear investigative question
- Avoid deploying high-noise rules without baseline references
- Track suppression changes with owner and expiration
- Validate detection behaviour after major app changes
Handoff package standard for incident teams
| Artifact | Minimum Content | Consumer |
|---|---|---|
| Alert context pack | Rule name, trigger logic summary, key fields | Tier-1/Tier-2 analysts |
| Correlation snapshot | Related auth/WAF/endpoint events | Incident responders |
| Scope summary | Affected app/route/session context | App owners + response team |
| Containment options | High-level recommended response actions | Incident commander |
Quality gates
- Can an analyst decide escalation from alert content alone?
- Are correlated signals sufficient to reduce false escalation?
- Is affected scope specific enough for engineering response?
Your 90-Day Detection Engineering Journey
Month 1: Fix the Foundation
- Get your web, app, and API log fields consistent
- Deploy your first set of high-signal web detections
- Write down the triage steps for each rule category
Month 2: Tune and Add Context
- Adjust thresholds based on what your app teams tell you is normal
- Add dashboards that show alert quality and how fast analysts work
- Kill recurring false positives by pattern type
Month 3: Expand and Mature
- Build detections for more of your business-critical endpoints
- Audit your rules—which ones still have owners? Which ones are stale?
- Write up what you learned and what comes next
| Metric | What It Tells You |
|---|---|
| Actionable alert ratio | Are analysts actually doing something with your alerts? |
| Mean time to triage | How fast can analysts figure out if something is real? |
| False-positive rate | Is your tuning getting better? |
| Incidents from detections | Are detections actually catching real attacks? |
The real trick is treating telemetry quality, rule ownership and triage speed as one connected system rather than three separate initiatives. Weak data starves good rules; unowned rules rot; slow triage buries good detections in the queue. Fix one in isolation and the other two pull it back down. Move all three together and the detection programme actually scales.
Detection engineering lifecycle (Splunk) without the chaos
Detections are code, and code you ship without tests, ownership or a rollback path is code that fails in production at the worst moment. A rule promoted straight to prod because it “looked right” in the search bar is how you discover, mid-incident, that it was matching on a field that only exists in staging. Give rules the same lifecycle you would give any other production system.
Rule “definition of done”
| Item | Minimum standard |
|---|---|
| Purpose | Clear threat/problem statement |
| Data sources | Required indexes/sourcetypes listed |
| Triage steps | 3–5 deterministic checks an analyst can follow |
| False-positive controls | Filters/suppressions documented with rationale |
| Owner | Named team/person responsible for tuning |
| Test data | Sample events or replay method documented |
Testing approach (practical)
- Unit test: query returns expected fields and does not error.
- Signal test: rule fires on known-bad simulated events or replayed incidents.
- Noise test: run against a typical week and record baseline alert volume.
Release controls
- Promote rules through
dev → stage → prodwith a consistent checklist. - Time-box high-risk changes and have rollback ready.
- Keep a changelog: what changed, why, and what metric improved.
Metrics that actually help
| Metric | Use |
|---|---|
| Alerts/day per rule | Identifies noisy or failing logic |
| True-positive rate | Validates detection value |
| Median triage time | Shows operational workload |
| Suppression count | Flags drift and environment changes |
This keeps Splunk detections professional-grade: tested, owned, and measurable over time.
