You're assessing an online amber jewelry store in Klaipeda, Lithuania — testing for cross-site scripting, command injection, credential weaknesses, and SQL injection across a WooCommerce platform with customer accounts and Stripe payments.
The discipline skills: multi-vulnerability exploitation across web, server, and authentication surfaces, writing Sigma rules from scratch for each vulnerability type, converting them to LogQL with pySigma, deploying Grafana alerts, and prioritizing remediation when you can't fix everything at once.
The AI-direction lesson: multiple vulnerability types look like one problem to AI. It applies the same exploitation approach to XSS, command injection, and credential testing — but each has different log signatures, different detection rules, and different fixes. AI also generates Sigma rules with field names from its training data that may not match your actual log format. A rule that validates syntactically but references the wrong fields will never fire. The skill here is recognizing when AI treats different problems as interchangeable and catching the mismatch before it reaches the report.
Your Role
You are assessing Ruta's online store for security vulnerabilities across multiple attack types. The purple team pipeline is the same as P1 — exploit, detect, remediate, report — but now you run it for several vulnerability types in a single engagement. Prioritizing what to fix first is part of the work.
What's New
You know the purple team loop from one vulnerability type. Now the loop runs across several types simultaneously, and the differences between them matter.
Multi-vulnerability exploitation. XSS, command injection, credential testing, and SQL injection each follow different patterns. An XSS payload targets the browser. A command injection payload targets the server's shell. Credential testing targets the authentication system. SQL injection targets the database. AI treats them as interchangeable security problems, but the exploitation technique, the log signature, and the remediation are different for each.
Sigma rule authoring. In P1, you worked with provided detection templates. Now you write Sigma rules from scratch for each vulnerability type. The challenge is that Sigma's field names are standardized, but your log source's field names are not. AI generates syntactically correct Sigma rules with field names from training data that may not match the fields in your actual logs. Testing the rule against real log data is the only way to know.
Priority-based remediation. With multiple findings, you cannot fix everything at once. You must decide what is urgent, what can wait, and what to recommend for later. AI treats all findings as equally important. The student decides which ones Ruta needs to hear about first.
Tools
- Docker — running the target application (WooCommerce-style store) and monitoring stack (Grafana, Loki, Alloy).
- Nmap — network scanning and service discovery. Continuing.
- Hydra — credential brute-force testing. New.
- sqlmap — SQL injection testing. Continuing from P1.
- ZAP (OWASP Zed Attack Proxy) — passive scanning for missing security headers. New.
- Grafana/Loki/Alloy — log viewing and monitoring. Continuing.
- pySigma — converting Sigma rules to Loki-compatible LogQL queries. New.
- Claude Code — AI agent directing all tool execution.
- Git/GitHub — version control and project submission.
Materials
- Scope document — assessment boundaries, authorized targets, and exclusions.
- TTP selection guide — attack techniques mapped to the vulnerability types present in the target.
- Client email — Ruta's initial request with context about the phishing incident.
- Sigma rule starter — YAML structure for writing detection rules.
- Report template — multi-finding assessment report structure.
- Docker environment — the store application, staging site, database, and monitoring stack.
- CLAUDE.md — project governance file with verification targets.