Gli aggressori possono trasformare gli agenti AWS SSM in trojan di accesso remoto

I ricercatori di Mitiga hanno documentato una nuova tecnica post-sfruttamento che gli aggressori possono utilizzare per ottenere un accesso remoto persistente alle istanze AWS Elastic Compute Cloud (EC2) (server virtuali), nonché alle macchine non EC2 (ad esempio, server aziendali locali e server virtuali). macchine e VM in altri ambienti cloud).

Il successo di questa tecnica di “vivere della terra” dipende da:

"Dopo aver controllato l'Agente SSM, gli aggressori possono svolgere attività dannose, come il furto di dati, crittografare il filesystem (come un ransomware), utilizzare in modo improprio le risorse dell'endpoint per il mining di criptovaluta e tentare di propagarsi ad altri endpoint all'interno della rete, il tutto con il pretesto di di utilizzare un software legittimo, l’Agente SSM”, hanno spiegato i ricercatori di Mitiga Ariel Szarf e Or Aspir.

I ricercatori hanno provato due diversi scenari e il livello di accesso richiesto per entrambi è elevato. Nel primo scenario, l'autore della minaccia richiede l'accesso root sulla macchina Linux presa di mira o i privilegi di amministratore sul sistema Windows preso di mira, mentre nel secondo deve essere in grado di funzionare almeno come utente con privilegi non root sulla macchina Linux presa di mira o come amministratore su il sistema Windows di destinazione.

“[Nel primo scenario], l'attacco sta 'dirottando' il processo originale dell'Agente SSM registrando l'Agente SSM per funzionare in modalità 'ibrida' con un account AWS diverso, costringendolo a non scegliere il server di metadati per il consumo dell'identità. Quindi, l’agente SSM comunicherà ed eseguirà i comandi dell’aggressore sull’account AWS di proprietà”, hanno spiegato.

Nel secondo scenario, l'aggressore esegue un altro processo di Agente SSM utilizzando gli spazi dei nomi Linux o impostando variabili di ambiente specifiche su Windows. "Il processo dell'agente dannoso comunica con l'account AWS dell'aggressore, lasciando che l'agente SSM originale continui a comunicare con l'account AWS originale."

E se l'autore della minaccia preferisce non utilizzare un account AWS per gestire gli agenti, non è obbligato a farlo: esiste una funzionalità SSM di cui si può abusare per instradare il traffico SSM a un server controllato dall'aggressore (ovvero, non attraverso i server AWS ).

Trasformare l'Agente SSM in un trojan di accesso remoto consente agli aggressori di compromettere gli endpoint senza essere individuati dalle soluzioni di sicurezza installate. Le comunicazioni C&C sembrano legittime, non è necessario sviluppare un'infrastruttura di attacco separata e l'Agente SSM può essere utilizzato per manipolare l'endpoint tramite funzionalità supportate.

Il fatto che l’agente SSM sia preinstallato su alcune popolari Amazon Machine Images e sia quindi già installato e in esecuzione su molte istanze EC2 esistenti amplia il pool di potenziali bersagli per gli avversari, hanno sottolineato i ricercatori.

Fortunatamente, ci sono modi per rilevare l’uso di questa tecnica. Includono: tenere d'occhio i nuovi ID di istanza, l'uso di comandi specifici, connessioni perse con gli agenti SSM nell'account AWS, nuovi processi e azioni sospette relative a Sessions Manager nei log di Amazon CloudTrail.

I ricercatori consigliano agli amministratori di sistema aziendali di:

“Crediamo fermamente che gli autori delle minacce ne approfitteranno negli attacchi nel mondo reale, se non lo fanno già. Per questo motivo, comprendere e mitigare i rischi associati al suo uso improprio è fondamentale per proteggere i sistemi da questa minaccia in evoluzione", hanno osservato, sottolineando che il team di sicurezza di AWS ha anche offerto una soluzione per limitare la ricezione di comandi dall'AWS originale. account/organizzazione utilizzando l'endpoint Virtual Private Cloud (VPC) per Systems Manager.

“Se le tue istanze EC2 si trovano in una sottorete privata senza accesso alla rete pubblica tramite un indirizzo EIP pubblico o un gateway NAT, puoi comunque configurare il servizio System Manager tramite un endpoint VPC. In questo modo, puoi garantire che le istanze EC2 rispondano solo ai comandi provenienti dai principali all'interno del loro account o organizzazione AWS originale. Per implementare questa restrizione in modo efficace, fare riferimento alla documentazione della policy VPC Endpoint.