Examiner et contrer les menaces

Cet article fournit des conseils informels pour vous aider à examiner et à contrer les menaces, ainsi qu'à utiliser 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 section 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 produit des résultats de sécurité en faisant correspondre les événements de vos flux de journaux Cloud Logging avec des indicateurs de compromission 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 contradictoires connues dans votre flux de journalisation, et en détectant les écarts par rapport au comportement antérieur 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 les résultats à écrire dans Cloud Logging.

Examiner les résultats

Pour examiner les résultats de menaces 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, dossier ou organisation Google Cloud.

    Sélecteur de projet

  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 de la source, seuls les résultats du service sélectionné apparaissent 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 des 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.

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

Désactivation des résultats de menaces

Une fois que vous avez résolu un problème ayant déclenché la détection d'une 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, envisagez de laisser l'état du résultat sur ACTIVE et de l'ignorer.

Pour les faux positifs persistants ou récurrents, créez une règle Ignorer. La définition d'une règle Ignorer peut réduire le nombre de résultats à gérer, ce qui facilite l'identification d'une véritable menace lorsqu'elle se produit.

Pour une menace réelle, avant de définir l'état du résultat sur INACTIVE, éliminez la menace et effectuez 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 ignorer un résultat ou modifier son état, consultez les articles suivants:

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 aux résultats générés par des modules personnalisés pour Event Threat Detection, car votre organisation définit les actions recommandées pour ces détecteurs.

Evasion: Access from Anonymizing Proxy

Les accès anormaux d'un proxy anonyme sont détectés en consultant les journaux Cloud Audit pour examiner les modifications apportées aux services Google Cloud provenant d'adresses IP de proxy anonymes, telles que les adresses IP 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 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ésumé du panneau des 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 apporté 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ésultat.

É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.

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 dans les charges de travail qui utilisent l'indicateur de type "bris de glace" 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, consultez 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.
      • Method name (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 à 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 requête de signature de certificat spécifique.
  3. Recherchez les 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 dans les détails du résultat.

    • PRINCIPAL_EMAIL: valeur que vous avez notée dans le champ Adresse e-mail principale 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 : Defense Evasion: Breakglass Workload Deployment (Evasion de défense : déploiement de charges de travail en mode "bris de glace").
  2. Examinez les résultats associés en cliquant sur le lien sous Résultats associés sur la ligne Résultats associés de l'onglet Résumé 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

L'état Breakglass Workload Deployment Updated est détecté en examinant Cloud Audit Logs pour vérifier si des mises à jour ont été apportées aux charges de travail qui utilisent l'indicateur de type "bris de glace" 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 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, consultez 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.
      • Method name (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 à 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 requête de signature de certificat spécifique.
  3. Recherchez les 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 dans les détails du résultat.

    • PRINCIPAL_EMAIL: valeur que vous avez notée dans le champ Adresse e-mail principale 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 : Defense Evasion: Breakglass Workload Deployment (Evasion de défense : déploiement de charges de travail en mode "bris de glace").
  2. Examinez les résultats associés en cliquant sur le lien sous Résultats associés sur la ligne Résultats associés de l'onglet Résumé 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: 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 pour détecter les modifications apportées aux périmètres VPC Service Controls pouvant entraîner 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 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, consultez les informations des sections suivantes:

    • Ce qui a été 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: modification (REMOVE ou ADD) d'un périmètre qui 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ésumé du panneau des 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 modifications apportées à 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. Examinez les résultats associés en cliquant sur le lien sous Résultats associés sur la ligne Résultats associés de l'onglet Résumé 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 approprié pour ce résultat, mais il peut également avoir un impact 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.

Discovery: Can get sensitive Kubernetes object check

Un acteur potentiellement malveillant a tenté de déterminer les objets sensibles dans GKE sur lesquels il peut interroger, à 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 Summary (Résumé), notez les valeurs des champs suivants:

    • Sous Ce qui a été détecté :
      • Examens d'accès Kubernetes: informations de vérification des accès demandées, en fonction de la ressource k8s SelfSubjectAccessReview.
      • Adresse e-mail principale: compte ayant effectué l'appel.
    • Sous Ressource concernée :
      • Nom à afficher pour la ressource: cluster Kubernetes où 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ésumé du panneau des 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 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 dans les détails du résultat.

    • PRINCIPAL_EMAIL: valeur que vous avez notée dans le champ Adresse e-mail principale des détails du résultat.

É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 : Discovery.
  2. Confirmez le niveau de sensibilité de l'objet interrogé et déterminez s'il existe d'autres signes d'activité malveillante du compte principal dans les journaux.
  3. Si le compte que vous avez noté dans la ligne Adresse e-mail principale des détails du résultat n'est pas un compte de service, contactez son propriétaire pour vérifier si le propriétaire légitime est à l'origine de l'action.

    Si l'adresse e-mail principale 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 développer un plan de réponse, combinez les résultats de votre enquête avec la recherche MITRE.

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 une gravité différente:

  • Sous-règle exfil_to_external_table avec un 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 un 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 Summary (Résumé) du panneau des détails du résultat, examinez les valeurs listées dans les sections suivantes:

    • Ce qui a été détecté :
      • Gravité: niveau de gravité défini sur 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: informations sur les tables à partir desquelles les données ont été exfiltrées.
      • Cibles d'exfiltration: informations sur les tables dans lesquelles les données exfiltrées étaient stockées.
    • Ressource concernée :
      • Nom complet de la ressource: nom complet de la ressource du projet, du dossier ou de l'organisation à partir duquel des 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.
      • Chronicle: lien vers Chronicle.
  3. Cliquez sur l'onglet Source Properties (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 a exfiltré 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 : Examiner dans Chronicle

Vous pouvez utiliser Chronicle pour examiner ce résultat. Chronicle est un service Google Cloud qui vous permet d'examiner les menaces et de parcourir les entités associées selon une chronologie unifiée. Chronicle enrichit les données des résultats, ce qui vous permet d'identifier les indicateurs intéressants et de simplifier les enquêtes.

Vous ne pouvez utiliser Chronicle que si vous activez Security Command Center au niveau de l'organisation.

  1. Accédez à la page Résultats de Security Command Center dans Google Cloud Console.

    Accéder

  2. Dans le panneau Filtres rapides, faites défiler la page vers le bas jusqu'à Nom à afficher de la source.

  3. Dans la section Nom à afficher de la source, sélectionnez Event Threat Detection.

    La table contient les résultats d'Event Threat Detection.

  4. Dans le tableau, sous catégorie, cliquez sur un résultat Exfiltration: BigQuery Data Exfiltration. Le panneau de détails du résultat s'ouvre.

  5. Dans la section Liens associés du panneau des détails du résultat, cliquez sur Enquêter dans Chronicle.

  6. Suivez les instructions de l'interface utilisateur guidée de Chronicle.

Utilisez les guides suivants pour mener des enquêtes dans Chronicle :

Étape 3 : 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 fichier JSON du résultat.

  3. Sur la page qui s'affiche, saisissez l'adresse e-mail indiquée dans Adresse e-mail principale dans la zone Filtre, puis vérifiez les autorisations attribuées au compte.

Étape 4 : Vérifier les journaux

  1. Dans l'onglet Résumé du panneau des 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 tâches BigQuery à l'aide des filtres suivants:

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

Étape 5 : É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 : 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 sous Résultats associés sur la ligne Résultats associés de l'onglet Résumé 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 6 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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.

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 du projet, 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 de détails du résultat s'ouvre dans l'onglet Summary (Résumé).
  2. Dans l'onglet Summary (Résumé) du panneau des détails du résultat, examinez les valeurs listées dans les sections suivantes:

    • Ce qui a été détecté :
      • Adresse e-mail principale: compte utilisé pour exfiltrer les données.
      • Sources d'exfiltration: informations sur les tables à partir desquelles les données ont été exfiltrées.
      • Cibles d'exfiltration: informations sur les tables dans lesquelles les données exfiltrées étaient 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 fichier JSON du résultat (à l'étape 1).

  3. Sur la page qui s'affiche, dans la zone Filtrer, saisissez l'adresse e-mail indiquée dans le champ Adresse e-mail principale (de l'étape 1) et vérifiez les autorisations attribuées au compte.

Étape 3 : Vérifier les journaux

  1. Dans l'onglet Résumé du panneau des 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. Examinez les résultats associés en cliquant sur le lien sur la ligne Résultats associés de l'onglet Résumé dans les 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 approprié pour ce résultat, mais il peut également avoir un impact 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.

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 des détails du résultat, consultez 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: informations relatives à la table BigQuery à partir de laquelle les données ont été exfiltrées.
      • Cibles d'exfiltration: informations 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 plus d'informations, 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 fichier JSON du résultat (à l'étape 1).

  3. Sur la page qui s'affiche, dans la zone Filtrer, saisissez l'adresse e-mail indiquée dans access.principalEmail (de l'étape 1) et vérifiez les autorisations attribuées au compte.

Étape 3 : Vérifier les journaux

  1. Dans l'onglet Résumé du panneau des 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. Examinez les résultats associés en cliquant sur le lien sous Résultats associés sur la ligne Résultats associés de l'onglet Résumé 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 approprié pour ce résultat, mais il peut également avoir un impact 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.

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 du projet, 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 de détails du résultat s'ouvre dans l'onglet Summary (Résumé).
  2. Dans l'onglet Récapitulatif, consultez 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: informations relatives à l'instance Cloud SQL dont les données ont été exfiltrées.
      • Cibles d'exfiltration: informations 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 fichier JSON du résultat, notez les champs suivants:

    • sourceProperties:
      • evidence:
      • sourceLogId:
        • projectId: projet Google Cloud qui contient 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, telles que 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 indiquée dans le champ projectId du résultat JSON (à l'étape 1).

  3. Sur la page qui s'affiche, dans la zone Filtrer, saisissez l'adresse e-mail indiquée sur la ligne Adresse e-mail principale de l'onglet Résumé des détails du résultat (é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 de l'URI Cloud Logging (à l'étape 1). La page Explorateur de journaux inclut tous les journaux associé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. Les résultats associés ont le même type de résultat 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 approprié pour ce résultat, mais il peut également avoir un impact 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.

Exfiltration: Cloud SQL Restore Backup to External Organization

L'exfiltration de données à partir d'une sauvegarde Cloud SQL est détectée en examinant les journaux d'audit afin de 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 compatibles.

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ésumé du panneau des détails du résultat, consultez 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 de l'instance Cloud SQL à partir de laquelle la sauvegarde a été créée.
      • Cibles d'exfiltration: détails de l'instance Cloud SQL sur 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 la ressource de la sauvegarde qui a été 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é dans le champ projectId du fichier JSON du résultat (à l'étape 1).

  3. Sur la page qui s'affiche, dans la zone Filtrer, saisissez l'adresse e-mail indiquée dans le champ Adresse e-mail principale (de l'étape 1) et 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 de l'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 sur la ligne Résultats associés. (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 approprié pour ce résultat, mais il peut également avoir un impact 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 indiqué sur la ligne Adresse e-mail du compte principal dans l'onglet Résumé des détails du résultat jusqu'à ce que l'investigation soit terminée.
  • Pour mettre fin à toute exfiltration, ajoutez des stratégies IAM restrictives sur les instances Cloud SQL concernées.
  • 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.

Exfiltration: Cloud SQL Over-Privileged Grant

Détecte les cas où tous les droits sur une base de données PostgreSQL (ou sur l'ensemble des 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 la section Examiner les résultats.
  2. Dans l'onglet Résumé du panneau des détails du résultat, consultez les informations des sections suivantes:

    • Ce qui a été détecté, en particulier les champs suivants :
      • Database display name (Nom à afficher de la base de données) : nom de la base de données de l'instance PostgreSQL Cloud SQL affectée.
      • Database user name (Nom d'utilisateur de la base de données) : utilisateur PostgreSQL ayant accordé les droits en excès.
      • Requête de base de données: requête PostgreSQL exécutée ayant accordé les droits.
      • Bénéficiaires de la base de données: bénéficiaires des privilèges trop larges.
    • Ressource concernée, en particulier les champs suivants :
      • Nom complet de la ressource: nom de la ressource de l'instance PostgreSQL Cloud SQL affectée.
      • Nom complet du parent: nom de ressource de l'instance PostgreSQL Cloud SQL.
      • Nom complet du projet: le projet Google Cloud contenant l'instance PostgreSQL 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 fichier 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 (à l'étape 1).
    • Fonctions ou procédures. Exécutez la métacommande \df et vérifiez les droits attribués pour les fonctions ou les procédures dans la base de données répertoriée dans Nom à afficher de la base de données (à l'é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 de l'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, consultez les journaux PostgreSQL pgaudit, 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 approprié pour ce résultat, mais il peut également avoir un impact 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 des bénéficiaires répertoriés dans Bénéfices de la base de données jusqu'à la fin de l'enquête.
  • Pour limiter l'accès à la base de données (dans le nom à afficher pour la base de données de l'étape 1, revoke les autorisations inutiles des bénéficiaires (à partir de bénéficiaires de base de données de l'étape 1).

Initial Access: Database Superuser Writes to User Tables

Détecte quand le compte super-utilisateur de la base de données Cloud SQL (postgres pour PostgreSQL et root pour MySQL) écrit dans des tables utilisateur Le super-utilisateur (un rôle avec un accès très large) ne doit généralement pas être utilisé pour écrire dans des tables utilisateur. Un compte utilisateur avec un accès plus limité doit être utilisé pour l'activité quotidienne normale. Lorsqu'un super-utilisateur écrit dans une table des utilisateurs, cela peut indiquer qu'un pirate informatique a élevé les privilèges, ou a compromis l'utilisateur de la base de données par défaut et qu'il modifie des données. Cela pourrait également indiquer des pratiques normales, mais non sûres.

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 des détails du résultat, consultez les informations des sections suivantes:

    • Ce qui a été détecté, en particulier les champs suivants :
      • Database display name (Nom à afficher de la base de données) : nom de la base de données de l'instance PostgreSQL ou MySQL Cloud SQL affectée.
      • Database user name (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 la ressource de l'instance Cloud SQL affectée.
      • Parent full name (Nom complet du parent) : nom de ressource de l'instance Cloud SQL.
      • Nom complet du projet: le 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 fichier 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 (étape 1). La page Explorateur de journaux inclut tous les journaux liés à l'instance Cloud SQL concernée.
  2. Vérifiez les journaux PostgreSQL pgaudit ou les journaux d'audit Cloud SQL pour MySQL, qui contiennent les requêtes exécutées par le super-utilisateur, à 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 approprié pour ce résultat, mais il peut également avoir un impact 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.

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 des accès basée sur les rôles (RBAC) dans votre cluster a autorisé cet utilisateur à 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 de journal correspondant à ce résultat.

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

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ée sur les rôles (RBAC) dans votre cluster a autorisé cet utilisateur à 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 de journal correspondant à ce résultat.

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

Initial Access: Dormant Service Account Action

Détecte les événements pour lesquels un compte de service géré par l'utilisateur inactif a déclenché une action. Dans ce contexte, un compte de service est considéré comme inactif 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 la section Examiner les résultats.
  2. Dans les détails du résultat, dans l'onglet Summary (Résumé), notez les valeurs des champs suivants.

    Sous Ce qui a été 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 du compte de service, tels que l'Analyseur d'activité, pour examiner l'activité du compte de service inactif.
  2. Contactez le propriétaire du compte de service dans le champ Adresse e-mail principale. vérifier si le propriétaire légitime est à l'origine de l'action ;

Étape 3: Implémentez votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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.
  • Pensez à supprimer le compte de service potentiellement compromis, et à alterner et supprimer toutes les clés d'accès du compte de service pour le projet potentiellement compromis. Après la 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 leurs propriétaires afin d'assurer la continuité des activités.
  • 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 Key Created

Détecte les événements pour lesquels une clé de compte de service géré par l'utilisateur inactive est créée. Dans ce contexte, un compte de service est considéré comme inactif 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 la section Examiner les résultats.
  2. Dans les détails du résultat, dans l'onglet Summary (Résumé), notez les valeurs des champs suivants.

    Sous Ce qui a été détecté:

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

    Sous Ressource concernée:

    • Nom à afficher pour la ressource: nouvelle clé du compte de service dormant
    • Nom complet du projet: projet contenant ce compte de service inactif

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

  1. Utilisez les outils du compte de service, tels que l'Analyseur d'activité, pour examiner l'activité du compte de service inactif.
  2. Contactez le propriétaire du champ Adresse e-mail principale. vérifier si le propriétaire légitime est à l'origine de l'action ;

Étape 3: Implémentez votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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.
  • S'il a été piraté, supprimez l'accès du propriétaire de l'adresse e-mail principale.
  • Invalidez la clé de compte de service que vous venez de créer sur la page Comptes de service.
  • Pensez à supprimer le compte de service potentiellement compromis, et à alterner et supprimer toutes les clés d'accès du compte de service pour le projet potentiellement compromis. Après la 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 leurs propriétaires afin d'assurer la continuité des activités.
  • 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 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: 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 publiée sur l'Internet public. Par exemple, les clés de compte de service sont souvent publiées par erreur sur 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 la section Examiner les résultats.
  2. Dans les détails du résultat, dans l'onglet Summary (Résumé), notez les valeurs des champs suivants.

    Sous Ce qui a été 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é
    • Method name (Nom de la méthode) : nom de la méthode de l'action
    • Nom de la clé du compte de service: la clé du compte de service divulguée utilisée pour authentifier cette action
    • Description: la description de ce qui a été détecté, y compris l'emplacement sur l'Internet public où se trouve la clé du compte de service

    Sous Ressource concernée:

    • Nom à afficher pour la ressource: la ressource impliquée dans 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 en utilisant le 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 principale 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 dans les détails du résultat.

Étape 3: Implémentez votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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é de compte de service sur la page Comptes de service.
  • Supprimez la page Web ou le dépôt GitHub où la clé du compte de service est publiée.
  • Envisagez de supprimer le compte de service compromis.
  • Alternez et supprimez toutes les clés d'accès du compte de service pour le projet potentiellement compromis. Après la suppression, les applications qui utilisent le compte de service pour l'authentification perdent l'accès. Avant de procéder à la suppression, votre équipe de sécurité doit identifier toutes les applications concernées et collaborer avec leurs propriétaires afin d'assurer la continuité des activités.
  • 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 Cloud Customer Care.

Initial Access: Excessive Permission Denied Actions

Détecte les événements où un compte principal déclenche à plusieurs reprises des erreurs d'autorisation refusée sur 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 la section Examiner les résultats.
  2. Dans les détails du résultat, dans l'onglet Summary (Résumé), notez les valeurs des champs suivants.

    Sous Ce qui a été détecté:

    • Adresse e-mail du compte principal: compte principal ayant déclenché plusieurs erreurs d'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 Source Properties (Propriétés sources), notez les valeurs des champs suivants dans le fichier JSON:

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

É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 en utilisant le 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 principale 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 approprié pour ce résultat, mais il peut également avoir un impact 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 est à l'origine de l'action.
  • supprimer 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 que vous ne connaissez pas.
  • Contactez le propriétaire du projet disposant du compte, et supprimez ou désactivez éventuellement le compte.

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 des détails du résultat, consultez 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 utilisé pour la connexion.
    • 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.
      • Chronicle: lien vers Chronicle.
  3. Cliquez sur l'onglet JSON.

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

    • sourceProperties:
      • evidence:
        • sourceLogId: ID du 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 : Examiner dans Chronicle

Vous pouvez utiliser Chronicle pour examiner ce résultat. Chronicle est un service Google Cloud qui vous permet d'examiner les menaces et de parcourir les entités associées selon une chronologie simple à utiliser. Chronicle enrichit les données des résultats, ce qui vous permet d'identifier les indicateurs intéressants et de simplifier les enquêtes.

Vous ne pouvez utiliser Chronicle que si vous activez Security Command Center au niveau de l'organisation.

  1. Accédez à la page Résultats de Security Command Center dans Google Cloud Console.

    Accéder

  2. Dans le panneau Filtres rapides, faites défiler la page vers le bas jusqu'à Nom à afficher de la source.

  3. Dans la section Nom à afficher de la source, sélectionnez Event Threat Detection.

    La table présente les résultats correspondant au type de source que vous avez sélectionné.

  4. Dans le tableau, sous catégorie, cliquez sur un résultat Brute Force: SSH. Le panneau d'informations du résultat s'ouvre.

  5. Dans la section Liens associés du panneau des détails du résultat, cliquez sur Enquêter dans Chronicle.

  6. Suivez les instructions de l'interface utilisateur guidée de Chronicle.

Utilisez les guides suivants pour mener des enquêtes dans Chronicle :

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

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

    Accéder au tableau de bord

  2. Cliquez sur la liste déroulante Sélectionner située en haut de la page. Dans la fenêtre Sélectionner qui vous est présentée, sélectionnez le projet répertorié 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 4 : 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 indiquée sur la ligne Adresse e-mail principale de l'onglet Résumé des détails du résultat en utilisant le filtre suivant :
    • logName="projects/projectId/logs/syslog"
    • labels."compute.googleapis.com/resource_name"="vmName"

Étape 5 : É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 : Comptes valides : comptes locaux.
  2. Examinez les résultats associés en cliquant sur le lien sous Résultats associés sur la ligne Résultats associés de l'onglet Résumé dans les 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 6 : Mettre en œuvre votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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: 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 Credential Access: External Member Added To Privileged Group comme indiqué dans la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Adresse e-mail principale: compte ayant apporté 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 des 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  Supprimer le membre ou  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ésumé du panneau des 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.

    Sélecteur de 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.

Credential Access: 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 Credential Access: Privileged Group Opened To Public comme indiqué dans la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Adresse e-mail principale: compte ayant apporté les modifications, qui ont peut-être été piratés.
    • 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ésumé du panneau des 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.

    Sélecteur de 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.

Credential Access: Secrets Accessed in Kubernetes Namespace

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

Credential Access: 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 Credential Access: Sensitive Role Granted To Hybrid Group comme indiqué dans la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Adresse e-mail principale: compte ayant apporté les modifications, qui ont peut-être été piratés.
    • Ressource concernée, en particulier les champs suivants :
      • Nom complet de la ressource: ressource à 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 nouvellement attribués à ce 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 nouvellement 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ésumé du panneau des 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.

    Sélecteur de 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.

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 de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Adresse IP source: l'adresse IP suspectée de minage de cryptomonnaies.
      • Port source: port source de la connexion, le cas échéant.
      • Adresse IP de destination: l'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 de journalisation: 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 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 apparaissent comme illustré dans l'exemple suivant:

      /projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME
  5. Pour afficher le fichier 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. Cliquez sur la liste déroulante Sélectionner située en haut de la page. Dans la fenêtre Sélectionner qui vous est présentée, sélectionnez le projet répertorié 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 approprié pour ce résultat, mais il peut également avoir un impact 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.

Initial Access: Log4j Compromise Attempt

Ce résultat est généré lorsque des lookups 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 du résultat. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

  2. Dans l'onglet Récapitulatif, consultez 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 qui a reçu la recherche JNDI
      • requestUrl : URL de la requête HTTP. S'il 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. S'il 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. Examinez les résultats associés en cliquant sur le lien sous Résultats associés sur la ligne Résultats associés de l'onglet Résumé des détails du résultat. Les résultats associés sont du même type de résultat, ainsi que la même instance et 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 approprié pour ce résultat, mais il peut également avoir un impact 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.

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 de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté
    • Ressource concernée, en particulier le champ suivant :
    • 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 sur 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. Examinez les résultats associés en cliquant sur le lien sous Résultats associés sur la ligne Résultats associés de l'onglet Résumé 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 approprié pour ce résultat, mais il peut également avoir un impact 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.

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 de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

  2. Dans l'onglet Récapitulatif, consultez 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 fichier 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 approprié pour ce résultat, mais il peut également avoir un impact 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 l'adresse 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 logiciel malveillant détecté. Les étapes suivantes utilisent le résultat Malware: Bad IP, comme indiqué dans la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Domaine d'indicateur: pour les résultats Bad domain, domaine qui a déclenché le résultat.
      • Indicator IP (Adresse IP de l'indicateur) : pour les résultats Bad IP, l'adresse IP qui a déclenché le résultat.
      • Adresse IP source: pour les résultats Bad IP, une adresse IP de commande et de contrôle de logiciel malveillant connue.
      • Port source: pour les résultats Bad IP, port source de la connexion.
      • Adresse IP de destination: pour les résultats Bad IP, l'adresse IP cible du logiciel malveillant.
      • Port de destination: pour les résultats Bad IP, port de destination de la connexion.
      • Protocol (Protocole) : pour les résultats Bad IP, le 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.
      • Chronicle: lien vers Chronicle.
      • Indicateur VirusTotal: lien vers la page d'analyse VirusTotal.
    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 : Examiner dans Chronicle

Vous pouvez utiliser Chronicle pour examiner ce résultat. Chronicle est un service Google Cloud qui vous permet d'examiner les menaces et de parcourir les entités associées selon une chronologie simple à utiliser. Chronicle enrichit les données des résultats, ce qui vous permet d'identifier les indicateurs intéressants et de simplifier les enquêtes.

Vous ne pouvez utiliser Chronicle que si vous activez Security Command Center au niveau de l'organisation.

  1. Accédez à la page Résultats de Security Command Center dans Google Cloud Console.

    Accéder

  2. Dans le panneau Filtres rapides, faites défiler la page vers le bas jusqu'à Nom à afficher de la source.

  3. Dans la section Nom à afficher de la source, sélectionnez Event Threat Detection.

    La table présente les résultats correspondant au type de source que vous avez sélectionné.

  4. Dans le tableau, sous Catégorie, cliquez sur le résultat Malware: Bad IP. Le panneau d'informations du résultat s'ouvre.

  5. Dans la section Liens associés du panneau des détails du résultat, cliquez sur Enquêter dans Chronicle.

  6. Suivez les instructions de l'interface utilisateur guidée de Chronicle.

Utilisez les guides suivants pour mener des enquêtes dans Chronicle :

Étape 3 : 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. Cliquez sur la liste déroulante de sélection du projet située en haut de la page. Dans la fenêtre Sélectionner à partir de qui s'affiche, dans le champ Rechercher des projets et des dossiers, saisissez le numéro de projet indiqué sur 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 correspondant au nom et à la zone indiqués 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 4 : Vérifier les journaux

  1. Dans l'onglet Résumé du panneau des 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 en utilisant le 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 avec sélectionnez le projet répertorié 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 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. Examinez les résultats associés en cliquant sur le lien sous Résultats associés sur la ligne Résultats associés de l'onglet Résumé 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. Consultez les URL et les domaines signalés 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.
  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 approprié pour ce résultat, mais il peut également avoir un impact 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: Outgoing DoS

Event Threat Detection détecte l'utilisation potentielle d'une instance pour lancer une attaque par déni de service (DoS) en analysant les journaux de flux VPC. 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: Outgoing DoS comme indiqué dans la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Éléments détectés
      • Adresse IP source: adresse IP source de l'activité DoS.
      • Port source: port source de la connexion.
      • Adresse IP de destination: adresse IP cible de l'activité DoS.
      • Port de destination: port de destination de la connexion.
    • 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. Dans la vue détaillée du résultat, cliquez sur l'onglet JSON.
    2. Dans le fichier JSON, notez les champs suivants.
    • sourceInstanceDetails : instance de VM Compute Engine concernée.

É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. Cliquez sur la liste déroulante Sélectionner située en haut de la page. Dans la fenêtre Sélectionner dans qui apparaît, sélectionnez l'ID du projet répertorié dans sourceInstanceDetails.

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

  4. Cliquez sur l'instance de VM correspondant au nom et à la zone de l'instance dans sourceInstanceDetails. Examinez les détails de l'instance, y compris les paramètres de 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ésumé du panneau des 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 srcIP à l'aide du filtre suivant:

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

      Remplacez les éléments suivants :

      • PROJECT_ID par l'ID du projet dans lequel le problème a été détecté.
      • SOURCE_IP par l'adresse IP répertoriée dans le champ srcIP du résultat JSON.
      • DESTINATION_IP par l'adresse IP répertoriée dans le champ destIp du résultat JSON.

É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éni de service réseau.
  2. Examinez les résultats associés en cliquant sur le lien sous Résultats associés sur la ligne Résultats associés de l'onglet Résumé 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 approprié pour ce résultat, mais il peut également avoir un impact 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 qui rencontre du trafic DoS sortant.
  • 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.

Persistence: IAM Anomalous Grant

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

Voici des exemples de subventions 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.
  • Un compte de service ajouté depuis l'extérieur de votre organisation ou de votre projet

Le résultat IAM Anomalous Grant est unique en ce sens qu'il inclut des sous-règles qui fournissent des informations plus spécifiques sur chaque instance de ce résultat. La classification du 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 hautement sensible a été attribué ou si un rôle de sensibilité moyenne a été attribué au niveau de l'organisation. Pour en savoir plus, consultez la section Rôles très sensibles.
    • MEDIUM, si un rôle à sensibilité moyenne a été attribué. Pour en savoir plus, consultez la section Rôles de sensibilité moyenne.
  • external_member_invited_to_policy : HIGH
  • external_member_added_to_policy:
    • HIGH, si un rôle hautement sensible a été attribué ou si un rôle de sensibilité moyenne a été attribué au niveau de l'organisation. Pour en savoir plus, consultez la section Rôles très sensibles.
    • MEDIUM, si un rôle à sensibilité moyenne a été attribué. Pour en savoir plus, consultez la section 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 de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Adresse e-mail principale: adresse e-mail de l'utilisateur ou du compte de service ayant 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.
      • Chronicle: lien vers Chronicle.
  3. Cliquez sur l'onglet JSON. Le fichier JSON complet du résultat s'affiche.

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

    • detectionCategory:
      • subRuleName: informations plus spécifiques sur le type d'autorisation inhabituelle qui a eu lieu. La sous-règle détermine la classification du niveau de gravité de ce résultat.
    • evidence:
      • sourceLogId:
      • projectId: ID du projet contenant le résultat.
    • properties:
      • sensitiveRoleGrant:
        • bindingDeltas:
        • Action: action effectuée par l'utilisateur.
        • Role: rôle attribué à l'utilisateur.
        • member: adresse e-mail de l'utilisateur ayant reçu le rôle.

Étape 2 : Examiner dans Chronicle

Vous pouvez utiliser Chronicle pour examiner ce résultat. Chronicle est un service Google Cloud qui vous permet d'examiner les menaces et de parcourir les entités associées selon une chronologie simple à utiliser. Chronicle enrichit les données des résultats, ce qui vous permet d'identifier les indicateurs intéressants et de simplifier les enquêtes.

Vous ne pouvez pas examiner les résultats de Security Command Center dans Chronicle si vous activez Security Command Center au niveau du projet.

  1. Accédez à la page Résultats de Security Command Center dans Google Cloud Console.

    Accéder

  2. Dans le panneau Filtres rapides, faites défiler la page vers le bas jusqu'à Nom à afficher de la source.

  3. Dans la section Nom à afficher de la source, sélectionnez Event Threat Detection.

    La table présente les résultats correspondant au type de source que vous avez sélectionné.

  4. Dans le tableau, sous catégorie, cliquez sur un résultat Persistence: IAM Anomalous Grant. Le panneau de détails du résultat s'ouvre.

  5. Dans la section Liens associés du panneau des détails du résultat, cliquez sur Enquêter dans Chronicle.

  6. Suivez les instructions de l'interface utilisateur guidée de Chronicle.

Utilisez les guides suivants pour mener des enquêtes dans Chronicle :

Étape 3 : Vérifier les journaux

  1. Dans l'onglet Résumé du panneau des 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 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 : Valid Accounts: Cloud Accounts (Comptes valides : comptes Cloud).
  2. Examinez les résultats associés en cliquant sur le lien sur la ligne Résultats associés de l'onglet Résumé dans les détails du résultat. Les résultats associés sont du même type de résultat, ainsi que la même instance et le même réseau.
  3. 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 approprié pour ce résultat, mais il peut également avoir un impact 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: Impersonation Role Granted for Dormant Service Account

Détecte les événements pour lesquels un rôle d'emprunt d'identité est attribué à un compte principal 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 inactif est la ressource concernée. Un compte de service est considéré comme inactif 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 Persistence: Impersonation Role Granted for Dormant Service Account, comme indiqué dans la section Examiner les résultats.
  2. Dans les détails du résultat, dans l'onglet Summary (Résumé), notez les valeurs des champs suivants.

    Sous Ce qui a été détecté:

    • Adresse e-mail principale: utilisateur ayant effectué l'action d'attribution
    • Autorisations d'accès mises en cause.Nom principal: compte principal auquel le rôle d'emprunt d'identité a été attribué

    Sous Ressource concernée:

    • Nom à afficher pour la ressource: compte de service inactif en tant que ressource
    • Nom complet du projet: projet contenant ce compte de service inactif

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

  1. Utilisez les outils du compte de service, tels que l'Analyseur d'activité, pour examiner l'activité du compte de service inactif.
  2. Contactez le propriétaire du champ Adresse e-mail principale. vérifier si le propriétaire légitime est à l'origine de l'action ;

Étape 3 : Vérifier les journaux

  1. Dans l'onglet Résumé du panneau des détails du 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 approprié pour ce résultat, mais il peut également avoir un impact 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.
  • S'il a été piraté, supprimez l'accès du propriétaire de l'adresse e-mail principale.
  • Supprimez le rôle d'emprunt d'identité nouvellement attribué au membre cible.
  • Pensez à supprimer le compte de service potentiellement compromis, et à alterner et supprimer toutes les clés d'accès du compte de service pour le projet potentiellement compromis. Après la 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 leurs propriétaires afin d'assurer la continuité des activités.
  • 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 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.

Persistence: Unmanaged Account Granted Sensitive Role

Détecte les événements pour lesquels un rôle sensible est attribué à 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 quitte 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 la section Examiner les résultats.
  2. Dans les détails du résultat, dans l'onglet Summary (Résumé), notez les valeurs des champs suivants.

    Sous Ce qui a été détecté:

    • Adresse e-mail principale: utilisateur ayant effectué l'action d'attribution
    • Autorisations d'accès mises en cause.Nom principal: compte non géré qui reçoit l'autorisation
    • Accords d'accès offensants.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 principale. vérifier si le propriétaire légitime est à l'origine de l'action ;
  2. Vérifiez auprès du propriétaire du champ Offending access grants.Principal name (Nom principal de l'accès mis en cause) pour connaître l'origine du compte non géré.

Étape 3 : Vérifier les journaux

  1. Dans l'onglet Résumé du panneau des détails du 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 approprié pour ce résultat, mais il peut également avoir un impact 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.
  • S'il a été piraté, supprimez l'accès du propriétaire de l'adresse e-mail principale.
  • Supprimez le rôle sensible nouvellement attribué du compte non géré.
  • Envisagez de convertir le compte non géré en compte géré à l'aide de l'outil de transfert, puis déplacez ce compte sous le contrôle des administrateurs système.

Persistence: New API Method

Une activité d'administration anormale a été détectée par un acteur potentiellement malveillant dans une organisation, un dossier ou un projet. 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 Summary (Résumé), notez les valeurs des champs suivants:

    • Sous Ce qui a été détecté :
      • Adresse e-mail principale: compte ayant effectué 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 :
      • Resource display name (Nom à afficher de la ressource) : le nom de la ressource concernée, qui peut être identique au nom de l'organisation, du dossier ou du projet.
      • Chemin d'accès à la ressource: emplacement dans la hiérarchie des ressources où l'activité s'est produite

É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. Vérifiez si l'action était justifiée dans l'organisation, le dossier ou le projet, et si elle a été prise par le propriétaire légitime du compte. L'organisation, le dossier ou le projet s'affiche sur la ligne Chemin de la ressource et le compte sur la ligne Adresse e-mail du compte principal.
  3. Pour élaborer un plan d'intervention, combinez les résultats de vos recherches avec les travaux de recherche du 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 tôt sur cette page. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

  • Ce qui a été détecté, en particulier les champs suivants :
    • Adresse e-mail principale: compte utilisateur potentiellement piraté.
  • Ressource concernée, en particulier les champs suivants :
    • Nom complet du projet: nom du 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 ressources Google 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 fichier JSON du résultat.

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

Étape 3 : Vérifier les journaux

  1. Dans l'onglet Résumé du panneau des 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 : Valid Accounts: Cloud Accounts (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 approprié pour ce résultat, mais il peut également avoir un impact 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 tôt sur cette page. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Adresse e-mail principale: compte de service potentiellement piraté.
    • Ressource concernée, en particulier les champs suivants :
      • Nom complet du projet: nom du 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: user-agent 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 Filtrer, saisissez le nom du compte figurant sur la ligne Adresse e-mail principale de l'onglet Résumé des détails du résultat, puis vérifiez les rôles attribués.

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

    Accéder à la page "Comptes de service"

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

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

Étape 3 : Vérifier les journaux

  1. Dans l'onglet Résumé du panneau des 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 approprié pour ce résultat, mais il peut également avoir un impact 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.

Privilege Escalation: Changes to sensitive Kubernetes RBAC objects

Pour élever des privilèges, un acteur potentiellement malveillant a tenté de modifier un objet de contrôle des accès basé sur les rôles (RBAC) ClusterRole ou ClusterRoleBinding du rôle cluster-admin sensible à 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 Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Adresse e-mail principale: compte ayant effectué l'appel.
      • Method name (Nom de la méthode) : méthode appelée.
      • Liaisons Kubernetes: liaison Kubernetes sensible ou ClusterRoleBinding modifiée.
    • Ressource concernée, en particulier les champs suivants :
      • Nom à afficher pour la ressource: cluster Kubernetes où 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 sur la ligne Liaisons Kubernetes. Les détails de la liaison s'affichent.

  4. Dans la liaison affichée, notez ses détails.

É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 à 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, consultez 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. Les modifications ne sont donc pas aussi claires.

  3. Recherchez les 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 dans les détails du résultat.

    • PRINCIPAL_EMAIL: valeur que vous avez notée dans le champ Adresse e-mail principale des détails du résultat.

É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 vérifier si celui-ci a besoin du rôle auquel il est lié.
  4. Déterminez s'il existe d'autres signes d'activité malveillante du compte principal dans les journaux.
  5. Si l'adresse e-mail principale n'est pas un compte de service, contactez le propriétaire du compte pour vérifier si le propriétaire légitime a effectué l'action.

    Si l'adresse e-mail principale est un compte de service (IAM ou Kubernetes), identifiez la source de la modification pour déterminer sa légitimité.

  6. Pour développer un plan de réponse, combinez les résultats de votre enquête avec la recherche MITRE.

Privilege Escalation: Create Kubernetes CSR for master cert

Pour élever des privilèges, un acteur potentiellement malveillant a créé une demande de signature de certificat (CSR) Kubernetes principale, ce qui lui donne un 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 Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Adresse e-mail principale: compte ayant effectué l'appel.
      • Method name (Nom de la méthode) : méthode appelée.
    • Ressource concernée, en particulier les champs suivants :
      • Nom à afficher pour la ressource: cluster Kubernetes où 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 à 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 requête de signature de certificat spécifique.
  3. Recherchez les 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 dans les détails du résultat.

    • PRINCIPAL_EMAIL: valeur que vous avez notée dans le champ Adresse e-mail principale des détails du résultat.

É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 principale n'est pas un compte de service, contactez le propriétaire du compte pour vérifier si le propriétaire légitime a effectué l'action.

    Si l'adresse e-mail principale est un compte de service (IAM ou Kubernetes), identifiez la source de l'action pour déterminer sa légitimité.

  4. Pour développer un plan de réponse, combinez les résultats de votre enquête avec la recherche MITRE.

Privilege Escalation: Creation of sensitive Kubernetes bindings

Pour élever des privilèges, un acteur 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 Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Adresse e-mail principale: compte ayant effectué l'appel.
      • Liaisons Kubernetes: liaison Kubernetes ou ClusterRoleBinding sensible qui a été créée.
    • Ressource concernée, en particulier les champs suivants :
      • Nom à afficher pour la ressource: cluster Kubernetes où 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 à Explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.
  2. Recherchez les 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 dans les détails du résultat.

    • PRINCIPAL_EMAIL: valeur que vous avez notée dans le champ Adresse e-mail principale des détails du résultat.

É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. Confirmez la 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 vérifier si celui-ci a besoin du rôle auquel il est lié.
  4. Déterminez s'il existe d'autres signes d'activité malveillante du compte principal dans les journaux.
  5. Si l'adresse e-mail principale n'est pas un compte de service, contactez le propriétaire du compte pour vérifier si le propriétaire légitime a effectué l'action.

    Si l'adresse e-mail principale est un compte de service (IAM ou Kubernetes), identifiez la source de l'action pour déterminer sa légitimité.

  6. Pour développer un plan de réponse, combinez les résultats de votre enquête avec la recherche MITRE.

Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials

Pour élever des privilèges, un acteur potentiellement malveillant a interrogé une demande de signature de certificat (CSR) à l'aide de la commande kubectl, à l'aide d'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 Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Adresse e-mail principale: compte ayant effectué l'appel.
      • Method name (Nom de la méthode) : méthode appelée.
    • Sous Ressource concernée :
      • Nom à afficher pour la ressource: cluster Kubernetes où 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 noté dans le champ Nom de la méthode des détails du résultat, 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 à 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 requête 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 requête de signature de certificat spécifique est disponible dans l'entrée de journal, examinez le niveau de sensibilité du certificat et déterminez si l'action était justifiée.
  3. Pour développer un plan de réponse, combinez les résultats de votre enquête avec la recherche MITRE.

Privilege Escalation: Launch of privileged Kubernetes container

Un acteur potentiellement malveillant a créé un pod contenant des conteneurs privilégiés ou des conteneurs dotés de fonctionnalités d'élévation des privilèges.

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 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 Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Adresse e-mail principale: compte ayant effectué l'appel.
      • Pods Kubernetes: le pod nouvellement créé contenant des conteneurs privilégiés.
    • Ressource concernée, en particulier les champs suivants :
      • Nom à afficher pour la ressource: cluster Kubernetes où 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é activé 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 à Explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.
  2. Recherchez les 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 dans les détails du résultat.

    • PRINCIPAL_EMAIL: valeur que vous avez notée dans le champ Adresse e-mail principale des détails du résultat.

É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 noyau.
  3. Déterminez s'il existe d'autres signes d'activité malveillante du compte principal dans les journaux.
  4. Si l'adresse e-mail principale n'est pas un compte de service, contactez le propriétaire du compte pour vérifier si le propriétaire légitime a effectué l'action.

    Si l'adresse e-mail principale est un compte de service (IAM ou Kubernetes), identifiez la source de l'action pour déterminer sa légitimité.

  5. Pour développer un plan de réponse, combinez les résultats de votre enquête avec la recherche MITRE.

Privilege Escalation: Dormant Service Account Granted Sensitive Role

Détecte les événements pour lesquels 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 inactif 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 la section Examiner les résultats.
  2. Dans les détails du résultat, dans l'onglet Summary (Résumé), notez les valeurs des champs suivants.

    Sous Ce qui a été détecté:

    • Adresse e-mail principale: utilisateur ayant effectué l'action d'attribution
    • Autorisations d'accès mises en cause.Nom principal: compte de service inactif ayant reçu le rôle sensible
    • Accords d'accès offensants.Rôle accordé: rôle IAM sensible attribué

    Sous Ressource concernée:

    • Nom à afficher de la ressource: organisation, dossier ou projet dans lesquels le rôle IAM sensible a été attribué au compte de service inactif.

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

  1. Utilisez les outils du compte de service, tels que l'Analyseur d'activité, pour examiner l'activité du compte de service inactif.
  2. Contactez le propriétaire du champ Adresse e-mail principale. vérifier si le propriétaire légitime est à l'origine de l'action ;

Étape 3 : Vérifier les journaux

  1. Dans l'onglet Résumé du panneau des détails du 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 approprié pour ce résultat, mais il peut également avoir un impact 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.
  • S'il a été piraté, supprimez l'accès du propriétaire de l'adresse e-mail principale.
  • Supprimez le rôle IAM sensible nouvellement attribué du compte de service inactif.
  • Pensez à supprimer le compte de service potentiellement compromis, et à alterner et supprimer toutes les clés d'accès du compte de service pour le projet potentiellement compromis. Après la suppression, les ressources qui utilisent le compte de service pour l'authentification perdent leur accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources concernées et collaborer avec les propriétaires des ressources pour assurer la continuité des activités.
  • 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 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 Impersonation of Service Account for Admin Activity

Une usurpation d'identité anormale de compte de service est détectée 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é de 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 Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

  2. Dans l'onglet Récapitulatif, consultez 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é utilisé pour accéder à Google Cloud.
      • Nom du service: nom d'API du service Google Cloud impliqué dans la requête d'emprunt d'identité.
      • Method name (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 de la chaîne de délégation. Le compte principal en bas de la liste est l'appelant de la requête d'emprunt 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 principale. vérifier si le propriétaire légitime est à l'origine de l'action ;
  2. Examinez les comptes principaux de la chaîne de délégation pour vérifier si la requête est anormale et si un compte a été piraté.
  3. Contactez le propriétaire de l'appelant de l'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: Implémentez votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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.
  • Pensez à supprimer le compte de service potentiellement compromis, et à alterner et supprimer toutes les clés d'accès du compte de service pour le projet potentiellement compromis. Après la suppression, les ressources qui utilisent le compte de service pour l'authentification perdent leur accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources concernées et collaborer avec les propriétaires des ressources pour assurer la continuité des activités.
  • 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 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 de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

  2. Dans l'onglet Récapitulatif, consultez 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é utilisé pour accéder à Google Cloud.
      • Nom du service: nom d'API du service Google Cloud impliqué dans la requête d'emprunt d'identité.
      • Method name (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 de la chaîne de délégation. Le compte principal en bas de la liste est l'appelant 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 principale. vérifier si le propriétaire légitime est à l'origine de l'action ;
  2. Examinez les comptes principaux de la chaîne de délégation pour vérifier si la requête est anormale et si un compte a été piraté.
  3. Contactez le propriétaire de l'appelant de l'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: Implémentez votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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.
  • Pensez à supprimer le compte de service potentiellement compromis, et à alterner et supprimer toutes les clés d'accès du compte de service pour le projet potentiellement compromis. Après la suppression, les ressources qui utilisent le compte de service pour l'authentification perdent leur accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources concernées et collaborer avec les propriétaires des ressources pour assurer la continuité des activités.
  • 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 Data Access

Anomalous Multistep Service Account Delegation est détecté en examinant les journaux d'audit d'accès aux données pour vérifier 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 de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

  2. Dans l'onglet Récapitulatif, consultez 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é utilisé pour accéder à Google Cloud
      • Nom du service: nom de l'API du service Google Cloud impliqué dans la requête d'emprunt 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 de la chaîne de délégation, le compte principal en bas de la liste étant l'appelant 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 principale. vérifier si le propriétaire légitime est à l'origine de l'action ;
  2. Examinez les comptes principaux de la chaîne de délégation pour vérifier si la requête est anormale et si un compte a été piraté.
  3. Contactez le propriétaire de l'appelant de l'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: Implémentez votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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.
  • Pensez à supprimer le compte de service potentiellement compromis, et à alterner et supprimer toutes les clés d'accès du compte de service pour le projet potentiellement compromis. Après la suppression, les ressources qui utilisent le compte de service pour l'authentification perdent leur accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources concernées et collaborer avec les propriétaires des ressources pour assurer la continuité des activités.
  • 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 de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

  2. Dans l'onglet Récapitulatif, consultez 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é utilisé pour accéder à Google Cloud
      • Nom du service: nom de l'API du service Google Cloud impliqué dans la requête d'emprunt 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 de la chaîne de délégation, le compte principal en bas de la liste étant l'appelant 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 principale. vérifier si le propriétaire légitime est à l'origine de l'action ;
  2. Examinez les comptes principaux de la chaîne de délégation pour vérifier si la requête est anormale et si un compte a été piraté.
  3. Contactez le propriétaire de l'appelant de l'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: Implémentez votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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.
  • Pensez à supprimer le compte de service potentiellement compromis, et à alterner et supprimer toutes les clés d'accès du compte de service pour le projet potentiellement compromis. Après la suppression, les ressources qui utilisent le compte de service pour l'authentification perdent leur accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources concernées et collaborer avec les propriétaires des ressources pour assurer la continuité des activités.
  • 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 Data Access

Un emprunt d'identité de compte de service anormal est détecté en examinant les journaux d'audit des accès aux données afin de déterminer si une anomalie s'est produite dans une demande d'emprunt d'identité de 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 la section Examiner les résultats.
  2. Dans les détails du résultat, dans l'onglet Summary (Résumé), notez les valeurs des champs suivants.

    Sous Ce qui a été détecté:

    • Adresse e-mail principale: compte de service final de la demande d'emprunt d'identité utilisé pour accéder à Google Cloud
    • Nom du service: nom de l'API du service Google Cloud impliqué dans la requête d'emprunt 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 de la chaîne de délégation, le compte principal en bas de la liste étant l'appelant 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 principale. vérifier si le propriétaire légitime est à l'origine de l'action ;
  2. Examinez les comptes principaux de la chaîne de délégation pour vérifier si la requête est anormale et si un compte a été piraté.
  3. Contactez le propriétaire de l'appelant de l'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: Implémentez votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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.
  • Pensez à supprimer le compte de service potentiellement compromis, et à alterner et supprimer toutes les clés d'accès du compte de service pour le projet potentiellement compromis. Après la suppression, les ressources qui utilisent le compte de service pour l'authentification perdent leur accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les ressources concernées et collaborer avec les propriétaires des ressources pour assurer la continuité des activités.
  • 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.

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 tôt sur cette page. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Gravité: niveau de risque attribué au résultat. Le niveau de gravité est HIGH si l'appel d'API qui a déclenché ce résultat n'a pas été 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 piraté.
      • 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: le projet contenant les identifiants du 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 fichier 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, saisissez le nom du compte indiqué dans Adresse e-mail principale dans la zone Filtre, puis vérifiez les autorisations attribuées.

  4. Dans Google Cloud Console, 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ésumé du panneau des 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 approprié pour ce résultat, mais il peut également avoir un impact 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.

Inhibit System Recovery: Deleted Google Cloud Backup and DR host

Event Threat Detection examine les journaux d'audit pour détecter la suppression d'hôtes qui exécutent des applications protégées par le service de sauvegarde et de reprise après sinistre. Après la suppression d'un hôte, les applications qui lui sont associées ne peuvent plus ê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 Inhibit System Recovery: Deleted Google Cloud Backup and DR host, comme indiqué dans la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).
  2. Dans l'onglet Summary (Résumé), consultez les informations des sections suivantes :
    • Ce qui a été détecté, en particulier les champs suivants :
      • Application name (Nom de l'application) : nom d'une base de données ou d'une VM connectée à la sauvegarde et à la reprise après sinistre.
      • Nom d'hôte: nom d'un hôte connecté à la sauvegarde et à la reprise après sinistre.
      • Principal subject (Objet principal) : utilisateur qui a exécuté une action.
    • 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 ATTACK: lien vers la documentation MITRE ATT&CK
      • URI de journalisation: 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 principale. vérifier si le propriétaire légitime est à l'origine de l'action ;

Étape 3: Implémentez votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat. Évaluez attentivement les informations que vous recueillez au cours de votre enquête afin de déterminer la meilleure façon de résoudre les résultats.

  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 de sauvegarde et de reprise après sinistre.
  3. Sélectionnez l'option Ajouter un hébergeur pour ajouter à nouveau l'hôte supprimé.

Inhibit System Recovery: Google Cloud Backup and DR remove plan

Security Command Center examine les journaux d'audit pour détecter toute suppression anormale d'un plan de sauvegarde du service de sauvegarde et de reprise après sinistre utilisé pour appliquer des stratégies de sauvegarde à une application.

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

  1. Ouvrez le résultat Inhibit System Recovery: Google Cloud Backup and DR remove plan, comme indiqué dans la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).
  2. Dans l'onglet Summary (Résumé), consultez les informations des sections suivantes :
    • Ce qui a été détecté, en particulier les champs suivants :
      • Application name (Nom de l'application) : nom d'une base de données ou d'une VM connectée à la sauvegarde et à la reprise après sinistre.
      • Profile name (Nom du profil) : spécifie la cible de stockage pour les sauvegardes des données de l'application et de la VM.
      • Nom du modèle: nom d'un ensemble de règles qui définissent la fréquence, la planification et la durée de conservation des sauvegardes
    • Ressource concernée
      • Nom à afficher pour la ressource: projet dans lequel le plan a été supprimé
    • Liens associés, en particulier les champs suivants :
      • Méthode MITRE ATTACK: lien vers la documentation MITRE ATT&CK
      • URI de journalisation: 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 principale. vérifier si le propriétaire légitime est à l'origine de l'action ;

Étape 3: Implémentez votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat. Évaluez attentivement les informations que vous recueillez au cours de votre enquête afin de déterminer la meilleure façon de résoudre les résultats.

  1. Dans le projet où l'action a été effectuée, accédez à la console de gestion.
  2. Dans l'onglet App Manager (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.

Inhibit System Recovery: Google Cloud Backup and DR delete template

Security Command Center examine les journaux d'audit pour détecter toute 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 Inhibit System Recovery: Google Cloud Backup and DR delete template, comme indiqué dans la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).
  2. Dans l'onglet Summary (Résumé), consultez 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 planification et la durée de conservation des sauvegardes
      • Principal subject (Objet principal) : utilisateur qui a exécuté une action.
    • Ressource concernée
      • Resource display name (Nom à afficher de la ressource) : projet dans lequel le modèle a été supprimé
    • Liens associés, en particulier les champs suivants :
      • Méthode MITRE ATTACK: lien vers la documentation MITRE ATT&CK
      • URI de journalisation: 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 principale. vérifier si le propriétaire légitime est à l'origine de l'action ;

Étape 3: Implémentez votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat. Évaluez attentivement les informations que vous recueillez au cours de votre enquête afin de déterminer la meilleure façon de résoudre les résultats.

  1. Dans le projet où l'action a été effectuée, accédez à la console de gestion.
  2. Dans l'onglet App Manager (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 sélectionnez l'option Créer un modèle.

Inhibit System Recovery: Google Cloud Backup and DR delete policy

Les journaux d'audit sont examinés pour détecter la suppression d'une règle. Une stratégie définit la manière dont 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 Inhibit System Recovery: Google Cloud Backup and DR delete policy, comme indiqué dans la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).
  2. Dans l'onglet Summary (Résumé), consultez 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 des sauvegardes, la planification et la durée de conservation
      • Principal subject (Objet principal) : utilisateur qui a exécuté une action.
    • Ressource concernée
      • Nom à afficher de la ressource: projet dans lequel la stratégie a été supprimée
    • Liens associés, en particulier les champs suivants :
      • Méthode MITRE ATTACK: lien vers la documentation MITRE ATT&CK
      • URI de journalisation: 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 principale. vérifier si le propriétaire légitime est à l'origine de l'action ;

Étape 3: Implémentez votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat. Examinez attentivement les informations que vous recueillez au cours de vos recherches afin de déterminer la meilleure façon de résoudre les problèmes. 1. Dans le projet où l'action a été effectuée, accédez à la console de gestion. 2. Dans l'onglet App Manager (Gestionnaire d'applications), sélectionnez l'application concernée et vérifiez les paramètres de Policy (Règles) qui lui sont appliqués.

Inhibit System Recovery: 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 Inhibit System Recovery: Google Cloud Backup and DR delete profile, comme indiqué dans la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).
  2. Dans l'onglet Summary (Résumé), consultez les informations des sections suivantes :
    • Ce qui a été détecté, en particulier les champs suivants :
      • Profile name (Nom du profil) : spécifie la cible de stockage pour les sauvegardes des données de l'application et de la VM.
      • Principal subject (Objet principal) : utilisateur qui a exécuté une action.
    • Ressource concernée
      • Nom à afficher pour la ressource: projet dans lequel le profil a été supprimé
    • Liens associés, en particulier les champs suivants :
      • Méthode MITRE ATTACK: lien vers la documentation MITRE ATT&CK
      • URI de journalisation: 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 principale. vérifier si le propriétaire légitime est à l'origine de l'action ;

Étape 3: Implémentez votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat. Examinez attentivement les informations que vous recueillez au cours de vos recherches afin de déterminer la meilleure façon de résoudre les problèmes. 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 vous assurer que tous les profils requis sont en place. 4. Si le profil supprimé a été retiré par erreur, sélectionnez Créer un profil pour définir des cibles de stockage pour vos dispositifs de sauvegarde et de reprise après sinistre.

Inhibit System Recovery: 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 à la sauvegarde et à la reprise après sinistre.

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

  1. Ouvrez le résultat Inhibit System Recovery: Google Cloud Backup and DR delete storage pool, comme indiqué dans la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).
  2. Dans l'onglet Summary (Résumé), consultez 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
      • Principal subject (Objet principal) : utilisateur qui a exécuté une action.
    • Ressource concernée
      • Nom à afficher pour la ressource: projet dans lequel le pool de stockage a été supprimé
    • Liens associés, en particulier les champs suivants :
      • Méthode MITRE ATTACK: lien vers la documentation MITRE ATT&CK
      • URI de journalisation: 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 principale. vérifier si le propriétaire légitime est à l'origine de l'action ;

Étape 3: Implémentez votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat. Examinez attentivement les informations que vous recueillez au cours de vos recherches afin de déterminer la meilleure façon de résoudre les problèmes. 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 des dispositifs de sauvegarde. 4. Si un appareil actif n'est associé à aucun pool de stockage, sélectionnez Ajouter un pool OnVault pour l'ajouter à nouveau.

Data Destruction: Google Cloud Backup and DR expire image

Un acteur potentiellement malveillant a demandé à supprimer une image de back-up.

É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 la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).
  2. Dans l'onglet Summary (Résumé), consultez 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 des sauvegardes, la planification et la durée de conservation
      • Nom du modèle: nom d'un ensemble de règles qui définissent la fréquence, la planification et la durée de conservation des sauvegardes
      • Profile name (Nom du profil) : spécifie la cible de stockage pour les sauvegardes des données de l'application et de la VM.
      • Principal subject (Objet principal) : utilisateur qui a exécuté une action.
    • Ressource concernée
      • Nom à afficher de la ressource: projet dans lequel l'image de back-up a été supprimée
    • Liens associés, en particulier les champs suivants :
      • Méthode MITRE ATTACK: lien vers la documentation MITRE ATT&CK
      • URI de journalisation: 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 principale. vérifier si le propriétaire légitime est à l'origine de l'action ;

Étape 3: Implémentez votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat. Examinez attentivement les informations que vous recueillez au cours de vos recherches afin de déterminer la meilleure façon de résoudre les problèmes. 1. Dans le projet où l'action a été effectuée, accédez à la console de gestion. 2. Accédez à l'onglet "Monitor" (Surveiller), sélectionnez "Jobs" (Tâches) pour consulter l'état du job de sauvegarde de suppression. 3. Si un job de suppression n'est pas autorisé, accédez aux autorisations IAM pour examiner les utilisateurs ayant accès aux données de sauvegarde.

Data Destruction: Google Cloud Backup and DR expire all images

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

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

  1. Ouvrez le résultat Inhibit System Recovery: Google Cloud Backup and DR expire all images, comme indiqué dans la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).
  2. Dans l'onglet Summary (Résumé), consultez 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 des sauvegardes, la planification et la durée de conservation
      • Nom du modèle: nom d'un ensemble de règles qui définissent la fréquence, la planification et la durée de conservation des sauvegardes
      • Profile name (Nom du profil) : spécifie la cible de stockage pour les sauvegardes des données de l'application et de la VM.
      • Principal subject (Objet principal) : utilisateur qui a exécuté une action.
    • Ressource concernée
      • Nom à afficher de la ressource: projet dans lequel les images de back-up ont été supprimées
    • Liens associés, en particulier les champs suivants :
      • Méthode MITRE ATTACK: lien vers la documentation MITRE ATT&CK
      • URI de journalisation: 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 principale. vérifier si le propriétaire légitime est à l'origine de l'action ;

Étape 3: Implémentez votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat. Examinez attentivement les informations que vous recueillez au cours de vos recherches afin de déterminer la meilleure façon de résoudre les problèmes. 1. Dans le projet où l'action a été effectuée, accédez à la console de gestion. 2. Accédez à l'onglet "Monitor" (Surveiller), sélectionnez "Jobs" (Tâches) pour consulter l'état du job de sauvegarde de suppression. 3. Si un job de suppression n'est pas autorisé, accédez aux autorisations IAM pour examiner les utilisateurs ayant accès aux données de sauvegarde.

Data Destruction: 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 dispositif de sauvegarde et de récupération est un composant essentiel des 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 la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).
  2. Dans l'onglet Summary (Résumé), consultez les informations des sections suivantes :
    • Ce qui a été détecté, en particulier les champs suivants :
      • Nom de l'appareil: nom d'une base de données ou d'une VM connectée à la sauvegarde et à la reprise après sinistre.
      • Principal subject (Objet principal) : utilisateur qui a exécuté une action.
    • Ressource concernée
      • Resource display name (Nom à afficher de la ressource) : projet dans lequel l'appareil a été supprimé
    • Liens associés, en particulier les champs suivants :
      • Méthode MITRE ATTACK: lien vers la documentation MITRE ATT&CK
      • URI de journalisation: 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 principale. vérifier si le propriétaire légitime est à l'origine de l'action ;

Étape 3: Implémentez votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat. Examinez attentivement les informations que vous recueillez au cours de vos recherches afin de déterminer la meilleure façon de résoudre les problèmes. 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 à "Sauvegarde et reprise après sinistre" dans la console Google Cloud, puis sélectionnez l'option "Déployer un autre dispositif de sauvegarde ou de récupération". 4. Dans le menu Stockage, configurez chaque nouveau dispositif avec une cible de stockage. Une fois le dispositif configuré, il s'affiche en tant qu'option lorsque vous créez un profil pour vos applications.

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 un dispositif de service de sauvegarde et de reprise après sinistre 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 la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).
  2. Dans l'onglet Summary (Résumé), consultez 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.
    • Ressource concernée
      • Nom à afficher de la ressource: projet dans lequel le délai d'expiration de la sauvegarde a été réduit.
    • Liens associés, en particulier les champs suivants :
      • Méthode MITRE ATTACK: lien vers la documentation MITRE ATT&CK.
      • URI de journalisation: 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 principal. vérifier si le propriétaire légitime est à l'origine de l'action ;

Étape 3: Implémentez votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat. Évaluez attentivement les informations que vous recueillez au cours de votre enquête afin de déterminer la meilleure façon de résoudre les résultats.

  1. Dans le projet où l'action a été effectuée, accédez à la console de gestion.
  2. Dans l'onglet App Manager, recherchez l'application concernée pour laquelle le délai d'expiration de la sauvegarde a été réduit et vérifiez que le délai d'expiration était prévu 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étecter si le plan de sauvegarde a été modifié pour 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 la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).
  2. Dans l'onglet Summary (Résumé), consultez 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.
    • 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 ATTACK: lien vers la documentation MITRE ATT&CK.
      • URI de journalisation: 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 principal. vérifier si le propriétaire légitime est à l'origine de l'action ;

Étape 3: Implémentez votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat. Évaluez attentivement les informations que vous recueillez au cours de votre enquête afin de déterminer la meilleure façon de résoudre les résultats.

  1. Dans le projet où l'action a été effectuée, accédez à la console de gestion.
  2. Dans l'onglet App Manager, recherchez l'application concernée pour laquelle la fréquence de sauvegarde a été réduite et vérifiez que la modification était prévue 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.

Lateral Movement: Modified Boot Disk Attached to Instance

Les journaux d'audit sont examinés pour détecter les mouvements de disque suspects parmi 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 la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).
  2. Dans l'onglet Summary (Résumé), notez les valeurs des champs suivants.

    Sous Ce qui a été 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 du compte de service, tels que 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 principale. vérifier si le propriétaire légitime est à l'origine de l'action ;

Étape 3: Implémentez votre réponse

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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 Compute Engine.
  • Pensez à supprimer le compte de service potentiellement compromis, et à alterner et supprimer toutes les clés d'accès du compte de service pour le projet potentiellement compromis. Après la 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 leurs propriétaires afin d'assurer la continuité des activités.
  • 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.

Privilege Escalation: AlloyDB Over-Privileged Grant

Détecte les cas où tous les droits sur 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 la section Examiner les résultats.
  2. Dans l'onglet Résumé du panneau des détails du résultat, consultez les informations des sections suivantes:

    • Ce qui a été détecté, en particulier les champs suivants :
      • Database display name (Nom à afficher de la base de données) : nom de la base de données de l'instance AlloyDB pour PostgreSQL affectée.
      • Database user name (Nom d'utilisateur de la base de données) : utilisateur PostgreSQL ayant accordé les droits en excès.
      • Requête de base de données: requête PostgreSQL exécutée ayant accordé les droits.
      • Bénéficiaires de la base de données: bénéficiaires des privilèges trop larges.
    • Ressource concernée, en particulier les champs suivants :
      • Nom complet de la ressource: nom de la ressource de l'instance AlloyDB pour PostgreSQL affectée.
      • Parent full name (Nom complet du parent) : nom de ressource de l'instance AlloyDB pour PostgreSQL.
      • Nom complet du projet: le 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 fichier 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 (à l'étape 1).
    • Fonctions ou procédures. Exécutez la métacommande \df et vérifiez les droits attribués pour les fonctions ou les procédures dans la base de données répertoriée dans Nom à afficher de la base de données (à l'é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 de l'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, consultez les journaux PostgreSQL pgaudit, 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 approprié pour ce résultat, mais il peut également avoir un impact 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 des bénéficiaires répertoriés dans Bénéfices de la base de données jusqu'à la fin de l'enquête.
  • Pour limiter l'accès à la base de données (dans le nom à afficher pour la base de données de l'étape 1, revoke les autorisations inutiles des bénéficiaires (à partir de bénéficiaires de base de données de l'étape 1).

Privilege Escalation: AlloyDB Database Superuser Writes to User Tables

Détecte quand le compte de super-utilisateur de base de données AlloyDB pour PostgreSQL (postgres) écrit dans des tables utilisateur. Le super-utilisateur (un rôle avec un accès très large) ne doit généralement pas être utilisé pour écrire dans des 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 des utilisateurs, cela peut indiquer qu'un pirate informatique a élever ses privilèges ou a compromis l'utilisateur de la base de données par défaut et qu'il modifie des données. Cela pourrait é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 des détails du résultat, consultez les informations des sections suivantes:

    • Ce qui a été détecté, en particulier les champs suivants :
      • Database display name (Nom à afficher de la base de données) : nom de la base de données de l'instance AlloyDB pour PostgreSQL affectée.
      • Database user name (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 la ressource de l'instance AlloyDB pour PostgreSQL affectée.
      • Parent full name (Nom complet du parent) : nom de ressource de l'instance AlloyDB pour PostgreSQL.
      • Nom complet du projet: le 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 fichier 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 (étape 1). La page Explorateur de journaux inclut tous les journaux liés à l'instance AlloyDB pour PostgreSQL concernée.
  2. Recherchez les journaux pgaudit de PostgreSQL, qui contiennent les requêtes exécutées par le super-utilisateur, dans les journaux à 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 approprié pour ce résultat, mais il peut également avoir un impact 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.

Détection des métadonnées de l'administrateur Compute Engine

Persistence: GCE Admin Added SSH Key

Description Actions
La clé de métadonnées de l'instance Compute Engine ssh-keys a été modifiée sur une instance établie. La clé de métadonnées de l'instance Compute Engine ssh-keys a été modifiée sur une instance créée il y a plus de sept jours. Vérifiez si la modification a été effectuée intentionnellement par un membre ou si elle a été mise en œuvre par une personne mal intentionnée pour créer un nouvel accès à votre organisation.

Vérifiez les journaux à l'aide des filtres suivants :

protopayload.resource.labels.instance_id=INSTANCE_ID

protoPayload.serviceName="compute.googleapis.com"

(protoPayload.metadata.instanceMetaData.addedMetadataKey : "ssh-keys" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "ssh-keys" )

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

Remplacez les éléments suivants :

  • INSTANCE_ID : valeur gceInstanceId répertoriée dans le résultat
  • ORGANIZATION_ID : ID de votre organisation.

Événements de recherche qui déclenchent ce résultat :

Persistence: GCE Admin Added Startup Script

Description Actions
La clé de métadonnées de l'instance Compute Engine startup-script ou startup-script-url a été modifiée sur une instance établie. La clé de métadonnées de l'instance Compute Engine startup-script ou startup-script-url a été modifiée sur une instance créée il y a plus de sept jours. Vérifiez si la modification a été effectuée intentionnellement par un membre ou si elle a été mise en œuvre par une personne mal intentionnée pour créer un nouvel accès à votre organisation.

Vérifiez les journaux à l'aide des filtres suivants :

protopayload.resource.labels.instance_id=INSTANCE_ID

protoPayload.serviceName="compute.googleapis.com"

((protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script" )

OR (protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script-url" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script-url" ))

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

Remplacez les éléments suivants :

  • INSTANCE_ID : valeur gceInstanceId répertoriée dans le résultat
  • ORGANIZATION_ID : ID de votre organisation.

Événements de recherche qui déclenchent ce résultat :

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. Étant donné que les journaux Google Workspace sont 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.

Description Actions
Le compte d'un membre est désactivé, car une fuite de mot de passe a été détectée. Réinitialisez les mots de passe des comptes concernés et conseillez aux membres de choisir des mots de passe uniques et sécurisés pour les comptes professionnels.

Vérifiez les journaux à l'aide des filtres suivants :

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

Remplacez ORGANIZATION_ID par votre ID d'organisation.

Événements de recherche qui déclenchent ce résultat :

Initial Access: Suspicious Login Blocked

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Description Actions
Une connexion suspecte au compte d'un membre a été détectée et bloquée. Ce compte peut être ciblé par des personnes mal intentionnées. Assurez-vous que le compte utilisateur respecte les consignes de sécurité de votre organisation concernant les mots de passe sécurisés et l'authentification multifacteur.

Vérifiez les journaux à l'aide des filtres suivants :

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

Remplacez ORGANIZATION_ID par votre ID d'organisation.

Événements de recherche qui déclenchent ce résultat :

Initial Access: Account Disabled Hijacked

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Description Actions
Le compte d'un membre a été suspendu en raison d'une activité suspecte. Ce compte a été piraté. Réinitialisez le mot de passe du compte d'entreprise et encouragez les utilisateurs à en créer des mots de passe uniques et sécurisés.

Vérifiez les journaux à l'aide des filtres suivants :

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

Remplacez ORGANIZATION_ID par votre ID d'organisation.

Événements de recherche qui déclenchent ce résultat :

Impair Defenses: Two Step Verification Disabled

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Description Actions
Un membre a désactivé la validation en deux étapes. Vérifiez si l'utilisateur a essayé de désactiver la validation en deux étapes. Si votre organisation requiert la validation en deux étapes, assurez-vous que l'utilisateur l'active rapidement.

Vérifiez les journaux à l'aide des filtres suivants :

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

Remplacez ORGANIZATION_ID par votre ID d'organisation.

Événements de recherche qui déclenchent ce résultat :

Initial Access: Government Based Attack

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Description Actions
Les pirates informatiques soutenus par un gouvernement ont peut-être tenté de compromettre le compte ou l'ordinateur d'un membre. Ce compte peut être ciblé par des personnes mal intentionnées. Assurez-vous que le compte utilisateur respecte les consignes de sécurité de votre organisation concernant les mots de passe sécurisés et l'authentification multifacteur.

Vérifiez les journaux à l'aide des filtres suivants :

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

Remplacez ORGANIZATION_ID par votre ID d'organisation.

Événements de recherche qui déclenchent ce résultat :

Persistence: SSO Enablement Toggle

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Description Actions
Le paramètre "Activer SSO" (Authentification unique) a été désactivé pour le compte administrateur. Les paramètres SSO de votre organisation ont été modifiés. Vérifiez si la modification a été effectuée intentionnellement par un membre ou si elle a été mise en œuvre par une personne mal intentionnée pour créer un nouvel accès à votre organisation.

Vérifiez les journaux à l'aide des filtres suivants :

protopayload.resource.labels.service="admin.googleapis.com"

protopayload.metadata.event.parameter.value=DOMAIN_NAME

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

Remplacez les éléments suivants :

  • DOMAIN_NAME : valeur domainName répertoriée dans le résultat
  • ORGANIZATION_ID : ID de votre organisation.

Événements de recherche qui déclenchent ce résultat :

Persistence: SSO Settings Changed

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Description Actions
Les paramètres SSO du compte administrateur ont été modifiés. Les paramètres SSO de votre organisation ont été modifiés. Vérifiez si la modification a été effectuée intentionnellement par un membre ou si elle a été mise en œuvre par une personne mal intentionnée pour créer un nouvel accès à votre organisation.

Vérifiez les journaux à l'aide des filtres suivants :

protopayload.resource.labels.service="admin.googleapis.com"

protopayload.metadata.event.parameter.value=DOMAIN_NAME

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

Remplacez les éléments suivants :

  • DOMAIN_NAME : valeur domainName répertoriée dans le résultat
  • ORGANIZATION_ID : ID de votre organisation.

Événements de recherche qui déclenchent ce résultat :

Impair Defenses: Strong Authentication Disabled

Ce résultat n'est pas disponible si vous activez Security Command Center au niveau du projet.

Description Actions
La validation en deux étapes a été désactivée pour l'organisation. La validation en deux étapes n'est plus nécessaire pour votre organisation. Déterminez s'il s'agit d'une modification de règle intentionnelle de la part d'un administrateur, ou s'il s'agit d'une tentative de la part d'une personne mal intentionnée visant à faciliter le piratage du compte.

Vérifiez les journaux à l'aide des filtres suivants :

protopayload.resource.labels.service="admin.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

Remplacez ORGANIZATION_ID par votre ID d'organisation.

Événements de recherche qui déclenchent ce résultat :

Réagir aux menaces Google Workspace

Les résultats concernant Google Workspace ne sont disponibles que pour les activations de Security Command Center au niveau de l'organisation. Les journaux Google Workspace ne permettent pas d'identifier 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 :

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 :

Détection 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 à destination et en provenance de vos ressources Google Cloud pour détecter les menaces. Lorsque Cloud IDS détecte une menace, il envoie des informations la concernant, telles que l'adresse IP source, l'adresse de destination et le numéro de port, à Event Threat Detection, qui émet ensuite un résultat de détection.

Étape 1 : Examiner les détails du résultat
  1. Ouvrez le résultat Cloud IDS: THREAT_ID, comme indiqué dans la section Examiner les résultats.

  2. Dans les détails du résultat, dans l'onglet Summary (Résumé), examinez les valeurs listées dans les sections suivantes:

    • Ce qui a été détecté, en particulier les champs suivants :
      • Protocol (Protocole) : le protocole réseau utilisé
      • Heure de l'événement: moment auquel l'événement s'est produit.
      • Description: informations supplémentaires sur le résultat
      • Gravité: niveau de gravité de l'alerte.
      • Adresse IP de destination: l'adresse IP cible du trafic réseau
      • Port de destination: port cible du trafic réseau
      • Adresse IP source: l'adresse IP source du trafic réseau.
      • Source Port (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 présentant 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 effectuer une recherche dans la volet Vault de Palao Alto Networks.
    • Service de détection
      • Catégorie de résultat : nom de la menace Cloud IDS
  3. Pour afficher le fichier JSON complet du résultat, cliquez sur l'onglet JSON.

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

Après avoir examiné les détails du résultat, veuillez vous reporter à la documentation Cloud IDS sur l'examen des alertes de menace pour déterminer une réponse appropriée.

Pour plus d'informations sur l'événement détecté dans l'entrée de journal d'origine, cliquez sur le lien dans le champ URI Cloud Logging dans les 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. 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 Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Binaire du programme: chemin 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.
  3. Cliquez sur le 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é.

Étape 2 : Vérifier le cluster et le nœud

  1. Dans Cloud Console, accédez à la page des clusters Kubernetes.

    Accéder à la page "Clusters Kubernetes"

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.

  3. Sélectionnez le cluster répertorié sur la ligne Nom complet de la ressource de 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 répertorié dans resource.project_display_name, si nécessaire.

  3. Si nécessaire, filtrez le cluster répertorié sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat et l'espace de noms du pod indiqué dans Pod_Namespace.

  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 répertorié 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 à Google Cloud Console.

    Ouvrir la console Google Cloud

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié 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 de l'outil Ingress, API native.
  2. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

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

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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.

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. 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 Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Binaire du programme: chemin complet du binaire de processus qui a chargé la bibliothèque.
      • Bibliothèques: informations sur la bibliothèque ajoutée.
      • Arguments: arguments fournis lors de l'appel du binaire de processus.
    • Ressource concernée, en particulier les champs suivants :
  3. Cliquez sur l'onglet JSON et notez les champs suivants:

    • resource:
      • project_display_name: nom du projet contenant l'élément.
    • 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é.

Étape 2 : Vérifier le cluster et le nœud

  1. Dans Cloud Console, accédez à la page des clusters Kubernetes.

    Accéder à la page "Clusters Kubernetes"

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié 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 répertorié dans resource.project_display_name, si nécessaire.

  3. Si nécessaire, filtrez le cluster répertorié sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat et l'espace de noms du pod indiqué dans Pod_Namespace.

  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 répertorié 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 à Google Cloud Console.

    Ouvrir la console Google Cloud

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié 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. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

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

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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.

Execution: Added Malicious Binary Executed

Un binaire malveillant qui ne faisait 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. Pour répondre à ce résultat, procédez comme suit :

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

  1. Ouvrez un résultat Execution: Added Malicious Binary Executed comme indiqué dans Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Binaire du programme: chemin absolu du binaire ajouté.
      • Arguments: arguments fournis lors de l'appel du binaire ajouté.
      • Conteneurs: nom du conteneur concerné.
      • URI du conteneur: nom de l'image du conteneur en cours de déploiement.
    • 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 l'onglet JSON et notez les champs suivants:

    • sourceProperties:
      • VM_Instance_Name: nom du nœud GKE sur lequel le pod a été exécuté.

Étape 2 : Vérifier le cluster et le nœud

  1. Dans Cloud Console, accédez à la page des clusters Kubernetes.

    Accéder à la page "Clusters Kubernetes"

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.

  3. Sélectionnez le cluster répertorié sur la ligne Nom complet de la ressource de 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 répertorié dans resource.project_display_name, si nécessaire.

  3. Si nécessaire, filtrez le cluster répertorié sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat et l'espace de noms du pod indiqué dans Pod_Namespace.

  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 répertorié 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 à Google Cloud Console.

    Ouvrir la console Google Cloud

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié 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 malveillant ajouté:

      kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
    

    Remplacez local_file par un chemin d'accès local pour stocker le binaire malveillant ajouté.

  6. Connectez-vous à l'environnement de conteneurs:

      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 de l'outil Ingress, API native.
  2. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.
  3. Vérifiez la valeur de hachage SHA-256 du 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.

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

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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.

Execution: Added Malicious Library Loaded

Une bibliothèque malveillante qui ne faisait 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. Pour répondre à ce résultat, procédez comme suit :

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

  1. Ouvrez un résultat Execution: Added Malicious Library Loaded comme indiqué dans Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Binaire du programme: chemin complet du binaire de processus qui a chargé la bibliothèque.
      • Bibliothèques: informations sur la bibliothèque ajoutée.
      • Arguments: arguments fournis lors de l'appel du binaire de processus.
      • Conteneurs: nom du conteneur concerné.
      • URI du conteneur: nom de l'image du conteneur en cours de déploiement.
    • Ressource concernée, en particulier les champs suivants :
    • 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:

    • sourceProperties:
      • VM_Instance_Name: nom du nœud GKE sur lequel le pod a été exécuté.

Étape 2 : Vérifier le cluster et le nœud

  1. Dans Cloud Console, accédez à la page des clusters Kubernetes.

    Accéder à la page "Clusters Kubernetes"

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.

  3. Sélectionnez le cluster répertorié sur la ligne Nom complet de la ressource de 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 répertorié dans resource.project_display_name, si nécessaire.

  3. Si nécessaire, filtrez le cluster répertorié sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat et l'espace de noms du pod indiqué dans Pod_Namespace.

  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 répertorié 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 à Google Cloud Console.

    Ouvrir la console Google Cloud

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié 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 malveillante ajoutée:

      kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
    

    Remplacez local_file par un chemin d'accès local pour stocker la bibliothèque malveillante ajoutée.

  6. Connectez-vous à l'environnement de conteneurs:

      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. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.
  3. Vérifiez la valeur de hachage SHA-256 de la bibliothèque signalée comme malveillante 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.

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

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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.

Execution: Built in Malicious Binary Executed

Un binaire exécuté, avec le binaire:

  • Incluse dans l'image de conteneur d'origine.
  • Identifiés comme malveillants d’après la Threat Intelligence

L'attaquant contrôle le dépôt d'images de conteneurs ou le pipeline de création, dans lesquels le binaire malveillant est injecté dans l'image du conteneur. Pour répondre à ce résultat, procédez comme suit :

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

  1. Ouvrez un résultat Execution: Built in Malicious Binary Executed comme indiqué dans Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Binaire du programme: chemin absolu du binaire intégré.
      • Arguments: arguments fournis lors de l'appel du binaire intégré.
      • Conteneurs: nom du conteneur concerné.
      • URI du conteneur: nom de l'image du conteneur en cours de déploiement.
    • 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 le JSON et notez les champs suivants:

    • sourceProperties:
      • VM_Instance_Name: nom du nœud GKE sur lequel le pod a été exécuté.

Étape 2 : Vérifier le cluster et le nœud

  1. Dans Cloud Console, accédez à la page des clusters Kubernetes.

    Accéder à la page "Clusters Kubernetes"

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.

  3. Sélectionnez le cluster répertorié sur la ligne Nom complet de la ressource de 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 répertorié dans resource.project_display_name, si nécessaire.

  3. Si nécessaire, filtrez le cluster répertorié sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat et l'espace de noms du pod indiqué dans Pod_Namespace.

  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 répertorié 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 à Google Cloud Console.

    Ouvrir la console Google Cloud

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié 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 malveillant intégré:

      kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
    

    Remplacez local_file par un chemin d'accès local pour stocker le binaire malveillant tin créé.

  6. Connectez-vous à l'environnement de conteneurs:

      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 de l'outil Ingress, API native.
  2. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.
  3. Vérifiez la valeur de hachage SHA-256 du 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.

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

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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.

Execution: Modified Malicious Binary Executed

Un binaire exécuté, avec le binaire:

  • Incluse dans l'image de conteneur d'origine.
  • Vous l'avez modifiée pendant l'exécution du conteneur.
  • Identifiés comme malveillants d’après la Threat Intelligence

Les pirates informatiques installent généralement les outils d'exploitation et les logiciels malveillants après le piratage initial. Pour répondre à ce résultat, procédez comme suit :

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

  1. Ouvrez un résultat Execution: Modified Malicious Binary Executed comme indiqué dans Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Binaire du programme: chemin absolu du binaire modifié.
      • Arguments: arguments fournis lors de l'appel du binaire modifié.
      • Conteneurs: nom du conteneur concerné.
      • URI du conteneur: nom de l'image du conteneur en cours de déploiement.
    • 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 le JSON et notez les champs suivants:

    • sourceProperties:
      • VM_Instance_Name: nom du nœud GKE sur lequel le pod a été exécuté.

Étape 2 : Vérifier le cluster et le nœud

  1. Dans Cloud Console, accédez à la page des clusters Kubernetes.

    Accéder à la page "Clusters Kubernetes"

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.

  3. Sélectionnez le cluster répertorié sur la ligne Nom complet de la ressource de 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 répertorié dans resource.project_display_name, si nécessaire.

  3. Si nécessaire, filtrez le cluster répertorié sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat et l'espace de noms du pod indiqué dans Pod_Namespace.

  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 répertorié 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 à Google Cloud Console.

    Ouvrir la console Google Cloud

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié 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 malveillant modifié:

      kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
    

    Remplacez local_file par un chemin d'accès local pour stocker le binaire malveillant modifié.

  6. Connectez-vous à l'environnement de conteneurs:

      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 de l'outil Ingress, API native.
  2. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.
  3. Vérifiez la valeur de hachage SHA-256 du 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.

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

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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.

Execution: Modified Malicious Library Loaded

Une bibliothèque chargée, avec la bibliothèque:

  • Incluse dans l'image de conteneur d'origine.
  • Vous l'avez modifiée pendant l'exécution du conteneur.
  • Identifiés comme malveillants d’après la Threat Intelligence

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. Pour répondre à ce résultat, procédez comme suit :

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

  1. Ouvrez un résultat Execution: Modified Malicious Library Loaded comme indiqué dans Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Binaire du programme: chemin complet du binaire de processus qui a chargé la bibliothèque.
      • Bibliothèques: informations sur la bibliothèque modifiée.
      • Arguments: arguments fournis lors de l'appel du binaire de processus.
      • Conteneurs: nom du conteneur concerné.
      • URI du conteneur: nom de l'image du conteneur en cours de déploiement.
    • Ressource concernée, en particulier les champs suivants :
    • 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:

    • sourceProperties:
      • VM_Instance_Name: nom du nœud GKE sur lequel le pod a été exécuté.

Étape 2 : Vérifier le cluster et le nœud

  1. Dans Cloud Console, accédez à la page des clusters Kubernetes.

    Accéder à la page "Clusters Kubernetes"

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié 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 répertorié dans resource.project_display_name, si nécessaire.

  3. Si nécessaire, filtrez le cluster répertorié sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat et l'espace de noms du pod indiqué dans Pod_Namespace.

  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 répertorié 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 à Google Cloud Console.

    Ouvrir la console Google Cloud

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié 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 malveillante modifiée:

      kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
    

    Remplacez local_file par un chemin d'accès local pour stocker la bibliothèque malveillante modifiée.

  6. Connectez-vous à l'environnement de conteneurs:

      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. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.
  3. Vérifiez la valeur de hachage SHA-256 de la bibliothèque signalée comme malveillante 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.

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

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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.

Malicious Script Executed

Un modèle de machine learning a identifié un script bash exécuté comme malveillant. Les pirates informatiques peuvent utiliser bash pour transférer des outils et exécuter des commandes sans binaire.

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

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

  1. Ouvrez un résultat Malicious Script Executed comme indiqué dans la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Binaire du programme: informations sur l'interpréteur qui a appelé le script.
      • Script: chemin absolu du nom du script sur le disque. Cet attribut n'apparaît que pour les scripts écrits sur le disque, pas pour l'exécution littérale de script, par exemple bash -c.
      • Arguments: arguments fournis lors de l'appel du script.
    • 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.

    • finding:
      • processes:
      • script:
        • contents : préfixe du contenu du fichier du script exécuté, ce qui peut faciliter votre enquête. Le contenu peut être tronqué pour des raisons de performances.
        • sha256 : hachage SHA-256 de script.contents
    • resource:
      • project_display_name: nom du projet contenant l'élément.
    • 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é.

Étape 2 : Vérifier le cluster et le nœud

  1. Dans Cloud Console, accédez à la page des clusters Kubernetes.

    Accéder à la page "Clusters Kubernetes"

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name, si nécessaire.

  3. Sélectionnez le cluster répertorié sur la ligne Nom complet de la ressource de 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 répertorié dans resource.project_display_name, si nécessaire.

  3. Filtrez le cluster répertorié dans resource.name et l'espace de noms du pod répertorié 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 répertorié 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. Dans Cloud Console, accédez à la page des clusters Kubernetes.

    Accéder à la page "Clusters Kubernetes"

  2. Cliquez sur le nom du cluster affiché dans resource.labels.cluster_name.

  3. Sur la page Clusters, cliquez sur Se connecter, puis sur Exécuter dans Cloud Shell.

    Cloud Shell lance et ajoute des commandes pour le cluster dans le terminal.

  4. Appuyez sur Entrée. Si la boîte de dialogue Autoriser Cloud Shell s'affiche, cliquez sur Autoriser.

  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 : Interpréteur de commandes et de scripts, Transfert d'outils Ingress.
  2. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

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

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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.

Malicious URL Observed

Container Threat Detection a détecté une URL malveillante dans la liste d'arguments d'un processus exécutable. Les pirates informatiques peuvent charger des logiciels malveillants ou des bibliothèques malveillantes via des URL malveillantes.

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

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

  1. Ouvrez un résultat Malicious URL Observed comme indiqué dans la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • URI: URI malveillant observé.
      • Binaire ajouté: chemin complet du binaire de processus qui a reçu les arguments contenant l'URL malveillante.
      • Arguments: arguments fournis lors de l'appel du binaire de processus.
      • Environment variables (Variables d'environnement) : variables d'environnement en vigueur lorsque le binaire de processus a été appelé.
      • Conteneurs: nom du conteneur.
      • Pods Kubernetes: nom et espace de noms du pod
    • Ressource concernée, en particulier les champs suivants :
      • Nom à afficher pour la ressource: nom de la ressource concernée.
      • Nom complet de la ressource: nom complet de la ressource du cluster. Le nom complet de la ressource contient les informations suivantes :
        • Projet contenant le cluster: projects/PROJECT_ID
        • Emplacement où se trouve le cluster: zone/ZONE ou locations/LOCATION
        • Le nom du cluster: projects/CLUSTER_NAME
  3. Dans l'onglet JSON, notez la valeur de la propriété VM_Instance_Name dans l'attribut sourceProperties.

Étape 2 : Vérifier le cluster et le nœud

  1. Dans Cloud Console, accédez à la page des clusters Kubernetes.

    Accéder à la page "Clusters Kubernetes"

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet qui s'affiche dans Nom complet de la ressource (resource.name), si nécessaire. Le nom du projet apparaît après /projects/ dans le nom complet de la ressource.

  3. Cliquez sur le nom du cluster que vous avez noté dans Nom à afficher de la ressource (resource.display_name) du résumé du résultat. La page Clusters s'ouvre.

  4. Dans la section Métadonnées de la page **Détails du cluster, notez les informations définies par l'utilisateur qui peuvent être utiles pour résoudre la menace, telles que les informations identifiant le propriétaire du cluster.

  5. Cliquez sur l'onglet Nœuds.

  6. Dans les nœuds répertoriés, sélectionnez celui qui correspond à la valeur de VM_Instance_Name que vous avez notée précédemment dans le résultat JSON.

  7. Dans l'onglet Détails de la page Détails du nœud, dans la section Annotations, notez la valeur de 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 que vous avez noté dans le champ Nom complet de la ressource (resource.name) du cluster dans le résumé des résultats, si nécessaire.

  3. Cliquez sur Afficher les charges de travail du système.

  4. Filtrez la liste des charges de travail en fonction du nom du cluster que vous avez noté dans Nom complet de la ressource (resource.name) du résumé du résultat et, si nécessaire, de l'espace de noms du pod (kubernetes.pods.ns) que vous avez noté.

  5. Cliquez sur le nom de la charge de travail qui correspond à la valeur de la propriété VM_Instance_Name que vous avez notée précédemment dans le résultat JSON. La page Détails du pod s'ouvre.

  6. Sur la page Détails du pod, notez toute information concernant le pod pouvant vous aider à résoudre la menace.

É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 qui s'affiche dans Nom complet de la ressource (resource.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 les journaux du pod (kubernetes.pods.name) à l'aide du filtre suivant :
      • resource.type="k8s_container"
      • resource.labels.project_id="PROJECT_ID"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • resource.labels.namespace_name="NAMESPACE_NAME"
      • resource.labels.pod_name="POD_NAME"
    2. Recherchez les journaux d'audit du cluster à l'aide du filtre suivant :
      • logName="projects/PROJECT_NAME/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="PROJECT_ID"
      • resource.labels.location="LOCATION_OR_ZONE"
      • resource.labels.cluster_name="CLUSTER_NAME/var>"
      • 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. Dans Cloud Console, accédez à la page des clusters Kubernetes.

    Accéder à la page "Clusters Kubernetes"

  2. Cliquez sur le nom du cluster affiché dans resource.labels.cluster_name.

  3. Sur la page Clusters, cliquez sur Se connecter, puis sur Exécuter dans Cloud Shell.

    Cloud Shell lance et ajoute des commandes pour le cluster dans le terminal.

  4. Appuyez sur Entrée. Si la boîte de dialogue Autoriser Cloud Shell s'affiche, cliquez sur Autoriser.

  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
    

    Remplacez CONTAINER_NAME par le nom du conteneur que vous avez noté précédemment dans le résumé des résultats.

    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. Consultez l'état du site selon la navigation sécurisée pour savoir pourquoi l'URL est classée comme malveillante.
  2. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Ingress Tool Transfer.
  3. Pour développer un plan de réponse, combinez les résultats de votre enquête avec la recherche MITRE.

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

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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.

Reverse Shell

Un processus a commencé par une redirection de flux vers un socket connecté distant. La génération d'une interface système connectée au réseau peut permettre à un pirate informatique d'effectuer des actions arbitraires après une compromission initiale limité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 Reverse Shell comme indiqué dans la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Binaire de programme: chemin absolu du processus démarré par la redirection de flux vers un socket distant.
      • Arguments: arguments fournis lors de l'appel du binaire de processus.
    • Ressource concernée, en particulier les champs suivants :
    • Dans la vue détaillée du résultat, cliquez sur l'onglet JSON.
    • Dans le fichier JSON, notez les champs suivants.
    • resource:
      • project_display_name: nom du projet contenant l'élément.
    • sourceProperties:
      • Pod_Namespace: nom de l'espace de noms Kubernetes du pod.
      • Pod_Name: nom du pod GKE.
      • Container_Name: nom du conteneur concerné.
      • VM_Instance_Name: nom du nœud GKE sur lequel le pod a été exécuté.
      • Reverse_Shell_Stdin_Redirection_Dst_Ip : adresse IP distante de la connexion.
      • Reverse_Shell_Stdin_Redirection_Dst_Port : port distant.
      • Reverse_Shell_Stdin_Redirection_Src_Ip : adresse IP locale de la connexion.
      • Reverse_Shell_Stdin_Redirection_Src_Port : port local.
      • Container_Image_Uri: nom de l'image de conteneur en cours d'exécution.

Étape 2 : Vérifier le cluster et le nœud

  1. Dans Cloud Console, accédez à la page des clusters Kubernetes.

    Accéder à la page "Clusters Kubernetes"

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié 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 répertorié dans resource.project_display_name, si nécessaire.

  3. Filtrez le cluster répertorié dans resource.name et l'espace de noms du pod répertorié 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 répertorié 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 à Google Cloud Console.

    Ouvrir la console Google Cloud

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié 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. Lancez une interface système dans 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.

    Pour afficher tous les processus exécutés dans le conteneur, exécutez la commande suivante dans l'interface système du conteneur :

      ps axjf
    

    L'exécution de cette commande nécessite l'installation de /bin/ps sur le conteneur.

É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 : Interpréteur de commandes et de scripts, Transfert d'outils Ingress.
  2. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

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

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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.

Unexpected Child Shell

Container Threat Detection a observé un processus qui a généré de manière inattendue un processus de shell enfant. Cet événement peut indiquer qu'un pirate informatique tente d'utiliser de manière abusive les commandes et les scripts shell.

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

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

  1. Ouvrez un résultat Unexpected Child Shell comme indiqué dans Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

    • Ce qui a été détecté, en particulier les champs suivants :
      • Processus parent: processus qui a créé de manière inattendue le processus du shell enfant.
      • Processus enfant: processus du shell enfant.
      • Arguments: les arguments fournis au shell enfant traitent le binaire.
      • Environment variables (Variables d'environnement) : variables d'environnement du binaire de processus du shell enfant.
      • Conteneurs: nom du conteneur.
      • URI du conteneur: URI de l'image du conteneur.
      • Pods Kubernetes: nom et espace de noms du pod
    • Ressource concernée, en particulier les champs suivants :
      • Nom à afficher pour la ressource: nom de la ressource concernée.
      • Nom complet de la ressource: nom complet de la ressource du cluster. Le nom complet de la ressource contient les informations suivantes :
        • Projet contenant le cluster: projects/PROJECT_ID
        • Emplacement où se trouve le cluster: zone/ZONE ou locations/LOCATION
        • Le nom du cluster: projects/CLUSTER_NAME
  3. Cliquez sur l'onglet JSON et notez les champs suivants:

+processes: tableau contenant tous les processus liés au résultat. Ce tableau inclut le processus du shell enfant et le processus parent. +resource : +project_display_name: nom du projet contenant les composants. +sourceProperties : +VM_Instance_Name: nom du nœud GKE sur lequel le pod a été exécuté.

Étape 2 : Vérifier le cluster et le nœud

  1. Dans Cloud Console, accédez à la page des clusters Kubernetes.

    Accéder à la page "Clusters Kubernetes"

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié 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 que vous avez noté dans le champ Nom complet de la ressource (resource.name) du cluster dans le résumé des résultats, si nécessaire.

  3. Cliquez sur Afficher les charges de travail du système.

  4. Filtrez la liste des charges de travail en fonction du nom du cluster que vous avez noté dans Nom complet de la ressource (resource.name) du résumé du résultat et, si nécessaire, de l'espace de noms du pod (kubernetes.pods.ns) que vous avez noté.

  5. Cliquez sur le nom de la charge de travail qui correspond à la valeur de la propriété VM_Instance_Name que vous avez notée précédemment dans le résultat JSON. La page Détails du pod s'ouvre.

  6. Sur la page Détails du pod, notez toute information concernant le pod pouvant vous aider à résoudre la menace.

É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 répertorié dans resource.project_display_name.

  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 à Google Cloud Console.

    Ouvrir la console Google Cloud

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet répertorié dans resource.project_display_name.

  3. Cliquez sur Activer Cloud Shell.

  4. Obtenez les identifiants GKE pour votre cluster en exécutant les commandes suivantes.

    Pour les clusters zonaux, exécutez la commande suivante:

      gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
    

    Pour les clusters régionaux, exécutez la commande suivante:

      gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
    
  5. Pour lancer une interface système dans l'environnement de conteneurs, exécutez 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.

    Pour afficher tous les processus exécutés dans le conteneur, exécutez la commande suivante dans l'interface système du conteneur :

      ps axjf
    

    L'exécution de cette commande nécessite l'installation de /bin/ps sur le conteneur.

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

  1. Examinez les entrées du framework MITRE ATT&CK pour le type de résultat Interpréteur de commandes et de scripts : shell Unix.
  2. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

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

Le plan de réponse suivant peut être approprié pour ce résultat, mais il peut également avoir un impact 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.

Réponse de VM Threat Detection

Pour en savoir plus sur VM Threat Detection, consultez la présentation de VM Threat Detection.

Execution: Cryptocurrency Mining Hash Match

VM Threat Detection a détecté les activités de minage de cryptomonnaie en mettant en correspondance les hachages de mémoire des programmes en cours d'exécution avec les hachages de mémoire des logiciels de minage de cryptomonnaies connus.

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

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

  1. Ouvrez un résultat Execution: Cryptocurrency Mining Hash Match, comme indiqué dans la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

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

      • Famille binaire: l'application de cryptomonnaie détectée.
      • Binaire du programme: chemin absolu du processus.
      • Arguments: arguments fournis lors de l'appel du binaire de processus.
      • Noms des processus: nom des processus exécutés dans l'instance de VM qui est associé aux correspondances de signature détectées.

      VM Threat Detection peut reconnaître les builds de noyau des principales distributions Linux. Si elle peut reconnaître la compilation du noyau de la VM concernée, elle peut identifier les détails du processus de l'application et renseigner le champ processes du résultat. Si VM Threat Detection ne peut pas reconnaître le noyau (par exemple, s'il est personnalisé), le champ processes du résultat n'est pas renseigné.

    • Ressource concernée, en particulier les champs suivants:

      • Nom complet de la ressource: nom complet de la ressource de l'instance de VM concernée, y compris l'ID du projet qui la contient.
  3. Pour afficher le JSON complet de ce résultat, dans la vue détaillée du résultat, cliquez sur l'onglet JSON.

    • indicator
      • signatures:
        • memory_hash_signature: signature correspondant aux hachages de pages de mémoire.
        • detections
          • binary: nom du binaire de l'application de cryptomonnaie (par exemple, linux--x86-64_ethminer_0.19.0_alpha.0_cuda10.0).
          • percent_pages_matched: pourcentage de pages en mémoire correspondant aux pages des applications de cryptomonnaie connues dans la base de données de hachage de pages.

Étape 2 : 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 contenant l'instance de VM, comme spécifié sur la ligne Nom complet de la ressource de l'onglet Résumé des détails du résultat.

  3. Recherchez des signes d'intrusion dans les journaux sur l'instance de VM concernée. Par exemple, recherchez les activités suspectes ou inconnues, ainsi que les signes d'identifiants compromis.

Étape 3 : 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. Cliquez sur la liste déroulante de sélection du projet située en haut de la page. Dans la fenêtre Sélectionner à partir de qui s'affiche, sélectionnez le projet identifié sur la ligne Nom complet de la ressource de l'onglet Résumé des détails du résultat.

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

  4. Cliquez sur l'instance de VM correspondant au projet identifié dans le champ Nom complet de la ressource. Vérifiez les détails de l'instance, y compris les paramètres réseau et d'accès.

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

  1. Examinez les entrées du framework MITRE ATT&CK pour Exécution.
  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 approprié pour ce résultat, mais il peut également avoir un impact 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.

Pour faciliter la détection et la suppression, utilisez une solution de détection et de gestion des points de terminaison.

  1. Contactez le propriétaire de la VM.
  2. Confirmez si l'application est une application de minage :

    • Si le nom de processus et le chemin d'accès binaire de l'application détectée sont disponibles, prenez en compte les valeurs figurant sur les lignes Programme binaire, Arguments et Noms de processus de l'onglet Résumé des détails du résultat de votre investigation.

    • Si les détails du processus ne sont pas disponibles, vérifiez si le nom binaire de la signature de hachage de la mémoire peut fournir des indices. Prenons l'exemple d'un binaire nommé linux-x86-64_xmrig_2.14.1. Vous pouvez utiliser la commande grep pour rechercher des fichiers importants dans l'espace de stockage. Utilisez une partie significative du nom binaire dans votre modèle de recherche, dans ce cas, xmrig. Examinez les résultats de recherche.

    • Examinez les processus en cours d'exécution, en particulier les processus avec une utilisation intensive du processeur, pour voir s'ils sont inconnus. Déterminez si les applications associées sont des applications de minage.

    • Recherchez dans les fichiers de l'espace de stockage les chaînes courantes utilisées par les applications de minage, telles que btc.com, ethminer, xmrig, cpuminer et randomx. Pour plus d'exemples de chaînes à rechercher, consultez la section Noms des logiciels et règles YARA et la documentation associée pour chaque logiciel répertorié.

  3. Si vous considérez que l'application est une application mineure et que son processus est toujours en cours d'exécution, arrêtez-le. Recherchez le binaire exécutable de l'application dans l'espace de stockage de la VM, puis supprimez-le.

  4. Si nécessaire, arrêtez l'instance compromise et remplacez-la par une nouvelle instance.

Execution: Cryptocurrency Mining YARA Rule

VM Threat Detection a détecté des activités de minage de cryptomonnaie en faisant correspondre des modèles de mémoire, tels que les constantes de démonstration de faisabilité, connues pour être utilisées par les logiciels de minage de cryptomonnaie.

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

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

  1. Ouvrez un résultat Execution: Cryptocurrency Mining YARA Rule, comme indiqué dans Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Summary (Résumé).

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

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

      • YARA policy name (Nom de la règle YARA) : règle déclenchée pour les détecteurs YARA.
      • Binaire du programme: chemin absolu du processus.
      • Arguments: arguments fournis lors de l'appel du binaire de processus.
      • Noms des processus: nom des processus exécutés dans l'instance de VM qui est associé aux correspondances de signature détectées.

      VM Threat Detection peut reconnaître les builds de noyau des principales distributions Linux. Si elle peut reconnaître la compilation du noyau de la VM concernée, elle peut identifier les détails du processus de l'application et renseigner le champ processes du résultat. Si VM Threat Detection ne peut pas reconnaître le noyau (par exemple, s'il est personnalisé), le champ processes du résultat n'est pas renseigné.

    • Ressource concernée, en particulier les champs suivants:

      • Nom complet de la ressource: nom complet de la ressource de l'instance de VM concernée, y compris l'ID du projet qui la contient.
    • 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.
      • Chronicle: lien vers Chronicle.
  3. Pour afficher le JSON complet de ce résultat, dans la vue détaillée 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.

    Accéder à l'explorateur de journaux

  2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet contenant l'instance de VM, comme spécifié sur la ligne Nom complet de la ressource de l'onglet Résumé des détails du résultat.

  3. Recherchez des signes d'intrusion dans les journaux sur l'instance de VM concernée. Par exemple, recherchez les activités suspectes ou inconnues, ainsi que les signes d'identifiants compromis.

Étape 3 : 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. Cliquez sur la liste déroulante de sélection du projet située en haut de la page. Dans la fenêtre Sélectionner à partir de qui s'affiche, sélectionnez le projet inclus dans le nom de ressource indiqué sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat.

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

  4. Cliquez sur l'instance de VM correspondant à resourceName. Vérifiez les détails de l'instance, y compris les paramètres réseau et d'accès.

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

  1. Examinez les entrées du framework MITRE ATT&CK pour Exécution.
  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 approprié pour ce résultat, mais il peut également avoir un impact 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.

Pour faciliter la détection et la suppression, utilisez une solution de détection et de gestion des points de terminaison.

  1. Contactez le propriétaire de la VM.
  2. Confirmez si l'application est une application de minage :

    • Si le nom de processus et le chemin d'accès binaire de l'application détectée sont disponibles, prenez en compte les valeurs figurant sur les lignes Programme binaire, Arguments et Noms de processus de l'onglet Résumé des détails du résultat de votre investigation.

    • Examinez les processus en cours d'exécution, en particulier les processus avec une utilisation intensive du processeur, pour voir s'ils sont inconnus. Déterminez si les applications associées sont des applications de minage.

    • Recherchez dans les fichiers de l'espace de stockage les chaînes courantes utilisées par les applications de minage, telles que btc.com, ethminer, xmrig, cpuminer et randomx. Pour plus d'exemples de chaînes à rechercher, consultez la section Noms des logiciels et règles YARA et la documentation associée pour chaque logiciel répertorié.

  3. Si vous considérez que l'application est une application mineure et que son processus est toujours en cours d'exécution, arrêtez-le. Recherchez le binaire exécutable de l'application dans l'espace de stockage de la VM, puis supprimez-le.

  4. Si nécessaire, arrêtez l'instance compromise et remplacez-la par une nouvelle instance.

Execution: cryptocurrency mining combined detection

VM Threat Detection a détecté plusieurs catégories de résultats au cours d'une même journée à partir d'une source unique. Une même application peut déclencher simultanément Execution: Cryptocurrency Mining YARA Rule et Execution: Cryptocurrency Mining Hash Match findings.

Pour répondre à un résultat combiné, suivez les instructions de réponse pour Execution: Cryptocurrency Mining YARA Rule et Execution: Cryptocurrency Mining Hash Match findings.

Pour éviter la récurrence des menaces, examinez et corrigez les résultats de failles et d'erreurs de configuration associées.

Pour rechercher des résultats associés, procédez comme suit:

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

    Accéder

  2. Examinez le résultat de la menace et copiez la valeur d'un attribut susceptible d'apparaître dans toute faille associée ou tout résultat d'erreur de configuration, comme l'adresse e-mail principale ou le nom de la ressource concernée.

  3. Sur la page Résultats, ouvrez l'éditeur de requête en cliquant sur Modifier la requête.

  4. Cliquez sur Ajouter un filtre. Le menu Sélectionner un filtre s'ouvre.

  5. Dans la liste des catégories de filtres à gauche du menu, sélectionnez la catégorie contenant l'attribut que vous avez noté dans le résultat de la menace.

    Par exemple, si vous avez noté le nom complet de la ressource concernée, sélectionnez Ressource. Les types d'attributs de la catégorie Ressource sont affichés dans la colonne de droite, y compris l'attribut Nom complet.

  6. Dans les attributs affichés, sélectionnez le type d'attribut que vous avez noté dans le résultat de la menace. Un panneau de recherche des valeurs d'attribut s'ouvre sur la droite et affiche toutes les valeurs trouvées pour le type d'attribut sélectionné.

  7. Dans le champ Filtrer, collez la valeur d'attribut que vous avez copiée à partir du résultat de la menace. La liste des valeurs affichée est mise à jour pour n'afficher que les valeurs correspondant à la valeur collée.

  8. Dans la liste des valeurs affichées, sélectionnez une ou plusieurs valeurs, puis cliquez sur Appliquer. Le panneau Résultats de la requête de résultats est actualisé pour n'afficher que les résultats correspondants.

  9. Si les résultats comportent beaucoup de résultats, filtrez-les en sélectionnant des filtres supplémentaires dans le panneau Filtres rapides.

    Par exemple, pour n'afficher que les résultats des classes Vulnerability et Misconfiguration contenant les valeurs d'attribut sélectionnées, faites défiler la page jusqu'à la section Classe de résultat du panneau Filtres rapides, puis sélectionnez Vulnérabilité et Erreur de configuration.

Outre les indicateurs de compromission fournis par Google, les utilisateurs clients de Palo Alto Networks peuvent intégrer la fonctionnalité AutoFocus Threat Intelligence de Palo Alto Networks à la solution Event Threat Detection. AutoFocus est un service de renseignements sur les menaces qui fournit des informations sur les menaces réseau. Pour en savoir plus, consultez la page AutoFocus dans la console Google Cloud.

Résoudre les menaces

La résolution des problèmes liés à Event Threat Detection et Container Threat Detection ne consiste pas seulement à corriger les erreurs de configuration et les failles identifiées par Security Command Center.

Les erreurs de configuration et les violations de conformité identifient les faiblesses des ressources qui pourraient être exploitées. En règle générale, les erreurs de configuration ont des correctifs connus et facilement mis en œuvre, tels que l'activation d'un pare-feu ou la rotation d'une clé de chiffrement.

Les menaces diffèrent des failles dans la mesure où elles sont dynamiques et indiquent une exploitation active possible sur une ou plusieurs ressources. Une recommandation de correction peut ne pas être efficace pour sécuriser vos ressources, car les méthodes exactes utilisées pour exploiter la faille peuvent ne pas être connues.

Par exemple, un résultat Added Binary Executed indique qu'un binaire non autorisé a été lancé dans un conteneur. Une recommandation de correction de base peut vous conseiller de mettre le conteneur en quarantaine et de supprimer le binaire, mais cela peut ne pas résoudre la cause racine sous-jacente qui a permis à l'attaquant d'exécuter le binaire. Vous devez déterminer comment l'image du conteneur a été corrompue pour corriger l'exploitation. Pour déterminer si le fichier a été ajouté via un port mal configuré ou par un autre moyen, une enquête approfondie est nécessaire. Il peut s'avérer nécessaire de demander à un analyste ayant des connaissances approfondies de votre système d'en examiner les faiblesses.

Les acteurs malveillants attaquent des ressources à l'aide de différentes techniques. Par conséquent, l'application d'un correctif pour une attaque spécifique peut ne pas être efficace contre les variantes de cette attaque. Par exemple, en réponse à un résultat Brute Force: SSH, vous pouvez réduire les niveaux d'autorisation pour certains comptes utilisateur afin de limiter l'accès aux ressources. Toutefois, un mot de passe peu sécurisé peut tout de même fournir un vecteur d'attaque.

L'ampleur des vecteurs d'attaque ne permet pas de fournir des mesures correctives qui fonctionnent dans toutes les situations. Dans votre plan de sécurité cloud, Security Command Center identifie les ressources concernées quasiment en temps réel, vous indique les menaces auxquelles vous faites face et vous fournit des preuves et du contexte pour vous aider dans vos recherches. Toutefois, votre personnel de sécurité doit utiliser les informations détaillées des résultats de Security Command Center afin de déterminer les meilleurs moyens de résoudre les failles et de protéger les ressources contre les attaques futures.

Étapes suivantes