Backdoor PAM: Pluggable Authentication Modules (T1556.003)

In un esercizio red team autorizzato la simulazione di T1556.003 richiede accesso root sul target e un lab isolato: qualsiasi modifica a PAM può bloccare l'autenticazione e rendere la macchina irraggiungibile, quindi mantenere sempre una sessione root aperta durante i test.

L'approccio più semplice è la modifica di configurazione: aggiungere una riga auth sufficient pam_permit.so in cima a /etc/pam.d/sshd fa sì che qualsiasi tentativo di autenticazione SSH sia accettato senza verifica reale delle credenziali. Il modulo pam_permit.so è fornito nativamente dal pacchetto Linux-PAM (open source) e l'effetto è immediato dopo il salvataggio del file.

Un secondo scenario, più realistico rispetto ai TTP di malware come Ebury e Skidmap, consiste nel patchare pam_unix.so. Il codice sorgente è disponibile nel repository ufficiale Linux-PAM (open source) su GitHub; si può clonarlo, modificare la funzione _unix_verify_password in modules/pam_unix/support.c per aggiungere una condizione tipo if (strcmp(p, "magic_string") == 0) return PAM_SUCCESS; e ricompilare con ./configure && make. La libreria risultante va posizionata in /lib/x86_64-linux-gnu/security/ (o /lib/security/ a seconda della distro), preservando permessi e ownership originali con chmod 644 e chown root:root.

Per la raccolta credenziali si può aggiungere codice al modulo che scrive le stringhe intercettate su un file nascosto, oppure usare progetti didattici come linux-pam-backdoor di zephrax (open source), pensato specificamente per esercitazioni di sicurezza offensiva.

Un terzo vettore riguarda i display manager: modificare /etc/pam.d/gdm-password o /etc/pam.d/lightdm estende la backdoor al login grafico. Su macOS l'equivalente sono i SecurityAgentPlugins in /Library/Security/SecurityAgentPlugins/, dove un bundle malevolo può intercettare le credenziali del loginwindow.

Per verificare l'efficacia della persistenza dopo la modifica, testare con ssh utente@target usando sia la password legittima che quella backdoor. Strumenti come auditd (open source, incluso nelle distro Linux) devono essere configurati sul lab per misurare la detection: una regola -w /etc/pam.d/ -p wa -k pam_change genera eventi utili per validare la visibilità del blue team. Il cleanup post-esercizio deve includere ripristino da backup dei file originali e verifica dell'hash SHA-256 dei moduli PAM contro pacchetti ufficiali della distribuzione tramite dpkg -V libpam-modules su Debian/Ubuntu o rpm -V pam su RHEL/CentOS.

La detection di T1556.003 si fonda su tre pilastri: monitoraggio dell'integrità dei file PAM, correlazione con eventi di autenticazione anomali e baseline comportamentale degli account.

Sul primo fronte, auditd (open source) è lo strumento di riferimento su Linux. Regole efficaci includono il monitoraggio in scrittura e cambio attributi delle directory sensibili:

-w /etc/pam.d/ -p wa -k pam_config_change -w /lib/security/ -p wa -k pam_module_change -w /lib/x86_64-linux-gnu/security/ -p wa -k pam_module_change

Gli eventi SYSCALL generati (open, openat, rename, unlink con path che matcha le directory PAM) devono confluire nel SIEM. Elastic Security, Splunk (freemium/a pagamento) o Wazuh (open source) possono correlare queste modifiche con il process ancestor: una scrittura su /lib/security/pam_unix.so originata da una shell interattiva o da un processo non appartenente al package manager (apt, dnf, yum, rpm) è altamente sospetta.

La detection AN1250 suggerisce di correlare le modifiche ai file PAM con pattern di autenticazione anomali: login multipli simultanei per lo stesso utente, accessi fuori orario, o sessioni SSH senza corrispondente traccia VPN o accesso fisico. Questa correlazione richiede una baseline per account — orari abituali, IP sorgente, frequenza — che va costruita su almeno 30 giorni di storico. I log auth.log o /var/log/secure, insieme agli eventi sshd di systemd-journald, alimentano la parte comportamentale.

Un segnale forte è l'accettazione di credenziali per utenti che normalmente non si autenticano su un dato host, o accessi SSH riusciti che non innescano voci corrispondenti in lastlog o wtmp — segno che il modulo compromesso potrebbe bypassare il logging standard. Il confronto NSM su connessioni SSH (durata, volume, orario) aiuta a isolare sessioni fuori pattern.

Su macOS la detection AN1251 punta a modifiche in /etc/pam.d/ e in /Library/Security/SecurityAgentPlugins/. Gli unified logs filtrati con log stream --predicate 'subsystem == "com.apple.opendirectoryd"' e query osquery (open source) sulle tabelle file e authorized_keys permettono monitoraggio continuo.

Sui falsi positivi: aggiornamenti legittimi del pacchetto PAM tramite gestori di pacchetti generano scritture nelle stesse directory. La whitelist deve includere i processi dpkg, apt, yum, rpm, dnf come parent legittimi, mantenendo però visibilità sulle scritture originate da shell utente, script Python/Perl o processi web server. Il tuning consigliato dai parametri AN1250 include MonitoredPaths, TimeWindow per la correlazione (raccomandato 24-72 ore) e BaselineAccounts per definire pattern attesi di login per utente e sistema.

L'analisi forense di una compromissione PAM parte dalla raccolta immediata dei moduli sospetti e dal confronto con versioni note-buone. Sul sistema live, prima dello spegnimento, catturare hash SHA-256 di tutti i file in /lib/security/, /lib/x86_64-linux-gnu/security/, /usr/lib64/security/ e dei file in /etc/pam.d/ con sha256sum. Il confronto va fatto contro gli hash forniti dal package manager: su Debian/Ubuntu con dpkg -V libpam-modules libpam-runtime, su RHEL/CentOS con rpm -V pam pam-devel. Qualsiasi discrepanza (segnalata con carattere 5 per checksum mismatch nell'output di rpm -V) è un indicatore forte di manomissione.

Gli artefatti digitali chiave includono i timestamp dei file PAM: stat /lib/security/pam_unix.so rivela mtime e ctime. Un ctime recente su un modulo PAM in assenza di aggiornamenti di sistema documentati punta a modifica manuale. Il correlato in /var/log/dpkg.log o /var/log/yum.log permette di validare se una scrittura sui moduli PAM corrisponde a un'operazione lecita del package manager.

La timeline forense va costruita con plaso/log2timeline (open source), integrando: eventi auditd con chiavi pam_config_change e pam_module_change, righe di /var/log/auth.log o /var/log/secure con accessi SSH e sudo, contenuto di utmp, wtmp, btmp (parsabili con last, lastb, utmpdump), e la history delle shell degli utenti privilegiati (~root/.bash_history, .zsh_history). L'assenza di history o un file troncato con permessi anomali è di per sé un IOC.

Per l'analisi statica del modulo sospetto, strings pam_unix.so | grep -iE 'passwd|magic|backdoor' può rivelare stringhe hardcoded caratteristiche, mentre readelf -d e nm -D mostrano symbol table e dipendenze. La differenza con un pam_unix.so pulito estratto dal pacchetto ufficiale tramite dpkg-deb -x o rpm2cpio | cpio -id è determinante: radare2 (open source) o Ghidra (open source, NSA) permettono confronto binario a livello di funzione.

Le campagne documentate offrono pattern noti. Ebury (S0377) disabilita moduli PAM per manomettere la configurazione sshd, quindi cercare voci commentate o rimosse in /etc/pam.d/sshd e configurazioni sshd_config con UsePAM no è utile. Skidmap (S0468) sostituisce direttamente pam_unix.so con una versione che accetta una password backdoor universale: l'hash del file differirà dalla versione ufficiale e strings potrebbe rivelare la password hardcoded.

Su macOS gli artefatti aggiuntivi sono in /Library/Security/SecurityAgentPlugins/ e negli unified logs persistenti in /var/db/diagnostics/, estraibili post-mortem con log show --archive. La collezione di osquery pack per file_events e process_events fornisce ulteriore contesto temporale.

Il panorama di threat intelligence su T1556.003 è dominato da malware Linux-centric progettati per persistenza server-side prolungata. I dati MITRE mappano due famiglie di riferimento — Ebury e Skidmap — che rappresentano due filosofie distinte di abuso PAM.

Ebury (S0377) è una backdoor OpenSSH attiva da oltre un decennio, associata a operazioni di credential theft su larga scala contro provider di hosting, registrar e infrastrutture accademiche. La sua peculiarità nell'abuso PAM è la disattivazione di moduli specifici per manomettere la configurazione sshd e nascondere l'attività della backdoor stessa. Ebury si integra spesso con altri componenti dell'ecosistema Operation Windigo, formando catene che combinano modifica di sshd, patch a libkeyutils, e hooking di funzioni crypto per esfiltrare credenziali SSH sia in ingresso che in uscita — trasformando un server compromesso in un nodo di raccolta credenziali che si propaga lateralmente ogni volta che un amministratore vi si connette da un'altra macchina.

Skidmap (S0468) adotta l'approccio opposto e più diretto: sostituisce integralmente pam_unix.so con una versione trojanizzata che accetta una password backdoor universale valida per qualsiasi utente locale, root incluso. Skidmap è nato come cryptominer Linux orientato al mining di Monero su server compromessi, ma la componente PAM lo trasforma in una piattaforma di accesso persistente ben oltre lo scopo iniziale di monetizzazione. La sua distribuzione mira principalmente a server esposti con credenziali deboli o vulnerabilità note non patchate.

Il pattern comune ai due software è la selezione di target Linux server-side ad alta uptime, dove la persistenza a livello di autenticazione garantisce ROI per l'attaccante misurato in mesi o anni. Non a caso T1556.003 è associata contemporaneamente a Persistence, Defense Evasion e Credential Access: un singolo impianto copre tre obiettivi tattici, riducendo la necessità di reintroduzione periodica di tooling che aumenterebbe il rischio di detection.

Dal punto di vista predittivo, il tool overlap tra Ebury e Skidmap con backdoor SSH (T1556.004) e con hijacking di libkeyutils suggerisce che un'organizzazione che rileva IOC PAM debba estendere la caccia agli altri sottotipi di T1556 e a modifiche di librerie condivise nel sistema. La convergenza tra ecosistemi cryptomining e credential harvesting osservata in Skidmap è un trend rilevante: attori inizialmente motivati economicamente evolvono verso capacità di accesso persistente rivendibili sui mercati underground come initial access per operatori ransomware o gruppi APT più sofisticati.

Le mitigazioni M1026 (Privileged Account Management) e M1032 (Multi-factor Authentication) sono complementari: MFA su SSH tramite moduli come pam_google_authenticator (open source) o Duo (freemium) neutralizza in parte l'utilità di credenziali rubate, mentre restrizioni MAC (SELinux, AppArmor, grsecurity) sui path PAM limitano la capacità stessa di modifica anche in presenza di privilegi root.

MITRE ATT&CK T1556.003 (Pluggable Authentication Modules), tattiche TA0003, TA0005, TA0006. Software S0377 (Ebury) e S0468 (Skidmap). Mitigazioni M1026, M1032. Detection DET0454 con analytics AN1250 (Linux) e AN1251 (macOS). MITRE D3FEND per artefatti digitali correlati. Alcune indicazioni operative su tool (auditd, osquery, plaso, Ghidra, radare2, Wazuh, linux-pam-backdoor) derivano da conoscenza professionale di cybersecurity su strumenti open source ampiamente adottati e documentati nei rispettivi repository ufficiali.