chkrootkit Integration with DefectDojo

chkrootkit Integration with DefectDojo

chkrootkit is a long-standing open source tool, written by Nelson Murilo and Klaus Steding-Jessen, that checks a running Unix or Linux host for signs of known rootkits. It looks for system binaries that have been replaced, hidden processes and directories, loadable kernel module trojans, sniffer logs, and suspicious open ports. chkrootkit runs as root on the machine it audits and prints its results as plain text, which DefectDojo imports.

chkrootkit Integration with DefectDojo

We run chkrootkit on a schedule across our Linux fleet, and DefectDojo is how we keep its output from scrolling past unread. Each failed check or warning becomes a Finding on the Asset for that host, with INFECTED verdicts imported as High so they reach someone quickly. Because the parser understands both the full report and the quiet -q output, the cron job can stay terse without the import treating a problem report as clean. Reimporting each run shows us whether a warning is new or the same environment quirk we already reviewed.

Why chkrootkit Matters

A host that has been compromised at the root level can lie to the tools running on it, which is exactly why a dedicated rootkit checker is useful.

• chkrootkit checks for known rootkit signatures in system binaries and for anomalies such as hidden directories and processes.
• It needs no agent or service. A single command run as root produces a report, which makes it easy to add to an existing configuration management or cron setup.
• Its output is short and readable, which helps during incident response when someone needs a quick second opinion on a suspicious host.
• On its own, though, chkrootkit keeps no history. Without a place to store results, nobody can tell whether a warning appeared last night or has been there since the server was built.

Advantages of This Integration

• Both output shapes parsed. Full output pairs each check with a verdict, and chkrootkit -q prints only WARNING: lines. The parser attaches a WARNING: line to the failed check above it, and turns a standalone one into its own Finding, so a quiet report never imports as clean.
• Unknown verdicts surface. Clean verdicts are an explicit list (not found, not infected, nothing found, no suspect files, and similar). Anything not on that list becomes a Finding, so a verdict wording the parser hasn't seen is reported rather than dropped.
• Severity that separates real alarms. INFECTED becomes High, WARNING becomes Medium, and "Vulnerable but disabled" becomes Low, so SLAs and notifications can treat an infection differently from a warning.
• Per-host history. Reimporting each run into the host's Test mitigates warnings that cleared, adds new ones, and reactivates any that return.
• Triage tools. Known environment noise can be marked false positive or risk-accepted with a note, and real detections can be assigned and pushed to Jira for incident follow-up.

How This Integration Works

DefectDojo imports chkrootkit output with the chkrootkit Scan scan type.

1. Run chkrootkit as root and save the output.

chkrootkit > chkrootkit.txt
chkrootkit -q > chkrootkit.txt

The first command saves the full report, and the second saves problems only. chkrootkit audits the machine it runs on, so run it on each host you want covered. Individual tests can be named as arguments (for example chkrootkit lkm), though not every internal check is a valid argument.

2. Import the file. In the UI, open the host's Engagement, choose Import Scan Results, select chkrootkit Scan, and upload the text file. From a scheduled job, use the API in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=chkrootkit Scan" 
  -F "file=@chkrootkit.txt" 
  -F "product_name=web-tier" 
  -F "engagement_name=Host Integrity" 
  -F "test_title=web-01" 
  -F "auto_create_context=true"

DefectDojo Pro users can use Universal Importer:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "chkrootkit Scan" 
  --report-path "./chkrootkit.txt" 
  --product-name "web-tier" 
  --engagement-name "Host Integrity" 
  --auto-create-context

3. Reimport each run. Send later results for the same host to /api/v2/reimport-scan/ against that host's Test.

Data Granularity: What Gets Imported

With no file, line, or check ID, findings are told apart by the check and verdict in the title and the explanations in the description.

Use Cases

For scheduled fleet checks: A nightly cron job runs chkrootkit -q on each server and reimports into a Test named for the host. Most nights nothing changes. When a new warning appears, it shows up as a new Finding on that host instead of a line in a log nobody reads.

During incident response: A responder runs chkrootkit on a suspect machine and imports the result into the incident's Engagement. The Finding, its notes, and any follow-up work stay attached to the investigation record.

For server baselines: Running chkrootkit on newly built hosts and importing the result creates a starting point. Later runs are compared against it through reimport, so drift stands out.

For compliance evidence: Organizations that must show periodic integrity checks on servers can point auditors at the dated Tests in DefectDojo rather than collecting output files from each host.

Operational Tips

• Expect noise inside containers. Running chkrootkit in a Docker container produces chkdirs warnings about skipping the unsupported overlayfs filesystem. That is chkrootkit saying it couldn't check a directory, not a finding about the host. Mark it false positive with a note, or run chkrootkit on the host itself.
• Use one Test per host and set test_title to the hostname. Because Findings carry no host information, separate Tests are what keep results from different machines apart.
• Consider deduplication_on_engagement if you group many hosts in one Asset, since identical warnings on two hosts would otherwise be treated as duplicates within the Asset.
• Treat any INFECTED Finding as an incident, not a ticket. Set up DefectDojo notifications for these Assets so new Findings reach the host owners promptly.
• Keep the same mode, full or -q, for a given host. The two shapes produce different titles for the same problem, so switching modes creates new Findings.
• chkrootkit relies on the host's own binaries. For a host you believe is compromised, follow up with analysis from trusted media rather than relying on a single run.