Linux Authentication and Privilege Model

PAM: the authentication gateway

Pluggable Authentication Modules is the framework through which every Linux authentication event passes. When a user logs in via SSH, types a password for sudo, or authenticates to any PAM-aware service, the request passes through a stack of PAM modules defined in configuration files under /etc/pam.d/. Each module performs a specific function: pam_unix checks the password against /etc/shadow, pam_faillock tracks failed attempts and enforces lockout, pam_google_authenticator provides TOTP-based MFA. The PAM stack is processed in order, and the control flags determine behavior: required means the module must succeed but processing continues. sufficient means if this module succeeds, authentication succeeds immediately without processing further modules. requisite means if this module fails, authentication fails immediately.

The security implication is dual. PAM is your authentication enforcement point — properly configured, it enforces password complexity, account lockout, MFA, and session controls. But PAM is also an attack surface. An attacker with root access can install a malicious PAM module that logs every password entered on the system — credential harvesting that captures plaintext passwords for every user who authenticates, including service accounts that connect to databases and manufacturing systems. The attacker can replace pam_unix with pam_permit — a module that accepts all authentication without checking credentials — creating a backdoor that accepts any password. Or they can insert a sufficient module at the top of the stack that accepts a hardcoded attacker password, bypassing all subsequent checks.

At NE, the 6 RHEL servers use default PAM configuration for SSH authentication: no MFA, no session logging, no file integrity monitoring on PAM configuration files. An attacker who compromises root can modify /etc/pam.d/sshd with a single line and create a persistent authentication backdoor that survives password changes, key rotations, and most incident response procedures that focus on user accounts rather than PAM infrastructure. The detection for PAM abuse is file integrity monitoring: auditd watch rules on /etc/pam.d/ and /lib64/security/ (the directory containing PAM shared object libraries) that alert on any file creation, modification, or deletion. Any change to these directories outside of a documented patching window is a critical finding that warrants immediate investigation — legitimate PAM changes happen during OS updates or deliberate configuration changes, not at 2 AM on a Tuesday.

Linux credential storage: /etc/shadow vs LSASS

Where Windows stores credentials in the LSASS process memory (Section 1.2), Linux stores password hashes in /etc/shadow — a file readable only by root. The hashes use modern algorithms: SHA-512 (identified by $6$ prefix) on most modern distributions, or yescrypt ($y$) on newer systems. Unlike Windows NTLM hashes, these hashes cannot be used directly for authentication (no pass-the-hash equivalent for Linux shadow hashes). They must be cracked offline using tools like hashcat or John the Ripper.

The credential theft comparison matters for understanding cross-platform risk. On Windows, dumping LSASS yields immediately usable NTLM hashes — the attacker can pass-the-hash without cracking. On Linux, extracting /etc/shadow yields hashes that require cracking — a time-intensive process that may not succeed for strong passwords. However, Linux has a credential exposure path that Windows does not: SSH key authentication. If the attacker finds SSH private keys in ~/.ssh/ on the compromised server — keys that authenticate to other servers — they have immediate, passwordless access to every server those keys unlock. SSH key theft on Linux is the functional equivalent of NTLM pass-the-hash on Windows: immediate lateral movement without password knowledge. The defensive control is the same principle applied differently — rotate SSH keys regularly, use passphrase-protected keys, and deploy an SSH certificate authority rather than distributing static keys.

Sudo: the privilege boundary attackers cross

Sudo is the primary mechanism for legitimate privilege escalation on Linux. The /etc/sudoers file defines which users can execute which commands as which other users. A properly configured sudoers file implements least privilege: the web service account can restart nginx but cannot modify system files. The database administrator can run maintenance commands but cannot install packages.

Misconfigured sudoers is one of the most common Linux privilege escalation vectors. The pattern: user ALL=(ALL) NOPASSWD: /usr/bin/vim allows the user to run vim as root without a password. Vim has a built-in command execution feature — :!bash spawns a shell from within vim, and because vim is running as root, the spawned shell inherits root privileges. The GTFOBins project (gtfobins.github.io) catalogues hundreds of Unix binaries that can be abused for shell escapes when available through sudo — including vim, less, more, find, awk, python, perl, and nmap. Every binary with a shell escape capability becomes a root shell when granted via sudo.

The GTFOBins categories matter for auditing. "Shell" binaries like vim and less spawn an interactive shell directly — granting sudo access to any Shell-category binary is an immediate root compromise using the binary's documented feature. "File read" binaries like head and xxd can read arbitrary files as root, including /etc/shadow. "File write" binaries like tee and cp can modify arbitrary files, allowing the attacker to write their own entry into /etc/sudoers or modify /etc/shadow directly. A thorough sudoers audit checks every permitted binary against the GTFOBins database across all three categories, not just the Shell category.

Beyond sudo, polkit (PolicyKit) is an additional privilege escalation mechanism on modern Linux systems that mediates privileged operations through authorization rules. The CVE-2021-4034 (PwnKit) vulnerability in polkit's pkexec allowed any local user to gain root by exploiting a memory corruption in the SUID-root pkexec binary — a vulnerability that existed for over 12 years before discovery. Polkit rules should be audited alongside sudoers because both are privilege delegation mechanisms, both can be misconfigured, and both are targeted by attackers.

Feb 14 09:35:41 rhel-web01 sudo: www-data : TTY=pts/2 ; PWD=/var/www ;
    USER=root ; COMMAND=/usr/bin/vim /etc/nginx/nginx.conf
Feb 14 09:35:44 rhel-web01 sudo: www-data : TTY=pts/2 ; PWD=/var/www ;
    USER=root ; COMMAND=/bin/bash
Feb 14 09:35:44 rhel-web01 su: (to root) www-data on pts/2

This auth.log sequence tells the story of the GTFOBins escalation. The first line shows www-data running vim as root through sudo — this is the legitimate use case the operations team configured. The second line, three seconds later, shows www-data running bash as root — this is the shell escape. The third line confirms the privilege change. The gap between the two sudo entries is where :!bash was typed inside vim. The detection opportunity is the second entry: www-data invoking /bin/bash as root through sudo. If the sudoers configuration only permits vim, why is bash being executed as root? The mismatch between the permitted command (vim) and the child process (bash) is the escalation indicator.

The defensive controls for sudo are audit logging of all sudo commands (enabled by default in most distributions through auth.log or journalctl), auditd rules that monitor /etc/sudoers modifications, Sysmon for Linux Event ID 1 capturing the process creation with the full command line, and regular sudoers review to identify overly permissive configurations. The correct remediation for the NE scenario: replace NOPASSWD: /usr/bin/vim with sudoedit /etc/nginx/nginx.conf — the sudoedit command opens the file in the user's editor but applies changes through a controlled mechanism that does not allow shell escapes.

The sudoers audit should run quarterly on all Linux servers. Export /etc/sudoers and all files in /etc/sudoers.d/. Flag any NOPASSWD entries — each should have a documented business justification and a confirmed absence of GTFOBins shell escapes. Flag any entries that grant access to binaries in the GTFOBins list: vim, vi, nano, less, more, find, awk, python, perl, ruby, nmap, ftp, and dozens of others. Flag any ALL=(ALL) entries for non-admin accounts — these are unrestricted root access. For service accounts that require passwordless sudo for automation, restrict to the specific commands the automation executes and verify each command against GTFOBins. This audit feeds into the hardening assessment from Module ES13.

SUID, capabilities, and the enumeration an attacker runs first

SUID (Set User ID) binaries run with the permissions of the file owner regardless of who invokes them. /usr/bin/passwd needs SUID because changing a password requires writing to /etc/shadow, which only root can modify. The attack surface: any SUID-root binary with a vulnerability gives the attacker root access. Custom SUID binaries installed by administrators or applications are particularly dangerous because they receive less security scrutiny than system binaries.

$ sudo -l
User www-data may run the following commands on rhel-web01:
    (root) NOPASSWD: /usr/bin/vim
$ find / -perm -4000 -type f 2>/dev/null
/usr/bin/passwd
/usr/bin/mount
/usr/bin/umount
/usr/bin/su
/usr/bin/sudo
/usr/bin/ping
/opt/mfg-tools/mfg-diag    ← non-standard SUID binary
$ getcap -r / 2>/dev/null
/usr/bin/ping cap_net_raw=ep
/opt/monitoring/check_health cap_sys_admin=ep    ← dangerous capability

This is the first thing an attacker runs after gaining a shell on a Linux server: enumerate privilege escalation paths. Three results are immediately actionable. The sudo rule for vim is a direct root shell via GTFOBins. The non-standard SUID binary /opt/mfg-tools/mfg-diag was installed by the manufacturing team and may contain exploitable vulnerabilities — any custom SUID binary warrants immediate security review. The cap_sys_admin capability on /opt/monitoring/check_health is effectively root access — CAP_SYS_ADMIN allows mounting filesystems, managing namespaces, and performing operations that can be leveraged for full privilege escalation.

On a hardened system, the SUID list contains only essential system binaries — passwd, su, mount, umount, ping, sudo. No custom binaries. Capabilities are assigned only where needed: cap_net_raw on ping is correct and minimal. cap_sys_admin on a monitoring tool is excessive — the tool likely needs only cap_dac_read_search (to read files regardless of permissions) or no capabilities at all if it can read what it needs as a regular user.

The defensive controls for SUID and capabilities are inventory-based. Schedule a weekly find / -perm -4000 -type f and compare the output against a known-good baseline — any new SUID binary that was not in the previous scan warrants immediate investigation because it means someone or something granted root-level execution privilege to a new binary. Mount non-system partitions with the nosuid option, which prevents SUID from functioning on files in those partitions — this stops an attacker from creating their own SUID binary on a writable filesystem like /tmp or /var. For capabilities, run getcap -r / 2>/dev/null and review each grant against the principle of minimal privilege. Flag any grant of CAP_SYS_ADMIN, CAP_SYS_PTRACE, or CAP_DAC_OVERRIDE on non-system binaries — each of these capabilities can be leveraged for privilege escalation in different ways. Container environments add another capability concern: containers running with excessive capabilities (especially --privileged flag in Docker, which grants all capabilities) effectively have root on the host.

// Detect sudo abuse — privilege escalation via GTFOBins shell escape
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName == "sudo"
| where FileName in~ ("bash", "sh", "dash", "zsh", "fish")
| where AccountName != "root"
| project Timestamp, DeviceName, AccountName,
    InitiatingProcessCommandLine, FileName, ProcessCommandLine
| sort by Timestamp desc

This query detects the exact pattern from the syslog evidence: a non-root user invoking a shell (bash, sh, dash, zsh) through sudo. On a properly configured system, non-root users should never need sudo to spawn a shell — they should use sudo for the specific operation they need. A shell spawned through sudo by a non-root user is either a legitimate administrator who should be using a dedicated admin account instead, or an attacker who has escalated through a GTFOBins technique. Either case warrants investigation.

The query also serves as a baseline for expected sudo behavior. Run it over 30 days and identify every unique AccountName + DeviceName combination. The results define who uses sudo shells and on which servers. Any new combination — a user who has never previously used sudo shell access on a server, or a new server appearing in the results — is an anomaly that may indicate compromise or unauthorized access. This baseline approach is especially valuable for Linux because Linux servers tend to have stable, predictable administrative patterns — the same administrators performing the same operations on the same servers. A deviation from that pattern is a higher-confidence indicator than on Windows workstations where user behavior varies more widely.