Linux servers underpin critical infrastructure all over the world. But a stealthy class of malware – rootkits – threatens the availability and integrity of these systems in hard-to-detect ways. By embedding themselves deep in an operating system, rootkits can covertly spy, exfiltrate data, and maintain persistent access without authorized users even realizing they’ve been compromised.
This is where chkrootkit comes in. An open source rootkit detection tool purpose-built for Linux. Running chkrootkit scans can uncover the presence of active, dormant, or remnants of historical rootkits on a system. It functions by proactively checking key areas like running processes, loaded kernel modules, and system binaries for signs of tampering.
In this comprehensive guide, we’ll cover everything you need to know about leveraging chkrootkit for proactive rootkit detection and incident response on Linux systems:
- Rootkit essentials – how they infect systems and avoid detection
- Installing, configuring, and interpreting chkrootkit scans
- Taking automated rootkit scanning to the next level
- Maximizing early threat detection in cloud environments
- And much more about this indispensable open source tool for Linux security practitioners
Let’s start by understanding why rootkits warrant so much caution and attention…
What are Rootkits?
Rootkits are a dangerous form of advanced malware that enable an attacker to secretly take control of a system while remaining undetected for long periods of time. The name comes from their ability to gain “root” (administrator-level) access to target systems – including servers and endpoints – and conceal or “kit” malicious processes to keep operational.
Once a bad actor has managed to breach a Linux environment and grab an initial foothold, covertly deploying a rootkit is a common next step. The rootkit allows them to silently retain backdoor access, move laterally deeper into the network, or siphon sensitive data over lengthy time spans.
There are two common types of rootkits:
Kernel rootkits – Attackers hijack the core kernel the operating system depends on, meddling with the heart of a system. This can grant a bad actor sweeping control to hide files, processes, registry entires, network connections, and other native OS features from standard system tools and utilities. For example hiding a malware process so it doesn’t show in “ps” listings or an open network port from appearing in “netstat” output. Stealth capabilities are immense.
Bootloader or firmware rootkits – Harder to pull off successfully, bootloader rootkits infect earlier in the system startup process even before the kernel loads. This gives the power to tamper with disk partition information, Trojan early code execution environments, or corrupt system bootstrapping functions wholesale. By necessity, they often require some degree of physical access.
Once a rootkit takes hold, the consequences can be devastating from a cybersecurity standpoint:
- Eavesdrop on sensitive traffic and exfiltrate data over long durations
- Manipulate configurations, delete logs, or disable defenses to enable follow-on attacks
- Capture plaintext credentials, encryption keys, intellectual property worth millions
- Take realtime interactive control or pilfer compute resources for cryptomining or botnets
Rootkits are a universal threat across major operating environments like Windows, Linux, UNIX, and Mac devices. But their stealth capabilities prove uniquely powerful and dangerous on infrastructure like Linux servers and Unix-based network gear such as routers and switches. Disrupting core network functions can result in massive outages.
This underscores why advanced rootkit detection capabilities specifically tailored to Linux environments – namely solutions like chkrootkit are so necessary. By proactively scanning for signs of system tampering, chkrootkit aims to surface these threats before extensive harms occur or at minimum supply forensic evidence to remediate infections.
These all demonstrate why rootkits represent advanced, dangerous threats that cannot be taken lightly. Now let’s explore how they achieve these ends without easy detection…
How Rootkits Achieve Stealth and Concealment
The singular focus of any rootkit is avoiding detection by security tools and evading observation by administrators. These goals require circumventing standard system diagnostics and manipulation of native operating system behaviors.
Rootkits manage to “hide in plain sight” through an array of stealth techniques specifically oriented around masking their presence:
Hollow out legitimate system binaries — Rootkits frequently target native OS executables like ps
, ls
, netstat
, and replace the programs with a Trojaned version functional enough not to fully break, but surreptitiously filters out results showing the rootkit’s own files, processes, registry keys or network connections.
Tamper with kernel modules — The Linux kernel relies on loadable modules to extend functionality. By substituting compromised modules, rootkits can intercept system calls from applications and selectively return spoofed content instead of true query results when programs request hardware details, processes listings, network states and more.
Modify bootloaders — Crafty rootkits may even sometimes tamper with bootloader code preceding the OS kernel, engraving themselves at the very first code a machine executes upon startup. This grants extreme early manipulation power to distort disk partition tables, modify memory addresses, or inject hooking frameworks.
Leverage authentication hooks — Malicious DLLs or Linux shared libraries may tap into authentication flows to capture user credentials or tokens for lateral movement. Once a process loads a poisoned library, the rootkit has free reign to trigger backdoors, escalate privileges, or masquerade its activities.
Hide filesystem changes — Rootkits frequently manipulate programs like find
, filesystem drivers in the kernel, or directory listing functions to selectively omit unauthorized files, alternate data streams, device nodes, configuration changes, or other evidence of compromise from a defender’s view. The same binaries still technically “work” but truthfully reflect altered realities.
In aggregate, these deception techniques allow rootkits to stealthily control a system while allowing it to otherwise perform routine functions – crucial for avoiding raising red flags to users. Much rootkit innovation focuses on further minimizing discrepancies that could reveal something amiss underneath.
Ultimately defending against crafty adversaries wielding rootkits requires observing not just the conventional surfaces, but searching for subtle oddities in environments presumed to furnish ground truth about their own states and behaviors. When the operating system itself lies or has its eyes deceived, only specialized scanners expressly designed to spot suspiciously obscured anomalies stand a chance at unveiling deeper realities.
So how does chkrootkit stack up to the challenge?
Chkrootkit – A Specialized Scanner for Rootkit Detection on Linux Systems
Chkrootkit is an open source security tool created specifically for detecting rootkits and collecting forensic evidence to assist with removal on Linux systems.
Authored and maintained primarily by security researcher Nelson Murilo with support from the open source community, chkrootkit delivers system administrators and incident responders a customized scanner to inspect for signs of Linux rootkit infections. It debuted in 200X and continues under active development with regular version releases introducing additional detection checks and remediation capabilities.
So what core capabilities set chkrootkit apart for rootkit scanning?
File integrity checking — At its foundation, chkrootkit cross-references file signatures of key system binaries and libraries against known trusted checksums to check for illegitimate modifications. If core commands like ps
, ls
, lsof
, find
, or netstat
were trojaned by a rootkit to filter outputs and hide information, hash mismatches signal alerts for further investigation.
Anomaly detection: Chkrootkit scans memory and mounted filesystems for hidden or obscured processes/files that don’t show up in standard system enumeration tools due to rootkit manipulation. Strings output mismatches and suspicious timestamps also hint at camouflaged items.
Live forensics: As a local on-system scanner, chkrootkit can directly inspect raw /proc entries, kernel modules, network activity in real-time and other artifacts beyond reach of external network analysis tools. This equips chkrootkit to spot additional traces of advanced rootkits actively executing their concealment tricks.
Remediation capabilities: Unique from some competitors, chkrootkit offers administrators abilities to automatically restore trojaned system binaries like SSH tools back to their original uncompromised state by fetching clean versions from verified OS media. This aids recovery efforts by undoing changes made by an attacker.
Together these facilities allow chkrootkit to counter many common rootkit stealth maneuvers seen in modern Linux malware campaigns and significantly raise adversaries’ detection risk when attempting to establish persistence.
Of course no single defensive tool alone proves foolproof against the most motivated and sophisticated attackers armed with 0-day techniques. But judiciously tapping chkrootkit’s capabilities where appropriate as part a multi-layered defense-in-depth strategy offers Linux environments a much improved security posture against these highly-stealthy threats.
Now let’s look at how you actually obtain and run chkrootkit in your own infrastructure…
Obtaining and Installing Chkrootkit
Chkrootkit can be easily installed on enterprise Linux distributions via conventional package managers or building from source. We’ll cover both approaches:
Official Download Pages
- Primary site – https://www.chkrootkit.org
- Mirror site – https://pkg.org/dist/chkrootkit/
The sites furnish tarballs containing the latest chkrootkit version for manual builds. But package manager installs are recommended for easier updates.
Linux Distribution Packages
For Red Hat based distros like RHEL, CentOS, Fedora, and Oracle Linux, chkrootkit is included in the EPEL (Extra Packages for Enterprise Linux) repository:
yum install chkrootkit
On Debian/Ubuntu systems, fetch it from main package repos:
apt install chkrootkit
openSUSE, Mageia, and other RPM distros also include chkrootkit:
zypper in chkrootkit
Distribution-specific packages offer automated updates when new chkrootkit versions emerge. Next we’ll cover compiling yourself from source…
Builds from Source
If your Linux distribution lacks a dedicated chkrootkit package, building from source is straightforward:
Dependencies
- gcc
- make
- OpenSSL development libraries
Steps
- Download latest chkrootkit tarball
- Extract contents
cd
into extracted folder- Run
make sense
to configure embellishment - Run
make all
to compile binaries - Run
make install
copying binaries to system executable paths
Repeat when new releases come out.
Now let’s walk through installation processes on specific distributions…
Linux Installation Instructions
Here are step-by-step examples for obtaining, installing, and confirming chkrootkit versions commonly used Linux distributions:
Debian
- Add Debian repo:
echo "deb http://http.debian.net/debian bullseye main contrib non-free" >> /etc/apt/sources.list
- Update repos:
apt update
- Install chkrootkit package:
apt install chkrootkit -y
- Verify install:
chkrootkit -V
Red Hat / CentOS
- Enable EPEL repository:
yum install epel-release
- Install chkrootkit package:
yum install chkrootkit
- Verify install:
chkrootkit -V
Fedora
- Install chkrootkit package:
dnf install chkrootkit
- Verify install:
chkrootkit -V
openSUSE
- Refresh repositories:
zypper refresh
- Install chkrootkit package:
zypper in chkrootkit
- Verify install:
chkrootkit -V
And so on for other Linux distributions…
The examples demonstrate obtaining chkrootkit through conventional package managers. You should now understand installation methods on any modern Linux environment.
Now we’ll explore utilizing chkrootkit capabilities through execution options…
Configuring Chkrootkit Scanning Through Execution Options
Chkrootkit offers administrators extensive flexibility to customize rootkit scanning patterns through available command options. Tuning these parameters appropriately allows tailoring checks to balance detection breadth, output detail, performance impact, and other factors per use case needs.
Let’s breakdown key capabilities exposed for administrators to leverage:
Top-level binaries
chkrootkit – Primary binary used to initiate broad rootkit scanning permeating different detection checks.
chrootkit – Alternate binary specifically focused on assessing tampering of the chroot() system call often abused by attackers.
Scan modes
-r – Rootkit detection mode enabling checks specifically hunting for rootkit footprints. This includes the classic tests like hidden processes, suspicious file timestamps, strings output mismatches and similar attributes.
-x – Extra detection mode expanding deeper across the system for additional rootkit traces. Checks here include scanning loaded kernel modules for signs of persistence, validating wider file integrity ranges, and searching the registry on some Linux variants.
-a – Enable ALL tests in chkrootkit’s arsenal for maximum scrutiny, from lightweight to very extensive. The kitchen sink approach when doing incident response or if you really want to stress test system integrity.
Output formats
-c – Output scan results to CSV format instead of regular stdout. Machine readable for feeding into parsing scripts.
-s – Silent mode returns no stdout output, for instances where you only care about the error code.
-q – Quiet mode limiting verbosity to support piping a minimal condensed output stream into logs or other commands.
Troubleshooting
-d – Debug mode logs extensive detail and forensic artifacts to help diagnose scan failures or error conditions.
Custom filtering
-n – Disables checks associated with NFS to avoid false positives for namespace collisions.
Remediation
-F – Restore original clean system binaries from verified OS media if tampered copies are detected. This allows “resetting” infected tools like SSH.
As we can see, chkrootkit offers versatile parameters to fine tune scans. Some common usage patterns include:
# Broad rootkit scan
chkrootkit -rx
# Cron scanning
chkrootkit -rq > chklog.txt
# Forensics check
chkrootkit -rad > incident.log
# Script usage prepping CSV
output=$(chkrootkit -qc)
echo $output >> log.csv
Adjust options per use case patterns like routine scanning, focused incident response, scripted automation, etc. This ensures efficiency while still balancing visibility.
Now that we understand command options, let’s explore what chkrootkit specifically searches for…
Understanding Chkrootkit Checks and Tests
Chkrootkit conducts a multitude of targeted tests to search for hints of rootkits or anomalies that warrant further investigation. Understanding exactly what these entail helps administrators interpret scan results and evaluate risks.
Default testing focuses on key locations where rootkits hide, including:
Processes
- Verify running processes against /proc entries
- Check connections against open sockets
- Confirm process binaries map to disk executables
Filesystem
- Search filesystem for hidden files
- Validate timestamp tampering on binaries
- Confirm hosts.txt and aliases matchDNS records
- Hash check suspicious files, configs, logs
Functions
- Check raw disk access capabilities
- Scan export functions for signs of sniffers
- Test connection hiding via socket mismatches
This covers typical rootkit tricks like process hiding, file masquerading, and function hooking.
The extra rootkit detection enabled by -x
looks deeper:
- Scan loaded kernel modules, symbol tables, LKMs for hidden execution flows
- Verify integrity of network binaries and libraries
- Hunt hidden registry keys, DLLs, and authentication hooks
And ALL test mode with -a
expands scans even further across the system.
Output presents scan findings like:
chkrootkit output
==================
Checking `amd'... not infected
Checking `basename'... not infected
Checking `biff'... not infected
Checking `chfn'... not infected
Checking `chsh'... not infected
Checking `cron'... not infected
Checking `date'... not infected
Checking `du'... INFECTED
Checking `dirname'... INFECTED
Checking `echo'... not infected
...
In this sample, du
and dirname
returned alarms warranting investigation. Detailed logging via -l
would contain additional forensic artifacts on mismatches.
Now that you understand chkrootkit checks, let’s examine output…
Interpreting Chkrootkit Output
Understanding how to interpret chkrootkit output is critical for evaluating potential threats when anomalies surface:
Anomalies point to tampering by a rootkit but don’t confirm maliciousness since occasional false positives do occur
- Unexpected INFECTION status on file
- Timestamp differences on binaries
- Missing processes or open ports
- Kernel module mismatches
Diagnosing anomalies involves:
- First re-run scan multiple times to weed out intermittent issues
- Check scan logs details on afffected files, symbols etc
- Dig deeper into anomalies:
- Analyze binary hashes manually
- Compare process lists with other commands
- Check other systems for similarities
Truly infected systems exhibit multiple anomalies – outliers limited to single checks may be false positives. But still investigate.
Sample infected output:
Checking `bindshell'... INFECTED
Checking `lkm'... INFECTED
Checking `rexedcs'... INFECTED
Checking `sniffer'... INFECTED
Checking `w55808'... INFECTED
Checking `wted'... INFECTED
Here the sheer volume of detections indicates a high likelihood of an actual rootkit present.
Isolate the system and gather further evidence fromchkrootkit logs and forensic investigation. Let’s discuss analyzing logs next…
Auditing chkrootkit Logs
Chkrootkit can output detailed logs using the -l
switch. These provide administrators and incident responders added data points when assessing anomalies or troubleshooting issues.
Logging Contents
Full logs chronicle the following:
- Date/time of scan execution
- Parameter options
- Name of each test performed
- Output of tests
- Any error messages
- Final warning counts
Structured logging enables easier parsing.
Gathering Logs
Logs get stored in /var/log/chkrootkit.log
by default with logrotate managing sizes.
Centralize into syslog or security monitoring tools for analysis.
Inspecting Logs
Evaluating logs aids rootcause analysis on several fronts:
- Timestamps on multiple INFECTED events may indicate initial intrusion
- Performance issues causing deadchild crashes
- Authentication errors accessing system areas
Logs provide added insight before reimaging if infection confirmed.
Now that chkrootkit output and logging are demystified, how does it stack up versus competitors? Let’s compare…
How Chkrootkit Compares to Other Rootkit Detection Tools
While chkrootkit offers robust capabilities for Linux rootkit detection, other open source and commercial options exist as well. How does it stack up?
rkhunter – Lightweight scanner focused primarily on file integrity monitoring. Useful for quick second opinion checks but lacks full function interrogation.
Maldet – Linux malware scanner with additional heuristic protections. Doesn’t specialize specifically for rootkits so can miss more stealthy threats.
Rootkit Hunter – Dedicated Linux scanner but no longer under active development. User base is moving toward chkrootkit.
OSSEC – Feature-packed host intrusion detection agent offering some rootkit detection as a secondary function. Jack of all trades but not laser focused on rootkits.
Only chkrootkit offers:
- Broad command line flexibility
- Scriptability for automation
- Active maintenance and signature updates for evolving threats
- Chroot and chrootkit detection focus
For optimal security on Linux servers, we recommend utilizing chkrootkit alongside antivirus, file integrity monitoring, and intrusion detection systems for defense in depth:
- ClamAV or similar for malware scanning
- Tripwire for filesystem monitoring
- OSSEC for anomaly detection
Integrated together, these layers mutually reinforce robust protection.
Now let’s look at…
Automating Chkrootkit Scans
While chkrootkit serves indispensibly for on-demand rootkit searches, the tool truly shines when incorporated into automated scanning for continuous monitoring.
Cron Jobs
Scheduler cron tasks on regular intervals to trigger scans, such as:
*/2 * * * * /usr/bin/chkrootkit >> /var/log/chkrootkit.log
Adjust frequency balancing performance impact vs detection timeliness.
Monitoring Integration
Output chkrootkit results into monitoring stacks like Splunk, ELK, and Security Onion for consolidated event streams with other security tooling:

Alerting
Set up notifications to security teams when new anomalies emerge:
- SMS
- Slack
- PagerDuty
Automate response and escalation workflows.
Orchestration
Embed chkrootkit into broader server hardening playbooks alongside patching, firewall rules, user access controls and more.
Now let’s examine administering and evolving chkrootkit over time.
Managing and Updating Chkrootkit
Like other software, chkrootkit requires ongoing management for feature improvements and adapting to new attack developments:
** Patching** – Install updated packages from your Linux distro as new chkrootkit versions release to enrich detection capabilities.
Signature Updates – Updates improve recognition of latest rootkit species in the wild targeting Linux systems.
Version Monitoring – Track threads on latest bypass techniques observed so you know which upgrade addresses the maneuvers.
** Regression Testing** – Verify scan continuity and no new false positives introduced after updates.
** Tuning** – Customize checks specific to your environment by editing /etc/chkrootkit.conf file and /usr/share/chkrootkit signatures.
** Mailing Lists** – Join chkrootkit-users forum to discuss issues and get community support.
Together these practices ensure you maximize value from chkrootkit while closely tracking the evolving threat landscape over time.
Now let’s examine how cloud and container platforms change the game.
Adapting Chkrootkit to Cloud and Container Servers
As Linux workloads shift from bare metal and virtualized servers toward cloud infrastructure and container hosting, changes arise in securing these environments against rootkits:
IaaS Cloud Instances – Scan privileges cloud hosts differently given multi-tenant isolation protections differ. Adapt security groups, network ACLs and instance profiles accordingly.
Container Scanning – Integrate chkrootkit into Docker and Kubernetes operations by tailoring for read-only volumes, ephemeral storage, and automated rebuilding of compromised containers.
Compensating Cloud Controls – Cloud providers offer alternate detection capabilities:
- AWS Inspector for intrusion detection
- Azure Security Center threat monitoring
- GCP OS Login brute force protection
Adjust for these native services rather than solely chkrootkit scanning for observations.
Despite architectural shifts to cloud native infrastructure, diligent chkrootkit security hygiene remains crucial as foundational protection against stealthy Linux threats.
Now let’s tackle troubleshooting operational issues.
Troubleshooting Chkrootkit Issues
Like all software utilities, administrators may encounter issues running or relying on chkrootkit for Linux protection:
Scan failures – If tests abort prematurely, enable debug mode and verify scan binary permissions allow accessing test files and directories.
False positives – Whitelist benign processes occasionally flagged incorrectly as hidden or suspicious. Fine tune policy customization.
Bug reporting – Capture debug logs and precise replica steps to submit issues to chkrootkit developers for investigation.
Error messages – Consult online documentation at https://www.chkrootkit.org for resolutions to common errors like missing dependency libraries.
Stuck child processes – Kill stalled background processes such as chkutmp
then run make clean
before recompiling chkrootkit again.
Tampered binary resets – Leverage chkrootkit -F
capability to restore infected binaries like SSH back to their original uncompromised states from installation media.
Community support – Join chkrootkit-users mailing list to search historical threads or discuss problems with knowledgable moderators and user base.
Armed with these troubleshooting techniques, admins can achieve resilient operations.
Now let’s wrap up with some closing thoughts…
Conclusion and Final Thoughts
We’ve covered extensive ground examining chkrootkit for combating Linux rootkits – perhaps the most stealthy class of threats facing mission critical environments:
- Fundamentals of how rootkits persist and avoid detection
- Installing and configuring chkrootkit for customized scanning
- Deciphering output to pinpoint IOCs vs false positives
- Autoscaling scans through automation and integrations
- Maintaining sustained effectiveness through updates and community collaboration
While no single tool can protect against advanced adversaries alone, every Linux administrator should have chkrootkit in their toolbox for regularly verifying control system integrity at both the host and network levels.
Coupled with rigorous security best practices like least privilege, encryption, monitoring, tapping chkrootkit for proactive rootkit searches arms defenders with vital capabilities against sophisticated threats before damage and destruction occurs unimpeded.