Add content from: Research Update Enhanced src/linux-hardening/linux-post-expl...

Author: HackTricks News Bot

src/linux-hardening/linux-post-exploitation/pam-pluggable-authentication-modules.md

@@ -44,6 +44,16 @@ Controls dictate the module's response to success or failure, influencing the ov
 - **Sufficient**: Success bypasses the rest of the same realm's checks unless a subsequent module fails.
 - **Optional**: Only causes failure if it's the sole module in the stack.
 
+#### Offensive Semantics That Matter
+
+When backdooring PAM, the **location of the inserted rule** is often more important than the payload itself:
+
+- `include` and `substack` pull rules from other files, so editing `sshd` might only affect SSH while editing `system-auth`, `common-auth`, or another shared stack affects several services at once.
+- PAM also supports bracketed controls such as `[success=1 default=ignore]`. These can be abused to **skip one or more modules** after a successful custom check instead of visibly replacing `pam_unix.so`.
+- The `module-path` can be **absolute** (`/usr/lib/security/pam_custom.so`) or **relative** to the default PAM module directory. On modern Linux systems the real directories are often `/lib/security`, `/lib64/security`, `/usr/lib/security`, or multiarch paths like `/usr/lib/x86_64-linux-gnu/security`.
+
+Quick operator takeaway: always map the **full service graph** before patching. For example, `sshd -> password-auth -> system-auth` on some distros or `sshd -> system-remote-login -> system-login -> system-auth` on others means the same one-line implant may fan out much wider than intended.
+
 #### Example Scenario
 
 In a setup with multiple auth modules, the process follows a strict order. If the `pam_securetty` module finds the login terminal unauthorized, root logins are blocked, yet all modules are still processed due to its "required" status. The `pam_env` sets environment variables, potentially aiding in user experience. The `pam_ldap` and `pam_unix` modules work together to authenticate the user, with `pam_unix` attempting to use a previously supplied password, enhancing efficiency and flexibility in authentication methods.
@@ -132,15 +142,44 @@ grep -R "pam_.*\.so" /etc/pam.d/ | grep -E 'plg|selinux|custom|exec'
 ### Abusing `pam_exec` for persistence
 Instead of replacing `pam_unix.so`, a lighter touch is to append a `pam_exec` line in `/etc/pam.d/sshd` so every SSH login launches an implant while leaving the normal stack intact:
 ```bash
-# Prepend to /etc/pam.d/sshd
-session optional pam_exec.so quiet /usr/local/bin/.ssh_hook.sh
+# Run on successful auth and receive the typed password on stdin
+auth optional pam_exec.so quiet expose_authtok /usr/local/bin/.ssh_hook.sh
 ```
-`pam_exec` runs as root inside the sshd PAM context, so the script can drop reverse shells, collect env vars, or re-open implanted sockets with no filesystem changes to core libraries.
+`pam_exec` receives PAM metadata in environment variables such as `PAM_USER`, `PAM_RHOST`, `PAM_SERVICE`, `PAM_TTY`, and `PAM_TYPE`. With `expose_authtok`, the helper can also read the password from `stdin` during `auth` or `password` phases. If you want the helper to run with the effective UID instead of the real UID, add `seteuid`.
+
+Practical notes:
+
+- `session optional pam_exec.so ...` is better for **post-login actions** such as re-opening sockets or spawning a detached daemon.
+- `auth optional pam_exec.so quiet expose_authtok ...` is the usual choice for **credential capture** because it runs before the session opens.
+- `type=session` or `type=auth` can be used to constrain execution to a specific PAM phase and avoid noisy double execution.
+
+### Surviving distro tooling: `authselect`
+
+On RHEL, CentOS Stream, Fedora, and derivative systems, direct edits to generated files such as `/etc/pam.d/system-auth` or `/etc/pam.d/password-auth` may be **overwritten by `authselect`**. For persistence, operators often patch the active custom profile under `/etc/authselect/custom/<profile>/` and then re-select or apply it.
+
+Typical workflow when you have root:
+
+```bash
+# Inspect the active profile first
+authselect current
+
+# If a custom profile already exists, edit its PAM templates instead of system-auth directly
+find /etc/authselect/custom -maxdepth 2 -type f \( -name 'system-auth' -o -name 'password-auth' \) -ls
+
+# Re-apply the profile after modifying the template files
+authselect select custom/<profile>
+```
+
+This matters for both offense and triage: if `/etc/pam.d/system-auth` contains the banner `Generated by authselect` and `Do not modify this file manually`, then the real persistence point may live under `/etc/authselect/custom/` rather than in `/etc/pam.d/`.
+
+### Recent tradecraft seen in the wild
+
+Recent 2025 reporting on the **Plague** Linux backdoor showed the same core idea taken further: a malicious PAM component with a **static bypass password**, plus cleanup of SSH-related environment variables and shell history (`HISTFILE=/dev/null`) to reduce session traces after login. That is a useful hunting pattern because the backdoor logic may live in PAM while the stealth artifacts only appear **after** authentication succeeds.
 
 
 ## References
 
-- [https://hotpotato.tistory.com/434](https://hotpotato.tistory.com/434)
-- [Palo Alto Unit42 – Infiltration of Global Telecom Networks](https://unit42.paloaltonetworks.com/infiltration-of-global-telecom-networks/)
+- [pam.conf(5) / pam.d(5) - Linux-PAM Manual](https://man7.org/linux/man-pages/man5/pam.d.5.html)
+- [Nextron Systems - Plague: A Newly Discovered PAM-Based Backdoor for Linux](https://www.nextron-systems.com/2025/08/01/plague-a-newly-discovered-pam-based-backdoor-for-linux/)
 
 {{#include ../../banners/hacktricks-training.md}}