Préambule

Bienvenue dans un nouvel épisode de l'ingénierie de détection AWS avec Elastic. Vous pouvez consulter la publication précédente sur STS AssumeRoot, ici.

Dans cet article, nous allons explorer comment les utilisateurs malveillants exploitent le chiffrement côté serveur d'Amazon S3 avec des clés fournies par le client (SSE-C) pour des opérations de demande de rançon ou d'extorsion. Cette tactique d’utilisation abusive contemporaine illustre les méthodes créatives par lesquelles les adversaires peuvent exploiter les services cloud natifs pour atteindre leurs objectifs financiers.

En tant que lecteur, vous découvrirez les rouages de S3, les workflows SSE-C et les configurations de buckets. Nous allons également passer en revue les étapes de cette technique, discuter des bonnes pratiques pour sécuriser les buckets S3, et fournir des conseils concrets pour élaborer une logique de détection permettant d'identifier les utilisations abusives de SSE-C dans votre environnement.

Cette recherche s'appuie sur une publication récente de l'équipe de recherche Halcyon, qui a documenté le premier cas connu publiquement d'utilisation abusive de SSE-C dans le cadre d'un ransomware. Rejoignez-nous pour approfondir cette menace émergente et découvrir comment garder une longueur d'avance sur les adversaires.

Nous avons publié un gist contenant le code Terraform et le script d'émulation référencés dans cet article. Ce contenu est fourni à des fins éducatives et de recherche uniquement. Veuillez l'utiliser de manière responsable et conformément aux lois et directives applicables. Elastic décline toute responsabilité en cas de conséquences involontaires ou d'utilisation abusive.

Bonne découverte !

Comprendre AWS S3 : principaux concepts et fonctionnalités en matière de sécurité

Avant de nous plonger directement dans l’émulation et ces tactiques, techniques et procédures (TTP), passons brièvement en revue ce qu’inclut AWS S3.

S3 est le service de stockage commun d'AWS qui permet aux utilisateurs de stocker des données structurées ou non structurées dans des ''buckets''. Ces buckets sont similaires aux dossiers que l’on trouve localement sur son système informatique. Les données stockées dans ces buckets sont appelées objets, et chaque objet est identifié de manière unique par une clé d'objet, qui fonctionne comme un nom de fichier. S3 prend en charge de nombreux formats de données, de JSON aux fichiers multimédias et bien d'autres encore, ce qui en fait la solution idéale pour de nombreux cas d'utilisation organisationnels.

bucketsLes configurés peuvent être buckets pour stocker des objets provenant de différents services AWS S3, mais ils peuvent également être alimentés manuellement ou par programmation selon le cas d'utilisation. En outre, les buckets peuvent utiliser la gestion des versions pour assurer la maintenance de plusieurs versions d'objets, ce qui permet de résister aux suppressions ou aux écrasements accidentels. Cependant, la gestion des versions n'est pas toujours activée par défaut, ce qui rend les données vulnérables à certains types d'attaques, telles que celles impliquant des ransomwares ou des suppressions massives. Les configurés peuvent être

L'accès à ces buckets dépend fortement de leurs politiques d'accès, généralement définies lors de leur création. Ces politiques comprennent des paramètres tels que la désactivation de l'accès public afin d'empêcher l'exposition involontaire du contenu des buckets. La configuration ne s'arrête pas là : les buckets ont également leur propre Amazon Resource Name (ARN), ce qui permet de définir des politiques d'accès plus granulaires via des rôles ou des politiques de gestion des identités et des accès (IAM). Par exemple, si l'utilisateur ''Alice'' a besoin d'accéder à un bucket et à ses objets, des autorisations spécifiques, telles que s3:GetObject, doivent être attribuées à son rôle IAM. Ce rôle peut être appliqué directement à Alice sous la forme d'une politique d'autorisation ou à un groupe associé auquel elle appartient.

Bien que ces mécanismes semblent infaillibles, les erreurs de configuration dans les contrôles d'accès (par exemple, des politiques de buckets ou des listes de contrôle d'accès trop permissives) sont une cause fréquente d'incidents de sécurité. Par exemple, à l'heure où nous écrivons ces lignes, environ 325 800 buckets sont accessibles au public, selon buckets.grayhatwarfare.com. Elastic Security Labs a également observé que 30 % des échecs de contrôle de posture d'AWS étaient liés à S3 dans le Rapport 2024 d'Elastic sur les menaces mondiales.

Chiffrement côté serveur sur S3
S3 propose plusieurs options de cryptage pour sécuriser les données au repos. Il s'agit notamment de

• SSE-S3: Les clés de chiffrement sont entièrement gérées par AWS.
• SSE-KMS : les clés sont gérées par le service de gestion des clés (Key Management Service) d'AWS, ce qui permet de personnaliser davantage les politiques relatives aux clés et le contrôle d'accès. Découvrez comment elles sont mises en œuvre dans Elastic.
• SSE-C: Les clients fournissent leurs propres clés de cryptage pour un contrôle accru. Cette option est souvent utilisée pour répondre à des exigences de conformité ou de sécurité spécifiques, mais elle entraîne des coûts opérationnels supplémentaires, tels que la gestion et le stockage sécurisés des clés. Il est important de noter qu'AWS ne stocke pas les clés SSE-C. En revanche, le code HMAC (code d'authentification de message basé sur le hachage) d'une clé est enregistré à des fins de vérification.

Dans le cas de SSE-C, une mauvaise gestion des clés de chiffrement ou une utilisation abusive intentionnelle (par exemple, un ransomware) peut rendre les données définitivement inaccessibles.

Politiques relatives au cycle de vie

Les buckets S3 peuvent également utiliser des politiques de cycle de vie, qui automatisent des actions telles que la transition d'objets vers des classes de stockage moins coûteuses (par exemple, Glacier) ou la suppression d'objets après une période spécifiée. Bien que ces politiques soient généralement utilisées pour optimiser les coûts, elles peuvent être exploitées par des cybercriminels pour planifier la suppression de données critiques, ce qui augmente la pression lors d'un incident lié à une demande de rançon.

Classes de stockage

Amazon S3 propose plusieurs classes de stockage, chacune conçue pour répondre à des modèles d'accès et des besoins de fréquence différents. Bien que les classes de stockage soient généralement choisies pour optimiser les coûts, il est essentiel de les comprendre pour savoir comment le chiffrement et la sécurité interagissent avec le stockage des données.

Par exemple, S3 Standard et Intelligent-Tiering assurent un accès fréquent avec une latence minimale, ce qui les rend adaptés aux applications en direct. En revanche, les classes d'archivage telles que Glacier Flexible Retrieval et Deep Archive introduisent des délais avant que les données ne soient accessibles, ce qui peut compliquer la réponse aux incidents dans les scénarios de sécurité.

Cela devient particulièrement pertinent lorsque le chiffrement est introduit. Le chiffrement côté serveur (SSE) fonctionne dans toutes les classes de stockage, mais le SSE-C (Customer-Provided Keys) transfère la responsabilité de la gestion des clés à l'utilisateur ou à l'adversaire. Contrairement au chiffrement géré par AWS (SSE-S3, SSE-KMS), SSE-C exige que chaque opération de récupération fournisse la clé de chiffrement d'origine, et si cette clé est perdue ou n'est pas fournie par un utilisateur malveillant, les données sont définitivement irrécupérables.

À partir de là, une question cruciale se pose quant aux implications des utilisations abusives de SSE-C qui sont observées : que se passe-t-il lorsqu'un cybercriminel accède à des buckets S3 exposés au public ou mal configurés et qu'il contrôle à la fois la politique de stockage et les clés de chiffrement ?

Ainsi commence : l’utilisation abusive du SSE-C pour les opérations de rançonnage

Dans la section suivante, nous partagerons une approche pratique pour émuler ce comportement dans notre environnement AWS de test en réalisant les étapes suivantes :

1. Déployer une infrastructure vulnérable via le fournisseur d'infrastructure en tant que code (IaC) Terraform
2. Découvrir comment rédiger des requêtes SSE-C en Python
3. Exécuter un script personnalisé pour émuler le comportement du rançongiciel décrit dans l'article de blog de Halcyon

Pré-requis

Cet article traite de la recréation d'un scénario spécifique pour l'ingénierie de détection. Si tel est votre objectif, les éléments suivants doivent d'abord être établis.

• Terraform doit être installé localement
• Python 3.9+ doit également être installé localement pour être utilisé dans l'environnement virtuel et pour exécuter un script d'émulation
• AWS CLI doit être configuré avec des privilèges administratifs pour être utilisé par Terraform lors du déploiement de l'infrastructure.

Déploiement d'une infrastructure vulnérable

Pour notre émulation en boîte blanche, il est important de reproduire une configuration S3 qu'une organisation pourrait avoir dans un scénario réel. Vous trouverez ci-dessous un résumé de l'infrastructure déployée :

• Région: us-east-1 (région de déploiement par défaut)
• Groupe S3: Un panier de données de paie portant un nom unique qui contient des données sensibles et permet un chiffrement contrôlé par l'adversaire.
• Contrôles de la propriété des godets: Enforces "BucketOwnerEnforced" pour empêcher les autorisations basées sur les listes de contrôle.
• Restrictions d'accès au public: L'accès du public est entièrement bloqué afin d'éviter toute exposition accidentelle.
• Utilisateur IAM: Un utilisateur IAM compromis contrôlé par un adversaire et disposant d'autorisations S3 excessives ; aucun profil de connexion n'est attribué, car les informations d'identification de la clé d'accès sont utilisées ailleurs de manière programmatique pour des tâches automatisées.
• Politique IAM: Au niveau du panier et de l'objet, les adversaires ont l'autorisation de.. :
  • s3:GetObject
  • s3:PutObject
  • s3:DeleteObject
  • s3:PutLifecycleConfiguration
  • s3:ListObjects
  • s3:ListBucket
• Appliqué à la fois au niveau du bucket et de l’objet
• Clés d'accès IAM: Les clés d'accès sont générées pour l'utilisateur adverse, ce qui permet un accès programmatique.
• Données factices : des données sensibles simulées (customer_data.csv) sont téléchargées dans le bucket

Il est essentiel de comprendre l'infrastructure pour évaluer le déroulement de ce type d'attaque. L'article de blog Halcyon décrit la méthodologie de l'attaque, mais fournit peu de détails sur la configuration spécifique d'AWS des organisations concernées. Ces détails sont essentiels pour déterminer la faisabilité d'une telle attaque et les étapes nécessaires à sa réussite.

Accessibilité et exposition des buckets

Pour qu’une attaque de cette nature se produise, un utilisateur malveillant doit obtenir l'accès à un bucket S3 par l’une des deux méthodes principales :

Buckets accessibles au public : si un bucket est mal configuré avec une politique d'accès public, un utilisateur malveillant peut interagir directement avec lui, à condition que la politique de permission du bucket autorise des actions telles que s3:PutObject, s3:DeleteObject ou s3:PutLifecycleConfiguration. Ces autorisations sont souvent attribuées par erreur à l'aide d'un caractère générique (*), ce qui signifie que n'importe qui peut exécuter ces opérations.

Informations d'identification compromises: Si un attaquant obtient des informations d'identification AWS (via des fuites d'informations d'identification, du phishing ou des logiciels malveillants), il peut s'authentifier en tant qu'utilisateur IAM légitime et interagir avec S3 comme s'il était le propriétaire du compte.

Dans notre émulation, nous supposons que le bucket n'est pas public, ce qui signifie que l'attaque repose sur des informations d'identification compromises. Cela nécessite que l'adversaire ait obtenu des clés d'accès AWS valides et qu'il ait effectué une découverte de l'infrastructure cloud pour identifier les buckets S3 accessibles. Cela se fait généralement à l'aide d'appels d'API AWS, tels que s3:ListAllMyBuckets, s3:ListBuckets ou s3:ListObjects, qui révèlent les buckets et leur contenu dans des régions spécifiques.

Permissions IAM requises pour l'exécution de l'attaque : Pour chiffrer des fichiers à l'aide de SSE-C et appliquer une politique de suppression avec succès, l'adversaire doit disposer des autorisations IAM appropriées. Dans notre émulation, nous avons configuré des autorisations explicites pour l'utilisateur IAM compromis, mais dans un scénario réel, plusieurs modèles d'autorisation pourraient permettre cette attaque :

• Politiques personnalisées trop permissives: Les organisations peuvent, à leur insu, accorder des autorisations S3 étendues sans contraintes strictes.
• Politiques gérées par AWS : L'adversaire peut avoir obtenu des informations d'identification associées à un utilisateur ou à un rôle ayant AmazonS3FullAccess ou AdministratorAccess.
• Autorisations partielles au niveau de l’objet : si l'utilisateur IAM a AllObjectActions, cela n'autorise que les actions au niveau de l'objet, mais pas les modifications de la politique de cycle de vie ou la liste des buckets, qui sont nécessaires pour récupérer les objets, puis les itérer pour les chiffrer et les remplacer.

L'article de blog Halcyon ne précise pas quelles autorisations ont été utilisées de manière abusive, mais notre émulation en boîte blanche garantit que les autorisations minimales nécessaires sont en place pour que l'attaque fonctionne comme décrit.

Le rôle de l'utilisateur IAM compromis
Un autre facteur critique est le type d'utilisateur IAM dont les informations d'identification ont été compromises. Dans AWS, un cybercriminel n’a pas nécessairement besoin d’informations d’identification pour un utilisateur disposant d’un profil de connexion interactif. De nombreux utilisateurs IAM sont créés exclusivement pour un accès par programmation et ne nécessitent pas de mot de passe pour la console de gestion AWS ni d'authentification multifacteurs (MFA), qui pourraient tous deux constituer des obstacles supplémentaires à la sécurité.

Cela signifie que si les informations d'identification volées appartenant à un utilisateur IAM sont utilisées pour l'automatisation ou l'intégration de services, le cybercriminel aura plus de facilité à exécuter des requêtes API sans rencontrer de défis d'authentification supplémentaires.

Bien que l'article Halcyon documente efficacement la technique utilisée dans cette attaque, il ne donne pas de détails sur la configuration AWS sous-jacente de la victime. Il est essentiel de comprendre l'infrastructure à l'origine des attaques, telle que l'accès aux buckets, les autorisations IAM et les rôles des utilisateurs, pour évaluer le déroulement de ces opérations de rançonnage dans la pratique. Étant donné que ces détails ne sont pas fournis, nous devons formuler des hypothèses éclairées pour mieux comprendre les conditions qui ont permis à l'attaque de réussir.

Notre émulation est conçue pour reproduire les conditions minimales nécessaires à ce type d'attaque, ce qui permet une évaluation réaliste des stratégies de défense et des capacités de détection des menaces. En explorant les aspects techniques de l'infrastructure, nous pouvons fournir des informations plus approfondies sur les mesures d'atténuation potentielles et sur la manière dont les organisations peuvent se défendre de manière proactive contre des menaces similaires.

Configuration de l'infrastructure

Pour le déploiement de notre infrastructure, nous utilisons Terraform comme framework IaC. Pour simplifier cette publication, nous avons stocké la configuration de Terraform et le script d'émulation atomique dans un gist téléchargeable pour un accès facile. Ci-dessous se trouve la structure de fichiers locale attendue une fois ces fichiers téléchargés.

Après avoir configuré les fichiers requis localement, vous pouvez créer un environnement virtuel Python pour ce scénario et installer les dépendances nécessaires. Une fois l'environnement configuré, la commande suivante initialisera Terraform et déploiera l'infrastructure :

Commande : python3 s3\_sse\_c\_ransom.py deploy

Une fois le déploiement terminé, l'infrastructure AWS requise sera en place pour procéder à l'émulation et à l'exécution de l'attaque. Il est important de noter que l'accès public est bloqué et que la politique IAM n'est appliquée qu'à l'utilisateur IAM généré dynamiquement pour des raisons de sécurité. Toutefois, nous vous recommandons vivement de démanteler l'infrastructure une fois les tests terminés ou après avoir recueilli les données nécessaires.

Si vous vous connectez à votre console AWS ou utilisez l'interface de ligne de commande, vous pouvez vérifier que le bucket de la région us-east-1 existe et qu'il contient customer_data.csv, qui, une fois téléchargé, sera en texte brut. Vous noterez également qu'aucun ''ransom.note'' n'existe non plus.

Découvrez comment rédiger des requêtes S3 SSE-C en Python

Avant d'exécuter l'émulation atomique, il est important d'explorer les techniques sous-jacentes qui permettent à un cybercriminel de mener à bien cette attaque.

Pour ceux qui connaissent AWS, les opérations S3 (telles que l’accès aux buckets, la liste des objets ou le chiffrement des données) sont généralement simples lorsque vous utilisez les kits AWS SDK ou de l’interface de ligne de commande AWS. Ces outils simplifient une grande partie de la complexité, permettant aux utilisateurs d'exécuter des opérations sans avoir besoin d'une compréhension approfondie des mécanismes sous-jacents des API. Cela réduit également la barrière de la connaissance pour un cybercriminel qui tenterait d'exploiter ces fonctionnalités de manière abusive.

L'article Halcyon relève toutefois un détail technique essentiel concernant l'exécution de l'attaque :

« L'utilisateur malveillant initie le processus de chiffrement en appelant l'en-tête x-amz-server-side-encryption-customer-algorithm, en utilisant une clé de chiffrement AES-256 qu'il génère et stocke localement. »

La principale différence est l'utilisation de l'en-tête x-amz-server-side-encryption-customer-algorithm, qui est nécessaire pour les opérations de cryptage dans cette attaque. Selon la documentation AWS, cet en-tête SSE-C est généralement spécifié lors de la création d'URL pré-signées et lors de l'utilisation de SSE-C dans S3. Cela signifie que le cybercriminel ne se contente pas de chiffrer les données de la victime, mais qu'il le fait de telle sorte qu'AWS ne stocke pas la clé de chiffrement, ce qui rend la récupération impossible sans la coopération de l'utilisateur malveillant.

Les URL pré-signées et leur rôle dans l'utilisation abusive de SSE-C

Que sont les URL pré-signées ?
URL pré-signés sont des demandes d'API signées qui permettent aux utilisateurs d'effectuer des opérations S3 spécifiques pendant une durée limitée. Ces URL sont couramment utilisées pour partager des objets en toute sécurité sans exposer les informations d'identification AWS. Une URL pré-signée accorde un accès temporaire à un objet S3 et peut être consultée par le biais d'un navigateur ou utilisée de manière programmatique dans des requêtes API.

Dans un environnement AWS typique, les utilisateurs exploitent des SDK ou des wrappers CLI pour les URL pré-signées. Cependant, lors de l'utilisation de SSE-C, AWS requiert des en-têtes supplémentaires pour le chiffrement ou le déchiffrement.

SSE-C et en-têtes HTTP requis
Lorsque vous effectuez des requêtes SSE-C, soit via le SDK AWS, soit via des appels directs à l'API REST S3, les en-têtes suivants doivent être inclus :

• x-amz-server-side-encryption-customer-algorithm: Spécifiez l'algorithme de cryptage, mais il doit être AES256 (noté dans le rapport Halcyon).
• x-amz-server-side-encryption-customer-key: Fournit une clé de cryptage 256 bits, encodée en base64, que S3 peut utiliser pour crypter ou décrypter vos données.
• x-amz-server-side-encryption-customer-key-MD5: Fournit un condensé MD5 de 128 bits codé en base64 de la clé de chiffrement ; S3 utilise cet en-tête pour vérifier l'intégrité du message afin de s'assurer que la clé de chiffrement a été transmise sans erreur ni falsification.

Lorsqu'on recherche des opportunités de détection, ces détails sont cruciaux.

AWS Signature Version 4 (SigV4) et son rôle

Les requêtes adressées à S3 sont soit authentifiées, soit anonymes. Étant donné que le chiffrement SSE-C avec des URL pré-signées nécessite une authentification, toutes les requêtes doivent être signées de manière cryptographique pour prouver leur légitimité. C'est là qu'intervient AWS Signature Version 4 (SigV4).

AWS SigV4 est un mécanisme d'authentification qui garantit que les requêtes API adressées aux services AWS sont signées et vérifiées. Ceci est particulièrement important pour les opérations SSE-C, car la modification d'objets dans S3 nécessite des appels API authentifiés.

Pour cette attaque, chaque demande de chiffrement doit être signée par :

1. Génération d'une signature cryptographique à l'aide d'AWS SigV4
2. Inclure la signature dans les en-têtes de la requête
3. Joindre les en-têtes de chiffrement SSE-C nécessaires
4. Envoi de la requête à S3 pour remplacer l'objet par la version cryptée

Sans une signature SigV4 correcte, AWS rejetterait ces requêtes. Les attaques telles que celle décrite par Halcyon reposent sur des identifiants compromis. Nous le savons car les requêtes n'ont pas été rejetées lors de nos tests. Cela suggère également que les cybercriminels savent qu'ils peuvent exploiter de manière abusive les erreurs de configuration d'AWS S3, telles que des exigences de signature inappropriées, et qu'ils comprennent la complexité des buckets et leur respect des contrôles d'accès aux objets. Cela renforce l'hypothèse selon laquelle l'attaque repose sur des informations d'identification AWS compromises plutôt que sur un bucket S3 exposé et accessible au public, et que les cybercriminels étaient suffisamment compétents pour comprendre les nuances concernant non seulement les buckets S3 et les objets, mais aussi l'authentification et le chiffrement dans AWS.

Détonation de notre émulation atomique

Notre émulation atomique utilisera les informations d'identification ''compromises'' de l'utilisateur IAM sans profil de connexion auquel est associée une politique d'autorisation autorisant plusieurs actions S3 sur notre bucket cible. Pour rappel, l'infrastructure et l'environnement dans lesquels nous menons cette opération ont été déployés à partir de la section ''Configuration de l'infrastructure'', en référence à notre gist commun.

Vous trouverez ci-dessous un workflow étape par étape de l'émulation.

1. Charger les informations d’identification AWS volées (récupérées à partir des variables d’environnement)
2. Établir un client S3 avec des informations d’identification compromises
3. Générer l'URL du point de terminaison S3 (construire l'URL du bucket)
4. Énumérer les objets S3 → s3:ListObjectsV2 (Récupérer la liste d’objets)
5. Générer une clé de chiffrement AES-256 (générée localement)
6. Démarrer la boucle (pour chaque objet dans les buckets)
   1. Générer une requête GET et la signer avec AWS SigV4 (authentifier la requête)
   2. Récupérer un objet depuis S3 → s3:GetObject (extraire des données non chiffrées)
   3. Générer une requête PUT et la signer avec AWS SigV4 (ajouter les en-têtes SSE-C)
   4. Chiffrer et remplacer l'objet dans S3 → s3:PutObject (chiffrer avec SSE-C)
7. Fin de la boucle
8. Appliquez la politique de suppression de 7 jours → s3:PutLifecycleConfiguration (destruction de données à durée limitée)
9. Télécharger la note de rançon sur S3 → s3:PutObject (message d'extorsion laissé à la victime)

Vous trouverez ci-dessous une représentation visuelle de ce workflow d’émulation :

Dans notre script Python, nous avons intentionnellement ajouté des invites qui requièrent l'interaction de l'utilisateur pour confirmer qu'il accepte de ne pas utiliser ce script de manière abusive. Une autre invite générée lors de la détonation bloque l'exécution pour donner à l'utilisateur le temps de mener une enquête AWS, si nécessaire, avant de supprimer les objets S3. Étant donné que le SSE-C est utilisé, les objets sont ensuite chiffrés avec une clé à laquelle Terraform n’a pas accès, ce qui entraînerait donc un échec.

Commande : python s3\_sse\_c\_ransom.py detonate

Après la détonation, les objets de notre bucket S3 seront chiffrés avec SSE-C, une note de rançon aura été téléchargée, et un cycle de vie d'expiration aura été ajouté.

Si vous essayez d'accéder à l'objet customer_data.csv, AWS rejettera la demande car il a été stocké à l'aide du chiffrement côté serveur. Pour récupérer l'objet, une demande signée comprenant la clé de chiffrement AES-256 correcte est requise.

Nettoyage

Le nettoyage de cette émulation est relativement simple. Si vous choisissez de conserver les objets S3, commencez par l'étape 1, sinon passez directement à l'étape 5.

1. Aller dans la région us-east-1
2. Se rendre dans S3
3. Localiser le bucket s3-sse-c-ransomware-payroll-XX bucket
4. Supprimer tous les objets
5. Commande : python s3\_sse\_c\_ransom.py cleanup

Une fois l'opération terminée, tout ce qui a été initialement déployé sera supprimé.

Stratégies de détection et de recherche

Après notre émulation atomique, il est essentiel de partager la façon dont nous pouvons détecter efficacement ce comportement de rançonnage sur la base des logs d'événements API fournis par AWS CloudTrail. Notez que nous utiliserons la Suite Elastic pour l'ingestion des données et le développement initial des requêtes ; cependant, la logique et le contexte des requêtes devraient pouvoir être traduits dans le SIEM de votre choix. Il est également important de noter que les événements de données pour S3 dans votre configuration CloudTrail doivent être définis sur ''Log all events''.

Chiffrement inhabituel des objets AWS S3 avec SSE-C

L'objectif de cette stratégie de détection est d'identifier les requêtes PutObject qui exploitent SSE-C, car les clés de chiffrement fournies par le client peuvent être un indicateur fort d'activité anormale, en particulier si une organisation utilise principalement le chiffrement géré par AWS via KMS (SSE-KMS) ou le chiffrement natif de S3 (SSE-S3).

Dans notre émulation, les requêtes PutObject ont été configurées avec l'en-tête x-amz-server-side-encryption-customer-algorithm défini sur AES256, indiquant à AWS que des clés fournies par le client ont été utilisées pour le chiffrement (SSE-C).

Heureusement, AWS CloudTrail enregistre ces détails de chiffrement dans les paramètres des requêtes, ce qui permet aux équipes de sécurité de détecter une utilisation inhabituelle de SSE-C. Les principaux attributs de CloudTrail à monitorer sont les suivants :

• SignatureVersion: SigV4 → Signale que cette demande a été signée
• SSEApplied : ESS_C → Signale que le chiffrement de la clé du client côté serveur a été utilisé
• bucketName : s3-sse-c-ransomware-payroll-96 → Signaux dont le seau est arrivé à
• x-amz-server-side-encryption-customer-algorithm : AES256 → Signale l'algorithme utilisé pour la clé de chiffrement du client
• clé : customer_data.csv → Indique le nom de l'objet auquel l'application a été faite

Avec ces détails, nous pouvons déjà élaborer une requête de détection de menace qui correspondrait à ces événements et, en fin de compte, à la menace signalée dans le blog Halcyon d'origine.

Bien que cette détection soit large, les organisations doivent l'adapter à leur environnement en se posant les questions suivantes :

• Doit-on s'attendre à des URL pré-signées avec SigV4 pour les opérations sur les buckets S3 ou les objets ?
• Doit-on s'attendre à ce que le SSE-C soit utilisé pour les opérations PutObject dans S3 ou dans ce bucket spécifique ?

Réduction des faux positifs avec de nouveaux types de règles pour les termes
Pour minimiser les faux positifs, nous pouvons exploiter le type de règle New Terms d'Elastic, qui permet de détecter les premières occurrences d'une activité suspecte. Au lieu d'alerter sur chaque correspondance, nous suivons les combinaisons uniques d'utilisateurs IAM et de buckets S3 affectés, en ne générant une alerte que lorsque ce comportement est observé pour la première fois au cours d'une période donnée. Voici quelques-unes des combinaisons uniques que nous recherchons :

• Utilisateurs IAM uniques (ARNs) réalisant le chiffrement SSE-C dans S3.
• Buckets spécifiques où le SSE-C est appliqué.

Ces alertes ne se déclenchent que si cette activité a été observée pour la première fois au cours des 14 derniers jours.

Cette approche adaptative garantit que les cas d'utilisation légitimes sont assimilés au fil du temps, ce qui permet d'éviter les alertes répétées sur des opérations prévues. Elle identifie, dans le même temps, les premières occurrences anormales de SSE-C dans S3, ce qui contribue à la détection précoce des menaces. Si nécessaire, des exceptions aux règles peuvent être ajoutées pour des ARNs d'identités d'utilisateurs spécifiques, des buckets, des objets ou même des adresses IP sources afin d'affiner la logique de détection. En intégrant le contexte historique et les bases comportementales, cette méthode améliore la fidélité du signal, ce qui augmente à la fois l'efficacité des détections et la capacité d'exploitation des alertes.

Références des règles

Chiffrement inhabituel des objets AWS S3 avec SSE-C
Chiffrement excessif des objets AWS S3 avec SSE-C

Conclusion

Nous vous remercions sincèrement d'avoir pris le temps de lire cette publication et, si vous l'avez fait, d'avoir vous-même essayé l'émulation. Les tests en boîte blanche jouent un rôle crucial dans la sécurité du cloud, car ils nous permettent de reproduire des menaces réelles, d'analyser leurs schémas comportementaux et de développer des stratégies de détection efficaces. Les attaques basées sur le cloud devenant de plus en plus répandues, il est essentiel de comprendre les outils derrière les tactiques des cybercriminels et de partager les résultats des recherches avec l'ensemble de la communauté de la sécurité.

Si vous souhaitez découvrir notre ensemble de règles de détection AWS, vous pouvez le trouver ici : Règles de détection AWS Elastic. Nous apprécions également les contributions visant à améliorer notre ensemble de règles. Vos efforts contribuent à renforcer les défenses collectives, et nous les apprécions beaucoup !

Nous encourageons toute personne intéressée à consulter la publication d'Halcyon et nous les remercions par avance d'avoir partagé leurs recherches.

À bientôt !

Références importantes :

Blog de Halcyon Research sur SSE-C ItW
Code d'émulation Elastic pour SSE-C sur AWS
Ensemble de règles prédéfinies de détection des menaces AWS d'Elastic
Référentiel de règles de détection prédéfinies Elastic
Règle : Chiffrement inhabituel des objets AWS S3 avec SSE-C
Règle : Chiffrement excessif d'objets AWS S3 avec SSE-C Chiffrement excessif d'objets AWS S3 avec SSE-C