Introduction
Since its creation, Linux has been an operating system (OS) designed for simplicity, functionality, and flexibility. It enables users to modify and customize every component and module of the system.
In July 1991, Linus Torvalds announced on the comp.os.minix newsgroup that his operating system was designed to be easily modified and improved by tech professionals according to their needs.

Figure 1: Screenshot of Linus Torvald’s message on comp.os.minix.
Linux’s modular design offers users the flexibility to customize the OS by adding, removing, or altering components such as networking, security, system management, graphical user interfaces, and automation tools. This flexibility allows Linux to operate on a diverse range of devices, including smartphones, personal computers, and game consoles.
Modularity and simplicity are crucial in Linux, where security is a primary concern. As an open-source system, Linux benefits from the contributions of thousands of security experts who continuously work to address vulnerabilities and bugs, enhancing the OS’s security and making it one of the most secure systems available. The separation between the kernel and user space, along with MAC-based settings provided by the SELinux security module, helps prevent unauthorized root access and limits the spread of malware.
Linux security encompasses various aspects, including authentication, data encryption, and user anonymization.
This article will delve into one of the most intricate and important aspects of Linux security: Pluggable Authentication Modules (PAM).
Key discoveries in the blog
- Despite its strengths, the Pluggable Authentication Module’s (PAM) modularity introduces risks, as malicious modifications to PAM modules can create backdoors or steal user credentials, especially since PAM does not store passwords but transmits values in plaintext.
- The pam_exec module, which allows the execution of external commands, can be exploited by attackers to gain unauthorized access or establish persistent control by injecting malicious scripts into PAM configuration files.
- A specific attack scenario involves manipulating PAM configuration for SSH authentication to execute a script via pam_exec, enabling silent malicious actions.
Who may find this blog interesting:
- Cybersecurity analysts and corporate security teams
- Malware analysts
- Threat intelligence specialists
- Cyber investigators
- Computer Emergency Response Teams (CERT)
What is PAM and what is it used for?
PAM is a modular framework built on shared libraries designed to manage user authentication and authorization across various applications. It separates the authentication process from individual applications, allowing for greater flexibility.
Applications such as su, passwd, login, gdm, sshd, and ftpd can all utilize PAM. PAM provides each of these applications with a specialized library to verify user identities and determine whether they have the necessary permissions to access resources.

Figure 2: Simplified PAM workflow.
The PAM framework offers four main types of modules, each serving a specific purpose:
- Auth: Validates user identity.
- Account: Handles account verification and ensures the account is in good standing.
- Password: Manages password updates, checks password complexity, and helps prevent dictionary attacks.
- Session: Manages activities and settings during a service session.

Figure 3: Detailed PAM workflow.
Each PAM module offers various control flags to manage authentication results:
- Required
- Passed: All subsequent controls are executed. If all are successful, the request is allowed.
- Failed: The request is denied after all other controls are checked.
- Requisite
- Passed: All subsequent controls are executed. If all are successful, the request is allowed.
- Failed: The request is immediately denied.
- Sufficient
- Passed: If this module succeeds, no further controls are checked, and the request is allowed.
- Failed: This module is ignored, and the remaining controls are evaluated.
- Optional: The result of this control is executed, but its outcome is ignored.
These control flags dictate how PAM handles each request’s result.
The PAM framework is built on a variety of modules, including:
- pam_unix: Manages global authentication policies.
- pam_ldap: Authenticates and authorizes against LDAP servers and handles password changes.
- pam_wheel: Restricts access to the su command.
- pam_cracklib: Tests password strength.
- pam_console: Grants special privileges to users at the physical console.
- pam_tally: Locks accounts after too many login attempts.
- pam_nologin: Disables accounts except for root.
- pam_limits: Sets limits on system resource usage.
- pam_time: Restricts access times to services.
- pam_access: Manages user access.
- pam_exec: Executes external commands.
PAM’s modular architecture offers extensive configuration options to meet diverse administrative needs.
However, it’s important to remember that PAM is not a panacea for all security issues. Adversaries can potentially exploit or modify PAM modules to gain unauthorized access or create backdoors. Malicious changes to PAM components could be used to steal credentials or inject harmful payloads since PAM does not store passwords and the values exchanged with its modules may be in plain text.
Exploiting pam_exec for full persistence
The Group-IB DFIR Team identified a new technique not yet included in the MITRE ATT&CK framework, which could lead to use the module pam_exec to obtain a privileged shell on a host and grant a full persistence to a threat actor.
The pam_exec module is typically used to run external commands when specified in one of the main PAM module interfaces. For example, you could configure PAM to send an email notification whenever a password change occurs. To achieve this, you would add pam_exec to the /etc/pam.d/passwd configuration file, which handles password updates, complexity checks, and dictionary attack prevention.
The configuration for pam_exec in this context might look like this:
pam_exec.so [debug] [expose_authtok] [seteuid] [quiet] [log=file] command

Figure 4: An example of pam_exec is used.
Adding this line to /etc/pam.d/passwd will configure the system to use the pam_exec.so module to execute the script mail_notification.sh with the real user ID of the calling process (as specified by the seteuid option) after every local password change:

Figure 5: pam_exec usage scenario.
Leave no trace: pam_exec and SSH
As previously explained, PAM is a framework that allows each application to connect and access its various modules.
Consider a scenario where OpenSSH—a powerful suite of tools for remotely controlling networked computers and transferring data between them—is configured to use PAM.
The OpenSSH server daemon, sshd, continuously listens for connection requests from external hosts. When a request is received, sshd establishes the appropriate connection based on the client tool that is connecting.
What if a threat actor modified the PAM configuration related to SSH authentication to invoke pam_exec and execute a malicious payload?
In this case, the sshd PAM module would be altered to include a new line that executes a script named tn.sh via pam_exec during SSH authentication attempts.

Figure 6: Screenshot of the sshd pam module after the alteration.
This new line, declared as optional, does not affect the authentication process chain, as previously explained, and will only be executed if the authentication attempt fails.
The executed script is configured as follows:

Figure 7: Script source code.
First, the script transfers the date, username, and environment data to the remote server with IP address 10.0.0.142, redirecting the output through a pipe to the tool netcat (also known as nc) on port 1234.

Figure 8: Examining lines 1 and 2 of the script source code (Figure 7).
Next, it sends data related to the environment variables `PAM_RHOST`, `PAM_SERVICE`, and `PAM_USER` to the remote server at IP address 10.0.0.142, redirecting the output through a pipe to the tool `netcat` on port 1234.

Figure 9: Examining lines 3 and 4 of the script source code (Figure 7).
Finally, it sends the same data as before, but this time using the `PAM_USER` variable to define the remote server, making the use of environment variables more flexible.

Figure 10: Examining line 5 of the script source code (Figure 7).
When an external host attempts to connect via SSH, the script is automatically executed, and data is transferred to the remote host specified by the aforementioned variable, even if the login attempt fails.

Figure 11: How SSH and PAM can be used to eliminate any traces of data exfiltration within system logs.

Figure 12: Screenshot of data transfer.
This technique ensures that no traces of data exfiltration appear in system logs, which will only show a failed login attempt. Consequently, it also makes forensic investigations more difficult.

Figure 13: Screenshot of SSH logs.
Conclusion
Linux is one of the most secure operating systems in use today, running on millions of hosts and offering reliability in various aspects. However, its features can also be exploited by threat actors to operate stealthily and conceal malicious activities. Therefore, it is crucial to harden each Linux-based server and workstation and conduct thorough security assessments to ensure the highest level of security.
Recommendations
The Group-IB DFIR team recommends hardening any publicly accessible Linux-based server and implementing several key security countermeasures, including:
- Apply the latest security patches and updates.
- Enable and configure SELinux and AppArmor for enhanced security.
- Install and configure Auditd with DISA-STIG recommended rules to monitor changes to system files.
- Evaluate to implement a solution like Wazuh to monitor and verify the compliance of a Linux Server to the company security baseline.
- Disable root login and ensure that only the root user has UID 0.
- Lock the root account to prevent unauthorized access.
- Restrict permissions related to cron jobs to minimize security risks.
- Restrict system settings to limit potential vulnerabilities.
- Install and enable PSAD to enhance intrusion detection.
- Install and enable AIDE for file integrity monitoring.
- Limit sudo access to authorized users only.
- Install and enable rkhunter to detect rootkits and other malicious software.
Learn more about Group-IB Incident Response!
Benefit from the fastest incident response from industry leaders.






