Dirottamento Sessioni SSH: SSH Hijacking (T1563.001)

In un ingaggio red team, il dirottamento SSH parte tipicamente da un host Linux dove si è ottenuto accesso privilegiato o dove un utente legittimo ha attivato l'agent forwarding verso il proprio jump host. La prima fase consiste nel censire i socket dell'agente presenti sul sistema:

find /tmp -type s -name 'agent.' 2>/dev/null*

ls -la /tmp/ssh-*

Ogni directory /tmp/ssh-XXXXXX contiene un socket appartenente a un utente autenticato via SSH con forwarding attivo. Con privilegi root è possibile impostare la variabile d'ambiente SSH_AUTH_SOCK per puntare al socket della vittima e successivamente elencare le chiavi caricate:

export SSH_AUTH_SOCK=/tmp/ssh-XXXXXX/agent.NNNN

ssh-add -l

Se l'agente contiene chiavi valide, un semplice ssh utente@target-interno userà quelle chiavi senza richiedere password, aprendo una connessione autenticata come l'utente originale. Questa è la vera essenza dell'hijacking: non serve estrarre la chiave privata, basta usare il canale già negoziato.

Esiste anche la variante di hijacking del ControlMaster: se la vittima ha configurato in ~/.ssh/config opzioni come ControlPath e ControlPersist, ogni nuova connessione riutilizza il canale multiplexato esistente. Un attaccante con accesso al socket di controllo può aprire nuove sessioni sulla connessione già autenticata:

ssh -S /home/vittima/.ssh/cm-target target hostname

Sul piano tooling da laboratorio, ssh-mitm (open source) permette di simulare scenari di intercettazione e session hijacking in ambienti controllati per esercizi di consapevolezza. Il framework Empire e Metasploit (open source) includono moduli post-exploitation per l'enumerazione di sessioni SSH attive e dei socket dell'agente. Per l'analisi statica di configurazioni SSH pericolose, Lynis (open source) evidenzia rapidamente forwarding abilitato, permessi lassi su ~/.ssh e configurazioni ControlMaster persistenti.

Un red teamer maturo evita di generare rumore: preferisce operazioni idempotenti che riproducono il comportamento dell'utente legittimo (stessi orari, stessi target, stesse dimensioni di sessione), documentando ogni pivot per la successiva fase di reporting. Il valore dimostrativo dell'esercizio sta nel provare al cliente che un singolo endpoint compromesso può, tramite agent forwarding non necessario, esporre l'intero perimetro amministrativo interno.

Il rilevamento del dirottamento SSH è complesso perché la tecnica riutilizza canali legittimi e chiavi valide. La strategia di detection DET0256 si concentra su tre pilastri: accesso incrociato ai socket dell'agente, attività laterale SSH senza corrispondenti eventi di autenticazione, e anomalie nell'uso di $SSH_AUTH_SOCK.

Su Linux (analitica AN0710), la telemetria principale arriva da auditd. Vanno monitorati i syscall connect verso path che matchano /tmp/ssh-*/agent.* e gli eventi EXECVE di processi che leggono socket appartenenti a UID diversi dal proprio. Una regola auditd utile intercetta l'accesso a socket dell'agente:

-a always,exit -F arch=b64 -S connect -F dir=/tmp -k ssh_agent_access

La correlazione critica è temporale: se osservate connessioni SSH in uscita da un host verso sistemi interni senza corrispondenti eventi di successo in /var/log/auth.log sull'host stesso (perché la sessione è stata stabilita riutilizzando l'agente di un altro utente), avete un forte indicatore. Analogamente, gli eventi sshd[PID]: Accepted publickey sui sistemi destinazione senza traffico interattivo giustificato dall'utente proprietario della chiave meritano approfondimento.

Su macOS (analitica AN0711), la sorgente è il unified log. Filtrate su processi che aprono file descriptor verso /private/tmp/com.apple.launchd.*/Listeners o socket in /tmp/ssh-* con predicati come process != "ssh" AND eventMessage CONTAINS "SSH_AUTH_SOCK". Stabilite una baseline degli utenti che usano SSH agent e delle directory dei socket monitorate (parametri di tuning BaselineUsers e SocketPathScope) per ridurre il rumore.

A livello di Network Security Monitoring, strumenti come Zeek (open source) e Suricata (open source) permettono di tracciare flussi SSH interni: un host che improvvisamente apre connessioni SSH verso segmenti che non contatta abitualmente, in finestre temporali strette e senza precedente autenticazione locale, è un candidato per triage prioritario.

I falsi positivi principali derivano da tool di orchestrazione (Ansible, Salt, script di deployment) che aprono molte sessioni SSH in rapida successione riutilizzando lo stesso agente. La mitigazione passa da whitelist di account di servizio e di jump host noti. Un altro pattern benigno da modellare è l'uso di tmux o screen con connessioni persistenti, che possono generare accessi ripetuti al socket dell'agente da parte dello stesso utente.

L'integrazione con SIEM (Splunk, Elastic Security, QRadar) dovrebbe correlare eventi auditd di accesso al socket con connessioni sshd successive entro finestre di 60-120 secondi, alzando alert solo quando l'UID del processo consumatore differisce da quello proprietario del socket.

L'analisi forense di un dirottamento SSH richiede di ricostruire una catena di eventi in cui una connessione autenticata è stata riutilizzata da un attore diverso dal proprietario legittimo delle chiavi. Il primo elemento da acquisire è il contenuto di /var/log/auth.log (Debian/Ubuntu) o /var/log/secure (RHEL/CentOS), dove sshd registra le sessioni accettate con orario, IP sorgente e metodo di autenticazione. Confrontate ogni evento Accepted publickey con la presenza dell'utente reale sulla workstation di origine nello stesso momento: una discrepanza è oro forense.

Gli artefatti chiave su Linux sono i seguenti:

• Socket dell'agente in /tmp/ssh-*/agent.*: durante l'incident response live è cruciale annotare owner, timestamp di creazione e processi che li hanno aperti (via lsof -U o ss -x).
• File di history: ~/.bash_history, ~/.zsh_history degli utenti coinvolti mostrano i comandi ssh eseguiti, ma attenzione: se l'attaccante ha esportato HISTFILE=/dev/null, l'evidenza potrebbe mancare.
• File ~/.ssh/known_hosts: nuovi fingerprint di host aggiunti in orari sospetti indicano nuove destinazioni contattate dal pivot.
• Log auditd in /var/log/audit/audit.log, se abilitato con regole su syscall connect e execve, forniscono la timeline granulare.
• Configurazioni ControlMaster: ~/.ssh/config e file in ~/.ssh/cm-* rivelano canali multiplexati riutilizzabili.

Su macOS le sorgenti equivalenti sono il unified log (interrogabile via log show --predicate 'process == "sshd"' --last 24h) e i database FSEvents in /.fseventsd/, utili per identificare la creazione dei socket temporanei anche dopo la loro rimozione.

La timeline ideale ricostruisce cinque momenti: (1) autenticazione iniziale legittima dell'utente vittima con forwarding attivo, (2) compromissione dell'host intermedio o escalation a root, (3) accesso al socket dell'agente da parte del processo malevolo, (4) connessione outbound verso il sistema target, (5) attività post-exploitation sul target. Strumenti come plaso/log2timeline (open source) e Timesketch (open source) sono ideali per aggregare log di più host in una vista unificata.

Sulle destinazioni, verificate gli eventi sshd Accepted publickey for X from IP-jump correlandoli con l'attività applicativa successiva (accessi a database, esecuzioni di sudo, modifica di file critici). Nei casi in cui il malware MEDUSA sia sospettato, cercate binari eseguibili con capacità di sniffing SSH nelle directory scrivibili dagli utenti e nelle unit systemd non standard. Preservate memory dump con AVML (open source) o LiME (open source) per estrarre chiavi in-memory e strutture dell'agente prima del reboot.

I dati MITRE ATT&CK non associano attualmente gruppi APT specifici alla tecnica T1563.001, il che riflette una realtà interessante: il dirottamento delle sessioni SSH è raramente attribuito in modo esplicito nei report pubblici, perché lascia tracce sottili e viene spesso classificato genericamente come "movimento laterale via SSH" o "uso di credenziali valide". L'unico artefatto tooling formalmente mappato è il malware MEDUSA (S1220), che integra la capacità di catturare credenziali SSH proprio attraverso hijacking delle sessioni, indicando che la tecnica è entrata nel bagaglio operativo di famiglie di malware moderne orientate al furto credenziali.

Dal punto di vista strategico per un Threat Intelligence Officer, la tecnica ha caratteristiche che ne fanno un target di interesse per attori con obiettivi di persistenza a lungo termine in ambienti Linux e macOS: infrastrutture cloud, ambienti DevOps con jump host, cluster Kubernetes gestiti via SSH, sistemi di CI/CD. Le organizzazioni che espongono maggiormente la superficie sono quelle con cultura ingegneristica marcata, dove l'agent forwarding viene lasciato abilitato per comodità e i jump host non vengono trattati con lo stesso rigore delle workstation amministrative.

Il pattern operativo che emerge dall'analisi tecnica è coerente con attori che privilegiano stealth e living-off-the-land: nessun binario custom da droppare per la fase di pivot, riuso di strumenti nativi, sessioni indistinguibili dal traffico amministrativo legittimo. Questo profilo si sposa bene con gruppi di espionage di livello statale interessati a esfiltrazione persistente da ambienti tecnologici, così come con gruppi di ransomware avanzati che devono muoversi rapidamente in reti Linux prima di lanciare l'encryption di massa.

Un indicatore predittivo utile è il grado di adozione di certificati SSH di breve durata e di soluzioni Zero Trust per l'accesso amministrativo: le organizzazioni che restano su modelli tradizionali di chiavi statiche con agent forwarding non ristretto rappresentano target a più alta probabilità di successo per questa tecnica. La compresenza di MEDUSA o altri stealer credenziali in un ambiente dovrebbe elevare immediatamente la priorità del threat model verso lo scenario di hijacking.

Le mitigazioni prioritarie dai dati MITRE (M1022, M1026, M1027, M1042) convergono su un tema unico: ridurre la superficie del socket dell'agente. Disabilitare ForwardAgent nei client SSH quando non strettamente necessario, impedire il login SSH come root, applicare password forti alle chiavi private e restringere permessi su ~/.ssh/ sono le contromisure ad alto ROI. Chi valuta il rischio residuo dovrebbe correlare il livello di enforcement di queste mitigazioni con la presenza di jump host multi-tenant come indicatore composito di esposizione.

MITRE ATT&CK: tecnica T1563.001, tattica TA0008, software S1220 (MEDUSA), mitigazioni M1022, M1026, M1027, M1042, strategia di detection DET0256 con analitiche AN0710 (Linux) e AN0711 (macOS). Framework difensivo MITRE D3FEND per le tecniche di detection e hardening correlate a SSH agent socket. Il contenuto integra conoscenza professionale di cybersecurity per comandi operativi, tool open source citati (auditd, Zeek, Suricata, Lynis, plaso, AVML, LiME) e configurazioni SSH standard.