Hades is an eBPF host intrusion detection system with 21 kernel hooks and one real-time event
Hades is a Host-Based Intrusion Detection System based on eBPF(mainly)
At a glance
- What is it?
- Hades is a Rust host-based intrusion detection system built on eBPF and netlink, declared as based on Tracee and ByteDance's Elkeid, with an agent described as mainly Elkeid 1.7. Its own documentation calls the backend a demo still under development, so the interesting material is the hook table: what is instrumented, which arguments are filtered, and which collector events are actually real time.
- Who is it for?
- Hades fits someone studying how host intrusion detection is instrumented in practice, since the hook list and its event IDs are the clearest published statement of what an eBPF based agent actually watches, and the collector's classification of periodic, real time, and configuration driven events is a useful checklist for asset inventory work.
- 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 131 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 October 2, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The backend calls itself a demo and the agent is Elkeid 1.7
The status statement is unambiguous. Hades is described as a host-based intrusion detection system based on eBPF and netlink with `cn_proc`, it is still under development, and the overview section says in as many words that this is a demo backend for now, still under dev. Pull requests and issues are invited.
The lineage is declared too. The project is based on Tracee from Aqua Security and Elkeid from ByteDance, and the architecture section is more specific: the agent part is mainly based on Elkeid version 1.7.
That single sentence explains most of the repository's shape. An eBPF agent that is derived from an existing one inherits its hook set, and the documentation says so directly: the hook fields are extended just like Elkeid. So Hades is best read as Elkeid plus a plugin layer and a different backend, not as a from-scratch detector.
The top level layout follows the same split, with an `agent/` directory, a `server/` directory for the backend, a `plugins/` directory holding each capability separately, an `SDK/` directory, images, and both English and Chinese READMEs. There is also a `.gitmodules` file, consistent with vendored components, plus a code of conduct and a contributing guide.
EDriver exposes 21 hooks, and the event IDs are the contract
The EDriver plugin is the eBPF layer, and its documented surface is a table of 21 hooks over tracepoints, kprobes, and uprobes. Each row carries a status and a numeric event ID, and those IDs are the stable contract a consumer of the stream depends on.
| Hook | Status | ID | | :--- | :--- | :---: | | tracepoint/syscalls/sys_enter_execve | ON | 700 | | tracepoint/syscalls/sys_enter_execveat | ON | 698 | | tracepoint/syscalls/sys_enter_memfd_create | ON | 614 | | kprobe/commit_creds | ON | 1011 | | kprobe/do_init_module | ON | 1026 | | kprobe/security_inode_create | ON | 1028 | | kprobe/security_inode_rename | ON | 1031 | | kprobe/security_sb_mount | ON | 1029 | | uprobe/trigger_sct_scan | ON | 1200 | | uprobe/trigger_idt_scan | ON | 1201 | | kprobe/security_bpf | ON | 1204 |
The numbering is not cosmetic. Syscall enter tracepoints sit in the 600 to 700 range, the security kprobes cluster around 1020 to 1032, and the uprobes start at 1200, so a reader can tell from the ID alone which mechanism produced an event. Every hook listed is marked ON.
The coverage is the standard host-intrusion set: process creation through both `execve` and `execveat`, credential changes, module loading, mount activity, inode creation and renaming, and file permission checks.
Some hooks are filtered by argument, so coverage is narrower than the hook count
Three rows in the EDriver table carry an argument restriction in the status column, and these are the ones that decide how much signal you actually get.
`tracepoint/syscalls/sys_enter_prctl` is ON for `PR_SET_NAME` and `PR_SET_MM` only. That is process renaming and address space manipulation, not every prctl call. `tracepoint/syscalls/sys_enter_ptrace` is ON for `PTRACE_PEEKTEXT` and `PTRACE_POKEDATA` only, which is the process memory read and write pair, and not the rest of the ptrace surface.
The third is the most interesting: `k(ret)probe/udp_recvmsg` is ON for ports 53 and 5353 for DNS data. That is a kprobe plus a kretprobe pair on the socket receive path, narrowed to the two ports where DNS actually arrives. Catching DNS from a return probe rather than by parsing traffic means the kernel has already assembled the buffer, so the argument filter is where the payload is available.
The practical reading is that a hook count overstates coverage. Twenty-one hooks with three of them filtered to specific arguments is closer to eighteen general hooks plus three targeted ones, and the security kprobes for sockets, `security_socket_connect` and `security_socket_bind`, add outbound connection visibility on top.
Uprobes on kernel text scanning catch things kprobes cannot
Three hooks are uprobes rather than kprobes, and they target scanning functions: `uprobe/trigger_sct_scan` with ID 1200, `uprobe/trigger_idt_scan` with 1201, and `uprobe/trigger_module_scan` with 1203.
`sct_scan` is the function that walks the syscall table, `idt_scan` is the interrupt descriptor table walk, and a module scan walks loaded modules. Attaching a uprobe to those functions is how a detector looks for a kernel component that has patched those structures, which is the kind of rootkit behaviour that leaves no trace in the syscall path itself. A process that calls the scanner legitimately looks identical at the syscall layer, so hooking the scanner is the only place with a signal.
The remaining hook, `kprobe/security_bpf` with ID 1204, watches BPF program loading. That is a self-referential choice worth naming: Hades is an eBPF based detector, and it observes the same loading path an attacker would use to hide behaviour from it.
Together with `security_kernel_read_file` for reads of kernel files and `call_usermodehelper` for helpers spawned from kernel context, the set covers both directions: userspace reaching the kernel and the kernel acting on behalf of userspace.
Collector reports periodically, with exactly one real-time event
The Collector plugin inventories host state, and its legend defines three types: S for sync, which is real time, P for periodicity, and C for configuration based.
Of the twenty events in the table, exactly one is S. `ssh login` carries ID 3003 and is the only real-time event. `host detect` is the only C event, ID 3007, which is a sensible split since host identity changes far less often than anything else on the list. Everything else is periodic: processes 1001, crontab 2001, sshdconfig 3002, user 3004, sshconfig 3005, yum 3006, apps 3008, kmod 3009, disk 3010, systemd 3011, interface 3012, iptable 3013, bpf_program 3014, jar 3015, dpkg 3016, rpm 3017, container 3018, and socket 5001.
The numbering tells you which events are grouped together. The 3000 block is SSH and user related, the 3008 to 3018 block is software inventory across package managers, container runtimes, JVM jars, and kernel modules, and the two outliers, crontab at 2001 and socket at 5001, sit in their own ranges.
Reading the type column is the point: an inventory tool that collected everything in real time would be unusable, so the design is periodic state with one exception where delay would matter.
Five plugins have repository directories, two are only names
The plugin list is short and the naming is short with it: EDriver, Collector, Eguard, WDriver, and NCP, each with a directory under `plugins/`, plus Scanner and Logger, which are listed as bare names without a link.
EDriver and Collector are the two documented at length, with the full hook and event tables in the README. NCP gets one line: Netlink CN_PROC. That is a mechanism description rather than a capability one, and it is the second of the two kernel event sources named in the project description, the first being eBPF.
Netlink CN_PROC is the standard Linux mechanism for the kernel to tell userspace about process events, so having a plugin for it alongside the eBPF driver means two independent paths for process information. Eguard and WDriver are named and linked but not described in the visible documentation, which means what they do has to be read from their directories rather than from the overview.
The project also ships an `SDK/` directory and a `server/` directory, so the intended consumer of the event stream has a documented surface, and the presence of a `.gitmodules` file means at least one component is pulled in as a submodule rather than vendored directly.
Releases are tagged per component, with a three year gap in the agent
The release history is component-scoped rather than repository-scoped, which is consistent with the plugin layout. Two agent releases and one collector release appear in the history.
`agent-v1.1.0` was tagged on 2023-03-28 and `agent-v1.1.0` for the collector on 2023-03-27, one day apart. The next agent release, `agent-v1.1.1`, came on 2026-05-24, and the last push to the `main` branch is the same date. So the agent spent three years at 1.1.0 before a patch release, and the collector has not been tagged since 2023.
A patch version as the first release in three years is worth reading carefully: it says the API surface stayed stable and the changes were internal, but it also means the version number alone tells you nothing about how old the code is. Anyone pinning `agent-v1.1.1` is pinning code from 2026, and anyone pinning `1.1.0` might mean 2023.
The licence is Apache 2.0, and the project has joined 404Starlink, an open source project listing. Contact is handled by sending the word `Hades` to get a QR code.
Editorial conclusion
Hades fits someone studying how host intrusion detection is instrumented in practice, since the hook list and its event IDs are the clearest published statement of what an eBPF based agent actually watches, and the collector's classification of periodic, real time, and configuration driven events is a useful checklist for asset inventory work. It does not fit anyone expecting a production security product, because the backend is described as a demo still under development and the last agent release before 2026 was tagged in 2023. Before relying on it, read the argument filters in the hook table rather than assuming full coverage, and remember the project ships an SDK and separate plugin directories rather than one binary.
Frequently asked questions
What is the Hades host intrusion detection system?
Hades is a host-based intrusion detection system based mainly on eBPF with netlink cn_proc as a second source, written in Rust and licensed Apache 2.0. Its documentation says the backend is a demo still under development, and pull requests and issues are invited.
Which open source projects is Hades based on?
The project declares itself based on Tracee from Aqua Security and Elkeid from ByteDance. More specifically, the agent part is mainly based on Elkeid version 1.7, and the eBPF hook fields are extended in the same style.
What does the Hades EDriver plugin hook into?
EDriver defines 21 hooks over tracepoints, kprobes, and uprobes with fixed event IDs, including execve and execveat, commit_creds, do_init_module, inode and mount security functions, uprobe hooks on kernel scanning functions such as trigger_sct_scan, and security_bpf.
How often does the Hades Collector report events?
Three types are used: S for real time sync, P for periodicity, and C for configuration based. Of twenty events only ssh login is real-time, host detect is configuration-based, and the rest including processes, crontab, systemd, iptable, bpf_program, container, dpkg, rpm, and socket are periodic.
What is the NCP plugin in Hades?
NCP is the netlink cn_proc plugin, the second kernel event path alongside eBPF. The README describes it in a single line as Netlink CN_PROC rather than listing hooks or event IDs.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/chriskalix-hades)