Over the years we’ve gradually added support for different platforms that people are most often investigating. Our roots started with Internet artifacts, then moved to Windows systems and chat apps, gradually adding Android and iOS on mobile, then Mac support with 3.0. Now we’ve expanded that support to include several Linux distributions as well with the 5.0 versions of Magnet AXIOM and Magnet AXIOM Cyber.
As part of our initial support of Linux artifacts, we’ve focused on some of the foundational OS artifacts that will help move your investigations along; here’s the list of Linux artifacts supported in 5.0:
- Bash History
- Network Interfaces
- OS Information
- Recent Files
- Scheduled Tasks
- SSH Activity
- Startup Items
- System Logs
- User Accounts
For this blog, we wanted to spotlight six of the newly support Linux artifacts and expand a little bit on why they’re forensically relevant and how they may be helpful for you.
1. User Accounts
One of the first places to look in any investigation is the users and accounts that have logged in or used a system. We’ve added a user accounts artifact to pull data from the /etc/passwd and /etc/shadow to quickly identify any user accounts or service accounts on the local machine.
You’ll get common details such as username, ID, group ID, home directory, password last change date/time, hash, etc…
2. SSH Keys, SSH Known Hosts, SSH Authorized Keys
Linux systems are used to host services quite often and access to these servers are typically done via SSH so building out SSH activity can be essential for any Linux investigation.
We now have three new artifacts to help identify SSH activity on a system for Linux, but it will also work for Windows and Mac systems as well because they are structured very similarly across operating systems. AXIOM and AXIOM Cyber will now:
- Identify any public and/or private keys found on the system,
- identify any users have connected to the system using SSH keys if you’re investigating the SSH server itself (public keys will get stored in the authorized_keys file), or
- any systems the local user might have connected to if an entry was made in the local known_hosts file
3. Scheduled Tasks
Knowing what tasks and services being run can be quite valuable in many investigations and even more importantly for incident response or intrusion cases where malware will often use scheduled tasks or cron jobs to maintain persistence on a system.
AXIOM and AXIOM Cyber have Scheduled Tasks artifacts for both Windows and Mac and it made sense to build them out for Linux as well. With version 5.0 you’ll see two new artifacts for cron and anacron schedules. Both artifacts will report scheduled tasks, the difference being that cron jobs run with the expectation that the system is always on (ex. Run this command every night at midnight), if a system is off when the cron job is set to run, it just won’t run on restart, it missed the opportunity. Anacron is meant to recognize those situations and set their schedule a little differently (ex. Run the job after next reboot) both places have value in investigations and that’s why we call out both.
Another thing that can be quite annoying is reading the data in the crontab files and trying to understand the actual schedule that is set for a given job. See screenshot below.
While the numbering system is well known for those who are used to using Linux systems, it can be challenging for people who are less familiar. AXIOM and AXIOM Cyber will parse out that schedule and provide you with a more user-friendly schedule to understand when a job is going to run.
4. System Logs
The center to any good investigation around the activity on a system centers around the logs available. Event logs with Windows, unified logs with Mac, and syslog for Linux. There are a lot of log files for a given system and almost every application generates logs in Linux, but most investigations start with the syslog.
The syslog can get noisy on a busy system but the benefit to pulling it into AXIOM or AXIOM Cyber is that the data gets broken out into different columns and gets indexed so searching for anything is very fast. While there is a timestamp for each log entry, unfortunately they’re stored in local time, so you’ll need to take that into account when conducting your investigation.
Most examiners are quite familiar with the value data found in the trash or recycle bin artifacts. Files the user deletes but may forget to completely remove from the system can have value to many investigation types. Luckily, the Linux trash artifact is very similar to what can be found in the Mac trash and for the most part we’re looking for two sources of data, the file itself and any metadata associated to it.
Find both the original file and any metadata associated to it (such as deletion date, etc…) but occasionally one of the two sources are missing, and you’ll be left with partial results.
6. Bash History
Bash history can be quite helpful to trace back the actions of a user if they’re using the command line. Like trash, bash history is another artifact very similar on both Linux and Mac systems. It will report the shell commands sent by each user. Unfortunately, there are no times associated to each command, but they will be in the same order as executed by the user. Also, of note for anyone doing analysis of a live system, the bash history file gets written on close so any open terminals won’t have a history file until the terminal is closed (however it is in memory).
There are plenty of other artifacts such as Startup Items, Recent Files, OS Info, etc… as well as plans to add more over time so if you have any favorites, please reach out and let us know what’s essential for your Linux investigations.
Many of these artifacts will work across most Linux distros but there are some variances between them and the versions of each will matter in some cases. We’ve focused our initial support for the following:
- RedHat Enterprise
Even though these are the ones we initially tested and built support for, these artifacts will work for many others not listed so feel free to run them if you encounter those other distros in your investigation.
Technical Advice Disclaimer
Magnet Forensics is dedicated to engaging with the DFIR community through our blogs and whitepapers. However, properly addressing technological issues often includes numerous variables that require independent assessment and strategies designed for each specific circumstance. Since Magnet Forensics cannot have complete insight into all variables involved in a specific situation, this blog/whitepaper is for informational purposes and should not be read as professional advice recommending techniques or technologies to address your specific situation. We do not accept responsibility for any omission, error, or inaccuracy in this blog/whitepaper or any action taken in reliance thereon.