Lion Cipher Lab
Detect web attacks in access logs after decoding the URLs
- SOC Analyst / Blue Team
- Intermediate
- ~60 min
- Free · no account required
Why it matters
Every public website is probed all day, and the access log is often the only record a SOC has of it: one line per request, written by the web server before anything else gets a say. Exploiting a public-facing application is one of the most common ways intruders get in (MITRE ATT&CK tracks it as T1190), and the evidence usually sits in that log. But attackers do not send their strings in plain English. They percent-encode them, double-encode them, mix upper and lower case, and swap spaces for plus signs, partly to slip past filters and partly because that is simply how browsers and tools send…
What you'll learn
- Reading an Apache/nginx Combined Log Format line field by field
- Explaining percent-encoding, double encoding and plus-for-space, and why each hides an attack string from a raw grep
- Normalizing request targets (decode until stable, lowercase) before matching
- Matching attack shapes (SQL injection, path traversal, JNDI lookups) instead of single scary words
- Detecting a scanner as a behaviour (a burst of 404s) rather than a string
- Ranking hits for escalation with response context: status code plus body size against the path's normal
- Stating the honest limits of access-log hunting: no POST bodies, attempts not proof, encodings a decoder does not normalize
Steps in this lab
- What an access log is, and why a SOC hunts in it
- Read one line, field by field (the Combined Log Format)
- Percent-encoding: the reason a raw grep goes blind
- Generate the synthetic access log
- Why the obvious grep fails (the judgement)
- Hunt three ways and score each one
- Read the one miss: an obfuscated lookup
- Decide what a human must look at today: escalate by context
- The honest limits of access-log hunting
- Take it to real logs, and where to go next