Chiavi SSH Non Autorizzate: Account Maintenance - SSH Authorized Keys (T1098.004)

Il test più basilare consiste nel generare una coppia di chiavi e aggiungerla all'account target. Su Linux, genera la chiave con:

ssh-keygen -t rsa -b 4096 -f ./persistence_key -N ""

Poi inietta la chiave pubblica nell'account vittima usando vari metodi. Il più diretto è: cat persistence_key.pub >> /home/victim/.ssh/authorized_keys

Per simulare comportamenti APT più sofisticati, modifica prima la configurazione SSH per garantire che l'autenticazione con chiave sia abilitata: sed -i 's/#PubkeyAuthentication./PubkeyAuthentication yes/' /etc/ssh/sshd_config* sed -i 's/#PermitRootLogin./PermitRootLogin yes/' /etc/ssh/sshd_config* systemctl restart sshd

In ambienti cloud, l'approccio cambia radicalmente. Su Google Cloud, usa il comando CLI per aggiungere chiavi a livello di progetto: gcloud compute project-info add-metadata --metadata-from-file ssh-keys=./malicious_keys.txt

Il file deve contenere il formato username:ssh-rsa AAAAB3.... Questo bypassa completamente il filesystem locale.

Per Azure, l'attacco richiede una richiesta PATCH all'API REST. Prima ottieni il token di accesso, poi esegui: az vm user update --resource-group TestRG --name TestVM --username azureuser --ssh-key-value "$(cat persistence_key.pub)"

Su ESXi, dopo aver abilitato la shell SSH, il percorso è diverso: mkdir -p /etc/ssh/keys-root/ echo "ssh-rsa AAAAB3..." >> /etc/ssh/keys-root/authorized_keys

I tool come XCSSET automatizzano questo processo generando chiavi al volo se non esistono. Simula questo comportamento con uno script che verifica la presenza di chiavi esistenti prima di generarne di nuove.

Per network device, il comando varia per vendor. Su Cisco IOS: ip ssh pubkey-chain username admin key-string [incolla la chiave pubblica riga per riga] exit

Il rilevamento efficace richiede monitoraggio multilivello che catturi sia le modifiche dirette ai file che gli abusi delle API cloud. Su sistemi Linux, configura auditd per tracciare ogni accesso al percorso delle chiavi SSH:

auditctl -w /home/ -p wa -k ssh_injection -F path=authorized_keys

Questo genera eventi SYSCALL quando qualsiasi processo scrive nel file. L'analisi comportamentale deve correlare la scrittura con il processo padre: è normale se proviene da ssh-copy-id, sospetto se originato da wget o curl.

Per macOS, sfrutta Unified Log per catturare modifiche sospette. Crea una query che identifichi processi non interattivi che scrivono in .ssh: log show --predicate 'process == "bash" AND eventMessage CONTAINS "authorized_keys"' --last 1h

Il vero valore sta nel correlare eventi multipli entro 60 secondi: modifica del file seguita da connessione SSH dall'esterno indica compromissione attiva.

In ambienti Google Cloud, monitora i log di audit per chiamate all'API che modificano metadati SSH. La detection rule deve catturare:

• Eventi compute.instances.setMetadata o compute.projects.setCommonInstanceMetadata
• Campo metadata.items.key contenente "ssh-keys"
• Account di servizio o utente che normalmente non gestisce SSH

Per Azure, traccia le operazioni PATCH sulle VM che modificano proprietà SSH. Eventi critici includono chiamate a Microsoft.Compute/virtualMachines/write con payload contenente chiavi SSH.

Su ESXi, la shell è normalmente disabilitata. Qualsiasi attivazione seguita da modifiche in /etc/ssh/keys-* è altamente sospetta. Monitora i log di shell per comandi che contengono questi percorsi.

I falsi positivi derivano principalmente da automation legittime. Mantieni una whitelist degli account di servizio autorizzati a modificare chiavi SSH e degli orari di manutenzione pianificata.

L'analisi forense di questa tecnica richiede la ricostruzione precisa di quando e come le chiavi sono state aggiunte. Su Linux, inizia esaminando i timestamp del file authorized_keys:

stat -c "%y %n" /home//.ssh/authorized_keys*

Confronta questi timestamp con i log di autenticazione SSH in /var/log/auth.log o /var/log/secure. Cerca pattern di accesso anomali subito dopo la modifica del file.

Gli artefatti critici includono la chiave pubblica stessa. Estrai tutte le chiavi e verifica:

• Il commento alla fine della chiave (spesso contiene username@hostname dell'attaccante)
• La data di creazione se presente nei metadati
• Hash della chiave per correlazioni cross-sistema

TeamTNT lascia tracce caratteristiche: chiavi RSA con commenti generici e spesso multiple chiavi aggiunte simultaneamente. Cerca anche modifiche a sshd_config che precedono l'injection.

Su sistemi cloud, la timeline deve includere i log delle API. In GCP, query BigQuery sui log di audit: SELECT timestamp, protoPayload.authenticationInfo.principalEmail, protoPayload.request FROM project.dataset.cloudaudit_googleapis_com_activity WHERE protoPayload.methodName = "v1.compute.projects.setCommonInstanceMetadata"

Per ESXi, esamina /var/log/shell.log per comandi eseguiti e /var/log/hostd.log per attivazioni della shell via API. Earth Lusca tipicamente droppa chiavi in /root/.ssh dopo aver elevato i privilegi.

La correlazione temporale è cruciale: mappa quando la chiave è stata aggiunta, il primo uso per login, e eventuali lateral movement successivi. Verifica anche se la stessa chiave appare su altri sistemi compromessi.

TeamTNT rappresenta il caso d'uso più basilare: aggiunge chiavi RSA standard senza particolare sofisticazione. Opera principalmente contro container Docker esposti, quindi cerca honeypot Docker per catturare le loro chiavi in uso.

Earth Lusca mostra maggiore cautela operativa. Droppa chiavi solo dopo aver ottenuto accesso root, indicando una fase post-exploitation matura. Le loro campagne targetizzano settori governativi in Southeast Asia, con persistence su server Linux critici.

Salt Typhoon eleva la tecnica attaccando network device. L'aggiunta di chiavi SSH a livello root su apparati di rete suggerisce obiettivi di intercettazione del traffico. Pattern geografici mostrano focus su provider telecom con presenza in regioni strategiche.

Il tool Skidmap automatizza l'intero processo per cryptomining. Aggiunge chiavi dei suoi handler per mantenere controllo sulla botnet anche se il malware principale viene rimosso. Bundlore su macOS genera nuove coppie di chiavi con ssh-keygen, comportamento facilmente identificabile.

XCSSET verifica l'esistenza di chiavi prima di generarne di nuove, indicando awareness delle detection. Carica anche chiavi private sul server per accesso remoto inverso, tattica avanzata.

L'overlap nei tool suggerisce condivisione di TTP tra gruppi. La generazione automatica di chiavi con commenti generici è comune. Monitora repository pubblici per chiavi compromise riutilizzate tra campagne.

I trend mostrano movimento verso abuse di cloud API invece di modifica diretta dei file. Prepara detection per metadata injection via Terraform o altri IaC tool che potrebbero essere weaponizzati.

Framework MITRE ATT&CK T1098.004 documenta dettagliatamente questa tecnica di persistence. Le campagne di TeamTNT contro Docker, Earth Lusca nel Sud-est asiatico e Salt Typhoon su network device forniscono case study reali. Detection strategies basate su auditd per Linux e API monitoring per cloud sono essenziali per identificare abuse in tempo reale.