Chiavi SSH Persistenti: SSH Authorized Keys (T1098.004)

L'iniezione di chiavi SSH è una delle tecniche di persistenza più silenziose e, in un engagement red team, merita di essere testata su ogni superficie disponibile: server Linux, macOS, hypervisor e ambienti cloud.

Preparazione della coppia di chiavi

Il primo passo è generare una coppia di chiavi dedicata all'operazione, separata da quelle personali. Il comando classico è sufficiente:

ssh-keygen -t ed25519 -f /tmp/rt_key -P "" -C "redteam-ops"

L'algoritmo Ed25519 è preferibile per la lunghezza ridotta della chiave pubblica, che rende meno evidente l'iniezione in un file con molte entry. Il commento (-C) va scelto in modo da non destare sospetti se qualcuno ispeziona il file — in un test reale si potrebbe usare un nome coerente con l'ambiente target.

Iniezione su Linux e macOS

Una volta ottenuta una shell sul target, l'inserimento è banale:

echo "<contenuto_chiave_pubblica>" >> /home/victim/.ssh/authorized_keys

Prima di procedere, verifica che la directory .ssh esista e che i permessi siano corretti — SSH rifiuta chiavi da file con permessi troppo aperti. Se necessario:

mkdir -p /home/victim/.ssh && chmod 700 /home/victim/.ssh && chmod 600 /home/victim/.ssh/authorized_keys

Per elevare i privilegi, il target ideale è l'utente root. Controlla che in /etc/ssh/sshd_config la direttiva PermitRootLogin sia impostata su yes o prohibit-password. Se hai accesso di scrittura alla configurazione, puoi modificarla e ricaricare il servizio con systemctl reload sshd.

Superficie ESXi

Sugli hypervisor VMware ESXi il percorso è diverso e va rispettato fedelmente:

echo "<contenuto_chiave_pubblica>" >> /etc/ssh/keys-root/authorized_keys

La shell ESXi è spesso disabilitata per default. Durante un assessment, se hai accesso al vCenter o alla DCUI, abilita SSH temporaneamente per testare questa persistenza. Ricorda che ESXi ricostruisce parte del filesystem al reboot, quindi verifica la persistenza effettiva riavviando l'host.

Ambienti cloud — GCP e Azure

In Google Cloud Platform, il comando gcloud permette l'iniezione tramite metadata:

gcloud compute instances add-metadata --metadata ssh-keys=":<contenuto_chiave_pubblica>"

Su Azure, l'equivalente passa per una PATCH request all'API di gestione della VM, aggiornando il campo osProfile.linuxConfiguration.ssh.publicKeys. Strumenti come az cli (open source) semplificano l'operazione. Il punto critico per il red team è dimostrare la privilege escalation: se il proprio account cloud può modificare le metadata di una VM che gira con un service account privilegiato, l'impatto è significativo.

Dispositivi di rete

Su router e switch Cisco IOS, la sintassi prevede l'uso della modalità di configurazione:

ip ssh pubkey-chain username admin key-string <contenuto_chiave_pubblica> exit

Questa persistenza è particolarmente insidiosa perché raramente i team di sicurezza monitorano le configurazioni SSH dei dispositivi di rete con la stessa attenzione dedicata ai server.

Il rilevamento dell'iniezione di chiavi SSH richiede un approccio stratificato per superficie: endpoint Linux/macOS, hypervisor ESXi, ambienti cloud e dispositivi di rete. La sfida principale è il volume di falsi positivi, perché l'autenticazione a chiave pubblica è pratica legittima per automazioni, deploy e amministrazione remota.

Linux — auditd come fondamento

La detection più affidabile su Linux passa per auditd. La log source critica è auditd:SYSCALL, dove si intercettano le scritture al file authorized_keys. Una regola auditd mirata:

-w /home/ -p wa -k ssh_key_injection

Questa regola cattura ogni scrittura o modifica di attributi sotto le home directory. Il tuning è essenziale: correla la finestra temporale tra la scrittura al file e il lancio di processi sospetti — una soglia di 60 secondi è un buon punto di partenza. Il contesto utente è altrettanto critico: un processo root che scrive nelle authorized_keys di un utente non-root è un segnale da investigare sempre. Attenzione ai percorsi personalizzati: alcune configurazioni usano path alternativi come /etc/skel/.ssh/ per i template.

Per i falsi positivi, crea una whitelist basata su automazioni note — Ansible, Puppet, Chef — identificabili dal processo padre e dall'utente di servizio. Non filtrare mai per path generico, ma per la combinazione processo + utente + path.

macOS — Unified Log e auth

Su macOS le sorgenti sono macos:unifiedlog e macos:auth. Il focus va posto sull'albero dei processi padre: un bash o zsh che scrive nelle authorized_keys è normale se la sessione è interattiva, ma diventa sospetto se il padre è curl o un processo non-TTY. Distingui le sessioni interattive da quelle remote tramite il flag di sessione — una shell non interattiva che modifica chiavi SSH merita sempre un alert di severità alta.

Cloud IaaS — Audit log GCP e Azure

Per l'analisi cloud, la sorgente gcp:audit è la più strutturata. Cerca eventi di tipo setMetadata dove il campo metadata contiene ssh-keys. Il tuning deve distinguere tra account amministratori, service principal e utenti di automazione. Il parametro più significativo è la privilege escalation: se la chiave viene aggiunta a un account con ruolo superiore a quello del richiedente, l'alert deve essere critico.

ESXi e dispositivi di rete

Su ESXi, monitora i log della shell (esxi:shell) per qualsiasi attività di scrittura su /etc/ssh/keys-*/authorized_keys. Verifica se la shell SSH era stata abilitata in precedenza tramite DCUI o API — un'abilitazione seguita da modifica delle chiavi è un pattern ad alta confidenza. Per i dispositivi di rete, la sorgente networkdevice:cli deve intercettare il comando ip ssh pubkey-chain. Correla con il ruolo dell'utente CLI: solo account esplicitamente autorizzati alla configurazione persistente dovrebbero poter eseguire questi comandi.

Un tool raccomandato per centralizzare queste detection è Wazuh (open source), che supporta nativamente il parsing di auditd e offre regole preconfigurate per file integrity monitoring sulle authorized_keys.

La ricostruzione forense di un'iniezione SSH segue un percorso che parte dal file manipolato e risale all'intera catena di compromissione. Gli artefatti variano significativamente per superficie, ma la logica investigativa resta costante: quando è stata modificata la chiave, da quale processo, con quale utente, e cosa è successo dopo il primo login con la nuova chiave.

Artefatti Linux — il cuore dell'indagine

Il file authorized_keys stesso è l'artefatto primario. Ogni entry contiene la chiave pubblica, il tipo di algoritmo e un commento opzionale — quest'ultimo spesso rivela informazioni sull'attaccante (hostname, username, stringa custom). Confronta le chiavi presenti con quelle autorizzate dall'organizzazione: qualsiasi chiave non riconosciuta è un indicatore di compromissione.

I timestamp del filesystem sono il secondo pilastro. Con stat ottieni i tempi di accesso, modifica e cambio del file. Incrocia il timestamp di modifica di authorized_keys con i log di auditd: il campo SYSCALL registra il PID del processo che ha eseguito la scrittura, il suo UID effettivo e la riga di comando. Ricostruisci la catena: se il processo era un bash figlio di un python3 figlio di un web server, hai tracciato il vettore di ingresso.

I log di autenticazione in /var/log/auth.log (Debian/Ubuntu) o /var/log/secure (RHEL/CentOS) registrano ogni login SSH riuscito con chiave pubblica. Cerca entry di tipo Accepted publickey for <user> e correla l'IP sorgente con la timeline. Il pattern tipico è: prima appare la modifica del file, poi entro ore o giorni compare il primo login dalla chiave iniettata.

Per ricostruire una timeline completa, Plaso/log2timeline (open source) è lo strumento di riferimento. Importa i log auditd, i log auth, il filesystem timeline e i log di sshd in un'unica super-timeline, filtrando poi per path contenente .ssh.

Artefatti macOS

Su macOS, oltre ai log unificati consultabili con log show --predicate 'process == "sshd"', verifica il contenuto della directory ~/.ssh/ per chiavi non riconosciute. Il sistema di quarantena di macOS non si applica ai file creati da riga di comando, quindi non aspettarti attributi extended come com.apple.quarantine.

Artefatti ESXi

Gli hypervisor ESXi presentano una particolarità: il filesystem è parzialmente volatile. Verifica se la chiave è stata inserita anche in /etc/ssh/keys-root/authorized_keys e controlla i log shell dell'host. Se disponibile, il log di vCenter registra l'abilitazione del servizio SSH sull'host — un evento che precede l'iniezione e va incluso nella timeline.

Artefatti Cloud

In ambienti cloud, i log di audit sono la fonte primaria. Su GCP, l'evento compute.instances.setMetadata con campo ssh-keys modificato registra chi ha eseguito l'operazione, da quale IP e con quale identità. Su Azure, cerca le operazioni PATCH sulle risorse VM nel log attività. Correla con i successivi log SSH della VM per determinare se la chiave iniettata è stata effettivamente utilizzata.

Il malware Skidmap è un caso studio utile: aggiunge la chiave pubblica dei suoi operatori per mantenere persistenza dopo la compromissione — durante un'indagine, la presenza di chiavi con commenti generici o pattern noti può ricondurre a famiglie malware specifiche.

La tecnica SSH Authorized Keys è adottata da attori con profili molto diversi, accomunati dalla necessità di una persistenza silenziosa e a bassa manutenzione su infrastruttura Linux e network. I 3 gruppi documentati coprono uno spettro che va dallo spionaggio state-sponsored al cryptomining su larga scala.

Earth Lusca (G1006) è un gruppo orientato allo spionaggio che opera contro target governativi e accademici. La loro tecnica prevede il drop di una chiave SSH autorizzata nella directory /root/.ssh di server compromessi — una scelta che indica accesso root già ottenuto e l'obiettivo di mantenere un canale di rientro con privilegi massimi. L'inserimento nel percorso root suggerisce che la persistenza SSH non è il vettore iniziale ma un meccanismo di backup dopo la compromissione primaria.

Salt Typhoon (G1045) presenta un profilo particolarmente sofisticato: aggiunge chiavi SSH autorizzate sotto root o altri utenti a livello Linux dei dispositivi di rete compromessi. Questo dettaglio è significativo — non si tratta della classica iniezione su server, ma di persistenza nell'infrastruttura di rete stessa. L'accesso SSH a livello OS di router e switch consente un controllo profondo del transito dati, coerente con operazioni di intercettazione su larga scala. Il pattern geografico del gruppo punta verso operazioni di intelligence delle telecomunicazioni.

TeamTNT (G1045) rappresenta il polo opposto dello spettro: gruppo finanziariamente motivato, specializzato in cryptomining e compromissione di ambienti container e cloud. L'aggiunta di chiavi RSA nelle authorized_keys fa parte di un playbook automatizzato dove la persistenza SSH garantisce il rientro anche dopo la rimozione del miner. La semplicità dell'approccio — chiavi RSA standard — riflette un'operatività su larga scala dove l'automazione prevale sulla stealth.

Pattern operativi trasversali

Sul versante malware, le tre famiglie documentate confermano la trasversalità della tecnica. Skidmap (S0468) la usa come backdoor persistente su host infetti, XCSSET (S0658) genera la coppia di chiavi con ssh-keygen e carica la chiave privata sul server C2 per abilitare il rientro senza password — un'inversione del flusso tradizionale dove l'attaccante deposita la pubblica. Bundlore (S0482) segue un pattern simile a XCSSET: crea una nuova coppia e deposita la chiave utente nelle authorized_keys.

Un elemento di convergenza tra tutti gli attori è la preferenza per l'account root come target dell'iniezione. Questo suggerisce che la tecnica viene impiegata tipicamente dopo aver già ottenuto privilege escalation, come meccanismo di ridondanza. Per il threat intelligence, il takeaway operativo è chiaro: il monitoraggio delle authorized_keys di root e degli account di servizio ad alto privilegio è il controllo con il miglior rapporto costo-beneficio per intercettare sia attori state-sponsored che criminalità organizzata.

La proiezione futura vede un aumento dell'uso in ambienti cloud, dove le API di metadata offrono un vettore scalabile e meno presidiato rispetto all'accesso diretto al filesystem.

Framework MITRE ATT&CK: T1098.004 (SSH Authorized Keys), TA0003, TA0004 — Gruppi: G1006, G1045, G0139 — Software: S0468, S0658, S0482 — Mitigazioni: M1018, M1022, M1042. Tool di detection: auditd, Wazuh, Plaso/log2timeline. Integrato con conoscenza professionale per tool e procedure operative.