chkrootkit

chkrootkit checks a running Unix host for known rootkits β€” replaced system binaries, hidden processes and directories, LKM trojans, sniffer logs, suspicious open ports. Like Lynis and rkhunter it inspects a live system, so findings are dynamic_finding and carry no file path or line.

chkrootkit has two output shapes, and both are supported

Full output pairs each check with a verdict:

Checking `basename'...                                      not infected
Searching for for hidden directories using chkdirs...       WARNING
WARNING: chkdirs: Possible LKM Trojan installed (or chkdirs failed):

chkrootkit -q prints only the WARNING: lines β€” no check lines at all.

The parser handles both. A WARNING: line following a failed check is attached to it as an explanation; one with no check to attach to becomes a finding in its own right. Supporting only the full shape would mean a quiet report β€” the one most likely to be collected in CI β€” imported as clean.

Field mapping

chkrootkitDefectDojo
Checking … / Searching for … plus its verdicttitle
the verdictseverity
following WARNING: linesdescription
a standalone WARNING: lineits own finding, the text as title

Verdicts map as INFECTED β†’ High, WARNING β†’ Medium, Vulnerable but disabled β†’ Low, anything else β†’ Medium. chkrootkit has no check identifiers, so its own wording is the only name a finding has and there is no vuln_id_from_tool.

Clean verdicts are an explicit list, because chkrootkit words them several ways β€” not found, not infected, not tested, nothing found, no suspect files, plus started/finished status lines bracketing multi-part tests. Anything not on that list is reported rather than dropped, so a verdict this parser has not seen surfaces instead of hiding.

Running it in a container produces environment noise

Six of the seven warnings in the many_vuln fixture are chkdirs: WARNING: Skipping unsupported filesystem (overlayfs). That is chkrootkit telling you it could not check a directory, not a finding about the host, and it happens for every overlayfs mount β€” which means every Docker container. Expect it, and read a run inside a container accordingly.

Sample Scan Data

Sample chkrootkit files are available at unittests/scans/chkrootkit.

Generating an importable file

chkrootkit > chkrootkit.txt          # full output
chkrootkit -q > chkrootkit.txt       # problems only

chkrootkit must run as root, and it audits the machine it runs on. Individual tests can be named as arguments β€” chkrootkit lkm β€” which is how the narrower fixtures here were produced. Note that not every internal check is a valid argument: chkrootkit chkdirs reports not a known test.

The fixtures were produced with chkrootkit 0.58b on Debian 13:

FixtureFindings
chkrootkit_no_vuln.txt0 β€” chkrootkit basename
chkrootkit_one_vuln.txt1 β€” chkrootkit lkm, one failed check with seven explanations
chkrootkit_many_vuln.txt7 β€” chkrootkit -q, standalone warnings with no check lines

Default deduplication hashcode fields

title, cwe, line, file_path, description β€” the legacy default. With no file, line or check id, findings are distinguished by the check and verdict in the title and the explanations in the description.