CloudRansomware natif - Comment les attaques sur la disponibilité s'appuient sur les services cloud

Comment les ransomwares affectent les données des entreprises hébergées sur cloud

Le ransomware est un crime à motivation financière dont l'objectif est d'inhiber les systèmes d'entreprise et d'obtenir le paiement d'une rançon. Historiquement, le rançonnement des données résidant dans les charges de travail traditionnelles des entreprises sur site et dans les systèmes gouvernementaux a permis aux assaillants utilisant les attaques par ransomware de réaliser d'importants gains financiers. Avec l'expansion de l'empreinte cloud des systèmes numériques modernes, les organisations tentent maintenant de déterminer si les ransomwares peuvent affecter les charges de travail basées sur cloud dans la même mesure, et se demandent également si les attaquants seront soumis à une pression évolutive qui les obligera à faire évoluer leurs tactiques.

Les récentes observations des tendances en matière d'adoption du site cloud et de migration des données m'amènent à la conclusion suivante : Je ne vois pas comment les ransomwares pourraient ne pas devenir un problème plus important pour les entreprises internationales.

Ma thèse sur ce sujet peut être résumée simplement comme suit : Là où se trouvent les données critiques, les ransomwares iront. Lorsque les données d'entreprise résident sur le site Cloud, plutôt que, par exemple, dans une base de données sur site, il est financièrement logique que les attaquants fassent évoluer leurs tactiques pour cibler les systèmes cloud avec les mêmes objectifs que les systèmes sur site.

Ce document a pour but de décrire les voies qu'un acteur malveillant sur le site cloud pourrait emprunter pour affecter la disponibilité des données en utilisant les outils fournis par le fournisseur de services (CSP) Cloud . Outre les comportements des attaquants, j'ai décrit des mesures proactives pour sécuriser cloud les API qui fournissent des services cryptographiques, des modèles architecturaux pour faciliter la sécurisation de ces systèmes et des méthodes pour détecter cloud-native ransomware.

Attaquer la disponibilité dans le Cloud

Les dix premières années de transformation de cloud ont vu une accélération des migrations de cloud et le dépôt d'ensembles de données de plus en plus importants sur cloud. Même si nous assistons à ce changement, nous continuons souvent à penser aux ransomwares uniquement dans le contexte des environnements sur site, en étendant naïvement ces concepts à cloud.

Dans le site cloud, les outils dont les développeurs et les clients ont besoin pour accomplir leurs tâches quotidiennes sont intégrés et proposés comme fonctionnalités par les fournisseurs de services cloud . Avec l'accès, les mêmes outils et capacités sont souvent utilisés par des acteurs malveillants pour contourner les contrôles de sécurité, éviter la détection et atteindre des objectifs spécifiques. L'utilisation malveillante de ces fonctionnalités est souvent qualifiée d'abus de fonctionnalités.

L'ouverture des services natifs de cloud via les API permet aux attaquants d'abuser facilement, ou plutôt d'utiliser à mauvais escient, les outils correspondants.

Les API, créées par chaque FSC, sont très faciles à découvrir et peuvent être rapidement comprises et exploitées de manière non intentionnelle. L'utilisation abusive des fonctionnalités présente un risque en plus des vulnérabilités du code. Contrairement à l'exploitation d'une vulnérabilité, il n'y a pas de faille de code à manipuler qui puisse être détectée par la recherche de motifs ou sécurisée par des correctifs. Au lieu de cela, cybercriminels exploite les outils fournis par le CSP pour déployer ou maintenir les logiciels et l'infrastructure de production afin d'accomplir des tâches malveillantes.

Quel que soit l'environnement dans lequel ils se trouvent, les cybercriminels exploiteront les outils à leur disposition pour accomplir leurs tâches néfastes. D'une certaine manière, en abusant des API publiques, les ransomwares du site cloud poursuivront la tendance à "vivre de la terre" où les "LOL Binaries" du site Cloud sont ses API, riches en fonctionnalités et publiques. Contrairement aux exécutables Windows qui peuvent être désinstallés comme des logiciels superflus, les API d'AWS cloud sont toujours actives. L'exposition, l'accès et la disponibilité continuent de fournir l'ouverture dont les services ont besoin et donnent lieu à des attaques dévastatrices par ransomware.

Où sont hébergées vos données Cloud ?

Pour comprendre les techniques d'abus que les opérateurs de ransomware pourraient utiliser, il faut d'abord comprendre les systèmes dans lesquels les données sont stockées. Les données sur site sont probablement stockées dans diverses technologies, des bases de données Oracle aux serveurs Microsoft SQL. Le point commun de ces systèmes est qu'il s'agit d'hôtes physiques, entièrement sous votre contrôle.

Les serveurs d'entrepôt de données sur site sont généralement des hôtes physiques mis en œuvre dans un environnement complet qui constitue une cible facile pour malware en raison de la vaste surface d'attaque. Cependant, les environnements complets bénéficient de stratégies de protection des données robustes, utilisant des contrôles de sécurité qui ont évolué au cours des 20 dernières années de modélisation des menaces basées sur le réseau. Ainsi, les bases de données traditionnelles sur site sont cachées derrière des couches de contrôles réseau, confinées dans les recoins profonds des réseaux d'entreprise et fortement surveillées par des agents de détection des menaces.

L'approche sur site de la sécurisation des magasins de données traditionnels ne s'applique pas au site cloud, et ne devrait pas s'y appliquer. Les données migrées vers cloud résident dans des systèmes où tous les utilisateurs finaux, y compris les acteurs malveillants, ont un accès limité et contrôlé au système sous-jacent. Cela signifie que les magasins de données cloud ont des surfaces d'attaque radicalement différentes.

Chacun des principaux fournisseurs de services cloud (par exemple, AWS, AZURE, GCP) dispose d'une version unique d'un magasin de données distribué, hautement disponible et polyvalent : AWS S3, Azure Blob Storage et GCP Storage Buckets. Chacun d'entre eux est un référentiel central pour les données non structurées et constitue un service omniprésent, stable et hautement disponible qui s'intègre à de nombreux autres services sur leurs plateformes respectives, répondant ainsi à la quasi-totalité des besoins de stockage de données des clients. Cloud Les fournisseurs utilisent les services de stockage pour créer des pipelines, et ils servent de magasin de données de secours pour les plateformes de big data ou de référentiels publics pour le contenu web.

Si vous êtes client d'AWS, il est difficile de ne pas utiliser S3. Ce qui en fait une cible de choix pour les auteurs de ransomwares natifs de cloud.

Stratégie traditionnelle de chiffrement des rançongiciels

Les rançongiciels ciblant les systèmes sur site utilisent un schéma de chiffrement hybride, tirant parti du meilleur du chiffrement symétrique et du chiffrement asymétrique, afin de contourner les limites de chacun d'^eux1.

Les limites étant :

• Alors que les opérations de cryptage asymétrique sont lentes, le cryptage des données à l'aide d'une clé symétrique est rapide !
• Le chiffrement symétrique utilise la même clé pour le chiffrement et le déchiffrement. Une stratégie purement symétrique laisse souvent la clé de décryptage sur le système, ce qui facilite sa récupération par les équipes de police scientifique.

Les stratégies employées par les auteurs de ransomwares pour contourner ces limitations sont les mêmes techniques que celles utilisées par les équipes de cryptographie internes. Que ce soit à des fins bienveillantes ou malveillantes, les hiérarchies de clés peuvent être utilisées pour dériver un ensemble de clés à partir d'un autre, puis pour chiffrer les clés de données symétriques.

En combinant le chiffrement symétrique et le chiffrement asymétrique, les auteurs de ransomwares peuvent atteindre des objectifs plus complexes.

• Vitesse accrue lors de l'exécution des tâches de chiffrement
  > En ciblant les données avec des clés symétriques, les ransomwares peuvent souvent terminer l'exploitation avant que les capacités défensives n'aient une chance de réagir.
• L'obscurcissement de la clé symétrique entrave la récupération lors de l'analyse post-exploitation.
  > En chiffrant la clé symétrique des données avec une clé asymétrique, la récupération de la clé est difficile, voire impossible, pour les professionnels de la police scientifique.

La création de malware pour réaliser des techniques de chiffrement complexes est nécessaire pour les chiffreurs sur site. Toutefois, cette stratégie de chiffrement est probablement lourde et totalement inutile lorsqu'elle vise des données sur le site cloud. Le présent document décrit les méthodes qu'un attaquant pourrait utiliser pour exploiter les outils offerts par les fournisseurs de services cloud et rendre obsolètes les techniques traditionnelles de ransomware.

Chiffrement d'objets S3 avec des clés KMS contrôlées par un attaquant

Cloud Les fournisseurs de services ont fait le gros du travail pour maintenir des racines de confiance sécurisées pour leurs clients qui utilisent leurs services cryptographiques. Les attaquants peuvent profiter de ces commodités pour affecter la disponibilité des données hébergées sur cloud.

AWS Key Management Service (AWS KMS) permet à ses clients de générer des clés, de contrôler l'accès à ces clés et de les utiliser pour effectuer des opérations cryptographiques telles que la signature, la vérification et la gestion du processus de cryptage requis pour le cryptage côté serveur S3 (SSE).

Lorsqu'ils n'utilisent pas le KMS, les objets cryptés sur S3 sont cryptés avec une clé AmazonMaster. Lorsqu'une partie autorisée demande l'accès à un objet dans ce bac, AWS déchiffre les données de manière transparente en arrière-plan. Au lieu de laisser AWS générer et gérer les clés de sauvegarde SSE, les clients peuvent utiliser une clé KMS et exploiter la politique basée sur les ressources attachée à la clé comme une autre couche de contrôle d'accès aux données cryptées. La possibilité d'appliquer une politique et de restreindre l'accès à une clé laisse une ouverture aux attaquants pour affecter la disponibilité des données chiffrées avec la clé.

Pour illustrer le rôle du KMS dans l'ESS, on peut se référer au premier scénario ci-dessous, dans lequel un opérateur de ransomware obtient un accès important à S3 et au KMS dans un compte AWS. L'acteur malveillant peut lire, copier et supprimer des objets de S3 et obtenir les autorisations nécessaires pour créer une nouvelle clé KMS. Le scénario décrit en outre comment un acteur de la menace pourrait utiliser l'accès pour affecter la disponibilité des données et demander une rançon pour leur restauration.

Scénario : Démonstration d'un ransomware natif de Cloud sur S3

Dans le scénario présenté, un acteur de la menace cible les données du bien nommé "victim-bucket". Sur ce panier, le chiffrement côté serveur (SSE) est activé, spécifiant que les objets sont chiffrés de manière transparente avec une clé maîtresse gérée par Amazon (SSE-S3). Un utilisateur final qui n'a accès qu'à l'extraction d'objets (action s3:GetObject) à partir de ce panier dispose d'autorisations suffisantes pour télécharger le texte en clair des objets stockés. Aucune autorisation supplémentaire n'est requise pour déchiffrer les objets lorsqu'ils sont chiffrés avec une clé principale gérée par Amazon.

Dans ce scénario, nous considérons qu'un acteur malveillant a compromis un utilisateur final avec l'intention de demander une rançon pour ses données. L'acteur malveillant a créé un nouveau godet S3 que nous appellerons "staging-bucket", qu'il utilisera comme zone d'atterrissage pour les données S3 ciblées. Le "staging-bucket" nouvellement créé exige également que les objets téléchargés soient chiffrés, mais avec une clé KMS. Nous avons généré la clé KMS dans AWS et l'avons stockée dans un HSM AWS, puis nous nous sommes appuyés sur la politique gérée par le client pour appliquer le contrôle d'accès à la clé.

Lors de la migration des données du "victim-bucket" vers le "staging-bucket", les objets sont recryptés avec la clé KMS nouvellement créée. Les autorisations associées aux objets S3 et à la clé KMS déterminent l'accès aux objets. Il faut s'attendre à des réponses de refus d'accès lorsque les demandes proviennent d'appelants qui n'ont pas les autorisations explicites pour accéder aux objets S3 et à la clé KMS. Si un utilisateur final dispose d'une autorisation explicite "refuser" sur l'objet S3 ou la clé KMS, il faut s'attendre à ce que les demandes d'accès soient également refusées.

À ce stade, notre acteur fictif a préparé le terrain pour une attaque par ransomware en migrant les objets S3 vers un nouveau magasin de données et en recryptant les objets avec des clés sous son contrôle. L'étape suivante de cette histoire consiste à influencer l'accès à la clé pour les opérations cryptographiques, telles que le décryptage.

Verrouillage des politiques clés - "REFUSER, sauf quand ; AUTORISER, seulement quand".

La technique consistant à empêcher un client AWS d'accéder à une clé KMS hébergée dans son propre compte a été décrite pour la première fois par Spencer Geitzen au village Cloud lors de la conférence DEFCON en ²⁰²⁰².

Voyons à quoi peut ressembler une mise à jour malveillante de la politique des clés.

• DENY - toutes les actions sur la clé KMS - sauf si la clé de condition "aws:sourceIp" est égale à l'IP contrôlée par l'attaquant.
• ALLOW - toutes les actions sur la clé KMS - uniquement lorsque l'appelant provient du compte contrôlé par l'attaquant.

Ce type de jargon politique basé sur les ressources peut être appelé : "REFUSER, sauf quand ; AUTORISER, seulement quand".

On peut imaginer que d'autres conditions peuvent être exploitées par un opérateur de ransomware cherchant à utiliser ce modèle. Exiger que l'appelant provienne d'une IP source spécifique est en fait un mécanisme permettant de restreindre toute activité sur une clé, mais l'utilisation des conditions de clé globale AWS suivantes pourrait être tout aussi efficace :

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

Toute condition dans laquelle une valeur unique et contrôlée par l'attaquant est requise par l'appelant peut être exploitée pour verrouiller les ressources d'un client AWS.

Lors de la mise à jour d'une politique basée sur les ressources attachée à la clé KMS vers le modèle "DENY, except when ; ALLOW, only when", le compte de la victime est effectivement bloqué hors de ses données nouvellement cryptées. Même l'utilisateur root ne peut pas accéder aux données S3 chiffrées.

Seuls les appelants provenant du compte AWS contrôlé par l'attaquant à partir de l'adresse IP contrôlée par l'attaquant seraient en mesure d'accéder à la clé KMS et de décrypter les données S3.

Le nettoyage final d'une attaque de ransomware originaire de cloud comprendrait la suppression du "panier de la victime" original et le téléchargement d'une note de rançon dans un nouveau panier non crypté.

Clés KMS existantes

Verrouiller l'accès d'une victime à une clé KMS n'est pas le seul moyen d'affecter la disponibilité de S3. Cependant, c'est l'un des mécanismes les plus intéressants à modéliser pour un chercheur en sécurité.

Cette technique n'est pas limitée aux nouvelles clés KMS. Pour affecter la disponibilité en agissant sur une clé KMS existante, il faudrait que l'acteur de la menace dispose d'autorisations encore plus limitées. La mise à jour d'une politique de clé KMS existante afin d'en restreindre l'accès pour les opérations cryptographiques aurait le même effet débilitant sur la disponibilité des données que le recryptage des données S3 à l'aide d'une nouvelle clé créée par l'attaquant.

Dans les deux scénarios précédents, l'accès à la clé symétrique utilisée pour le chiffrement côté serveur (SSE-KMS) est pris en otage par des acteurs malveillants qui manipulent la politique des clés.

Quand la victime paie

Nous ne pouvons pas prétendre savoir à quoi ressemblerait, pour un gang de ransomwares natifs de cloud, l'abandon du contrôle de la clé de décryptage des données basée sur un ransomware traditionnel sur site. Sur le site cloud, le processus de "remise des clés" des données cryptées sera différent, même s'il reste un élément nécessaire du cycle de vie des ransomwares. Après tout, le produit que le ransomware fournit à son consommateur est un mécanisme de récupération des données cryptées. Comme toute autre entreprise, les opérateurs de ransomwares ont besoin d'un moyen fiable et sûr pour livrer leurs produits à leurs "clients".

Dans le premier scénario, seuls les appelants du compte de l'attaquant peuvent accéder à la clé KMS qui est nécessaire pour déchiffrer les données critiques de l'entreprise, mais la mise à jour de la politique des clés est une action qu'un attaquant ne peut pas effectuer entre comptes. Par conséquent, un mécanisme fiable et en temps réel pour rendre le contrôle à la victime ne peut pas impliquer une mise à jour de la politique des clés. Un gang de ransomwares peut plutôt se tourner vers les subventions de clés, un mécanisme alternatif de contrôle d'accès pour les clés KMS utilisées pour déléguer des permissions pour les opérations cryptographiques.

Un octroi de clé ^KMS3 est une délégation de permissions à un bénéficiaire qui renvoie un jeton utilisé pour effectuer des opérations cryptographiques sur cette clé. En créant un octroi de clé et en permettant au compte de la victime d'utiliser la clé détournée pour le déchiffrement, le gang du ransomware peut effectivement rendre la disponibilité à ses "clients" payants, en contournant les restrictions imposées par la politique de clé restreinte. L'octroi d'une clé KMS permet à la victime d'accéder à la clé KSM et d'entamer le processus de récupération de ses données chiffrées.

AWS pourrait-il vous sauver d'une attaque de ransomware Cloud-Native ?

Compte tenu de ce qui précède, face à une attaque de ransomware dans un environnement "cloud", il est raisonnable de se demander quel est le rôle du "modèle de responsabilité partagée". Voici quelques considérations qui méritent d'être examinées.

Le premier scénario d'intervention d'AWS suppose qu'AWS pourrait accéder aux clés KMS d'un HSM AWS. Cette hypothèse est si peu plausible qu'elle semble totalement hors du champ des possibles. Il est impensable qu'AWS puisse récupérer une clé KMS à partir de l'un de ses HSM hébergés dans ses centres de données. AWS s'est donné beaucoup de mal pour s'assurer que personne ne puisse récupérer les clés et a fait des déclarations publiques sérieuses à cet effet.

Les deux autres scénarios d'intervention du système d'alerte avancée sont beaucoup plus incertains. La première possibilité d'assistance impliquerait qu'AWS modifie l'environnement de la victime. Rien ne prouve qu'AWS puisse inverser une politique de clés appliquée de manière malveillante dans un compte victime, en rétablissant l'accès à une clé KMS. Rien n'indique qu'elle dispose d'une quelconque capacité de "main de Dieu" sur les politiques basées sur les ressources. Il n'y a pas non plus d'incitation à admettre publiquement cette capacité si elle existait.

La dernière option de remédiation assistée à envisager consisterait à demander à AWS de réquisitionner le compte dans lequel les acteurs malveillants opèrent. L'équipe "Trust and Safety" d'AWS met en quarantaine et ferme les comptes indésirables qui ne respectent pas les conditions de service, comme ceux utilisés dans les campagnes de botnet. Toutefois, la mise en quarantaine et la fermeture de comptes sont très différentes de la prise de contrôle des ressources, qui serait nécessaire pour reprendre le contrôle d'une clé KMS détournée. Bien qu'il ne soit pas certain qu'AWS dispose d'un processus de prise de contrôle des comptes, certains éléments laissent à penser que c'est le cas.

AWS dispose d'un mécanisme permettant de modifier l'adresse électronique racine d'un compte. Vous verriez cela en action si vous oubliiez le mot de passe de votre utilisateur racine et perdiez l'accès à l'adresse électronique associée à l'utilisateur racine. Le service d'assistance d'AWS vous demandera de fournir une attestation notariée de la propriété de votre compte avant de modifier l'adresse électronique racine sous-jacente. Ce processus interne suggère qu'AWS a le pouvoir de prendre le contrôle des comptes, non seulement de les fermer, mais aussi d'accéder aux ressources qui y sont hébergées avec des capacités administratives.

Tout comme la théorie de la "main de Dieu", AWS n'a que peu d'intérêt à rendre publique sa capacité à confisquer les comptes. Du point de vue des défenseurs, en l'absence d'un processus clairement documenté de récupération assistée par AWS avec des accords de niveau de service garantis, l'assistance théorique d'AWS en matière de remédiation n'est pas utile. La planification de la réponse et de la reprise après un ransomware ne devrait pas être centrée sur l'aide d'AWS et ne devrait pas être attendue.

Prévention, détection et réponse à Cloud-Native Ransomware

Partant du principe qu'il est peu probable qu'AWS puisse aider en cas de ransomware, nous nous intéressons à la base de tous les programmes de sécurité, aux contrôles préventifs et aux capacités de détection et de réponse.

Restriction des clés KMS par SCP

Les mesures d'atténuation via la politique de contrôle des services (SCP) exigent un certain degré de maturité dans votre programme de sécurité cloud , mais cela ne signifie pas que leur utilisation ne devrait pas être un objectif opérationnel. La création d'une politique sur mesure pour les clés KMS nécessite de comprendre quelles clés doivent être autorisées à effectuer des opérations cryptographiques sur vos données et qui doit y avoir accès.

Une politique de contrôle des services (SCP) désignant les clés KMS spécifiques autorisées à chiffrer les objets pourrait constituer un bon point de départ pour prévenir une attaque de ransomware native cloud du type de celle décrite dans le présent document. Restreindre les opérations cryptographiques à des clés spécifiques empêcherait un attaquant de chiffrer malicieusement des objets S3 avec une clé nouvellement créée ou une clé externe qu'il contrôle, mais pas de détourner la politique d'une clé existante et approuvée.

Ce type de SCP est souvent associé à un modèle architectural qui regroupe toutes les clés KMS dans un compte unique. Il devrait s'agir d'un modèle de conception privilégié, non seulement pour la résilience face aux ransomwares, mais aussi pour tous les avantages que la centralisation apporte, tels que l'auditabilité et la rotation simplifiée des clés.

L'utilisation de cette approche centralisée "Fort Knox" pour la gestion des clés permet de mettre tous les œufs dans le même panier. Elle permet également de mettre tous les contrôles de sécurité dans le même panier. Un compte central de gestion des clés permet à une organisation de sécurité d'appliquer le principe du moindre privilège au sens le plus strict, d'établir une base de référence pour les schémas normaux d'utilisation des clés et de surveiller les transactions anormales.

Configurations des godets S3

Tous les seaux S3 ne peuvent pas être configurés pour devenir des forteresses, mais il convient de noter les contrôles disponibles dans S3 qui peuvent contribuer à la stratégie globale de résilience face aux ransomwares.

• Verrouillage d'objet : Une configuration appliquée à un godet S3 qui empêche la suppression d'un objet ou de sa version.
• Versionnement des objets: Ce paramètre force la création de nouveaux objets, au lieu d'écraser les objets précédemment téléchargés. Combinés au "verrouillage des objets", ces paramètres peuvent empêcher l'écrasement d'objets par des versions cryptées à des fins malveillantes. Lorsque le versionnage est activé, veillez à définir des règles pour gérer le cycle de vie de vos objets versionnés.
• MFA Delete : Assure que le bit MFA est activé sur le jeton de session de l'appelant lorsqu'il tente de supprimer un objet de S3. Là encore, ces contrôles seront probablement incompatibles avec les données hautement transactionnelles, mais ils pourraient s'avérer utiles pour sécuriser vos sauvegardes sensibles. Connaître les données que vous possédez et l'endroit où elles se trouvent est une condition préalable à l'application de l'une de ces mesures d'atténuation au niveau du panier.

Détection de Cloud-Native Ransomware

Cet article décrit deux possibilités qu'un acteur de la menace pourrait utiliser pour affecter la disponibilité des données hébergées sur S3. Notre acteur fictif a utilisé une méthode de verrouillage de la politique des clés pour influer sur la disponibilité d'une nouvelle clé KMS. Il est également possible d'utiliser le même modus operandi sur une clé existante. Ou de chiffrer malicieusement des données S3 avec une clé KMS externe, hébergée dans le compte contrôlé par l'attaquant. Examinons chacun de ces scénarios afin de déterminer quels événements de votre CloudTrail pourraient justifier une enquête de la part de vos intervenants.

Verrouillage de la police à clé avec une nouvelle clé

Si un acteur de la menace utilise cette technique, deux points critiques pourraient faire l'objet d'une alerte et d'une réponse au cours de la phase d'exploitation, lors de l'observation de l'utilisation d'une nouvelle clé KMS et de l'ingestion des événements entourant la mise à jour de la politique de clés. Si votre organisation a une vision claire des clés à utiliser pour le chiffrement, l'utilisation de clés KMS non approuvées devrait déclencher des alarmes. En outre, la mise à jour de la politique des clés pour inclure l'une des clés de condition globale mentionnées dans ce document devrait également justifier un suivi.

Verrouillage de la police à clé avec la clé existante

Un acteur de la menace peut choisir de concentrer ses efforts sur l'impact d'une clé KMS existante. Les possibilités de détection au cours de la phase d'exploitation sont alors limitées. Néanmoins, des alertes personnalisées peuvent être élaborées pour notifier la mise à jour de la politique des clés afin d'inclure l'une des clés de condition globale mentionnées dans le présent document, ce qui pourrait signifier qu'une attaque par ransomware originaire de cloud s'est produite.

Chiffrement avec une clé KMS externe

Bien que ce scénario ne soit pas détaillé dans le présent document, il reste un mécanisme viable pour le chiffrement malveillant de données. Les équipes chargées des opérations de sécurité voudraient être informées lorsque des opérations de chiffrement sont effectuées avec des clés KMS qui ne sont pas hébergées dans un compte sous leur contrôle.

En conclusion

Cloud Les fournisseurs de services mettent à disposition des outils cryptographiques qui, s'ils ne sont pas correctement sécurisés, peuvent être utilisés par des gangs de ransomware pour affecter la disponibilité des données sur le site cloud. Une campagne de ransomware réussie sur le site cloud utilise les services natifs de cloud pour crypter les données avec rapidité et des mécanismes de contrôle d'accès intégrés pour verrouiller l'accès de la victime aux données critiques de l'entreprise.

L'élaboration de modèles architecturaux centralisés pour la gestion des clés est la première étape de la prévention des ransomwares cloud-native ransomware. La gestion centralisée des clés permet à la fois une prévention plus efficace des ransomwares et une image plus cohérente de ce à quoi ressemble un schéma cryptographique normal dans votre domaine cloud .

Bien qu'une posture préventive soit idéale, il est peu probable que la majorité des organisations aient mis en place ces contrôles architecturaux dès le premier jour. En outre, il incombe à chaque organisation, même à celles qui disposent d'environnements très restrictifs, de prévoir le jour où leurs garde-fous seront défaillants. Ainsi, détecter si les données hébergées sur cloud sont touchées par un ransomware devrait être la priorité absolue. Ces stratégies de détection varieront subtilement en fonction de la technique utilisée par l'acteur de la menace, mais elles sont enracinées dans le concept de savoir ce que signifie l'externe pour votre domaine cloud , qu'il s'agisse de la surveillance de l'autorisation d'accès externe, de l'utilisation de clés externes ou de déclarations conditionnelles dans la politique.

---

Références :

¹ Techniques de cryptage des ransomwares : https://medium.com/@tarcisioma/ransomware-encryption-techniques696531d07bb9

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

³ Grants in AWS KMS : https://docs.aws.amazon.com/kms/latest/developerguide/grants.html S3 Ransomware Part 1 : Vecteur d'attaque : https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/ S3 Ransomware Part 2 : Prevention and Defense : https://rhinosecuritylabs.com/aws/s3-ransomware-part-2- prevention-and-defense/