ALIRT

ALIRT — Advanced Linux Incident Response Toolkit

Developed and maintained by madsys, coolq — v0.6.0

License: GPL v3

ALIRT (Advanced Linux incident response toolkit, formerly known as AIRT) is a Linux-based tool suit for incident response, specifically designed to detect kernel rootkit on the Linux box. Compared to other kernel-based malware detection systems, ALIRT occupies a unique position:

  1. No signatures required; complements signature-based tools (such as the rkhunter family);
  2. Unlike the “proactive, resident” approach of LKRG/Tracee, it focuses on post-incident response: even after an attacker has wiped logs and hidden modules, traces can still be detected when programs are launched from a trusted medium;
  3. Unlike Volatility’s offline image analysis, it performs real-time online inspection without requiring a system shutdown for forensics. It fully covers the “online but not pre-installed” gap in the “online-offline” spectrum.

Supports the following architectures:

It’s useful when you want to know what evil kernel backdoor is still resident on your broken system and what the hell it is. ALIRT consists of 5 useful tools:

Note: unlike signature-based scanners, ALIRT finds backdoors by their low-level structural traces in kernel memory — there is no signature database.

Table of contents

  1. What is ALIRT?
  2. Usage
  3. What platforms does it support now?
  4. Tested kernel versions
  5. Where can I get the latest version?
  6. How can I report a bug?
  7. Documentation
  8. License

What is ALIRT?

(See the introduction above.)

Usage

Unpack the sources, enter the top directory and just execute:

make

The modules are built into src/<tool>/ (e.g. src/mod_hunter/mod_hunter.ko). Dependencies: kernel headers for the target kernel (linux-headers / kernel-devel package), make, gcc. On Secure Boot / module-signature enforced systems, enroll a MOK and sign the modules before loading (dkms + mokutil on Debian/Ubuntu; sign-file from the kernel tree on RHEL-likes).

Cross-compiling for another platform

Pick the target platform with ARCH=; the build maps it to the kernel’s architecture and a default cross-toolchain prefix (override the prefix with CROSS_COMPILE= when your toolchain has a different name, and point KDIR= at the target kernel build tree when it is not the running one):

Platform ARCH= value Default cross prefix
x86_64 (native) x86_64 none
32-bit ARM (armv7) armv7 arm-linux-gnueabihf-
ARM64 (AArch64) aarch64 aarch64-linux-gnu-
MIPS (o32) mips mips-linux-gnu-
PowerPC (ppc64le) powerpc powerpc64le-linux-gnu-
RISC-V (rv64) riscv riscv64-linux-gnu-

Examples:

make ARCH=aarch64 CROSS_COMPILE=aarch64-linux-gnu- KDIR=/build/linux-6.12
make ARCH=armv7 CROSS_COMPILE=arm-linux-gnueabihf- KDIR=/build/linux-5.15
make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- KDIR=/build/linux-6.6 mod_hunter

Run make help for the full list. The arch-specific address-space helpers are selected automatically from the target kernel’s CONFIG_*, so the same source tree builds for every platform above.

mod_hunter

to check if there is hidden module in your system, just run:

$ sudo insmod src/mod_hunter/mod_hunter.ko && cat /proc/showmodules

Suspicious struct module candidates are reported with a verdict (CRITICAL / HIGH / MEDIUM / SUSPICIOUS) based on three data sources:

verdict    address              name            core_size  in_list  in_kset
CRITICAL   0xffffc90000012340   am_evil         16384      no       no
VISIBLE    0xffffc90000023480   pcnet32         34824      yes      yes

to inspect a suspect module in place, just try:

$ sudo echo "0xffffc90000012340" > /proc/showmodules

Note: the address is the one reported in the scan output. On kernels

= 4.0 this prints full details and recommends a manual dump (no automatic re-linking — recovery decisions belong to the analyst). On older kernels (<= 3.x) pass reveal=1 at insmod to optionally re-link the module for removal, at your own risk.

mod_hunter workflow diagram:

mod_hunter diagram

process_hunter

to check if there is hidden process in your system:

$ sudo insmod src/process_hunter/process_hunter.ko && cat /proc/showprocess

sock_hunter

to check if there is hidden port in your system:

$ sudo insmod src/sock_hunter/sock_hunter.ko && cat /proc/showsocks

modumper + dismod

to dump a module’s core image:

$ sudo insmod src/mod_dumper/modumper.ko mod_name=MODULE && cat /proc/get_mod

On kernels <= 5.9 this writes dump.dat & dump.info to the current directory; on kernels >= 5.10 (where kernel-space file writing is no longer possible) the dump is emitted through /proc/get_mod — convert it with src/mod_dumper/dump-extract.sh.

to disassemble the dump (supports x86, x86_64, arm, arm64, mips, powerpc, riscv — via the system binutils):

$ src/mod_dumper/dismod.sh dump.dat        # or: src/mod_dumper/dismod.pl

What platforms it support now?

Tested kernel versions

Every version below is verified by GitHub Actions CI on every push: all ALIRT tools are compiled against the exact kernel source and mod_hunter must detect a self-hiding sample module in a QEMU boot of that kernel.

Build + QEMU runtime detection (hidden-module test), per architecture:

Kernel x86_64 aarch64 armv7 mips (o32) powerpc (ppc64le) riscv (rv64)
3.10.108 ✅ – † ✅ – –
4.4.302 ✅ ✅ ✅ ✅ † –
4.19.325 ✅ ✅ ✅ ✅ ✅ ✅
5.4.290 ✅ ✅ ✅ ✅ ✅ ✅
5.10.271 ✅ ✅ ✅ ✅ ✅ ✅
5.15.180 ✅ ✅ ✅ ✅ ✅ ✅
6.1.189 ✅ ✅ ✅ ✅ ✅ ✅
6.6.158 ✅ ✅ ✅ ✅ ✅ ✅
6.12.35 (longterm) ✅ ✅ ✅ ✅ ✅ ✅
6.18.56 (longterm) ✅ ✅ ✅ ✅ ✅ ✅
7.2.10 ✅ ✅ ✅ ✅ ✅ ✅

† Declared CI limitations (not code failures): the 4.4.302/ppc64le and 3.10.108/armv7 QEMU guests never start under any era-matching TCG combination tried (six combinations each, evidence in the ci.yml comments and docs/ci-matrix-61-green-report); the same kernel trees pass on every other architecture, and powerpc 4.19+ / armv7 4.4+ are fully green. “–” = the architecture did not exist in mainline for that kernel generation (arm64 before 4.4, riscv before 4.19, no little-endian ppc64 in the 3.x series).

The live, always-current version of this table is the compatibility matrix in the latest CI run summary.

Where can I get the latest version?

How can I report a bug?

We are glad to receive any comments, bugs and suggestions — please mail to:

Documentation

License

This project is licensed under the GNU General Public License v3.0 — see the LICENSE file for details.

This site is open source. Improve this page.