Artifact Analysis: Linux Package Managers (APT, DPKG, RPM, DNF)

Note

Executive Summary: Package managers (APT/DPKG on Debian systems, DNF/RPM on RHEL systems) are the native utilities used to install, update, and remove software on Linux. For DFIR analysts, these utilities serve a critical dual purpose during post-mortem investigations. First, their historical logs reveal exactly what tools a threat actor may have installed to facilitate lateral movement or data exfiltration. Second, their cryptographic databases act as a built-in File Integrity Monitoring (FIM) system, allowing analysts to rapidly detect “trojaned” system binaries modified by user-land rootkits.

1. Tracing the Timeline: Package Manager Logs

When threat actors compromise a server, they often lack the specific tools needed for their objectives (e.g., port scanners, compilation tools, or reverse shell utilities). They frequently rely on the system’s native package manager to download these dependencies, leaving a permanent historical record.

Assuming the compromised forensic image is mounted at /mnt/analysis/, analysts must target the following log files based on the OS family.

A. Debian / Ubuntu Family (APT & DPKG)

• /var/log/apt/history.log: This is the most analyst-friendly log. It records the exact high-level command executed by the user (e.g., apt install netcat), the requested packages, and the start/end timestamps.
• /var/log/dpkg.log: Highly verbose. It tracks the low-level unpacking and configuration of every single file. It is invaluable for granular timeline reconstruction when correlating with file system MAC times.

B. RHEL / CentOS / Fedora Family (DNF & RPM)

• /var/log/dnf.log (or yum.log on older systems): The primary historical record. It lists all packages installed, updated, or erased with precise timestamps.
• The DNF Transaction Database: On a live system (or via chroot), the dnf history command provides a powerful overview of past transactions, including the ability to see reverted (“Undo”) actions that attackers might use to clean up their dropped packages.

2. Rootkit Detection: Cryptographic Integrity Verification

Beyond logging, package managers maintain a local database containing the cryptographic hashes, file sizes, and permissions of every file they install. DFIR analysts can weaponize this database to detect Trojanized Binaries (e.g., an attacker replacing /usr/sbin/sshd or /bin/ls with a malicious, backdoored version).

RPM Integrity (RHEL/CentOS)

verify_rpm_offline.sh

# RPM natively supports offline analysis via the --root flag.
# -V stands for Verify, -a stands for All installed packages.
rpm --root /mnt/analysis -Va

Decoding the Output: RPM returns an 8-character string for any file that deviates from its baseline.

• S: Size differs
• 5: MD5 hash differs (The most critical indicator)
• M: Mode (permissions) differs
• T: Modification Time differs
• U / G: User or Group ownership differs

Red Flag Example: S.5....T. /usr/sbin/sshd indicates the size, hash, and timestamp of the SSH daemon have changed. It is highly probable the binary has been backdoored.

DPKG Integrity (Debian/Ubuntu)

verify_dpkg_chroot.sh

# DPKG requires a chroot environment to verify an offline mounted image properly.
# Mount necessary pseudo-filesystems first (bind /dev, /proc, /sys)
chroot /mnt/analysis /bin/bash -c "dpkg -V"

Decoding the Output: If the command returns no output, all files are intact. If it returns 5?? /bin/ps, it indicates an MD5 mismatch. The process listing utility (ps) has likely been modified by a user-land rootkit to hide malicious PIDs.

3. DFIR Hunting Strategies

When analyzing package manager artifacts, analysts should focus on three primary hunting hypotheses:

1. Hunting for “Compile-on-Site” Capability: If the logs reveal the installation of compilation toolchains (gcc, make, kernel-headers), it is a massive red flag. Attackers install these packages to compile custom local privilege escalation (LPE) exploits directly on the victim machine to bypass kernel version mismatches.
2. Hunting for Dual-Use Network Tools: Query the logs for the installation of tools like nmap, netcat, socat, tcpdump, wireshark, python3-pip, or whois. If these tools are not part of the standard corporate “gold image” build, they were likely installed by the adversary to facilitate lateral movement and reconnaissance.
3. Temporal Isolation (The Incident Window): Legitimate system patching usually involves updating dozens or hundreds of packages simultaneously. An isolated entry showing the installation of a single package (e.g., screen or rsync) at 03:00 AM on the day of the suspected intrusion is highly anomalous and requires immediate investigation.

---

References & Further Reading

• SANS Institute: Linux Forensic Analysis
• Red Hat Documentation: Verifying Packages with RPM
• Related Artifact: Linux Account & Privilege Analysis
• Related Artifact: Linux Legacy Persistence (init.d)