In che modo il ransomware influisce sui dati aziendali cloud
Il ransomware è un reato a scopo di lucro che mira a paralizzare i sistemi aziendali e a ottenere il pagamento di un riscatto. Storicamente, il riscatto dei dati presenti nei tradizionali carichi di lavoro aziendali on-premise e nei sistemi governativi ha portato a ingenti guadagni finanziari per gli autori degli attacchi ransomware. Con cloud moderni sistemi digitali, le organizzazioni stanno ora cercando di determinare se il ransomware possa influenzare i carichi di lavoro cloud nella stessa misura, e si chiedono inoltre se "ci sarà una pressione evolutiva sugli autori degli attacchi che li costringerà a evolvere le loro tattiche".
Alla luce delle recenti osservazioni sulle tendenze relative cloud e alla migrazione dei dati, la mia conclusione è la seguente: non vedo come il ransomware NON possa diventare un problema sempre più grave per le aziende a livello globale.
La mia tesi su questo argomento può essere sintetizzata semplicemente così: ovunque si trovino dati critici, lì arriverà il ransomware. Quando i dati aziendali risiedono nel Cloud, anziché, ad esempio, in un database locale, per gli hacker è economicamente vantaggioso evolvere le proprie tattiche per prendere di mira cloud con gli stessi obiettivi dei sistemi locali.
Il presente documento ha lo scopo di illustrare le strategie che un malintenzionato cloud adottare nell'ambiente cloud per compromettere la disponibilità dei dati utilizzando gli strumenti forniti dal fornitore Cloud (CSP). Oltre ai comportamenti degli aggressori, ho delineato misure proattive per proteggere cloud che forniscono servizi crittografici, modelli architetturali volti a semplificare la protezione di tali sistemi e metodi per individuare il ransomware cloud.
Minacce alla disponibilità nel Cloud
I primi dieci anni e più di cloud hanno visto un'accelerazione delle cloud e l'archiviazione di set di dati sempre più voluminosi su questa cloud. Pur assistendo a questo cambiamento, spesso continuiamo a considerare il ransomware esclusivamente nel contesto degli ambienti on-premise, estendendo ingenuamente tali concetti al cloud.
Nel cloud, gli strumenti di cui sviluppatori e clienti hanno bisogno per svolgere le attività quotidiane sono integrati e offerti come funzionalità dai fornitori cloud . Una volta ottenuto l'accesso, gli stessi strumenti e le stesse funzionalità vengono spesso utilizzati da malintenzionati per eludere i controlli di sicurezza, evitare di essere individuati e raggiungere obiettivi specifici. L'uso di queste funzionalità con intenti malevoli viene spesso definito "abuso delle funzionalità".
L'accessibilità dei servizi cloud tramite API rende facile per gli hacker abusarne, o meglio, utilizzarli in modo improprio.
Le API create da ciascun fornitore di servizi cloud (CSP) sono facilmente individuabili e possono essere rapidamente comprese e sfruttate in modi non previsti. L'abuso delle funzionalità rappresenta un rischio aggiuntivo rispetto alle vulnerabilità del codice. A differenza dello sfruttamento di una vulnerabilità, in questo caso non esiste un difetto nel codice da manipolare che possa essere individuato tramite il confronto con modelli prestabiliti o risolto con l'applicazione di patch. Gli autori delle minacce sfruttano invece gli strumenti forniti dal CSP, utilizzati per l'implementazione o la manutenzione del software e dell'infrastruttura di produzione, per compiere azioni illecite.
Qualunque sia l'ambiente in cui si trovino, gli autori delle minacce sfrutteranno gli strumenti a loro disposizione per portare a termine i propri scopi malevoli. In un certo senso, abusando delle API pubbliche, il ransomware nel cloud la tendenza del "Living off the Land", dove i "LOL Binaries" del Cloud proprio le sue API, ricche di funzionalità e pubbliche. A differenza degli eseguibili di Windows, che possono essere disinstallati come software superflui, cloud AWS sono sempre attive. L'esposizione, l'accesso e la disponibilità continuano a fornire l'apertura richiesta dai servizi e aprono la strada a devastanti attacchi ransomware.
Dove sono ospitati Cloud tuoi Cloud ?
Per comprendere le tecniche di attacco che gli autori dei ransomware potrebbero utilizzare, è necessario innanzitutto conoscere i sistemi in cui vengono archiviati i dati. I dati in locale sono solitamente conservati su diverse piattaforme tecnologiche, dai database Oracle ai server Microsoft SQL. Ciò che accomuna questi sistemi è il fatto di essere host fisici, interamente sotto il vostro controllo.
I server di data warehouse on-premise sono solitamente host fisici implementati in un ambiente full-stack che costituiscono facili bersagli per malware dell'ampia superficie di attacco. Tuttavia, gli ambienti full-stack traggono vantaggio dall'essere protetti da solide strategie di protezione dei dati, che impiegano controlli di sicurezza evolutisi negli ultimi 20 anni di modellazione delle minacce basate sulla rete. Di conseguenza, i database tradizionali on-premise sono nascosti dietro livelli di controlli di rete, confinati nei meandri più remoti delle reti aziendali e sottoposti a un monitoraggio intensivo tramite sistemi di rilevamento delle minacce basati su agenti.
L'approccio on-premise alla protezione degli archivi di dati tradizionali non è applicabile al cloud, né dovrebbe esserlo. I dati migrati nel cloud in sistemi in cui tutti gli utenti finali, compresi gli autori di attacchi, dispongono di un accesso limitato e controllato al sistema sottostante. Ciò significa che gli archivi cloud presentano superfici di attacco nettamente diverse.
Ciascuno dei principali fornitori cloud (ad esempio AWS, Azure, GCP) dispone di una propria versione di un archivio dati distribuito, altamente disponibile e versatile: AWS S3, Azure Blob Storage e GCP Storage Buckets. Ognuno di essi costituisce un archivio fondamentale per i dati non strutturati ed è un servizio onnipresente, stabile e altamente disponibile che si integra con molti altri servizi sulle rispettive piattaforme, soddisfacendo praticamente qualsiasi esigenza di archiviazione dati dei clienti. Cloud utilizzano i servizi di archiviazione per creare pipeline e fungono da archivio dati di supporto per le piattaforme di big data o da repository pubblici per i contenuti web.
Se sei un cliente AWS, è difficile NON utilizzare S3. Il che lo rende un probabile bersaglio degli autori di ransomware cloud
Strategia tradizionale di crittografia del ransomware
Il ransomware che prende di mira i sistemi on-premise utilizza uno schema di crittografia ibrido, che sfrutta i vantaggi sia della crittografia simmetrica che di quella asimmetrica, per aggirare i limiti diciascuna1.
Le limitazioni sono le seguenti:
Mentre le operazioni di crittografia asimmetrica sono lente, la crittografia dei dati con una chiave simmetrica è veloce!
La crittografia simmetrica utilizza la stessa chiave sia per la crittografia che per la decrittografia. Una strategia puramente simmetrica spesso lascia la chiave di decrittografia sul sistema, facilitando il recupero da parte delle squadre di analisi forense.
Le strategie adottate dagli autori di ransomware per aggirare queste limitazioni sono le stesse tecniche utilizzate dai team di crittografia interni. Che sia per scopi benevoli o malevoli, le gerarchie di chiavi possono essere utilizzate per ricavare un insieme di chiavi da un altro e quindi crittografare le chiavi simmetriche dei dati.
Il ransomware che prende di mira i sistemi on-premise utilizza uno schema di crittografia ibrido, che sfrutta i vantaggi sia della crittografia simmetrica che di quella asimmetrica.
Combinando la crittografia simmetrica e quella asimmetrica, gli autori dei ransomware possono raggiungere una serie di obiettivi più complessi.
Maggiore velocità nell'esecuzione delle operazioni di crittografia > Poiché il ransomware prende di mira i dati protetti da chiavi simmetriche, spesso riesce a portare a termine l'attacco prima che i sistemi di difesa abbiano il tempo di reagire.
L'offuscamento del materiale della chiave simmetrica ostacola il recupero durante l'analisi post-esploitazione. > Crittografando la chiave simmetrica dei dati con una chiave asimmetrica, il recupero del materiale della chiave risulta difficile, se non impossibile, per i professionisti della scienza forense.
Per i sistemi di crittografia on-premise è necessario sviluppare malware eseguire tecniche di crittografia complesse. Tuttavia, questa strategia di crittografia rischia di rivelarsi macchinosa e del tutto superflua quando si prendono di mira i dati nel cloud. Nel presente documento vengono illustrati i metodi che un aggressore potrebbe utilizzare, sfruttando gli strumenti offerti dai fornitori cloud e rendendo obsolete le tecniche tradizionali di ransomware.
Crittografia degli oggetti S3 con chiavi KMS controllate dall'autore dell'attacco
I fornitori Cloud hanno svolto il lavoro più impegnativo per garantire la sicurezza delle radici di fiducia ai propri clienti che utilizzano i loro servizi crittografici. Gli hacker possono approfittare di queste comodità per compromettere la disponibilità dei dati cloud.
AWS Key Management Service (AWS KMS) consente ai propri clienti di generare chiavi, controllarne l'accesso e utilizzarle per eseguire operazioni crittografiche quali la firma, la verifica e la gestione del processo di crittografia dell'involucro richiesto per la crittografia lato server (SSE) di S3.
Quando non si utilizza KMS, gli oggetti crittografati su S3 vengono crittografati con una chiave AmazonMaster. Quando un soggetto autorizzato richiede l'accesso a un oggetto in questo bucket, AWS decrittografa i dati in modo trasparente in background. Anziché consentire ad AWS di generare e gestire le chiavi di supporto SSE, i clienti possono utilizzare una chiave KMS e avvalersi della policy basata sulle risorse associata alla chiave come ulteriore livello di controllo degli accessi sui dati crittografati. La possibilità di applicare una policy e limitare l'accesso a una chiave lascia uno spiraglio agli aggressori per compromettere la disponibilità dei dati crittografati con la chiave.
Per illustrare il ruolo di KMS nell'SSE, si consideri il primo scenario riportato di seguito, in cui un operatore di ransomware ottiene un accesso esteso a S3 e KMS all'interno di un account AWS. L'autore dell'attacco può leggere, copiare ed eliminare oggetti da S3, oltre ad acquisire le autorizzazioni necessarie per creare una nuova chiave KMS. Lo scenario descrive inoltre come un autore dell'attacco potrebbe sfruttare tale accesso per compromettere la disponibilità dei dati e richiedere un riscatto per il loro ripristino.
Scenario: Dimostrazione di un ransomware Cloud su S3
Lo scenario descritto prevede che un autore di minacce prenda di mira i dati contenuti nel bucket denominato, in modo appropriato, "victim-bucket". Su questo bucket è abilitata la crittografia lato server (SSE), che prevede che gli oggetti vengano crittografati in modo trasparente con una chiave master gestita da Amazon (SSE-S3). Un utente finale a cui è concesso solo l'accesso per recuperare oggetti (azione s3:GetObject) da questo bucket avrebbe permessi sufficienti per scaricare il testo in chiaro degli oggetti memorizzati. Non sono richiesti permessi aggiuntivi per decrittografare gli oggetti quando sono crittografati con una chiave master gestita da Amazon.
In questo scenario, ipotizziamo che un malintenzionato abbia compromesso un utente finale con l'intento di ricattarlo per ottenere un riscatto. Il malintenzionato ha creato un nuovo bucket S3 che chiameremo "staging-bucket", che utilizzerà come zona di raccolta per i dati S3 mirati. Il "staging-bucket" appena creato richiede inoltre che gli oggetti caricati siano crittografati, ma con una chiave KMS. Abbiamo generato la chiave KMS in AWS e l'abbiamo archiviata in un HSM AWS, quindi ci siamo affidati a una policy gestita dal cliente per applicare il controllo degli accessi alla chiave.
Durante la migrazione dei dati dal "victim-bucket" allo "staging-bucket", gli oggetti vengono crittografati nuovamente con la chiave KMS appena creata. L'accesso agli oggetti è regolato dalle autorizzazioni associate agli oggetti S3 e alla chiave KMS. Ci si deve aspettare risposte di accesso negato quando le richieste provengono da chiamanti che non dispongono di autorizzazioni esplicite per accedere sia agli oggetti S3 che alla chiave KMS. Se un utente finale ha un'autorizzazione esplicita di "negazione" sull'oggetto S3 o sulla chiave KMS, ci si deve aspettare che anche le richieste di accesso vengano negate.
A questo punto, il nostro aggressore fittizio ha creato le condizioni per un attacco ransomware trasferendo gli oggetti S3 in un nuovo archivio dati e crittografandoli nuovamente con chiavi sotto il proprio controllo. Il passo successivo in questa scenario prevede di compromettere l'accesso alla chiave necessaria per le operazioni crittografiche, come la decrittografia.
Blocco tramite chiave di politica -«NEGARE, tranne quando; CONSENTIRE, solo quando»
La tecnica che consente di impedire a un cliente AWS l'accesso a una chiave KMS ospitata nel proprio account è stata descritta per la prima volta da Spencer Geitzen al Cloud del DEFCON nel2020.
Vediamo come potrebbe presentarsi un aggiornamento dannoso di una politica chiave.
NEGARE – tutte le operazioni sulla chiave KMS – tranne nel caso in cui la chiave di condizione“aws:sourceIp”corrisponda all’IP controllato dall’autore dell’attacco.
CONSENTI – tutte le operazioni sulla chiave KMS — solo se il richiedente proviene da un account controllato dall'autore dell'attacco.
Questo tipo di gergo politico incentrato sulle risorse può essere sintetizzato come:«NEGARE, tranne quando; CONCEDERE, solo quando».
È facile immaginare altre condizioni che potrebbero essere sfruttate da un operatore di ransomware intenzionato a utilizzare questo schema. Richiedere che la chiamata provenga da un indirizzo IP di origine specifico costituisce di fatto un meccanismo per limitare tutte le attività su una chiave; tuttavia, altrettanto efficace potrebbe essere l'uso delle seguenti condizioni relative alle chiavi globali di AWS:
aws:PrincipalArn
aws:AccountPrincipale
aws:sourceVPC
aws:SourceVPCe
Qualsiasi situazione in cui il chiamante richieda un valore univoco controllato dall'autore dell'attacco può essere sfruttata per impedire a un cliente AWS l'accesso alle proprie risorse.
Quando si aggiorna una politica basata sulle risorse associata alla chiave KMS secondo lo schema «NEGATO, tranne quando; CONSENTITO, solo quando», l'account della vittima viene di fatto escluso dall'accesso ai propri dati appena crittografati. Nemmeno l'utente root è in grado di accedere ai dati crittografati su S3.
Solo le richieste provenienti dall'account AWS controllato dall'autore dell'attacco e da un indirizzo IP controllato dall'autore dell'attacco sarebbero in grado di accedere alla chiave KMS e decriptare i dati S3.
La pulizia finale a seguito di un attacco ransomware cloud comporterebbe l'eliminazione del "victim-bucket" originale e il caricamento di una richiesta di riscatto su un nuovo bucket non crittografato.
Chiavi KMS esistenti
Escludere una vittima da una chiave KMS non è l'unico modo per compromettere la disponibilità di S3. Tuttavia, è uno dei meccanismi più interessanti da analizzare per un ricercatore nel campo della sicurezza.
Questa tecnica non si limita alle nuove chiavi KMS. Per compromettere la disponibilità agendo su una chiave KMS esistente, l'autore dell'attacco avrebbe bisogno di autorizzazioni ancora più limitate. L'aggiornamento di una politica relativa a una chiave KMS esistente al fine di limitarne l'accesso per le operazioni crittografiche avrebbe lo stesso effetto devastante sulla disponibilità dei dati che si otterrebbe ricrittografando i dati S3 con una nuova chiave creata dall'autore dell'attacco.
In entrambi gli scenari precedenti, l'accesso alla chiave simmetrica utilizzata nella crittografia lato server (SSE-KMS) viene ostacolato da malintenzionati attraverso la manipolazione della politica relativa alle chiavi.
Quando è la vittima a pagare
Non possiamo presumere di sapere come sarebbe se una banda di autori di ransomware cloud decidesse di cedere il controllo della chiave di decrittazione dei dati, come avviene nel caso del ransomware tradizionale on-premises. Nel cloud, il processo di "consegna delle chiavi" dei dati crittografati avrà un aspetto diverso, pur rimanendo una componente necessaria del ciclo di vita del ransomware. Dopotutto, il prodotto che il ransomware fornisce al suo consumatore è un meccanismo per recuperare i dati crittografati. Come qualsiasi altra attività commerciale, gli operatori di ransomware hanno bisogno di un mezzo affidabile e sicuro per fornire i prodotti ai loro "clienti".
Nel primo scenario, solo gli utenti che effettuano chiamate dall'account dell'autore dell'attacco possono accedere alla chiave KMS necessaria per decriptare i dati critici per l'azienda, ma l'aggiornamento della politica delle chiavi è un'operazione che un autore dell'attacco non può eseguire tra account diversi. Pertanto, un meccanismo affidabile e in tempo reale per restituire il controllo alla vittima non può comportare un aggiornamento della politica delle chiavi. Piuttosto, una banda di ransomware potrebbe rivolgere la propria attenzione alle concessioni di chiavi, un meccanismo alternativo di controllo degli accessi per le chiavi KMS utilizzato per delegare le autorizzazioni per le operazioni crittografiche.
Una concessione di chiaveKMS³ consiste nella delega di autorizzazioni a un destinatario, che restituisce un token utilizzato per eseguire operazioni crittografiche su quella chiave. Creando una concessione di chiave e consentendo all'account della vittima di utilizzare la chiave sottratta per la decrittografia, la banda di ransomware può effettivamente ripristinare la disponibilità dei dati per i propri "clienti" paganti, aggirando le restrizioni imposte dalla politica di limitazione delle chiavi. Una concessione di chiave KMS consentirebbe alla vittima di accedere alla chiave KSM e avviare il processo di recupero dei propri dati crittografati.
AWS potrebbe proteggerti da un attacco ransomware Cloud?
Alla luce di quanto esposto in precedenza, quando ci si trova ad affrontare un attacco ransomware in un ambiente cloud-native, è opportuno riflettere su come si inserisca in questo contesto il “modello di responsabilità condivisa”. Di seguito sono riportate alcune considerazioni che vale la pena approfondire.
Il primo scenario previsto per un intervento di AWS ipotizza che AWS possa accedere al materiale delle chiavi KMS da un HSM di AWS. Questa ipotesi è talmente inverosimile da sembrare del tutto fuori dal regno delle possibilità. È impensabile che AWS possa recuperare una chiave KMS da uno dei propri HSM ospitati nei propri data center. AWS ha fatto di tutto per garantire che nessuno potesse recuperare il materiale delle chiavi e ha rilasciato dichiarazioni pubbliche in tal senso.
Gli altri due scenari possibili in caso di intervento da parte di AWS sono molto più incerti. La prima possibilità di assistenza comporterebbe una modifica dell'ambiente della vittima da parte di AWS. Non vi sono prove che AWS sia in grado di annullare una politica relativa alle chiavi applicata in modo doloso nell'account di una vittima, ripristinando l'accesso a una chiave KMS. Non vi è alcuna indicazione che disponga di poteri "divini" sulle politiche basate sulle risorse. Inoltre, se anche fosse così, non avrebbe molti motivi per ammetterlo pubblicamente.
L'ultima opzione di intervento assistito da prendere in considerazione prevede che AWS assuma il controllo dell'account utilizzato dagli autori degli attacchi. Il team Trust and Safety di AWS metterà in quarantena e chiuderà gli account non autorizzati che ha riscontrato violare i termini di servizio, come quelli utilizzati nelle campagne Botnet. Tuttavia, mettere in quarantena e chiudere gli account è molto diverso dall'assumere il controllo delle risorse, cosa che sarebbe necessaria per riprendere il controllo di una chiave KMS dirottata. Sebbene non sia chiaro se AWS disponga di una procedura per assumere il controllo degli account, vi sono alcune prove che suggeriscono che sia così.
AWS dispone di un meccanismo che consente di modificare l'indirizzo e-mail principale di un account. Ciò risulta particolarmente utile nel caso in cui si dimentichi la password dell'utente principale e si perda l'accesso all'indirizzo e-mail ad esso associato. Il supporto tecnico di AWS richiederà di fornire un'attestazione autenticata della titolarità dell'account prima di apportare qualsiasi modifica all'account e-mail principale sottostante. Questa procedura interna suggerisce che AWS abbia il potere di assumere il controllo degli account, non solo di chiuderli, ma anche di accedere alle risorse in essi contenute con privilegi amministrativi.
Come nel caso della teoriadella "mano di Dio", AWS ha ben pochi motivi per rendere pubblica la propria capacità di confiscare gli account. Dal punto di vista dei responsabili della sicurezza, in assenza di una procedura chiaramente documentata per il recupero assistito da parte di AWS, corredata da accordi sul livello di servizio (SLA) garantiti, l'assistenza teorica offerta da AWS non è di alcuna utilità. La pianificazione della risposta e del ripristino a seguito di un attacco ransomware non dovrebbe basarsi sull'aiuto di AWS né si dovrebbe fare affidamento su di esso.
Prevenzione, individuazione e risposta al ransomware Cloud
Partendo dalla consapevolezza che è improbabile che AWS possa fornire assistenza in caso di attacco ransomware, concentriamo la nostra attenzione sugli elementi fondamentali di qualsiasi programma di sicurezza: i controlli preventivi e le capacità di rilevamento e risposta.
SCP: limitazione delle chiavi KMS
Le misure di mitigazione tramite la Service Control Policy (SCP) richiedono un certo grado di maturità nel vostro programma cloud , ma ciò non significa che il loro utilizzo non debba essere un obiettivo operativo. La creazione di una politica su misura per le chiavi KMS richiede di capire quali chiavi debbano essere autorizzate a eseguire operazioni crittografiche sui vostri dati e chi debba avervi accesso.
Una politica di controllo dei servizi (SCP) che indichi le chiavi KMS specifiche autorizzate a crittografare gli oggetti potrebbe rappresentare un buon punto di partenza per prevenire un attacco ransomware cloud del tipo descritto in questo documento. Limitare le operazioni crittografiche a chiavi specifiche impedirebbe a un malintenzionato di crittografare in modo dannoso oggetti S3 utilizzando una chiave appena creata o una chiave esterna sotto il proprio controllo, senza però poter dirottare la politica di una chiave esistente e approvata.
Spesso questo tipo di SCP è abbinato a un modello architettonico che raggruppa tutte le chiavi KMS in un unico account. Dovrebbe essere il modello di progettazione preferito, non solo per garantire la resilienza contro il ransomware, ma anche per tutti i vantaggi offerti dalla centralizzazione, quali la tracciabilità e la semplificazione della rotazione delle chiavi.
L'adozione di questo approccio centralizzato alla gestione delle chiavi, simile al sistema di "Fort Knox", comporta il rischio di "mettere tutte le uova nello stesso paniere". Consente inoltre di adottare un approccio in cui "tutti i controlli di sicurezza sono concentrati in un unico punto". Un account centrale di gestione delle chiavi permette a un'organizzazione di sicurezza di applicare il principio del privilegio minimo nel senso più rigoroso del termine, stabilire una linea di riferimento per i normali modelli di utilizzo delle chiavi e monitorare le transazioni anomale.
Configurazioni dei bucket S3
Non tutti i bucket S3 possono essere configurati come "fortezze", ma vale la pena sottolineare che i controlli disponibili in S3 possono contribuire alla strategia complessiva di resilienza contro il ransomware.
Blocco oggetto: una configurazione applicata a un bucket S3 che impedisce la cancellazione di un oggetto o di una sua versione.
Controllo delle versioni degli oggetti: questa impostazione impone la creazione di nuovi oggetti, anziché sovrascrivere quelli caricati in precedenza. Se combinata con l’opzione "Blocco oggetti", questa impostazione può impedire che gli oggetti vengano sovrascritti con versioni crittografate in modo dannoso. Quando il controllo delle versioni è abilitato, assicurati di impostare delle politiche per gestire il ciclo di vita degli oggetti sottoposti a controllo delle versioni.
MFA Delete: garantisce che il bit MFA sia impostato sul token di sessione del richiedente quando si tenta di eliminare un oggetto da S3. Anche in questo caso, questi controlli potrebbero risultare incompatibili con dati altamente transazionali, ma potrebbero essere una soluzione praticabile quando si desidera proteggere i backup sensibili. Sapere quali dati si possiedono e dove sono archiviati è un prerequisito fondamentale per applicare qualsiasi misura di mitigazione a livello di bucket.
Rilevamento dei ransomware Cloud
Il presente documento illustra due possibili strategie che un autore di minacce potrebbe adottare per compromettere la disponibilità dei dati ospitati su S3. Il nostro autore di minacce fittizio ha utilizzato un metodo di blocco delle politiche delle chiavi per compromettere la disponibilità di una nuova chiave KMS. Si rileva inoltre la possibilità di applicare lo stesso modus operandi a una chiave esistente, oppure di crittografare in modo doloso i dati S3 utilizzando una chiave KMS esterna, ospitata in un account controllato dall'autore dell'attacco. Esaminiamo ciascuno degli scenari per discutere quali eventi nel vostro CloudTrail potrebbero giustificare un'indagine da parte dei vostri responsabili della risposta agli incidenti.
Blocco della politica delle chiavi con una nuova chiave
Se un autore di minacce ricorre a questa tecnica, vi sono due aspetti critici che potrebbero essere segnalati e ai quali si potrebbe reagire durante la fase di sfruttamento, quando si rileva l’uso di una nuova chiave KMS e si acquisiscono gli eventi relativi all’aggiornamento della politica delle chiavi. Se la vostra organizzazione ha una visione chiara di quali chiavi debbano essere utilizzate per la crittografia, l'uso di chiavi KMS non approvate dovrebbe far scattare un allarme. Inoltre, l'aggiornamento della politica delle chiavi per includere una delle chiavi di condizione globali menzionate in questo documento dovrebbe anche giustificare un approfondimento.
Blocco della politica delle chiavi con la chiave esistente
Un autore di attacchi potrebbe decidere di concentrare i propri sforzi sul compromesso di una chiave KMS esistente. Ciò riduce notevolmente le possibilità di rilevamento durante la fase di sfruttamento. Tuttavia, è possibile creare avvisi personalizzati che segnalino l'aggiornamento della politica relativa alle chiavi per includere una delle chiavi di condizione globali menzionate nel presente documento, il che potrebbe indicare che si è verificato un attacco ransomware cloud.
Crittografia con chiave KMS esterna
Sebbene questo scenario non sia descritto in dettaglio nel presente documento, rimane comunque un meccanismo plausibile per la crittografia dolosa dei dati. I team addetti alla sicurezza vorrebbero essere avvisati quando vengono eseguite operazioni di crittografia con chiavi KMS che non sono ospitate in un account sotto il loro controllo.
In conclusione
I fornitori Cloud mettono a disposizione strumenti crittografici che, se non adeguatamente protetti, possono essere sfruttati dalle bande di ransomware per compromettere la disponibilità dei dati nel cloud. Una campagna di ransomware di successo nel cloud servizi cloud per crittografare i dati con rapidità e meccanismi di controllo degli accessi integrati per impedire alla vittima l'accesso ai dati aziendali critici.
La definizione di modelli architetturali centralizzati per la gestione delle chiavi rappresenta il primo passo per prevenire il ransomware cloud. La gestione centralizzata delle chiavi consente sia una prevenzione più efficace del ransomware, sia una visione più coerente di come si presenta un modello crittografico normale nel proprio cloud .
Sebbene un approccio preventivo sia l'ideale, è improbabile che la maggior parte delle organizzazioni disponga di tali controlli architetturali sin dal primo giorno. Inoltre, spetta a ogni organizzazione, anche a quelle con ambienti altamente restrittivi, pianificare il giorno in cui le proprie misure di protezione dovessero fallire. Pertanto, individuare se i dati cloud siano stati colpiti da un ransomware dovrebbe essere la priorità assoluta. Queste strategie di rilevamento varieranno leggermente a seconda della tecnica utilizzata dall'autore della minaccia, ma si basano sul concetto di sapere cosa si intende per "esterno" nel proprio cloud , che si tratti del monitoraggio della concessione di accessi esterni, dell'utilizzo di chiavi esterne o di condizioni specificate nelle politiche.
