Linux Forensics
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Initial Information Gathering
Basic Information
First of all, it's recommended to have some USB with good known binaries and libraries on it (you can just get ubuntu and copy the folders /bin, /sbin, /lib, and /lib64), then mount the USB, and modify the env variables to use those binaries:
Once you have configured the system to use good and known binaries you can start extracting some basic information:
Suspicious information
While obtaining the basic information you should check for weird things like:
Root processes usually run with low PIDS, so if you find a root process with a big PID you may suspect
Check registered logins of users without a shell inside
/etc/passwdCheck for password hashes inside
/etc/shadowfor users without a shell
Memory Dump
To obtain the memory of the running system, it's recommended to use LiME. To compile it, you need to use the same kernel that the victim machine is using.
Remember that you cannot install LiME or any other thing in the victim machine as it will make several changes to it
So, if you have an identical version of Ubuntu you can use apt-get install lime-forensics-dkms
In other cases, you need to download LiME from github and compile it with correct kernel headers. To obtain the exact kernel headers of the victim machine, you can just copy the directory /lib/modules/<kernel version> to your machine, and then compile LiME using them:
LiME supports 3 formats:
Raw (every segment concatenated together)
Padded (same as raw, but with zeroes in right bits)
Lime (recommended format with metadata
LiME can also be used to send the dump via network instead of storing it on the system using something like: path=tcp:4444
Disk Imaging
Shutting down
First of all, you will need to shut down the system. This isn't always an option as some times system will be a production server that the company cannot afford to shut down.
There are 2 ways of shutting down the system, a normal shutdown and a "plug the plug" shutdown. The first one will allow the processes to terminate as usual and the filesystem to be synchronized, but it will also allow the possible malware to destroy evidence. The "pull the plug" approach may carry some information loss (not much of the info is going to be lost as we already took an image of the memory ) and the malware won't have any opportunity to do anything about it. Therefore, if you suspect that there may be a malware, just execute the sync command on the system and pull the plug.
Taking an image of the disk
It's important to note that before connecting your computer to anything related to the case, you need to be sure that it's going to be mounted as read only to avoid modifying any information.
Disk Image pre-analysis
Imaging a disk image with no more data.
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Search for known Malware
Modified System Files
Linux offers tools for ensuring the integrity of system components, crucial for spotting potentially problematic files.
RedHat-based systems: Use
rpm -Vafor a comprehensive check.Debian-based systems:
dpkg --verifyfor initial verification, followed bydebsums | grep -v "OK$"(after installingdebsumswithapt-get install debsums) to identify any issues.
Malware/Rootkit Detectors
Read the following page to learn about tools that can be useful to find malware:
pageMalware AnalysisSearch installed programs
To effectively search for installed programs on both Debian and RedHat systems, consider leveraging system logs and databases alongside manual checks in common directories.
For Debian, inspect
/var/lib/dpkg/statusand/var/log/dpkg.logto fetch details about package installations, usinggrepto filter for specific information.RedHat users can query the RPM database with
rpm -qa --root=/mntpath/var/lib/rpmto list installed packages.
To uncover software installed manually or outside of these package managers, explore directories like /usr/local, /opt, /usr/sbin, /usr/bin, /bin, and /sbin. Combine directory listings with system-specific commands to identify executables not associated with known packages, enhancing your search for all installed programs.
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Recover Deleted Running Binaries
Imagine a process that was executed from /tmp/exec and then deleted. It's possible to extract it
Inspect Autostart locations
Scheduled Tasks
Services
Paths where a malware could be installed as a service:
/etc/inittab: Calls initialization scripts like rc.sysinit, directing further to startup scripts.
/etc/rc.d/ and /etc/rc.boot/: Contain scripts for service startup, the latter being found in older Linux versions.
/etc/init.d/: Used in certain Linux versions like Debian for storing startup scripts.
Services may also be activated via /etc/inetd.conf or /etc/xinetd/, depending on the Linux variant.
/etc/systemd/system: A directory for system and service manager scripts.
/etc/systemd/system/multi-user.target.wants/: Contains links to services that should be started in a multi-user runlevel.
/usr/local/etc/rc.d/: For custom or third-party services.
~/.config/autostart/: For user-specific automatic startup applications, which can be a hiding spot for user-targeted malware.
/lib/systemd/system/: System-wide default unit files provided by installed packages.
Kernel Modules
Linux kernel modules, often utilized by malware as rootkit components, are loaded at system boot. The directories and files critical for these modules include:
/lib/modules/$(uname -r): Holds modules for the running kernel version.
/etc/modprobe.d: Contains configuration files to control module loading.
/etc/modprobe and /etc/modprobe.conf: Files for global module settings.
Other Autostart Locations
Linux employs various files for automatically executing programs upon user login, potentially harboring malware:
/etc/profile.d/*, /etc/profile, and /etc/bash.bashrc: Executed for any user login.
~/.bashrc, ~/.bash_profile, ~/.profile, and ~/.config/autostart: User-specific files that run upon their login.
/etc/rc.local: Runs after all system services have started, marking the end of the transition to a multiuser environment.
Examine Logs
Linux systems track user activities and system events through various log files. These logs are pivotal for identifying unauthorized access, malware infections, and other security incidents. Key log files include:
/var/log/syslog (Debian) or /var/log/messages (RedHat): Capture system-wide messages and activities.
/var/log/auth.log (Debian) or /var/log/secure (RedHat): Record authentication attempts, successful and failed logins.
Use
grep -iE "session opened for|accepted password|new session|not in sudoers" /var/log/auth.logto filter relevant authentication events.
/var/log/boot.log: Contains system startup messages.
/var/log/maillog or /var/log/mail.log: Logs email server activities, useful for tracking email-related services.
/var/log/kern.log: Stores kernel messages, including errors and warnings.
/var/log/dmesg: Holds device driver messages.
/var/log/faillog: Records failed login attempts, aiding in security breach investigations.
/var/log/cron: Logs cron job executions.
/var/log/daemon.log: Tracks background service activities.
/var/log/btmp: Documents failed login attempts.
/var/log/httpd/: Contains Apache HTTPD error and access logs.
/var/log/mysqld.log or /var/log/mysql.log: Logs MySQL database activities.
/var/log/xferlog: Records FTP file transfers.
/var/log/: Always check for unexpected logs here.
Linux system logs and audit subsystems may be disabled or deleted in an intrusion or malware incident. Because logs on Linux systems generally contain some of the most useful information about malicious activities, intruders routinely delete them. Therefore, when examining available log files, it is important to look for gaps or out of order entries that might be an indication of deletion or tampering.
Linux maintains a command history for each user, stored in:
~/.bash_history
~/.zsh_history
~/.zsh_sessions/*
~/.python_history
~/.*_history
Moreover, the last -Faiwx command provides a list of user logins. Check it for unknown or unexpected logins.
Check files that can grant extra rprivileges:
Review
/etc/sudoersfor unanticipated user privileges that may have been granted.Review
/etc/sudoers.d/for unanticipated user privileges that may have been granted.Examine
/etc/groupsto identify any unusual group memberships or permissions.Examine
/etc/passwdto identify any unusual group memberships or permissions.
Some apps alse generates its own logs:
SSH: Examine ~/.ssh/authorized_keys and ~/.ssh/known_hosts for unauthorized remote connections.
Gnome Desktop: Look into ~/.recently-used.xbel for recently accessed files via Gnome applications.
Firefox/Chrome: Check browser history and downloads in ~/.mozilla/firefox or ~/.config/google-chrome for suspicious activities.
VIM: Review ~/.viminfo for usage details, such as accessed file paths and search history.
Open Office: Check for recent document access that may indicate compromised files.
FTP/SFTP: Review logs in ~/.ftp_history or ~/.sftp_history for file transfers that might be unauthorized.
MySQL: Investigate ~/.mysql_history for executed MySQL queries, potentially revealing unauthorized database activities.
Less: Analyze ~/.lesshst for usage history, including viewed files and commands executed.
Git: Examine ~/.gitconfig and project .git/logs for changes to repositories.
USB Logs
usbrip is a small piece of software written in pure Python 3 which parses Linux log files (/var/log/syslog* or /var/log/messages* depending on the distro) for constructing USB event history tables.
It is interesting to know all the USBs that have been used and it will be more useful if you have an authorized list of USBs to find "violation events" (the use of USBs that aren't inside that list).
Installation
Examples
More examples and info inside the github: https://github.com/snovvcrash/usbrip
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Review User Accounts and Logon Activities
Examine the /etc/passwd, /etc/shadow and security logs for unusual names or accounts created and or used in close proximity to known unauthorized events. Also, check possible sudo brute-force attacks. Moreover, check files like /etc/sudoers and /etc/groups for unexpected privileges given to users. Finally, look for accounts with no passwords or easily guessed passwords.
Examine File System
Analyzing File System Structures in Malware Investigation
When investigating malware incidents, the structure of the file system is a crucial source of information, revealing both the sequence of events and the malware's content. However, malware authors are developing techniques to hinder this analysis, such as modifying file timestamps or avoiding the file system for data storage.
To counter these anti-forensic methods, it's essential to:
Conduct a thorough timeline analysis using tools like Autopsy for visualizing event timelines or Sleuth Kit's
mactimefor detailed timeline data.Investigate unexpected scripts in the system's $PATH, which might include shell or PHP scripts used by attackers.
Examine
/devfor atypical files, as it traditionally contains special files, but may house malware-related files.Search for hidden files or directories with names like ".. " (dot dot space) or "..^G" (dot dot control-G), which could conceal malicious content.
Identify setuid root files using the command:
find / -user root -perm -04000 -printThis finds files with elevated permissions, which could be abused by attackers.Review deletion timestamps in inode tables to spot mass file deletions, possibly indicating the presence of rootkits or trojans.
Inspect consecutive inodes for nearby malicious files after identifying one, as they may have been placed together.
Check common binary directories (/bin, /sbin) for recently modified files, as these could be altered by malware.
Note that an attacker can modify the time to make files appear legitimate, but he cannot modify the inode. If you find that a file indicates that it was created and modified at the same time as the rest of the files in the same folder, but the inode is unexpectedly bigger, then the timestamps of that file were modified.
Compare files of different filesystem versions
Filesystem Version Comparison Summary
To compare filesystem versions and pinpoint changes, we use simplified git diff commands:
To find new files, compare two directories:
For modified content, list changes while ignoring specific lines:
To detect deleted files:
Filter options (
--diff-filter) help narrow down to specific changes like added (A), deleted (D), or modified (M) files.A: Added filesC: Copied filesD: Deleted filesM: Modified filesR: Renamed filesT: Type changes (e.g., file to symlink)U: Unmerged filesX: Unknown filesB: Broken files
References
Book: Malware Forensics Field Guide for Linux Systems: Digital Forensics Field Guides
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Last updated
