--
chkrootkit
Overview
chkrootkit is a host-based scanner that checks a Linux/Unix system for signs of known rootkits and common indicators of compromise (IoCs). It runs a collection of tests that look for suspicious binaries, modified system tools, hidden processes, and unusual network behavior. It is most useful as a quick, repeatable signal in incident triage and as part of a layered monitoring strategy, not as a guarantee that a system is clean.
History
- Rootkit scanners emerged as systems became routinely exposed to internet threats and attackers began replacing core utilities (for example,
ps,netstat) to hide activity. chkrootkitgained traction as a lightweight, scriptable scanner that can be run locally without complex dependencies.
Adoption
chkrootkit is commonly used in:
- Basic incident response triage on Linux hosts
- Routine “sanity checks” on servers when compromise is suspected
- Environments where a lightweight, offline-capable scanner is preferred
- Legacy and minimal systems where heavier EDR tooling is unavailable
Maintainer
Maintained by the chkrootkit project/community.
Best when to use
- You need a quick, local scan for common rootkit indicators
- You want an additional signal alongside logs, EDR, and integrity monitoring
- You are triaging a host and need fast checks before deeper forensics
- You can run scans from a trusted administrative session (console or well-controlled SSH)
Not suitable when
- You require detection of new/unknown rootkits beyond known signatures and heuristics
- You cannot trust the host OS (a sophisticated rootkit can subvert local tools)
- You need centralized fleet detection and response without additional tooling
- You need evidence-grade forensic collection (use dedicated forensics tooling)
Compatibility notes
- Primarily targets Linux and some Unix-like systems; results and tests vary by platform.
- Output may differ across distributions due to different binary locations and tooling.
- A highly compromised system can influence scan results; prefer running checks from a trusted environment when possible.
chkrootkit runs on the host it is scanning. If the host is heavily compromised, local scanners can be evaded. Treat results as one signal, not proof of absence.
How it works
chkrootkit runs a suite of checks that can include:
- Known rootkit string/signature checks against common system paths
- Behavioral and heuristic checks (hidden processes, suspicious interfaces)
- Comparison and validation of expected system tool behaviors
Key operational points:
- Many alerts are heuristic and require follow-up verification.
- Some “not infected” messages are informational rather than definitive.
- Running from a trusted shell with minimal interference improves reliability.
Installation
Verify if already installed (read-only)
command -v chkrootkit >/dev/null && chkrootkit -V || echo "chkrootkit not installed"
Install via package manager
- Debian/Ubuntu
- Fedora/RHEL family
- Arch
sudo apt update
sudo apt install chkrootkit
sudo dnf install chkrootkit
sudo pacman -S chkrootkit
Some distributions may ship older versions or apply patches. Confirm your installed version with chkrootkit -V and rely on distro security updates.
Common commands and options
Basic scan (recommended starting point)
Run as root for best coverage:
sudo chkrootkit
Run specific tests
List supported tests (help output varies by version):
chkrootkit --help 2>/dev/null || chkrootkit -h
Run one or more tests (example pattern):
sudo chkrootkit <testname>
Run with a custom root directory (advanced / offline mounts)
When scanning a mounted filesystem (for example, a suspected compromised disk mounted at /mnt/target), use the root directory option if supported by your build:
sudo chkrootkit -r /mnt/target
The -r option exists in many builds, but flags can vary by distro packaging. If -r is not recognized, rely on a live-response approach from a trusted rescue environment and use additional tools for offline analysis.
Save output for review
sudo chkrootkit | tee /var/tmp/chkrootkit-$(date +%F).log
Practical use cases
Triage a suspected host compromise
- Capture basic host context (read-only):
uname -a
uptime
who
last -n 20
- Run the scanner and save output:
sudo chkrootkit | tee /var/tmp/chkrootkit-$(date +%F-%H%M).log
- Corroborate any findings with independent checks (see Troubleshooting).
Scan a server after unexpected behavior
Symptoms such as unexplained CPU usage, unknown listeners, or altered binaries can justify a scan.
Before scanning, gather read-only indicators:
sudo ss -lntp
ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head
Then run:
sudo chkrootkit
Interpreting results
chkrootkit output typically includes:
- “INFECTED” or suspicious matches
- Informational lines (“not infected” or checks performed)
- Warnings when a check cannot run fully
Treat alerts as leads:
- Validate suspicious binaries against trusted package checks.
- Compare running processes with system accounting and logs.
- Inspect persistence mechanisms (cron, systemd units, init scripts).
Some detections are heuristic and can trigger on legitimate admin tools, containers, or custom builds. Confirm findings with additional evidence before taking destructive actions.
Follow-up verification steps
Check for unexpected listeners (read-only)
sudo ss -lntp
sudo ss -lntp | grep -E ':(22|80|443|3306|5432|6379|27017)\b' || true
Validate system binaries against packages
Debian/Ubuntu
sudo debsums -s 2>/dev/null || true
dpkg -V 2>/dev/null | head
RHEL/Fedora
rpm -Va 2>/dev/null | head
If debsums is not installed, install it before relying on it. Package verification is one of the most reliable ways to detect replaced system binaries when the package database is intact.
Review persistence points
sudo systemctl list-unit-files --state=enabled
sudo crontab -l 2>/dev/null || true
sudo ls -la /etc/cron.* 2>/dev/null || true
sudo find /etc/systemd/system -maxdepth 2 -type f -name "*.service" 2>/dev/null | head
Review recent auth activity
sudo last -n 50
sudo lastb -n 20 2>/dev/null || true
Troubleshooting
“INFECTED” reported for a known tool
Actions:
- Identify the exact file/path referenced in output.
- Hash the file and compare to a known-good reference (from packages or a trusted source).
- Verify with package integrity checks (
dpkg -V,rpm -Va).
Example hash:
sha256sum /path/to/suspicious/binary
Missing tools or partial checks
Some checks rely on utilities like strings, ps, netstat/ss, etc. If dependencies are missing or replaced, results may be incomplete.
Verify tool availability:
command -v strings ps ss awk sed grep >/dev/null && echo "common tools present"
If you suspect core tools are compromised, use a trusted rescue environment for deeper analysis.
Scan results look inconsistent across runs
Potential causes:
- Race conditions with short-lived processes
- Containers/namespaces affecting process visibility
- Resource constraints or permissions
Mitigation:
- Run as root.
- Capture outputs with timestamps (
tee). - Cross-check with
journalctl,auditd, and system logs.
Security notes
If compromise is suspected, avoid “cleanup in place” as a first step. Preserve evidence, isolate the host, and plan recovery. Rebuilding from known-good images is often safer than attempting to surgically remove a rootkit.
Recommended response posture:
- Isolate the host from the network (or restrict to management plane) while maintaining access for investigation.
- Collect logs and artifacts (auth logs, process listings, network listeners).
- Rotate credentials and keys that may have been exposed.
- Rebuild from trusted sources and restore data carefully.
Quick reference
| Task | Command |
|---|---|
| -- | |
| Check if installed | command -v chkrootkit && chkrootkit -V |
| Run full scan | sudo chkrootkit |
| Save scan output | sudo chkrootkit | tee /var/tmp/chkrootkit-$(date +%F).log |
| Check listeners | sudo ss -lntp |
| Verify packages (Debian) | dpkg -V |
| Verify packages (RHEL/Fedora) | rpm -Va |
| Review enabled services | systemctl list-unit-files --state=enabled |
| Review cron directories | ls -la /etc/cron.* |