Abuse of Modular Trust
PAM (Pluggable Authentication Modules) is a fundamental part of Linux authentication infrastructure. Its flexibility – designed to support various authentication mechanisms – can be exploited by adversaries. In our analysis, we encountered a backdoor implemented as a PAM module, consisting of fewer than 100 lines of code, that enables credential theft, authentication bypass, and stealthy persistence.
This implant is compact, effective, and almost entirely invisible. At the time of analysis, the samples had 0-1 detections on VirusTotal – highlighting a critical gap in traditional detection technologies.
Why this Threat Model Matters
PAM modules are loaded into privileged authentication processes, giving them direct access to sensitive user credentials. A malicious PAM can:
- Stealing user names and passwords during login.
- Bypass authentication checks, even with invalid credentials.
- Grant access and remain undetected by standard monitoring tools.
Since PAM modules are shared objects loaded at runtime, attackers can drop malicious modules to disk and configure PAM to load them – without modifying startup binaries. While the analyzed samples were disk-based, in-memory patching or injection of PAM modules remains a plausible and even stealthier alternative in more advanced scenarios.
Functional Overview of the Backdoor
The core mechanism hooks into pam_sm_authenticate() , the primary function called during user authentication. Once invoked, the backdoor:
- Logs or exfiltrates the provided credentials.
- Returns
PAM_SUCCESSunconditionally to bypass authentication. - Mimics legitimate behavior to avoid raising alerts.
The pam.linux.so sample contains both authentication bypass and credential-stealing capabilities. A hardcoded password within the module allows any user to authenticate, effectively enabling impersonation of any system account. When the authentication bypass is triggered, a notification is sent to the command-and-control (C2) server.
The other capability involves recording the username, password, and SSH server listening port to the C2 server. This enables the attacker to establish a reserve connection to the compromised host.
Credential exfiltration with pam_sm_authenticate () – username, password, and host info are assembled and sent via a custom exfiltration function.
Despite its small code footprint, the implant is functionally complete. By integrating directly into the authentication flow, it ensures both credential access and persistence – no additional mechanisms are needed to maintain control. The use of legitimate authentication via _user_auth allows it to remain operational without disrupting expected login behavior.
Limitations of Conventional Malware Scanning
The following SHA-256 hashes represent analyzed variants of the PAM backdoor:
| Name | Hash |
|---|---|
| centos7_pam_access.so | f62624d28aaa0de93e49fcdaaa3b73623723bdfb308e95dcbeab583bdfe3ac64 |
| pam_linux.so | 24d71c0524467db1b83e661abc2b80d582f62fa0ead38fdf4974a64d59423ff1 |
| sshhook(1).so | 5aeae90e3ab3418ef001cce2cddeaaaea5e4e27efdad4c6fa7459105ef6d55fa |
| looter.so | ae26a4bc9323b7ae9d135ef3606339ee681a443ef45184c2553aa1468ba2e04b |
| pam_daemon.so.orig | ac32ed04c0a81eb2a84f3737affe73f5101970cc3f07e5a2e34b239ab0918edd |
Most variants received 0 or 1 detection on VirusTotal when we discovered the threat. This reflects a broader issue with traditional AV engines, which struggle with:
- Non-obfuscated but non-standard logic.
- Custom compiled binaries.
- Implants that resemble legitimate modules in structure and metadata.
THOR Detection Strategy
Unlike AV engines, THOR uses anomaly-based techniques and behavioral logic to identify such implants. Updated detection rules focus on:
- Deviations in control flow inside
pam_sm_authenticate. - Suspicious patterns of credential access or system calls.
- Static anomalies in shared object metadata or build structure.
These patterns have been integrated into THOR‘s current signature set. As long as signatures are up to date, such implants are detectable even if the binary is customized or compiled from scratch.
Practical Detection and Response Guidance
Security teams should consider the following technical steps to detect and mitigate malicious PAM modules:
- Validate all shared objects under
/lib/security/against known-good hashes. - Monitor for changes to
/etc/pam.d/*and use audit frameworks to capture module loads. - Inspect authentication logs for login flows that succeed unexpectedly or bypass multi-factor mechanisms.
- Use THOR in standalone or ASGARD managed-mode to scan for behavioral anomalies across fleets.
- Review signature coverage regularly with
thor-util upgradeand enforce periodic scans.
These steps are particularly critical in high-trust environments such as bastion hosts or jump boxes, where PAM modules act as a security choke point.
Closing Thoughts
This case exemplifies the effectiveness of low-complexity implants in critical areas of the operating system. Modern attackers do not require sophisticated malware frameworks – merely a deep understanding of privileged trust boundaries and minimal code to exploit them.
Because we live in the LLM era, we were able to reproduce the password exfiltration capability by asking a standard AI (not jailbroken) with a single prompt:
Tools like THOR fill the detection gap left by signature-based and EDR-centric approaches by inspecting behavior and metadata. If you already use THOR, verify that your signatures are up to date. If not, consider where such blind spots may exist in your current detection stack – and evaluate how you can mitigate them effectively.
