How it works

What InnerWarden Detects

Name: InnerWarden
Author: InnerWarden

The attack families InnerWarden catches, from brute force to firmware rootkits, and the exact collectors, detectors, and eBPF programs behind each.

What It Detects

For: a technical evaluator deciding whether InnerWarden covers the attacks you care about. You'll get the threat families it sees, and exactly how it sees each one.

Most security tools hand you a list of detectors and let you work out what they protect against. This page does the opposite: it starts from the attack and tells you what InnerWarden uses to catch it. The plain answer first, the kernel-level detail underneath.

The short version: InnerWarden watches the machine from firmware up to userspace, in real time, with eBPF in the kernel. It does not rely on CVE signatures to recognise an exploit. It recognises behaviour, the things an attacker has to do regardless of which bug they used to get in, and it stitches single events into attack chains across layers. So a brand-new exploit with no published signature still trips the same alarms as a known one, because the post-exploit moves (spawn a shell, read /etc/shadow, dial out to a C2 server) are the same.

The numbers behind it, if you want the depth up front: 30 collectors feed 82 detectors, backed by 47 eBPF programs in the kernel (27 loaded in production, kernel-dependent), 69 cross-layer correlation rules, 208 Sigma rules + 9 built-in, a YARA binary scanner, an on-device anomaly model, and ~55 MITRE ATT&CK technique IDs (90+ detector-to-technique mappings) across 12 tactics. The rest of this page is those numbers told as a story.

Where to go next: the full collector and detector inventory lives in Architecture and the source tree that licensed customers can audit. How an alert turns into a contained attacker is Responding to Incidents. How to extend detection with your own rule is Write a Module.

The threat families

Threat family	What you're protected from	How it sees it (short)
Intrusion and brute force	Someone forcing their way in over SSH or the web	auth log + native capture, sliding-window detectors
Credential theft	Reading secrets, dumping memory, harvesting keys	eBPF file opens + memory forensics
Privilege escalation	A normal user (or a payload) becoming root	eBPF `commit_creds` + provenance, technique-independent
Persistence	Backdoors that survive a reboot	integrity polling + Sigma + eBPF
Command-and-control and exfil	The box phoning home or shipping data out	native DNS/HTTP/TLS capture + beacon detectors
Ransomware	Mass encryption of your files	fanotify real-time + entropy analysis
Container escape	Breaking out of a container onto the host	eBPF LSM + namespace and mount detectors
Rootkit and firmware	Hiding in the kernel, the hypervisor, or below	kernel integrity + Ring -1/-2 audits
DDoS and floods	Traffic designed to take you down	XDP wire-speed + the Shield module

Each family is below, with the real collector, detector, and eBPF names so you can verify the claim, and the MITRE tactic it maps to.

Intrusion and brute force

What you're protected from: an attacker guessing passwords against SSH, spraying a stolen username list, or scanning your web app with automated tools. The first move of most internet-facing compromises.

How it sees it:

auth_log and journald parse every SSH attempt (failures, logins, invalid users). The ssh_bruteforce detector runs a sliding window per source IP; credential_stuffing watches for many distinct usernames from one IP (a spray); distributed_ssh catches the same campaign coming from many IPs at once.
Web side: http_capture (a raw AF_PACKET socket, no nginx logs required) reads method, path, Host, and User-Agent off the wire. web_scan flags scanner error-rate bursts, search_abuse flags path-fuzzing, and user_agent_scanner recognises 20 known tools (Nikto, sqlmap, Nuclei, Masscan, Burp, Metasploit, and more) on sight.
tls_fingerprint computes JA3 and JA4 fingerprints from the TLS ClientHello and matches 10 known-malicious ones (Cobalt Strike, Metasploit, Emotet), so a tool is recognised even over an encrypted channel.

MITRE: Reconnaissance (T1595), Initial Access, Credential Access (T1110 brute force).

Credential theft

What you're protected from: reading /etc/shadow, dumping process memory, scraping SSH private keys or cloud credentials, planting a keylogger. The step an attacker takes to move from one box to the rest of your estate.

How it sees it:

The eBPF openat hook always emits genuine reads of credential files (it never rate-limits those, even while it throttles ordinary /etc noise). The credential_harvest detector flags shadow-file access, /proc/*/maps scraping, and mimikatz-class behaviour; ssh_key_injection and the integrity collector catch writes to authorized_keys (raising a specific ssh.authorized_keys_changed, not a generic file-changed event).
proc_maps (memory forensics) scans /proc/[pid]/maps for the giveaways of in-memory credential theft: RWX regions, injected code, and LD_PRELOAD hooks.
keylogger_bash_trap and clipboard_read cover the quieter harvesting paths; imds_ssrf catches an attacker pivoting to the cloud metadata endpoint to steal instance credentials.

MITRE: Credential Access (T1003 OS credential dumping, T1552 unsecured credentials).

Privilege escalation

What you're protected from: a local exploit or a misconfiguration that turns a normal user, or a compromised service, into root. The difference between a contained foothold and game over.

How it sees it (and why it's technique-independent):

InnerWarden does not try to recognise each privesc CVE. It recognises the outcome and the provenance. An eBPF kprobe on commit_creds fires the instant any process transitions uid non-root to root. The privesc detector then judges legitimacy by the parent or self executable path, not the forgeable comm string, so a payload renamed sudo sitting in /tmp does not get a free pass.

Three detectors make this hold for zero-days:

untrusted_root_exec: a uid-0 process executing a binary from an unprivileged-writable path (/tmp, /home, /dev/shm, anything world-writable or not root-owned), outside any container runtime. About the most technique-independent post-exploit signal there is.
setns_owner: a root process joining a user namespace owned by a non-root uid from outside a container runtime, the classic userns / container-escape pivot. Backed by a dedicated setns(2) eBPF kprobe.
provenance: ties the lineage together so an illegitimate root action is caught regardless of which bug produced it.

The correlation engine then links illegitimate privilege provenance to a high-value root action and raises a single Critical incident, so you see "this got root and then did X" as one story, not two unrelated alerts.

MITRE: Privilege Escalation (T1068 exploitation, T1548 abuse elevation control, T1611 escape to host).

Persistence

What you're protected from: the backdoor an attacker plants so they keep their foothold after you reboot or after you think you've cleaned up. Cron jobs, systemd units, modified shell startup files, new user accounts, PAM tampering.

How it sees it:

The integrity collector SHA-256 polls the files attackers reach for: it raises a specific cron.tampering event for /etc/crontab, cron.d, and per-user crontabs (T1053.003). crontab_persistence, systemd_persistence, and startup_script_persistence cover the scheduling and service angles; user_creation catches useradd and direct /etc/passwd writes; pam_module_change catches authentication-backdoor PAM edits.
The Sigma engine adds log-based rules for the same ground (SSH authorized_keys, sudoers modification, new systemd service, kernel module load), with custom rules in rules/sigma/*.yml.
eBPF init_module / finit_module hooks and the kernel_module_load detector catch persistence that hides in a loadable kernel module.

MITRE: Persistence (T1053 scheduled task, T1543 system service, T1546 event-triggered, T1098 account manipulation).

Command-and-control and exfiltration

What you're protected from: a compromised host beaconing to its operator, tunnelling commands through DNS, or shipping your data out the door. The phase where a breach turns into real damage.

How it sees it:

Native capture means no Suricata or extra agent: dns_capture (UDP:53) feeds dns_tunneling and dns_c2 (high-entropy subdomains, abnormal query volume, TXT abuse), and http_capture feeds the web-side detectors. The TLS fingerprinting above catches C2 frameworks even over HTTPS.
The C2 family is broad on purpose: c2_callback (periodic beaconing), c2_non_standard_port, c2_protocol_tunneling, and c2_web_tunnel. eBPF connect and bind hooks give the kernel-level view of every outbound connection and listener.
Exfil: data_exfiltration, data_exfil_ebpf, outbound_anomaly, automated_file_collection, and lateral_egress_scp_rsync / lateral_egress_ssh catch large or unusual outbound transfers and staged-then-uploaded archives. Baseline learning flags a connection to a destination this process has never talked to before.

The kill-chain engine (an eBPF LSM program) recognises full exploit-to-C2 and data-exfiltration patterns by correlating syscalls in the kernel, and can block them at execve with no CVE signature needed.

MITRE: Command and Control (T1071 application-layer protocol, T1572 tunnelling, T1571 non-standard port), Exfiltration (T1041, T1048).

Ransomware

What you're protected from: mass encryption of your files, ransom-note dropping, and shadow-copy deletion, fast enough to matter.

How it sees it: fanotify_watch is real-time filesystem monitoring with Shannon-entropy analysis. It detects the burst signature directly (50+ writes in 10 seconds) and rising entropy that means content is being encrypted in place. The ransomware and data_destruction_pattern detectors add the note-creation and destructive-delete signals. Because the detection is behavioural (encrypt-many-files-fast), it does not depend on knowing the specific ransomware family.

MITRE: Impact (T1486 data encrypted for impact, T1490 inhibit recovery).

Container escape

What you're protected from: an attacker breaking out of a container to own the host underneath it, the thing that makes a single bad image a full-host compromise.

How it sees it:

The docker collector inspects every container.start and flags the dangerous shapes that enable escape: --privileged, a mounted Docker socket, and dangerous capabilities (SYS_ADMIN, SYS_PTRACE, SYS_MODULE, NET_ADMIN).
At runtime, container_escape, container_drift, cgroup_abuse, and docker_anomaly watch the live behaviour; container drift uses the overlayfs upper-layer check (a known-good Falco trick) to spot a container that has been tampered with since it started.
The eBPF LSM userns_create hook can block unshare(CLONE_NEWUSER) from a chain-flagged PID, and setns_owner (above) catches the namespace-join pivot. Every eBPF event carries a cgroup_id, so InnerWarden always knows whether something happened inside a container or on the host.

MITRE: Privilege Escalation (T1611 escape to host).

Rootkit and firmware

What you're protected from: the deepest hiding places, a kernel rootkit hiding processes and hooking syscalls, a weaponised eBPF program, or a threat below the OS entirely in the hypervisor, firmware, or SMM.

How it sees it:

kernel_integrity and the rootkit detector watch for the tells: syscall-table tampering (via /proc/kallsyms address monitoring), hidden processes, a new unexpected eBPF program (baselined at boot via bpftool, alert on anything new, this is the VoidLink-style eBPF-weaponisation defence), and /proc anomalies. eBPF kprobes on native_write_msr and acpi_evaluate_object catch MSR-write and ACPI-method rootkit techniques, and the LSM bpf hook catches malicious BPF program loads.
Below the OS: the firmware audit (firmware_integrity collector plus the agent's firmware tick) checks the BIOS/UEFI boot chain every few minutes (ESP binary hashes, UEFI variables like SecureBoot/DBX/PK/KEK, ACPI tables, DMI/SMBIOS baseline, kernel tainted flag) and recognises BlackLotus, LoJax, and MosaicRegressor-class firmware implants. A hypervisor integrity tick (Ring -1) and an SMM audit (Ring -2) run inline in the agent, so firmware-to-SMM-to-hypervisor coverage is real and deployed, not a roadmap item.
Correlation rules tie these layers together: a firmware finding plus a hypervisor finding becomes one "deep ring compromise" incident rather than two stray alerts.

MITRE: Defense Evasion (T1014 rootkit, T1542 pre-OS boot, T1601 modify system image).

DDoS and floods

What you're protected from: traffic floods meant to take the service down, SYN floods, UDP and ICMP floods, amplification.

How it sees it: the packet_flood detector spots the flood signature, and the Shield module does adaptive rate limiting and SYN tracking with escalation. The response side can drop offending IPs at wire speed: one XDP program blocks at the network-driver level (millions of packets per second, near-zero CPU) and, if you run Cloudflare, the block is pushed to the edge too. Shield runs inline inside the agent in production.

MITRE: Impact (T1498 network DoS, T1499 endpoint DoS).

What turns single events into attacks

Three things sit above the per-event detectors and are the reason InnerWarden catches campaigns, not just moments:

Cross-layer correlation (69 rules). Events from firmware, hypervisor, kernel, userspace, network, and the honeypot are stitched together by entity (IP, user, container, PID) inside a time window. A recon scan, then a successful login, then a privilege escalation from the same IP becomes one attack-chain incident. Representative rules: VM-escape chains, deep-ring (firmware + hypervisor) compromise, and the illegitimate-privilege-to-root-action chain described above. A "3+ low-severity detectors from one IP" rule escalates a quiet campaign to High, and a silence-detection rule treats an unexplained drop in event rate as a possible compromise.
Baseline learning (no rules). Over a 7-day training window the agent learns what normal looks like on this specific host: event rate per hour by source, process lineages (which parent spawns which child), user login hours, and outbound destinations per process. After that it flags the anomalies rules can't anticipate, an unseen lineage like nginx -> sh, a login at 3am, a never-seen outbound destination, or a sudden silence.
On-device anomaly model + intelligence. A small autoencoder anomaly model and the Local Warden classifier run on-device (no data leaves the box). Attacker DNA fingerprints behaviour across sessions so a returning attacker is recognised even from a new IP, and campaigns are clustered by shared C2 infrastructure and overlapping techniques. Threat feeds (AbuseIPDB, DShield, CrowdSec, custom IOC feeds, VirusTotal hash checks) and the YARA binary scanner (executed-binary scanning for miners, webshells, packers, Cobalt Strike, Metasploit) add the known-bad layer on top of the behavioural one.

A note on guarding AI agents

Everything above defends the host. InnerWarden's second job is to guard the AI agents running on the host, screening what an agent's tool calls try to do before they happen, so a tricked agent is caught from the outside. That is a different surface with its own detection (command-pattern analysis, MCP traffic inspection, agent-threat rules) and it has its own pages: AI Agent Guardrail and Connect Your Agent.

Verify it yourself

The detector and collector lists here are kept honest by a CI check (scripts/verify-doc-vs-source.sh) that fails the build if the source tree and the docs disagree. Licensed customers with source access can verify the canonical inventory directly: one .rs file per detector in crates/sensor/src/detectors/ and per collector in crates/sensor/src/collectors/. For the eBPF program list, the authoritative source is crates/sensor-ebpf/src/main.rs. See Architecture for the full map and Data Formats for the exact shape of the events and incidents these detectors emit.