Ce qu'il faut savoir sur les ransomwares AWS

Aussi problématique que soit le ransomware dans les centres de données, j'étais quelque peu sceptique quant à son ampleur dans le cloud. Personnellement, je n'avais rencontré aucun incident, et j'ai commencé à penser que la menace était plus théorique qu'autre chose. Il s'avère que je me trompais un peu. Bon, complètement. Non seulement le problème est plus important que je ne le pensais, mais le schéma d'attaque était différent de ce à quoi je m'attendais au sein d'Amazon Web Services (AWS).

Lors de la conférence AWS re:Inforce, j'ai assisté à une excellente session animée par Kyle Dickinson, Megan O'Neil et Karthik Ram. La salle était comble et le responsable a dû refuser des dizaines de personnes. Cet article est une forme de synthèse de cette session, associée à mes propres expériences et recommandations concernant le ransomware sur AWS. Les erreurs et omissions éventuelles me sont imputables, et non à eux.

Points clés :

• Les auteurs de ransomwares ciblent de plus en plus les environnements Amazon Web Services (AWS), en exploitant souvent les failles d'accès liées aux identités, les configurations de stockage et le manque de visibilité entre les services.
• Les buckets Amazon S3 constituent un point d'entrée courant : les attaquants chiffrent ou suppriment des données critiques en raison de politiques trop faibles ou d'une absence d'application du chiffrement.
• Une défense efficace contre les ransomwares dans le cloud exige une stratégie en couches, incluant le contrôle des accès, la surveillance en temps réel et des processus de réponse rapides.
• FireMon renforce la posture de sécurité des données en surveillant en continu les erreurs de configuration, en appliquant les politiques à grande échelle et en offrant une visibilité qui aide les équipes à réagir plus vite aux menaces de ransomware dans le cloud.

Le ransomware sur Amazon AWS est-il un problème

Oui. Il s'avère que le ransomware sur AWS pose davantage de problèmes que je ne le pensais initialement. De vrais clients sont touchés, la menace n'est pas seulement théorique.

Comment se déroule une attaque par ransomware sur Amazon

J'aborderai le vecteur d'exploitation initial dans la question suivante, mais il existe quatre techniques d'attaque par ransomware possibles sur Amazon :

• Les attaquants compromettent une instance (souvent par hameçonnage d'un utilisateur ou d'un administrateur, pas toujours par compromission directe), puis installent leur malware pour chiffrer les données et se propager vers d'autres instances accessibles. Cela ne diffère en rien d'un ransomware dans un centre de données, puisqu'aucun élément spécifique au cloud n'entre en jeu.
• L'attaquant copie les données d'un bucket S3 puis supprime les données d'origine. Il s'agit du ransomware Amazon cloud natif le plus fréquemment observé.
• Un acteur malveillant chiffre les données S3 à l'aide d'une clé KMS qu'il contrôle. Ce scénario est plus théorique que réel, pour plusieurs raisons. Il est bien plus simple de supprimer un objet ou un bucket que de le chiffrer rétroactivement.
• Un attaquant intervient sur les données d'un autre service de stockage pour les verrouiller ou les supprimer. Je reste volontairement vague, car ce cas n'est pas observé et la plupart de ces services comportent des limitations internes et une résilience intégrée qui rendent un ransomware difficile à mener.

Les ransomwares ciblent le plus souvent les buckets AWS S3, les attaquants copiant puis supprimant les données. Les instances et serveurs peuvent également être la cible des mêmes malwares que ceux utilisés contre les centres de données. Quelques attaques théoriques ne sont pas réellement observées dans la nature.

Une nouvelle attaque par ransomware sur Amazon gagne toutefois du terrain : les groupes de ransomware ont commencé à chiffrer les données sur place en utilisant le chiffrement côté serveur d'AWS avec des clés fournies par le client (SSE-C). Cette technique permet aux attaquants de chiffrer directement les fichiers dans vos buckets S3 sans les supprimer ni déclencher les alertes standard, et la récupération est impossible sans la clé de chiffrement personnalisée de l'attaquant.

Comment les acteurs malveillants obtiennent-ils l'accès nécessaire pour mener des attaques par ransomware sur Amazon Web Services

Des identifiants exposés. Presque toujours des clés d'accès statiques, mais parfois des clés obtenues depuis une instance compromise (via le service de métadonnées). Bref, à peu près la manière dont fonctionnent presque toutes les attaques de sécurité dans le cloud.

Quel est le déroulement d'une attaque par ransomware sur S3

Je me concentrerai sur le scénario de ransomware visant les buckets S3, puisqu'il s'agit du scénario cloud natif qui nous intéresse.

• L'attaquant obtient des identifiants.
• L'attaquant utilise ces identifiants pour effectuer une reconnaissance afin de déterminer les appels d'API autorisés et d'identifier les ressources auxquelles il peut accéder.
• L'attaquant découvre qu'il dispose de droits d'écriture S3 et d'un accès en liste/lecture permettant d'identifier les buckets. Notez qu'il peut ne pas disposer des privilèges List mais obtenir les noms de buckets par d'autres sources, comme le DNS, GitHub ou d'autres emplacements. Ce cas est beaucoup moins probable.
• L'attaquant copie ou déplace les données vers un autre emplacement, qui ne se trouve pas nécessairement dans AWS.
• L'attaquant supprime les objets/fichiers sources.
• L'attaquant dépose une demande de rançon (ou l'envoie par e-mail).

Lors de campagnes récentes, les attaquants ont également commencé à utiliser les politiques S3 Object Lifecycle Management pour marquer les fichiers chiffrés en vue d'une suppression sous sept jours, accentuant la pression pour payer la rançon. Ils laissent souvent un fichier warning.txt dans le répertoire concerné, avec une adresse de portefeuille Bitcoin et un identifiant unique de victime.

Comme tout cela est automatisé, le processus peut démarrer moins d'une minute après l'exposition d'un identifiant.

Comment détecter un ransomware sur Amazon S3

Eh bien, si vous ne pouvez pas passer directement à la prévention des ransomwares S3…

L'attaquant laisse généralement un message avec ses coordonnées afin que vous puissiez lui envoyer des Bitcoins, ce qui est pratique. Mais il y a fort à parier que la plupart d'entre vous souhaitent repérer le problème avant cela. Parcourons la séquence d'une attaque par ransomware sur Amazon S3 pour voir où il est possible d'intervenir.

D'abord, vous voudrez activer une surveillance plus approfondie de vos buckets sensibles. Comme cet article est déjà plus long que je ne le souhaiterais, je passerai sur les détails de l'identification et de la gestion de ces buckets pour me concentrer sur quelques sources clés à envisager. Pour des raisons de coût, ne comptez pas les activer pour l'ensemble de votre environnement :

• CloudTrail, bien entendu.
• Les CloudTrail Data Events pour tous les buckets qui comptent pour vous. Cela représente un coût supplémentaire.
• GuardDuty.
• Facultatif : Security Hub. C'est le meilleur moyen d'agréger GuardDuty et les autres services de sécurité AWS sur l'ensemble de vos comptes.
• Éventuellement : les S3 Server Access Logs. Si vous disposez des CloudTrail Data Events, vous obtenez l'essentiel de ce que vous pouvez souhaiter. Mais les journaux S3 sont gratuits à générer (vous ne payez que le stockage) et capturent quelques événements que CloudTrail peut manquer (par exemple, les échecs d'authentification). Ils mettent aussi plusieurs heures à apparaître, ils ne sont donc pas utiles lors d'un incident en cours. Pour en savoir plus, consultez ce guide de l'utilisateur.

Maintenant que nous avons traité la surveillance, examinons les sept étapes du processus de détection :

1. Détecter les identifiants exposés et l'activité de reconnaissance

Le processus de détection commence par l'identification, par vous-même ou par un tiers, de clés AWS divulguées publiquement ou compromises, ainsi que de toute activité suspecte. Généralement par l'analyse d'un dépôt courant, comme GitHub. Amazon Web Services a un jour trouvé l'une des miennes et m'a envoyé un e-mail. Oups.

Vos détections de reconnaissance d'identifiants de compte fonctionneront ici. Quelques options :

• Les findings GuardDuty, comme l'exfiltration d'identifiants. Ils accusent toutefois un délai d'environ 20 minutes et des techniques d'évasion existent
• L'appel d'API GetCallerIdentity n'est pas toujours malveillant, mais ce n'est pas un appel que vous devriez observer fréquemment dans des comptes de production
• GetAccountAuthorizationDetails devrait déclencher une alerte à chaque fois
• Plusieurs appels d'API en échec provenant d'une même entité IAM

2. Surveiller l'énumération S3

Nous nous concentrons désormais sur les détections de ransomware AWS indiquant que l'attaquant s'intéresse à S3. Vous remarquerez sans doute qu'une détection précoce à ces phases peut être difficile en raison du bruit, mais gardez à l'esprit qu'elle sera plus viable dans des situations telles que des comptes de production gérés via CI/CD avec un accès humain limité. Cela pourrait même vous inciter à adopter davantage de modèles cloud natifs.

Les findings GuardDuty pour S3 relatifs aux événements de découverte, qui doivent être activés en plus de la simple activation de GuardDuty, selon la configuration de votre compte et de votre organisation. Filtrez les Read et List Management ainsi que les Data Events en échec sur le service S3. Vous pourriez surprendre l'attaquant en pleine exploration. Vous pouvez le faire dans votre SIEM, mais il est également simple de créer des CloudWatch Metrics Filters pour cela.

3. Surveiller les lectures et copies d'objets

Ici, vous une surveillance continue pour déterminer si l'attaquant lit les objets et en réalise des copies. S'il lit (copie) puis supprime chaque objet, cette activité peut se confondre avec la phase suivante.

4. Détecter les suppressions massives et le dépôt de la demande de rançon

C'est le stade critique. L'attaquant ne se contente plus d'explorer : il exécute l'attaque et supprime les données copiées. Les résultats GuardDuty relatifs à l'exfiltration et à l'impact sur S3 se déclenchent alors. N'oubliez pas qu'il faut au moins 20 minutes pour qu'ils se déclenchent et que, selon le nombre d'objets, cet indicateur peut être tardif. CloudTrail Insights, si vous l'utilisez, signalera le grand nombre d'événements Write utilisés pour déplacer les données.

Vous pouvez créer vos propres détections pour un grand nombre d'appels de suppression. Selon votre environnement et vos schémas d'activité habituels, ce nombre peut être faible et se déclencher plus rapidement que GuardDuty. Votre SIEM et les filtres de métriques CloudWatch sont de bonnes options.

5. Repérer les abus de SSE-C (chiffrement silencieux)

Surveillez l'apparition soudaine d'en-têtes SSE-C dans des appels d'API comme PutObject : c'est le signe que les données sont peut-être chiffrées avec la clé de l'attaquant. Comme AWS ne journalise qu'un hachage HMAC des opérations, toute récupération forensique classique est impossible sans surveillance proactive.

6. Utiliser des buckets canaris et la détection KMS

Les organisations matures peuvent semer dans leurs comptes des buckets ou objets canaris et générer une alerte à la moindre opération portant sur ces buckets. Bien qu'il s'agisse d'un schéma d'attaque moins courant, vous pouvez alerter les équipes sur l'utilisation d'une clé KMS depuis l'extérieur de votre compte.

7. Escalade et réponse à incident

Si vous détectez l'attaque à ce stade, vous êtes déjà compromis. Il est temps de réagir. Prévenez les forces de l'ordre et sollicitez l'équipe de réponse aux incidents clients d'AWS.

Protection contre les ransomwares AWS : comment protéger mon entreprise

Pour mener à bien une attaque par ransomware sur AWS, l'acteur malveillant a besoin de trois conditions :

• un accès à des identifiants ;
• des autorisations de lecture et d'écriture dans S3 ;
• la capacité de supprimer des objets de manière irrécupérable.

La première couche de la prévention des ransomwares consiste à verrouiller IAM, puis à utiliser les outils de résilience intégrés d'AWS. C'est facile à dire et difficile à faire, mais voici une liste de contrôle axée sur S3, en laissant de côté la plupart des mesures d'hygiène et de contrôle courantes :

• N'autorisez aucun utilisateur IAM doté de clés d'accès statiques. Si ce n'est pas possible, utilisez impérativement votre outillage pour identifier les utilisateurs disposant d'autorisations de suppression dans S3.
• Exigez la MFA pour les utilisateurs SSO ou fédérés. Toujours et sans exception.
• Faites en sorte que les administrateurs basculent vers un autre rôle IAM lorsqu'ils doivent effectuer des opérations de suppression. Vous pouvez même séparer entièrement les autorisations de lecture et de suppression dans des rôles distincts.
• Si une instance a besoin d'accéder à S3, veillez à restreindre au maximum les autorisations, aux appels d'API strictement nécessaires et aux ressources strictement nécessaires.
• Désactivez SSE-C, sauf en cas d'absolue nécessité. Cela contribue à prévenir les attaques par chiffrement silencieux, qui peuvent vous priver de vos données sans aucune possibilité de récupération.
• Utilisez un point de terminaison VPC pour accéder au bucket, et ajoutez une politique de ressource qui n'autorise la suppression que depuis le VPC source. L'attaquant ne pourra alors pas utiliser les identifiants en dehors de ce VPC.
• Activez la gestion des versions, AWS Backup et/ou la réplication de buckets. Ces mesures garantissent que vous ne perdrez pas l'accès à vos données. Sauf, bien sûr, si vous compromettez gravement vos politiques IAM et laissez le champ libre à l'attaquant. Certaines de ces options doivent être activées à la création du bucket : une opération de migration peut donc s'avérer nécessaire.

Vous remarquerez que je passe sous silence Block Public Access. C'est une excellente fonctionnalité, mais de nombreuses organisations peinent à la déployer à grande échelle, car elles ont besoin de certains buckets publics et elle n'est d'aucun secours face aux attaques exploitant des identifiants exposés.

Tout cela demande des efforts et engendre des coûts : je recommande donc vivement de se concentrer d'abord sur les buckets réellement critiques. Il existe des stratégies plus avancées, en particulier pour les environnements de grande taille, qui ne tiennent pas dans un article, mais écrivez-moi si vous souhaitez en discuter.

Qu'avez-vous appris de nouveau sur les ransomwares S3 lors de la session Re:Inforce

J'ignorais que les ransomwares visant S3 étaient aussi répandus. J'ignorais également que la technique d'attaque privilégiée consistait à copier puis à supprimer. Je pensais qu'elle reposait sur le chiffrement KMS, et l'on comprend parfaitement pourquoi cette approche reste théorique et rare. Je connaissais les mécanismes de détection et de défense, mais les intervenants d'AWS ont su les articuler de façon très claire et exploitable. Cette présentation a largement dépassé mes attentes.

Comment FireMon peut-il aider mon entreprise à se protéger des ransomwares S3

Nous avons un nouveau produit IAM en bêta pour les privilèges Just in Time, qui devrait être disponible prochainement. Nous proposons également des contrôles de posture et des détecteurs de menaces dans DisruptOps pour identifier les buckets à risque et alerter sur les activités malveillantes, telles que les attaques par ransomware. Écrivez-moi si vous souhaitez en discuter, ou même si vous voulez simplement des conseils généraux sur les options AWS évoquées dans cet article.

Réservez une démo dès aujourd'hui et découvrez comment FireMon peut vous aider à protéger votre entreprise contre les ransomwares AWS.