Linux Server Forensics

1. cron
   
2. Services/systemd
3. bashrc
4. Kernel modules
5. SSH keys

Cron is one of the more common methodologies, so it's probably best to start there.

It looks like the command from the previous task was set up to run under the root2 account. This account doesn't make any sense as there should only be one root account. Wonder how it got there?

There are a couple of locations where account information is stored on Linux distributions, including:

1. /etc/passwd  - contains the names of most of the accounts on the system.  Should have open read permissions and should not contain password hashes. 
2. /etc/shadow -  contains names but should also contain password hashes.  Should have strict permissions.

Wow, it looks like they got hacked again! Better have another look; the credentials are the same as last time:

1. MACHINE_IP
   
2. 'fred'
3. 'FredRules!'
   

The log file is a lot smaller this time around, so it looks like our attacker was a little more subtle. There also don't appear to be obvious user agents anymore. Fortunately, there are a few other ways of identifying traffic originating from scanners. The time between each request is a good metric for most tools. You can also identify individual tools from signatures left in the requests; for example, Nmap will send HTTP requests with a random non-standard method when performing certain enumeration tasks. More aggressive tools can also be identified simply from the number of requests sent during any given attack; directory brute-forcing tools are a perfect example of this and are likely to fall foul of banning systems like fail2ban.

A poorly designed site may also freely grant valuable information without the need for aggressive tools. In this case, the site uses sequential IDs for all of the products making. It easily scrapes every single product or finds the total size of the product database by simply increasing the product ID until a 404 error occurs.

Of course, adding a public key to root's authorized_keys requires root-level privileges so, it may be best to look for more evidence of privilege escalation. In general, Linux stores a tiny amount of programme execution history when compared to Windows but, there are still a few valuable sources, including:

1. bash_history - Contains a history of commands run in bash; this file is well known, easy to edit and sometimes disabled by default.
2. auth.log - Contains a history of all commands run using sudo.
3. history.log (apt) - Contains a history of all tasks performed using apt - is useful for tracking programme installation and removal.

systemd services also keep logs in the journald system; these logs are kept in a binary format and have to be read by a utility like journalctl. This binary format comes with some advantages; however, each journal is capable of validating itself and is harder to modify.

This is getting a little annoying now. The credentials are still the same:

1. MACHINE_IP
   
2. 'fred'
3. 'FredRules!'

Malware can also maintain persistence using systemd as scripts run under systemd can run in the background and restart whenever the system is booted or whenever the script crashes. It is also relatively easy to conceal malicious scripts as they can blend in with other services. systemd services are defined in .service files which can contain:

1. The command that runs whenever the service starts
2. The user the service runs as
3. An optional description 

In this case, the malware is pretty obvious as it seems to be printing errors to the screen so, there is no way that it is dormant. Running systemctl will list all of the services loaded into the system. And much like Windows, there's usually a lot of them. It might be worth adding --type=service --state=active to the command as it will reduce the list to services that are running. Once the name of a suspicious service is found, more information can then be extracted by running systemctl status <service name> .