Logging Passwords on Linux

By Tim Medin | May 30, 2019

Hal Pomeranz tipped me off to a nasty little trick of using Linux’s own auditing features and PAM to grab clear text passwords from users as they use sudo/su on the command line. Linux PAM (Pluggable Authentication Modules) are a flexible method of implementing authentication services.


The pam_tty_audit PAM module can be used to enable auditing of TTY input for specified users. The log is then stored in /var/log/audit/audit.log.

You can configure PAM auditing of user commands by adding a variation to some of the PAM configuration files (more later on the ones that are interesting to us). 

session required pam_tty_audit.so disable=user1,user2 enable=user3,user4

The line above will log all commands for user3 and user4 and will not log user1 or user2. Since we want all the info, we would just use enable=* and no disable option.

Logging Passwords

Of course, we’d like the data (and passwords) for all users. To get passwords in addition to commands we need to use the log_passwd option, so the full like looks like the one below:

session required pam_tty_audit.so enable=* log_passwd

The key to grabbing the passwords is to add the log_passwd option, which is supported in Kernel 3.9 and later. With this option, auditd will capture all keystrokes, including passwords entered on the command line.

This method only works for passwords entered in an active session, such as with su or sudo. Unfortunately, this means you cannot get logon passwords via this method. If you want to capture login credentials you’ll have to create a custom PAM module as demonstrated here.

You can view the audit log with aureport --tty and grep for sudo or su. You’ll see a line that looks like this:

18. 05/23/2019 20:00:00 108 1000 ? 5 sudo "Password1"

The data is pulled from /var/log/audit/audit.log. The relevant line looks like this:

type=TTY msg=audit(1558641803.690:227): tty pid=2170 uid=1000 auid=1000 ses=20 major=4 minor=1 comm="sudo" data=50617373776F726432

The input to sudo (the password) is hex encoded in the data portion of this line. If we decode it, we can see the password.

$ echo 50617373776f726431 | xxd -r -p



Using *nix’s built in auditing features is an easy way to grab privileged passwords on the system. It does require that you have root to get the passwords, just like poor man’s mimikatz for Linux.  


Ubuntu (and Debian)

I tested this on Ubuntu and I assume it will work the same on on Debian.

Assuming you want to catch passwords used in SSH sessions (remember, this method will not get you the login password) you’ll need to enable the PAM modules in SSHD by changing the following line…:

UsePAM no

… to this:

UsePAM yes

Next, you need to setup logging for all sessions. Edit /etc/pam.d/common-session and add the line below anywhere above the first “session required” line (I added it to the top of the file):

session optional pam_tty_audit.so enable=* log_passwd

To make this work you need auditd. auditd is the “userspace component to the Linux Auditing System.” To install auditd run the command below:

apt install auditd

Now use sudo or su in an SSH session or the console/terminal and you should capture the password.

Fedora (and Red Hat):

Add the following line:

session required pam_tty_audit.so enable=* log_passwd

…To the following files:



If it isn’t installed, install audit with the following command:

yum install auditd

This is much easier on the RHEL side of things!


Introduction to Sliver

By Red Siege | November 7, 2022

By: Justin Palk, Security Consultant Around the time Tim decided he was going to give a Siegecast on selecting a C2, I finished building out a test Windows AD domain […]

Learn More
Introduction to Sliver

Moving beyond T4 – Deconstructing Nmap Tuning

By Red Siege | July 6, 2022

by Alex Norman, Senior Security Consultant Nmap -T4 -iL targets.txt This is a very common scan string that many people use to get initial recon done on assessments and, to […]

Learn More
Moving beyond T4 – Deconstructing Nmap Tuning

Creating a Simple Windows Domain for Offensive Testing: Part 4

By Red Siege | June 23, 2022

By: Justin Palk, Security Consultant This is part four of my series of blog posts on creating a windows domain for offensive security testing. In part 1, I stood up […]

Learn More
Creating a Simple Windows Domain for Offensive Testing: Part 4

Find Out What’s Next

Stay in the loop with our upcoming events.