Menu
How to check the IDS alert log after an attack and decide whether the rule converged or needs refinement.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Generate Snort 3.9.7.0 IDS rules from a natural-language operator intent. Use whenever you need to write a new rule, refine an existing one, or recover from a syntax error.
Reuse Snort rules that already fired in past experiments. ALWAYS consult this skill at the start of every cycle BEFORE writing a new rule. Validated rules are known-good detection patterns persisted per attack_id under data/validated_rules/.
How to produce an evasion variant of a previously successful attack. Use this when request_variant=True on the attacker request.
How to execute the selected attack container on the attacker host and interpret the result.
How to map an operator intent to one of the attacks discovered on the attacker host. Use this before calling execute_attack.
Rule-generation refinement playbook for MQTT Brute Force — credential brute force against MQTT brokers on TCP port 1883 using dictionary attacks. Load when the operator intent maps to attack_id mqtt-bruteforce.
| name | alert-interpretation |
| description | How to check the IDS alert log after an attack and decide whether the rule converged or needs refinement. |
Use this skill immediately after trigger_attacker returns. The alert log is read from ids_alert_log_path on the IDS host.
check_alert_fired(sid: int) -> bool
Returns:
True — at least one alert for the given SID is present in the log.False — no alert for this SID was found.assign_sid (NOT the placeholder 0).True, the variant cycle has converged for this attack. Record the iteration with fired=True, populate final_rule and final_sid on your IterationResult, and return.False, the rule failed to detect the attack. You must regenerate:
container_exit_code and container_stderr — if the attack container errored, the issue is the attack arguments, not the rule.snort-rule-generation again with the feedback embedded in your reasoning, bump rev, validate, and redeploy.| Symptom | Likely Cause | Fix |
|---|---|---|
fired=False, container_exit_code=0 | Rule matcher is too narrow | Broaden matching options, drop overly specific content matches, lower detection_filter threshold |
fired=False, container_exit_code != 0 | Attack container failed | Look at container_stderr; record diagnosis but do not infinite-loop on rule changes |
If max_internal_attempts is exhausted and fired=False, return IterationResult(fired=False, diagnosis="attempts-exhausted") so the orchestrator can fail the experiment.