Les attaquants silencieux : exploiter les point de terminaison VPC pour exposer les comptes AWS des buckets S3 sans laisser de traces

La divulgation d’un identifiant de compte AWS peut sembler anodine, mais elle peut constituer une menace pour la sécurité et ouvrir la voie à différentes attaques. En raison du risque encouru, il est fortement recommandé de ne pas inclure votre identifiant de compte AWS dans les noms de service, l’infrastructure ou les ressources accessibles au public.

Bien que la divulgation d’un identifiant de compte ne fournisse pas de voie d’attaque directe, elle peut néanmoins aider les pirates à identifier les configurations vulnérables, à élargir leurs privilèges, à forcer les noms d’utilisateur IAM et à valider leur existence en se basant sur les différences entre les messages d’erreur AWS.

Bien qu’AWS ait corrigé plusieurs techniques d’énumération connues, Varonis Threat Labs a récemment découvert une nouvelle méthode simple et efficace pour récupérer l’ID de compte AWS de n’importe quel bucket S3, en raison d’un manque de nettoyage adéquat des événements CloudTrail Network Activity.

Si des chercheurs tels que Sam Cox ont également exploité les buckets S3 (Simple Storage Service) pour révéler les identifiants de compte, cette vulnérabilité est plus rapide, plus facile et plus discrète, car elle ne génère pas de journaux sur le compte cible.

Nous avons divulgué cette découverte de manière responsable via le programme de divulgation des vulnérabilités (VDP) d’AWS, qui contribue à améliorer la sécurité de l’infrastructure AWS et empêche l’exposition inutile des identifiants de compte. AWS a publié la déclaration suivante :

« AWS a pris connaissance d’une publication intitulée « The Silent Attackers: Exploiting VPC Endpoints to Expose AWS Accounts of S3 Buckets Without a Trace » (Les attaquants silencieux : exploiter les points de terminaison VPC pour exposer les comptes AWS des buckets S3 sans laisser de trace), qui décrit un problème selon lequel les appels intercomptes pour les événements d’activité réseau CloudTrail pourraient renvoyer l’ID du compte du propriétaire de la ressource dans l’événement transmis à l’appelant de l’API. Ce problème ne se produisait que lorsque les comptes de l’appelant API et du propriétaire des ressources étaient différents, et si l’appel échouait en raison d’un accès refusé.

Le 20 juin 2025, nous avons publié une amélioration de la fonctionnalité de défense en profondeur afin de résoudre ce problème. Cette amélioration supprime l’identifiant du compte propriétaire dans ce scénario. Aucune action n’est requise de la part des clients.

Bien que les identifiants de compte, comme toute information d'identification, doivent être utilisés et partagés avec prudence, ils ne sont pas considérés comme des informations secrètes, sensibles ou confidentielles. Étant donné que l'inclusion des identifiants de compte n'est ni nécessaire ni appropriée dans ce cas, nous avons choisi de les supprimer par mesure de précaution pour les clients qui auraient créé des buckets contenant des informations sensibles ou identifiables dans leurs noms, contrairement aux bonnes pratiques.

Nous tenons à remercier Varonis d’avoir signalé ce problème à AWS. »

L'abus et son fonctionnement

En explorant la dernière nouveauté de CloudTrail, les « événements d’activité réseau », nous avons découvert une technique simple qui permet d’exposer l’ID de compte de tout bucket S3 valide, quels que soient ses paramètres de confidentialité. Cette méthode ne laisse aucune trace dans les journaux du compte cible, ce qui en fait une méthode discrète et efficace pour l’énumération.

Le processus consiste à configurer l’environnement AWS de l’attaquant et à effectuer un seul appel API :

1. Déployez un point de terminaison VPC pour les buckets S3 avec une politique qui refuse toutes les demandes vers tous les buckets en dehors de leur propre compte AWS.
2. Définissez un trail CloudTrail qui capture les événements d’activité réseau.
3. Lancer une requête API vers le bucket S3 cible à partir du point de terminaison VPC.

En conséquence, un événement d’activité réseau est créé et enregistré dans le trail d’activité réseau de l’attaquant, et l’ID du compte du bucket S3 est exposé. Étant donné que la demande est refusée au niveau du VPC dans le compte de l’attaquant, aucun journal ne sera généré dans le compte cible.

Pour bien comprendre cela, passons en revue quelques services AWS : CloudTrail, les points de terminaison VPC et S3.

AWS CloudTrail

AWS CloudTrail est le service de journalisation et de surveillance d'AWS. Il enregistre les appels API et les requêtes console (comme la connexion) dans un compte AWS. Quatre types d'événements peuvent être enregistrés :

1. Événements de gestion
2. Événements de données
3. Événements Insight
4. Événements liés à l’activité réseau

Les événements de gestion sont automatiquement enregistrés dans CloudTrail, tandis que l’enregistrement d’autres types d’événements doit être explicitement configuré dans un trail. Chaque fois qu’une identité demande une action sur un service configuré dans un trail, un événement décrivant la demande et la réponse est créé, fournissant des détails sur l’identité, la ressource cible, la réponse, etc.

La journalisation des événements d’activité réseau est une fonctionnalité récemment ajoutée qui offre une visibilité sur les appels API au sein d’un cloud privé virtuel (VPC) à l’aide d’un point de terminaison VPC. Plus précisément, seules les opérations de journalisation des événements d’activité réseau ont été refusées par les points de terminaison VPC. Les événements d’activité réseau prennent en charge plusieurs services, notamment les buckets S3, qui seront générés en raison d’un manque d’autorisations pour un bucket S3 privé à partir d’un compte AWS externe. Un nouvel événement sera créé dans le trail, capturant la requête ayant échoué. De plus, un événement sera créé dans le compte cible pour décrire la tentative ayant échoué. Cependant, les tentatives d’accès ont été refusées en raison de la politique de la pointe VPC. Si un trail est configurée pour enregistrer les événements de gestion ou de données pour les buckets S3, une tentative d’accès refusée n’enregistrera aucun événement dans les trails de gestion ou de données.

En cas d’erreur de gestion ou d’événement lié aux données, la propriété « account id » sous l’objet ressource qui contient l’ID du compte du bucket cible est remplacée par le texte « HIDDEN_DUE_TO_SECURITY_REASONS ». Cela s’explique par le fait que l’identité demandant l’accès à la ressource cible est refusée. La ressource cible se trouvant en dehors du compte AWS, l’ID du compte AWS cible ne doit pas être divulgué.

Cela devrait ressembler à ceci :

	
		
{
  "eventName": "ListObjects",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "199.00.00.00",
  "userAgent": "[.....]",
  "errorCode": "AccessDenied",
  "errorMessage": "Access Denied",
  "requestParameters": { ... },
  "responseElements": null,
  "additionalEventData": { ... },
  "requestID": "[123456654321]",
  "eventID": "[12345678]",
  "readOnly": true,
  "resources": [
    {
      "accountId": "[HIDDEN_DUE_TO_SECURITY_REASONS]",
      "type": "AWS::S3::Bucket",
      "ARN": "arn:aws:s3:::targetbucket"
    },
    {
      "type": "AWS::S3::Object",
      "ARNPrefix": "arn:aws:s3:::targetbucket/*"
    }
  ]
}
	

Point de terminaison VPC AWS

AWS VPC Endpoint permet une connectivité privée entre votre VPC et les services AWS pris en charge sans nécessiter de passerelle Internet, de dispositif NAT ou de connexion VPN.

Un point de terminaison VPC vers le service S3 fonctionne en ajoutant une route à la table de routage de votre VPC, ce qui permet au trafic de circuler directement vers les buckets S3 via le réseau AWS. Lorsqu’un principal (tel qu’une instance EC2, une fonction Lambda ou un utilisateur IAM) envoie une requête API pour effectuer une action S3 à partir du VPC, le trafic est automatiquement acheminé via le point de terminaison VPC.

Les politiques peuvent être attachées à un Endpoint VPC pour contrôler l'accès au service connecté. Ces politiques utilisent la même syntaxe basée sur JSON que les politiques IAM AWS standard. Un exemple de politique d'endpoint VPC permet au trafic de tous les principaux d'effectuer toutes les actions S3 sur toutes les ressources.

	
		
{
  "Version": "2008-10-17",
  "Statement": 
  [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}
 
	

Cette politique n’est pas recommandée, car elle autorise tout le trafic S3 transitant par le VPC vers toutes les ressources par tous les principaux.

Il est important de noter que lorsqu’une stratégie de point de terminaison VPC autorise l’accès, elle n’accorde pas automatiquement l’autorisation à l’identité qui en fait la demande. L’identité doit également disposer des autorisations nécessaires via une stratégie basée sur les ressources ou sur l’identité. Dans ce cas, la demande passe au niveau des ressources, générant un événement d’activité réseau dans la trace, ainsi qu’un événement de gestion ou de données, à la fois dans le compte du demandeur et dans le compte cible, si les traces sont configurées.

Cependant, lorsque la stratégie de point de terminaison VPC refuse explicitement l’accès, la requête est bloquée au niveau de la couche réseau et n’atteint jamais la ressource. Cela se traduit par un seul événement d’activité réseau avec le message d’erreur « VpceAccessDenied » dans le compte du demandeur.

Aucun événement de gestion ou de données n’est créé dans l’un ou l’autre des comptes, ce qui fait que le compte cible n’a absolument pas connaissance de la tentative.

Le refus d’accès à toutes les ressources dans la politique de point de terminaison VPC a été l’étape la plus critique pour exposer les identifiants de compte de bucket auxquels l’identité n’a pas accès.

AWS remplace toujours l’ID de compte d’un bucket cible lorsque l’accès est refusé en raison d’un manque d’autorisations, comme dans le cas d’une erreur « DeniedAccess ». Cependant, lorsque l’erreur « VpceAccessDenied » a été ajoutée, nous avons découvert que les ID de compte n’étaient pas remplacés, exposant ainsi l’ID de compte de tout bucket dès lors que le nom du bucket était connu de l’attaquant.

La stratégie de point de terminaison VPC refusant tout accès se présente comme suit :

	
		
{
  "Version": "2008-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}
	

AWS Simple Storage Service (S3)

Amazon S3 stocke les données dans des conteneurs appelés « buckets », et chaque fichier contenu dans un bucket est appelé « objet ». S3 prend en charge les politiques basées sur les ressources (politiques de bucket) pour contrôler l’accès au niveau du bucket, ainsi que des fonctionnalités de sécurité supplémentaires, telles que le blocage de l’accès public et les contrôles de propriété.

Étant donné que le VPC est associé au point de terminaison VPC, tous les appels API S3 exécutés à l’intérieur du VPC seront refusés par la politique du point de terminaison. Par exemple, le résultat de l’exécution de « aws s3 ls s3://target-bucket » devrait ressembler à ceci :

Comme nous avons configuré un trail pour collecter les événements d’activité réseau, cet événement est apparu dans le trail en quelques minutes. Il ressemblait à ceci :

	
		
{
  "accountId": "2222222222",
 "accessKeyId": "123456789",
  "sessionContext": {
    "sessionIssuer": {
      "type": "Role",
      "principalId": "1234567",
      "arn": "arn:aws:iam::2222222222:role/ec2Role",
      "accountId": "2222222222",
      "userName": "ec2Role"
    },
    "attributes": {
      "creationDate": "2025-05-15T09:22:36Z",
      "mfaAuthenticated": "false"
    },
    "ec2RoleDelivery": "2.0"
  },
  "eventTime": "2025-05-15T09:41:22Z",
  "eventSource": "s3.amazonaws.com",
  "eventName": "GetObject",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "172.00.00.00",
  "errorCode": "VpcAccessDenied",
  "errorMessage": "The request was denied due to a VPC endpoint policy.",
  "requestID": "12344321",
  "eventID": "12341234",
  "resources": [
    {
      "accountID": "external-account-id-is-revealed-here",
      "type": "AWS::S3::Bucket",
      "ARN": "arn:s3:::target-bucket"
    },
    {
      "type": "AWS:S3:Object",
      "ARN": "arn:s3:::target-bucket/bla.txt"
    }
  ]
}
	

L’ID du compte cible a été exposé dans l’objet « Resources » dans l’événement ci-dessus. Comme mentionné précédemment, l’événement n’a été enregistré nulle part ailleurs, car la requête a été refusée en raison du point de terminaison VPC au niveau du réseau.

Depuis qu’AWS a ajouté la suppression des identifiants de compte à ces enregistrements d’activité réseau, l’événement se présente désormais comme suit :

	
		
{
  "accountId": "1111111",
  "accessKeyId": "87654321",
  "sessionContext": {
    "sessionIssuer": {
      "type": "Role",
      "principalId": "654321",
      "arn": "arn:aws:iam::1111111:role/ec2role",
      "accountId": "1111111",
      "userName": "ec2role"
    },
    "attributes": {
      "creationDate": "2025-10-10T08:25:32Z",
      "mfaAuthenticated": "false"
    },
    "ec2RoleDelivery": "2.0"
  },
  "eventTime": "2025-10-10T09:27:27Z",
  "eventSource": "s3.amazonaws.com",
  "eventName": "ListObjects",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "172.00.00.00",
  "errorCode": "VpcAccessDenied",
  "errorMessage": "The request was denied due to a VPC endpoint policy.",
  "requestID": "654321",
  "eventID": "1234-4321",
  "resources": [
    {
      "accountId": "HIDDEN_DUE_TO_SECURITY_REASONS",
      "type": "AWS::S3::Bucket",
      "ARN": "arn:s3:::target-bucket"
    },
    {
      "type": "AWS::S3::Object",
      "ARNPrefix": "arn:s3:::target-bucket/*"
    }
  ]
}
	

Limites

Il est important de noter que cette technique n’a pas directement aidé à découvrir ou à énumérer les buckets S3. Elle ne fonctionnait que si l’attaquant connaissait le nom du bucket cible. Cette technique a permis de découvrir l’ID du compte sur lequel le bucket avait été créé.

Réduire les risques

Cet article détaille une vulnérabilité que j’ai découverte en étudiant une nouvelle fonctionnalité AWS. L’exposition des identifiants de compte via les événements d’activité réseau, même lorsque l’accès aux buckets S3 privés est refusé, nous rappelle que même avec des principes solides tels que le principe du moindre privilège et la protection des données externes, les nouvelles fonctionnalités peuvent introduire des comportements inattendus faciles à négliger.

Pour réduire les risques :

1. Utilisez le chiffrement pour les journaux au repos et en transit, afin de garantir la protection des métadonnées sensibles.
2. Supprimez les identifiants sensibles des journaux afin d’éviter toute divulgation involontaire.
3. Évitez d’exposer les identifiants de compte dans les noms de ressources.
4. Utilisez les point de terminaison VPC et la connectivité privée dans AWS pour réduire davantage la surface d’attaque en isolant le trafic provenant de l’Internet public.

Combinées à une mentalité de sécurité proactive, ces pratiques peuvent aider les équipes à anticiper et à atténuer les risques importants qui peuvent émerger à mesure que les plateformes cloud évoluent et introduisent de nouvelles capacités.

Nous remercions sincèrement l'équipe du programme de divulgation des vulnérabilités d'AWS pour sa réponse rapide et réfléchie tout au long du processus de divulgation.

Protégez votre environnement AWS

Vous ne pouvez pas sécuriser ce que vous ne voyez pas. Obtenez gratuitement une évaluation des risques liés aux données dans le cloud pour découvrir les identifiants de compte exposés, les buckets mal configurés et autres risques silencieux qui se cachent dans votre cloud.