Exploitation and Detection

Step 1: Web application testing

Your reconnaissance is complete -- passive findings mapped, active scanning documented, content discovery done. Now you test whether the ordering platform protects buyer data.

Refer to materials/ttp-selection-guide.md -- the web application testing category describes authentication testing, input handling, API security, and information disclosure. You already know which endpoints exist from your reconnaissance. Now you test them.

Direct Claude to test the ordering platform for common web vulnerabilities. Focus on what matters for Samir's buyers: can someone access data without authorization? Can someone inject malicious input through the order forms or search fields? Are there API endpoints that bypass authentication?

Test the ordering platform for web application vulnerabilities. Start with authentication testing on the login mechanism, then test input handling on user-facing forms, then check API endpoints for access control issues.

When you find a vulnerability, document it with evidence. What exactly is the vulnerability? What can an attacker do with it? What buyer data is exposed? The difference between "found XSS" and "found stored XSS in the order notes field that could let an attacker steal session cookies from other buyers, exposing their trade terms and pricing" is the difference between a finding and a meaningful finding.

Step 2: Document exploitation findings

For each confirmed vulnerability, create a finding entry that connects the technical issue to Samir's business.

Samir's buyers are wholesale olive oil importers. Their accounts contain company names, shipping addresses, order histories, and pricing tiers. Pricing tiers are commercially confidential -- a buyer in Lyon paying one rate should not be able to discover what a buyer in Montreal pays. When you document a vulnerability, explain the impact in terms Samir understands: "Someone could see all your buyers' pricing terms" means more to him than "unauthenticated API endpoint returns JSON."

For each confirmed vulnerability, document: what you found, the evidence (exact request and response), what an attacker could do, which buyer data is at risk, and the compliance relevance for the French food safety review.

Step 3: Find patterns in Grafana

Switch sides. Open Grafana at http://localhost:3000 and navigate to the Explore view with the Loki data source.

You are now looking for two distinct categories of activity in the same log stream: your reconnaissance patterns from Units 2-3 and your exploitation patterns from Step 1. These leave different signatures.

Reconnaissance patterns are network-layer: rapid sequential requests to different ports or paths, unusual user agent strings from Nmap or ffuf, repeated connection attempts. Exploitation patterns are application-layer: injection strings in request parameters, authentication failures, unusual API calls.

Find both types in the logs. The scan timing you chose in Unit 3 determines how the reconnaissance looks -- aggressive timing creates obvious bursts; polite timing spreads activity across a longer window.

Step 4: Write detection rules for reconnaissance patterns

In P2, you wrote Sigma rules for web application attacks -- SQL injection patterns, XSS payloads. Now you write rules for scanning and content discovery patterns. The detection challenge is different.

Open materials/sigma-rule-starter.yml to review the Sigma YAML structure.

Web attack signatures live in request parameters and body content. Scanning signatures live in traffic patterns -- volume, timing, user agents, sequential path enumeration. A Sigma rule that detects "100 requests to unique paths in 10 seconds" is a different kind of rule than one that detects "UNION SELECT in a query parameter."

Write Sigma rules that detect the reconnaissance patterns visible in the Grafana logs. Include rules for port scanning activity, content discovery (ffuf-style sequential path requests), and any OSINT-triggered traffic patterns. Use the sigma-rule-starter.yml template as the structural base.

AI commonly writes detection rules that only cover web application attacks when you ask for "detection rules." It defaults to what it has seen most often. Be explicit about wanting reconnaissance detection -- the scanning patterns, not just the exploitation patterns.

Step 5: Cross-check the detection rules

In P2, you reviewed your own Sigma rules and caught formatting issues. Self-review works for syntax, but it has a blind spot: the same reasoning that produced the rule also evaluates it. If you misunderstood a log field name, your self-review will accept the same mistake.

Cross-checking uses a different approach. You give the Sigma rules and a sample of the actual log data to a fresh Claude session -- one that has no context about how the rules were written. The fresh session sees only what you give it: the rules and the logs.

Start a new Claude session or explicitly instruct Claude to review with fresh context. Provide only the Sigma rules and the log samples -- not your conversation history, not your reasoning, not your reconnaissance notes.

Review these Sigma rules against these log samples. Check whether the field names in the rules match the actual field names in the logs. Check whether the detection patterns would match the log entries they are intended to catch. Identify any gaps.

Compare what the cross-check finds with what your own review would have caught. The cross-check should surface at least one issue -- typically a field name mismatch, a detection pattern that is too narrow, or a timing window that does not match the actual log cadence. This is why fresh context matters: it has no established assumptions to normalize around.

Step 6: Deploy and test

Convert the Sigma rules to LogQL using pySigma, deploy them as Grafana alerts, and test by replaying the scanning and exploitation patterns.

Convert the corrected Sigma rules to LogQL queries. Create Grafana alert rules for each detection. Then replay the reconnaissance scans and exploitation tests to verify the alerts fire.

Every rule should fire when you replay the attack it was designed to detect. If a rule does not fire, the issue is in the conversion, the field mapping, or the detection logic itself. Do not adjust the LogQL until you understand which layer the problem is in.