Cloud-Ransomware nativo - Come gli attacchi alla disponibilità sfruttano i servizi di cloud

Come il ransomware colpisce i dati aziendali cloud

Il ransomware è un crimine a sfondo finanziario con l'obiettivo di inibire i sistemi aziendali e ottenere il pagamento di un riscatto. Storicamente, il riscatto dei dati che risiedono nei tradizionali carichi di lavoro aziendali on-premises e nei sistemi governativi ha portato a un ampio guadagno finanziario per gli aggressori che utilizzano gli attacchi ransomware. Con l'espansione dell'impronta cloud dei moderni sistemi digitali, le organizzazioni stanno ora cercando di determinare se il ransomware può colpire allo stesso modo i carichi di lavoro cloud e si chiedono se ci sarà una pressione evolutiva sugli aggressori che li costringerà a evolvere le loro tattiche.

Alla luce delle recenti osservazioni sulle tendenze nell'adozione cloud e nella migrazione dei dati, la mia conclusione è questa: Non vedo come il ransomware possa NON diventare un problema più grande per le aziende globali.

La mia tesi su questo argomento può essere riassunta semplicemente come segue: Ovunque risiedano i dati critici, il ransomware andrà. Quando i dati aziendali risiedono nel Cloud, piuttosto che, ad esempio, in un database on-premise, ha senso dal punto di vista finanziario che gli aggressori evolvano le loro tattiche per colpire i sistemi cloud con gli stessi obiettivi dei sistemi on-premise.

Questo documento serve a delineare i percorsi che un attore malintenzionato nel cloud potrebbe intraprendere per compromettere la disponibilità dei dati utilizzando gli strumenti forniti dal Cloud Service Provider (CSP). Oltre ai comportamenti degli aggressori, ho delineato le misure proattive per proteggere le API cloud che forniscono servizi crittografici, i modelli architettonici per rendere più semplice la protezione di questi sistemi e i metodi per rilevare i ransomware cloud.

Attacco alla disponibilità nel Cloud

Nei primi 10 anni di trasformazione del cloud si è assistito a un'accelerazione delle migrazioni cloud e al deposito di set di dati sempre più grandi nel cloud. Anche se siamo testimoni di questo cambiamento, spesso continuiamo a pensare al ransomware solo nel contesto degli ambienti on-premise, estendendo ingenuamente questi 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 di servizi cloud . Con l'accesso, gli stessi strumenti e funzionalità sono spesso utilizzati da malintenzionati per superare i controlli di sicurezza, evitare il rilevamento e raggiungere obiettivi specifici. L'utilizzo di queste funzionalità con intenti illeciti viene spesso definito abuso di funzionalità.

L'apertura dei servizi cloud tramite API facilita l'abuso da parte degli aggressori, o meglio l'uso improprio di strumenti per lo stesso.

Le API, create da ciascun CSP, sono altamente scopribili e possono essere rapidamente comprese e sfruttate in modi non voluti. L'abuso di funzionalità presenta un rischio aggiuntivo rispetto alle vulnerabilità del codice. A differenza dello sfruttamento di una vulnerabilità, non esiste una falla nel codice da manipolare che possa essere rilevata tramite pattern matching o protetta tramite patch. Gli attori delle minacce sfruttano invece gli strumenti forniti dal CSP utilizzati per la distribuzione o la manutenzione del software e dell'infrastruttura di produzione per portare a termine compiti nefasti.

In qualsiasi ambiente si trovino, gli attori delle minacce sfrutteranno gli strumenti a loro disposizione per portare a termine i loro compiti nefasti. In un certo senso, abusando delle API pubbliche, il ransomware nel cloud continuerà la tendenza di "Living off the Land", dove i "LOL Binaries" del Cloud sono le sue API, ricche di funzionalità e pubbliche. A differenza degli eseguibili di Windows che possono essere disinstallati come software superfluo, le API cloud AWS sono sempre attive. L'esposizione, l'accesso e la disponibilità continuano a fornire l'apertura che i servizi richiedono e lasciano spazio ai mezzi per devastanti attacchi ransomware.

Dove sono ospitati i vostri dati Cloud ?

Per comprendere le tecniche di abuso che gli operatori di ransomware potrebbero utilizzare, è necessario innanzitutto conoscere i sistemi in cui sono archiviati i dati. È probabile che i dati in sede siano archiviati in varie tecnologie, dai database Oracle ai server Microsoft SQL. Ciò che accomuna questi sistemi è che si tratta di host fisici, completamente sotto il vostro controllo.

I server di data warehouse on-premises sono generalmente host fisici implementati in un ambiente full-stack, che costituiscono un facile bersaglio per le malware a causa dell'ampia superficie di attacco. Tuttavia, gli ambienti full-stack sono protetti da solide strategie di protezione dei dati, che impiegano controlli di sicurezza che si sono evoluti negli ultimi 20 anni di modellazione delle minacce basate sulla rete. Per questo motivo, i database tradizionali on-premise sono nascosti dietro strati di controlli di rete, confinati nei recessi più profondi delle reti aziendali e monitorati pesantemente con il rilevamento delle minacce basato su agenti.

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

Ciascuno dei principali fornitori di servizi cloud (ad esempio, AWS, AZURE, GCP) ha una versione unica di un archivio dati distribuito, altamente disponibile e universale: AWS S3, Azure Blob Storage e GCP Storage Buckets. Ognuno di essi è un archivio di base per i dati non strutturati ed è un servizio onnipresente, stabile e altamente disponibile che si integra con molti altri servizi sulle rispettive piattaforme, soddisfacendo quasi tutte le esigenze di archiviazione dei dati dei clienti. I fornitori di Cloud utilizzano i servizi di archiviazione per creare pipeline e servono come archivio dati di supporto per le piattaforme di big data o come repository pubblici per i contenuti web.

Se siete clienti di AWS, è difficile che non usiate S3. Il che lo rende un probabile bersaglio degli autori di ransomware cloud.

Strategia tradizionale di crittografia dei ransomware

I ransomware che colpiscono i sistemi on-premise utilizzano uno schema di crittografia ibrido, sfruttando il meglio della crittografia simmetrica e asimmetrica, per aggirare i limiti di ^ciascuna1.

Le limitazioni sono:

• 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 decifrazione sul sistema, facilitando il recupero da parte delle squadre forensi.

Le strategie impiegate dagli autori di ransomware per aggirare queste limitazioni sono le stesse tecniche utilizzate dai team di crittografia interni. Che si tratti di un intento benevolo o malevolo, le gerarchie di chiavi possono essere utilizzate per derivare un set di chiavi da un altro e quindi crittografare le chiavi simmetriche dei dati.

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

• Maggiore velocità nell'esecuzione delle operazioni di crittografia
  > Mirando ai dati con chiavi simmetriche, il ransomware può spesso completare lo sfruttamento prima che le capacità difensive abbiano la possibilità di rispondere.
• L'offuscamento del materiale della chiave simmetrica ostacola il recupero durante le analisi successive allo sfruttamento.
  > Crittografando la chiave simmetrica dei dati con una chiave asimmetrica, il recupero del materiale della chiave è difficile, se non impossibile, per i professionisti della forensics.

La creazione di malware per eseguire tecniche di crittografia complesse è necessaria per i crittografi on-premises. Tuttavia, questa strategia di crittografia rischia di essere macchinosa e del tutto inutile quando si prendono di mira i dati nel cloud. Il presente documento illustra i metodi che un aggressore potrebbe utilizzare per sfruttare gli strumenti offerti dai fornitori di servizi cloud e rendere obsolete le tradizionali tecniche di ransomware.

Crittografia di oggetti S3 con chiavi KMS controllate dall'attaccante

I fornitori di servizi Cloud hanno fatto il lavoro più pesante per mantenere un sistema di fiducia sicuro per i 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 clienti di generare chiavi, controllare l'accesso a tali chiavi e utilizzarle per eseguire operazioni crittografiche come la firma, la verifica e la gestione del processo di crittografia della busta richiesto da S3 Server-Side Encryption (SSE).

Quando non si utilizza il KMS, gli oggetti crittografati su S3 sono criptati con una chiave AmazonMaster. Quando una parte autorizzata richiede l'accesso a un oggetto in questo bucket, AWS decifra in modo trasparente i dati in background. Invece di permettere ad AWS di generare e gestire le chiavi di backup SSE, i clienti possono utilizzare una chiave KMS e sfruttare i criteri basati sulle risorse collegati 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 agli aggressori la possibilità di influire sulla disponibilità dei dati crittografati con la chiave.

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

Scenario: Dimostrazione di un ransomware Cloud su S3

Lo scenario descritto prevede che un attore minaccioso prenda di mira i dati contenuti nell'apposito "bucket vittima". Su questo bucket è abilitata la crittografia lato server (SSE), specificando che gli oggetti sono crittografati in modo trasparente con una chiave master gestita da Amazon (SSE-S3). Un utente finale a cui è stato concesso l'accesso solo per recuperare gli oggetti (azione s3:GetObject) da questo bucket avrà le autorizzazioni sufficienti per scaricare il testo in chiaro degli oggetti memorizzati. Non sono necessarie ulteriori autorizzazioni per decifrare gli oggetti quando sono crittografati con una chiave master gestita da Amazon.

In questo scenario, consideriamo che un attore malintenzionato abbia compromesso un utente finale con l'intento di chiedere un riscatto per i suoi dati. L'attore malintenzionato ha creato un nuovo bucket S3, che chiameremo "staging-bucket", che utilizzerà come zona di atterraggio per i dati S3 mirati. Anche il nuovo "staging-bucket" richiede che gli oggetti caricati siano crittografati, ma con una chiave KMS. Abbiamo generato la chiave KMS in AWS e l'abbiamo memorizzata in un HSM AWS, quindi ci siamo affidati ai criteri gestiti dal cliente per imporre il controllo degli accessi alla chiave.

Durante la migrazione dei dati dal "victim-bucket" allo "staging-bucket", gli oggetti vengono nuovamente crittografati con la nuova chiave KMS creata. I permessi associati agli oggetti S3 e alla chiave KMS determinano l'accesso agli oggetti. Aspettatevi 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 "nega" sull'oggetto S3 o sulla chiave KMS, ci si aspetta che anche le richieste di accesso siano negate.

A questo punto, il nostro attore fittizio ha preparato il terreno per un attacco ransomware migrando gli oggetti S3 su un nuovo datastore e crittografando nuovamente gli oggetti con chiavi sotto il suo controllo. Il passo successivo in questa narrazione prevede l'impatto sull'accesso alla chiave per le operazioni crittografiche, come la decrittazione.

Blocco dei criteri chiave - "DENY, tranne quando; ALLOW, solo quando".

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

Vediamo come potrebbe apparire un aggiornamento dannoso dei criteri delle chiavi.

• DENY - tutte le azioni sulla chiave KMS, tranne quando la chiave di condizione "aws:sourceIp" corrisponde all'IP controllato dall'attaccante.
• ALLOW - tutte le azioni sulla chiave KMS, solo quando il chiamante proviene dall'account controllato dall'aggressore.

Questo stile di politica basata sulle risorse può essere definito come: "DENY, tranne quando; ALLOW, solo quando".

È possibile immaginare che un operatore di ransomware che voglia utilizzare questo schema possa sfruttare altre condizioni. 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 della chiave globale AWS:

• aws:PrincipalArn
• aws:PrincipalAccount
• aws:sourceVPC
• aws:SourceVPCe

Qualsiasi condizione in cui il chiamante richiede un valore unico e controllato dall'attaccante può essere sfruttata per bloccare un cliente AWS dalle sue risorse.

Quando si aggiorna un criterio basato sulle risorse collegato alla chiave KMS al modello "DENY, except when; ALLOW, only when", l'account vittima viene di fatto escluso dai 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'aggressore e dall'IP controllato dall'aggressore sarebbero in grado di accedere alla chiave KMS e decifrare i dati S3.

La pulizia finale di un attacco ransomware cloud prevede l'eliminazione del "victim-bucket" originale e il caricamento di una nota di riscatto su un nuovo bucket non crittografato.

Chiavi KMS esistenti

Bloccare una vittima da una chiave KMS non è l'unico modo per influenzare la 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 influenzare la disponibilità colpendo una chiave KMS esistente, l'attore della minaccia richiederebbe autorizzazioni ancora più limitate. L'aggiornamento di una chiave KMS esistente per limitarne l'accesso alle operazioni crittografiche avrebbe lo stesso effetto debilitante sulla disponibilità dei dati che avrebbe una nuova crittografia dei dati S3 con una nuova chiave creata dall'aggressore.

In entrambi gli scenari precedenti, l'accesso alla chiave simmetrica utilizzata nella crittografia lato server (SSE-KMS) è tenuto in ostaggio da attori malintenzionati attraverso la manipolazione della politica delle chiavi.

Quando la vittima paga

Non possiamo presumere di sapere come si comporterebbe una banda di ransomware cloud per cedere il controllo della chiave di decrittazione dei dati basata su un ransomware tradizionale on-premises. Nel cloud, il processo di "consegna delle chiavi" dei dati crittografati sarà diverso, anche se rimane una componente necessaria del ciclo di vita del ransomware. Dopo tutto, il prodotto che il ransomware offre al suo consumatore è un meccanismo per recuperare i dati crittografati. Come qualsiasi altra azienda, gli operatori di ransomware hanno bisogno di un mezzo affidabile e fidato per consegnare i prodotti ai loro "clienti".

Nello scenario uno, solo i chiamanti dell'account dell'aggressore possono accedere alle chiavi KMS necessarie per decifrare i dati critici per l'azienda, ma l'aggiornamento della politica delle chiavi è un'azione che un aggressore non può eseguire in modo trasversale. Pertanto, un meccanismo affidabile e in tempo reale per restituire il controllo alla vittima non può prevedere l'aggiornamento dei criteri delle chiavi. Piuttosto, una banda di ransomware potrebbe puntare sui key grant, un meccanismo alternativo di controllo dell'accesso alle chiavi KMS utilizzato per delegare le autorizzazioni per le operazioni crittografiche.

Una concessione di chiave ^KMS3 è una delega di permessi 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 decrittazione, la banda del ransomware può effettivamente restituire la disponibilità ai suoi "clienti" paganti, aggirando le restrizioni imposte dalla politica delle chiavi vincolate. Una concessione di chiave KMS consentirebbe alla vittima di accedere alla chiave KSM e di iniziare il processo di recupero dei dati crittografati.

AWS potrebbe salvarvi da un attacco Ransomware Cloud?

Alla luce delle precedenti considerazioni, quando ci si trova di fronte a un attacco Ransomware in un ambiente cloudnative, è ragionevole chiedersi dove si inserisce il "modello di responsabilità condivisa". Di seguito sono riportate alcune considerazioni che vale la pena esaminare.

Il primo scenario di intervento di AWS ipotizza che AWS possa accedere al materiale delle chiavi KMS da un HSM AWS. Questa congettura è così poco plausibile che sembra completamente fuori dal campo delle possibilità. È impensabile che AWS possa recuperare una chiave KMS da uno dei suoi HSM ospitati nei suoi centri dati. AWS si è impegnata a fondo per garantire che nessuno potesse recuperare il materiale della chiave e ha rilasciato dichiarazioni pubbliche in tal senso.

I restanti due scenari di un eventuale intervento di AWS sono una questione molto più aperta. La prima possibilità di assistenza prevede che AWS modifichi l'ambiente della vittima. Non ci sono prove che AWS sia in grado di invertire un criterio di chiave applicato in modo malevolo in un account della vittima, ripristinando l'accesso a una chiave KMS. Non vi è alcuna indicazione che l'azienda disponga di capacità di "mano di Dio" sulle politiche basate sulle risorse. Inoltre, non c'è molto incentivo ad ammettere pubblicamente questa capacità, anche se ci fosse.

L'ultima opzione di riparazione assistita da prendere in considerazione prevede che AWS requisisca l'account in cui operano gli attori maligni. Il team Trust and Safety di AWS metterà in quarantena e chiuderà gli account dannosi che violano 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, che sarebbe necessario per riprendere il controllo di una chiave KMS dirottata. Sebbene non sia chiaro se AWS disponga di un processo per rilevare gli account, vi sono alcune prove che suggeriscono che lo faccia.

In AWS esiste un meccanismo per modificare l'indirizzo e-mail di root di un account. Questo meccanismo è applicabile se si dimentica la password dell'utente principale e si perde l'accesso all'e-mail associata all'utente principale. L'assistenza AWS richiederà all'utente un'attestazione notarile della proprietà dell'account prima di poter apportare una modifica all'account e-mail di root. Questo processo interno suggerisce che AWS ha il potere di prendere il controllo sugli account, non semplicemente di chiuderli, ma di accedere alle risorse in essi contenute con capacità amministrative.

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

Prevenzione, rilevamento e risposta al ransomware Cloud

Con la consapevolezza che è improbabile che AWS possa essere d'aiuto durante un evento di ransomware, ci rivolgiamo alla base di tutti i programmi di sicurezza, ai controlli preventivi e alle capacità di rilevamento e risposta.

SCP Limitazione delle chiavi KMS

Le mitigazioni tramite i criteri di controllo dei servizi (SCP) richiedono un certo grado di maturità nel programma di sicurezza 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 la comprensione di quali chiavi debbano essere autorizzate a eseguire operazioni crittografiche sui dati e chi debba accedervi.

Un criterio di controllo dei servizi (SCP) che indichi le chiavi KMS specifiche consentite per la crittografia degli oggetti potrebbe essere un buon inizio 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 maliziosamente gli oggetti S3 con una chiave di nuova creazione o una chiave esterna di suo 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 uno schema di progettazione preferito, non solo per la resilienza ai ransomware, ma anche per tutti i vantaggi che la centralizzazione comporta, come la verificabilità e la rotazione semplificata delle chiavi.

L'utilizzo di questo approccio centralizzato "Fort Knox" alla gestione delle chiavi crea il concetto di "tutte le uova in un paniere". Inoltre, consente di mettere tutti i controlli di sicurezza in un unico paniere. Un account centrale di gestione delle chiavi consente a un'organizzazione di sicurezza di applicare il principio del minimo privilegio nel senso più stretto del termine, di stabilire una linea di base per i normali modelli di utilizzo delle chiavi e di monitorare le transazioni anomale.

Configurazioni della benna S3

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

• Blocco dell'oggetto: Una configurazione applicata a un bucket S3 che impedisce la cancellazione di un oggetto o della sua versione.
• Versione degli oggetti: Questa impostazione forza la creazione di nuovi oggetti, invece di sovrascrivere quelli precedentemente caricati. Se combinate con "Object Lock", queste impostazioni possono impedire che gli oggetti vengano sovrascritti con versioni criptate da malintenzionati. Ogni volta che si abilita il versioning, assicurarsi di impostare le politiche per gestire il ciclo di vita degli oggetti versionati.
• Eliminazione MFA: Assicura 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 sono probabilmente incompatibili con i dati altamente transazionali, ma potrebbero essere fattibili quando si vuole proteggere i backup sensibili. Conoscere i dati in vostro possesso e dove risiedono è un prerequisito per applicare una qualsiasi di queste mitigazioni a livello di bucket.

Rilevamento del ransomware Cloud

Il presente documento illustra due possibilità che un attore di minacce potrebbe utilizzare per compromettere la disponibilità dei dati ospitati su S3. Il nostro attore malintenzionato ha utilizzato un metodo di blocco della politica delle chiavi per compromettere la disponibilità di una nuova chiave KMS. È stata anche riconosciuta la possibilità di utilizzare lo stesso modus operandi su una chiave esistente. Oppure crittografare maliziosamente i dati S3 con una chiave KMS esterna, ospitata nell'account controllato dall'aggressore. Esaminiamo ciascuno degli scenari per discutere quali eventi nel vostro CloudTrail potrebbero giustificare un'indagine da parte dei vostri soccorritori.

Blocco della politica delle chiavi con una nuova chiave

Se un attore minaccia impiega questa tecnica, ci sono due punti critici che potrebbero essere allertati e a cui rispondere durante la fase di sfruttamento, quando si osserva l'uso di una nuova chiave KMS e si ingeriscono gli eventi che circondano l'aggiornamento del criterio della chiave. Se l'organizzazione ha una visione chiara delle chiavi da utilizzare per la crittografia, l'uso di chiavi KMS non approvate dovrebbe far scattare l'allarme. Inoltre, 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 politica delle chiavi con la chiave esistente

Un attore delle minacce può scegliere di concentrare i propri sforzi sull'impatto di una chiave KMS esistente. Ciò lascia limitate opportunità di rilevamento durante la fase di sfruttamento. Tuttavia, è possibile creare avvisi personalizzati per notificare quando il criterio delle chiavi viene aggiornato per includere una delle chiavi di condizione globale menzionate in questo 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 un meccanismo praticabile per la crittografia dolosa dei dati. I team operativi della sicurezza vorrebbero essere avvisati quando vengono eseguite operazioni di crittografia con chiavi KMS che non si trovano in un account sotto il loro controllo.

In conclusione

I fornitori di servizi 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 ransomware di successo nel cloud utilizza servizi cloud per crittografare i dati con rapidità e meccanismi di controllo degli accessi integrati per bloccare la vittima dai dati aziendali critici.

La stesura 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 nella vostra proprietà cloud .

Sebbene una postura preventiva sia ideale, è improbabile che la maggior parte delle organizzazioni disponga di questi controlli architetturali fin dal primo giorno. Inoltre, spetta a tutte le organizzazioni, anche a quelle con ambienti altamente restrittivi, pianificare il giorno in cui i loro guardrail dovessero cedere. Pertanto, la priorità assoluta dovrebbe essere quella di rilevare se i dati cloud sono stati colpiti da ransomware. Queste strategie di rilevamento variano in modo sottile a seconda della tecnica utilizzata dall'attore della minaccia, ma sono radicate nel concetto di sapere cosa significa esterno per la proprietà cloud , sia che si tratti del monitoraggio della concessione di accesso esterno, dell'utilizzo di chiavi esterne o di dichiarazioni condizionali nei criteri.

---

Riferimenti:

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

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

³ Borse di studio 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/