Rootkit Detection with rkhunter and chkrootkit

1. What rkhunter and chkrootkit Really Check

rkhunter (Rootkit Hunter) and chkrootkit are not antivirus programs in the classic sense, but diagnostic tools that check the current state of a Linux system against known anomalies and a stored reference state. Both work largely as shell scripts that scan system binaries, kernel modules, network interfaces, and configuration files, reporting deviations that are typical of a compromise. No single test proves an infection on its own, each test only produces a signal that must be evaluated in context.

The value of both tools lies in the combination of many small, specific checks: MD5 checksums of /bin and /sbin, known file names and directories from historical rootkits, suspicious SUID bits, hidden entries in network interface status, and discrepancies between different system calls used to list processes. Anyone who treats rkhunter and chkrootkit as an additional control layer alongside firewalling, SSH hardening, and regular updates gains genuine value. Anyone who mistakes them for complete protection is systematically misjudging their scope.

2. Signature-Based Detection of Known Rootkits

The core of rkhunter is a maintained database of known rootkit signatures: characteristic file names, directory structures, and byte patterns left behind by documented rootkit families such as Adore, T0rn, Suckit, or Beastkit. On every run, rkhunter --check compares the filesystem against this list and reports matches as a Warning. chkrootkit follows the same approach with its own, smaller set of tests that specifically look for strings and artifacts of known LKM trojans and user-space rootkits.

These signature databases are refreshed via rkhunter --update, which pulls new definitions from the configured mirrors. What matters is that a match means this exact known pattern was found, not a heuristic assessment of "suspicious" behavior. That is precisely what makes the detection precise against known threats, but ineffective against any rootkit that is not in the database because it is new, custom-built, or written specifically for the target system.

#!/usr/bin/env bash
# Update the signature database, then run a signature-focused check
rkhunter --update
rkhunter --versioncheck

# Run only the known-rootkit signature tests
rkhunter --check --enable known_rkts --disable all

3. File Integrity and Suspicious Permissions

A second core check area is the integrity of critical system binaries. On its first run, rkhunter builds a baseline via rkhunter --propupd with MD5 hashes and metadata for files such as /bin/login, /usr/sbin/sshd, or /bin/ps. On every subsequent run, these hashes are recalculated and compared against the stored baseline. A mismatch means one of two things: the file was replaced by a legitimate package update, or it was swapped for a trojanized binary that mimics the same function while carrying extra backdoors.

Both tools additionally check for unexpected SUID and SGID bits, files with unusual owners in /etc and /dev, and hidden dot-prefixed files in unusual system paths, a classic hiding spot for rootkit components. debsums -c or rpm -Va provide a second, independent confirmation, since they check against the package manager rather than a locally stored baseline, which matters for cross-checks in a suspected incident.

4. Spotting Hidden Processes and Network Anomalies

Classic rootkits manipulate system tools like ps, netstat, or ls so that certain processes, ports, or files disappear from the output. chkrootkit includes the chkproc test for exactly this, comparing the process list from /proc directly against the output of ps. A discrepancy, a process that exists in /proc but is missing from ps, is a strong indicator of a manipulated system binary or a loadable kernel module rootkit intercepting system calls.

rkhunter complements this with network checks: it verifies whether a network interface is running in promiscuous mode, which can indicate an installed sniffer, and checks known backdoor ports against a list of typical trojan default ports. Both approaches are valuable but limited: a cleanly implemented kernel rootkit can falsify both the /proc data and the network statistics at the kernel level, meaning even this cross-check no longer produces a reliable result.

#!/usr/bin/env bash
# Compare /proc process list against ps output directly (chkrootkit's chkproc logic)
chkrootkit -x chkproc

# Check network interfaces for promiscuous mode manually
ip link show | grep -i promisc

# List listening ports to cross-check against rkhunter's backdoor port list
ss -tulpn

5. Installation and Initial Configuration

On Debian and Ubuntu systems, both tools install from the standard package repositories: apt install rkhunter chkrootkit. Right after installation, rkhunter --update should be run to pull the current signature database, followed by rkhunter --propupd to create the file baseline on a system assumed to be clean. This order matters: building a baseline on an already-compromised system permanently records the manipulated files as "normal", rendering the tool worthless.

The configuration file /etc/rkhunter.conf controls, among other things, whether true-positive alerts for known, legitimate system deviations get suppressed. On systems running Docker, unusual SSH configurations, or configuration management tools, an unconfigured default installation regularly produces false positives that dilute the signal of genuine warnings. A clean initial configuration reduces this noise floor before the tool moves into production baseline operation.

; /etc/rkhunter.conf - selected production settings
; Automatically update signature mirrors before each check
UPDATE_MIRRORS=1
MIRRORS_MODE=0

; Disable interactive prompts for unattended cron execution
CRON_DAILY_RUN=true
CONFIGFILE_CHECK=1

; Explicitly document why root SSH login is (not) allowed here
ALLOW_SSH_ROOT_USER=no
ALLOW_SSH_PROT_V1=0

; Whitelist scripts flagged as false positives after manual review
SCRIPTWHITELIST=/usr/bin/whatis
SCRIPTWHITELIST=/usr/bin/lwp-request

; Package manager used to cross-check file properties
PKGMGR=DPKG

6. Building a Baseline and Scheduling It as a Cron Job

The real benefit only comes from regular, automated runs. The Debian package sets up a daily cron job by default under /etc/cron.daily/rkhunter, which emails results provided CRON_DAILY_RUN=true is set in /etc/default/rkhunter. For chkrootkit, a dedicated cron job or systemd timer needs to be added, since it ships with no built-in scheduler. It is important that rkhunter --propupd is re-run after every legitimate system update, otherwise every following run reports the same, already-explained file changes as new warnings.

This baseline maintenance is where many operators fail: a scanner that produces twenty expected warnings on every run gets ignored after a short time, and that is exactly when a real finding slips through. Clean operation logs every deviation, attributes it to a known cause, and updates the baseline only after that review, never automatically and unseen.

#!/usr/bin/env bash
# Run after every verified package update to avoid stale-baseline false positives
apt full-upgrade -y
rkhunter --propupd
rkhunter --check --sk --report-warnings-only >> /var/log/rkhunter-manual.log

# Unattended nightly run with warnings-only output for alerting pipelines
rkhunter --check --sk --nocolors --report-warnings-only
echo "Exit code: $?"   # 0 = clean, 1 = warnings found

7. The Limits: What These Tools Cannot Detect

The most important limitation is structural: both tools primarily detect what is already known and stored in their signature database. A newly developed rootkit written specifically for one particular system, a so-called custom or zero-day rootkit, appears in no signature database and is simply not found by signature-based detection. An attacker with root privileges can also, in theory, tamper with the locally stored baseline itself, so that a manipulated binary is thereafter considered "known and correct".

Kernel-level rootkits pose the biggest challenge: they can intercept system calls at a layer below rkhunter and chkrootkit, and thereby falsify exactly the data both tools rely on, such as the output of /proc or network statistics. For reliable results, a suspected incident should therefore always be verified additionally with tools that run outside the potentially compromised system, for example live-boot media, external integrity checks, or network traffic analysis from a separate host.

8. Correctly Interpreting a Positive Finding

A Warning is not proof of compromise, but a signal that requires follow-up work. The first step is always to look up the specific test name in the log (/var/log/rkhunter.log) and determine exactly which file or behavior triggered it. For file changes, comparing against dpkg -V packagename or debsums helps establish whether the change is explained by a regular package update. If both sources agree, it is usually an explainable false positive that can be folded into the baseline after review.

If the suspicion is confirmed instead, for example because a binary cannot be explained by dpkg or any known update, and chkrootkit independently flags the same area as suspicious, the system must be treated as compromised. From that point on: do not run forensic analysis using the potentially manipulated tools on the affected system itself, isolate the host from the network, capture disk images for offline analysis, and when in doubt, rebuild from scratch instead of "cleaning up", since a fully clean state after a root-level compromise is practically impossible to guarantee.

{
  "check": "rootkit_scan_summary",
  "host": "shop-prod-02",
  "timestamp": "2026-07-12T03:05:00Z",
  "tool": "rkhunter",
  "tests_run": 312,
  "warnings": 1,
  "findings": [
    {
      "test": "File properties changed",
      "path": "/usr/sbin/sshd",
      "expected_md5": "a1b2c3d4e5f6",
      "current_md5": "9f8e7d6c5b4a",
      "explained_by_update": true,
      "package_version": "1:9.6p1-3ubuntu13.5"
    }
  ],
  "status": "reviewed_false_positive",
  "baseline_updated": "2026-07-12T03:10:00Z"
}

9. rkhunter vs. chkrootkit Compared

Both tools complement rather than replace each other: rkhunter is more extensively configurable and maintains a larger, actively updated signature database along with baseline functionality, while chkrootkit is leaner and provides an independent second view of the process list through its chkproc test. The biggest practical benefit comes from running both in parallel: when their results agree, confidence in a finding rises significantly.

In practice, a weekly or daily run of both tools with structured log review pays off far better than relying on a single tool. The combination reduces blind spots, but in no case replaces a complete security strategy built on firewalling, hardening, access logging, and regular updates.

10. Summary

rkhunter and chkrootkit check known rootkit signatures, file integrity against a stored baseline, and discrepancies in process and network data that indicate manipulated system tools. Both tools are valuable, free building blocks of a security strategy when run regularly as a scheduled baseline check via cron, kept up to date with fresh signature databases, and maintained by re-running rkhunter --propupd after every legitimate update.

The central limitation remains structural: signature-based detection only finds what is already known, a new or specifically developed rootkit stays undetected. A positive finding is always a signal, never proof, and it demands manual verification against the package manager and, when in doubt, analysis from outside the affected system. Anyone who treats rkhunter and chkrootkit as one of several control layers alongside firewalling, hardening, and monitoring, rather than as complete protection, gains a realistic and lasting security benefit.

11. FAQ: Rootkit Detection with rkhunter and chkrootkit