Examiner et contrer les menaces

Ce document fournit des conseils informels pour vous aider à examiner les résultats d'activités suspectes dans votre environnement Google Cloud provenant d'acteurs potentiellement malveillants. Ce document fournit également des ressources supplémentaires pour mettre en contexte les résultats de Security Command Center. En suivant ces étapes, vous pouvez comprendre ce qui s'est passé lors d'une attaque potentielle et développer les réponses possibles pour les ressources affectées.

L'efficacité des techniques décrites sur cette page n'est pas garantie contre les menaces passées, actuelles ou futures. Pour savoir pourquoi Security Command Center ne fournit pas de conseils officiels pour la résolution des menaces, consultez la page Corriger les menaces.

Avant de commencer

Vous devez disposer des rôles IAM (Identity and Access Management) appropriés pour afficher ou modifier les résultats et les journaux, et pour modifier les ressources Google Cloud . Si vous rencontrez des erreurs d'accès dans Security Command Center, demandez de l'aide à votre administrateur et consultez la page Contrôle des accès pour en savoir plus sur les rôles. Pour résoudre les erreurs de ressources, consultez la documentation des produits concernés.

Comprendre les menaces détectées

Event Threat Detection génère des résultats de sécurité en faisant correspondre les événements de vos flux de journaux Cloud Logging aux indicateurs de compromission (IoC) connus. Les IoC, développés par des sources de sécurité internes de Google, identifient les failles et les attaques potentielles. Event Threat Detection détecte également les menaces en identifiant les tactiques, techniques et procédures antagonistes connues dans votre flux de journalisation, et en détectant les écarts par rapport au comportement passé de votre organisation ou de votre projet. Si vous activez le niveau Premium de Security Command Center au niveau de l'organisation, Event Threat Detection peut également analyser vos journaux Google Workspace.

Container Threat Detection génère des résultats en collectant et en analysant les comportements de bas niveau observés dans le noyau invité des conteneurs.

Les résultats sont écrits dans Security Command Center. Si vous activez le niveau Premium de Security Command Center au niveau de l'organisation, vous pouvez également configurer l'écriture des résultats dans Cloud Logging.

Examiner les résultats

Pour examiner les menaces détectées dans la console Google Cloud , procédez comme suit :

1. Dans la console Google Cloud , accédez à la page Résultats de Security Command Center.

   Accéder

2. Si nécessaire, sélectionnez votre projet, votre dossier ou votre organisation. Google Cloud

3. Dans la section Filtres rapides, cliquez sur un filtre approprié pour afficher le résultat dont vous avez besoin dans le tableau Résultats de la requête de résultats. Par exemple, si vous sélectionnez Event Threat Detection ou Container Threat Detection dans la sous-section Nom à afficher pour la source, seuls les résultats du service sélectionné s'affichent dans les résultats.

   Le tableau est rempli avec les résultats de la source sélectionnée.

4. Pour afficher les détails d'un résultat spécifique, cliquez sur le nom du résultat sous Category. Le volet de détails du résultat se développe pour afficher un résumé des détails du résultat.

5. Pour afficher la définition JSON du résultat, cliquez sur l'onglet JSON.

Les résultats fournissent les noms et les identifiants numériques des ressources impliquées dans un incident, ainsi que les variables d'environnement et les propriétés des éléments. Vous pouvez utiliser ces informations pour isoler rapidement les ressources concernées et déterminer le champ d'application potentiel d'un événement.

Pour faciliter votre enquête, les résultats de la détection de menaces contiennent également des liens vers les ressources externes suivantes :

• Entrées du framework MITRE ATT&CK. Le framework décrit les techniques d'attaque contre les ressources cloud et fournit des conseils pour s'en protéger.

• VirusTotal, un service appartenant à Alphabet qui fournit du contexte sur les fichiers, URL, domaines et adresses IP potentiellement malveillants. Le champ Indicateur VirusTotal, s'il est disponible, fournit un lien vers VirusTotal pour vous aider à examiner plus en détail les problèmes de sécurité potentiels.

  VirusTotal est une offre payante distincte avec des limites d'utilisation et des fonctionnalités différentes. Il vous incombe de comprendre et de respecter les règles d'utilisation de l'API VirusTotal, ainsi que les coûts associés. Pour en savoir plus, consultez la documentation VirusTotal.

Les sections suivantes décrivent des réponses potentielles aux menaces détectées.

Désactivation des menaces détectées

Une fois que vous avez résolu un problème qui a déclenché un résultat de menace, Security Command Center ne définit pas automatiquement l'état du résultat sur INACTIVE. L'état d'un résultat de menace reste ACTIVE, sauf si vous définissez manuellement la propriété state sur INACTIVE.

En cas de faux positif, vous pouvez laisser l'état du résultat sur ACTIVE et l'ignorer.

Pour les faux positifs persistants ou récurrents, créez une règle de blocage. Définir une règle de mise en sourdine peut réduire le nombre de résultats que vous devez gérer, ce qui facilite l'identification d'une véritable menace lorsqu'elle se produit.

En cas de menace réelle, avant de définir l'état du résultat sur INACTIVE, éliminez la menace et menez une enquête approfondie sur la menace détectée, l'étendue de l'intrusion et tout autre résultat et problème associés.

Pour désactiver un résultat ou modifier son état, consultez les rubriques suivantes :

• Ignorer les résultats
• Modifier l'état d'un résultat

Réponses Event Threat Detection

Pour en savoir plus sur Event Threat Detection, consultez la section Fonctionnement d'Event Threat Detection.

Cette section ne contient pas de réponses pour les résultats générés par les modules personnalisés Event Threat Detection, car votre organisation définit les actions recommandées pour ces détecteurs.

Active Scan: Log4j Vulnerable to RCE

Les analyseurs de failles Log4j compatibles injectent des recherches JNDI obscurcies dans les paramètres HTTP, les URL et les champs de texte avec des rappels aux domaines contrôlés par les analyseurs. Ce résultat est généré lorsque des requêtes DNS sont trouvées pour les domaines non obscurcis. Ces requêtes ne se produisent que si une recherche JNDI a abouti, ce qui indique une faille Log4j active. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Active Scan: Log4j Vulnerable to RCE, comme indiqué dans la section Examiner les détails des résultats. Le panneau d'informations sur le résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté
   • Ressource concernée, en particulier le champ suivant :
     • Nom complet de la ressource : nom complet de la ressource de l'instance Compute Engine vulnérable au RCE de Log4j.
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

3. Dans la vue détaillée du résultat, cliquez sur l'onglet JSON.

4. Dans le fichier JSON, notez les champs suivants.

   • properties
     • scannerDomain : domaine utilisé par l'outil d'analyse dans le cadre de la recherche JNDI. Cela vous indique quel outil d'analyse a identifié la faille.
     • sourceIp : adresse IP utilisée pour effectuer la requête DNS
     • vpcName : nom du réseau de l'instance sur laquelle la requête DNS a été effectuée.

Étape 2 : Vérifier les journaux

1. Dans la console Google Cloud , accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging de l'étape 1.

2. Sur la page qui s'affiche, recherchez les jetons de chaîne (tels que ${jndi:ldap://) dans les champs httpRequest qui peuvent indiquer des tentatives d'exploitation possibles.

   Pour découvrir des exemples de chaînes à rechercher et un exemple de requête, consultez la section CVE-2021-44228 : Détection de l'exploitation Log4Shell dans la documentation de Logging.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exploitation des services à distance.
2. Consultez les résultats associés en cliquant sur le lien Résultats associés dans la ligne Résultats associés de l'onglet Récapitulatif des détails du résultat. Les résultats associés sont du même type de résultat, sur la même instance et sur le même réseau.
3. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Étape 4 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Installez la dernière version de Log4j2.
• Suivez les recommandations deGoogle Cloudpour enquêter sur la faille "Apache Log4j 2" et y répondre.
• Mettez en œuvre les techniques d'atténuation recommandées dans Failles de sécurité Apache Log4j.
• Si vous utilisez Google Cloud Armor, déployez la ressource cve-canary rule dans une stratégie de sécurité Google Cloud Armor nouvelle ou existante. Pour en savoir plus, consultez la page Règle WAF de Google Cloud Armor pour limiter les failles Apache Log4j.

Brute Force: SSH

Détection d'une attaque par force brute SSH réussie sur un hôte Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Brute Force: SSH, comme indiqué dans la section Examiner les résultats.

2. Dans l'onglet Résumé du panneau "Détails du résultat", examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :

     • Adresse IP de l'appelant : adresse IP qui a lancé l'attaque.
     • Nom d'utilisateur : compte auquel l'utilisateur s'est connecté.

   • Ressource concernée

   • Liens associés, en particulier les champs suivants :

     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

3. Cliquez sur l'onglet JSON.

4. Dans le fichier JSON, notez les champs suivants.

   • sourceProperties :
     • evidence :
       • sourceLogId : ID de projet et code temporel permettant d'identifier l'entrée de journal
       • projectId : projet contenant le résultat.
     • properties :
       • attempts :
       • Attempts : nombre de tentatives de connexion.
         • username : compte qui s'est connecté.
         • vmName : nom de la machine virtuelle.
         • authResult : résultat de l'authentification SSH.

Étape 2 : Vérifier les autorisations et les paramètres

1. Dans la console Google Cloud , accédez au tableau de bord.

   Accéder au tableau de bord

2. Sélectionnez le projet spécifié dans projectId.

3. Accédez à la fiche Ressources, puis cliquez sur Compute Engine.

4. Cliquez sur l'instance de VM qui correspond au nom et à la zone dans vmName. Examinez les détails de l'instance, y compris les paramètres réseau et d'accès.

5. Dans le panneau de navigation, cliquez sur Réseau VPC, puis sur Pare-feu. Supprimez ou désactivez les règles de pare-feu trop permissives sur le port 22.

Étape 3 : Vérifier les journaux

1. Dans la console Google Cloud , accédez à l'explorateur de journaux en cliquant sur le lien dans URI Cloud Logging.
2. Sur la page qui s'affiche, recherchez les journaux de flux VPC associés à l'adresse IP listée dans la ligne Adresse e-mail principale de l'onglet Résumé des détails du résultat à l'aide du filtre suivant :
   • logName="projects/projectId/logs/syslog"
   • labels."compute.googleapis.com/resource_name"="vmName"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Comptes valides : comptes locaux.
2. Consultez les résultats associés en cliquant sur le lien Résultats associés dans la ligne Résultats associés de l'onglet Récapitulatif des détails du résultat. Les résultats associés sont du même type de résultat, sur la même instance et sur le même réseau.
3. Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet associé à la tentative de force brute réussie.
• Examinez l'instance potentiellement compromise et supprimez tous les logiciels malveillants détectés. Pour faciliter la détection et la suppression, utilisez une solution de détection et de gestion des points de terminaison.
• Envisagez de désactiver l'accès SSH à la VM. Pour en savoir plus sur la désactivation des clés SSH, consultez la section Restreindre des clés SSH sur des VM. Cette étape peut interrompre l'accès autorisé à la VM. Par conséquent, pensez aux besoins de votre organisation avant de l'appliquer.
• N'utilisez l'authentification SSH qu'avec des clés autorisées.
• Bloquez les adresses IP malveillantes en mettant à jour les règles de pare-feu ou en utilisant Google Cloud Armor Vous pouvez activer Google Cloud Armor sur la page Services intégrés de Security Command Center. Selon la quantité d'informations, les coûts de Google Cloud Armor peuvent être importants. Pour en savoir plus, consultez le guide des tarifs de Google Cloud Armor.

Credential Access: CloudDB Failed login from Anonymizing Proxy IP

Détecte un échec de connexion à votre instance de base de données à partir d'une adresse IP d'anonymisation connue. Ces adresses d'anonymisation sont des nœuds Tor. Cela peut indiquer qu'un pirate informatique tente d'accéder à votre instance de manière non autorisée.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Credential Access: CloudDB Failed login from Anonymizing Proxy IP, comme indiqué dans la section Examiner les résultats.

2. Dans l'onglet Récapitulatif du panneau "Détails du résultat", examinez les informations des sections suivantes :

   • Risque détecté, en particulier les champs suivants :
   • Adresse IP de l'indicateur : adresse IP anonymisée.
   • Nom à afficher de la base de données : nom de la base de données dans l'instance Cloud SQL PostgreSQL, MySQL ou AlloyDB concernée.
   • Nom d'utilisateur de la base de données : l'utilisateur.
   • Nom complet du projet : projet Google Cloud contenant l'instance Cloud SQL.

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Accès aux identifiants.
2. Pour déterminer si d'autres mesures correctives sont nécessaires, combinez vos résultats d'enquête avec la recherche MITRE.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Examinez les utilisateurs autorisés à se connecter à la base de données.

  • Pour PostgreSQL, consultez Créer et gérer des utilisateurs.
  • Pour MySQL, consultez Gérer les utilisateurs avec l'authentification intégrée.

• Envisagez de modifier le mot de passe de l'utilisateur.

  • Pour PostgreSQL, consultez Définir le mot de passe de l'utilisateur par défaut.

  • Pour MySQL, consultez Définir le mot de passe de l'utilisateur par défaut.

  • Mettez à jour les identifiants des clients qui se connectent à l'instance Cloud SQL.

• Vérifier l'accès réseau à votre instance

  • Pour PostgreSQL, consultez Définir le mot de passe de l'utilisateur par défaut.
  • Pour MySQL, consultez Définir le mot de passe de l'utilisateur par défaut.

Credential Access: Failed Attempt to Approve Kubernetes Certificate Signing Request (CSR)

Quelqu'un a tenté d'approuver manuellement une demande de signature de certificat (CSR), mais l'action a échoué. La création d'un certificat pour l'authentification du cluster est une méthode courante permettant aux pirates informatiques de créer un accès persistant à un cluster compromis. Les autorisations associées au certificat varient en fonction du sujet inclus, mais peuvent être très privilégiées. Pour en savoir plus, consultez le message du journal associé à cette alerte.

1. Examinez les journaux d'audit dans Cloud Logging et les alertes supplémentaires pour les autres événements liés aux requêtes de signature de certificat (CSR) afin de déterminer si des CSR ont été approved et émises, et si les actions liées aux CSR correspondent à une activité attendue de la part du compte principal.
2. Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux d'audit de Cloud Logging. Exemple :
   • Le compte principal qui a tenté d'approuver la CSR était-il différent de celui qui l'a créée ?
   • Le compte principal a-t-il essayé de demander, de créer, d'approuver ou de supprimer d'autres CSR ?
3. Si l'approbation d'une requête de signature de certificat n'était pas attendue ou si celle-ci est considérée comme malveillante, une rotation des identifiants du cluster est nécessaire pour invalider le certificat. Reportez-vous aux instructions pour effectuer une rotation des identifiants de cluster.

Credential Access: Manually Approved Kubernetes Certificate Signing Request (CSR)

Une personne a approuvé manuellement une requête de signature de certificat (CSR). La création d'un certificat pour l'authentification de cluster est une méthode courante permettant aux pirates informatiques de créer un accès persistant à un cluster compromis. Les autorisations associées au certificat varient en fonction du sujet inclus, mais peuvent être très privilégiées. Pour en savoir plus, consultez le message du journal associé à cette alerte.

1. Examinez les journaux d'audit dans Cloud Logging et les alertes supplémentaires pour les autres événements liés aux requêtes de signature de certificat (CSR) afin de déterminer si les actions liées aux CSR sont des activités attendues de la part du compte principal.
2. Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux d'audit de Cloud Logging. Exemple :
   • Le compte principal qui a approuvé la CSR était-il différent de celui qui l'a créée ?
   • La requête de signature de certificat spécifiait-elle un signataire intégré, mais a finalement dû être approuvée manuellement car elle ne respectait pas les critères du signataire ?
   • Le compte principal a-t-il essayé de demander, de créer, d'approuver ou de supprimer d'autres CSR ?
3. Si l'approbation d'une requête de signature de certificat n'était pas attendue ou si celle-ci est considérée comme malveillante, une rotation des identifiants du cluster est nécessaire pour invalider le certificat. Reportez-vous aux instructions pour effectuer une rotation des identifiants de cluster.

Credential Access: Secrets Accessed in Kubernetes Namespace

Détecte l'utilisation du compte de service Kubernetes default d'un pod pour accéder aux objets secrets du cluster. Le compte de service Kubernetes default ne doit pas avoir accès aux objets Secret, sauf si vous lui avez explicitement accordé cet accès avec un objet Role ou ClusterRole.

Defense Evasion: Breakglass Workload Deployment Created

Breakglass Workload Deployment Created est détecté en examinant Cloud Audit Logs pour voir s'il existe des déploiements de charges de travail qui utilisent l'option "break-glass" pour ignorer les contrôles de l'autorisation binaire.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Defense Evasion: Breakglass Workload Deployment Created, comme indiqué dans Examiner les résultats. Le panneau des détails du résultat s'ouvre et affiche l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail principale : compte ayant effectué la modification.
     • Nom de la méthode : méthode appelée.
     • Pods Kubernetes : nom et espace de noms du pod.
   • Ressource concernée, en particulier le champ suivant :
     • Nom à afficher de la ressource : espace de noms GKE dans lequel le déploiement a eu lieu.
   • Liens associés :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

Étape 2 : Vérifier les journaux

1. Dans l'onglet Résumé des détails du résultat dans la console Google Cloud , accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.
2. Vérifiez la valeur du champ protoPayload.resourceName pour identifier la demande de signature de certificat spécifique.

3. Recherchez d'autres actions effectuées par le principal à l'aide des filtres suivants :

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Remplacez les éléments suivants :

   • CLUSTER_NAME : valeur que vous avez notée dans le champ Nom à afficher de la ressource des détails du résultat.

   • PRINCIPAL_EMAIL : valeur que vous avez notée dans le champ Adresse e-mail du compte principal des détails du problème.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Évitement des défenses : déploiement de charge de travail Breakglass.
2. Consultez les résultats associés en cliquant sur le lien Résultats associés dans la ligne Résultats associés de l'onglet Récapitulatif des détails du résultat.
3. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Defense Evasion: Breakglass Workload Deployment Updated

Breakglass Workload Deployment Updated est détecté en examinant Cloud Audit Logs pour voir s'il existe des mises à jour des charges de travail qui utilisent l'option "break-glass" pour remplacer les contrôles d'autorisation binaire.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Defense Evasion: Breakglass Workload Deployment Updated, comme indiqué dans Examiner les résultats. Le panneau des détails du résultat s'ouvre et affiche l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail principale : compte ayant effectué la modification.
     • Nom de la méthode : méthode appelée.
     • Pods Kubernetes : nom et espace de noms du pod.
   • Ressource concernée, en particulier le champ suivant :
     • Nom à afficher de la ressource : espace de noms GKE dans lequel la mise à jour a eu lieu.
   • Liens associés :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

Étape 2 : Vérifier les journaux

1. Dans l'onglet Résumé des détails du résultat dans la console Google Cloud , accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.
2. Vérifiez la valeur du champ protoPayload.resourceName pour identifier la demande de signature de certificat spécifique.

3. Recherchez d'autres actions effectuées par le principal à l'aide des filtres suivants :

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Remplacez les éléments suivants :

   • CLUSTER_NAME : valeur que vous avez notée dans le champ Nom à afficher de la ressource des détails du résultat.

   • PRINCIPAL_EMAIL : valeur que vous avez notée dans le champ Adresse e-mail du compte principal des détails du problème.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Évitement des défenses : déploiement de charge de travail Breakglass.
2. Consultez les résultats associés en cliquant sur le lien Résultats associés dans la ligne Résultats associés de l'onglet Récapitulatif des détails du résultat.
3. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Defense Evasion: GCS Bucket IP Filtering Modified

Event Threat Detection examine les journaux d'audit pour détecter si la configuration du filtrage des adresses IP a été modifiée sur un bucket Cloud Storage.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Defense Evasion: GCS Bucket IP Filtering Modified, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre dans l'onglet Résumé.
2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Description : informations sur la détection
     • Objet principal : compte utilisateur ou de service ayant exécuté une action avec succès
   • Ressource concernée
     • Nom à afficher de la ressource : bucket dans lequel la configuration a été mise à jour.
   • Liens associés, en particulier les champs suivants :
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • URI Logging : lien permettant d'ouvrir l'explorateur de journaux.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service ou du compte utilisateur dans le champ Sujet principal. Confirmez si le propriétaire légitime a effectué l'action.

Defense Evasion: Manually Deleted Certificate Signing Request (CSR)

Une personne a supprimé manuellement une demande de signature de certificat (CSR). Les CSR sont automatiquement supprimées par un contrôleur de collecte des déchets, mais des personnes malveillantes peuvent les supprimer manuellement pour échapper à la détection. Si la CSR supprimée concernait un certificat approuvé et émis, l'acteur potentiellement malveillant dispose désormais d'une méthode d'authentification supplémentaire pour accéder au cluster. Les autorisations associées au certificat varient en fonction du sujet qu'il inclut, mais peuvent être très privilégiées. Kubernetes n'accepte pas la révocation de certificats. Pour en savoir plus, consultez le message du journal associé à cette alerte.

1. Examinez les journaux d'audit dans Cloud Logging et les alertes supplémentaires pour les autres événements liés à cette requête de signature de certificat (CSR) afin de déterminer si la requête a été approved et si la création de la requête était une activité attendue de la part du compte principal.
2. Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux d'audit de Cloud Logging. Exemple :
   • Le compte principal qui a supprimé la CSR est-il différent de celui qui l'a créée ou approuvée ?
   • Le compte principal a-t-il essayé de demander, de créer, d'approuver ou de supprimer d'autres CSR ?
3. Si l'approbation d'une requête de signature de certificat n'était pas attendue ou si celle-ci est considérée comme malveillante, une rotation des identifiants du cluster est nécessaire pour invalider le certificat. Reportez-vous aux instructions pour effectuer une rotation des identifiants de cluster.

Defense Evasion: Modify VPC Service Control

Ce résultat n'est pas disponible pour les activations au niveau du projet.

Les journaux d'audit sont examinés afin de détecter les modifications apportées aux périmètres VPC Service Controls, ce qui entraînerait une réduction de la protection offerte par ce périmètre. Voici quelques exemples :

• Un projet est supprimé d'un périmètre.
• Une stratégie de niveau d'accès est ajoutée à un périmètre existant.
• Un ou plusieurs services sont ajoutés à la liste des services accessibles.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Defense Evasion: Modify VPC Service Control, comme indiqué dans la section Examiner les résultats. Le panneau des détails du résultat s'ouvre et affiche l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Risque détecté, en particulier le champ suivant :
     • Adresse e-mail principale : compte ayant effectué la modification.
   • Ressource concernée, en particulier le champ suivant :
     • Nom complet de la ressource : nom du périmètre VPC Service Controls modifié.
   • Liens associés :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

3. Cliquez sur l'onglet JSON.

4. Dans le fichier JSON, notez les champs suivants.

   • sourceProperties
     • properties
       • name : nom du périmètre VPC Service Controls modifié.
       • policyLink : lien vers la règle d'accès qui contrôle le périmètre
       • delta : modifications, REMOVE ou ADD, d'un périmètre qui a réduit sa protection
       • restricted_resources : projets qui respectent les restrictions de ce périmètre. La protection est réduite si vous supprimez un projet
       • restricted_services : services dont l'exécution est interdite par les restrictions de ce périmètre. La protection est réduite si vous supprimez un service restreint
       • allowed_services : services autorisés à s'exécuter sous les restrictions de ce périmètre. La protection est réduite si vous ajoutez un service autorisé
       • access_levels : niveaux d'accès configurés pour autoriser l'accès aux ressources situées sous le périmètre La protection est réduite si vous ajoutez d'autres niveaux d'accès

Étape 2 : Vérifier les journaux

1. Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
2. Recherchez les journaux des activités d'administration liés aux modifications de VPC Service Controls à l'aide des filtres suivants :
   • protoPayload.methodName:"AccessContextManager.UpdateServicePerimeter"
   • protoPayload.methodName:"AccessContextManager.ReplaceServicePerimeters"

Étape 3 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Defense Evasion : Modifier Authentication Process.
2. Consultez les résultats associés en cliquant sur le lien Résultats associés dans la ligne Résultats associés de l'onglet Récapitulatif des détails du résultat.
3. Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 4 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire de la règle et du périmètre VPC Service Controls.
• Envisagez d'annuler les modifications du périmètre jusqu'à la fin de l'enquête.
• Envisagez de révoquer les rôles Access Context Manager sur le compte principal qui a modifié le périmètre jusqu'à la fin de l'enquête.
• Examinez comment les protections réduites ont été utilisées. Par exemple, si l'API BigQuery Data Transfer Service est activée ou ajoutée en tant que service autorisé, vérifiez qui a commencé à utiliser ce service et ce qu'il transfère.

Defense Evasion: Potential Kubernetes Pod Masquerading

Une personne a déployé un pod avec une convention de nommage semblable aux charges de travail par défaut que GKE crée pour le fonctionnement normal du cluster. Cette technique est appelée mascarade. Pour en savoir plus, consultez le message du journal associé à cette alerte.

1. Vérifiez que le pod est légitime.
2. Déterminez s'il existe d'autres signes d'activité malveillante de la part du pod ou du compte principal dans les journaux d'audit de Cloud Logging.
3. Si le compte principal n'est pas un compte de service (IAM ou Kubernetes), contactez le propriétaire du compte pour confirmer que ce propriétaire légitime est bien à l'origine de l'action.
4. Si le compte principal est un compte de service (IAM ou Kubernetes), identifiez la source de l'action pour déterminer sa légitimité.
5. Si le pod n'est pas légitime, supprimez-le, ainsi que toutes les liaisons RBAC et comptes de service associés utilisés par la charge de travail qui ont permis sa création.

Defense Evasion: Project HTTP Policy Block Disabled

Event Threat Detection examine les journaux d'audit pour détecter si la règle constraints/storage.secureHttpTransport a été mise à jour pour désactiver le blocage de la règle http.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Defense Evasion: Project HTTP Policy Block Disabled, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre dans l'onglet Résumé.
2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Description : informations sur la détection
     • Objet principal : compte utilisateur ou de service ayant exécuté une action avec succès
   • Ressource concernée
     • Nom à afficher de la ressource : projet/dossier/organisation dans lequel la règle a été mise à jour.
   • Liens associés, en particulier les champs suivants :
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • URI Logging : lien permettant d'ouvrir l'explorateur de journaux.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service ou du compte utilisateur dans le champ Sujet principal. Confirmez si le propriétaire légitime a effectué l'action visant à désactiver les contraintes/la règle storage.secureHttpTransport.

Defensive Evasion: Static Pod Created

Quelqu'un a créé un pod statique dans votre cluster GKE. Les pods statiques s'exécutent directement sur le nœud et contournent le serveur d'API Kubernetes, ce qui les rend plus difficiles à surveiller et à contrôler. Les pirates informatiques peuvent l'utiliser pour échapper à la détection ou maintenir leur persistance.

1. Examinez le fichier manifeste du pod statique et son objectif. Vérifiez qu'il est légitime et nécessaire.
2. Évaluez si la fonctionnalité du pod statique peut être obtenue via un pod régulier géré par le serveur d'API Kubernetes.
3. Si le pod statique est requis, assurez-vous qu'il respecte les bonnes pratiques de sécurité et qu'il dispose de privilèges minimaux.
4. Surveillez l'activité du pod statique et son impact sur votre cluster.

Discovery: Can get sensitive Kubernetes object check

Une personne potentiellement malveillante a tenté d'identifier les objets sensibles dans GKE sur lesquels il peut effectuer des requêtes, à l'aide de la commande kubectl auth can-i get. Plus précisément, l'acteur a exécuté l'une des commandes suivantes :

• kubectl auth can-i get '*'
• kubectl auth can-i get secrets
• kubectl auth can-i get clusterroles/cluster-admin

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Discovery: Can get sensitive Kubernetes object check comme indiqué dans Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Récapitulatif, notez les valeurs des champs suivants :

   • Sous Ce qui a été détecté :
     • Examens d'accès Kubernetes : informations demandées sur l'examen d'accès, basées sur la ressource k8s SelfSubjectAccessReview.
     • Adresse e-mail principale : compte à l'origine de l'appel.
   • Sous Ressource concernée :
     • Nom à afficher de la ressource : cluster Kubernetes dans lequel l'action s'est produite.
   • Sous Liens associés :
     • URI Cloud Logging : lien vers les entrées Logging.

Étape 2 : Vérifier les journaux

1. Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.

2. Sur la page qui s'affiche, recherchez d'autres actions effectuées par le compte principal à l'aide des filtres suivants :

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Remplacez les éléments suivants :

   • CLUSTER_NAME : valeur que vous avez notée dans le champ Nom à afficher de la ressource des détails du résultat.

   • PRINCIPAL_EMAIL : valeur que vous avez notée dans le champ Adresse e-mail du compte principal des détails du problème.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

1. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Découverte.
2. Vérifiez le degré de sensibilité de l'objet interrogé et déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux.

3. Si le compte que vous avez noté dans la ligne Adresse e-mail du compte principal des détails du résultat n'est pas un compte de service, contactez le propriétaire du compte pour confirmer que ce propriétaire légitime est bien à l'origine de l'action.

   Si l'adresse e-mail du compte principal est un compte de service (IAM ou Kubernetes), identifiez la source de l'examen d'accès pour déterminer sa légitimité.

4. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Evasion: Access from Anonymizing Proxy

Les accès anormaux d'un proxy anonyme sont détectés en consultant Cloud Audit Logs pour examiner les modifications apportées au service Google Cloud provenant d'une adresse IP associée au réseau Tor.

Pour répondre à ces résultats, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Evasion: Access from Anonymizing Proxy, comme indiqué dans la section Examiner les résultats. Le panneau des détails du résultat s'ouvre et affiche l'onglet Résumé.

2. Dans l'onglet Récapitulatif du panneau "Détails du résultat", examinez les valeurs listées dans les sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail principale : compte ayant effectué les modifications (compte potentiellement piraté).
     • IP : adresse IP du proxy à partir de laquelle les modifications sont effectuées.
   • Ressource concernée
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

3. Vous pouvez également cliquer sur l'onglet JSON pour afficher d'autres champs de résultats.

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Proxy : proxy à sauts multiples.
2. Contactez le propriétaire du compte dans le champ principalEmail. Confirmez si l'action a été effectuée par le propriétaire légitime.
3. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Execution: Cryptomining Docker Image

Détecte la création ou la révision d'un service ou d'un job Cloud Run en ajoutant une image Docker connue comme malveillante et capable de faire du minage de cryptomonnaie.

Pour répondre à ce résultat, procédez comme suit :

1. Vérifiez l'image du conteneur pour déterminer si cela était prévu.
2. Supprimez le conteneur compromis et remplacez-le par un nouveau.

Execution: GKE launch excessively capable container

Une personne a déployé un conteneur avec une ou plusieurs des fonctionnalités suivantes dans un cluster GKE dont le contexte de sécurité est élevé :

• CAP_SYS_MODULE
• CAP_SYS_RAWIO
• CAP_SYS_PTRACE
• CAP_SYS_BOOT
• CAP_DAC_READ_SEARCH
• CAP_NET_ADMIN
• CAP_BPF

Ces capacités ont déjà été utilisées pour s'échapper des conteneurs et doivent être provisionnées avec prudence.

1. Examinez le contexte de sécurité du conteneur dans la définition de son pod. Identifiez les fonctionnalités qui ne sont pas strictement nécessaires à son fonctionnement.
2. Supprimez ou réduisez les capacités excessives dans la mesure du possible. Utilisez le principe du moindre privilège.

Execution: Kubernetes Pod Created with Potential Reverse Shell Arguments

Un utilisateur a créé un pod contenant des commandes ou des arguments généralement associés à un shell inversé. Les pirates informatiques utilisent des shells inversés pour étendre ou maintenir leur accès initial à un cluster et pour exécuter des commandes arbitraires. Pour en savoir plus, consultez le message du journal associé à cette alerte.

1. Vérifiez que le pod a une raison légitime de spécifier ces commandes et arguments.
2. Déterminez s'il existe d'autres signes d'activité malveillante de la part du pod ou du compte principal dans les journaux d'audit de Cloud Logging.
3. Si le compte principal n'est pas un compte de service (IAM ou Kubernetes), contactez le propriétaire du compte pour confirmer que ce propriétaire légitime est bien à l'origine de l'action.
4. Si le compte principal est un compte de service (IAM ou Kubernetes), assurez-vous de la légitimité de ce qui a amené le compte de service à effectuer cette action.
5. Si le pod n'est pas légitime, supprimez-le, ainsi que toutes les liaisons RBAC et comptes de service associés utilisés par la charge de travail qui ont permis sa création.

Execution: Suspicious Exec or Attach to a System Pod

Quelqu'un a utilisé les commandes exec ou attach pour obtenir un shell ou exécuter une commande sur un conteneur s'exécutant dans l'espace de noms kube-system. Ces méthodes sont parfois utilisées à des fins de débogage légitimes. Toutefois, kube-system namespace est destiné aux objets système créés par Kubernetes. Toute exécution de commande ou création de shell inattendue doit être examinée. Pour en savoir plus, consultez le message du journal associé à cette alerte.

1. Examinez les journaux d'audit dans Cloud Logging pour déterminer s'il s'agissait d'une activité attendue de la part du compte principal.
2. Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux.

Examinez les conseils sur l'utilisation du principe du moindre privilège et appliquez-les aux rôles RBAC et rôles de cluster ayant autorisé cet accès.

Execution: Workload triggered in sensitive namespace

Une personne a déployé une charge de travail (par exemple, un pod ou un déploiement) dans les espaces de noms kube-system ou kube-public. Ces espaces de noms sont essentiels aux opérations des clusters GKE. Des charges de travail non autorisées pourraient compromettre la stabilité ou la sécurité du cluster.

1. Identifiez la charge de travail déployée et son objectif.
2. Si la charge de travail n'est pas autorisée, supprimez-la et examinez la source du déploiement.

Exfiltration: BigQuery Data Exfiltration

Les résultats renvoyés par Exfiltration: BigQuery Data Exfiltration contiennent l'une des deux sous-règles possibles. Chaque sous-règle a un niveau de gravité différent :

• Sous-règle exfil_to_external_table avec le niveau de gravité HIGH :
  • Une ressource a été enregistrée en dehors de votre organisation ou de votre projet.
• Sous-règle vpc_perimeter_violation avec le niveau de gravité LOW :
  • VPC Service Controls a bloqué une opération de copie ou une tentative d'accès aux ressources BigQuery.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Exfiltration: BigQuery Data Exfiltration, comme indiqué dans Examiner les résultats.

2. Dans l'onglet Récapitulatif du panneau "Détails du résultat", examinez les valeurs listées dans les sections suivantes :

   • Éléments détectés :
     • Gravité : la gravité est HIGH pour la sous-règle exfil_to_external_table ou LOW pour la sous-règle vpc_perimeter_violation.
     • Adresse e-mail principale : compte utilisé pour exfiltrer les données.
     • Sources d'exfiltration : détails concernant les tables à partir desquelles les données ont été exfiltrées.
     • Cibles d'exfiltration : détails concernant les tables dans lesquelles les données exfiltrées ont été stockées.
   • Ressource concernée :
     • Nom complet de la ressource : nom complet de la ressource du projet, du dossier ou de l'organisation à partir desquels les données ont été exfiltrées.
   • Liens associés :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

3. Cliquez sur l'onglet Propriétés sources et examinez les champs affichés, en particulier :

   • detectionCategory :
     • subRuleName : exfil_to_external_table ou vpc_perimeter_violation.
   • evidence :
     • sourceLogId :
       • projectId : projet Google Cloud contenant l'ensemble de données BigQuery source.
   • properties
     • dataExfiltrationAttempt
       • jobLink : lien vers la tâche BigQuery qui exfiltre des données.
       • query : requête SQL exécutée sur l'ensemble de données BigQuery.

4. Vous pouvez également cliquer sur l'onglet JSON pour obtenir la liste complète des propriétés JSON du résultat.

Étape 2 : Vérifier les autorisations et les paramètres

1. Dans la console Google Cloud , accédez à la page IAM.

   Accéder à IAM

2. Si nécessaire, sélectionnez le projet répertorié dans le champ projectId du JSON du résultat.

3. Sur la page qui s'affiche, dans la zone Filtre, saisissez l'adresse e-mail répertoriée dans Adresse e-mail du compte principal et vérifiez les autorisations attribuées au compte.

Étape 3 : Vérifier les journaux

1. Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.

2. Recherchez les journaux d'activité d'administration liés aux tâches BigQuery à l'aide des filtres suivants :

   • protoPayload.methodName="Jobservice.insert"
   • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service: Exfiltration to Cloud Storage (Exfiltration via service Web : Exfiltration vers Cloud Storage).
2. Consultez les résultats associés en cliquant sur le lien Résultats associés dans la ligne Résultats associés de l'onglet Récapitulatif des détails du résultat. Les résultats associés sont du même type de résultat, sur la même instance et sur le même réseau.
3. Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet contenant les données exfiltrées.
• Envisagez de révoquer les autorisations pour userEmail jusqu'à ce que l'enquête soit terminée.
• Pour mettre fin à une exfiltration plus approfondie, ajoutez des stratégies IAM restrictives aux ensembles de données BigQuery concernés (exfiltration.sources et exfiltration.targets).
• Pour rechercher des informations sensibles dans les ensembles de données concernés, utilisez la protection des données sensibles. Vous pouvez également envoyer des données Sensitive Data Protection à Security Command Center. Selon la quantité d'informations, les coûts liés à Sensitive Data Protection peuvent être importants. Suivez les bonnes pratiques pour contrôler les coûts liés à Sensitive Data Protection.
• Pour limiter l'accès à l'API BigQuery, utilisez VPC Service Controls.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Exfiltration: BigQuery Data Extraction

L'exfiltration de données de BigQuery est détectée en examinant les journaux d'audit pour deux scénarios :

• Une ressource est enregistrée dans un bucket Cloud Storage extérieur à votre organisation.
• Une ressource est enregistrée dans un bucket Cloud Storage accessible au public et appartenant à votre organisation.

Pour les activations du niveau Premium de Security Command Center au niveau des projets, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Exfiltration: BigQuery Data Extraction, comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif du panneau "Détails du résultat", examinez les valeurs listées dans les sections suivantes :

   • Éléments détectés :
     • Adresse e-mail principale : compte utilisé pour exfiltrer les données.
     • Sources d'exfiltration : détails concernant les tables à partir desquelles les données ont été exfiltrées.
     • Cibles d'exfiltration : détails concernant les tables dans lesquelles les données exfiltrées ont été stockées.
   • Ressource concernée :
     • Nom complet de la ressource : nom de la ressource BigQuery dont les données ont été exfiltrées.
     • Nom complet du projet : projet Google Cloud contenant l'ensemble de données BigQuery source.
   • Liens associés :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

3. Dans le panneau des détails du résultat, cliquez sur l'onglet JSON.

4. Dans le fichier JSON, notez les champs suivants.

   • sourceProperties :
     • evidence :
       • sourceLogId :
       • projectId : projet Google Cloud contenant l'ensemble de données BigQuery source.
     • properties :
       • extractionAttempt :
       • jobLink : lien vers la tâche BigQuery qui a exfiltré des données.

Étape 2 : Vérifier les autorisations et les paramètres

1. Dans la console Google Cloud , accédez à la page IAM.

   Accéder à IAM

2. Si nécessaire, sélectionnez le projet répertorié dans le champ projectId du JSON du résultat (à l'étape 1).

3. Sur la page qui s'affiche, dans la zone Filtre, saisissez l'adresse e-mail répertoriée dans Adresse e-mail principale (à l'étape 1) et vérifiez quelles autorisations sont attribuées au compte.

Étape 3 : Vérifier les journaux

1. Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
2. Recherchez les journaux d'activité d'administration liés aux tâches BigQuery à l'aide des filtres suivants :
   • protoPayload.methodName="Jobservice.insert"
   • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service: Exfiltration to Cloud Storage (Exfiltration via service Web : Exfiltration vers Cloud Storage).
2. Consultez les résultats associés en cliquant sur le lien de la ligne Résultats associés dans l'onglet Récapitulatif des détails du résultat. Les résultats associés sont du même type de résultat, sur la même instance et sur le même réseau.
3. Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet contenant les données exfiltrées.
• Envisagez de révoquer les autorisations pour le compte principal indiqué dans la ligne Adresse e-mail principale de l'onglet Récapitulatif des détails du résultat jusqu'à la fin de l'enquête.
• Pour mettre fin à toute exfiltration, ajoutez des stratégies IAM restrictives aux ensembles de données BigQuery concernés, identifiés dans le champ Sources d'exfiltration de l'onglet Résumé des détails du résultat.
• Pour rechercher des informations sensibles dans les ensembles de données concernés, utilisez la protection des données sensibles. Vous pouvez également envoyer des données Sensitive Data Protection à Security Command Center. Selon la quantité d'informations, les coûts liés à Sensitive Data Protection peuvent être importants. Suivez les bonnes pratiques pour contrôler les coûts liés à Sensitive Data Protection.
• Pour limiter l'accès à l'API BigQuery, utilisez VPC Service Controls.
• Si vous êtes le propriétaire du bucket, envisagez de révoquer les autorisations d'accès public.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Exfiltration: BigQuery Data to Google Drive

L'exfiltration de données de BigQuery est détectée en examinant les journaux d'audit pour le scénario suivant :

• Une ressource est enregistrée dans un dossier Google Drive.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Exfiltration: BigQuery Data to Google Drive, comme indiqué dans la section Examiner les résultats.

2. Dans l'onglet Résumé du panneau "Détails du résultat", examinez les informations des sections suivantes :

   • Ce qui a été détecté, y compris :
     • Adresse e-mail principale : compte utilisé pour exfiltrer les données.
     • Sources d'exfiltration : détails sur la table BigQuery à partir de laquelle les données ont été exfiltrées.
     • Cibles d'exfiltration : détails sur la destination dans Google Drive.
   • Ressource concernée, y compris :
     • Nom complet de la ressource : nom de la ressource BigQuery dont les données ont été exfiltrées.
     • Nom complet du projet : projet Google Cloud contenant l'ensemble de données BigQuery source.
   • Liens associés, y compris :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

3. Pour en savoir plus, cliquez sur l'onglet JSON.

4. Dans le fichier JSON, notez les champs suivants.

   • sourceProperties :
     • evidence :
       • sourceLogId :
       • projectId : projet Google Cloud contenant l'ensemble de données BigQuery source.
     • properties :
       • extractionAttempt :
       • jobLink : lien vers la tâche BigQuery qui exfiltre des données.

Étape 2 : Vérifier les autorisations et les paramètres

1. Dans la console Google Cloud , accédez à la page IAM.

   Accéder à IAM

2. Si nécessaire, sélectionnez le projet répertorié dans le champ projectId du JSON du résultat (à l'étape 1).

3. Sur la page qui s'affiche, dans la zone Filtre, saisissez l'adresse e-mail répertoriée dans access.principalEmail (à l'étape 1) et vérifiez quelles autorisations sont attribuées au compte.

Étape 3 : Vérifier les journaux

1. Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
2. Recherchez les journaux d'activité d'administration liés aux tâches BigQuery à l'aide des filtres suivants :
   • protoPayload.methodName="Jobservice.insert"
   • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service: Exfiltration to Cloud Storage (Exfiltration via service Web : Exfiltration vers Cloud Storage).
2. Consultez les résultats associés en cliquant sur le lien Résultats associés dans la ligne Résultats associés de l'onglet Récapitulatif des détails du résultat. Les résultats associés sont du même type de résultat, sur la même instance et sur le même réseau.
3. Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet contenant les données exfiltrées.
• Envisagez de révoquer des autorisations du compte principal dans le champ access.principalEmail jusqu'à la fin de l'enquête.
• Pour mettre fin à une exfiltration plus approfondie, ajoutez des stratégies IAM restrictives aux ensembles de données BigQuery concernés (exfiltration.sources).
• Pour rechercher des informations sensibles dans les ensembles de données concernés, utilisez la protection des données sensibles. Vous pouvez également envoyer des données Sensitive Data Protection à Security Command Center. Selon la quantité d'informations, les coûts liés à Sensitive Data Protection peuvent être importants. Suivez les bonnes pratiques pour contrôler les coûts liés à Sensitive Data Protection.
• Pour limiter l'accès à l'API BigQuery, utilisez VPC Service Controls.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Exfiltration: Cloud SQL Data Exfiltration

Il est possible de détecter une exfiltration de données de Cloud SQL en recherchant dans les journaux d'audit deux scénarios différents :

• Données d'instance actives exportées vers un bucket Cloud Storage en dehors de l'organisation.
• Données d'instance actives exportées vers un bucket Cloud Storage appartenant à l'organisation, mais accessible au public.

Tous les types d'instances Cloud SQL sont compatibles.

Pour les activations du niveau Premium de Security Command Center au niveau des projets, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Exfiltration: Cloud SQL Data Exfiltration, comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail principale : compte utilisé pour exfiltrer les données.
     • Sources d'exfiltration : détails concernant l'instance Cloud SQL dont les données ont été exfiltrées.
     • Cibles d'exfiltration : détails sur le bucket Cloud Storage vers lequel les données ont été exportées.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource : nom de la ressource Cloud SQL dont les données ont été exfiltrées.
     • Nom complet du projet : projet Google Cloud contenant les données Cloud SQL sources.
   • Liens associés, y compris :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

3. Cliquez sur l'onglet JSON.

4. Dans le JSON du résultat, notez les champs suivants :

   • sourceProperties :
     • evidence :
     • sourceLogId :
       • projectId : projet Google Cloud contenant l'instance Cloud SQL source.
     • properties
     • bucketAccess : indique si le bucket Cloud Storage est accessible au public ou externe à l'organisation.
     • exportScope : quantité de données exportées (l'instance entière, une ou plusieurs bases de données, une ou plusieurs tables, ou un sous-ensemble spécifié par une requête).

Étape 2 : Vérifier les autorisations et les paramètres

1. Dans la console Google Cloud , accédez à la page IAM.

   Accéder à IAM

2. Si nécessaire, sélectionnez le projet de l'instance répertoriée dans le champ projectId du JSON du résultat (à l'étape 1).

3. Sur la page qui s'affiche, dans la zone Filtre, saisissez l'adresse e-mail indiquée sur la ligne Adresse e-mail principale de l'onglet Récapitulatif des détails du résultat (à l'étape 1). Vérifiez les autorisations attribuées au compte.

Étape 3 : Vérifier les journaux

1. Dans la console Google Cloud , accédez à l'explorateur de journaux en cliquant sur le lien dans URI Cloud Logging (à l'étape 1). La page Explorateur de journaux inclut tous les journaux liés à l'instance Cloud SQL concernée.

Étape 4 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service: Exfiltration to Cloud Storage (Exfiltration via service Web : Exfiltration vers Cloud Storage).
2. Examinez les résultats associés en cliquant sur le lien de la ligne Résultats associés décrit à l'étape 1. Le type des résultats associés est le même, sur la même instance Cloud SQL.
3. Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet contenant les données exfiltrées.
• Envisagez de révoquer les autorisations pour access.principalEmail jusqu'à ce que l'enquête soit terminée.
• Pour mettre fin à toute exfiltration, ajoutez des stratégies IAM restrictives sur les instances Cloud SQL concernées.
  • MySQL
  • PostgreSQL
  • SQL Server
• Pour limiter l'accès à l'API Cloud SQL Admin et au module d'exportation, utilisez VPC Service Controls.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Exfiltration: Cloud SQL Over-Privileged Grant

Détecte lorsque tous les droits associés à une base de données PostgreSQL (ou toutes les fonctions ou procédures d'une base de données) sont accordés à un ou plusieurs utilisateurs de la base de données.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Exfiltration: Cloud SQL Over-Privileged Grant, comme indiqué dans Examiner les résultats.

2. Dans l'onglet Résumé du panneau "Détails du résultat", examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Nom à afficher de la base de données : nom de la base de données de l'instance Cloud SQL PostgreSQL affectée.
     • Nom d'utilisateur de la base de données : utilisateur PostgreSQL ayant accordé des droits en excès.
     • Requête de base de données : requête PostgreSQL exécutée ayant accordé les droits d'accès.
     • Bénéficiaires des droits pour la base de données : bénéficiaires des droits étrangers.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource : nom de la ressource de l'instance Cloud SQL PostgreSQL affectée.
     • Nom complet du parent : nom de ressource de l'instance Cloud SQL pour PostgreSQL.
     • Nom complet du projet : projet Google Cloud contenant l'instance Cloud SQL PostgreSQL.
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

3. Pour afficher le code JSON complet du résultat, cliquez sur l'onglet JSON.

Étape 2 : Vérifier les droits associés à la base de données

1. Connectez-vous à la base de données PostgreSQL.
2. Regroupez et affichez les droits d'accès pour les éléments suivants :
   • Bases de données. Utilisez la métacommande \l ou \list et vérifiez les droits attribués à la base de données répertoriée dans Nom à afficher de la base de données (voir Étape 1).
   • Fonctions ou procédures. Utilisez la métacommande \df et vérifiez les privilèges attribués aux fonctions ou procédures dans la base de données spécifiée dans Nom à afficher de la base de données (voir Étape 1).

Étape 3 : Vérifier les journaux

1. Dans la console Google Cloud , accédez à l'explorateur de journaux en cliquant sur le lien dans URI Cloud Logging (à l'étape 1). La page Explorateur de journaux inclut tous les journaux liés à l'instance Cloud SQL concernée.
2. Dans l'explorateur de journaux, vérifiez les journaux pgaudit PostgreSQL, qui enregistrent les requêtes exécutées dans la base de données, à l'aide des filtres suivants :
   • protoPayload.request.database="var class="edit">database"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service (Exfiltration via service Web).
2. Pour déterminer si d'autres mesures correctives sont nécessaires, combinez vos résultats d'enquête avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire de l'instance disposant d'autorisations excessives.
• Envisagez de révoquer toutes les autorisations pour les bénéficiaires listés dans Bénéficiaires de la base de données jusqu'à ce que l'enquête soit terminée.
• Pour limiter l'accès à la base de données (à partir de Nom à afficher de la base de données de l'Étape 1, révoquez les autorisations inutiles accordées par les bénéficiaires (à partir de Bénéficiaires de la base de données de l'Étape 1.

Exfiltration: Cloud SQL Restore Backup to External Organization

L'exfiltration de données d'une sauvegarde Cloud SQL est détectée en examinant les journaux d'audit pour déterminer si les données de la sauvegarde ont été restaurées sur une instance Cloud SQL en dehors de l'organisation ou du projet. Tous les types d'instances et de sauvegardes Cloud SQL sont acceptés.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Exfiltration: Cloud SQL Restore Backup to External Organization, comme indiqué dans la section Examiner les résultats.

2. Dans l'onglet Récapitulatif du panneau "Détails du résultat", examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail principale : compte utilisé pour exfiltrer les données.
     • Sources d'exfiltration : détails concernant l'instance Cloud SQL à partir de laquelle la sauvegarde a été créée.
     • Cibles d'exfiltration : détails concernant l'instance Cloud SQL dans laquelle les données de sauvegarde ont été restaurées.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource : nom de ressource de la sauvegarde restaurée.
     • Nom complet du projet : projet Google Cloud contenant l'instance Cloud SQL à partir de laquelle la sauvegarde a été créée.

3. Liens associés, en particulier les champs suivants :

   • URI Cloud Logging : lien vers les entrées Logging.
   • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
   • Résultats associés : liens vers les résultats associés.

4. Cliquez sur l'onglet JSON.

5. Dans le fichier JSON, notez les champs suivants.

   • resource :
     • parent_name : nom de ressource de l'instance Cloud SQL à partir de laquelle la sauvegarde a été créée
   • evidence :
     • sourceLogId :
       • projectId : projet Google Cloud contenant l'ensemble de données BigQuery source.
   • properties :
     • restoreToExternalInstance :
       • backupId : ID de l'exécution de sauvegarde qui a été restaurée

Étape 2 : Vérifier les autorisations et les paramètres

1. Dans la console Google Cloud , accédez à la page IAM.

   Accéder à IAM

2. Si nécessaire, sélectionnez le projet de l'instance répertoriée dans le champ projectId du JSON du résultat (à l'étape 1).

3. Sur la page qui s'affiche, dans la zone Filtre, saisissez l'adresse e-mail répertoriée dans Adresse e-mail du compte principal (à l'étape 1) et vérifiez quelles autorisations sont attribuées au compte.

Étape 3 : Vérifier les journaux

1. Dans la console Google Cloud , accédez à l'explorateur de journaux en cliquant sur le lien dans URI Cloud Logging (à l'étape 1). La page Explorateur de journaux inclut tous les journaux liés à l'instance Cloud SQL concernée.

Étape 4 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service: Exfiltration to Cloud Storage (Exfiltration via service Web : Exfiltration vers Cloud Storage).
2. Consultez les résultats associés en cliquant sur le lien dans la ligne Résultats associés. (à partir de l'étape 1). Le type des résultats associés est le même, sur la même instance Cloud SQL.
3. Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet contenant les données exfiltrées.
• Envisagez de révoquer les autorisations du compte principal listé dans la ligne Adresse e-mail principale de l'onglet Récapitulatif des détails du résultat jusqu'à la fin de l'enquête.
• Pour mettre fin à toute exfiltration, ajoutez des stratégies IAM restrictives sur les instances Cloud SQL concernées.
  • MySQL
  • PostgreSQL
  • SQL Server
• Pour limiter l'accès à l'API Cloud SQL Admin, utilisez VPC Service Controls.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Impact: Cryptomining Commands

Détecte lorsque des commandes de minage de cryptomonnaie connues sont transmises à des jobs Cloud Run en tant que points d'entrée qui seront exécutés lorsque le job sera exécuté.

Pour répondre à ce résultat, procédez comme suit :

1. Vérifiez le job, la commande et le conteneur pour déterminer si ce comportement était attendu.
2. Supprimez le job et le conteneur compromis.

Impact: Deleted Google Cloud Backup and DR Backup

Event Threat Detection examine les journaux d'audit pour déterminer si une sauvegarde stockée dans un coffre-fort de sauvegarde a été supprimée.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Impact: Deleted Google Cloud Backup and DR Backup, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre dans l'onglet Résumé.
2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Description : informations sur la détection.
     • Objet principal : utilisateur ou compte de service ayant exécuté une action avec succès.
   • Ressource concernée
     • Nom à afficher de la ressource : projet dans lequel la fréquence de sauvegarde a été réduite.
   • Liens associés, en particulier les champs suivants :
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • URI Logging : lien permettant d'ouvrir l'explorateur de journaux.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Objet du compte principal et vérifiez qu'il est bien à l'origine de l'action.

Impact: Deleted Google Cloud Backup and DR host

Event Threat Detection examine les journaux d'audit pour détecter la suppression d'hôtes exécutant des applications protégées par le service Backup and DR. Une fois un hôte supprimé, les applications qui y sont associées ne peuvent pas être sauvegardées.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Impact: Deleted Google Cloud Backup and DR host, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.
2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Nom de l'application : nom d'une base de données ou d'une VM connectée à Backup and DR
     • Nom d'hôte : nom d'un hôte connecté à Backup and DR
     • Sujet principal : un utilisateur qui a exécuté une action avec succès
   • Ressource concernée
     • Nom à afficher de la ressource : projet dans lequel l'hôte a été supprimé
   • Liens associés, en particulier les champs suivants :
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK
     • URI Logging : lien permettant d'ouvrir l'explorateur de journaux

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de résoudre les problèmes détectés.

1. Dans le projet où l'action a été effectuée, accédez à la console de gestion.
2. Vérifiez que l'hôte supprimé ne figure plus dans la liste des hôtes Backup and DR.
3. Sélectionnez l'option Ajouter un hôte pour ajouter à nouveau l'hôte supprimé.

Impact: Deleted Google Cloud Backup and DR plan association

Event Threat Detection examine les journaux d'audit pour détecter si une association de forfait a été supprimée.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Impact: Deleted Google Cloud Backup and DR plan association, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre dans l'onglet Résumé.
2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Description : informations sur la détection.
     • Objet principal : utilisateur ou compte de service ayant exécuté une action avec succès.
   • Ressource concernée
     • Nom à afficher de la ressource : projet dans lequel la fréquence de sauvegarde a été réduite.
   • Liens associés, en particulier les champs suivants :
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • URI Logging : lien permettant d'ouvrir l'explorateur de journaux.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Objet du compte principal et vérifiez qu'il est bien à l'origine de l'action.

Impact: Deleted Google Cloud Backup and DR Vault

Event Threat Detection examine les journaux d'audit pour détecter si le coffre de sauvegarde a été supprimé.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Impact: Google Cloud Backup and DR reduced backup frequency, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre dans l'onglet Résumé.
2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Description : informations sur la détection.
     • Objet principal : utilisateur ou compte de service ayant exécuté une action avec succès.
   • Ressource concernée
     • Nom à afficher de la ressource : projet dans lequel la fréquence de sauvegarde a été réduite.
   • Liens associés, en particulier les champs suivants :
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • URI Logging : lien permettant d'ouvrir l'explorateur de journaux.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Sujet du compte principal. Confirmez si le propriétaire légitime a effectué l'action.

Impact: GKE kube-dns modification detected

La configuration kube-dns de votre cluster GKE a été modifiée. GKE kube-dns est un composant essentiel de la mise en réseau de votre cluster. Une mauvaise configuration peut entraîner une brèche de sécurité.

1. Examinez la configuration kube-dns du cluster pour identifier toute modification suspecte.

Impact: Google Cloud Backup and DR delete policy

Les journaux d'audit sont examinés pour détecter la suppression d'une règle. Une règle définit comment une sauvegarde est effectuée et où elle est stockée.

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Impact: Google Cloud Backup and DR delete policy, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre dans l'onglet Résumé.
2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Nom de la règle : nom d'une règle unique qui définit la fréquence, la programmation et la durée de conservation des sauvegardes
     • Sujet principal : un utilisateur qui a exécuté une action avec succès
   • Ressource concernée
     • Nom à afficher de la ressource : projet dans lequel la règle a été supprimée
   • Les liens Associés, en particulier les champs suivants :
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK
     • URI Logging : lien permettant d'ouvrir l'explorateur de journaux.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de résoudre les problèmes détectés. 1. Dans le projet où l'action a été effectuée, accédez à la console de gestion. 2. Dans l'onglet Gestionnaire d'applications, sélectionnez l'application concernée et examinez les paramètres Règles qui lui sont appliqués.

Impact: Google Cloud Backup and DR delete profile

Les journaux d'audit sont examinés pour détecter la suppression d'un profil. Un profil définit les pools de stockage utilisés pour stocker les sauvegardes.

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Impact: Google Cloud Backup and DR delete profile, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.
2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Nom du profil : spécifie la cible de stockage pour les sauvegardes des données d'application et de VM.
     • Sujet principal : un utilisateur qui a exécuté une action avec succès
   • Ressource concernée
     • Nom à afficher de la ressource : projet dans lequel le profil a été supprimé
   • Les liens Associés, en particulier les champs suivants :
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK
     • URI Logging : lien permettant d'ouvrir l'explorateur de journaux

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de résoudre les problèmes détectés. 1. Dans le projet où l'action a été effectuée, accédez à la console de gestion. 2. Dans l'onglet Plans de sauvegarde, sélectionnez Profils pour afficher la liste de tous les profils. 3. Examinez les profils pour vérifier que tous les profils requis sont en place. 4. Si le profil supprimé a été supprimé par erreur, sélectionnez Créer un profil pour définir des cibles de stockage pour vos appliances Backup and DR.

Impact: Google Cloud Backup and DR delete template

Security Command Center examine les journaux d'audit pour détecter la suppression anormale d'un modèle. Un modèle est une configuration de base pour les sauvegardes qui peut être appliquée à plusieurs applications.

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Impact: Google Cloud Backup and DR delete template, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre dans l'onglet Résumé.
2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Nom du modèle : nom d'un ensemble de règles qui définissent la fréquence, la programmation et la durée de conservation des sauvegardes
     • Sujet principal : utilisateur ayant exécuté une action avec succès
   • Ressource concernée
     • Nom à afficher de la ressource : projet dans lequel le modèle a été supprimé
   • Les liens Associés, en particulier les champs suivants :
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK
     • URI Logging : lien permettant d'ouvrir l'explorateur de journaux

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

1. Dans le projet où l'action a été effectuée, accédez à la console de gestion.
2. Dans l'onglet Gestionnaire d'applications, recherchez les applications concernées qui ne sont plus protégées et examinez les règles de sauvegarde pour chacune d'elles.
3. Pour ajouter à nouveau un modèle, accédez à l'onglet Plans de sauvegarde, sélectionnez Modèles, puis l'option Créer un modèle.

Impact: Google Cloud Backup and DR delete storage pool

Les journaux d'audit sont examinés pour détecter la suppression d'un pool de stockage. Un pool de stockage associe un bucket Cloud Storage à Backup and DR.

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Impact: Google Cloud Backup and DR delete storage pool, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.
2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Nom du pool de stockage : nom des buckets de stockage dans lesquels les sauvegardes sont stockées
     • Sujet principal : utilisateur ayant exécuté une action avec succès
   • Ressource concernée
     • Nom à afficher de la ressource : projet dans lequel le pool de stockage a été supprimé
   • Les liens Associés, en particulier les champs suivants :
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK
     • URI Logging : lien permettant d'ouvrir l'explorateur de journaux

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de résoudre les problèmes détectés. 1. Dans le projet où l'action a été effectuée, accédez à la console de gestion. 2. Dans l'onglet "Gérer", sélectionnez Pools de stockage pour afficher la liste de tous les pools de stockage. 3. Examinez les associations de pools de stockage avec les appliances de sauvegarde. 4. Si une appliance active n'est pas associée à un pool de stockage, sélectionnez Ajouter un pool OnVault pour l'ajouter de nouveau.

Impact: Google Cloud Backup and DR expire all images

Un acteur potentiellement malveillant a demandé à supprimer toutes les images de sauvegarde associées à une application.

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Impact: Google Cloud Backup and DR expire all images, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.
2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Nom de la règle : nom d'une règle unique qui définit la fréquence, la programmation et la durée de conservation des sauvegardes
     • Nom du modèle : nom d'un ensemble de règles qui définissent la fréquence, la programmation et la durée de conservation des sauvegardes
     • Nom du profil : spécifie la cible de stockage pour les sauvegardes des données d'application et de VM.
     • Sujet principal : un utilisateur qui a exécuté une action avec succès
   • Ressource concernée
     • Nom à afficher de la ressource : projet dans lequel les images de sauvegarde ont été supprimées
   • Les liens Associés, en particulier les champs suivants :
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK
     • URI Logging : lien permettant d'ouvrir l'explorateur de journaux.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de résoudre les problèmes détectés. 1. Dans le projet où l'action a été effectuée, accédez à la console de gestion. 2. Accédez à l'onglet "Surveiller", puis sélectionnez "Jobs" pour vérifier l'état du job de suppression de la sauvegarde. 3. Si une tâche de suppression n'est pas autorisée, accédez aux autorisations IAM pour examiner les utilisateurs ayant accès aux données de sauvegarde.

Impact: Google Cloud Backup and DR expire image

Une personne potentiellement malveillante a demandé à supprimer une image de sauvegarde.

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Inhibit System Recovery: Google Cloud Backup and DR expire image, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.
2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Nom de la règle : nom d'une règle unique qui définit la fréquence, la programmation et la durée de conservation des sauvegardes
     • Nom du modèle : nom d'un ensemble de règles qui définissent la fréquence, la programmation et la durée de conservation des sauvegardes
     • Nom du profil : spécifie la cible de stockage pour les sauvegardes des données d'application et de VM.
     • Sujet principal : un utilisateur qui a exécuté une action avec succès
   • Ressource concernée
     • Nom à afficher de la ressource : projet dans lequel l'image de sauvegarde a été supprimée
   • Les liens Associés, en particulier les champs suivants :
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK
     • URI Logging : lien permettant d'ouvrir l'explorateur de journaux

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de résoudre les problèmes détectés. 1. Dans le projet où l'action a été effectuée, accédez à la console de gestion. 2. Accédez à l'onglet "Surveiller", puis sélectionnez "Jobs" pour vérifier l'état du job de suppression de la sauvegarde. 3. Si une tâche de suppression n'est pas autorisée, accédez aux autorisations IAM pour examiner les utilisateurs ayant accès aux données de sauvegarde.

Impact: Google Cloud Backup and DR reduced backup expiration

Event Threat Detection examine les journaux d'audit pour détecter si la date d'expiration d'une sauvegarde sur une appliance Backup and DR Service a été réduite.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Impact: Google Cloud Backup and DR reduced backup expiration, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre dans l'onglet Résumé.
2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Description : informations sur la détection
     • Objet principal : compte utilisateur ou de service ayant exécuté une action avec succès
   • Ressource concernée
     • Nom à afficher de la ressource : projet dans lequel la durée d'expiration de la sauvegarde a été réduite.
   • Liens associés, en particulier les champs suivants :
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • URI Logging : lien permettant d'ouvrir l'explorateur de journaux.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Sujet du compte principal. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

1. Dans le projet où l'action a été effectuée, accédez à la console de gestion.
2. Dans l'onglet Gestionnaire d'applications, recherchez l'application concernée pour laquelle la date d'expiration de la sauvegarde a été réduite, puis vérifiez que la date d'expiration a été définie par le compte principal.
3. Pour lancer une nouvelle sauvegarde de l'application, sélectionnez Gérer les configurations de sauvegarde afin de créer une sauvegarde à la demande ou de planifier une nouvelle sauvegarde.

Impact: Google Cloud Backup and DR reduced backup frequency

Event Threat Detection examine les journaux d'audit pour déterminer si le plan de sauvegarde a été modifié afin de réduire la fréquence des sauvegardes.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Impact: Google Cloud Backup and DR reduced backup frequency, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre dans l'onglet Résumé.
2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Description : informations sur la détection
     • Objet principal : compte utilisateur ou de service ayant exécuté une action avec succès
   • Ressource concernée
     • Nom à afficher de la ressource : projet dans lequel la fréquence de sauvegarde a été réduite.
   • Liens associés, en particulier les champs suivants :
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • URI Logging : lien permettant d'ouvrir l'explorateur de journaux.

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Sujet du compte principal. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

1. Dans le projet où l'action a été effectuée, accédez à la console de gestion.
2. Dans l'onglet Gestionnaire d'applications, recherchez l'application concernée pour laquelle la fréquence de sauvegarde a été réduite et vérifiez que la modification a été voulue par le responsable.
3. Pour lancer une nouvelle sauvegarde de l'application, sélectionnez Gérer les configurations de sauvegarde afin de créer une sauvegarde à la demande ou de planifier une nouvelle sauvegarde.

Impact: Google Cloud Backup and DR remove appliance

Les journaux d'audit sont examinés pour détecter la suppression d'un dispositif de sauvegarde et de récupération. Un appareil de sauvegarde et de récupération est un composant essentiel pour les opérations de sauvegarde.

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Inhibit System Recovery: Google Cloud Backup and DR remove appliance, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.
2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Nom de l'appliance : nom d'une base de données ou d'une VM connectée à Backup and DR
     • Sujet principal : un utilisateur qui a exécuté une action avec succès
   • Ressource concernée
     • Nom à afficher de la ressource : projet dans lequel l'appliance a été supprimée
   • Les liens Associés, en particulier les champs suivants :
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK
     • URI Logging : lien permettant d'ouvrir l'explorateur de journaux

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de résoudre les problèmes détectés. 1. Dans le projet où l'action a été effectuée, accédez à la console de gestion. 2. Dans l'onglet Gestionnaire d'applications, recherchez les applications concernées qui ne sont plus protégées et examinez les règles de sauvegarde pour chacune d'elles. 3. Pour créer un appareil et réappliquer des protections aux applications non protégées, accédez à Backup and DR dans la console Google Cloud , puis sélectionnez l'option "Déployer un autre appareil de sauvegarde ou de récupération". 4. Dans le menu Stockage, configurez chaque nouvelle appliance avec une cible de stockage. Une fois que vous avez configuré un serveur, il s'affiche comme option lorsque vous créez un profil pour vos applications.

Impact: Google Cloud Backup and DR remove plan

Security Command Center examine les journaux d'audit pour détecter la suppression anormale d'un plan de sauvegarde Backup and DR Service utilisé pour appliquer des règles de sauvegarde à une application.

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Impact: Google Cloud Backup and DR remove plan, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre dans l'onglet Résumé.
2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Nom de l'application : nom d'une base de données ou d'une VM connectée à Backup and DR
     • Nom du profil : spécifie la cible de stockage pour les sauvegardes des données d'application et de VM.
     • Nom du modèle : nom d'un ensemble de règles qui définissent la fréquence, la programmation et la durée de conservation des sauvegardes
   • Ressource concernée
     • Nom à afficher de la ressource : projet dans lequel le forfait a été supprimé
   • Les liens Associés, en particulier les champs suivants :
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK
     • URI Logging : lien permettant d'ouvrir l'explorateur de journaux

Étape 2 : Étudier les méthodes d'attaque et de réponse

Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

1. Dans le projet où l'action a été effectuée, accédez à la console de gestion.
2. Dans l'onglet Gestionnaire d'applications, recherchez les applications concernées qui ne sont plus protégées et examinez les règles de sauvegarde pour chacune d'elles.

Impact: Suspicious Kubernetes Container Names - Cryptocurrency Mining

Quelqu'un a déployé un pod avec une convention de dénomination semblable à celle des mineurs de pièces de monnaie cryptographiques courants. Il peut s'agir d'une tentative d'un pirate informatique qui a obtenu un accès initial au cluster pour utiliser les ressources du cluster à des fins de minage de cryptomonnaie. Pour en savoir plus, consultez le message du journal associé à cette alerte.

1. Vérifiez que le pod est légitime.
2. Déterminez s'il existe d'autres signes d'activité malveillante de la part du pod ou du compte principal dans les journaux d'audit de Cloud Logging.
3. Si le compte principal n'est pas un compte de service (IAM ou Kubernetes), contactez le propriétaire du compte pour confirmer que ce propriétaire légitime est bien à l'origine de l'action.
4. Si le compte principal est un compte de service (IAM ou Kubernetes), identifiez la source de l'action pour déterminer sa légitimité.
5. Si le pod n'est pas légitime, supprimez-le, ainsi que toutes les liaisons RBAC et comptes de service associés utilisés par la charge de travail qui ont permis sa création.

Initial Access: Anonymous GKE resource created from the internet

Détecte lorsqu'un acteur potentiellement malveillant a utilisé l'un des utilisateurs ou groupes d'utilisateurs Kubernetes par défaut suivants pour créer une ressource Kubernetes dans le cluster :

• system:anonymous
• system:authenticated
• system:unauthenticated

Ces utilisateurs et groupes sont effectivement anonymes. Une liaison de contrôle d'accès basé sur les rôles (RBAC) dans votre cluster a accordé à cet utilisateur l'autorisation de créer ces ressources dans le cluster.

Examinez la ressource créée et la liaison RBAC associée pour vous assurer que la liaison est nécessaire. Si la liaison n'est pas nécessaire, supprimez-la. Pour en savoir plus, consultez le message du journal concernant ce problème.

Pour résoudre ce problème, consultez Éviter les rôles et les groupes par défaut.

Initial Access: CloudDB Successful login from Anonymizing Proxy IP

Détecte une connexion réussie à votre instance de base de données à partir d'une adresse IP d'anonymisation connue. Ces adresses d'anonymisation sont des nœuds Tor. Cela peut indiquer qu'un pirate informatique a réussi à accéder à votre instance.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Initial Access: CloudDB Successful login from Anonymizing Proxy IP, comme indiqué dans la section Examiner les résultats.

2. Dans l'onglet Récapitulatif du panneau "Détails du résultat", examinez les informations des sections suivantes :

   • Risque détecté, en particulier les champs suivants :
   • Adresse IP de l'indicateur : adresse IP anonymisée.
   • Nom à afficher de la base de données : nom de la base de données dans l'instance Cloud SQL PostgreSQL, MySQL ou AlloyDB concernée.
   • Nom d'utilisateur de la base de données : l'utilisateur.
   • Nom complet du projet : projet Google Cloud contenant l'instance Cloud SQL.

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Accès initial.
2. Pour déterminer si d'autres mesures correctives sont nécessaires, combinez vos résultats d'enquête avec la recherche MITRE.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Examinez les utilisateurs autorisés à se connecter à la base de données.

  • Pour PostgreSQL, consultez Créer et gérer des utilisateurs.
  • Pour MySQL, consultez Gérer les utilisateurs avec l'authentification intégrée.

• Envisagez de modifier le mot de passe de l'utilisateur.

  • Pour PostgreSQL, consultez Définir le mot de passe de l'utilisateur par défaut.

  • Pour MySQL, consultez Définir le mot de passe de l'utilisateur par défaut.

  • Mettez à jour les identifiants des clients qui se connectent à l'instance Cloud SQL.

Initial Access: Database Superuser Writes to User Tables

Détecte lorsque le compte super-utilisateur de la base de données Cloud SQL (postgres pour PostgreSQL et root pour MySQL) écrit dans les tables utilisateur. Le super-utilisateur (un rôle disposant d'un accès très étendu) ne doit généralement pas être utilisé pour écrire dans les tables utilisateur. Un compte utilisateur avec un accès plus limité doit être utilisé pour les activités quotidiennes normales. Lorsqu'un super-utilisateur écrit dans une table utilisateur, cela peut indiquer qu'un pirate informatique a élevé ses droits ou compromis l'utilisateur de base de données par défaut, et qu'il est en train de modifier des données. Il peut également indiquer des pratiques normales, mais dangereuses.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Initial Access: Database Superuser Writes to User Tables, comme indiqué dans la section Examiner les résultats.

2. Dans l'onglet Résumé du panneau "Détails du résultat", examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Nom à afficher de la base de données : nom de la base de données de l'instance Cloud SQL PostgreSQL ou MySQL affectée.
     • Nom d'utilisateur de la base de données : super-utilisateur.
     • Requête de base de données : requête SQL exécutée lors de l'écriture dans les tables utilisateur.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource : nom de ressource de l'instance Cloud SQL concernée.
     • Nom complet du parent : nom de ressource de l'instance Cloud SQL.
     • Nom complet du projet : projet Google Cloud contenant l'instance Cloud SQL.
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

3. Pour afficher le code JSON complet du résultat, cliquez sur l'onglet JSON.

Étape 2 : Vérifier les journaux

1. Dans la console Google Cloud , accédez à l'explorateur de journaux en cliquant sur le lien figurant dans cloudLoggingQueryURI (à l'étape 1). La page Explorateur de journaux inclut tous les journaux liés à l'instance Cloud SQL concernée.
2. Consultez les journaux pgaudit PostgreSQL ou les journaux d'audit Cloud SQL pour MySQL, qui contiennent les requêtes exécutées par le superutilisateur, à l'aide des filtres suivants :
   • protoPayload.request.user="SUPERUSER"

Étape 3 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service (Exfiltration via service Web).
2. Pour déterminer si d'autres mesures correctives sont nécessaires, combinez vos résultats d'enquête avec la recherche MITRE.

Étape 4 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Examinez les utilisateurs autorisés à se connecter à la base de données.

  • Pour PostgreSQL, consultez Créer et gérer des utilisateurs.
  • Pour MySQL, consultez Gérer les utilisateurs avec l'authentification intégrée.

• Envisagez de modifier le mot de passe du super-utilisateur.

  • Pour PostgreSQL, consultez Définir le mot de passe de l'utilisateur par défaut.
  • Pour MySQL, consultez Définir le mot de passe de l'utilisateur par défaut.

• Envisagez de créer un utilisateur à accès limité pour les différents types de requêtes utilisées sur l'instance.

  • N'accordez au nouvel utilisateur que les autorisations nécessaires pour exécuter ses requêtes.

    • Pour PostgreSQL, consultez GRANT (commande).
    • Pour MySQL, consultez Contrôle des accès et gestion des comptes.

  • Mettez à jour les identifiants des clients qui se connectent à l'instance Cloud SQL.

Initial Access: Dormant Service Account Action

Détecte les événements où un compte de service géré par l'utilisateur dormant a déclenché une action. Dans ce contexte, un compte de service est considéré comme dormant s'il est inactif depuis plus de 180 jours.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Initial Access: Dormant Service Account Action, comme indiqué dans Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Récapitulatif, notez les valeurs des champs suivants.

   Sous Risque détecté :

   • Adresse e-mail principale : compte de service inactif ayant effectué l'action
   • Nom du service : nom de l'API du service Google Cloud auquel le compte de service a accédé
   • Nom de la méthode : méthode appelée

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Utilisez les outils de compte de service, comme Activity Analyzer, pour examiner l'activité du compte de service inactif.
2. Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet dans lequel l'action a été effectuée.
• Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les applications qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les applications concernées et collaborer avec les propriétaires des applications pour assurer la continuité des opérations.
• Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
• Répondez aux notifications de l'assistance Google Cloud .
• Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Initial Access: Dormant Service Account Activity in AI Service

Détecte les événements où un compte de service géré par l'utilisateur dormant a déclenché une action dans un service d'IA. Dans ce contexte, un compte de service est considéré comme dormant s'il est inactif depuis plus de 180 jours.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Initial Access: Dormant Service Account Activity in AI Service, comme indiqué dans la section Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Récapitulatif, notez les valeurs des champs suivants.

   Sous Risque détecté :

   • Adresse e-mail principale : compte de service inactif ayant effectué l'action
   • Nom de la méthode : méthode appelée
   • Ressources d'IA : ressources d'IA potentiellement concernées, telles que les ressources Vertex AI et le modèle d'IA.

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Utilisez les outils de compte de service, comme Activity Analyzer, pour examiner l'activité du compte de service inactif.
2. Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet dans lequel l'action a été effectuée.
• Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les applications qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les applications concernées et collaborer avec les propriétaires des applications pour assurer la continuité des opérations.
• Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
• Répondez à toutes les notifications de Cloud Customer Care.
• Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Initial Access: Dormant Service Account Key Created

Détecte les événements où une clé de compte de service géré par l'utilisateur dormant est créée. Dans ce contexte, un compte de service est considéré comme dormant s'il est inactif depuis plus de 180 jours.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Initial Access: Dormant Service Account Key Created, comme indiqué dans Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Récapitulatif, notez les valeurs des champs suivants.

   Sous Risque détecté :

   • Adresse e-mail principale : l'utilisateur qui a créé la clé de compte de service

   Sous Ressource concernée :

   • Nom à afficher de la ressource : clé de compte de service inactif nouvellement créée
   • Nom complet du projet : projet dans lequel réside le compte de service inactif

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Utilisez les outils de compte de service, comme Activity Analyzer, pour examiner l'activité du compte de service inactif.
2. Contactez le propriétaire du champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet dans lequel l'action a été effectuée.
• Supprimez l'accès du propriétaire de l'adresse e-mail du compte principal si elle est compromise.
• Invalidez la clé de compte de service que vous venez de créer sur la page Comptes de service.
• Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les applications qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les applications concernées et collaborer avec les propriétaires des applications pour assurer la continuité des opérations.
• Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
• Répondez à toutes les notifications de Cloud Customer Care.
• Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Initial Access: Excessive Permission Denied Actions

Détecte les événements dans lesquels un principal déclenche à plusieurs reprises des erreurs Autorisation refusée dans plusieurs méthodes et services.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Initial Access: Excessive Permission Denied Actions, comme indiqué dans Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Résumé, notez les valeurs des champs suivants.

   Sous Risque détecté :

   • Adresse e-mail du compte principal : compte principal qui a déclenché plusieurs erreurs "Autorisation refusée"
   • Nom du service : nom de l'API du service Google Cloud pour lequel la dernière erreur d'autorisation refusée s'est produite
   • Nom de la méthode : méthode appelée lorsque la dernière erreur d'autorisation refusée s'est produite

3. Dans les détails du résultat, dans l'onglet Propriétés sources, notez les valeurs des champs suivants dans le fichier JSON :

   • properties.failedActions : erreurs d'autorisation refusée qui se sont produites. Pour chaque entrée, les détails incluent le nom du service, le nom de la méthode, le nombre de tentatives infructueuses et l'heure à laquelle l'erreur s'est produite pour la dernière fois. Un maximum de 10 entrées est affiché.

Étape 2 : Vérifier les journaux

1. Dans la console Google Cloud , accédez à l'explorateur de journaux en cliquant sur le lien dans URI Cloud Logging.
2. Dans la barre d'outils de la console Google Cloud , sélectionnez votre projet.

3. Sur la page qui s'affiche, recherchez les journaux associés à l'aide du filtre suivant :

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
   • protoPayload.status.code=7

   Remplacez PRINCIPAL_EMAIL par la valeur que vous avez notée dans le champ Adresse e-mail du principal des détails du résultat.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Comptes valides : comptes Cloud.
2. Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 4 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du compte dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.
• Supprimez les ressources de projet créées par ce compte, telles que les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM inconnus, etc.
• Contactez le propriétaire du projet contenant le compte, et supprimez ou désactivez éventuellement le compte.

Initial Access: GKE NodePort service created

Un utilisateur a créé un service NodePort. Les services NodePort exposent les pods directement sur l'adresse IP et le port statique d'un nœud, ce qui les rend accessibles depuis l'extérieur du cluster. Cela peut présenter un risque de sécurité important, car cela pourrait permettre à un pirate informatique d'exploiter les failles du service exposé pour accéder au cluster ou à des données sensibles.

1. Examinez la configuration du service pour déterminer son objectif.
2. Envisagez de limiter les règles de réseau pour sécuriser le service.

Initial Access: GKE resource modified anonymously from the internet

Détecte lorsqu'un acteur potentiellement malveillant a utilisé l'un des utilisateurs ou groupes d'utilisateurs Kubernetes par défaut suivants pour modifier une ressource Kubernetes dans le cluster :

• system:anonymous
• system:authenticated
• system:unauthenticated

Ces utilisateurs et groupes sont effectivement anonymes. Une liaison de contrôle des accès basé sur les rôles (RBAC) dans votre cluster accorde à cet utilisateur l'autorisation de modifier ces ressources dans le cluster.

Examinez la ressource modifiée et la liaison RBAC associée pour vous assurer que la liaison est nécessaire. Si la liaison n'est pas nécessaire, supprimez-la. Pour en savoir plus, consultez le message du journal concernant ce problème.

Pour résoudre ce problème, consultez Éviter les rôles et les groupes par défaut.

Initial Access: Leaked Service Account Key Used

Détecte les événements où une clé de compte de service divulguée est utilisée pour authentifier l'action. Dans ce contexte, une clé de compte de service divulguée est une clé qui a été publiée sur Internet. Par exemple, les clés de compte de service sont souvent publiées par erreur dans un dépôt GitHub public.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Initial Access: Leaked Service Account Key Used, comme indiqué dans Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Récapitulatif, notez les valeurs des champs suivants.

   Sous Risque détecté :

   • Adresse e-mail principale : compte de service utilisé dans cette action
   • Nom du service : nom de l'API du service Google Cloud auquel le compte de service a accédé
   • Nom de la méthode : nom de la méthode de l'action
   • Nom de la clé de compte de service : clé de compte de service divulguée utilisée pour authentifier cette action
   • Description : description de ce qui a été détecté, y compris l'emplacement sur Internet public où se trouve la clé du compte de service

   Sous Ressource concernée :

   • Nom à afficher de la ressource : ressource concernée par l'action

Étape 2 : Vérifier les journaux

1. Dans la console Google Cloud , accédez à l'explorateur de journaux en cliquant sur le lien dans URI Cloud Logging.
2. Dans la barre d'outils de la console Google Cloud , sélectionnez votre projet ou votre organisation.

3. Sur la page qui s'affiche, recherchez les journaux associés à l'aide du filtre suivant :

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
   • protoPayload.authenticationInfo.serviceAccountKeyName="SERVICE_ACCOUNT_KEY_NAME"

   Remplacez PRINCIPAL_EMAIL par la valeur que vous avez notée dans le champ Adresse e-mail du principal des détails du résultat. Remplacez SERVICE_ACCOUNT_KEY_NAME par la valeur que vous avez notée dans le champ Nom de la clé du compte de service des détails du résultat.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Révoquez immédiatement la clé du compte de service sur la page Comptes de service.
• Supprimez la page Web ou le dépôt GitHub où la clé de compte de service est publiée.
• Envisagez de supprimer le compte de service compromis.
• Alterner et supprimer toutes les clés d'accès de compte de service du projet potentiellement compromis. Après suppression, les applications qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de supprimer, votre équipe de sécurité doit identifier toutes les applications concernées et collaborer avec les propriétaires des applications pour assurer la continuité des opérations.
• Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
• Répondez à toutes les notifications de Cloud Customer Care.

Initial Access: Log4j Compromise Attempt

Ce résultat est généré lorsque des recherches Java Naming and Directory Interface (JNDI) dans les en-têtes ou les paramètres d'URL sont détectés. Ces recherches peuvent indiquer des tentatives d'exploitation Log4Shell. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Initial Access: Log4j Compromise Attempt, comme indiqué dans la section Examiner les détails des résultats. Le panneau de détails du résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté
   • Ressource concernée
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.
   • Dans la vue détaillée du résultat, cliquez sur l'onglet JSON.

   • Dans le fichier JSON, notez les champs suivants.

   • properties

     • loadBalancerName : nom de l'équilibreur de charge ayant reçu la recherche JNDI
     • requestUrl : URL de la requête HTTP. Si ce champ est présent, il contient une recherche JNDI.
     • requestUserAgent : user-agent qui a envoyé la requête HTTP. Si ce champ est présent, il contient une recherche JNDI.
     • refererUrl : URL de la page qui a envoyé la requête HTTP. Si ce champ est présent, il contient une recherche JNDI.

Étape 2 : Vérifier les journaux

1. Dans la console Google Cloud , accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging de l'étape 1.

2. Sur la page qui s'affiche, recherchez les jetons de chaîne (tels que ${jndi:ldap://) dans les champs httpRequest qui peuvent indiquer des tentatives d'exploitation possibles.

   Pour découvrir des exemples de chaînes à rechercher et un exemple de requête, consultez la section CVE-2021-44228 : Détection de l'exploitation Log4Shell dans la documentation de Logging.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exploitation d'une application publique.
2. Consultez les résultats associés en cliquant sur le lien Résultats associés dans la ligne Résultats associés de l'onglet Récapitulatif des détails du résultat. Les résultats associés sont du même type de résultat, sur la même instance et sur le même réseau.
3. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Étape 4 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Installez la dernière version de Log4j2.
• Suivez les recommandations deGoogle Cloudpour enquêter sur la faille "Apache Log4j 2" et y répondre.
• Mettez en œuvre les techniques d'atténuation recommandées dans Failles de sécurité Apache Log4j.
• Si vous utilisez Google Cloud Armor, déployez la ressource cve-canary rule dans une stratégie de sécurité Google Cloud Armor nouvelle ou existante. Pour en savoir plus, consultez la page Règle WAF de Google Cloud Armor pour limiter les failles Apache Log4j.

Initial Access: Successful API call made from a TOR proxy IP

Un appel d'API a été effectué avec succès vers votre cluster GKE à partir d'une adresse IP associée au réseau Tor. Tor offre l'anonymat, que les pirates informatiques exploitent souvent pour masquer leur identité.

1. Examinez la nature de l'appel d'API et des ressources auxquelles il a accédé.
2. Examinez vos règles de pare-feu et vos stratégies réseau pour bloquer l'accès à partir des adresses IP du proxy Tor.

Lateral Movement: Modified Boot Disk Attached to Instance

Les journaux d'audit sont examinés pour détecter les mouvements de disque suspects entre les ressources d'instance Compute Engine. Un disque de démarrage potentiellement modifié a été associé à votre Compute Engine.

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Lateral Movement: Modify Boot Disk Attaching to Instance, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Résumé, notez les valeurs des champs suivants.

   Sous Risque détecté :

   • Adresse e-mail principale : compte de service ayant effectué l'action
   • Nom du service : nom de l'API du service Google Cloud auquel le compte de service a accédé
   • Nom de la méthode : méthode appelée

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Utilisez les outils de compte de service, comme Activity Analyzer, pour examiner l'activité du compte de service associé.
2. Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet dans lequel l'action a été effectuée.
• Envisagez d'utiliser le démarrage sécurisé pour vos instances de VM Compute Engine.
• Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les applications qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les applications concernées et collaborer avec les propriétaires des applications pour assurer la continuité des opérations.
• Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
• Répondez aux notifications de l'assistance Google Cloud .

Leaked credentials

Ce résultat n'est pas disponible pour les activations au niveau du projet.

Ce résultat est généré lorsque des identifiants de compte de service Google Cloud sont accidentellement divulgués en ligne ou compromis. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat account_has_leaked_credentials, comme indiqué dans la section Examiner les détails des résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

• Ce qui a été détecté
• Ressource concernée

1. Cliquez sur l'onglet Propriétés sources et notez les champs suivants :

   • Compromised_account : compte de service potentiellement compromis.
   • Project_identifier : projet contenant les identifiants de compte potentiellement divulgués.
   • URL : lien vers le dépôt GitHub.

2. Pour afficher le code JSON complet du résultat, cliquez sur l'onglet JSON.

Étape 2 : Vérifier les autorisations des projets et des comptes de service

1. Dans la console Google Cloud , accédez à la page IAM.

   Accéder à IAM

2. Si nécessaire, sélectionnez le projet répertorié dans Project_identifier.

3. Sur la page qui s'affiche, dans la zone Filtre, saisissez le nom du compte répertorié dans Compromised_account et vérifiez les autorisations attribuées.

4. Dans la console Google Cloud , accédez à la page Comptes de service.

   Accéder à la page "Comptes de service"

5. Sur la page qui s'affiche, dans le champ Filtre, saisissez le nom du compte de service compromis et vérifiez ses clés ainsi que les dates de création des clés.

Étape 3 : Vérifier les journaux

1. Dans la console Google Cloud , accédez à l'explorateur de journaux.

   Accéder à l'explorateur de journaux

2. Dans la barre d'outils de la console Google Cloud , sélectionnez votre projet.

3. Sur la page qui se charge, vérifiez les journaux à la recherche d'activité provenant de ressources Cloud IAM nouvelles ou mises à jour à l'aide des filtres suivants :

   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • resource.type="gce_instance" AND log_name="projects/Project_identifier/logs/cloudaudit.googleapis.com%2Factivity"
   • protoPayload.methodName="InsertProjectOwnershipInvite"
   • protoPayload.authenticationInfo.principalEmail="Compromised_account"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Comptes valides : comptes Cloud.
2. Consultez les résultats associés en cliquant sur le lien correspondant dans le fichier relatedFindingURI. Les résultats associés sont du même type de résultat, sur la même instance et sur le même réseau.
3. Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet contenant les identifiants divulgués.
• Envisagez de supprimer le compte de service compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources affectées et collaborer avec les propriétaires des ressources pour assurer la continuité des opérations.
• Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
• Répondez aux notifications de l'assistance Google Cloud .
• Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.
• Ouvrez le lien URL et supprimez les identifiants divulgués. Rassemblez plus d'informations sur le compte compromis et contactez le propriétaire.

Malware

Les logiciels malveillants sont détectés en examinant les journaux de flux VPC et les journaux Cloud DNS pour détecter les connexions à des domaines de commande et de contrôle connus ainsi qu'à des adresses IP connues. Actuellement, Event Threat Detection fournit une détection générale des logiciels malveillants (Malware: Bad IP et Malware: Bad Domain) et des détecteurs en particulier pour les logiciels malveillants liés à Log4j (Log4j Malware: Bad IP et Log4j Malware: Bad Domain).

Les étapes suivantes décrivent comment examiner les résultats basés sur les adresses IP et y répondre. Les étapes de résolution sont similaires pour les résultats basés sur un domaine.

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat de détection de logiciel malveillant concerné. Les étapes suivantes utilisent le résultat Malware: Bad IP, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Domaine de l'indicateur : pour les résultats Bad domain, le domaine qui a déclenché le résultat.
     • Adresse IP de l'indicateur : pour les résultats Bad IP, adresse IP qui a déclenché le résultat.
     • Adresse IP source : pour les résultats Bad IP, une commande de logiciel malveillant connue et une adresse IP de contrôle.
     • Port source : pour les résultats Bad IP, port source de la connexion.
     • Adresse IP de destination : pour les résultats Bad IP, adresse IP cible du logiciel malveillant.
     • Port de destination : pour les résultats Bad IP, port de destination de la connexion.
     • Protocole : pour les résultats Bad IP, numéro de protocole IANA associé à la connexion.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource : nom complet de la ressource de l'instance Compute Engine concernée.
     • Nom complet du projet : nom complet de la ressource du projet contenant le résultat.
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.
     • Indicateur VirusTotal : lien vers la page d'analyse VirusTotal.
     • Flow Analyzer : lien vers la fonctionnalité Flow Analyzer de Network Intelligence Center. Ce champ ne s'affiche que lorsque les journaux de flux VPC sont activés.

   1. Cliquez sur l'onglet JSON et notez le champ suivant :

      • evidence :
      • sourceLogId :
        • projectID : ID du projet dans lequel le problème a été détecté.
      • properties :
      • InstanceDetails : adresse de la ressource pour l'instance Compute Engine.

Étape 2 : Vérifier les autorisations et les paramètres

1. Dans la console Google Cloud , accédez à la page Tableau de bord.

   Accéder au tableau de bord

2. Sélectionnez le projet spécifié dans la ligne Nom complet du projet de l'onglet Résumé.

3. Accédez à la fiche Ressources, puis cliquez sur Compute Engine.

4. Cliquez sur l'instance de VM qui correspond au nom et à la zone dans Nom complet de la ressource. Vérifiez les détails de l'instance, y compris les paramètres réseau et d'accès.

5. Dans le panneau de navigation, cliquez sur Réseau VPC, puis sur Pare-feu. Supprimez ou désactivez les règles de pare-feu trop permissives.

Étape 3 : Vérifier les journaux

1. Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.

2. Sur la page qui s'affiche, recherchez les journaux de flux VPC associés à l'adresse IP dans Adresse IP source à l'aide du filtre suivant :

   • logName="projects/projectId/logs/compute.googleapis.com%2Fvpc_flows" AND (jsonPayload.connection.src_ip="SOURCE_IP" OR jsonPayload.connection.dest_ip="destIP")

     Remplacez les éléments suivants :

     • PROJECT_ID, puis sélectionnez le projet listé dans projectId.
     • SOURCE_IP par l'adresse IP indiquée sur la ligne Adresse IP source de l'onglet Résumé des détails du résultat.

Étape 4 : Vérifiez l'analyseur de flux

Vous devez activer les journaux de flux VPC pour effectuer la procédure suivante.

1. Assurez-vous d'avoir mis à niveau votre bucket de journaux pour utiliser l'Analyse de journaux. Pour obtenir des instructions, consultez Mettre à niveau un bucket pour utiliser l'analyse de journaux. La mise à niveau n'entraîne aucuns frais supplémentaires.

2. Dans la console Google Cloud , accédez à la page Analyseur de flux :

   Accéder à Flow Analyzer

   Vous pouvez également accéder à Flow Analyzer via le lien URL de Flow Analyzer dans la section Liens associés de l'onglet Résumé du volet Détails du problème.

3. Pour examiner plus en détail les informations concernant le résultat Event Threat Detection, utilisez le sélecteur de période dans la barre d'action pour modifier la période. La période doit correspondre à la date à laquelle le résultat a été signalé pour la première fois. Par exemple, si le problème a été signalé au cours des deux dernières heures, vous pouvez définir la période sur Dernières six heures. Cela permet de s'assurer que la période dans l'analyseur de flux inclut le moment où le problème a été signalé.

4. Filtrez l'analyseur de flux pour afficher les résultats appropriés pour l'adresse IP associée au résultat d'adresse IP malveillante :

   1. Dans le menu Filtrer de la ligne Source de la section Requête, sélectionnez IP.

   2. Dans le champ Valeur, saisissez l'adresse IP associée au résultat, puis cliquez sur Exécuter une nouvelle requête.

      Si l'analyseur de flux n'affiche aucun résultat pour l'adresse IP, effacez le filtre de la ligne Source, puis exécutez à nouveau la requête avec le même filtre dans la ligne Destination.

5. Analysez les résultats. Pour en savoir plus sur un flux spécifique, cliquez sur Détails dans le tableau Tous les flux de données pour ouvrir le volet Détails du flux.

Étape 5 : Étudier les méthodes d'attaque et de réponse

1. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Résolution dynamique et Commande et contrôle.
2. Consultez les résultats associés en cliquant sur le lien Résultats associés dans la ligne Résultats associés de l'onglet Récapitulatif des détails du résultat. Les résultats associés sont du même type de résultat, sur la même instance et sur le même réseau.
3. Vérifiez les URL et les domaines signalés dans VirusTotal en cliquant sur le lien dans l'indicateur VirusTotal. VirusTotal est un service appartenant à Alphabet qui fournit du contexte sur des fichiers, des URL, des domaines et des adresses IP potentiellement malveillants.
4. Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 6 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet contenant les logiciels malveillants.
• Examinez l'instance potentiellement compromise et supprimez tous les logiciels malveillants détectés. Pour faciliter la détection et la suppression, utilisez une solution de détection et de gestion des points de terminaison.
• Pour suivre l'activité et les failles ayant permis l'insertion de logiciels malveillants, consultez les journaux d'audit et les journaux syslog associés à l'instance compromise.
• Si nécessaire, arrêtez l'instance compromise et remplacez-la par une nouvelle instance.
• Bloquez les adresses IP malveillantes en mettant à jour les règles de pare-feu ou en utilisant Google Cloud Armor Vous pouvez activer Google Cloud Armor sur la page Services intégrés de Security Command Center. Selon le volume de données, les coûts de Google Cloud Armor peuvent être importants. Pour en savoir plus, consultez le guide des tarifs de Google Cloud Armor.
• Pour contrôler les accès et l'utilisation des images de VM, utilisez les stratégies IAM de VM protégée et d'image de confiance.

Malware: Cryptomining Bad IP

La présence de logiciels malveillants est détectée en examinant les journaux de flux VPC et les journaux Cloud DNS pour détecter les connexions à des domaines de contrôle et de commande connus ainsi qu'à des adresses IP connues. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Malware: Cryptomining Bad IP, comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse IP source : adresse IP de minage de cryptomonnaie suspectée.
     • Port source : port source de la connexion, le cas échéant.
     • Adresse IP de destination : adresse IP cible.
     • Port de destination : port de destination de la connexion, le cas échéant.
     • Protocole : protocole IANA associé à la connexion.
   • Ressource concernée
   • Liens associés, y compris les champs suivants :
     • URI Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.
     • Flow Analyzer : lien vers la fonctionnalité Flow Analyzer de Network Intelligence Center. Ce champ ne s'affiche que lorsque les journaux de flux VPC sont activés.

3. Dans la vue détaillée du résultat, cliquez sur l'onglet Propriétés sources.

4. Développez properties et notez les valeurs du projet et de l'instance dans le champ suivant :

   • instanceDetails : notez l'ID du projet et le nom de l'instance Compute Engine. L'ID du projet et le nom de l'instance s'affichent comme dans l'exemple suivant :

     /projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME

5. Pour afficher le code JSON complet du résultat, cliquez sur l'onglet JSON.

Étape 2 : Vérifier les autorisations et les paramètres

1. Dans la console Google Cloud , accédez à la page Tableau de bord.

   Accéder au tableau de bord

2. Sélectionnez le projet spécifié dans properties_project_id.

3. Accédez à la fiche Ressources, puis cliquez sur Compute Engine.

4. Cliquez sur l'instance de VM correspondant à properties_sourceInstance. Examinez l'instance potentiellement compromise à la recherche de logiciels malveillants.

5. Dans le panneau de navigation, cliquez sur Réseau VPC, puis sur Pare-feu. Supprimez ou désactivez les règles de pare-feu trop permissives.

Étape 3 : Vérifier les journaux

1. Dans la console Google Cloud , accédez à l'explorateur de journaux.

   Accéder à l'explorateur de journaux

2. Dans la barre d'outils de la console Google Cloud , sélectionnez votre projet.

3. Sur la page qui s'affiche, recherchez les journaux de flux VPC liés à Properties_ip_0 à l'aide du filtre suivant :

   • logName="projects/properties_project_id/logs/compute.googleapis.com%2Fvpc_flows"
   • (jsonPayload.connection.src_ip="Properties_ip_0" OR jsonPayload.connection.dest_ip="Properties_ip_0")

Étape 4 : Rechercher des méthodes d'attaque et de réponse

1. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Détournement de ressources.
2. Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet contenant les logiciels malveillants.
• Examinez l'instance potentiellement compromise et supprimez tous les logiciels malveillants détectés. Pour faciliter la détection et la suppression, utilisez une solution de détection et de gestion des points de terminaison.
• Si nécessaire, arrêtez l'instance compromise et remplacez-la par une nouvelle instance.
• Bloquez les adresses IP malveillantes en mettant à jour les règles de pare-feu ou en utilisant Google Cloud Armor Vous pouvez activer Google Cloud Armor sur la page Services intégrés de Security Command Center. Selon le volume de données, les coûts de Google Cloud Armor peuvent être importants. Pour en savoir plus, consultez le guide des tarifs de Google Cloud Armor.

Persistence: GKE Webhook Configuration Detected

Une configuration de webhook a été détectée dans votre cluster GKE. Les webhooks peuvent intercepter et modifier les requêtes de l'API Kubernetes, ce qui permet potentiellement aux pirates informatiques de persister dans votre cluster ou de manipuler des ressources.

1. Identifiez l'objectif et l'origine de la configuration du webhook. Vérifiez qu'il provient d'une source fiable et qu'il sert un objectif légitime.
2. Examinez la configuration du webhook pour comprendre son champ d'application et les types de requêtes qu'il intercepte.
3. Surveillez l'activité du webhook pour détecter toute action suspecte ou non autorisée.
4. Si le webhook n'est pas nécessaire ou si son comportement est préoccupant, envisagez de le supprimer ou de le désactiver.

Persistence: IAM Anomalous Grant

Les journaux d'audit sont examinés pour détecter toute attribution d'autorisations IAM (IAM) potentiellement suspecte.

Vous trouverez ci-dessous des exemples d'attributions anormales :

• Inviter un utilisateur externe, tel qu'un utilisateur gmail.com, en tant que propriétaire de projet à partir de la console Google Cloud
• Compte de service accordant des autorisations sensibles.
• Rôle personnalisé accordant des autorisations sensibles.
• Compte de service ajouté depuis l'extérieur de votre organisation ou de votre projet

Le résultat IAM Anomalous Grant est unique, car il inclut des sous-règles qui fournissent des informations plus spécifiques sur chaque instance de ce résultat. Le niveau de gravité de ce résultat dépend de la sous-règle. Chaque sous-règle peut nécessiter une réponse différente.

La liste suivante présente toutes les sous-règles possibles et leur niveau de gravité :

• external_service_account_added_to_policy :
  • HIGH, si un rôle à sensibilité élevée a été attribué ou si un rôle à sensibilité moyenne a été attribué au niveau de l'organisation. Pour en savoir plus, consultez Rôles très sensibles.
  • MEDIUM, si un rôle à sensibilité moyenne a été attribué. Pour en savoir plus, consultez Rôles de sensibilité moyenne.
• external_member_invited_to_policy : HIGH
• external_member_added_to_policy :
  • HIGH, si un rôle à sensibilité élevée a été attribué ou si un rôle à sensibilité moyenne a été attribué au niveau de l'organisation. Pour en savoir plus, consultez Rôles très sensibles.
  • MEDIUM, si un rôle à sensibilité moyenne a été attribué. Pour en savoir plus, consultez Rôles de sensibilité moyenne.
• custom_role_given_sensitive_permissions : MEDIUM
• service_account_granted_sensitive_role_to_member : HIGH
• policy_modified_by_default_compute_service_account : HIGH

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Persistence: IAM Anomalous Grant comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du compte principal : adresse e-mail de l'utilisateur ou du compte de service qui a attribué le rôle.

   • Ressource concernée

   • Liens associés, en particulier les champs suivants :

     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.
     • Indicateur VirusTotal : lien vers la page d'analyse VirusTotal.

3. Cliquez sur l'onglet JSON. Le JSON complet du résultat s'affiche.

4. Dans le JSON du résultat, notez les champs suivants :

   • detectionCategory :
     • subRuleName : informations plus spécifiques sur le type d'attribution anormale qui s'est produite. La sous-règle détermine le niveau de gravité de ce résultat.
   • evidence :
     • sourceLogId :
     • projectId : ID du projet contenant le résultat.
   • properties :
     • sensitiveRoleGrant :
       • bindingDeltas :
       • Action : action entreprise par l'utilisateur.
       • Role : rôle attribué à l'utilisateur.
       • member : adresse e-mail de l'utilisateur ayant reçu le rôle.

Étape 2 : Vérifier les journaux

1. Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
2. Sur la page qui s'affiche, recherchez les ressources IAM nouvelles ou mises à jour à l'aide des filtres suivants :
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"

Étape 3 : Rechercher des méthodes d'attaque et de réponse

1. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Comptes valides : Comptes Cloud.
2. Consultez les résultats associés en cliquant sur le lien de la ligne Résultats associés dans l'onglet Récapitulatif des détails du résultat. Les résultats associés sont du même type de résultat, sur la même instance et sur le même réseau.
3. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Étape 4 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet contenant le conteneur compromis.
• Supprimer le compte de service compromis : et alterner puis supprimer toutes les clés d'accès de compte de service du projet compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès.
• Supprimez les ressources de projet créées par des comptes non autorisés telles que les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM inconnus.
• Pour limiter l'ajout d'utilisateurs gmail.com, utilisez la règle d'administration.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Persistence: New AI API Method

Une activité d'administrateur anormale pour les services d'IA a été détectée dans une organisation, un dossier ou un projet. Elle pourrait être le fait d'une personne malveillante. Une activité anormale peut être l'une des suivantes :

• Nouvelle activité d'un compte principal dans une organisation, un dossier ou un projet
• Activité qui n'a pas été observée depuis un certain temps, effectuée par un compte principal dans une organisation, un dossier ou un projet

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Persistence: New AI API Method comme indiqué dans Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Résumé, notez les valeurs des champs suivants :

   • Sous Ce qui a été détecté :
     • Adresse e-mail principale : compte à l'origine de l'appel
     • Nom de la méthode : méthode appelée
     • Ressources d'IA : ressources d'IA potentiellement concernées, telles que les ressources Vertex AI et le modèle d'IA.
   • Sous Ressource concernée :
     • Nom à afficher de la ressource : nom de la ressource concernée, qui peut être identique à celui de l'organisation, du dossier ou du projet
     • Chemin d'accès à la ressource : emplacement dans la hiérarchie des ressources où l'activité a eu lieu

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Persistance.
2. Déterminez si l'action était justifiée dans l'organisation, le dossier ou le projet, et si elle a été effectuée par le propriétaire légitime du compte. L'organisation, le dossier ou le projet s'affichent dans le champ Chemin d'accès à la ressource, et le compte s'affiche dans la ligne Adresse e-mail du compte principal.
3. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Persistence: New API Method

Une activité d'administrateur anormale a été détectée dans une organisation, un dossier ou un projet, et pourrait être le fait d'un acteur malveillant. Une activité anormale peut être l'une des suivantes :

• Nouvelle activité d'un compte principal dans une organisation, un dossier ou un projet
• Activité qui n'a pas été vue depuis un certain temps par un compte principal dans une organisation, un dossier ou un projet

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Persistence: New API Method comme indiqué dans Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Résumé, notez les valeurs des champs suivants :

   • Sous Ce qui a été détecté :
     • Adresse e-mail principale : compte à l'origine de l'appel
     • Nom du service : nom de l'API du service Google Cloud utilisé dans l'action
     • Nom de la méthode : méthode appelée
   • Sous Ressource concernée :
     • Nom à afficher de la ressource : nom de la ressource concernée, qui peut être identique à celui de l'organisation, du dossier ou du projet
     • Chemin d'accès à la ressource : emplacement dans la hiérarchie des ressources où l'activité a eu lieu

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Persistance.
2. Déterminez si l'action était justifiée dans l'organisation, le dossier ou le projet, et si elle a été effectuée par le propriétaire légitime du compte. L'organisation, le dossier ou le projet s'affichent sur la ligne Chemin d'accès à la ressource, et le compte s'affiche sur la ligne Adresse e-mail du compte principal.
3. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Persistence: New Geography

Ce résultat n'est pas disponible pour les activations au niveau du projet.

Un utilisateur ou un compte de service IAM accède à Google Cloudà partir d'un emplacement anormal, sur la base de la géolocalisation de l'adresse IP à l'origine de la demande.

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Persistence: New Geography, comme indiqué dans la section Examiner les détails des résultats plus haut sur cette page. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

• Ce qui a été détecté, en particulier les champs suivants :
  • Adresse e-mail du compte principal : compte utilisateur potentiellement compromis.
• Ressource concernée, en particulier les champs suivants :
  • Nom complet du projet : projet contenant le compte utilisateur potentiellement compromis.
• Liens associés, en particulier les champs suivants :
  • URI Cloud Logging : lien vers les entrées Logging.
  • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
  • Résultats associés : liens vers les résultats associés.

1. Dans la vue détaillée du résultat, cliquez sur l'onglet JSON.

2. Dans le fichier JSON, notez les champs sourceProperties suivants :

   • affectedResources :
     • gcpResourceName : ressource concernée.
   • evidence :
     • sourceLogId :
     • projectId : ID du projet contenant le résultat.
   • properties :
     • anomalousLocation :
     • anomalousLocation : position actuelle estimée de l'utilisateur.
     • callerIp : adresse IP externe.
     • notSeenInLast : période utilisée pour établir une référence pour un comportement normal.
     • typicalGeolocations : emplacements où l'utilisateur accède généralement aux ressourcesGoogle Cloud .

Étape 2 : Vérifier les autorisations du projet et du compte

1. Dans la console Google Cloud , accédez à la page IAM.

   Accéder à IAM

2. Si nécessaire, sélectionnez le projet répertorié dans le champ projectID du JSON du résultat.

3. Sur la page qui s'affiche, dans la zone Filtre, saisissez le nom du compte répertorié dans Adresse e-mail du compte principal et vérifiez les rôles attribués.

Étape 3 : Vérifier les journaux

1. Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
2. Si nécessaire, sélectionnez votre projet.
3. Sur la page qui s'affiche, vérifiez les journaux d'activité des ressources IAM nouvelles ou mises à jour à l'aide des filtres suivants :
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Comptes valides : comptes Cloud.
2. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Étape 5 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet contenant le conteneur compromis.
• Examinez les champs anomalousLocation, typicalGeolocations et notSeenInLast pour vérifier si l'accès est anormal et si le compte a été compromis.
• Supprimez les ressources de projet créées par des comptes non autorisés telles que les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM inconnus.
• Pour restreindre la création de ressources à des régions spécifiques, consultez Restreindre les emplacements des ressources.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Persistence: New Geography for AI Service

Ce résultat n'est pas disponible pour les activations au niveau du projet.

Un utilisateur ou un compte de service IAM accède aux services d'IA Google Cloudà partir d'un emplacement anormal, en fonction de la géolocalisation de l'adresse IP à l'origine de la demande.

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Persistence: New Geography for AI Service, comme indiqué dans la section Examiner les détails des résultats plus haut sur cette page. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

• Ce qui a été détecté, en particulier les champs suivants :
  • Adresse e-mail du compte principal : compte utilisateur potentiellement compromis.
  • Ressources d'IA : ressources d'IA potentiellement concernées, telles que les ressources Vertex AI et le modèle d'IA.
• Ressource concernée, en particulier les champs suivants :
  • Nom complet du projet : projet contenant le compte utilisateur potentiellement compromis.
• Liens associés, en particulier les champs suivants :
  • URI Cloud Logging : lien vers les entrées Logging.
  • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
  • Résultats associés : liens vers les résultats associés.

1. Dans la vue détaillée du résultat, cliquez sur l'onglet JSON.

2. Dans le fichier JSON, notez les champs sourceProperties suivants :

   • affectedResources :
     • gcpResourceName : ressource concernée.
   • evidence :
     • sourceLogId :
     • projectId : ID du projet contenant le résultat.
   • properties :
     • anomalousLocation :
     • anomalousLocation : position actuelle estimée de l'utilisateur.
     • callerIp : adresse IP externe.
     • notSeenInLast : période utilisée pour établir une référence pour un comportement normal.
     • typicalGeolocations : emplacements où l'utilisateur accède généralement aux ressourcesGoogle Cloud .
   • aiModel :
     • name : l'IA concernée Model
   • vertexAi :
     • datasets : ensembles de données Vertex AI concernés
     • pipelines : pipelines d'entraînement Vertex AI concernés

Étape 2 : Vérifier les autorisations du projet et du compte

1. Dans la console Google Cloud , accédez à la page IAM.

   Accéder à IAM

2. Si nécessaire, sélectionnez le projet répertorié dans le champ projectID du JSON du résultat.

3. Sur la page qui s'affiche, dans la zone Filtre, saisissez le nom du compte répertorié dans Adresse e-mail du compte principal et vérifiez les rôles attribués.

Étape 3 : Vérifier les journaux

1. Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
2. Si nécessaire, sélectionnez votre projet.
3. Sur la page qui s'affiche, vérifiez les journaux d'activité des ressources IAM nouvelles ou mises à jour à l'aide des filtres suivants :
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Comptes valides : comptes Cloud.
2. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Étape 5 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet contenant le conteneur compromis.
• Examinez les champs anomalousLocation, typicalGeolocations et notSeenInLast pour vérifier si l'accès est anormal et si le compte a été compromis.
• Supprimez les ressources de projet créées par des comptes non autorisés telles que les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM inconnus.
• Pour restreindre la création de ressources à des régions spécifiques, consultez Restreindre les emplacements des ressources.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Persistence: New User Agent

Ce résultat n'est pas disponible pour les activations au niveau du projet.

Un compte de service IAM accède à Google Cloud à l'aide d'un logiciel suspect, comme indiqué par un agent utilisateur anormal.

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Persistence: New User Agent, comme indiqué dans la section Examiner les détails des résultats plus haut sur cette page. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail principale : compte de service potentiellement compromis.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet du projet : projet contenant le compte de service potentiellement compromis.
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.
   1. Dans la vue détaillée du résultat, cliquez sur l'onglet JSON.
   2. Dans le fichier JSON, notez les champs suivants.
   • projectId : projet contenant le compte de service potentiellement compromis.
   • callerUserAgent : agent utilisateur anormal.
   • anomalousSoftwareClassification : type de logiciel.
   • notSeenInLast : période utilisée pour établir une référence pour un comportement normal.

Étape 2 : Vérifier les autorisations du projet et du compte

1. Dans la console Google Cloud , accédez à la page IAM.

   Accéder à IAM

2. Si nécessaire, sélectionnez le projet répertorié dans projectId.

3. Sur la page qui s'affiche, dans la zone Filtre, saisissez le nom du compte répertorié dans la ligne Adresse e-mail du compte principal de l'onglet Résumé des détails du résultat, puis vérifiez les rôles attribués.

4. Dans la console Google Cloud , accédez à la page Comptes de service.

   Accéder à la page "Comptes de service"

5. Sur la page qui s'affiche, dans la zone Filtre, saisissez le nom du compte indiqué sur la ligne Adresse e-mail principale de l'onglet Récapitulatif des détails du résultat.

6. Vérifiez les clés du compte de service et leurs dates de création.

Étape 3 : Vérifier les journaux

1. Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
2. Si nécessaire, sélectionnez votre projet.
3. Sur la page qui s'affiche, vérifiez les journaux d'activité des ressources IAM nouvelles ou mises à jour à l'aide des filtres suivants :
   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Comptes valides : comptes Cloud.
2. Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet contenant le conteneur compromis.
• Examinez les champs anomalousSoftwareClassification, callerUserAgent et behaviorPeriod pour vérifier si l'accès est anormal et si le compte a été compromis.
• Supprimez les ressources de projet créées par des comptes non autorisés telles que les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM inconnus.
• Pour restreindre la création de ressources à des régions spécifiques, consultez Restreindre les emplacements des ressources.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Persistence: Service Account Created in sensitive namespace

Un utilisateur a créé un compte de service dans un espace de noms sensible. Les espaces de nomskube-system etkube-public sont essentiels aux opérations des clusters GKE. Des comptes de service non autorisés pourraient compromettre la stabilité et la sécurité des clusters. 1. Si le compte de service n'est pas autorisé, supprimez-le et examinez la méthode de création.

Persistence: Unmanaged Account Granted Sensitive Role

Détecte les événements où un rôle sensible est accordé à un compte non géré. Les comptes non gérés ne peuvent pas être contrôlés par les administrateurs système. Par exemple, lorsque l'employé correspondant a quitté l'entreprise, l'administrateur ne peut pas supprimer le compte. Par conséquent, l'attribution de rôles sensibles à des comptes non gérés crée un risque de sécurité potentiel pour l'organisation.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Persistence: Unmanaged Account Granted Sensitive Role, comme indiqué dans Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Récapitulatif, notez les valeurs des champs suivants.

   Sous Risque détecté :

   • Adresse e-mail principale : utilisateur ayant effectué l'action d'attribution
   • Attribution d'accès non conforme.Nom du compte principal : compte non géré qui reçoit l'attribution
   • Autorisations d'accès concernées.Rôle accordé : rôle sensible accordé

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Contactez le propriétaire du champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.
2. Contactez le propriétaire du champ Offending access grants.Principal name pour comprendre l'origine du compte non géré.

Étape 3 : Vérifier les journaux

1. Dans l'onglet Récapitulatif du panneau d'informations sur le résultat, sous Liens associés, cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.

Étape 4 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet dans lequel l'action a été effectuée.
• Supprimez l'accès du propriétaire de l'adresse e-mail du compte principal si elle est compromise.
• Supprimez le rôle sensible récemment accordé au compte non géré.
• Envisagez de convertir le compte non géré en compte géré à l'aide de l'outil de transfert et de le placer sous le contrôle des administrateurs système.

Privilege Escalation: AlloyDB Database Superuser Writes to User Tables

Détecte lorsque le compte super-utilisateur de la base de données AlloyDB pour PostgreSQL (postgres) écrit dans les tables utilisateur. Le super-utilisateur (un rôle disposant d'un accès très étendu) ne doit généralement pas être utilisé pour écrire dans les tables utilisateur. Un compte utilisateur avec un accès plus limité doit être utilisé pour les activités quotidiennes normales. Lorsqu'un super-utilisateur écrit dans une table utilisateur, cela peut indiquer qu'un pirate informatique a élevé ses droits ou compromis l'utilisateur de base de données par défaut, et qu'il est en train de modifier des données. Il peut également indiquer des pratiques normales, mais dangereuses.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Privilege Escalation: AlloyDB Database Superuser Writes to User Tables, comme indiqué dans la section Examiner les résultats.

2. Dans l'onglet Résumé du panneau "Détails du résultat", examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Nom à afficher de la base de données : nom de la base de données dans l'instance AlloyDB pour PostgreSQL concernée.
     • Nom d'utilisateur de la base de données : super-utilisateur.
     • Requête de base de données : requête SQL exécutée lors de l'écriture dans les tables utilisateur.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource : nom de ressource de l'instance AlloyDB pour PostgreSQL concernée.
     • Nom complet du parent : nom de ressource de l'instance AlloyDB pour PostgreSQL.
     • Nom complet du projet : projet Google Cloud contenant l'instance AlloyDB pour PostgreSQL.
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.

3. Pour afficher le code JSON complet du résultat, cliquez sur l'onglet JSON.

Étape 2 : Vérifier les journaux

1. Dans la console Google Cloud , accédez à l'explorateur de journaux en cliquant sur le lien figurant dans cloudLoggingQueryURI (à l'étape 1). La page Explorateur de journaux inclut tous les journaux liés à l'instance AlloyDB pour PostgreSQL concernée.
2. Recherchez les journaux PostgreSQL pgaudit, qui contiennent les requêtes exécutées par le superutilisateur, à l'aide des filtres suivants :
   • protoPayload.request.user="postgres"

Étape 3 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service (Exfiltration via service Web).
2. Pour déterminer si d'autres mesures correctives sont nécessaires, combinez vos résultats d'enquête avec la recherche MITRE.

Étape 4 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Vérifiez les utilisateurs autorisés à se connecter à la base de données.
• Envisagez de modifier le mot de passe du superutilisateur.
• Envisagez de créer un utilisateur à accès limité pour les différents types de requêtes utilisées sur l'instance.
  • N'accordez au nouvel utilisateur que les autorisations nécessaires pour exécuter ses requêtes.
  • Mettez à jour les identifiants des clients qui se connectent à l'instance AlloyDB pour PostgreSQL.

Privilege Escalation: AlloyDB Over-Privileged Grant

Détecte lorsque tous les droits associés à une base de données AlloyDB pour PostgreSQL (ou toutes les fonctions ou procédures d'une base de données) sont accordés à un ou plusieurs utilisateurs de la base de données.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Privilege Escalation: AlloyDB Over-Privileged Grant, comme indiqué dans Examiner les résultats.

2. Dans l'onglet Résumé du panneau "Détails du résultat", examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Nom à afficher de la base de données : nom de la base de données dans l'instance AlloyDB pour PostgreSQL concernée.
     • Nom d'utilisateur de la base de données : utilisateur PostgreSQL ayant accordé des droits en excès.
     • Requête de base de données : requête PostgreSQL exécutée ayant accordé les droits d'accès.
     • Bénéficiaires des droits pour la base de données : bénéficiaires des droits étrangers.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource : nom de ressource de l'instance AlloyDB pour PostgreSQL concernée.
     • Nom complet du parent : nom de ressource de l'instance AlloyDB pour PostgreSQL.
     • Nom complet du projet : projet Google Cloud contenant l'instance AlloyDB pour PostgreSQL.
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.

3. Pour afficher le code JSON complet du résultat, cliquez sur l'onglet JSON.

Étape 2 : Vérifier les droits associés à la base de données

1. Connectez-vous à l'instance AlloyDB pour PostgreSQL.
2. Regroupez et affichez les droits d'accès pour les éléments suivants :
   • Bases de données. Utilisez la métacommande \l ou \list et vérifiez les droits attribués à la base de données répertoriée dans Nom à afficher de la base de données (voir Étape 1).
   • Fonctions ou procédures. Utilisez la métacommande \df et vérifiez les privilèges attribués aux fonctions ou procédures dans la base de données spécifiée dans Nom à afficher de la base de données (voir Étape 1).

Étape 3 : Vérifier les journaux

1. Dans la console Google Cloud , accédez à l'explorateur de journaux en cliquant sur le lien dans URI Cloud Logging (à l'étape 1). La page Explorateur de journaux inclut tous les journaux liés à l'instance Cloud SQL concernée.
2. Dans l'explorateur de journaux, vérifiez les journaux pgaudit PostgreSQL, qui enregistrent les requêtes exécutées dans la base de données, à l'aide des filtres suivants :
   • protoPayload.request.database="var class="edit">database"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service (Exfiltration via service Web).
2. Pour déterminer si d'autres mesures correctives sont nécessaires, combinez vos résultats d'enquête avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire de l'instance disposant d'autorisations excessives.
• Envisagez de révoquer toutes les autorisations pour les bénéficiaires listés dans Bénéficiaires de la base de données jusqu'à ce que l'enquête soit terminée.
• Pour limiter l'accès à la base de données (à partir de Nom à afficher de la base de données de l'Étape 1, révoquez les autorisations inutiles accordées par les bénéficiaires (à partir de Bénéficiaires de la base de données de l'Étape 1.

Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity

Anomalous Impersonation of Service Account est détecté en examinant les journaux d'audit des activités d'administration pour voir si une anomalie s'est produite dans une demande d'emprunt d'identité d'un compte de service.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity, comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du principal : compte de service final de la requête d'emprunt d'identité qui a été utilisé pour accéder à Google Cloud.
     • Nom du service : nom de l'API du service Google Cloud impliqué dans la demande d'usurpation d'identité.
     • Nom de la méthode : méthode appelée.
     • Informations sur la délégation de compte de service : détails des comptes de service dans la chaîne de délégation. Le compte principal en bas de la liste est l'auteur de la requête d'usurpation d'identité.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource : nom du cluster.
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.
2. Examinez les principaux de la chaîne de délégation pour vérifier si la demande est anormale et si un compte a été compromis.
3. Contactez le propriétaire de l'appelant d'emprunt d'identité dans la liste Informations sur la délégation de compte de service. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet dans lequel l'action a été effectuée.
• Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources affectées et collaborer avec les propriétaires des ressources pour assurer la continuité des opérations.
• Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
• Répondez aux notifications de l'assistance Google Cloud .
• Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Privilege Escalation: Anomalous Impersonation of Service Account for AI Admin Activity

Anomalous Impersonation of Service Account est détecté lorsque les journaux d'audit des activités d'administration d'un service d'IA indiquent qu'une anomalie s'est produite dans une demande d'emprunt d'identité d'un compte de service.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Privilege Escalation: Anomalous Impersonation of Service Account for AI Admin Activity, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du principal : compte de service final de la requête d'emprunt d'identité qui a été utilisé pour accéder à Google Cloud.
     • Nom de la méthode : méthode appelée.
     • Informations sur la délégation de compte de service : détails des comptes de service dans la chaîne de délégation. Le compte principal en bas de la liste est l'appelant de la demande d'usurpation d'identité.
     • Ressources d'IA : ressources d'IA potentiellement concernées, telles que les ressources Vertex AI et le modèle d'IA.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource : nom du cluster.
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.
2. Examinez les principaux de la chaîne de délégation pour vérifier si la demande est anormale et si un compte a été compromis.
3. Contactez le propriétaire de l'appelant d'emprunt d'identité dans la liste Informations sur la délégation de compte de service. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet dans lequel l'action a été effectuée.
• Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources affectées et collaborer avec les propriétaires des ressources pour assurer la continuité des opérations.
• Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
• Répondez à toutes les notifications de Cloud Customer Care.
• Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity

Anomalous Multistep Service Account Delegation est détecté en examinant les journaux d'audit des activités d'administration pour voir si une anomalie s'est produite dans une demande d'emprunt d'identité d'un compte de service.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail principale : compte de service final de la requête d'emprunt d'identité qui a été utilisé pour accéder à Google Cloud.
     • Nom du service : nom de l'API du service Google Cloud impliqué dans la demande d'usurpation d'identité.
     • Nom de la méthode : méthode appelée.
     • Informations sur la délégation de compte de service : détails des comptes de service dans la chaîne de délégation. Le compte principal en bas de la liste est l'auteur de la requête d'emprunt d'identité.
   • Ressource concernée
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.
2. Examinez les principaux de la chaîne de délégation pour vérifier si la demande est anormale et si un compte a été compromis.
3. Contactez le propriétaire de l'appelant d'emprunt d'identité dans la liste Informations sur la délégation de compte de service. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet dans lequel l'action a été effectuée.
• Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources affectées et collaborer avec les propriétaires des ressources pour assurer la continuité des opérations.
• Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
• Répondez aux notifications de l'assistance Google Cloud .
• Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Privilege Escalation: Anomalous Multistep Service Account Delegation for AI Admin Activity

Anomalous Multistep Service Account Delegation est détecté lorsque les journaux d'audit de l'activité d'administration d'un service d'IA indiquent qu'une anomalie s'est produite dans une demande d'emprunt d'identité d'un compte de service.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Privilege Escalation: Anomalous Multistep Service Account Delegation for AI Admin Activity, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du principal : compte de service final de la requête d'emprunt d'identité qui a été utilisé pour accéder à Google Cloud.
     • Nom de la méthode : méthode appelée.
     • Informations sur la délégation de compte de service : détails des comptes de service dans la chaîne de délégation. Le principal en bas de la liste est l'appelant de la demande d'usurpation d'identité.
     • Ressources d'IA : ressources d'IA potentiellement concernées, telles que les ressources Vertex AI et le modèle d'IA.
   • Ressource concernée
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.
2. Examinez les principaux de la chaîne de délégation pour vérifier si la demande est anormale et si un compte a été compromis.
3. Contactez le propriétaire de l'appelant d'emprunt d'identité dans la liste Informations sur la délégation de compte de service. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet dans lequel l'action a été effectuée.
• Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources affectées et collaborer avec les propriétaires des ressources pour assurer la continuité des opérations.
• Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
• Répondez à toutes les notifications de Cloud Customer Care.
• Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Privilege Escalation: Anomalous Multistep Service Account Delegation for AI Data Access

Anomalous Multistep Service Account Delegation est détecté lorsque les journaux d'audit de l'activité d'administration d'un service d'IA indiquent qu'une anomalie s'est produite dans une demande d'emprunt d'identité d'un compte de service.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Privilege Escalation: Anomalous Multistep Service Account Delegation for AI Data Access, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail principale : compte de service final de la demande d'emprunt d'identité qui a été utilisé pour accéder à Google Cloud
     • Nom de la méthode : méthode appelée
     • Informations sur la délégation de compte de service : détails des comptes de service dans la chaîne de délégation. Le compte principal en bas de la liste est celui qui a appelé la requête d'usurpation d'identité.
     • Ressources d'IA : ressources d'IA potentiellement concernées, telles que les ressources Vertex AI et le modèle d'IA.
   • Ressource concernée
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.
2. Examinez les principaux de la chaîne de délégation pour vérifier si la demande est anormale et si un compte a été compromis.
3. Contactez le propriétaire de l'appelant d'emprunt d'identité dans la liste Informations sur la délégation de compte de service. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet dans lequel l'action a été effectuée.
• Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources affectées et collaborer avec les propriétaires des ressources pour assurer la continuité des opérations.
• Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
• Répondez à toutes les notifications de Cloud Customer Care.
• Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access

Anomalous Multistep Service Account Delegation est détecté en examinant les journaux d'audit des accès aux données pour voir si une anomalie s'est produite dans une demande d'emprunt d'identité d'un compte de service.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail principale : compte de service final de la demande d'emprunt d'identité qui a été utilisé pour accéder à Google Cloud
     • Nom du service : nom de l'API du service Google Cloud impliqué dans la demande d'usurpation d'identité
     • Nom de la méthode : méthode appelée
     • Informations sur la délégation de compte de service : détails des comptes de service dans la chaîne de délégation. Le compte principal en bas de la liste est l'auteur de la requête d'emprunt d'identité.
   • Ressource concernée
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.
2. Examinez les principaux de la chaîne de délégation pour vérifier si la demande est anormale et si un compte a été compromis.
3. Contactez le propriétaire de l'appelant d'emprunt d'identité dans la liste Informations sur la délégation de compte de service. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet dans lequel l'action a été effectuée.
• Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources affectées et collaborer avec les propriétaires des ressources pour assurer la continuité des opérations.
• Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
• Répondez aux notifications de l'assistance Google Cloud .
• Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity

Anomalous Service Account Impersonator est détecté en examinant les journaux d'audit des activités d'administration pour voir si une anomalie s'est produite dans une demande d'emprunt d'identité d'un compte de service.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Risque détecté, en particulier les champs suivants :

     • Adresse e-mail du compte principal : compte de service final de la demande d'emprunt d'identité qui a été utilisé pour accéder à Google Cloud
     • Nom du service : nom de l'API du service Google Cloud concerné par la demande d'usurpation d'identité
     • Nom de la méthode : méthode appelée
     • Informations sur la délégation de compte de service : détails des comptes de service dans la chaîne de délégation. Le compte principal en bas de la liste est l'auteur de la requête d'emprunt d'identité.

   • Ressource concernée

   • Liens associés, en particulier les champs suivants :

     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.
2. Examinez les principaux de la chaîne de délégation pour vérifier si la demande est anormale et si un compte a été compromis.
3. Contactez le propriétaire de l'appelant d'emprunt d'identité dans la liste Informations sur la délégation de compte de service. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet dans lequel l'action a été effectuée.
• Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources affectées et collaborer avec les propriétaires des ressources pour assurer la continuité des opérations.
• Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
• Répondez aux notifications de l'assistance Google Cloud .
• Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Privilege Escalation: Anomalous Service Account Impersonator for AI Admin Activity

Anomalous Service Account Impersonator est détecté lorsque les journaux d'audit des activités d'administration d'un service d'IA indiquent qu'une anomalie s'est produite dans une demande d'emprunt d'identité d'un compte de service.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Privilege Escalation: Anomalous Service Account Impersonator for AI Admin Activity, comme indiqué dans Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail principale : compte de service final de la demande d'emprunt d'identité qui a été utilisé pour accéder à Google Cloud
     • Nom de la méthode : méthode appelée
     • Informations sur la délégation de compte de service : détails des comptes de service dans la chaîne de délégation. Le compte principal en bas de la liste est celui qui a appelé la requête d'usurpation d'identité.
     • Ressources d'IA : ressources d'IA potentiellement concernées, telles que les ressources Vertex AI et le modèle d'IA.
   • Ressource concernée
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.
2. Examinez les principaux de la chaîne de délégation pour vérifier si la demande est anormale et si un compte a été compromis.
3. Contactez le propriétaire de l'appelant d'emprunt d'identité dans la liste Informations sur la délégation de compte de service. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet dans lequel l'action a été effectuée.
• Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources affectées et collaborer avec les propriétaires des ressources pour assurer la continuité des opérations.
• Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
• Répondez à toutes les notifications de Cloud Customer Care.
• Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Privilege Escalation: Anomalous Service Account Impersonator for AI Data Access

Anomalous Service Account Impersonator est détecté lorsque les journaux d'audit des activités d'administration d'un service d'IA indiquent qu'une anomalie s'est produite dans une demande d'emprunt d'identité d'un compte de service.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Privilege Escalation: Anomalous Service Account Impersonator for AI Data Access, comme indiqué dans Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Résumé, notez les valeurs des champs suivants.

   Sous Risque détecté :

   • Adresse e-mail principale : compte de service final de la demande d'emprunt d'identité qui a été utilisé pour accéder à Google Cloud
   • Nom de la méthode : méthode appelée
   • Informations sur la délégation de compte de service : détails des comptes de service dans la chaîne de délégation. Le principal en bas de la liste est l'appelant de la demande d'usurpation d'identité.
   • Ressources d'IA : ressources d'IA potentiellement concernées, telles que les ressources Vertex AI et le modèle d'IA.

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.
2. Examinez les principaux de la chaîne de délégation pour vérifier si la demande est anormale et si un compte a été compromis.
3. Contactez le propriétaire de l'appelant d'emprunt d'identité dans la liste Informations sur la délégation de compte de service. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet dans lequel l'action a été effectuée.
• Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources affectées et collaborer avec les propriétaires des ressources pour assurer la continuité des opérations.
• Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
• Répondez à toutes les notifications de Cloud Customer Care.
• Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Privilege Escalation: Anomalous Service Account Impersonator for Data Access

Anomalous Service Account Impersonator est détecté en examinant les journaux d'audit d'accès aux données pour voir si une anomalie s'est produite dans une demande d'usurpation d'identité d'un compte de service.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Privilege Escalation: Anomalous Service Account Impersonator for Data Access, comme indiqué dans Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Résumé, notez les valeurs des champs suivants.

   Sous Risque détecté :

   • Adresse e-mail du compte principal : compte de service final de la demande d'emprunt d'identité qui a été utilisé pour accéder à Google Cloud
   • Nom du service : nom de l'API du service Google Cloud concerné par la demande d'usurpation d'identité
   • Nom de la méthode : méthode appelée
   • Informations sur la délégation de compte de service : détails des comptes de service dans la chaîne de délégation. Le compte principal en bas de la liste est l'auteur de la requête d'emprunt d'identité.

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.
2. Examinez les principaux de la chaîne de délégation pour vérifier si la demande est anormale et si un compte a été compromis.
3. Contactez le propriétaire de l'appelant d'emprunt d'identité dans la liste Informations sur la délégation de compte de service. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet dans lequel l'action a été effectuée.
• Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources affectées et collaborer avec les propriétaires des ressources pour assurer la continuité des opérations.
• Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
• Répondez aux notifications de l'assistance Google Cloud .
• Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Privilege Escalation: Changes to sensitive Kubernetes RBAC objects

Pour élever un privilège, une personne potentiellement malveillante a tenté de modifier un objet RBAC (contrôle des accès basé sur les rôles) ClusterRole, RoleBinding ou ClusterRoleBinding du rôle sensible cluster-admin à l'aide d'une requête PUT ou PATCH.

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Privilege Escalation: Changes to sensitive Kubernetes RBAC objects comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail principale : compte à l'origine de l'appel.
     • Nom de la méthode : méthode appelée.
     • Liaisons Kubernetes : liaison Kubernetes sensible ou ClusterRoleBinding qui a été modifiée.
   • Ressource concernée, en particulier les champs suivants :
     • Nom à afficher de la ressource : cluster Kubernetes dans lequel l'action s'est produite.
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

3. Dans la section Ce qui a été détecté, cliquez sur le nom de la liaison dans la ligne Liaisons Kubernetes. Les détails de la liaison s'affichent.

4. Notez les détails de la liaison dans la liaison affichée.

Étape 2 : Vérifier les journaux

1. Dans l'onglet Résumé des détails du résultat dans la console Google Cloud , accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.

2. Si la valeur dans Nom de la méthode était une méthode PATCH, vérifiez le corps de la requête pour voir quelles propriétés ont été modifiées.

   Dans les appels update (PUT), l'objet entier est envoyé dans la requête, de sorte que les modifications ne sont pas aussi claires.

3. Recherchez d'autres actions effectuées par le principal à l'aide des filtres suivants :

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Remplacez les éléments suivants :

   • CLUSTER_NAME : valeur que vous avez notée dans le champ Nom à afficher de la ressource des détails du résultat.

   • PRINCIPAL_EMAIL : valeur que vous avez notée dans le champ Adresse e-mail du compte principal des détails du problème.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

1. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Élévation des privilèges.
2. Vérifiez le degré de sensibilité de l’objet et assurez-vous que la modification est justifiée.
3. Pour les liaisons, vous pouvez vérifier le sujet et déterminer s'il a besoin du rôle auquel il est lié.
4. Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux.

5. Si l'adresse e-mail du compte principal n'est pas un compte de service, contactez le propriétaire du compte pour confirmer que ce propriétaire légitime est bien à l'origine de l'action.

   Si l'adresse e-mail du compte principal est un compte de service (IAM ou Kubernetes), identifiez la source de la modification pour déterminer sa légitimité.

6. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Privilege Escalation: ClusterRole with Privileged Verbs

Quelqu'un a créé un objet ClusterRole RBAC qui contient les verbes bind, escalate ou impersonate. Un sujet lié à un rôle avec ces verbes peut emprunter l'identité d'autres utilisateurs disposant de droits plus élevés, se lier à des objets Role ou ClusterRole supplémentaires contenant des autorisations supplémentaires, ou modifier ses propres autorisations ClusterRole. Cela peut entraîner l'obtention de privilèges cluster-admin par ces sujets. Pour en savoir plus, consultez le message du journal associé à cette alerte.

1. Examinez le ClusterRole et les ClusterRoleBindings associés pour vérifier si les sujets ont réellement besoin de ces autorisations.
2. Si possible, évitez de créer des rôles qui impliquent les verbes bind, escalate ou impersonate.
3. Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux d'audit de Cloud Logging.
4. Lorsque vous attribuez des autorisations dans un rôle RBAC, appliquez le principe du moindre privilège en n'accordant que les autorisations minimales nécessaires pour effectuer une tâche. Le principe du moindre privilège réduit le risque d'élévation des privilèges si votre cluster est compromis, ainsi que la probabilité d'un incident de sécurité en cas d'autorisations d'accès excessives.

Privilege Escalation: ClusterRoleBinding to Privileged Role

Un utilisateur a créé un ClusterRoleBinding RBAC qui fait référence à l'ClusterRole system:controller:clusterrole-aggregation-controller par défaut. Ce ClusterRole par défaut possède le verbe escalate, qui permet aux sujets de modifier les privilèges de leurs propres rôles, ce qui permet une escalade des privilèges. Pour en savoir plus, consultez le message du journal associé à cette alerte.

1. Examinez tous les ClusterRoleBinding qui font référence à l'system:controller:clusterrole-aggregation-controller ClusterRole.
2. Examinez les modifications apportées à system:controller:clusterrole-aggregation-controller ClusterRole.
3. Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal qui a créé le ClusterRoleBinding dans les journaux d'audit de Cloud Logging.

Privilege Escalation: Create Kubernetes CSR for master cert

Pour élever un privilège, une personne potentiellement malveillante a créé une requête de signature de certificat (CSR) maître Kubernetes, qui lui permet de disposer de l'accès cluster-admin.

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Privilege Escalation: Create Kubernetes CSR for master cert comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail principale : compte à l'origine de l'appel.
     • Nom de la méthode : méthode appelée.
   • Ressource concernée, en particulier les champs suivants :
     • Nom à afficher de la ressource : cluster Kubernetes dans lequel l'action s'est produite.
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

Étape 2 : Vérifier les journaux

1. Dans l'onglet Résumé des détails du résultat dans la console Google Cloud , accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.
2. Vérifiez la valeur du champ protoPayload.resourceName pour identifier la demande de signature de certificat spécifique.

3. Recherchez d'autres actions effectuées par le principal à l'aide des filtres suivants :

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Remplacez les éléments suivants :

   • CLUSTER_NAME : valeur que vous avez notée dans le champ Nom à afficher de la ressource des détails du résultat.

   • PRINCIPAL_EMAIL : valeur que vous avez notée dans le champ Adresse e-mail du compte principal des détails du problème.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

1. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Élévation des privilèges.
2. Déterminez si l'accès à cluster-admin était justifié.

3. Si l'adresse e-mail du compte principal n'est pas un compte de service, contactez le propriétaire du compte pour confirmer que ce propriétaire légitime est bien à l'origine de l'action.

   Si l'adresse e-mail du compte principal est un compte de service (IAM ou Kubernetes), identifiez la source de l'action pour déterminer sa légitimité.

4. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Privilege Escalation: Creation of sensitive Kubernetes bindings

Pour élever un privilège, un individu potentiellement malveillant a tenté de créer un objet RoleBinding ou ClusterRoleBinding pour le rôle cluster-admin.

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Privilege Escalation: Creation of sensitive Kubernetes bindings comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail principale : compte à l'origine de l'appel.
     • Liaisons Kubernetes : liaison Kubernetes sensible ou ClusterRoleBinding qui a été créée.
   • Ressource concernée, en particulier les champs suivants :
     • Nom à afficher de la ressource : cluster Kubernetes dans lequel l'action s'est produite.
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

Étape 2 : Vérifier les journaux

1. Dans l'onglet Résumé des détails du résultat dans la console Google Cloud , accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.

2. Recherchez d'autres actions effectuées par le principal à l'aide des filtres suivants :

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Remplacez les éléments suivants :

   • CLUSTER_NAME : valeur que vous avez notée dans le champ Nom à afficher de la ressource des détails du résultat.

   • PRINCIPAL_EMAIL : valeur que vous avez notée dans le champ Adresse e-mail du compte principal des détails du problème.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

1. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Élévation des privilèges.
2. Vérifiez le degré de sensibilité de la liaison créée et si les rôles sont nécessaires pour les sujets.
3. Pour les liaisons, vous pouvez vérifier le sujet et déterminer s'il a besoin du rôle auquel il est lié.
4. Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux.

5. Si l'adresse e-mail du compte principal n'est pas un compte de service, contactez le propriétaire du compte pour confirmer que ce propriétaire légitime est bien à l'origine de l'action.

   Si l'adresse e-mail du compte principal est un compte de service (IAM ou Kubernetes), identifiez la source de l'action pour déterminer sa légitimité.

6. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Privilege Escalation: Default Compute Engine Service Account SetIAMPolicy

Détecte lorsque le compte de service Compute Engine par défaut est utilisé pour définir la stratégie IAM d'un service Cloud Run. Il s'agit d'une action post-exploitation potentielle lorsqu'un jeton Compute Engine est compromis à partir d'un service sans serveur.

Pour répondre à ce résultat, procédez comme suit :

1. Examinez les journaux d'audit dans Cloud Logging pour déterminer s'il s'agissait d'une activité attendue de la part du compte principal.
2. Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux.

Privilege Escalation: Dormant Service Account Granted Sensitive Role

Détecte les événements où un rôle IAM sensible est attribué à un compte de service géré par l'utilisateur inactif. Dans ce contexte, un compte de service est considéré comme dormant s'il est inactif depuis plus de 180 jours.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Privilege Escalation: Dormant Service Account Granted Sensitive Role, comme indiqué dans Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Récapitulatif, notez les valeurs des champs suivants.

   Sous Risque détecté :

   • Adresse e-mail principale : utilisateur ayant effectué l'action d'attribution
   • Nom du compte principal ayant reçu les droits d'accès concernés : compte de service inactif ayant reçu le rôle sensible
   • Autorisations d'accès concernées.Rôle accordé : rôle IAM sensible attribué

   Sous Ressource concernée :

   • Nom à afficher de la ressource : organisation, dossier ou projet dans lequel le rôle IAM sensible a été accordé au compte de service inactif.

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Utilisez les outils de compte de service, comme Activity Analyzer, pour examiner l'activité du compte de service inactif.
2. Contactez le propriétaire du champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Vérifier les journaux

1. Dans l'onglet Récapitulatif du panneau d'informations sur le résultat, sous Liens associés, cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.

Étape 4 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet dans lequel l'action a été effectuée.
• Supprimez l'accès du propriétaire de l'adresse e-mail du compte principal si elle est compromise.
• Supprimez le rôle IAM sensible nouvellement attribué au compte de service inactif.
• Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources affectées et collaborer avec les propriétaires des ressources pour assurer la continuité des opérations.
• Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
• Répondez à toutes les notifications de Cloud Customer Care.
• Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Privilege Escalation: Effectively Anonymous Users Granted GKE Cluster Access

Une personne a créé une liaison RBAC qui fait référence à l'un des utilisateurs ou groupes suivants :

• system:anonymous
• system:authenticated
• system:unauthenticated

Ces utilisateurs et groupes sont effectivement anonymes et doivent être évités lors de la création de liaisons de rôle ou de liaisons de rôle de cluster à des rôles RBAC. Vérifiez que la liaison est nécessaire. Si l'association n'est pas nécessaire, supprimez-la. Pour en savoir plus, consultez le message du journal concernant ce problème.

1. Examinez les liaisons créées qui ont accordé des autorisations d'accès à l'utilisateur system:anonymous, au groupe system:unauthenticated group ou au groupe system:authenticated.
2. Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux d'audit de Cloud Logging.

S'il y a des signes d'activité malveillante, consultez les conseils sur l'examen et la suppression des liaisons et appliquez-les à celles qui ont autorisé cet accès.

Privilege Escalation: External Member Added To Privileged Group

Ce résultat n'est pas disponible pour les activations au niveau du projet.

Détecte lorsqu'un membre externe est ajouté à un groupe Google privilégié (groupe doté d'autorisations ou de rôles sensibles). Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Privilege Escalation: External Member Added To Privileged Group comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail principale : compte ayant effectué les modifications.
   • Ressource concernée
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

3. Dans le panneau de détails, cliquez sur l'onglet JSON.

4. Dans le fichier JSON, notez les champs suivants.

   • groupName : groupe Google auquel les modifications ont été apportées
   • externalMember : membre externe récemment ajouté
   • sensitiveRoles : rôles sensibles associés au groupe

Étape 2 : Vérifier les membres du groupe

1. Accédez à Google Groupes.

   Accéder à Google Groupes

2. Cliquez sur le nom du groupe que vous souhaitez examiner.

3. Dans le menu de navigation, cliquez sur Membres.

4. Si le membre externe récemment ajouté ne doit pas faire partie de ce groupe, cochez la case à côté de son nom, puis sélectionnez remove_circle_outline Supprimer le membre ou not_interested Exclure le membre.

   Pour supprimer des membres, vous devez être un administrateur Google Workspace ou avoir le rôle de Propriétaire ou de Gestionnaire dans le groupe Google. Pour en savoir plus, consultez la section Attribuer des rôles aux membres d'un groupe.

Étape 3 : Vérifier les journaux

1. Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.

2. Si nécessaire, sélectionnez votre projet.

3. Sur la page qui s'affiche, consultez les journaux des modifications apportées à la liste des membres du groupe Google à l'aide des filtres suivants :

   • protoPayload.methodName="google.apps.cloudidentity.groups.v1.MembershipsService.UpdateMembership"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Comptes valides.
2. Pour déterminer si d'autres mesures correctives sont nécessaires, combinez vos résultats d'enquête avec la recherche MITRE.

Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials

Pour élever un privilège, une personne potentiellement malveillante a émis une requête de signature de certificat (CSR) à l'aide de la commande kubectl, en utilisant des identifiants d'amorçage compromis.

Voici un exemple de commande détectée par cette règle :

kubectl --client-certificate kubelet.crt --client-key kubelet.key --server YOUR_SERVER get csr CSR_NAME

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail principale : compte à l'origine de l'appel.
     • Nom de la méthode : méthode appelée.
   • Sous Ressource concernée :
     • Nom à afficher de la ressource : cluster Kubernetes dans lequel l'action s'est produite.
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

Étape 2 : Vérifier les journaux

Si le nom de la méthode, que vous avez indiqué dans le champ Nom de la méthode des détails du problème, est une méthode GET, procédez comme suit :

1. Dans l'onglet Résumé des détails du résultat dans la console Google Cloud , accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.
2. Vérifiez la valeur du champ protoPayload.resourceName pour identifier la demande de signature de certificat spécifique.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

1. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Élévation des privilèges.
2. Si la CSR spécifique est disponible dans l'entrée de journal, examinez la sensibilité du certificat et déterminez si l'action était justifiée.
3. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Privilege Escalation: Impersonation Role Granted for Dormant Service Account

Détecte les événements où un rôle d'emprunt d'identité est accordé à un compte principal, ce qui lui permet d'emprunter l'identité d'un compte de service géré par l'utilisateur inactif. Dans ce résultat, le compte de service dormant est la ressource concernée. Un compte de service est considéré comme dormant s'il est inactif depuis plus de 180 jours.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Privilege Escalation: Impersonation Role Granted for Dormant Service Account, comme indiqué dans Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Récapitulatif, notez les valeurs des champs suivants.

   Sous Risque détecté :

   • Adresse e-mail principale : utilisateur ayant effectué l'action d'attribution
   • Droits d'accès concernés.Nom du compte principal : compte principal auquel le rôle d'usurpation a été accordé

   Sous Ressource concernée :

   • Nom à afficher de la ressource : compte de service inactif en tant que ressource
   • Nom complet du projet : projet dans lequel réside le compte de service inactif

Étape 2 : Étudier les méthodes d'attaque et de réponse

1. Utilisez les outils de compte de service, comme Activity Analyzer, pour examiner l'activité du compte de service inactif.
2. Contactez le propriétaire du champ Adresse e-mail du compte principal. Confirmez si le propriétaire légitime a effectué l'action.

Étape 3 : Vérifier les journaux

1. Dans l'onglet Récapitulatif du panneau d'informations sur le résultat, sous Liens associés, cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.

Étape 4 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet dans lequel l'action a été effectuée.
• Supprimez l'accès du propriétaire de l'adresse e-mail du compte principal si elle est compromise.
• Supprimez le rôle d'usurpation d'identité nouvellement accordé au membre cible.
• Envisagez de supprimer le compte de service potentiellement compromis et d'alterner puis supprimer toutes les clés d'accès au compte de service du projet potentiellement compromis. Après suppression, les applications qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les applications concernées et collaborer avec les propriétaires des applications pour assurer la continuité des opérations.
• Collaborez avec votre équipe de sécurité pour identifier les ressources inconnues, y compris les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM. Supprimez les ressources qui n'ont pas été créées avec des comptes autorisés.
• Répondez à toutes les notifications de Cloud Customer Care.
• Pour limiter les utilisateurs autorisés à créer des comptes de service, utilisez le service de règles d'administration.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Privilege Escalation: Launch of privileged Kubernetes container

Un individu potentiellement malveillant a créé un pod contenant des conteneurs privilégiés ou dotés de capacités d'élévation des droits.

Le champ privileged d'un conteneur privilégié est défini sur true. Le champ allowPrivilegeEscalation d'un conteneur doté de fonctionnalités d'élévation des privilèges est défini sur true. Pour en savoir plus, consultez la documentation de référence de l'API SecurityContext v1 Core dans la documentation de Kubernetes.

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Privilege Escalation: Launch of privileged Kubernetes container comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail principale : compte à l'origine de l'appel.
     • Pods Kubernetes : le pod nouvellement créé avec des conteneurs privilégiés.
   • Ressource concernée, en particulier les champs suivants :
     • Nom à afficher de la ressource : cluster Kubernetes dans lequel l'action s'est produite.
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.

3. Dans l'onglet JSON, notez les valeurs des champs de résultat :

   • findings.kubernetes.pods[].containers : conteneur privilégié détecté dans le pod.

Étape 2 : Vérifier les journaux

1. Dans l'onglet Résumé des détails du résultat dans la console Google Cloud , accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.

2. Recherchez d'autres actions effectuées par le principal à l'aide des filtres suivants :

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Remplacez les éléments suivants :

   • CLUSTER_NAME : valeur que vous avez notée dans le champ Nom à afficher de la ressource des détails du résultat.

   • PRINCIPAL_EMAIL : valeur que vous avez notée dans le champ Adresse e-mail du compte principal des détails du problème.

Étape 3 : Rechercher des méthodes d'attaque et de réponse

1. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Élévation des privilèges.
2. Vérifiez que le conteneur créé nécessite un accès aux ressources de l'hôte et aux fonctionnalités du kernel.
3. Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux.

4. Si l'adresse e-mail du compte principal n'est pas un compte de service, contactez le propriétaire du compte pour confirmer que ce propriétaire légitime est bien à l'origine de l'action.

   Si l'adresse e-mail du compte principal est un compte de service (IAM ou Kubernetes), identifiez la source de l'action pour déterminer sa légitimité.

5. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Privilege Escalation: Privileged Group Opened To Public

Ce résultat n'est pas disponible pour les activations au niveau du projet.

Détecte lorsqu'un groupe Google privilégié (groupe disposant de rôles ou d'autorisations sensibles) est modifié pour devenir accessible au grand public. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Privilege Escalation: Privileged Group Opened To Public comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail principale : compte ayant effectué les modifications, qui peut être piraté.
   • Ressource concernée
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.
   1. Cliquez sur l'onglet JSON.
   2. Dans le fichier JSON, notez les champs suivants.
   • groupName : groupe Google auquel les modifications ont été apportées
   • sensitiveRoles : rôles sensibles associés au groupe
   • whoCanJoin : paramètre de joignabilité du groupe

Étape 2 : Vérifier les paramètres d'accès au groupe

1. Accédez à la console d'administration de Google Groupes. Vous devez être un administrateur Google Workspace pour vous connecter à la console.

   Accéder à la console d'administration

2. Dans le volet de navigation, cliquez sur Annuaire, puis sélectionnez Groupes.

3. Cliquez sur le nom du groupe que vous souhaitez examiner.

4. Cliquez sur Paramètres d'accès, puis, sous Qui peut rejoindre le groupe, vérifiez le paramètre de joignabilité du groupe.

5. Dans le menu déroulant, modifiez le paramètre de joignabilité si nécessaire.

Étape 3 : Vérifier les journaux

1. Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.

2. Si nécessaire, sélectionnez votre projet.

3. Sur la page qui s'affiche, consultez les journaux des modifications apportées aux paramètres du groupe Google à l'aide des filtres suivants :

   • protoPayload.methodName="google.admin.AdminService.changeGroupSetting"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Comptes valides.
2. Pour déterminer si d'autres mesures correctives sont nécessaires, combinez vos résultats d'enquête avec la recherche MITRE.

Privilege Escalation: Sensitive Role Granted To Hybrid Group

Détecte les rôles ou autorisations sensibles accordés à un groupe Google avec des membres externes. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Privilege Escalation: Sensitive Role Granted To Hybrid Group comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail principale : compte ayant effectué les modifications, qui peut être piraté.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource : ressource dans laquelle le nouveau rôle a été attribué.
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.
   1. Cliquez sur l'onglet JSON.
   2. Dans le fichier JSON, notez les champs suivants.
   • groupName : groupe Google auquel les modifications ont été apportées
   • bindingDeltas : rôles sensibles qui viennent d'être attribués au groupe.

Étape 2 : Vérifier les autorisations du groupe

1. Accédez à la page IAM de la console Google Cloud .

   Accéder à IAM

2. Dans le champ Filtre, saisissez le nom du compte répertorié dans groupName.

3. Examinez les rôles sensibles attribués au groupe.

4. Si le rôle sensible récemment ajouté n'est pas nécessaire, révoquez-le.

   Vous devez disposer d'autorisations spécifiques pour gérer les rôles dans votre organisation ou votre projet. Pour en savoir plus, consultez la section Autorisations requises.

Étape 3 : Vérifier les journaux

1. Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.

2. Si nécessaire, sélectionnez votre projet.

3. Sur la page qui s'affiche, consultez les journaux des modifications apportées aux paramètres du groupe Google à l'aide des filtres suivants :

   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Comptes valides.
2. Pour déterminer si d'autres mesures correctives sont nécessaires, combinez vos résultats d'enquête avec la recherche MITRE.

Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape

Une personne a déployé un pod avec une convention d'attribution de noms semblable à celle des outils courants utilisés pour les échappements de conteneurs ou pour exécuter d'autres attaques sur le cluster. Pour en savoir plus, consultez le message du journal associé à cette alerte.

1. Vérifiez que le pod est légitime.
2. Déterminez s'il existe d'autres signes d'activité malveillante de la part du pod ou du compte principal dans les journaux d'audit de Cloud Logging.
3. Si le compte principal n'est pas un compte de service (IAM ou Kubernetes), contactez le propriétaire du compte pour confirmer que ce propriétaire légitime est bien à l'origine de l'action.
4. Si le compte principal est un compte de service (IAM ou Kubernetes), identifiez la source de l'action pour déterminer sa légitimité.
5. Si le pod n'est pas légitime, supprimez-le, ainsi que toutes les liaisons RBAC et comptes de service associés utilisés par la charge de travail qui ont permis sa création.

Privilege Escalation: Workload Created with a Sensitive Host Path Mount

Une personne a créé une charge de travail qui contient un montage de volume hostPath vers un chemin sensible sur le système de fichiers du nœud hôte. L'accès à ces chemins d'accès sur le système de fichiers hôte peut être utilisé pour accéder à des informations privilégiées ou sensibles sur le nœud et pour les échappées de conteneur. Si possible, n'autorisez aucun volume hostPath dans votre cluster. Pour en savoir plus, consultez le message du journal associé à cette alerte.

1. Examinez la charge de travail pour déterminer si ce volume hostPath est nécessaire pour la fonctionnalité envisagée. Si c'est le cas, veillez à ce que le chemin d'accès soit le plus spécifique possible. Par exemple, /etc/myapp/myfiles au lieu de / ou /etc.
2. Déterminez s'il existe d'autres signes d'activité malveillante liée à cette charge de travail dans les journaux d'audit de Cloud Logging.

Pour bloquer l'installation de volumes hostPath dans le cluster, consultez les conseils sur l'application des normes de sécurité des pods.

Privilege Escalation: Workload with shareProcessNamespace enabled

Une personne a déployé une charge de travail avec l'option shareProcessNamespace définie sur true, ce qui permet à tous les conteneurs de partager le même espace de noms de processus Linux. Cela pourrait permettre à un conteneur non fiable ou compromis d'escalader les privilèges en accédant aux variables d'environnement, à la mémoire et à d'autres données sensibles des processus s'exécutant dans d'autres conteneurs, et en les contrôlant. Certaines charges de travail peuvent nécessiter cette fonctionnalité pour fonctionner pour des raisons légitimes, comme les conteneurs side-car de gestion des journaux ou les conteneurs de débogage. Pour en savoir plus, consultez le message du journal associé à cette alerte.

1. Vérifiez que la charge de travail nécessite réellement l'accès à un espace de noms de processus partagé pour tous les conteneurs de la charge de travail.
2. Vérifiez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux d'audit de Cloud Logging.
3. Si le compte principal n'est pas un compte de service (IAM ou Kubernetes), contactez le propriétaire du compte pour confirmer qu'il est bien à l'origine de l'action.
4. Si le compte principal est un compte de service (IAM ou Kubernetes), assurez-vous de la légitimité de ce qui a amené le compte de service à effectuer cette action.

Service account self-investigation

Des identifiants de compte de service sont utilisés pour examiner les rôles et les autorisations associés à ce même compte de service. Ce résultat indique que les identifiants du compte de service pourraient être compromis et qu'une action immédiate doit être effectuée.

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Discovery: Service Account Self-Investigation, comme indiqué dans la section Examiner les détails des résultats plus haut sur cette page. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Gravité : niveau de risque attribué au résultat. La gravité est définie sur HIGH si l'appel d'API qui a déclenché ce résultat n'est pas autorisé. Le compte de service n'est pas autorisé à interroger ses propres autorisations IAM avec l'API projects.getIamPolicy.
     • Adresse e-mail principale : compte de service potentiellement compromis.
     • Adresse IP de l'appelant : adresse IP interne ou externe
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource :
     • Nom complet du projet : projet contenant les identifiants de compte potentiellement divulgués.
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK : lien vers la documentation MITRE ATT&CK.
     • Résultats associés : liens vers les résultats associés.
   1. Pour afficher le code JSON complet du résultat, cliquez sur l'onglet JSON.

Étape 2 : Vérifier les autorisations des projets et des comptes de service

1. Dans la console Google Cloud , accédez à la page IAM.

   Accéder à IAM

2. Si nécessaire, sélectionnez le projet répertorié dans le champ projectID du fichier JSON du résultat.

3. Sur la page qui s'affiche, dans la zone Filtre, saisissez le nom du compte répertorié dans Adresse e-mail principale et vérifiez les autorisations attribuées.

4. Dans la console Google Cloud , accédez à la page Comptes de service.

   Accéder à la page "Comptes de service"

5. Sur la page qui s'affiche, dans le champ Filtre, saisissez le nom du compte de service compromis et vérifiez ses clés ainsi que les dates de création des clés.

Étape 3 : Vérifier les journaux

1. Dans l'onglet Récapitulatif du panneau "Détails du résultat", cliquez sur le lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
2. Si nécessaire, sélectionnez votre projet.
3. Sur la page qui s'affiche, vérifiez les journaux d'activité des ressources IAM nouvelles ou mises à jour à l'aide des filtres suivants :
   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Étape 4 : Rechercher des méthodes d'attaque et de réponse

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Découverte de groupes d'autorisations : Groupes Cloud.
2. Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 5 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet contenant le conteneur compromis.
• Supprimer le compte de service compromis : et alterner puis supprimer toutes les clés d'accès de compte de service du projet compromis. Après suppression, les ressources qui utilisent le compte de service pour l'authentification perdent l'accès.
• Supprimez les ressources de projet créées par le compte compromis telles que les instances Compute Engine, les instantanés, les comptes de service et les utilisateurs IAM inconnus.

Détection des métadonnées de l'administrateur Compute Engine

Persistence: GCE Admin Added SSH Key

Persistence: GCE Admin Added Startup Script

Détection des journaux Google Workspace

Si vous partagez vos journaux Google Workspace avec Cloud Logging, Event Threat Detection génère des résultats pour plusieurs menaces Google Workspace. Les journaux Google Workspace étant au niveau de l'organisation, Event Threat Detection ne peut les analyser que si vous activez Security Command Center au niveau de l'organisation.

Event Threat Detection enrichit les événements des journaux et écrit les résultats dans Security Command Center. Le tableau suivant contient les menaces Google Workspace, les entrées pertinentes du framework MITRE ATT&CK et les détails des événements qui déclenchent des résultats. Vous pouvez également vérifier les journaux à l'aide de filtres spécifiques et combiner toutes les informations pour répondre aux menaces Google Workspace.

Initial Access: Disabled Password Leak

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Initial Access: Suspicious Login Blocked

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Initial Access: Account Disabled Hijacked

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Impair Defenses: Two Step Verification Disabled

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Initial Access: Government Based Attack

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Persistence: SSO Enablement Toggle

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Persistence: SSO Settings Changed

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Impair Defenses: Strong Authentication Disabled

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Réagir aux menaces Google Workspace

Les résultats pour Google Workspace ne sont disponibles que pour les activations de Security Command Center au niveau de l'organisation. Il est impossible d'analyser les journaux Google Workspace pour les activations au niveau du projet.

Si vous êtes administrateur Google Workspace, vous pouvez utiliser les outils de sécurité du service pour résoudre ces menaces :

• Centre d'alerte Google Workspace
• Centre de sécurité Google Workspace

Ces outils incluent des alertes, un tableau de bord de sécurité et des recommandations de sécurité qui peuvent vous aider à examiner et à résoudre les menaces.

Si vous n'êtes pas administrateur Google Workspace, procédez comme suit :

• Si vous avez encore accès à votre compte, modifiez ou réinitialisez votre mot de passe et activez la validation en deux étapes.
• Contactez votre administrateur Google Workspace ou l'équipe de votre entreprise qui gère votre compte Google Workspace. Utilisez ces résultats pour indiquer qu'un compte peut être compromis.

Détections des menaces Cloud IDS

Cloud IDS: THREAT_ID

Les résultats Cloud IDS sont générés par Cloud IDS, un service de sécurité qui surveille le trafic vers et depuis vos ressourcesGoogle Cloud pour détecter les menaces. Lorsque Cloud IDS détecte une menace, il envoie des informations à son sujet (adresse IP source, adresse de destination et numéro de port, par exemple) à Event Threat Detection, qui génère ensuite un résultat de menace.

Étape 1 : Examiner les détails du résultat

1. Ouvrez le résultat Cloud IDS: THREAT_ID, comme indiqué dans Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Résumé, examinez les valeurs listées dans les sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Protocole : protocole réseau utilisé
     • Heure de l'événement : moment où l'événement s'est produit
     • Description : informations supplémentaires sur le problème
     • Gravité : niveau de gravité de l'alerte.
     • Adresse IP de destination : adresse IP cible du trafic réseau
     • Port de destination : port cible du trafic réseau
     • Adresse IP source : adresse IP source du trafic réseau
     • Port source : port source du trafic réseau
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource : projet contenant le réseau avec la menace
   • Liens associés, en particulier les champs suivants :
     • URI Cloud Logging : lien vers les entrées Cloud IDS Logging. Ces entrées contiennent les informations nécessaires pour rechercher le Threat Vault de Palo Alto Networks.
   • Service de détection
     • Catégorie du résultat : nom de la menace Cloud IDS

3. Pour afficher le code JSON complet du résultat, cliquez sur l'onglet JSON.

Étape 2 : Rechercher des méthodes d'attaque et de réponse

Après avoir examiné les détails de la découverte, veuillez consulter la documentation Cloud IDS sur l'examen des alertes de menace pour déterminer la réponse appropriée.

Pour en savoir plus sur l'événement détecté, cliquez sur le lien dans le champ URI Cloud Logging des détails du résultat.

Réponses Container Threat Detection

Pour en savoir plus sur Container Threat Detection, découvrez le fonctionnement de Container Threat Detection.

Added Binary Executed

Un fichier binaire ne faisant pas partie de l'image de conteneur d'origine a été exécuté. Les pirates informatiques installent généralement les outils d'exploitation et les logiciels malveillants après le piratage initial. Il est important de s'assurer que vos conteneurs sont immuables. Il s'agit d'un problème de faible gravité, car il est possible que votre organisation ne suive pas cette bonne pratique. Des résultats Execution: Added Malicious Binary Executed correspondants s'affichent lorsque le hachage du binaire est un indicateur de compromission (IoC) connu. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Added Binary Executed comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Binaire du programme : chemin d'accès absolu du binaire ajouté.
     • Arguments : arguments fournis lors de l'appel du binaire ajouté.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource : nom complet de la ressource du cluster, y compris le numéro de projet, l'emplacement et le nom du cluster.
   • Liens associés, en particulier les champs suivants :
     • Indicateur VirusTotal : lien vers la page d'analyse VirusTotal.

3. Cliquez sur JSON et notez les champs suivants :

   • resource :
     • project_display_name : nom du projet contenant le cluster.
   • sourceProperties :
     • Pod_Namespace : nom de l'espace de noms Kubernetes du pod.
     • Pod_Name : nom du pod GKE.
     • Container_Name : nom du conteneur concerné.
     • Container_Image_Uri : nom de l'image de conteneur en cours de déploiement.
     • VM_Instance_Name : nom du nœud GKE sur lequel le pod a été exécuté.

4. Identifiez d'autres résultats qui se sont produits à peu près au même moment pour ce conteneur. Les résultats associés peuvent indiquer que cette activité était malveillante, plutôt qu'un non-respect des bonnes pratiques.

Étape 2 : Vérifier le cluster et le nœud

1. Dans la console Google Cloud , accédez à la page Clusters Kubernetes.

   Accéder à la page "Clusters Kubernetes"

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Sélectionnez le cluster listé sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat. Notez toutes les métadonnées concernant le cluster et son propriétaire.

4. Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.

5. Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

1. Dans la console Google Cloud , accédez à la page Charges de travail Kubernetes.

   Accéder à la page "Charges de travail Kubernetes"

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Filtrez le cluster listé dans la ligne Nom complet de la ressource de l'onglet Résumé des détails du résultat et l'espace de noms du pod listé dans Pod_Namespace, si nécessaire.

4. Sélectionnez le pod répertorié dans Pod_Name. Notez les métadonnées concernant le pod et son propriétaire.

Étape 4 : Vérifier les journaux

1. Dans la console Google Cloud , accédez à l'explorateur de journaux.

   Accéder à l'explorateur de journaux

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Définissez Sélectionner une période sur la période qui vous intéresse.

4. Sur la page qui s'affiche, procédez comme suit :

   1. Recherchez Pod_Name dans les journaux des pods à l'aide du filtre suivant :
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Recherchez les journaux d'audit du cluster à l'aide du filtre suivant :
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Recherchez les journaux de la console de nœud GKE à l'aide du filtre suivant :
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Étape 5 : Examiner le conteneur en cours d'exécution

Si le conteneur est toujours en cours d'exécution, il peut être possible d'analyser directement l'environnement du conteneur.

1. Accédez à la console Google Cloud .

   Ouvrir la console Google Cloud

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Cliquez sur Activer Cloud Shell.

4. Obtenez les identifiants GKE pour votre cluster en exécutant les commandes suivantes.

   Pour les clusters zonaux :

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   Pour les clusters régionaux :

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   Remplacez les éléments suivants :

   • cluster_name : cluster répertorié dans resource.labels.cluster_name
   • location : emplacement répertorié dans resource.labels.location
   • project_name : nom du projet répertorié dans resource.project_display_name

5. Récupérez le binaire ajouté en exécutant la commande suivante :

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   Remplacez local_file par un chemin d'accès au fichier local pour stocker le binaire ajouté.

6. Connectez-vous à l'environnement de conteneur en exécutant la commande suivante :

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Pour ce faire, une interface système est installée sur le conteneur à l'adresse /bin/sh.

Étape 6 : Étudier les méthodes d'attaque et de réponse

1. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Transfert d'outil Ingress, API native.
2. Vérifiez la valeur de hachage SHA-256 du fichier binaire signalé comme malveillant sur VirusTotal en cliquant sur le lien dans l'indicateur VirusTotal. VirusTotal est un service appartenant à Alphabet qui fournit du contexte sur des fichiers, des URL, des domaines et des adresses IP potentiellement malveillants.
3. Pour élaborer un plan d'intervention, combinez les résultats de vos enquêtes avec les recherches MITRE et l'analyse VirusTotal.

Étape 7 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Si le binaire était censé être inclus dans le conteneur, recréez l'image de conteneur en incluant le binaire. Le conteneur peut ainsi être immuable.
• Sinon, contactez le propriétaire du projet contenant le conteneur compromis.
• Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

Added Library Loaded

Une bibliothèque ne faisant pas partie de l'image de conteneur d'origine a été chargée. Les pirates informatiques peuvent charger des bibliothèques malveillantes dans des programmes existants afin de contourner les protections d'exécution du code et de masquer du code malveillant. Il est important de s'assurer que vos conteneurs sont immuables. Il s'agit d'un problème de faible gravité, car il est possible que votre organisation ne suive pas cette bonne pratique. Des résultats Execution: Added Malicious Library Loaded correspondants s'affichent lorsque le hachage du binaire est un indicateur de compromission (IoC) connu. Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Added Library Loaded comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Binaire du programme : chemin d'accès complet du binaire du processus qui a chargé la bibliothèque.
     • Bibliothèques : détails concernant la bibliothèque ajoutée.
     • Arguments : arguments fournis lors de l'appel du binaire du processus.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource : nom complet de la ressource du cluster.
   • Liens associés, en particulier les champs suivants :
     • Indicateur VirusTotal : lien vers la page d'analyse VirusTotal.

3. Cliquez sur l'onglet JSON et notez les champs suivants :

   • resource :
     • project_display_name : nom du projet contenant le composant.
   • sourceProperties :
     • Pod_Namespace : nom de l'espace de noms Kubernetes du pod.
     • Pod_Name : nom du pod GKE.
     • Container_Name : nom du conteneur concerné.
     • Container_Image_Uri : nom de l'image de conteneur en cours d'exécution.
     • VM_Instance_Name : nom du nœud GKE sur lequel le pod a été exécuté.

4. Identifiez d'autres résultats qui se sont produits à peu près au même moment pour ce conteneur. Les résultats associés peuvent indiquer que cette activité était malveillante, plutôt qu'un non-respect des bonnes pratiques.

Étape 2 : Vérifier le cluster et le nœud

1. Dans la console Google Cloud , accédez à la page Clusters Kubernetes.

   Accéder à la page "Clusters Kubernetes"

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Sélectionnez le cluster répertorié dans resource.name. Notez toutes les métadonnées concernant le cluster et son propriétaire.

4. Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.

5. Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

1. Dans la console Google Cloud , accédez à la page Charges de travail Kubernetes.

   Accéder à la page "Charges de travail Kubernetes"

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Filtrez le cluster listé dans la ligne Nom complet de la ressource de l'onglet Résumé des détails du résultat et l'espace de noms du pod listé dans Pod_Namespace, si nécessaire.

4. Sélectionnez le pod répertorié dans Pod_Name. Notez les métadonnées concernant le pod et son propriétaire.

Étape 4 : Vérifier les journaux

1. Dans la console Google Cloud , accédez à l'explorateur de journaux.

   Accéder à l'explorateur de journaux

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Définissez Sélectionner une période sur la période qui vous intéresse.

4. Sur la page qui s'affiche, procédez comme suit :

   1. Recherchez Pod_Name dans les journaux des pods à l'aide du filtre suivant :
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Recherchez les journaux d'audit du cluster à l'aide du filtre suivant :
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Recherchez les journaux de la console de nœud GKE à l'aide du filtre suivant :
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Étape 5 : Examiner le conteneur en cours d'exécution

Si le conteneur est toujours en cours d'exécution, il peut être possible d'analyser directement l'environnement du conteneur.

1. Accédez à la console Google Cloud .

   Ouvrir la console Google Cloud

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Cliquez sur Activer Cloud Shell.

4. Obtenez les identifiants GKE pour votre cluster en exécutant les commandes suivantes.

   Pour les clusters zonaux :

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   Pour les clusters régionaux :

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. Récupérez la bibliothèque ajoutée en exécutant la commande suivante :

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   Remplacez local_file par un chemin d'accès local au fichier pour stocker la bibliothèque ajoutée.

6. Connectez-vous à l'environnement de conteneur en exécutant la commande suivante :

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Pour ce faire, une interface système est installée sur le conteneur à l'adresse /bin/sh.

Étape 6 : Étudier les méthodes d'attaque et de réponse

1. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Transfert d'outil Ingress, Modules partagés.
2. Vérifiez la valeur de hachage SHA-256 du fichier binaire signalé comme malveillant sur VirusTotal en cliquant sur le lien dans l'indicateur VirusTotal. VirusTotal est un service appartenant à Alphabet qui fournit du contexte sur des fichiers, des URL, des domaines et des adresses IP potentiellement malveillants.
3. Pour élaborer un plan d'intervention, combinez les résultats de vos enquêtes avec les recherches MITRE et l'analyse VirusTotal.

Étape 7 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Si la bibliothèque était censée être incluse dans le conteneur, recréez l'image de conteneur en incluant la bibliothèque. Le conteneur peut ainsi être immuable.
• Sinon, contactez le propriétaire du projet contenant le conteneur compromis.
• Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

Command and Control: Steganography Tool Detected

Un processus a été détecté. Il utilise des outils de stéganographie couramment présents dans les distributions de type Unix pour potentiellement dissimuler des communications. Ce comportement suggère une tentative de dissimulation du trafic de commande et de contrôle (C2) ou de données sensibles dans des messages numériques apparemment inoffensifs échangés avec une entité externe. Les pirates informatiques utilisent souvent la stéganographie pour échapper à la surveillance du réseau et rendre les activités malveillantes moins visibles. La présence de ces outils suggère une tentative délibérée d'obscurcir le transfert de données illicites. Ce comportement peut entraîner une compromission ou une exfiltration supplémentaires d'informations sensibles. Il est essentiel d'identifier le contenu masqué pour évaluer précisément les risques encourus.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Command and Control: Steganography Tool Detected comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Binaire du programme : chemin d'accès absolu du binaire exécuté.
     • Arguments : arguments transmis lors de l'exécution du binaire.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource : nom complet de la ressource du cluster, y compris le numéro de projet, l'emplacement et le nom du cluster.

3. Dans la vue détaillée du résultat, cliquez sur l'onglet JSON.

4. Dans le fichier JSON, notez les champs suivants.

   • resource :
     • project_display_name : nom du projet contenant le cluster.
   • finding :
     • processes :
     • binary :
       • path : chemin d'accès complet du binaire exécuté.
     • args : arguments fournis lors de l'exécution du binaire.
   • sourceProperties :
     • Pod_Namespace : nom de l'espace de noms Kubernetes du pod.
     • Pod_Name : nom du pod GKE.
     • Container_Name : nom du conteneur concerné.
     • Container_Image_Uri : nom de l'image de conteneur en cours de déploiement.
     • VM_Instance_Name : nom du nœud GKE sur lequel le pod a été exécuté.

5. Identifiez d'autres résultats qui se sont produits à peu près au même moment pour ce conteneur. Les résultats associés peuvent indiquer que cette activité était malveillante, plutôt qu'un non-respect des bonnes pratiques.

Étape 2 : Vérifier le cluster et le nœud

1. Dans la console Google Cloud , accédez à la page Clusters Kubernetes.

   Accéder à la page "Clusters Kubernetes"

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Sélectionnez le cluster listé sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat. Notez toutes les métadonnées concernant le cluster et son propriétaire.

4. Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.

5. Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

1. Dans la console Google Cloud , accédez à la page Charges de travail Kubernetes.

   Accéder à la page "Charges de travail Kubernetes"

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Filtrez le cluster listé dans la ligne Nom complet de la ressource de l'onglet Résumé des détails du résultat et l'espace de noms du pod listé dans Pod_Namespace, si nécessaire.

4. Sélectionnez le pod répertorié dans Pod_Name. Notez les métadonnées concernant le pod et son propriétaire.

Étape 4 : Vérifier les journaux

1. Dans la console Google Cloud , accédez à l'explorateur de journaux.

   Accéder à l'explorateur de journaux

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Définissez Sélectionner une période sur la période qui vous intéresse.

4. Sur la page qui s'affiche, procédez comme suit :

   1. Recherchez Pod_Name dans les journaux des pods à l'aide du filtre suivant :
      • resource.type="k8s_container"
      • resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • resource.labels.namespace_name="POD_NAMESPACE"
      • resource.labels.pod_name="POD_NAME"
   2. Recherchez les journaux d'audit du cluster à l'aide du filtre suivant :
      • logName="projects/RESOURCE.PROJECT_DISPLAY_NAME/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • POD_NAME
   3. Recherchez les journaux de la console de nœud GKE à l'aide du filtre suivant :
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

Étape 5 : Examiner le conteneur en cours d'exécution

Si le conteneur est toujours en cours d'exécution, il peut être possible d'analyser directement l'environnement du conteneur.

1. Accédez à la console Google Cloud .

   Ouvrir la console Google Cloud

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Cliquez sur Activer Cloud Shell.

4. Obtenez les identifiants GKE pour votre cluster en exécutant les commandes suivantes.

   Pour les clusters zonaux :

   gcloud container clusters get-credentials CLUSTER_NAME \
         --zone LOCATION \
         --project PROJECT_NAME
   

   Pour les clusters régionaux :

   gcloud container clusters get-credentials CLUSTER_NAME \
         --region LOCATION \
         --project PROJECT_NAME
   

   Remplacez les éléments suivants :

   • CLUSTER_NAME : cluster répertorié dans resource.labels.cluster_name
   • LOCATION : emplacement répertorié dans resource.labels.location
   • PROJECT_NAME : nom du projet répertorié dans resource.project_display_name

5. Récupérez le binaire exécuté :

   kubectl cp \
         POD_NAMESPACE/POD_NAME:PROCESS_BINARY_FULLPATH \
         -c CONTAINER_NAME \
         LOCAL_FILE
   

   Remplacez local_file par un chemin d'accès au fichier local pour stocker le binaire ajouté.

6. Connectez-vous à l'environnement de conteneur en exécutant la commande suivante :

   kubectl exec \
         --namespace=POD_NAMESPACE \
         -ti POD_NAME \
         -c CONTAINER_NAME \
         -- /bin/sh
   

   Pour ce faire, une interface système est installée sur le conteneur à l'adresse /bin/sh.

Étape 6 : Étudier les méthodes d'attaque et de réponse

1. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Obscurcissement des données : stéganographie.
2. Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 7 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet contenant le conteneur compromis.
• Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

Credential Access: Find Google Cloud Credentials

Un processus a été détecté lors de la recherche d'identifiants Google Cloud . Ce comportement suggère une tentative de localisation et d'extraction de secrets stockés qui pourraient être utilisés pour élever les privilèges, accéder à des ressources restreintes ou se déplacer latéralement dans l'environnement. Les pirates informatiques recherchent fréquemment des identifiants pour accéder de manière non autorisée aux ressources cloud afin d'obtenir des droits plus élevés ou d'exécuter des comportements malveillants.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Credential Access: Find Google Cloud Credentials comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Binaire du programme : chemin d'accès absolu du binaire exécuté.
     • Arguments : arguments transmis lors de l'exécution du binaire.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource : nom complet de la ressource du cluster, y compris le numéro de projet, l'emplacement et le nom du cluster.

3. Dans la vue détaillée du résultat, cliquez sur l'onglet JSON.

4. Dans le fichier JSON, notez les champs suivants.

   • resource :
     • project_display_name : nom du projet contenant le cluster.
   • finding :
     • processes :
     • binary :
       • path : chemin d'accès complet du binaire exécuté.
     • args : arguments fournis lors de l'exécution du binaire.
   • sourceProperties :
     • Pod_Namespace : nom de l'espace de noms Kubernetes du pod.
     • Pod_Name : nom du pod GKE.
     • Container_Name : nom du conteneur concerné.
     • Container_Image_Uri : nom de l'image de conteneur en cours de déploiement.
     • VM_Instance_Name : nom du nœud GKE sur lequel le pod a été exécuté.

5. Identifiez d'autres résultats qui se sont produits à peu près au même moment pour ce conteneur. Les résultats associés peuvent indiquer que cette activité était malveillante, plutôt qu'un non-respect des bonnes pratiques.

Étape 2 : Vérifier le cluster et le nœud

1. Dans la console Google Cloud , accédez à la page Clusters Kubernetes.

   Accéder à la page "Clusters Kubernetes"

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Sélectionnez le cluster listé sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat. Notez toutes les métadonnées concernant le cluster et son propriétaire.

4. Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.

5. Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

1. Dans la console Google Cloud , accédez à la page Charges de travail Kubernetes.

   Accéder à la page "Charges de travail Kubernetes"

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Filtrez le cluster listé dans la ligne Nom complet de la ressource de l'onglet Résumé des détails du résultat et l'espace de noms du pod listé dans Pod_Namespace, si nécessaire.

4. Sélectionnez le pod répertorié dans Pod_Name. Notez les métadonnées concernant le pod et son propriétaire.

Étape 4 : Vérifier les journaux

1. Dans la console Google Cloud , accédez à l'explorateur de journaux.

   Accéder à l'explorateur de journaux

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Définissez Sélectionner une période sur la période qui vous intéresse.

4. Sur la page qui s'affiche, procédez comme suit :

   1. Recherchez Pod_Name dans les journaux des pods à l'aide du filtre suivant :
      • resource.type="k8s_container"
      • resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • resource.labels.namespace_name="POD_NAMESPACE"
      • resource.labels.pod_name="POD_NAME"
   2. Recherchez les journaux d'audit du cluster à l'aide du filtre suivant :
      • logName="projects/RESOURCE.PROJECT_DISPLAY_NAME/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • POD_NAME
   3. Recherchez les journaux de la console de nœud GKE à l'aide du filtre suivant :
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

Étape 5 : Examiner le conteneur en cours d'exécution

Si le conteneur est toujours en cours d'exécution, il peut être possible d'analyser directement l'environnement du conteneur.

1. Accédez à la console Google Cloud .

   Ouvrir la console Google Cloud

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Cliquez sur Activer Cloud Shell.

4. Obtenez les identifiants GKE pour votre cluster en exécutant les commandes suivantes.

   Pour les clusters zonaux :

   gcloud container clusters get-credentials CLUSTER_NAME \
         --zone LOCATION \
         --project PROJECT_NAME
   

   Pour les clusters régionaux :

   gcloud container clusters get-credentials CLUSTER_NAME \
         --region LOCATION \
         --project PROJECT_NAME
   

   Remplacez les éléments suivants :

   • CLUSTER_NAME : cluster répertorié dans resource.labels.cluster_name
   • LOCATION : emplacement répertorié dans resource.labels.location
   • PROJECT_NAME : nom du projet répertorié dans resource.project_display_name

5. Connectez-vous à l'environnement de conteneur en exécutant la commande suivante :

   kubectl exec \
         --namespace=POD_NAMESPACE \
         -ti POD_NAME \
         -c CONTAINER_NAME \
         -- /bin/sh
   

   Pour ce faire, une interface système est installée sur le conteneur à l'adresse /bin/sh.

Étape 6 : Étudier les méthodes d'attaque et de réponse

1. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Identifiants non sécurisés : clés privées.
2. Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 7 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet contenant le conteneur compromis.
• Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

Credential Access: GPG Key Reconnaissance

Un processus a été détecté lors de la recherche de clés GPG. Ce comportement suggère une tentative de localisation et d'extraction des clés de sécurité stockées utilisées pour chiffrer et déchiffrer des documents, et pour authentifier des documents avec des signatures numériques. Les pirates informatiques utilisent des clés de sécurité pour accéder de manière non autorisée à des informations et des systèmes critiques. Il s'agit donc d'une détection de haute gravité qui nécessite une enquête immédiate.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Credential Access: GPG Key Reconnaissance comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Binaire du programme : chemin d'accès absolu du binaire exécuté.
     • Arguments : arguments transmis lors de l'exécution du binaire.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource : nom complet de la ressource du cluster, y compris le numéro de projet, l'emplacement et le nom du cluster.

3. Dans la vue détaillée du résultat, cliquez sur l'onglet JSON.

4. Dans le fichier JSON, notez les champs suivants.

   • resource :
     • project_display_name : nom du projet contenant le cluster.
   • finding :
     • processes :
     • binary :
       • path : chemin d'accès complet du binaire exécuté.
     • args : arguments fournis lors de l'exécution du binaire.
   • sourceProperties :
     • Pod_Namespace : nom de l'espace de noms Kubernetes du pod.
     • Pod_Name : nom du pod GKE.
     • Container_Name : nom du conteneur concerné.
     • Container_Image_Uri : nom de l'image de conteneur en cours de déploiement.
     • VM_Instance_Name : nom du nœud GKE sur lequel le pod a été exécuté.

5. Identifiez d'autres résultats qui se sont produits à peu près au même moment pour ce conteneur. Les résultats associés peuvent indiquer que cette activité était malveillante, plutôt qu'un non-respect des bonnes pratiques.

Étape 2 : Vérifier le cluster et le nœud

1. Dans la console Google Cloud , accédez à la page Clusters Kubernetes.

   Accéder à la page "Clusters Kubernetes"

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Sélectionnez le cluster listé sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat. Notez toutes les métadonnées concernant le cluster et son propriétaire.

4. Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.

5. Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

1. Dans la console Google Cloud , accédez à la page Charges de travail Kubernetes.

   Accéder à la page "Charges de travail Kubernetes"

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Filtrez le cluster listé dans la ligne Nom complet de la ressource de l'onglet Résumé des détails du résultat et l'espace de noms du pod listé dans Pod_Namespace, si nécessaire.

4. Sélectionnez le pod répertorié dans Pod_Name. Notez les métadonnées concernant le pod et son propriétaire.

Étape 4 : Vérifier les journaux

1. Dans la console Google Cloud , accédez à l'explorateur de journaux.

   Accéder à l'explorateur de journaux

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Définissez Sélectionner une période sur la période qui vous intéresse.

4. Sur la page qui s'affiche, procédez comme suit :

   1. Recherchez Pod_Name dans les journaux des pods à l'aide du filtre suivant :
      • resource.type="k8s_container"
      • resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • resource.labels.namespace_name="POD_NAMESPACE"
      • resource.labels.pod_name="POD_NAME"
   2. Recherchez les journaux d'audit du cluster à l'aide du filtre suivant :
      • logName="projects/RESOURCE.PROJECT_DISPLAY_NAME/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • POD_NAME
   3. Recherchez les journaux de la console de nœud GKE à l'aide du filtre suivant :
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

Étape 5 : Examiner le conteneur en cours d'exécution

Si le conteneur est toujours en cours d'exécution, il peut être possible d'analyser directement l'environnement du conteneur.

1. Accédez à la console Google Cloud .

   Ouvrir la console Google Cloud

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Cliquez sur Activer Cloud Shell.

4. Obtenez les identifiants GKE pour votre cluster en exécutant les commandes suivantes.

   Pour les clusters zonaux :

   gcloud container clusters get-credentials CLUSTER_NAME \
         --zone LOCATION \
         --project PROJECT_NAME
   

   Pour les clusters régionaux :

   gcloud container clusters get-credentials CLUSTER_NAME \
         --region LOCATION \
         --project PROJECT_NAME
   

   Remplacez les éléments suivants :

   • CLUSTER_NAME : cluster répertorié dans resource.labels.cluster_name
   • LOCATION : emplacement répertorié dans resource.labels.location
   • PROJECT_NAME : nom du projet répertorié dans resource.project_display_name

5. Connectez-vous à l'environnement de conteneur en exécutant la commande suivante :

   kubectl exec \
         --namespace=POD_NAMESPACE \
         -ti POD_NAME \
         -c CONTAINER_NAME \
         -- /bin/sh
   

   Pour ce faire, une interface système est installée sur le conteneur à l'adresse /bin/sh.

Étape 6 : Étudier les méthodes d'attaque et de réponse

1. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Identifiants non sécurisés : clés privées.
2. Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 7 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet contenant le conteneur compromis.
• Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

Credential Access: Search Private Keys or Passwords

Un processus a été détecté lors de la recherche de clés privées, d'identifiants ou d'autres informations d'authentification sensibles dans le conteneur. Ce comportement suggère une tentative de localisation et d'extraction de secrets stockés qui pourraient être utilisés pour élever les privilèges, accéder à des ressources restreintes ou se déplacer latéralement dans l'environnement. Les pirates informatiques recherchent fréquemment des clés SSH, des jetons d'API ou des identifiants de base de données pour accéder de manière non autorisée à des systèmes critiques. Il s'agit donc d'une détection de haute gravité qui nécessite une enquête immédiate.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Credential Access: Search Private Keys or Passwords comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Binaire du programme : chemin d'accès absolu du binaire exécuté.
     • Arguments : arguments transmis lors de l'exécution du binaire.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource : nom complet de la ressource du cluster, y compris le numéro de projet, l'emplacement et le nom du cluster.

3. Dans la vue détaillée du résultat, cliquez sur l'onglet JSON.

4. Dans le fichier JSON, notez les champs suivants.

   • resource :
     • project_display_name : nom du projet contenant le cluster.
   • finding :
     • processes :
     • binary :
       • path : chemin d'accès complet du binaire exécuté.
     • args : arguments fournis lors de l'exécution du binaire.
   • sourceProperties :
     • Pod_Namespace : nom de l'espace de noms Kubernetes du pod.
     • Pod_Name : nom du pod GKE.
     • Container_Name : nom du conteneur concerné.
     • Container_Image_Uri : nom de l'image de conteneur en cours de déploiement.
     • VM_Instance_Name : nom du nœud GKE sur lequel le pod a été exécuté.

5. Identifiez d'autres résultats qui se sont produits à peu près au même moment pour ce conteneur. Les résultats associés peuvent indiquer que cette activité était malveillante, plutôt qu'un non-respect des bonnes pratiques.

Étape 2 : Vérifier le cluster et le nœud

1. Dans la console Google Cloud , accédez à la page Clusters Kubernetes.

   Accéder à la page "Clusters Kubernetes"

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Sélectionnez le cluster listé sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat. Notez toutes les métadonnées concernant le cluster et son propriétaire.

4. Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.

5. Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

1. Dans la console Google Cloud , accédez à la page Charges de travail Kubernetes.

   Accéder à la page "Charges de travail Kubernetes"

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Filtrez le cluster listé dans la ligne Nom complet de la ressource de l'onglet Résumé des détails du résultat et l'espace de noms du pod listé dans Pod_Namespace, si nécessaire.

4. Sélectionnez le pod répertorié dans Pod_Name. Notez les métadonnées concernant le pod et son propriétaire.

Étape 4 : Vérifier les journaux

1. Dans la console Google Cloud , accédez à l'explorateur de journaux.

   Accéder à l'explorateur de journaux

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Définissez Sélectionner une période sur la période qui vous intéresse.

4. Sur la page qui s'affiche, procédez comme suit :

   1. Recherchez Pod_Name dans les journaux des pods à l'aide du filtre suivant :
      • resource.type="k8s_container"
      • resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • resource.labels.namespace_name="POD_NAMESPACE"
      • resource.labels.pod_name="POD_NAME"
   2. Recherchez les journaux d'audit du cluster à l'aide du filtre suivant :
      • logName="projects/RESOURCE.PROJECT_DISPLAY_NAME/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • POD_NAME
   3. Recherchez les journaux de la console de nœud GKE à l'aide du filtre suivant :
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

Étape 5 : Examiner le conteneur en cours d'exécution

Si le conteneur est toujours en cours d'exécution, il peut être possible d'analyser directement l'environnement du conteneur.

1. Accédez à la console Google Cloud .

   Ouvrir la console Google Cloud

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Cliquez sur Activer Cloud Shell.

4. Obtenez les identifiants GKE pour votre cluster en exécutant les commandes suivantes.

   Pour les clusters zonaux :

   gcloud container clusters get-credentials CLUSTER_NAME \
         --zone LOCATION \
         --project PROJECT_NAME
   

   Pour les clusters régionaux :

   gcloud container clusters get-credentials CLUSTER_NAME \
         --region LOCATION \
         --project PROJECT_NAME
   

   Remplacez les éléments suivants :

   • CLUSTER_NAME : cluster répertorié dans resource.labels.cluster_name
   • LOCATION : emplacement répertorié dans resource.labels.location
   • PROJECT_NAME : nom du projet répertorié dans resource.project_display_name

5. Récupérez le binaire exécuté :

   kubectl cp \
         POD_NAMESPACE/POD_NAME:PROCESS_BINARY_FULLPATH \
         -c CONTAINER_NAME \
         LOCAL_FILE
   

   Remplacez local_file par un chemin d'accès au fichier local pour stocker le binaire ajouté.

6. Connectez-vous à l'environnement de conteneur en exécutant la commande suivante :

   kubectl exec \
         --namespace=POD_NAMESPACE \
         -ti POD_NAME \
         -c CONTAINER_NAME \
         -- /bin/sh
   

   Pour ce faire, une interface système est installée sur le conteneur à l'adresse /bin/sh.

Étape 6 : Étudier les méthodes d'attaque et de réponse

1. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Identifiants non sécurisés : identifiants dans les fichiers.
2. Pour élaborer un plan de réponse, combinez les résultats de vos enquêtes avec la recherche MITRE.

Étape 7 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations. Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.

• Contactez le propriétaire du projet contenant le conteneur compromis.
• Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

Defense Evasion: Base64 ELF File Command Line

Un processus a été exécuté et contient un argument qui est un fichier ELF (Executable and Linkable Format). Si l'exécution d'un fichier ELF encodé est détectée, cela indique qu'un pirate informatique tente d'encoder des données binaires pour les transférer vers des lignes de commande ASCII uniquement. Les pirates informatiques peuvent utiliser cette technique pour échapper à la détection et exécuter du code malveillant intégré dans un fichier ELF.

Pour répondre à ce résultat, procédez comme suit :

Étape 1 : Examiner les détails du résultat

1. Ouvrez un résultat Defense Evasion: Base64 ELF File Command Line comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :

   • Ce qui a été détecté, en particulier les champs suivants :
     • Binaire du programme : chemin d'accès absolu du binaire exécuté.
     • Arguments : arguments transmis lors de l'exécution du binaire.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource : nom complet de la ressource du cluster, y compris le numéro de projet, l'emplacement et le nom du cluster.

3. Dans la vue détaillée du résultat, cliquez sur l'onglet JSON.

4. Dans le fichier JSON, notez les champs suivants.

   • resource :
     • project_display_name : nom du projet contenant le cluster.
   • finding :
     • processes :
     • binary :
       • path : chemin d'accès complet du binaire exécuté.
     • args : arguments fournis lors de l'exécution du binaire.
   • sourceProperties :
     • Pod_Namespace : nom de l'espace de noms Kubernetes du pod.
     • Pod_Name : nom du pod GKE.
     • Container_Name : nom du conteneur concerné.
     • Container_Image_Uri : nom de l'image de conteneur en cours de déploiement.
     • VM_Instance_Name : nom du nœud GKE sur lequel le pod a été exécuté.

5. Identifiez d'autres résultats qui se sont produits à peu près au même moment pour ce conteneur. Les résultats associés peuvent indiquer que cette activité était malveillante, plutôt qu'un non-respect des bonnes pratiques.

Étape 2 : Vérifier le cluster et le nœud

1. Dans la console Google Cloud , accédez à la page Clusters Kubernetes.

   Accéder à la page "Clusters Kubernetes"

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Sélectionnez le cluster listé sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat. Notez toutes les métadonnées concernant le cluster et son propriétaire.

4. Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.

5. Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

1. Dans la console Google Cloud , accédez à la page Charges de travail Kubernetes.

   Accéder à la page "Charges de travail Kubernetes"

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Filtrez le cluster listé dans la ligne Nom complet de la ressource de l'onglet Résumé des détails du résultat et l'espace de noms du pod listé dans Pod_Namespace, si nécessaire.

4. Sélectionnez le pod répertorié dans Pod_Name. Notez les métadonnées concernant le pod et son propriétaire.

Étape 4 : Vérifier les journaux

1. Dans la console Google Cloud , accédez à l'explorateur de journaux.

   Accéder à l'explorateur de journaux

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Définissez Sélectionner une période sur la période qui vous intéresse.

4. Sur la page qui s'affiche, procédez comme suit :

   1. Recherchez Pod_Name dans les journaux des pods à l'aide du filtre suivant :
      • resource.type="k8s_container"
      • resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • resource.labels.namespace_name="POD_NAMESPACE"
      • resource.labels.pod_name="POD_NAME"
   2. Recherchez les journaux d'audit du cluster à l'aide du filtre suivant :
      • logName="projects/RESOURCE.PROJECT_DISPLAY_NAME/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • POD_NAME
   3. Recherchez les journaux de la console de nœud GKE à l'aide du filtre suivant :
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

Étape 5 : Examiner le conteneur en cours d'exécution

Si le conteneur est toujours en cours d'exécution, il peut être possible d'analyser directement l'environnement du conteneur.

1. Accédez à la console Google Cloud .

   Ouvrir la console Google Cloud

2. Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.

3. Cliquez sur Activer Cloud Shell.

4. Obtenez les identifiants GKE pour votre cluster en exécutant les commandes suivantes.

   Pour les clusters zonaux :

   gcloud container clusters get-credentials CLUSTER_NAME \
         --zone LOCATION \
         --project PROJECT_NAME
   

   Pour les clusters régionaux :

   gcloud container clusters get-credentials CLUSTER_NAME \
         --region LOCATION \
         --project PROJECT_NAME
   

   Remplacez les éléments suivants :

   • CLUSTER_NAME : cluster répertorié dans resource.labels.cluster_name
   • LOCATION : emplacement répertorié dans resource.labels.location
   • PROJECT_NAME : nom du projet répertorié dans resource.project_display_name

5. Récupérez le binaire exécuté :

   kubectl cp \
         POD_NAMESPACE/POD_NAME:PROCESS_BINARY_FULLPATH \
         -c CONTAINER_NAME \
         LOCAL_FILE
   

   Remplacez local_file par un chemin d'accès au fichier local pour stocker le binaire ajouté.

6. Connectez-vous à l'environnement de conteneur en exécutant la commande suivante :

   kubectl exec \
         --namespace=POD_NAMESPACE \
         -ti POD_NAME \
         -c CONTAINER_NAME \
         -- /bin/sh
   

   Pour ce faire, une interface système est installée sur le conteneur à l'adresse /bin/sh.