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

Dal punto di vista offensivo, l'iniezione di una chiave in authorized_keys è una delle azioni post-exploitation più economiche e affidabili su sistemi Unix-like. Una volta ottenuto un shell come utente target, la sequenza minima è generare localmente una coppia con ssh-keygen -t ed25519 -f ./implant_key -N "" e poi appendere la parte pubblica sul bersaglio.

Su Linux/macOS il pattern tipico è:

mkdir -p ~/.ssh && chmod 700 ~/.ssh echo "ssh-ed25519 AAAA... attacker@op" >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys

I permessi restrittivi sono fondamentali: sshd rifiuta il file se world-writable. Per rendere l'operazione silenziosa in red team, è buona prassi conservare il timestamp originale con touch -r /etc/passwd ~/.ssh/authorized_keys per non alterare l'mtime della directory .ssh.

Su ESXi il path cambia: le chiavi vanno in /etc/ssh/keys-root/authorized_keys e l'SSH service va abilitato via vim-cmd hostsvc/enable_ssh o dalla DCUI. Verifica sempre prima con chkconfig --list | grep -i ssh per capire lo stato del servizio.

Negli scenari cloud la superficie si sposta sulle API di controllo. Su GCP, se le credenziali compromesse hanno il ruolo compute.instanceAdmin, un red teamer può eseguire:

gcloud compute instances add-metadata VM_NAME --metadata-from-file ssh-keys=keys.txt --zone=ZONE

dove keys.txt contiene una riga nel formato username:ssh-rsa AAAA... user. Su Azure, l'endpoint REST virtualMachines/{name} accetta un PATCH sul blocco osProfile.linuxConfiguration.ssh.publicKeys — l'equivalente CLI è az vm user update con --ssh-key-value.

Per emulazione controllata delle TTP dei gruppi documentati, Atomic Red Team (open source) include test per T1098.004 che riproducono l'append della chiave e il fingerprint del comportamento di TeamTNT. Per esercizi più realistici su cloud, Stratus Red Team di DataDog (open source) offre l'attacco aws.persistence.iam-backdoor-user e scenari GCP analoghi.

Catena tipica in un'operazione: initial access via exploit web → escalation locale → drop di chiave in /root/.ssh/authorized_keys (pattern osservato in Earth Lusca) → pivoting laterale via SSH usando la chiave come credenziale valida. Per il pivoting, sshuttle (open source) o il classico ssh -D 1080 permettono di trasformare l'accesso in tunnel SOCKS senza deployare implant aggiuntivi.

La detection di T1098.004 richiede visibilità simultanea su filesystem, processi e — negli ambienti moderni — control plane cloud. La strategia DET0126 di MITRE articola cinque analitiche per piattaforma; il minimo comune denominatore è correlare scrittura sul file authorized_keys con contesto di processo anomalo.

Su Linux, la fonte primaria è auditd. Una regola efficace intercetta ogni write su path che matchano .ssh/authorized_keys:

-w /root/.ssh/authorized_keys -p wa -k ssh_persistence -a always,exit -F arch=b64 -S open,openat,truncate -F path=/home -F success=1 -k ssh_home

Per coprire tutti gli utenti in modo scalabile, auditd supporta path glob limitati; in alternativa Falco (open source, CNCF) offre la regola built-in Write below etc estendibile con un macro dedicato a .ssh. La chiave analitica è la user-to-process correlation: root che scrive nell'authorized_keys di un utente non-root, oppure processi con parent sh -c originato da un web server (nginx, apache) sono segnali forti.

Su macOS, l'Unified Logging System (accessibile via log stream --predicate 'subsystem == "com.openssh.sshd"') traccia le sessioni SSH ma non gli edit al file. Serve affiancare ESF (Endpoint Security Framework) — sfruttabile via strumenti come Crescendo (open source) o soluzioni EDR commerciali — per catturare eventi ES_EVENT_TYPE_NOTIFY_WRITE sul path. Il segnale ad alta confidenza è la scrittura da parte di shell non interattiva (parent = curl | bash, osascript, LaunchAgent sospetto).

In ambienti IaaS, la telemetria si sposta sui log del control plane. Su GCP, i Cloud Audit Logs registrano v1.compute.instances.setMetadata e v1.compute.projects.setCommonInstanceMetadata: filtrare protoPayload.request.items.key = "ssh-keys" isola il caso d'uso. Su Azure, l'Activity Log espone Microsoft.Compute/virtualMachines/write — l'analisi del body JSON per la presenza di publicKeys sotto linuxConfiguration è il segnale corretto. Su AWS, l'analogo è ec2:ModifyInstanceAttribute con chiave userData modificata a runtime.

Su ESXi, il log /var/log/shell.log traccia i comandi eseguiti nella shell dell'hypervisor; correlare l'abilitazione di SSH via vim-cmd con successive modifiche a /etc/ssh/keys-* chiude il ciclo. Su network devices Cisco, il comando ip ssh pubkey-chain genera eventi AAA/TACACS+ che vanno inoltrati al SIEM.

I falsi positivi tipici sono legati a Ansible, Terraform e tool di configuration management che legittimamente distribuiscono chiavi. La mitigazione è baseline: whitelist degli account di automazione (SPN, service account) e alerting solo sulle write da fuori il perimetro CI/CD.

L'analisi forense di una compromissione via authorized_keys si costruisce attorno a tre pilastri: il file stesso, le tracce di scrittura e le sessioni SSH successive che ne hanno fatto uso.

Il primo artefatto è il contenuto di authorized_keys. Ogni riga contiene tipo di chiave, materiale pubblico, e — cruciale per l'analisi — un commento finale che tipicamente riporta user@host di chi l'ha generata. Nei casi reali, gruppi come TeamTNT hanno lasciato comment stringhe riconoscibili; Salt Typhoon, che ha operato su apparati di rete Linux-based, ha iniettato chiavi negli account root e in altri account privilegiati. Confrontare i fingerprint (ssh-keygen -lf authorized_keys) con eventuali chiavi legittime inventariate dall'organizzazione permette di isolare rapidamente le entry sospette.

Sul filesystem Linux, i timestamp del file (accessibili via stat) forniscono ancore temporali. L'mtime segna l'ultima scrittura, il ctime l'ultima modifica di inode/permessi. Se l'attaccante ha manipolato i timestamp con touch -r, il ctime rimane comunque veritiero perché non è direttamente settabile da userspace senza chiamate a utimensat con privilegi. Anche il journal ext4 (analizzabile con debugfs o plaso/log2timeline, open source) può conservare tracce di scritture recenti.

Se auditd era attivo, i log in /var/log/audit/audit.log (o inoltrati al SIEM) contengono le syscall open/openat con PID, PPID, UID e comm del processo scrivente. Correlare con /var/log/auth.log — o journalctl -u ssh su sistemi systemd — permette di ricostruire quali sessioni SSH abbiano poi utilizzato la chiave: le entry Accepted publickey for from port ssh2: SHA256: legano l'accesso alla chiave specifica.

Su macOS, il file si trova nella stessa posizione (~/.ssh/authorized_keys). L'analisi va integrata con le quarantine extended attributes (xattr -l) e con il database FSEvents (/.fseventsd/), parsabile con FSEventsParser (open source) per ricostruire eventi di creazione/modifica sulla directory .ssh. Il malware XCSSET documentato da MITRE genera chiavi con ssh-keygen -t rsa -f $HOME/.ssh/id_rsa -P e uploada la privata al C2 — traccia rilevabile confrontando le chiavi presenti con eventuale traffico egress verso IP non noti. Bundlore segue lo stesso pattern per abilitare remote login.

Su ESXi, oltre a /etc/ssh/keys-<user>/authorized_keys, sono rilevanti /var/log/shell.log, /var/log/hostd.log (per l'abilitazione del servizio SSH) e /var/log/auth.log. Il malware Skidmap ha usato la tecnica su Linux server per persistere iniettando chiavi degli handler.

In cloud, gli artefatti sono API-side: CloudTrail su AWS, Activity Log su Azure, Admin Activity audit logs su GCP. Estrarre body request e identity del principal chiudono la timeline dalla modifica metadata fino al primo login SSH riuscito sulla VM.

L'abuso di authorized_keys è trasversale a threat actor con motivazioni molto diverse — dal cybercrime al cyberespionage state-sponsored — proprio per la sua semplicità e per la copertura offerta dal comportamento amministrativo legittimo.

TeamTNT (G0139) è il caso paradigmatico nel dominio cloud/container. Attivo dal 2019, il gruppo è specializzato in campagne di cryptojacking che colpiscono ambienti Docker/Kubernetes esposti e istanze AWS/GCP mal configurate. L'iniezione di chiavi RSA in authorized_keys è parte della loro toolchain standard di persistence, spesso combinata con harvest di credenziali cloud dalle instance metadata. Il pattern è massivo e opportunistico: scan Internet-wide, exploit di Docker API esposte, drop di chiave e miner.

Earth Lusca (G1006), tracciato da Trend Micro, è un attore con probabile nesso cinese focalizzato su cyberespionage verso obiettivi in Asia, Australia ed Europa. A differenza di TeamTNT opera in modo mirato: dopo la compromissione di un server, deposita una chiave SSH direttamente in /root/.ssh, ottenendo persistence al massimo livello di privilegio. Il gruppo mostra sovrapposizioni infrastrutturali con altri cluster cinesi come Winnti e utilizza toolkit ibridi (Cobalt Strike, ShadowPad) accanto a strumenti custom.

Salt Typhoon (G1045) rappresenta l'evoluzione più recente e allarmante: attribuito a un attore nation-state cinese, il gruppo ha condotto operazioni di ampio respiro contro operatori telco e infrastrutture di rete. L'uso documentato consiste nell'aggiunta di chiavi SSH negli account root o privilegiati a livello Linux di dispositivi di rete compromessi — un vettore particolarmente pericoloso perché questi apparati raramente hanno EDR e i log sono spesso volatili o non centralizzati.

Sul fronte malware, tre famiglie mappate mostrano tre approcci distinti. Skidmap (S0468) è un rootkit Linux con moduli kernel-level per cryptojacking: la persistence via SSH key è complementare al rootkit stesso, come fallback in caso di rimozione dei moduli. Bundlore (S0482) e XCSSET (S0658) sono invece minacce macOS: entrambi generano una nuova coppia di chiavi con ssh-keygen e depositano la pubblica in authorized_keys, ma XCSSET aggiunge l'esfiltrazione della chiave privata al C2 — trasformando la macchina in un asset accessibile on-demand dall'operatore.

Il trend osservabile combina tre vettori. Nel cloud, l'abuso avviene sempre più via API di metadata (add-metadata di GCP, PATCH REST di Azure) invece che via filesystem, spostando la detection dal piano host al control plane. Sui network device, l'uso di ip ssh pubkey-chain sta emergendo come pattern di persistence enterprise-grade. Su ESXi, la crescita dei ransomware che colpiscono hypervisor (Akira, Play, BlackBasta nel panorama recente) rende plausibile una futura adozione più ampia della tecnica sui path /etc/ssh/keys-<user>/. Le mitigazioni MITRE M1018, M1022 e M1042 — user account management, restrizione dei permessi sul file e disabilitazione dei servizi non necessari — restano contromisure di base ma richiedono enforcement continuo tramite configuration management e file integrity monitoring.

MITRE ATT&CK T1098.004 (SSH Authorized Keys), tattiche TA0003 e TA0004. Gruppi: G0139 TeamTNT, G1006 Earth Lusca, G1045 Salt Typhoon. Software: S0468 Skidmap, S0482 Bundlore, S0658 XCSSET. Mitigazioni M1018, M1022, M1042. Detection strategy DET0126 (analitiche AN0350-AN0354). MITRE D3FEND per artefatti e controlli difensivi. Le sezioni operative integrano conoscenza professionale su tool open source (auditd, Falco, Atomic Red Team, Stratus Red Team, plaso, FSEventsParser, sshuttle) e sintassi CLI di gcloud, az e OpenSSH verificabili nella documentazione ufficiale dei rispettivi progetti.