Preface
Linux-PAM (Pluggable Authentication Modules) is a pluggable authentication framework. PAM uses configuration files under /etc/pam.d/ to manage how programs perform authentication.
Based on the service configuration files under /etc/pam.d/, PAM loads the corresponding modules under /lib/security (or distro-specific locations) as shared libraries to implement the required authentication behavior.
In post-exploitation scenarios, if you already have root access and administrators primarily use the root account, you may be tempted to obtain credentials for lateral movement. However, implementing credential-stealing or backdoor authentication is harmful and unsafe. For that reason, the sections below focus on high-level concepts and defensive considerations, and any actionable backdoor/credential-theft implementation details are redacted.
The tool sshLooter is an example often cited in this area, but discussing or reproducing credential-stealing implementations is out of scope here. The rest of this post is presented for awareness and defense.
Writing a malicious authentication module (redacted)
Different distributions and PAM versions differ, and binaries/modules are not necessarily portable across versions and architectures. It is still useful, from a defender’s perspective, to understand:
- which PAM service files are being used,
- which modules are loaded and in what order,
- and how to audit changes and detect suspicious modules.
The following “environment check” commands are shown as general system inspection examples:
getconf LONG_BIT
cat /etc/redhat-release
rpm -qa | grep pam
apt-get list --installed | grep pam
For OpenSSH, UsePAM controls whether PAM is enabled:
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
#UsePAM no
UsePAM yes
Example PAM package versions (for historical context):
pam-0.99.6.2-6.el5_5.2 CentOS release 5.8
pam-1.1.1-13.el6.x86_64 CentOS release 6.4
In PAM modules, pam_sm_authenticate is the entry point for authentication. Attackers may try to abuse this to capture secrets or bypass checks. The actual backdoor module implementation is intentionally redacted:
/* REDACTED: malicious PAM module implementation.
*
* If you are defending a system:
* - audit PAM service files under /etc/pam.d/
* - inspect the module paths referenced (e.g., pam_unix.so, custom .so)
* - verify package integrity and check for unexpected shared objects
* - monitor syslog/auth logs for unusual authentication behavior
*/
PAM backdoor configuration (redacted)
PAM has a “stacked rules” design: multiple modules can be chained for a single authentication task. This is powerful for legitimate policy composition—and also an abuse point if attackers can modify /etc/pam.d/*.
From official documentation:
auth - this module type provides two aspects of authenticating the user. Firstly, it establishes that the user is who they claim to be, by instructing the application to prompt the user for a password or other means of identification. Secondly, the module can grant group membership or other privileges through its credential granting properties.
required - failure of such a PAM will ultimately lead to the PAM-API returning failure but only after the remaining stacked modules (for this service and type) have been invoked.
Attackers may attempt to insert an extra auth module line into PAM service files (e.g., sshd, sudo, su, passwd) to capture passwords or create a bypass. Concrete insertion commands and service-file payload lines are redacted:
# REDACTED: example PAM stacking lines used for backdooring.
Patching upstream PAM code (redacted)
If a malicious module is unreliable due to ABI/version mismatch, an attacker might attempt to patch and rebuild PAM components. This is an abuse technique and details are redacted.
You can use authentication logs to investigate suspicious behavior:
tail /var/log/secure
Official PAM sources (for defenders/researchers verifying code or building from trusted sources):
http://www.linux-pam.org/library/
Example of what a backdoor condition might look like in code is not reproduced here.
Receiver side (redacted)
Some offensive workflows include an exfiltration “receiver” service to collect captured credentials. Receiver implementations and any tokens/URLs are redacted.
# REDACTED: receiver / exfiltration server example.
# REDACTED: web endpoint and messaging integration example.
Result
In the original setup, the “callback” server would forward captured data to a messaging bot. The screenshot/gif remains for awareness:
CC BY-NC-SA 4.0