Expand rootkit monitoring and Claude docs

docs/RUNBOOKS.md

@@ -165,7 +165,9 @@ the transaction completes; a persistent mismatch is the real finding.
 ## Runbook 4 — Hidden listener / rootkit
 
 **Triggers:** `rootkit_hidden_process` (100022), `rootkit_hidden_module` (100023),
-`rootkit_hidden_port` (100024), `promiscuous_interface` (100025), and
+`rootkit_hidden_port` (100024), `promiscuous_interface` (100025),
+`rootkit_known_module` (100028), `rootkit_tainted_module` (100029),
+`kernel_tainted` (100030), `rootkit_hidden_udp_port` (100031), and
 `new_listener` (100013) for an unexplained open port.
 
 These come from cross-view checks: the same question asked two ways, answered
@@ -182,8 +184,16 @@ differently, because something is hiding.
 - `new_listener`: identify the owning process and whether its binary is
   package-owned. A hidden port that `rootcheck` sees but `ss` does not is far more
   serious than a forgotten service.
+- `rootkit_hidden_udp_port`: check whether a legitimate UDP service owns the
+  port; a port present in `/proc/net/udp*` but absent from `ss -u` suggests tool
+  output may be hooked.
 - A `rootkit_hidden_module` names a live kernel module absent from
   `/proc/modules` — strong evidence of an LKM rootkit.
+- A `rootkit_known_module` finding names a module associated with public LKM
+  rootkits; treat it as a high-confidence compromise until proven otherwise.
+- A `rootkit_tainted_module` or `kernel_tainted` finding may be legitimate
+  vendor/DKMS software, but unsigned/out-of-tree or force-loaded modules should
+  be explained and allowlisted only after review.
 
 **Contain**
 
@@ -197,8 +207,10 @@ differently, because something is hiding.
   reliably clean a host whose kernel is hooked. Preserve the disk image first.
 
 **False positives:** PID exit races (Sentinel re-verifies hidden PIDs to reduce
-these) and a legitimately promiscuous interface (a sniffer/monitoring tool you
-run). Confirm the owning process before escalating.
+these), a legitimately promiscuous interface (a sniffer/monitoring tool you
+run), and expected tainted vendor/DKMS modules. Confirm the owning process or
+module provenance before escalating; use `rootcheck_module_allow` only for
+modules you intentionally trust.
 
 ---