Hades: an eBPF and netlink HIDS with a demo backend
Hades is a Host-Based Intrusion Detection System based on eBPF(mainly)
At a glance
- What is it?
- Hades is a Rust HIDS built on eBPF tracepoints, kprobes and uprobes plus netlink CN_PROC, derived from Tracee and Elkeid. It is honest about being under development, and that honesty should shape how you read it.
- Who is it for?
- Adopt Hades if you want a Rust eBPF HIDS whose hook table you can read before you deploy it, and you are willing to treat the repository as a moving target. Do not adopt it if you need a supported product with a stable backend, or if you cannot read the plugin source to confirm what each hook emits.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 115 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Hades aims at: kernel events plus host state
A host intrusion detection agent has to answer two different questions. What is happening right now, and what does this machine look like. Most tools pick one. Hades tries to cover both. The eBPF driver watches kernel activity through 21 hooks, and the collector sweeps host state on a schedule. The README splits them into separate plugins: EDriver for the eBPF side, Collector for host inventory and configuration, plus Eguard, WDriver, NCP, Scanner and Logger. NCP is the netlink CN_PROC piece, which the README lists as its own plugin and describes only as Netlink CN_PROC. The intended audience is an engineer or small security team running Linux servers who wants process, network and configuration telemetry in one agent rather than stitching together auditd rules and a separate inventory script. The project is Apache-2.0 and written mainly in Rust, with Go and C in the topic list, which matches a plugin layout that mixes a userspace agent with eBPF programs.
What the 21 eBPF hooks actually watch
The hook table is the most concrete thing in the repository, and it is worth reading line by line because it tells you what the agent can and cannot see. Execve and execveat are hooked at the syscall tracepoint, which is the standard place to catch process starts. memfd_create is hooked too, which matters because fileless execution often goes through an anonymous memory file rather than a path on disk. commit_creds is a kprobe, so privilege changes are visible at the point the kernel installs new credentials. Network activity comes through security_socket_connect and security_socket_bind, and DNS data is pulled from udp_recvmsg filtered to ports 53 and 5353. That filter is narrow: DNS over 853, over 5353 variants outside the listed port, or over TCP will not appear in that hook. Kernel tampering gets several hooks: do_init_module, security_kernel_read_file, security_bpf and call_usermodehelper. Filesystem changes are covered by security_inode_create, security_inode_rename, security_inode_link, security_sb_mount and security_file_permission. There are also uprobes named trigger_sct_scan, trigger_idt_scan and trigger_module_scan, which look like on-demand scan triggers rather than continuous monitoring. Each hook carries a numeric ID, from 700 for execve down to 1204 for security_bpf, and the README says the fields are extended just like Elkeid. Those IDs are the contract between the driver and whatever consumes the events.
The collector is a periodic sweep, not a stream
The collector table uses three types: S for sync or real-time, P for periodicity, C for configuration-based. Almost everything is P. Processes, crontab, sshdconfig, user, sshconfig, yum, apps, kmod, disk, systemd, interface, iptable, bpf_program, jar, dpkg, rpm, container and socket are all periodic, each with its own event ID in the 1001 to 5001 range. Only ssh login is marked S, and only host detect is marked C. That design has a direct consequence for detection latency: a crontab entry added and removed between two collection cycles will not be captured by the collector, and a package installed and uninstalled inside the interval leaves only whatever the periodic diff happened to catch. The eBPF side is the real-time path, and the collector is the baseline and drift path. Treating the collector as an alerting source will produce gaps. Treating it as inventory and change tracking is closer to what the type column implies. The socket event at ID 5001 sits apart from the rest of the numbering, which suggests it was added later or belongs to a different producer, though the README does not say.
Getting it running: plugins, builds and the missing backend
The README does not give an install command, a config file example, or a default path. What it does give is the repository layout. Each plugin lives under plugins/ with its own directory: plugins/edriver, plugins/collector, plugins/eguard, plugins/wdriver, plugins/ncp, plus Scanner and Logger. The CI badges at the top of the README point at three separate workflows, ci-edriver.yaml, ci-collector.yaml and ci-agent.yaml, which tells you the build is split per component rather than a single top-level binary. Releases follow the same split: agent-v1.1.1 and agent-v1.1.0 for the agent, collector-v1.1.0 for the collector. If you want to try Hades, the realistic path is to clone the repository, read the workflow files to see how each plugin is built, and build the plugin you need from its own directory. There is no documented configuration key list in the supplied material, so any claim about specific config keys would be invented. The overview screenshots are described in the README itself as a demo backend, still under development, which means the collection side is more finished than the consumption side.
Where Hades is the wrong tool
The first limitation is stated by the project: it is still under development, and the backend is a demo. An agent without a supported backend means you own the pipeline from event to storage to alert. The second is release cadence. agent-v1.1.0 landed in March 2023 and agent-v1.1.1 in May 2026, a gap of roughly three years between agent releases, so the version number is not a reliable guide to how much the main branch has moved. The third is the kprobe surface. Hooks like commit_creds, security_socket_connect and security_kernel_read_file attach to kernel functions whose signatures and availability vary by kernel version and by distribution backports, and the README gives no supported kernel range. The fourth is the DNS filter, which is limited to ports 53 and 5353 on udp_recvmsg. The fifth is the collector interval, which is not documented in the supplied material, so you cannot reason about worst-case detection latency for a crontab or systemd change without reading the source. If your requirement is a signed, supported agent with a vendor-backed console, Hades is not that.
How it differs from Tracee and from auditd
The README states that Hades is based on Tracee and Elkeid, and that the agent part follows Elkeid version 1.7. The difference from Tracee is scope. Tracee is an eBPF runtime security tool built around tracing and detection signatures, and its primary output is the event stream and the rules applied to it. Hades keeps the eBPF event source but adds the collector plugin, so host state such as crontab, systemd units, iptables rules, kernel modules, installed packages, containers and listening sockets is part of the same agent rather than a separate inventory tool. That is a real architectural difference: Elkeid's influence shows in the field layout and in the decision to ship host inventory alongside kernel events. Against auditd, the difference is the event model. Auditd rules are configured per syscall and write to a local audit log, and the collector-style state above is not auditd's job at all. Hades emits structured events with numeric IDs from a fixed hook set, which is easier to route into a stream processor but gives you less freedom to add a new syscall watch without writing eBPF code. Neither comparison makes Hades better in the abstract; they describe which parts you would have to build yourself if you chose the other.
Maintenance, licence and what to check before trusting an event
Hades is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notices, and it includes a patent grant. It also means no warranty, so the operational risk sits with you. Because the project derives from Tracee and Elkeid, if you redistribute a modified agent you should check what notices those upstream projects require, and that is a question for your own legal review rather than something the README settles. The maintenance cost is the plugin split itself. Six plugins plus Scanner and Logger means six build targets to keep working, and the CI workflows named in the README show the project already treats them as separate pipelines. Upgrading the agent does not necessarily upgrade the collector, since they version independently. Before you trust any single event, open the plugin directory for the hook or collector event you care about and confirm the fields and the trigger condition in the source, because the README table gives you the hook name and the ID but not the payload.
Editorial conclusion
Adopt Hades if you want a Rust eBPF HIDS whose hook table you can read before you deploy it, and you are willing to treat the repository as a moving target. Do not adopt it if you need a supported product with a stable backend, or if you cannot read the plugin source to confirm what each hook emits. Verify first: whether the main branch builds the edriver, collector and agent plugins as they stand, which kernel versions your fleet runs against the kprobe and tracepoint set, and whether the 21 hooks cover the syscall paths you actually care about. The README calls the backend a demo, so plan for the data path, not just the agent.
Community notes