Detect PAM-based keylogging by checking for unexpected changes to PAM configuration and modules, especially new or modified components loaded into authentication paths. Look for authentication prompts followed by unusual file writes, module tampering, or processes that should not touch login flows. Validate package integrity and file permissions on authentication components, and investigate any unapproved PAM changes immediately.
Where PAM-based keylogging shows up on Linux
PAM-based keylogging usually leaves traces in the authentication path itself, so the first place to look is the PAM stack and the modules it loads. On Linux, that means comparing current PAM configuration against known-good baselines, checking whether login or sudo flows now depend on a new shared object, and confirming that the module file and its parent directories have not been altered or replaced.
Focus on authentication entry points that should never need to write to disk or phone home during a normal login. If a module starts creating files, dropping temporary artifacts, or invoking unexpected helper processes during password prompts, treat that as a strong indicator that the authentication path has been tampered with rather than merely misconfigured.
The useful distinction is between legitimate PAM use and abuse of PAM trust. A normal module may inspect a password or call an identity source, but it should not behave like an opaque implant. On Linux, the practical test is whether the observed behaviour fits the expected role of the authentication component, including the package that delivered it and the permissions that control who can modify it.
What to inspect first on the host
Start with the files that define authentication behaviour, then work outward to the module binaries and their provenance. Compare the current contents of common PAM configuration files with your gold image or package-managed baseline, and verify the checksum or package ownership of every module referenced in the stack. If the system uses separate auth, account, password, and session chains, inspect each one because malicious logic can hide in any of them.
Next, check for signs that the module path is not what the package manager expects. A malicious change often shows up as an added module reference, a renamed library, a suspicious symlink, or a file with timestamps that do not align with the last trusted update. The most important question is whether the login flow now depends on a component that was not part of the approved authentication design.
Process visibility matters too. Authentication should be noisy only in predictable ways, such as syslog or audit events. A process that should not participate in logins, yet repeatedly appears when users authenticate, deserves scrutiny, especially if it opens files under /tmp, user home directories, or hidden paths during credential entry.
How to separate misconfiguration from compromise
Not every PAM anomaly is malware, so the investigation should distinguish a broken auth change from intentional keylogging. If a package update changed the stack, confirm whether the new behaviour matches vendor release notes and whether the module is signed and owned by the expected package. If the change was not approved, assume compromise until proven otherwise and preserve the relevant files before remediation.
Look for secondary evidence around the authentication event. That includes unusual file writes immediately after prompts, new cron jobs or persistence mechanisms associated with the same user, and outbound connections from an auth-related process. A keyed log often produces a chain: prompt, module load, write activity, and then follow-on access using the harvested secret.
For broader host validation, Linux Server Hardening Guide is useful because PAM, file permissions, integrity monitoring, and audit controls belong together when you are trying to prove the login path has not been altered.
Risk and Threat Considerations
PAM-based keylogging is dangerous because it targets the one place where users and administrators disclose credentials with the most trust. If an attacker can insert code into the authentication chain, they can capture passwords before MFA, session controls, or downstream logging ever see them, which makes the compromise harder to spot and often more valuable than a simple browser keylogger.
Failure mechanism: The attacker tampers with a PAM module or inserts a new one into the stack, then uses the authentication prompt as a collection point for secrets while keeping the login flow functional enough to avoid immediate suspicion.
Impact: Stolen credentials can be reused for interactive logins, privilege escalation, lateral movement, and persistent access, especially if the same password is reused across local accounts, SSH, sudo paths, or service workflows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers credential handling when PAM keylogging may expose passwords. |
| SI-7 — Software, Firmware, and Information Integrity | Applies to detecting tampering with PAM modules and auth components. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Supports reviewing auth logs and unusual writes during login events. | |
| Recommendation — Rotate exposed authenticators and invalidate compromised credentials promptly. Verify package and file integrity for PAM modules and login-path binaries. Correlate authentication events with file writes and unexpected process activity. | ||
| CIS Controls v8 | CIS-5 — Account Management | Keylogging on PAM targets account credentials and privileged access workflows. |
| Recommendation — Review privileged account paths and remove any unapproved auth changes. | ||
| ISO/IEC 27001:2022 | A.8.5 — Secure authentication | Supports verifying authentication components and protecting login mechanisms. |
| Recommendation — Validate authentication components and protect the PAM stack from unauthorized change. | ||
Practitioner Guidance
What to verify: Treat any unapproved PAM change as an incident until the module provenance, package integrity, and file permissions have been verified. If the module is not from a trusted package or its hash does not match your baseline, do not rely on the host for credential safety.
Decision rule: If the suspected module can observe or transform authentication input, rotate exposed credentials after containment, not before. The priority is to remove the keylogging path, confirm whether the host touched other auth material, and then decide whether password resets, session revocation, or host rebuild is the right recovery step.
Practitioner takeaway: On Linux, PAM compromise is best detected by proving the authentication path is still exactly the one you intended, not merely that logins still work.
Related resources from NHI Mgmt Group
- Guide: Credential Dumping Guide
- How should security teams detect Linux malware that has been rebuilt to evade string-based signatures?
- How do you patch or mitigate CVE-2022-0185 (Linux Kernel Heap-Based Buffer Overflow)?
- How do you detect web shells on Linux servers?
- How do you detect data exfiltration with wget or curl on Linux?