Torvalds Tuesday: auth.log

A few weeks ago, I published a post describing the *tmp files in Linux environments, which can be used to identify logon history. For today’s post, I’m going to focus on another important artifact that helps capture related information: auth.log.

Located in /var/log, auth.log is about as simple as it sounds — it contains authorization information. In most cases, this can include:

  • Remote logins
  • Usage of the sudo command
  • Instances where a user password was required for authorization (you may see this referred to as authorization systems elsewhere)

The file is stored in plain text, and rolled/archived logs will be compressed with gzip. Here’s a screenshot of auth.log contents from one of my analysis VMs:

Screenshot of auth.log* files from /var/log

auth.log Contents

As I mentioned, the log file contains various types of authorization events. Let’s look at a few samples:

sudo commands

It’s well known that sudo allows a user to execute a command with superuser privileges, or another user (superuser is the default). As you can imagine, these are authorization events.

grep sudo /var/log/auth.log
Screenshot of auth.log showing sudo events

We can parse this file to see what folder the command was issued from, the user, as well as the command itself! This was an example of me shutting down the system by running init 0.

root session

Aside from sudo, which may be used to run a command with elevated privileges, we can also track a user escalating to root. Here’s an example:

Jan 24 05:52:03 siftworkstation sudo: pam_unix(sudo:session): session opened for user root by sansforensics(uid=0)
Jan 24 05:52:03 siftworkstation su[2916]: Successful su for root by root
Jan 24 05:52:03 siftworkstation su[2916]: + /dev/pts/18 root:root
Jan 24 05:52:03 siftworkstation su[2916]: pam_unix(su:session): session opened for user root by sansforensics(uid=0)
<snip>
Jan 24 07:06:27 siftworkstation su[2916]: pam_unix(su:session): session closed for user root
Jan 24 07:06:27 siftworkstation sudo: pam_unix(sudo:session): session closed for user root

We can use the su[####] to track session activity. Obviously, in this case, the session was a little over 70 minutes.

ssh activity

Also, as mentioned, auth.log will record SSH remote login activity. If you’re running an external server, like some of the honeypots I’ve got going, this log will blow up like crazy VERY FAST. In these situations, it might be best to find successful authentications, and then filter on those session IDs. Here’s an example where I’m connecting via a public key

:/var/log# wc -l auth.log
39864

Let’s walk through this:

:/var/log# grep Accepted auth.log
Jan 23 18:04:40 <hostname> sshd[11089]: Accepted publickey for root from <remote IP> port 61158 ssh2: RSA <RSA STRING>
Jan 24 07:10:49 <hostname> sshd[18038]: Accepted publickey for root from <remote IP> port 50820 ssh2: RSA <RSA STRING>

Now, we can pivot off of 11089 and 18039 to find related activity and session closes:

:/var/log# grep 11089 auth.log
Jan 23 18:04:40 <hostname> sshd[11089]: Accepted publickey for root from <remote IP> port 61158 ssh2: RSA <RSA STRING>
Jan 23 18:04:40 <hostname> sshd[11089]: pam_unix(sshd:session): session opened for user root by (uid=0)
Jan 23 21:38:30 <hostname> sshd[11089]: Received disconnect from <remote IP>: 11: disconnected by user
Jan 23 21:38:30 <hostname> sshd[11089]: pam_unix(sshd:session): session closed for user root

auth.log will also capture failed logins, as I’m sure you can imagine. Using some quick filters to find successful attempts helps us filter out the noise.

When performing Linux triage, I always get a copy of auth.log (and its backups) so I can figure out what’s going on with the system.


Until tomorrow, Happy Forensicating!