Generating a Log file for Command Line Commands in Linux

This is one of these cases when you wonder why this isn’t there by default in all Linux-based systems. In many cases, it can be useful to look at the list of the command line commands that were used on a server, and perhaps look at the user accounts that were used to issue these commands. This could help accelerate forensic investigations and incident response. It could also help in identifying the scope of a breach.

In this short tutorial, we will use syslog services to capture all commands issued in the command line, the time of command issuance, the username of the account used, and if the command was issued using SSH, we will also capture the IP address that was used in this SSH session.

Step 1: Creating the log settings file, to tell the server where to store the log entries

Create a file named /etc/rsyslog.d/commands.confusing an editor of your choice, such as nano:

sudo nano /etc/rsyslog.d/commands.conf

Add the following two lines to the new empty file:

# Log every command executed by a user to a separate file
local6.* /var/log/commands.log

Save the file and exit. This will create a logger that would capture whatever you pass to local6 events and put it in the commands.log file.

Step 2: Configure your Bash shell to pass the information to the logger.

Edit your /etc/bash.bashrcfile to add these two lines:

# Set PROMPT_COMMAND to log every command to syslog
PROMPT_COMMAND='history -a >(logger -p local6.debug -t "[$USER] $SSH_CONNECTION")'

The first command will tell bash to pass the required information to the logger called local6. The second command will tell the bash shell to capture all commands, including ones with spaces before them.

If you use other types of shell, such as zsh, or sh, make sure that you add the same two lines to their settings files to ensure that the log catches all commands used on all of these shells.

Step 3: Restarting services.

Restart syslog service:

sudo systemctl restart rsyslog

Close all open bash shell sessions, and start a new one. All of the commands types now will be captured in /var/log/commands.log file.



Note: You might face a scenario where “logger” command needs to run with sudo to be able to capture the passed data.

Cracking a “shadow” password using John the Ripper

In this short article, I’ll walk you through the steps of cracking a password stored in the /etc/shadow file on a Linux machine. Keep in mind that in order to access the shadow and passwd files, you need root access.

Step 1:

Extract the user’s entry from the passwd file and the shadow file and put them in text files for John the ripper (replace the USERNAME with the username of your choice):

sudo cat /etc/passwd | grep USERNAME > passwd.txt
sudo cat /etc/shadow | grep USERNAME > shadow.txt

Step 2:

Use the unshadow tool that is part of John the ripper tool set to create a single text file that contains both entries of the user into on line:

unshadow passwd.txt shadow.txt > unshadow.txt

The resulting file would be a combination of the user’s entries from passwd and shadow. This step organizaes the data needed by John in a format that John recognizes.

Step 3:

Choose a dictionary of possible passwords, such as Kali’s rockyou.txt (contains over 14 million passwords), and run John:

john --wordlist=/usr/share/wordlists/rockyou.txt unshadow.txt

If the password is found within the given wordlist, you’d see the output like this:

password (USERNAME)

Step 4:

If you get the famous “No password hashes loaded”, then the cryptographic hashing algorithm used is not easily recognized by John.

Take a look at the unshadow.txt file. The field after the username (with a number or letter between two dollar signs) is the one that identifies the hash type used. It could be one of the following:

  1. $1$ is MD5
  2. $2a$ is Blowfish
  3. $2y$ is Blowfish
  4. $5$ is SHA-256
  5. $6$ is SHA-512
  6. $y$ is yescrypt

For $y$, for example, you can use the command:

john --format=crypt --wordlist=/usr/share/wordlists/rockyou.txt unshadow.txt