Parse and query HTTP logs in Splunk: your first web-log hunt

In Splunk Web, go to Settings → Add Data → Upload, pick your access.log, and on the Set Source Type screen choose access_combined. Send it to a new index called web.

> index=web sourcetype=access_combined | head 5

Set the time picker to All time while you work with sample data — it is dated, and Last 24 hours will show nothing. You should see five raw lines, each a single request.

Why this matters. Picking access_combined instead of letting Splunk guess is the whole game: it tells Splunk the field layout up front, so clientip, status and the rest are already parsed the first time you search. Guess wrong here and every later search returns nothing.

Run the base search, then open the fields panel on the left. One ugly line is now a dozen named fields.

> index=web sourcetype=access_combined | table clientip method uri_path status bytes useragent

The ones you will use all day: clientip (who), method (GET/POST), uri_path (what they asked for), status (how it went), bytes (how big the reply was), useragent (what claims to be asking).

Why this matters. Everything after this is just counting and grouping these six fields. If a field is blank here, your source type is wrong — fix step 1 before going on.

Count requests per source address, busiest first.

> index=web sourcetype=access_combined | stats count by clientip | sort - count

The top row is usually boring — a monitoring check or a CDN. The row that matters is the one you cannot explain.

The attacker’s view. A single address doing thousands of requests is cheap recon; it costs them nothing and tells them your whole URL layout.

The defender’s move. You now have the one number — requests per IP — that a dashboard panel or alert can watch forever.

Group by HTTP status so the shape of the day is one glance.

> index=web sourcetype=access_combined | stats count by status | sort - count

A healthy site is mostly 200 and 304. A wall of 404 means someone is guessing paths; a spike of 500 means something server-side is falling over — sometimes because of what the 404s were probing.

Why this matters. Status codes are the fastest triage in any web log. You read this panel before you read anything else.

Scanning looks like one address racking up 404s against many different paths. Count the 404s per IP and how many distinct paths they missed.

> index=web sourcetype=access_combined status=404 | stats count dc(uri_path) as paths by clientip | sort - count

One human mistypes a URL and gets a 404 or two. A scanner gets hundreds, across hundreds of paths they were never linked to. dc(uri_path) — distinct count of paths — is what tells the two apart.

The raw 404 count alone will flag your own broken image as an “attack.” The distinct-paths number is what stops you paging someone at 2 a.m. over a missing favicon. — Nyx

Why this matters. This single search is a working recon detector. Everything fancier is a refinement of it.

The useragent is attacker-controlled text, so it is never proof — but tools are lazy and often announce themselves. List the rare ones.

> index=web sourcetype=access_combined | stats count by useragent | sort count

Sorting ascending puts the rarest agents on top — that is where sqlmap, nikto, curl and bare python-requests hide, not in the millions of normal browser strings.

The attacker’s view. Changing the user agent to look like a browser is one line of code, so a smart one does.

The defender’s move. You never trust it alone — you cross it with the scanner IPs from step 5. A rare agent and a 404 storm from the same address is a real lead.

Attack payloads often ride in the URI itself. Search the raw path for the markers of traversal and injection.

> index=web sourcetype=access_combined uri=*union* OR uri=*select* OR uri=*../* OR uri=*etc/passwd* OR uri=*<script* | table _time clientip status uri

A hit here is not proof the attack worked — status tells you that. A 200 next to etc/passwd is the one you stop and read; a 404 is a miss you still want to know happened.

Why this matters. This turns “were we attacked?” into a search that either returns rows or does not. Save it — it is the first thing to run after any web CVE lands.

Turn the scanner search from step 5 into a saved alert so you never hand-type it again. Run it, then Save As → Alert.

> index=web sourcetype=access_combined status=404 | stats count dc(uri_path) as paths by clientip | where paths > 30

Set it to run over the last hour, on a schedule, and trigger when the result count is greater than zero. The where paths > 30 is your threshold — tune it to your own site by looking at a normal day first.

Why this matters. A search you ran once caught nothing tomorrow. A saved alert is the difference between a lab exercise and a control that actually watches your logs while you sleep.