Ransomware Cloud: come gli attacchi alla disponibilità sfruttano cloud

In che modo il ransomware influisce sui dati aziendali cloud

Il ransomware è un crimine a scopo di lucro che ha come obiettivo quello di bloccare i sistemi aziendali e ottenere il pagamento di un riscatto. Storicamente, il riscatto dei dati residenti nei tradizionali carichi di lavoro aziendali on-premise e nei sistemi governativi ha portato a ingenti guadagni finanziari per gli aggressori che utilizzano attacchi ransomware. Con l'espansione cloud dei 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 stanno inoltre chiedendo se "ci sarà una pressione evolutiva sugli aggressori 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 POTREBBE diventare un problema ancora più grave per le aziende globali.

La mia tesi su questo argomento può essere riassunta semplicemente così: ovunque si trovino dati critici, lì arriverà il ransomware. Quando i dati aziendali risiedono nel Cloud, piuttosto che, ad esempio, in un database locale, per gli aggressori è finanziariamente vantaggioso evolvere le loro tattiche per prendere di mira cloud con gli stessi obiettivi dei sistemi locali.

Questo documento serve a delineare i percorsi che un malintenzionato nel cloud seguire per compromettere la disponibilità dei dati utilizzando gli strumenti forniti dal Cloud Provider (CSP). Oltre ai comportamenti degli aggressori, ho delineato misure proattive per proteggere cloud che forniscono servizi crittografici, modelli architetturali per facilitare la protezione di questi sistemi e metodi per rilevare il ransomware cloud.

Attaccare la 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ù grandi nel cloud. Anche se assistiamo a questo cambiamento, spesso continuiamo a pensare al ransomware esclusivamente nel contesto degli ambienti on-premise, estendendo ingenuamente tali concetti al cloud.

Nel cloud, gli strumenti disponibili 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 aggirare i controlli di sicurezza, evitare il rilevamento e raggiungere obiettivi specifici. L'uso di queste funzionalità con intenti illeciti viene spesso definito abuso delle funzionalità.

L'apertura dei servizi cloud tramite API rende facile per gli aggressori abusare, o meglio utilizzare in modo improprio, gli strumenti per gli stessi.

Le API create da ciascun 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à, non esiste un difetto nel codice che possa essere manipolato e che possa essere rilevato tramite il pattern matching o protetto tramite 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 trovano, gli autori delle minacce sfrutteranno gli strumenti a loro disposizione per portare a termine i loro compiti illeciti. 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 le sue API, ricche di funzionalità e pubbliche. A differenza degli eseguibili di Windows che possono essere disinstallati come software superfluo, 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 abuso che gli operatori di ransomware potrebbero utilizzare, è necessario innanzitutto comprendere i sistemi in cui vengono archiviati i dati. I dati on-premise vengono solitamente archiviati su diverse tecnologie, dai database Oracle ai server Microsoft SQL. Ciò che questi sistemi hanno in comune è che sono host fisici, completamente sotto il vostro controllo.

I server di data warehouse on-premise sono comunemente host fisici implementati in un ambiente full-stack che costituiscono facili bersagli per malware dell'ampia superficie di attacco. Tuttavia, gli ambienti full-stack beneficiano della protezione offerta da solide strategie di protezione dei dati, che impiegano controlli di sicurezza sviluppati negli ultimi 20 anni di modellizzazione delle minacce basate sulla rete. Pertanto, i database tradizionali on-premise sono nascosti dietro livelli di controlli di rete, confinati nei meandri delle reti aziendali e sottoposti a un monitoraggio intensivo con rilevamento delle minacce basato su agenti.

L'approccio on-premise alla protezione degli archivi dati tradizionali non è applicabile al cloud, né dovrebbe esserlo. I dati migrati al cloud in sistemi in cui tutti gli utenti finali, compresi gli attori malintenzionati, hanno un accesso limitato e controllato al sistema sottostante. Ciò significa che gli archivi cloud hanno superfici di attacco notevolmente diverse.

Ciascuno dei principali fornitori cloud (ad esempio AWS, AZURE, GCP) dispone di una versione unica di un archivio dati distribuito, altamente disponibile e multiuso: AWS S3, Azure Blob Storage e GCP Storage Buckets. Ciascuno di essi è un archivio centrale per dati non strutturati e rappresenta un servizio onnipresente, stabile e altamente disponibile che si integra con molti altri servizi sulle rispettive piattaforme, soddisfacendo quasi tutte le esigenze 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 dei ransomware

Il ransomware che prende di mira i sistemi locali utilizza uno schema di crittografia ibrido, sfruttando il meglio della crittografia simmetrica e asimmetrica, per aggirare i limiti di^ciascuna1.

Limiti:

• 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 dei team forensi.

Le strategie utilizzate 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 set di chiavi da un altro e quindi crittografare le chiavi di dati simmetriche.

Combinando la crittografia simmetrica e asimmetrica, gli autori di ransomware possono raggiungere una serie di obiettivi più complessi.

• Maggiore velocità nell'esecuzione delle attività di crittografia
  > Prendendo di mira i dati con chiavi simmetriche, il ransomware spesso riesce a completare lo sfruttamento prima che le capacità difensive abbiano la possibilità di rispondere.
• L'offuscamento del materiale della chiave simmetrica ostacola il recupero durante l'analisi post-sfruttamento.
  > Criptando 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.

La creazione di malware eseguire tecniche di crittografia complesse è necessaria per i crittografi on-premise. Tuttavia, questa strategia di crittografia rischia di essere macchinosa e del tutto superflua quando si prendono di mira i dati nel cloud. In questo documento vengono descritti 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 un lavoro impegnativo per mantenere radici di fiducia sicure per i propri clienti che utilizzano i loro servizi crittografici. Gli aggressori possono sfruttare 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 delle buste richiesto per la crittografia lato server S3 (SSE).

Quando non si utilizza KMS, gli oggetti crittografati su S3 vengono crittografati con una chiave AmazonMaster. Quando una parte autorizzata richiede l'accesso a un oggetto in questo bucket, AWS decrittografa i dati in modo trasparente in background. Invece di consentire ad AWS di generare e gestire le chiavi di supporto SSE, i clienti possono utilizzare una chiave KMS e sfruttare la politica basata sulle risorse associata alla chiave come ulteriore livello di controllo dell'accesso ai dati crittografati. La possibilità di applicare criteri e limitare l'accesso a una chiave lascia uno spazio agli aggressori per compromettere la disponibilità dei dati crittografati con la chiave.

Per dimostrare il ruolo di KMS in SSE, si consideri lo scenario uno riportato di seguito, in cui un operatore ransomware ottiene un accesso significativo a S3 e KMS in un account AWS. L'autore dell'attacco può leggere, copiare ed eliminare oggetti da S3, oltre ad ottenere le autorizzazioni per creare una nuova chiave KMS. Lo scenario descrive inoltre come un autore dell'attacco potrebbe utilizzare l'accesso per compromettere la disponibilità dei dati e richiedere un riscatto per il loro ripristino.

Scenario: dimostrazione di ransomware Cloud su S3

Lo scenario descritto prevede che un autore di minacce prenda di mira i dati contenuti nel bucket denominato "victim-bucket". Su questo bucket è abilitata la crittografia lato server (SSE), che specifica che gli oggetti vengono 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 autorizzazioni sufficienti per scaricare il testo in chiaro degli oggetti archiviati. Non sono necessarie autorizzazioni aggiuntive 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 trattenere i dati per chiedere un riscatto. Il malintenzionato ha creato un nuovo bucket S3 che chiameremo "staging-bucket", che utilizzerà come zona di atterraggio per i dati S3 mirati. Il "staging-bucket" appena creato richiede anche che gli oggetti caricati siano crittografati, ma con una chiave KMS. Abbiamo generato la chiave KMS in AWS e l'abbiamo archiviata in un AWS HSM, quindi ci siamo affidati a una politica gestita dal cliente per applicare il controllo degli accessi alla chiave.

Durante la migrazione dei dati dal "bucket vittima" al "bucket di staging", gli oggetti vengono nuovamente crittografati con la chiave KMS appena creata. Le autorizzazioni associate agli oggetti S3 e alla chiave KMS determinano l'accesso agli oggetti. È possibile che vengano restituite 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 dispone di un'autorizzazione esplicita di "negazione" sull'oggetto S3 o sulla chiave KMS, è possibile che anche le richieste di accesso vengano negate.

A questo punto, il nostro attore malintenzionato fittizio ha preparato il terreno per un attacco ransomware migrando gli oggetti S3 in un nuovo datastore e ricriptandoli con chiavi sotto il proprio controllo. Il passo successivo in questa narrazione consiste nell'influenzare l'accesso alla chiave per le operazioni crittografiche, come la decrittografia.

Blocco delle politiche chiave - "NEGARE, tranne quando; CONSENTIRE, solo quando"

La tecnica di bloccare un cliente AWS da una chiave KMS ospitata nel proprio account è stata descritta per la prima volta da Spencer Geitzen al Cloud al DEFCON nel²⁰²⁰².

Vediamo come potrebbe presentarsi un aggiornamento dannoso alla politica chiave.

• DENY – tutte le azioni sulla chiave KMS, tranne quando la chiave di condizione "aws:sourceIp"è uguale all'IP controllato dall'autore dell'attacco.
• CONSENTI – tutte le azioni sulla chiave KMS — solo quando il chiamante proviene dall'account controllato dall'autore dell'attacco.

Questo tipo di gergo politico basato sulle risorse può essere definito come: "NEGARE, tranne quando; CONSENTIRE, solo quando".

È possibile immaginare altre condizioni sfruttate da un operatore ransomware che intende utilizzare questo modello. Richiedere che il chiamante provenga da un IP di origine specifico è in effetti un meccanismo per limitare tutte le attività su una chiave, ma altrettanto efficace potrebbe essere l'uso delle seguenti condizioni chiave globali AWS:

• aws:Arn principale
• aws:AccountPrincipale
• aws:sourceVPC
• aws:SourceVPCe

Qualsiasi condizione in cui il chiamante richieda un valore unico e controllato dall'autore dell'attacco può essere sfruttata per bloccare l'accesso di un cliente AWS alle proprie risorse.

Quando si aggiorna una politica basata sulle risorse associata alla chiave KMS al modello "DENY, except when; ALLOW, only when" (NEGARE, tranne quando; CONSENTIRE, solo quando), l'account della vittima viene effettivamente bloccato dai propri dati appena crittografati. Anche l'utente root non è in grado di accedere ai dati S3 crittografati.

Solo i chiamanti provenienti dall'account AWS controllato dall'autore dell'attacco dall'IP controllato dall'autore dell'attacco sarebbero in grado di accedere alla chiave KMS e decrittografare i dati S3.

La pulizia finale da un attacco ransomware cloud includerebbe l'eliminazione del "bucket delle vittime" originale e il caricamento di una richiesta di riscatto su un nuovo bucket non crittografato.

Chiavi KMS esistenti

Bloccare una vittima da una chiave KMS non è l'unico modo per influire sulla disponibilità di S3. Tuttavia, è uno dei meccanismi più interessanti da modellare per un ricercatore di sicurezza.

Questa tecnica non è limitata alle nuove chiavi KMS. Per influire sulla disponibilità agendo su una chiave KMS esistente, l'autore della minaccia avrebbe bisogno di autorizzazioni ancora più limitate. L'aggiornamento di una politica di chiavi KMS esistente per limitarne l'accesso alle operazioni crittografiche avrebbe lo stesso effetto debilitante 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) è tenuto in ostaggio da malintenzionati attraverso la manipolazione della politica delle chiavi.

Quando la vittima paga

Non possiamo presumere di sapere come sarebbe per una banda di ransomware cloud rinunciare al controllo della chiave di decrittazione dei dati basata su un ransomware tradizionale on-premise. Nel cloud, il processo di "consegna delle chiavi" per i dati crittografati sarà diverso, anche se rimarrà una componente necessaria del ciclo di vita del ransomware. Dopo tutto, il prodotto che il ransomware fornisce al 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 propri "clienti".

Nel primo scenario, solo i chiamanti dall'account dell'autore dell'attacco possono accedere alla chiave KMS necessaria per decrittografare i dati aziendali critici, ma l'aggiornamento della politica delle chiavi è un'azione 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} chiave^KMS3 è una delega di autorizzazioni a un beneficiario 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 dirottata per la decrittografia, la banda di ransomware può effettivamente restituire la disponibilità ai propri "clienti" paganti, aggirando le restrizioni imposte dalla politica di chiave vincolata. 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 delle considerazioni precedenti, quando ci si trova di fronte a un attacco ransomware in un ambiente cloud-native, è ragionevole riflettere su come si applica il "modello di responsabilità condivisa". Di seguito sono riportate alcune considerazioni che vale la pena esaminare.

Il primo scenario per un intervento da parte di AWS ipotizza che AWS possa accedere al materiale delle chiavi KMS da un HSM AWS. Questa ipotesi è talmente improbabile da sembrare completamente 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 in cui AWS potrebbe intervenire sono molto più incerti. La prima possibilità di assistenza consisterebbe nella modifica dell'ambiente della vittima da parte di AWS. Non ci sono prove che AWS sia in grado di annullare una politica chiave applicata in modo dannoso in un account vittima, ripristinando l'accesso a una chiave KMS. Non vi è alcuna indicazione che AWS abbia poteri illimitati sulle politiche basate sulle risorse. Inoltre, non vi è alcun incentivo ad ammettere pubblicamente tale capacità, se esistesse.

L'ultima opzione di rimedio assistito da prendere in considerazione sarebbe quella di far requisire da AWS l'account utilizzato dagli autori delle attività dannose. 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 dal prendere 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, alcune prove suggeriscono che sia così.

AWS dispone di un meccanismo che consente di modificare l'indirizzo e-mail principale di un account. Questo meccanismo entra in funzione nel caso in cui l'utente dimentichi la password dell'account principale e perda l'accesso all'indirizzo e-mail associato a tale account. Il supporto AWS richiederà all'utente di fornire un'attestazione autenticata della titolarità dell'account prima di apportare modifiche all'account e-mail principale sottostante. Questo processo interno suggerisce che AWS ha il potere di assumere il controllo degli account, non solo di chiuderli, ma anche di accedere alle risorse in essi contenute con funzionalità amministrative.

Come nel caso della teoriadella "mano di Dio", AWS ha pochi incentivi a pubblicizzare la propria capacità di confiscare gli account. Dal punto di vista dei difensori, senza un processo chiaramente documentato per il recupero assistito da AWS con accordi sul livello di servizio garantiti, l'assistenza teorica di AWS non è utile. La pianificazione della risposta e del recupero da un evento ransomware non dovrebbe essere incentrata sull'aiuto di AWS e non dovrebbe essere prevista.

Prevenzione, rilevamento e risposta al ransomware Cloud

Partendo dal presupposto che è improbabile che AWS possa essere d'aiuto in caso di attacco ransomware, rivolgiamo la nostra attenzione agli elementi fondamentali di tutti i programmi di sicurezza, ovvero i controlli preventivi e le capacità di rilevamento e risposta.

SCP Limitazione delle chiavi KMS

Le mitigazioni tramite Service Control Policy (SCP) richiedono un certo grado di maturità nel programma cloud , ma ciò non significa che il loro utilizzo non debba essere un obiettivo operativo. La creazione di una policy personalizzata per le chiavi KMS richiede la comprensione di quali chiavi devono essere autorizzate a eseguire operazioni crittografiche sui dati e chi deve avere accesso ad esse.

Una politica di controllo dei servizi (SCP) che indichi le chiavi KMS specifiche consentite per crittografare gli oggetti potrebbe essere 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 aggressore di crittografare in modo dannoso gli oggetti S3 con una chiave appena creata o una chiave esterna sotto il proprio controllo, ma non di 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 un modello di progettazione preferibile non solo per la resilienza al ransomware, ma anche per tutti i vantaggi che la centralizzazione comporta, come la verificabilità e la semplificazione della rotazione delle chiavi.

L'utilizzo di questo approccio centralizzato "Fort Knox" alla gestione delle chiavi crea un modello in cui "tutte le uova sono nello stesso paniere". Consente inoltre di adottare un approccio in cui "tutti i controlli di sicurezza sono nello stesso paniere". Un account centrale di gestione delle chiavi consente a un'organizzazione di sicurezza di applicare il principio del privilegio minimo nel senso più rigoroso, stabilire una linea di base per i normali modelli di utilizzo delle chiavi e monitorare le transazioni anomale.

Configurazioni bucket S3

Non tutti i bucket S3 possono essere configurati come fortezze, ma vale la pena notare i controlli disponibili in S3 che possono contribuire alla strategia complessiva di resilienza al ransomware.

• Blocco oggetto: una configurazione applicata a un bucket S3 che impedisce la cancellazione di un oggetto o della sua versione.
• Versioni degli oggetti: questa impostazione forza la creazione di nuovi oggetti, invece di sovrascrivere quelli caricati in precedenza. Se combinata con "Blocco oggetti", questa impostazione impedisce che gli oggetti vengano sovrascritti con versioni crittografate in modo dannoso. Quando la gestione delle versioni è abilitata, assicurati di impostare delle politiche per gestire il ciclo di vita degli oggetti sottoposti a versione.
• Eliminazione MFA: garantisce che il bit MFA sia impostato sul token di sessione del chiamante quando si tenta di eliminare un oggetto da S3. Anche in questo caso, questi controlli potrebbero essere incompatibili con dati altamente transazionali, ma potrebbero essere fattibili quando si desidera proteggere i backup sensibili. Sapere quali dati si possiedono e dove si trovano è un prerequisito per applicare qualsiasi di queste misure di mitigazione a livello di bucket.

Rilevamento di ransomware Cloud

Questo documento illustra due possibilità che un autore di minacce potrebbe utilizzare per compromettere la disponibilità dei dati ospitati su S3. Il nostro autore di minacce fittizio ha utilizzato un metodo di blocco delle politiche chiave per compromettere la disponibilità di una nuova chiave KMS. È stata inoltre riconosciuta la possibilità di utilizzare lo stesso modus operandi su una chiave esistente. Oppure crittografare in modo dannoso i dati S3 con una chiave KMS esterna, ospitata nell'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.

Blocco chiave con nuova chiave

Se un autore di minacce utilizza questa tecnica, ci sono due punti critici che potrebbero essere segnalati e ai quali è possibile rispondere durante la fase di sfruttamento, osservando l'uso di una nuova chiave KMS e acquisendo gli eventi relativi all'aggiornamento della politica delle chiavi. Se la vostra organizzazione ha una visione chiara di quali chiavi devono essere utilizzate per la crittografia, l'uso di chiavi KMS non approvate dovrebbe far scattare un allarme. Inoltre, anche l'aggiornamento della politica delle chiavi per includere una delle chiavi di condizione globale menzionate in questo documento dovrebbe giustificare un follow-up.

Blocco della chiave con chiave esistente

Un autore di minacce potrebbe scegliere di concentrare i propri sforzi sull'influenzare una chiave KMS esistente. Ciò lascia poche possibilità di rilevamento durante la fase di sfruttamento. Tuttavia, è possibile creare avvisi personalizzati per segnalare quando la politica delle chiavi viene aggiornata per includere una delle chiavi di condizione globali menzionate in questo documento, il che potrebbe significare 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 valido per la crittografia dannosa 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 dai gruppi 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 di accedere a dati aziendali critici.

La creazione di modelli architetturali centralizzati per la gestione delle chiavi è il primo passo per prevenire il ransomware cloud. La gestione centralizzata delle chiavi consente sia una prevenzione più efficace del ransomware sia un quadro più coerente di come si presenta un normale modello crittografico nel proprio cloud .

Sebbene un approccio preventivo sia l'ideale, è improbabile che la maggior parte delle organizzazioni disponga di questi controlli architetturali sin dal primo giorno. Inoltre, è compito di ogni organizzazione, anche quelle con ambienti altamente restrittivi, pianificare il giorno in cui le loro misure di protezione falliranno. Pertanto, rilevare se i dati cloud sono stati colpiti da ransomware dovrebbe essere la priorità assoluta. Queste strategie di rilevamento variano leggermente a seconda della tecnica utilizzata dall'autore della minaccia, ma si basano sul concetto di conoscere cosa significa "esterno" per cloud proprio cloud , che si tratti del monitoraggio della concessione di accessi esterni, dell'utilizzo di chiavi esterne o di istruzioni condizionali nella politica.

---

Riferimenti:

¹ Tecniche di crittografia ransomware: https://medium.com/@tarcisioma/ransomware-encryption-techniques696531d07bb9

² Ransom nel Cloud Spencer Gietzen (DEF CON Cloud ): https://www.youtube.com/watch?v=8QdZ2- sAQFs&list=PL5944c_fOMYn2cQQuQe23gtqZfHWzyrPn&index=3

³ Grant in AWS KMS: https://docs.aws.amazon.com/kms/latest/developerguide/grants.html S3 Ransomware Parte 1: Vettore di attacco: https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/ S3 Ransomware Parte 2: Prevenzione e difesa: https://rhinosecuritylabs.com/aws/s3-ransomware-part-2- prevention-and-defense/