LKRG watches the kernel from the inside. The moment something tries to subvert the integrity of the kernel or task credentials (e.g., a privilege escalation attempt), LKRG fires and can stop the attack in the same move. But a blocked attempt is still an attempt. Someone is attacking that host, and they may get another try. Stopping the attack is only the first step. Your security team still has to see it, connect it to the next one, and respond to the pattern, and none of that happens while the record sits in a local log on the host under attack.
So the alert is only half the job. The other half is getting it off the box, in front of a team that can act on it and into storage the attack can't reach. That's what routing LKRG events into Wazuh is for. Kernel events land in the same console as your host and application alerts, and a copy lives out of band, off the machine that raised it.
Getting the alert off the box is the hard part
An alert only does you good if it reaches somewhere you're watching. And getting it there is hardest when the kernel itself is the target.
When LKRG detects the kernel's own integrity is compromised (beyond "merely" credentials of a task), we by default set it to panic and halt the system on the spot. That's the safest response. But halting the box takes local userspace logging down with it, right when you most need the record.
This is where LKRG does something most tools can't. Its remote logging runs in the kernel module itself, so the event leaves straight from the kernel over an encrypted, send-only connection, without waiting on the disk, the filesystem, or any userspace software. As the box goes down, that gives the alert its best chance to get out ahead of it. It's not guaranteed, but it can be the difference between having the record and losing it. And because nothing extra runs on the protected host to do this, it adds almost no attack surface.
Solar Designer, who built LKRG's remote logging, has spoken about exactly this: getting the record out before the local copy can be lost, truncated, or rewritten.¹
Where lkrg-logger meets Wazuh
That encrypted feed has to land somewhere. On the receiving end, a central log server runs lkrg-logger, the userspace component that terminates LKRG's remote logging and writes the events down. That collector is your hook into Wazuh. It's the integration point, so Wazuh takes the kernel events from the log server instead of from every protected host, and they land in the same console as the rest of your security data. LKRG's kernel module sends, lkrg-logger receives, Wazuh reads.
You don't have to route it that way. LKRG also writes to the local kernel log, so you can forward those messages into Wazuh with rsyslog or a Wazuh Agent, the same as any other host log. That path is simpler to stand up, and it's the right call in plenty of environments. The tradeoff is what it depends on. Ordinary forwarding needs the host still running normally to carry the message, so in the panic case, it can go down with the box. The kernel-direct path is the one that can still get a message out as the system stops, which is why it's the one to use for the events that matter most.
The exact configuration steps live in the RLC-H documentation.
LKRG catches the attack in the kernel. Whether the evidence survives the host comes down to how you route it, so choose that path deliberately.
Further reading
- Rocky Linux from CIQ — Hardened (RLC Pro Hardened) — the product this runs on.
- Why BOD 26-04's three-day window assumes runtime kernel monitoring — why kernel-level visibility is the point.
- The real danger of systemd-coredump (CVE-2025-4598) — LKRG holding the line on a live exploit.
¹ Solar Designer, "Linux kernel remote logging: approaches, challenges, implementation," BSidesZagreb 2024.
