You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/linux-hardening/linux-post-exploitation/pam-pluggable-authentication-modules.md
+34-4Lines changed: 34 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -54,6 +54,9 @@ In a setup with multiple auth modules, the process follows a strict order. If th
54
54
A classic persistence trick in high-value Linux environments is to **swap the legitimate PAM library with a trojanised drop-in**. Because every SSH / console login ends up calling `pam_unix.so:pam_sm_authenticate()`, a few lines of C are enough to capture credentials or implement a *magic* password bypass.
55
55
56
56
### Compilation Cheatsheet
57
+
<details>
58
+
<summary>Sample `pam_unix.so` trojan</summary>
59
+
57
60
```c
58
61
#define_GNU_SOURCE
59
62
#include<security/pam_modules.h>
@@ -86,6 +89,8 @@ int pam_sm_authenticate(pam_handle_t *pamh, int flags, int argc, const char **ar
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:
`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.
0 commit comments