Une étude de cas — Partie 1

Introduction

Nous sommes passionnés par la réponse aux incidents dans le cloud, c'est pourquoi nous avons décidé de partager certaines de nos connaissances sur la base d'un cas IR récent dans AWS. Cette série de blogs en 3 parties est rédigée par Cado Security et Invictus Incident Response .

Fond

Un incident a été découvert lors d'un audit de compte de l'environnement Amazon d'un client. Un nouveau compte super utilisateur a été trouvé et personne ne l'a reconnu, ce qui a déclenché un incident. Dans ce blog, nous allons parcourir l'incident en utilisant la journalisation native dans le cloud et en tirant parti de la plate-forme Cado Response pour notre enquête.

Questions d'enquête

• Quand le compte a-t-il été créé ?
• Comment le compte a-t-il été créé ?
• Quelles actions ont été effectuées avec le compte ?
• Existe-t-il d'autres traces d'activités suspectes ?

Nous suivrons les étapes standard du guide de gestion des incidents informatiques comme rappel, il y a quatre étapes :

1. Préparation
2. Acquisition
3. Traitement et analyse
4. Activité post-incident

Acquisition
Pour l'acquisition des données de journal, nous utilisons notre script open-source Invictus-AWS ( GitHub ). Invictus-AWS peut être exécuté dans une organisation AWS ou un compte AWS pour énumérer automatiquement la configuration AWS utilisée et la journalisation activée. Le script extraira également toute la journalisation disponible au sein d'une organisation/compte AWS. Ce script a été exécuté et un compartiment S3 a été créé contenant tous les journaux disponibles qui ressemble à ceci :

Traitement
Comme nous pouvons le voir dans l'image ci-dessus, il existe une journalisation par défaut CloudTrail, mais également une journalisation supplémentaire telle que les journaux de flux VPC et la journalisation d'audit S3. Pour commencer notre enquête, nous traiterons d'abord le journal CloudTrail pour analyse. Pour l'analyse, nous utilisons une combinaison de l'outil de ligne de commande jq ( GitHub ) et de Splunk ( Website ).

Avec jq, nous n'avons pas besoin d'analyser les données, vous pouvez interroger directement les données json. Par exemple, pour ouvrir le journal CloudTrail et ne voir que EventTime et EventName, nous pouvons utiliser la requête suivante :

jq . cloudtrail.json

JQ peut également effectuer un filtrage et une recherche avancés, c'est très rapide, mais le langage de requête peut être un peu difficile et la lecture des informations à partir de la console n'est pas toujours la plus facile à analyser. Passons donc au chargement des journaux dans Splunk, nous utiliserons jq pour manipuler nos données afin de nous assurer que Splunk les comprend.

Étape 1 - Extraire le champ d'événement CloudTrail

Dans la première étape, nous allons extraire le champ CloudTrailEvent du fichier Cloudtrail.json. Ce champ contient l'intégralité de l'événement au format json.

chat cloudtrail.json| jq -r '.Events[].CloudTrailEvent' > cloudtrailevents.json

Étape 2 - Charger les événements dans Splunk

Pour charger le fichier json dans Splunk, définissez le type de source sur cloudtrail_json et assurez-vous d'ajouter ce qui suit dans votre fichier props.conf( reference ) pour analyser les événements CloudTrail.

### props.conf ###
[cloudtrail_json]
DATETIME_CONFIG =
INDEXED_EXTRACTIONS = json
KV_MODE = aucun
LINE_BREAKER = ([\r\n]+)
NO_BINARY_CHECK = vrai
TIMESTAMP_FIELDS = eventTime
désactivé = faux
pulldown_type = vrai

Une fois que vous avez chargé vos données, cela devrait ressembler à ceci :

Analyse
Au début d'un engagement de réponse à un incident, il existe souvent un indicateur ou un fait connu à partir duquel vous pouvez commencer votre enquête. Dans ce cas, il s'agit du compte inconnu DevOps3 . N'oubliez pas que nous devons répondre aux questions suivantes :

1. Quand et comment le compte a-t-il été créé ?
2. Quelles actions ont été effectuées avec le compte ?
3. Existe-t-il d'autres traces d'activités suspectes ?

Voyons donc si nous pouvons en savoir plus sur ce compte et sa création dans le journal CloudTrail. Nous allons simplement rechercher le nom du compte et trier d'abord sur l'événement le plus ancien pour voir ce que la première fois que ce compte a été mentionné.

Le premier événement que nous trouvons lié à l'utilisateur est l' événement CreateUser qui est attendu pour le premier événement d'un nouveau compte. Cette entrée de journal dans CloudTrail contient de nombreuses informations pour notre réponse aux incidents.

recherche utilisée : index=nom_de_l'index DevOps3 |table eventTime,eventName,requestParameters.userName,sourceIPAddress,sessionCredentialFromConsole,userIdentity.arn

Nous pouvons voir le nom du compte d'utilisateur nouvellement créé dans le requestParameters.userName et le userIdentity.arn qui a demandé la création de ce compte. Le champ sessionCredentialFromConsole est défini sur true, ce qui signifie que ce compte a été créé à partir de la console de gestion AWS ( référence ). Nous pouvons également voir le compte utilisateur DevOps1-bpvpb et la clé d'accès associée qui a créé ce compte. Après notre recherche initiale, nous pouvons répondre aux deux premières questions d'investigation :

Quand le compte a-t-il été créé ?
Heure de création : 26-10-2022 à 21:29:03
(toutes les heures dans CloudTrail sont en UTC)

Comment le compte a-t-il été créé ?
Créé par : DevOps1-bpvbp
Méthode de création : AWS Management Console

Creusons un peu plus sur le compte qui a créé le compte. Étant donné que la création du compte a été effectuée via la console de gestion, les journaux n'affichent pas l'adresse IP externe utilisée pour cette action. Mais nous savons que l'activité s'est produite depuis la console de gestion. Dans AWS, nous pouvons filtrer spécifiquement sur les connexions à la console de gestion. Si nous filtrons sur eventName=ConsoleLogin ( reference ) avec le compte DevOps1-bpvpb nous voyons l'événement suivant 6 minutes avant la création du nouveau compte :

recherche utilisée : index=nom_de_l'index eventName=ConsoleLogin DevOps1-bpvbp

Les champs les plus pertinents ont été soulignés, nous pouvons voir que cet utilisateur n'avait pas activé MFA. Nous pouvons également voir l'adresse IP source à partir de laquelle l'utilisateur s'est connecté à la console. Nous avons maintenant une image plus claire de ce qui s'est passé :

Heure de création : 26-10-2022 à 21:29:03
Créé par : DevOps1-bpvbp
Méthode de création : AWS Management Console
Adresse IP utilisée : 185.195.232.111

Quelles actions ont été effectuées avec le compte ?

Nous pouvons maintenant essayer de déterminer quelles activités se sont produites avec le compte nouvellement créé. Pour avoir une idée de l'activité qui s'est produite dans un environnement AWS, nous pouvons rechercher le compte d'utilisateur et créer une table des noms d'événements générés dans CloudTrail pour ce compte.

recherche utilisée : index=nom_de_l'index devops3 | nombre de statistiques par nom d'événement

Il n'y a qu'un seul événement lié à ce compte, qui est sa création. À ce stade, nous sommes en mesure de répondre à la troisième question d'enquête. À ce stade, il s'agit de deviner quelles sont les intentions des acteurs de la menace pour le compte nouvellement créé, l'une des options consiste à l'utiliser comme méthode de persistance.

Quelles actions ont été effectuées avec le compte ?
Aucune action effectuée avec le compte DevOps3

Existe-t-il d'autres traces d'activités suspectes ?

Passons maintenant à l'analyse de l'activité de DevOps1-bpvbp, le compte qui a créé DevOps3 pour déterminer s'il existe une activité suspecte supplémentaire utilisant ce compte.

La première étape consiste à rechercher l'activité de ce compte autour de la période de l'attaque :

recherche utilisée : index=nom_de_l'index DevOps1-bpvbp |table _time, eventSource,eventName,userIdentity.arn

Ainsi, dans la même minute que le compte utilisateur DevOps3 a été créé, un événement StartSession ( référence ) a été enregistré avec le même compte.

StartSession, initie une connexion à une cible (par exemple, un nœud géré) pour une session Session Manager. Renvoie une URL et un jeton qui peuvent être utilisés pour ouvrir une connexion WebSocket pour envoyer des entrées et recevoir des sorties.

Lorsque nous inspectons l'événement, nous pouvons voir des détails supplémentaires sur ce qui s'est passé :

Sur la base de l'événement, nous pouvons conclure qu'une session a été démarrée à partir du compte DevOps1-bpvbp vers une instance avec l'identifiant i-08e56d6b6c0439daf. Encore une fois, cette activité s'est produite depuis la console de gestion, c'est pourquoi nous ne pouvons pas utiliser l'adresse IP source pour trouver cet événement. À ce stade de notre enquête, nous allons enquêter sur ce qui s'est passé sur cette instance spécifique pour déterminer s'il s'agit d'une activité malveillante. Nous ne pouvons plus compter uniquement sur les journaux CloudTrail car ils n'enregistrent pas toutes les activités qui se produisent à partir d'un hôte.

Prochainement… la partie 2, où nous commencerons à enquêter sur l'instance avec la plateforme Cado Security.

PS : L'ID de compte AWS et l'adresse IP source ont été modifiés pour les captures d'écran de ce blog.

À propos de Cado Security

Cado Security est la société d'automatisation des enquêtes et des réponses dans le cloud. La plate-forme Cado tire parti de l'échelle, de la vitesse et de l'automatisation du cloud pour fournir sans effort des détails de niveau médico-légal dans les environnements cloud, conteneurs et sans serveur.

À propos de la réponse aux incidents d'Invictus

Nous sommes une société de réponse aux incidents spécialisée dans l'accompagnement des organisations confrontées à une cyberattaque. Nous aidons nos clients à rester invaincus !

Assistance en cas d' incident, contactez [email protected] ou rendez-vous surhttps://www.invictus-ir.com/247

Questions ou suggestions contactez-nous à [email protected]