Detection -- Writing Rules for Each Attack Type

Step 1: Find the XSS Attack Pattern in the Logs

Switch to the defender's view. Open Grafana at http://localhost:3000 and query the application logs for the time window when you tested the XSS payloads in Unit 3.

In Grafana, search the application logs for the XSS payloads from Unit 3. Look for the reflected XSS test against the search endpoint and the stored XSS review submission. What do these attacks look like in the access logs?

The reflected XSS shows up differently than the stored one. The reflected payload appears in the URL query string -- the request itself contains the script tag. The stored payload appears in the POST body of the review submission. Both are XSS, but they look different in the logs. This matters because a detection rule written for one pattern will not catch the other.

Step 2: Understand the Sigma Rule Starter Template

Open materials/sigma-rule-starter.yml. This is not a complete rule. It is the YAML structure with placeholder detection logic -- you write the actual patterns.

The template has four key sections:

• logsource defines where Sigma looks for data. The category and product fields must match your environment. Check these against your Alloy configuration -- if they do not match, the rule compiles but never fires.
• detection defines what to look for. The selection block contains field names and patterns. The condition tells Sigma how to combine them.
• falsepositives documents what legitimate traffic might trigger the rule. This forces you to think about noise before you deploy.
• level sets the severity. This maps to the priority ordering from the TTP selection.

A Sigma rule is a hypothesis about what an attack looks like in log data. Writing one is the beginning of testing, not the end. The hypothesis might be wrong. The field names might not match. The pattern might be too broad or too narrow. You find out when you deploy and test.

Step 3: Write the XSS Detection Rule

Direct Claude to write a Sigma rule for the XSS pattern you found in the logs. Then immediately direct it to check its own work:

Write a Sigma rule that detects XSS payloads in the web access logs, based on the patterns we saw in the Grafana logs. Use the sigma-rule-starter.yml as the template structure.

After Claude produces the rule, direct it to self-review:

Check whether the field names in this Sigma rule match the actual label names in the Loki log stream. Open Grafana, look at a real log entry, and compare the field names in your rule to the labels on the log entry.

This is the first time you are using AI self-review as a verification technique. The specific prompt matters. "Check field names against the log stream" tells Claude exactly what to verify. A vague prompt like "do these rules look right?" produces confident reassurance, not useful findings. AI commonly generates Sigma rules with field names from its training data that do not match the actual log format in your environment. The rule will pass syntax validation but never fire in production.

Step 4: Convert the XSS Rule to LogQL and Deploy

Sigma rules are vendor-neutral. They describe what to detect, not how to query for it. To use the rule in Grafana, you need to convert it to LogQL -- the query language Loki uses.

Direct Claude to convert and deploy:

Convert the XSS Sigma rule to a LogQL query using pySigma. Then create a Grafana alert using that LogQL query.

The conversion step itself is a source of error. pySigma translates Sigma field names and operators into LogQL equivalents, but the mapping is not always transparent. A field name that works in Sigma might map to a different label in LogQL, or the pattern matching might change behavior. Compare the LogQL output to what you would write by hand.

The logging pipeline has three stages: Alloy collects logs from Docker containers, Loki stores and indexes them, and Grafana queries Loki. A failure at any stage breaks the chain. If your alert never fires, the problem could be in the Sigma rule, the pySigma conversion, the Grafana alert configuration, or the pipeline itself.

Step 5: Test the XSS Detection Rule

Replay the XSS attack from Unit 3:

Replay the reflected XSS attack against the search endpoint -- the same payload that worked in Unit 3. Then check whether the Grafana alert fired.

If the alert fires, your detection hypothesis was correct for this attack pattern. If it does not, investigate. The most common cause is a field name mismatch -- the Sigma rule references a field that does not exist in the actual log labels. The second most common cause is a conversion artifact from pySigma. Check the LogQL query in the alert definition against what the log entries actually contain.

This is the purple team feedback loop. You attacked the system. You wrote a rule to detect that attack. You replayed the attack to test the rule. The offense provides ground truth that the defense is measured against.

Step 6: Write and Test the Command Injection Detection Rule

The command injection attack produces a different log signature than XSS. The payload is in a different field, the pattern is different, and the detection logic must reflect that.

Direct Claude through the same cycle -- write, self-review, convert, deploy, test:

Write a Sigma rule for the command injection pattern we found in the logs. Use the same template structure but with detection patterns specific to command injection -- shell metacharacters, command separators, system utilities. Then check the field names against the actual Loki labels.

Convert the command injection Sigma rule to LogQL, deploy it as a Grafana alert, and replay the command injection attack to test it.

Notice how the detection logic differs from the XSS rule. XSS detection looks for script tags and event handlers in URL parameters. Command injection detection looks for shell metacharacters and system commands in POST bodies. Detection is not a template you copy -- it is a hypothesis shaped by the specific attack you observed.

Step 7: Write and Test the Credential Testing Detection Rule

Hydra's brute-force attempts produce a third pattern: a burst of failed login attempts from the same source in a short time window. This is fundamentally different from both XSS and command injection detection.

Write a Sigma rule that detects brute-force login attempts -- a rapid sequence of failed authentications to the admin login endpoint. Convert to LogQL, deploy as a Grafana alert, and test by replaying the Hydra credential test.

The credential testing rule might need a count threshold in the condition rather than a simple pattern match. A single failed login is normal. Twenty failed logins in thirty seconds from the same IP is a brute-force attempt. AI commonly writes broad detection patterns that match individual failed logins, which would fire constantly on legitimate users who mistype their passwords.

Step 8: Evaluate All Detection Rules Together

You now have at least three detection rules, each targeting a different attack type. Consider them as a system, not individually.

Review all deployed Sigma rules together. For each rule, assess: would it fire on legitimate customer activity on Ruta's real shop? What would a false positive look like? Are any rules too broad?

If this session has been long, check whether Claude's responses are still consistent with earlier decisions. Context degradation shows up as AI re-introducing patterns it was already told to avoid, or contradicting scope constraints from earlier in the session. If you notice inconsistencies, that is not a bug in the tool -- it is a structural property of long sessions where earlier context loses influence over later output.