Killing ransomware from inside the kernel: writing the response engine for an eBPF monitor in Rust

In part one of this story, I explained how an eBPF monitor detects ransomware by monitoring execve, openat, unlink, and mkdir system calls, streaming the events to userspace, and keeping a sliding window of timestamps for each process ID (PID) to score activity. This part focuses on the response after a verdict is triggered.

The response mechanism is designed to promptly terminate the suspicious process without requiring additional tools like Security Modules (LSMs) or kernel modules. The rationale is that kill(2) is a single syscall, and the event has already transferred from kernel to userspace via a zero-copy handoff, making any extra round-trip unnecessary. The decision to terminate the process is handled in Rust, ensuring that policy management remains in a debuggable, user-space environment rather than the potentially buggy kernel space.

Two primary race conditions were considered:

1. **Kill on Verdict, Not First Event**: A naive design would terminate a process upon detecting a single suspicious open. This could lead to false positives, such as when a database rebuild occurs. The monitoring system waits until the activity rate crosses the threshold within the one-second window before taking action. This reduces the likelihood of erroneous terminations and provides a more accurate assessment.

2. **PID Reuse**: Since the PID is a u32 and is converted to i32 for the kill syscall, there is a potential for PID reuse between the event capture and the termination attempt. Although the window is very small, this race condition could still be a concern. The design includes safeguards to verify that the process name associated with the recycled PID matches the reported process to mitigate this risk, though a full fix is planned for future updates.

The auto-kill feature is triggered based on the scoring mechanism outlined earlier. If the auto-kill feature is enabled, the system sends a SIGKILL to the process and logs the action, including the timestamp, PID, command name, and success status of the termination attempt. The code snippet provided demonstrates the function responsible for sending the SIGKILL and returning its success status.

To test the auto-kill feature safely, a controlled environment is suggested. A simple ransomware-like behavior is simulated by creating numerous file opens in a controlled manner, and then enabling the auto-kill feature. This controlled testing ensures that the response mechanism functions as intended without risking the integrity of the system or causing unnecessary disruptions.

The final consideration addresses a critical aspect of security: ensuring that the response engine itself does not become the attack. The Talus agent, which implements this response mechanism, is designed with minimal capabilities to reduce the potential impact if it is compromised. Specific steps include dropping unnecessary capabilities and ensuring that the agent functions as intended with strict controls in place.

In summary, the response engine for the eBPF monitor, written in Rust, is efficient, robust, and carefully designed to minimize the chance of false positives and mitigate risks associated with process termination. The agent's capability to auto-kill processes is balanced with stringent security measures to prevent it from being exploited as an attack vector.