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

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

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

Examiner les résultats

Pour examiner les résultats des 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.

   

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ésultat. Par exemple, si vous sélectionnez Event Threat Detection ou Container Threat Detection dans la sous-section Nom à afficher 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.

Pour un faux positif, envisagez de conserver l'état du résultat ACTIVE et d'ignorer à la place le résultat.

Pour les faux positifs persistants ou récurrents, créez une règle de masquage. 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 terminez une enquête approfondie sur la menace détectée, l'étendue de l'intrusion et tout autre constat et problème associé.

Pour ignorer un résultat ou modifier son état, consultez les articles suivants:

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

Réponses Event Threat Detection

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

Cette section ne contient pas de réponses aux résultats générés par les 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 la section Examiner les résultats. Le panneau des détails du résultat s'ouvre, affichant l'onglet Résumé.

2. Dans l'onglet Résumé du panneau des détails du résultat, examinez les valeurs indiquées dans les sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du compte principal: compte qui a 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 :
     • Cloud Logging URI (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 des champs de résultat supplémentaires.

É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

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Breakglass Workload Deployment Created est détecté en examinant Cloud Audit Logs pour déterminer s'il existe des déploiements dans des charges de travail qui utilisent l'option "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 la section Examiner les résultats. Le panneau des détails du résultat s'ouvre, affichant l'onglet Summary (Résumé).

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du compte principal: compte qui a effectué la modification.
     • Method name (Nom de la méthode) : méthode appelée.
     • Pods Kubernetes: nom du pod et espace de noms
   • Ressource concernée, en particulier le champ suivant :
     • Nom à afficher pour la ressource: espace de noms GKE dans lequel le déploiement a eu lieu.
   • Liens associés :
     • Cloud Logging URI (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 de la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.
2. Vérifiez la valeur du champ protoPayload.resourceName pour identifier la requête de signature de certificat spécifique.

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

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Remplacez les éléments suivants :

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

   • PRINCIPAL_EMAIL: valeur que vous avez notée dans le champ Adresse e-mail du compte principal des détails du 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 (Évitement de défense : déploiement de la charge de travail en mode "bris de glace").
2. Examinez les résultats associés en cliquant sur le lien 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

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Breakglass Workload Deployment Updated est détecté en examinant Cloud Audit Logs pour déterminer s'il existe des mises à jour des charges de travail qui utilisent l'option "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 la section Examiner les résultats. Le panneau des détails du résultat s'ouvre, affichant l'onglet Summary (Résumé).

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du compte principal: compte qui a effectué la modification.
     • Method name (Nom de la méthode) : méthode appelée.
     • Pods Kubernetes: nom du pod et espace de noms
   • Ressource concernée, en particulier le champ suivant :
     • Nom à afficher pour la ressource: espace de noms GKE dans lequel la mise à jour a eu lieu.
   • Liens associés :
     • Cloud Logging URI (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 de la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.
2. Vérifiez la valeur du champ protoPayload.resourceName pour identifier la requête de signature de certificat spécifique.

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

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Remplacez les éléments suivants :

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

   • PRINCIPAL_EMAIL: valeur que vous avez notée dans le champ Adresse e-mail du compte principal des détails du 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 (Évitement de défense : déploiement de la charge de travail en mode "bris de glace").
2. Examinez les résultats associés en cliquant sur le lien 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, ce qui entraînerait une réduction de la protection offerte par ces périmètres. Voici quelques exemples :

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

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

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

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

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier le champ suivant :
     • Adresse e-mail du compte principal: compte qui a effectué la modification.
   • Ressource concernée, en particulier le champ suivant :
     • Nom complet de la ressource: nom du périmètre VPC Service Controls qui a été modifié.
   • Liens associés :
     • Cloud Logging URI (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: les modifications, REMOVE ou ADD, sur un périmètre ayant 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 des activités 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 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 individu potentiellement malveillant a tenté de déterminer les objets sensibles dans GKE qu'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 des résultats, dans l'onglet Résumé, notez les valeurs des champs suivants:

   • Sous Ce qui a été détecté :
     • Examens d'accès Kubernetes: informations sur les examens d'accès demandés, basées sur la ressource k8s SelfSubjectAccessReview.
     • Adresse e-mail du compte principal: compte qui a passé l'appel.
   • Sous Ressource concernée :
     • Nom à afficher pour la ressource: cluster Kubernetes dans lequel l'action s'est produite.
   • Sous Liens associés :
     • Cloud Logging URI (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 d'autres actions effectuées par le compte principal à l'aide des filtres suivants:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Remplacez les éléments suivants :

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

   • PRINCIPAL_EMAIL: valeur que vous avez notée dans le champ Adresse e-mail du compte principal des détails du 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. Vérifiez le degré de sensibilité de l'objet interrogé et déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux.

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

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

4. Pour élaborer un plan d'intervention, combinez les résultats de votre investigation 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 un niveau de gravité différent:

• Sous-règle exfil_to_external_table dont la gravité est définie sur HIGH :
  • Une ressource a été enregistrée en dehors de votre organisation ou de votre projet.
• Sous-règle vpc_perimeter_violation dont la gravité est définie sur 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 la section Examiner les résultats.

2. Dans l'onglet Résumé du panneau des détails du résultat, examinez les valeurs répertoriées dans les sections suivantes:

   • Ce qui a été détecté :
     • Gravité: la gravité est définie sur HIGH pour la sous-règle exfil_to_external_table ou sur LOW pour la sous-règle vpc_perimeter_violation.
     • Adresse e-mail du compte principal: compte utilisé pour exfiltrer les données.
     • Sources d'exfiltration: détails 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 ont été stockées.
   • Ressource concernée :
     • Nom complet de la ressource: nom complet de la ressource du projet, du dossier ou de l'organisation à partir duquel les données ont été exfiltrées.
   • Liens associés :
     • Cloud Logging URI (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 Google SecOps.

3. Cliquez sur l'onglet Propriétés sources et vérifiez 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é les 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 afficher la liste complète des propriétés JSON du résultat.

Étape 2: Enquêtez sur Google Security Operations

Vous pouvez utiliser Google Security Operations pour examiner ce résultat. Google SecOps est un service Google Cloud qui vous permet d'examiner les menaces et de passer d'une entité associée à une autre dans un calendrier unifié. Google SecOps enrichit les données de résultats, ce qui vous permet d'identifier les indicateurs intéressants et de simplifier les investigations.

Vous ne pouvez utiliser Google SecOps 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 jusqu'à Nom à afficher pour la source.

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

   La table se remplit avec 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 Examiner dans Chronicle.

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

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

• Examiner un utilisateur
• Examiner un élément

É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 résultat JSON.

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

Étape 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 associé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 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 pour userEmail jusqu'à ce que l'enquête soit terminée.
• Pour mettre fin à une exfiltration plus approfondie, ajoutez des stratégies IAM restrictives aux ensembles de données BigQuery concernés (exfiltration.sources et exfiltration.targets).
• Pour analyser les ensembles de données concernés afin d'y rechercher des informations sensibles, utilisez Sensitive Data Protection. Vous pouvez également envoyer des données de protection des données sensibles à Security Command Center. Selon la quantité d'informations, les coûts liés à la protection des données sensibles peuvent s'avérer importants. Suivez les bonnes pratiques pour maîtriser les coûts liés à Sensitive Data Protection.
• Pour limiter l'accès à l'API BigQuery, utilisez VPC Service Controls.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Exfiltration: BigQuery Data Extraction

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

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

Pour les activations du niveau Premium de Security Command Center au niveau 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 Résumé.

2. Dans l'onglet Résumé du panneau des détails du résultat, examinez les valeurs répertoriées dans les sections suivantes:

   • Ce qui a été détecté :
     • Adresse e-mail du compte principal: compte utilisé pour exfiltrer les données.
     • Sources d'exfiltration: détails 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 ont été stockées.
   • Ressource concernée :
     • Nom complet de la ressource: nom de la ressource BigQuery dont les données ont été exfiltrées.
     • Nom complet du projet: projet Google Cloud contenant l'ensemble de données BigQuery source.
   • Liens associés :
     • Cloud Logging URI (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é les 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 résultat JSON (à l'étape 1).

3. Sur la page qui s'affiche, dans la zone Filtre, saisissez l'adresse e-mail indiquée dans Adresse e-mail du compte principal (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 de la ligne Résultats associés dans 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 éviter toute exfiltration supplémentaire, ajoutez des stratégies IAM restrictives aux ensembles de données BigQuery concernés qui sont identifiés dans le champ Sources d'exfiltration de l'onglet Résumé des détails des résultats.
• Pour analyser les ensembles de données concernés afin d'y rechercher des informations sensibles, utilisez Sensitive Data Protection. Vous pouvez également envoyer des données de protection des données sensibles à Security Command Center. Selon la quantité d'informations, les coûts liés à la protection des données sensibles peuvent s'avérer importants. Suivez les bonnes pratiques pour maîtriser les coûts liés à Sensitive Data Protection.
• Pour limiter l'accès à l'API BigQuery, utilisez VPC Service Controls.
• Si vous êtes le propriétaire du bucket, envisagez de révoquer les autorisations d'accès public.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Exfiltration: BigQuery Data to Google Drive

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

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

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

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

1. Ouvrez un résultat Exfiltration: BigQuery Data to Google Drive, tel qu'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 du compte principal: compte utilisé pour exfiltrer les données.
     • Sources d'exfiltration: informations sur 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 :
     • Cloud Logging URI (URI Cloud Logging) : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
     • Résultats associés: liens vers les résultats associés.

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

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

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

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

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

   Accéder à IAM

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

3. Sur la page qui s'affiche, dans la zone Filtre, 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 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 des autorisations du compte principal dans le champ access.principalEmail jusqu'à la fin de l'enquête.
• Pour mettre fin à une exfiltration plus approfondie, ajoutez des stratégies IAM restrictives aux ensembles de données BigQuery concernés (exfiltration.sources).
• Pour analyser les ensembles de données concernés afin d'y rechercher des informations sensibles, utilisez Sensitive Data Protection. Vous pouvez également envoyer des données de protection des données sensibles à Security Command Center. Selon la quantité d'informations, les coûts liés à la protection des données sensibles peuvent s'avérer importants. Suivez les bonnes pratiques pour maîtriser les coûts liés à Sensitive Data Protection.
• Pour limiter l'accès à l'API BigQuery, utilisez VPC Service Controls.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Exfiltration: Cloud SQL Data Exfiltration

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

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

Tous les types d'instances Cloud SQL sont compatibles.

Pour les activations du niveau Premium de Security Command Center au niveau 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 Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du compte principal : compte utilisé pour exfiltrer les données.
     • Sources d'exfiltration: informations sur 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 :
     • Cloud Logging URI (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 contenant l'instance Cloud SQL source.
     • properties
     • bucketAccess : indique si le bucket Cloud Storage est accessible au public ou externe à l'organisation.
     • exportScope: quantité de données exportée, telle que l'ensemble de l'instance, une ou plusieurs bases de données, une ou plusieurs tables, ou un sous-ensemble spécifié par une requête)

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

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

   Accéder à IAM

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

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

Étape 3 : Vérifier les journaux

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

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

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service: Exfiltration to Cloud Storage (Exfiltration via service Web : Exfiltration vers Cloud Storage).
2. Examinez les résultats associés en cliquant sur le lien de la ligne Résultats associés décrit à l'étape 1. Les résultats associés présentent 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 pour access.principalEmail jusqu'à ce que l'enquête soit terminée.
• Pour mettre fin à toute exfiltration, ajoutez des stratégies IAM restrictives sur les instances Cloud SQL concernées.
  • MySQL
  • PostgreSQL
  • SQL Server
• Pour limiter l'accès à l'API Cloud SQL Admin et au module d'exportation, utilisez VPC Service Controls.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Exfiltration: Cloud SQL Restore Backup to External Organization

L'exfiltration de données d'une sauvegarde Cloud SQL est détectée en examinant les journaux d'audit 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, examinez les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du compte principal: compte utilisé pour exfiltrer les données.
     • Sources d'exfiltration: informations sur l'instance Cloud SQL à partir de laquelle la sauvegarde a été créée.
     • Cibles d'exfiltration: informations sur 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 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:

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

4. Cliquez sur l'onglet JSON.

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

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

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

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

   Accéder à IAM

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

3. Sur la page qui s'affiche, dans la zone Filtre, saisissez l'adresse e-mail indiquée dans Adresse e-mail du compte principal (issue 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 dans l'URI Cloud Logging (de l'étape 1). La page Explorateur de journaux inclut tous les journaux liés à l'instance Cloud SQL concernée.

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

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service: Exfiltration to Cloud Storage (Exfiltration via service Web : Exfiltration vers Cloud Storage).
2. Examinez les résultats associés en cliquant sur le lien de la ligne Résultats associés. (voir 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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.
• Vous pouvez envisager 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.
  • MySQL
  • PostgreSQL
  • SQL Server
• Pour limiter l'accès à l'API Cloud SQL Admin, utilisez VPC Service Controls.
• Pour identifier et corriger les rôles trop permissifs, utilisez l'outil de recommandation IAM.

Exfiltration: Cloud SQL Over-Privileged Grant

Détecte les cas où tous les droits sur une base de données PostgreSQL (ou toutes les fonctions ou procédures d'une base de données) sont accordés à un ou plusieurs utilisateurs de 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é des droits excédentaires
     • Database query (Requête de base de données) : requête PostgreSQL exécutée qui a accordé les privilèges.
     • Bénéficiaires de la base de données: bénéficiaires des droits 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 la 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 :
     • Cloud Logging URI (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 indiquée dans la section Nom à afficher de la base de données (à l'étape 1).
   • Fonctions ou procédures. Utilisez la métacommande \df et vérifiez les droits attribués aux fonctions ou procédures de la base de données répertoriées dans la section Nom à afficher de la base de données (étape 1).

Étape 3 : Vérifier les journaux

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

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

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

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

Le plan d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 la section Bénéficiaires de la base de données jusqu'à ce que l'investigation soit terminée.
• Pour limiter l'accès à la base de données (à partir du Nom à afficher de la base de données de l'étape 1, revoke les autorisations inutiles des bénéficiaires (voir Bénéficiaires de la base de données de l'étape 1).

Initial Access: Database Superuser Writes to User Tables

Détecte les cas où 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 (rôle doté d'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 utilisateur, cela peut indiquer qu'un pirate informatique a élevé des privilèges ou qu'il a compromis l'utilisateur de base de données par défaut et qu'il modifie les 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) : le super-utilisateur.
     • Database query (Requête de base de données) : requête SQL exécutée lors de l'écriture dans des tables utilisateur.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource: nom de ressource de l'instance Cloud SQL affectée.
     • Nom complet du parent: nom de ressource de l'instance Cloud SQL.
     • Nom complet du projet: projet Google Cloud contenant l'instance Cloud SQL.
   • Liens associés, en particulier les champs suivants :
     • Cloud Logging URI (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. Recherchez les journaux pgaudit de PostgreSQL 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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.

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

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

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

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

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

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

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

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

Initial Access: Anonymous GKE resource created from the internet

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Détecte les cas où un individu 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 qu'elle est nécessaire. Si la liaison n'est pas nécessaire, supprimez-la. Pour en savoir plus, consultez le message de journal de ce résultat.

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

Initial Access: GKE resource modified anonymously from the internet

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Détecte les cas où un individu 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 qu'elle est nécessaire. Si la liaison n'est pas nécessaire, supprimez-la. Pour en savoir plus, consultez le message de journal de ce résultat.

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

Initial Access: Dormant Service Account Action

Détecte les événements où 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 des résultats, dans l'onglet Résumé, notez les valeurs des champs suivants.

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

   • Principal email (Adresse e-mail du compte principal) : compte de service dormant qui a effectué l'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) : la 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 dormant.
2. Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez que le propriétaire légitime est bien à l'origine de l'action.

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

Le plan d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 pour lequel l'action a été effectuée.
• Envisagez de supprimer le compte de service potentiellement compromis, puis d'alterner et de 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 leur accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les applications concernées et collaborer avec leurs propriétaires pour assurer la continuité de l'activité.
• 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 où 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 des résultats, dans l'onglet Résumé, notez les valeurs des champs suivants.

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

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

   Sous Ressource concernée:

   • Resource display name (Nom à afficher pour la ressource) : la clé du compte de service dormant nouvellement créée
   • Nom complet du projet: projet où se trouve le compte de service dormant

É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 dormant.
2. Contactez le propriétaire du champ Adresse e-mail du compte principal. Confirmez que le propriétaire légitime est bien à l'origine de l'action.

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

Le plan d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 pour lequel l'action a été effectuée.
• Supprimez l'accès du propriétaire de l'adresse e-mail du compte principal si l'adresse e-mail est compromise.
• Invalidez la clé de compte de service nouvellement créée sur la page Comptes de service.
• Envisagez de supprimer le compte de service potentiellement compromis, puis d'alterner et de 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 leur accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les applications concernées et collaborer avec leurs propriétaires pour assurer la continuité de l'activité.
• 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 une clé 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 des résultats, dans l'onglet Résumé, notez les valeurs des champs suivants.

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

   • Adresse e-mail du compte principal: compte de service utilisé pour 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 associée à l'action.
   • Service account key name (Nom de la clé de compte de service) : clé de compte de service divulguée utilisée pour authentifier cette action
   • Description: description de ce qui a été détecté, y compris l'emplacement sur l'Internet public où se trouve la clé du compte de service

   Sous Ressource concernée:

   • Resource display name (Nom à afficher de 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 l'URI Cloud Logging.
2. Dans la barre d'outils de la console Google Cloud, sélectionnez votre projet ou votre organisation.

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

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

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

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

Le plan d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 sur lesquels 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 leur accès. Avant de les supprimer, votre équipe de sécurité doit identifier toutes les applications concernées et collaborer avec leurs propriétaires pour assurer la continuité de l'activité.
• 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 de manière répétée 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 des résultats, dans l'onglet Résumé, notez les valeurs des champs suivants.

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

   • Adresse e-mail du compte principal: le compte principal ayant déclenché plusieurs erreurs d'autorisation refusée
   • Service name (Nom du service) : nom de l'API du service Google Cloud pour lequel la dernière erreur d'autorisation refusée s'est produite
   • Method name (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 à laquelle l'erreur s'est produite pour la dernière fois. Un maximum de 10 entrées est affiché.

Étape 2 : Vérifier les journaux

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

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

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

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

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

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

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

Le plan d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 a effectué l'action.
• supprimer les ressources de projet créées par ce compte, telles que les instances Compute Engine inconnues, les instantanés, les comptes de service, les utilisateurs IAM, etc.
• 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 à l'origine de l'attaque.
     • Nom d'utilisateur: le compte avec lequel vous vous êtes connecté.

   • Ressource concernée

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

     • Cloud Logging URI (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 Google SecOps.

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: Enquêtez sur Google Security Operations

Vous pouvez utiliser Google Security Operations pour examiner ce résultat. Google SecOps est un service Google Cloud qui vous permet d'examiner les menaces et de passer d'une entité associée à une autre dans un calendrier facile à utiliser. Google SecOps enrichit les données de résultats, ce qui vous permet d'identifier les indicateurs intéressants et de simplifier les investigations.

Vous ne pouvez utiliser Google SecOps 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 jusqu'à Nom à afficher pour la source.

3. Dans la section Nom à afficher pour 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 des détails du résultat s'ouvre.

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

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

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

• Examiner un utilisateur
• Examiner une adresse IP
• Examiner un élément

É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. Sélectionnez le projet spécifié dans projectId.

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

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

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

Étape 4 : Vérifier les journaux

1. Dans la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans l'URI Cloud Logging.
2. Sur la page qui s'affiche, recherchez les journaux de flux VPC associés à l'adresse IP répertoriée sur la ligne Adresse e-mail du compte principal dans 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. Consultez les résultats associés en cliquant sur le lien 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 des détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du compte principal: compte ayant effectué les modifications
   • Ressource concernée
   • Liens associés, en particulier les champs suivants :
     • Cloud Logging URI (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.

   

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

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du compte principal: compte qui a apporté les modifications susceptibles d'être piratées.
   • Ressource concernée
   • Liens associés, en particulier les champs suivants :
     • Cloud Logging URI (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.

   

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

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Détecte les cas où 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 avez explicitement accordé cet accès à l'aide d'un objet Role ou 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 Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du compte principal: compte qui a apporté les modifications susceptibles d'être piratées.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource: la ressource pour laquelle le nouveau rôle a été attribué.
   • Liens associés, en particulier les champs suivants :
     • Cloud Logging URI (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 que vous venez d'ajouter 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.

   

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 Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse IP source: adresse IP suspectée de minage de cryptomonnaie.
     • Port source: port source de la connexion, si disponible.
     • Adresse IP de destination: l'adresse IP cible.
     • Port de destination: port de destination de la connexion, le cas échéant.
     • Protocol (Protocole) : le protocole IANA associé à la connexion.
   • Ressource concernée
   • Liens associés, y compris les champs suivants :
     • Logging URI (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 le champ properties, puis notez les valeurs du projet et de l'instance dans les champs suivants:

   • 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 indiqué 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. Sélectionnez le projet spécifié dans properties_project_id.

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

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

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

Étape 3 : Vérifier les journaux

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

   Accéder à l'explorateur de journaux

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

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

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

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

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

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

Le plan d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 des détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

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

   • Dans le fichier JSON, notez les champs suivants.

   • properties

     • loadBalancerName: nom de l'équilibreur de charge ayant reçu la recherche JNDI
     • requestUrl : URL de la requête HTTP. 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 figurant dans le champ Cloud Logging URI (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 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 correspondent au même type de résultat, ainsi qu'à la même instance et au 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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.

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

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 Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté
   • Ressource concernée, en particulier le champ suivant :
     • Nom complet de la ressource: nom complet de la ressource de l'instance Compute Engine vulnérable à la RCE Log4j.
   • Liens associés, en particulier les champs suivants :
     • Cloud Logging URI (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 où 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 figurant dans le champ Cloud Logging URI (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 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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.

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

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

2. Dans l'onglet Résumé, passez en revue 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 associé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 la recherche de logiciels malveillants. 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 Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Domaine de l'indicateur: pour les résultats Bad domain, il s'agit du domaine qui a déclenché le résultat.
     • Adresse IP de l'indicateur: pour les résultats Bad IP, adresse IP qui a déclenché le résultat.
     • Adresse IP source: pour les résultats Bad IP, adresse IP de contrôle et de commande de logiciel malveillant connue.
     • Port source: pour les résultats Bad IP, il s'agit du port source de la connexion.
     • Adresse IP de destination: pour les résultats Bad IP, adresse IP cible du logiciel malveillant.
     • Port de destination: port de destination de la connexion pour les résultats Bad IP.
     • Protocole: pour les résultats Bad IP, numéro de protocole IANA associé à la connexion.
   • Ressource concernée, en particulier les champs suivants :
     • Resource full name (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 :
     • Cloud Logging URI (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 Google SecOps.
     • 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: Enquêtez sur Google Security Operations

Vous pouvez utiliser Google Security Operations pour examiner ce résultat. Google SecOps est un service Google Cloud qui vous permet d'examiner les menaces et de passer d'une entité associée à une autre dans un calendrier facile à utiliser. Google SecOps enrichit les données de résultats, ce qui vous permet d'identifier les indicateurs intéressants et de simplifier les investigations.

Vous ne pouvez utiliser Google SecOps 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 jusqu'à Nom à afficher pour la source.

3. Dans la section Nom à afficher pour 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 des détails du résultat s'ouvre.

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

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

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

• Examiner une adresse IP
• Examiner un élément

É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. Sélectionnez le projet spécifié 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 à l'aide du filtre suivant:

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

     Remplacez les éléments suivants :

     • PROJECT_ID en sélectionnant 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 résultats.

É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 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. Vérifiez les URL et les domaines signalés sur VirusTotal en cliquant sur le lien dans 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté
     • 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 :
     • Cloud Logging URI (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. Sélectionnez le projet spécifié dans sourceInstanceDetails.

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

4. Cliquez sur l'instance de VM correspondant au nom de l'instance et à la zone 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 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 du projet depuis 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 répertorie toutes les sous-règles possibles et leur niveau de gravité:

• external_service_account_added_to_policy:
  • HIGH, si un rôle très sensible a été accordé ou si un rôle à sensibilité moyenne a été accordé au niveau de l'organisation. Pour en savoir plus, consultez la section Rôles très sensibles.
  • MEDIUM, si un rôle de sensibilité moyenne a été accordé. Pour en savoir plus, consultez la section Rôles à sensibilité moyenne.
• external_member_invited_to_policy : HIGH
• external_member_added_to_policy:
  • HIGH, si un rôle très sensible a été accordé ou si un rôle à sensibilité moyenne a été accordé au niveau de l'organisation. Pour en savoir plus, consultez la section Rôles très sensibles.
  • MEDIUM, si un rôle de sensibilité moyenne a été accordé. Pour en savoir plus, consultez la section Rôles à 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 Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

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

   • Ressource concernée

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

     • Cloud Logging URI (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 Google SecOps.

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'attribution anonyme qui a eu lieu. La sous-règle détermine la classification de la 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: Enquêtez sur Google Security Operations

Vous pouvez utiliser Google Security Operations pour examiner ce résultat. Google SecOps est un service Google Cloud qui vous permet d'examiner les menaces et de passer d'une entité associée à une autre dans un calendrier facile à utiliser. Google SecOps enrichit les données de résultats, ce qui vous permet d'identifier les indicateurs intéressants et de simplifier les investigations.

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 jusqu'à Nom à afficher pour la source.

3. Dans la section Nom à afficher pour 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 Examiner dans Chronicle.

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

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

• Examiner un utilisateur
• Examiner un élément

É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 de la ligne Résultats associés dans l'onglet Résumé des détails du résultat. Les résultats associés correspondent au même type de résultat, ainsi qu'à la même instance et au 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 où un rôle d'emprunt d'identité est attribué à un compte principal qui lui permet d'usurper l'identité d'un compte de service géré par l'utilisateur inactif. Dans ce résultat, le compte de service dormant est la ressource affectée, et un compte de service est considéré comme dormant s'il est inactif depuis plus de 180 jours.

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

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

1. Ouvrez le résultat Persistence: Impersonation Role Granted for Dormant Service Account, comme indiqué dans la section Examiner les résultats.

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

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

   • Adresse e-mail du compte principal: utilisateur ayant effectué l'action d'attribution
   • Accords d'accès incriminés.Nom principal: le compte principal auquel le rôle d'emprunt d'identité a été attribué

   Sous Ressource concernée:

   • Nom à afficher pour la ressource: le compte de service dormant en tant que ressource
   • Nom complet du projet: projet où se trouve le compte de service dormant

É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 dormant.
2. Contactez le propriétaire du champ Adresse e-mail du compte principal. Confirmez que le propriétaire légitime est bien à 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 pour lequel l'action a été effectuée.
• Supprimez l'accès du propriétaire de l'adresse e-mail du compte principal si l'adresse e-mail est compromise.
• Supprimez le rôle d'emprunt d'identité nouvellement attribué du membre cible.
• Envisagez de supprimer le compte de service potentiellement compromis, puis d'alterner et de 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 leur accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les applications concernées et collaborer avec leurs propriétaires pour assurer la continuité de l'activité.
• 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

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Détecte les événements lorsqu'un rôle sensible est attribué à un compte non géré Les administrateurs système ne peuvent pas contrôler les comptes non gérés. Par exemple, lorsque l'employé correspondant a quitté l'entreprise, l'administrateur ne peut pas supprimer le compte. Par conséquent, l'attribution de rôles sensibles à des comptes non gérés présente 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 des résultats, dans l'onglet Résumé, notez les valeurs des champs suivants.

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

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

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

1. Contactez le propriétaire du champ Adresse e-mail du compte principal. Confirmez que le propriétaire légitime est bien à l'origine de l'action.
2. Contactez le propriétaire du champ Offending access grants.Principal name (Nom principal des autorisations d'accès incriminés) pour bien comprendre 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 pour lequel l'action a été effectuée.
• Supprimez l'accès du propriétaire de l'adresse e-mail du compte principal si l'adresse e-mail est compromise.
• 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 de déplacer ce compte sous le contrôle des administrateurs système.

Persistence: New API Method

Une activité d'administration anormale de la part d'un acteur potentiellement malveillant a été détectée dans une organisation, un dossier ou un projet. Une activité anormale peut se présenter sous l'une des formes suivantes:

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

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

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

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

   • Sous Ce qui a été détecté :
     • Adresse e-mail du compte principal: compte qui a passé l'appel
     • Nom du service: nom de l'API du service Google Cloud utilisé dans l'action
     • Method name (Nom de la méthode) : la méthode appelée
   • Sous Ressource concernée :
     • Nom à afficher pour la ressource: 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. Déterminez si l'action était justifiée dans l'organisation, le dossier ou le projet, et si elle a été entreprise par le propriétaire légitime du compte. L'organisation, le dossier ou le projet s'affiche sur la ligne Chemin d'accès à 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 votre investigation avec la recherche 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 du résultat plus tôt sur cette page. Le panneau des détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

• Ce qui a été détecté, en particulier les champs suivants :
  • Adresse e-mail du compte principal: compte utilisateur potentiellement piraté.
• Ressource concernée, en particulier les champs suivants :
  • Nom complet du projet: projet contenant le compte utilisateur potentiellement piraté.
• Liens associés, en particulier les champs suivants :
  • Cloud Logging URI (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 résultat JSON.

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

Étape 3 : Vérifier les journaux

1. Dans l'onglet Ré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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 d'un résultat plus tôt sur cette page. Le panneau des détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du compte principal: compte de service potentiellement piraté.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet du projet: projet contenant le compte de service potentiellement compromis.
   • Liens associés, en particulier les champs suivants :
     • Cloud Logging URI (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 Filtre, saisissez le nom du compte répertorié sur la ligne Adresse e-mail du compte principal dans l'onglet Résumé des détails du résultat et 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 Filtre, saisissez le nom du compte répertorié sur la ligne Adresse e-mail du compte principal dans l'onglet Résumé des détails du résultat.

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

Étape 3 : Vérifier les journaux

1. Dans l'onglet Ré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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 effectuer une élévation de droits, un individu potentiellement malveillant a tenté de modifier un objet RBAC (contrôle des accès basé sur les rôles) ClusterRole, RoleBinding ou ClusterRoleBinding du rôle sensible cluster-admin à l'aide d'une requête PUT ou PATCH.

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

1. Ouvrez le résultat Privilege Escalation: Changes to sensitive Kubernetes RBAC objects comme indiqué dans la section Examiner les résultats. Le panneau des détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du compte principal: compte qui a passé 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 dans lequel l'action s'est produite.
   • Liens associés, en particulier les champs suivants :
     • Cloud Logging URI (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. Notez les détails de la liaison affichée.

Étape 2 : Vérifier les journaux

1. Dans l'onglet Résumé des détails du résultat de la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.

2. Si la valeur dans Method name était une méthode PATCH, vérifiez le corps de la requête pour voir quelles propriétés ont été modifiées.

   Dans les appels update (PUT), l'intégralité de l'objet est envoyée dans la requête. Les modifications ne sont donc pas aussi claires.

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

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Remplacez les éléments suivants :

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

   • PRINCIPAL_EMAIL: valeur que vous avez notée dans le champ Adresse e-mail du compte principal des détails du 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 déterminer s'il a besoin du rôle auquel il est lié.
4. Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux.

5. Si l'adresse e-mail principale n'est pas un compte de service, contactez le propriétaire du compte pour confirmer que ce dernier est bien à l'origine de l'action.

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

6. Pour élaborer un plan d'intervention, combinez les résultats de votre investigation avec la recherche MITRE.

Privilege Escalation: Create Kubernetes CSR for master cert

Pour élever des privilèges, un individu potentiellement malveillant a créé une demande de signature de certificat (CSR) maître Kubernetes, ce qui lui accorde l'accès cluster-admin.

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

1. Ouvrez le résultat Privilege Escalation: Create Kubernetes CSR for master cert comme indiqué dans la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du compte principal: compte qui a passé 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 dans lequel l'action s'est produite.
   • Liens associés, en particulier les champs suivants :
     • Cloud Logging URI (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 de la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.
2. Vérifiez la valeur du champ protoPayload.resourceName pour identifier la requête de signature de certificat spécifique.

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

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Remplacez les éléments suivants :

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

   • PRINCIPAL_EMAIL: valeur que vous avez notée dans le champ Adresse e-mail du compte principal des détails du 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 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 confirmer que ce dernier est bien à l'origine de l'action.

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

4. Pour élaborer un plan d'intervention, combinez les résultats de votre investigation avec la recherche MITRE.

Privilege Escalation: Creation of sensitive Kubernetes bindings

Pour élever des privilèges, un individu potentiellement malveillant a tenté de créer un objet RoleBinding ou ClusterRoleBinding pour le rôle cluster-admin.

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

1. Ouvrez le résultat Privilege Escalation: Creation of sensitive Kubernetes bindings comme indiqué dans la section Examiner les résultats. Le panneau des détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du compte principal: compte qui a passé l'appel.
     • Liaisons Kubernetes: liaison Kubernetes sensible ou ClusterRoleBinding qui a été créée.
   • Ressource concernée, en particulier les champs suivants :
     • Nom à afficher pour la ressource: cluster Kubernetes dans lequel l'action s'est produite.
   • Liens associés, en particulier les champs suivants :
     • Cloud Logging URI (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 de la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.

2. Recherchez d'autres actions effectuées par le 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 pour la ressource dans les détails du résultat.

   • PRINCIPAL_EMAIL: valeur que vous avez notée dans le champ Adresse e-mail du compte principal des détails du 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 la liaison créée et si les rôles sont nécessaires pour les sujets.
3. Pour les liaisons, vous pouvez vérifier le sujet et déterminer s'il a besoin du rôle auquel il est lié.
4. Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux.

5. Si l'adresse e-mail principale n'est pas un compte de service, contactez le propriétaire du compte pour confirmer que ce dernier est bien à l'origine de l'action.

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

6. Pour élaborer un plan d'intervention, combinez les résultats de votre investigation avec la recherche MITRE.

Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials

Pour effectuer une élévation de privilèges, un individu potentiellement malveillant a interrogé une demande de signature de certificat (CSR) à l'aide de la commande kubectl, en utilisant des identifiants d'amorçage compromis.

Voici un exemple de commande détectée par cette règle:

kubectl --client-certificate kubelet.crt --client-key kubelet.key --server YOUR_SERVER get csr CSR_NAME

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

1. Ouvrez le résultat Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials comme indiqué dans la section Examiner les résultats. Le panneau des détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du compte principal: compte qui a passé l'appel.
     • Method name (Nom de la méthode) : méthode appelée.
   • Sous Ressource concernée :
     • Nom à afficher pour la ressource: cluster Kubernetes dans lequel l'action s'est produite.
   • Liens associés, en particulier les champs suivants :
     • Cloud Logging URI (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 Method name (Nom de la méthode) des détails des résultats, est une méthode GET, procédez comme suit:

1. Dans l'onglet Résumé des détails du résultat de la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.
2. Vérifiez la valeur du champ protoPayload.resourceName pour identifier la 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 degré de sensibilité du certificat et vérifiez si l'action était justifiée.
3. Pour élaborer un plan d'intervention, combinez les résultats de votre investigation avec la recherche MITRE.

Privilege Escalation: Launch of privileged Kubernetes container

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

Le champ privileged d'un conteneur privilégié est défini sur true. Le champ allowPrivilegeEscalation d'un conteneur disposant de capacités d'élévation des droits est défini sur true. Pour en savoir plus, consultez la documentation de référence de l'API SecurityContext v1 core dans la documentation de Kubernetes.

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

1. Ouvrez le résultat Privilege Escalation: Launch of privileged Kubernetes container comme indiqué dans la section Examiner les résultats. Le panneau des détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du compte principal: compte qui a passé l'appel.
     • Pods Kubernetes: il s'agit du nouveau pod créé avec des conteneurs privilégiés.
   • Ressource concernée, en particulier les champs suivants :
     • Nom à afficher pour la ressource: cluster Kubernetes dans lequel l'action s'est produite.
   • Liens associés, en particulier les champs suivants :
     • Cloud Logging URI (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 de la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans le champ URI Cloud Logging.

2. Recherchez d'autres actions effectuées par le 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 pour la ressource dans les détails du résultat.

   • PRINCIPAL_EMAIL: valeur que vous avez notée dans le champ Adresse e-mail du compte principal des détails du 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 capacités du noyau.
3. Déterminez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux.

4. Si l'adresse e-mail principale n'est pas un compte de service, contactez le propriétaire du compte pour confirmer que le propriétaire légitime est bien à l'origine de l'action.

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

5. Pour élaborer un plan d'intervention, combinez les résultats de votre investigation avec la recherche MITRE.

Privilege Escalation: Dormant Service Account Granted Sensitive Role

Détecte les événements où un rôle IAM sensible est attribué à un compte de service géré par l'utilisateur inactif. Dans ce contexte, un compte de service est considéré comme 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 des résultats, dans l'onglet Résumé, notez les valeurs des champs suivants.

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

   • Adresse e-mail du compte principal: utilisateur ayant effectué l'action d'attribution
   • Accords d'accès incriminés.Nom principal: compte de service dormant ayant reçu le rôle sensible
   • Accords d'accès incriminés.Rôle accordé: rôles IAM sensibles attribués

   Sous Ressource concernée:

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

É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 dormant.
2. Contactez le propriétaire du champ Adresse e-mail du compte principal. Confirmez que le propriétaire légitime est bien à 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 pour lequel l'action a été effectuée.
• Supprimez l'accès du propriétaire de l'adresse e-mail du compte principal si l'adresse e-mail est compromise.
• Supprimez le rôle IAM sensible nouvellement attribué du compte de service dormant.
• Envisagez de supprimer le compte de service potentiellement compromis, puis d'alterner et de 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 de ces 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 la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du compte principal: compte de service final dans la requête d'emprunt d'identité utilisée pour accéder à Google Cloud.
     • Nom du service: nom de l'API du service Google Cloud impliqué dans la demande 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 correspond à l'appelant de la demande 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 :
     • Cloud Logging URI (URI Cloud Logging) : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
     • Résultats associés: liens vers les résultats associés.

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

1. Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez que le propriétaire légitime est bien à 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 d'emprunt d'identité dans la liste Informations sur la délégation de compte de service. Confirmez si le propriétaire légitime a effectué l'action.

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

Le plan d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 pour lequel l'action a été effectuée.
• Envisagez de supprimer le compte de service potentiellement compromis, puis d'alterner et de 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 de ces 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é 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 Multistep Service Account Delegation for Admin Activity, comme indiqué dans la section Examiner les résultats. Le panneau des détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du compte principal: compte de service final dans la requête d'emprunt d'identité utilisée pour accéder à Google Cloud.
     • Nom du service: nom de l'API du service Google Cloud impliqué dans la demande 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 correspond à l'appelant de la demande d'emprunt d'identité.
   • Ressource concernée
   • Liens associés, en particulier les champs suivants :
     • Cloud Logging URI (URI Cloud Logging) : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
     • Résultats associés: liens vers les résultats associés.

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

1. Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez que le propriétaire légitime est bien à 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 d'emprunt d'identité dans la liste Informations sur la délégation de compte de service. Confirmez si le propriétaire légitime a effectué l'action.

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

Le plan d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 pour lequel l'action a été effectuée.
• Envisagez de supprimer le compte de service potentiellement compromis, puis d'alterner et de 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 de ces 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 des accès aux données 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 Multistep Service Account Delegation for Data Access, comme indiqué dans la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Adresse e-mail du compte principal: compte de service final dans la requête d'emprunt d'identité utilisée pour accéder à Google Cloud
     • Nom du service: nom de l'API du service Google Cloud impliqué dans la demande d'emprunt d'identité.
     • Method name (Nom de la méthode) : la 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 correspond à l'appelant de la demande d'emprunt d'identité.
   • Ressource concernée
   • Liens associés, en particulier les champs suivants :
     • Cloud Logging URI (URI Cloud Logging) : lien vers les entrées Logging.
     • Méthode MITRE ATT&CK: lien vers la documentation MITRE ATT&CK.
     • Résultats associés: liens vers les résultats associés.

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

1. Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez que le propriétaire légitime est bien à 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 d'emprunt d'identité dans la liste Informations sur la délégation de compte de service. Confirmez si le propriétaire légitime a effectué l'action.

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

Le plan d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 pour lequel l'action a été effectuée.
• Envisagez de supprimer le compte de service potentiellement compromis, puis d'alterner et de 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 de ces 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é 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 Admin Activity, comme indiqué dans la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

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

     • Adresse e-mail du compte principal: compte de service final dans la requête d'emprunt d'identité utilisée pour accéder à Google Cloud
     • Nom du service: nom de l'API du service Google Cloud impliqué dans la demande d'emprunt d'identité.
     • Method name (Nom de la méthode) : la 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 correspond à l'appelant de la demande d'emprunt d'identité.

   • Ressource concernée

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

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

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

1. Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez que le propriétaire légitime est bien à 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 d'emprunt d'identité dans la liste Informations sur la délégation de compte de service. Confirmez si le propriétaire légitime a effectué l'action.

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

Le plan d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 pour lequel l'action a été effectuée.
• Envisagez de supprimer le compte de service potentiellement compromis, puis d'alterner et de 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 de ces 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 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 Service Account Impersonator for Data Access, comme indiqué dans la section Examiner les résultats.

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

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

   • Adresse e-mail du compte principal: compte de service final dans la requête d'emprunt d'identité utilisée pour accéder à Google Cloud
   • Nom du service: nom de l'API du service Google Cloud impliqué dans la demande d'emprunt d'identité.
   • Method name (Nom de la méthode) : la 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 correspond à l'appelant de la demande d'emprunt d'identité.

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

1. Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez que le propriétaire légitime est bien à 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 d'emprunt d'identité dans la liste Informations sur la délégation de compte de service. Confirmez si le propriétaire légitime a effectué l'action.

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

Le plan d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 pour lequel l'action a été effectuée.
• Envisagez de supprimer le compte de service potentiellement compromis, puis d'alterner et de 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 de ces 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 d'un résultat plus tôt sur cette page. Le panneau des détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Gravité: niveau de risque attribué au résultat La gravité est définie sur HIGH si l'appel d'API qui a déclenché ce résultat n'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 du compte principal: compte de service potentiellement piraté.
     • Adresse IP de l'appelant: l'adresse IP interne ou externe
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource:
     • Nom complet du projet: projet contenant les identifiants de compte potentiellement divulgués.
   • Liens associés, en particulier les champs suivants :
     • Cloud Logging URI (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 résultat JSON.

3. Sur la page qui s'affiche, dans le champ Filtre, saisissez le nom du compte répertorié dans Adresse e-mail du compte principal et 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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. Une fois qu'un hôte est supprimé, 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 des détails du résultat s'ouvre dans l'onglet Résumé.
2. Dans l'onglet Summary (Résumé), passez en revue les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Nom de l'application: nom d'une base de données ou d'une VM connectée à 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
     • Resource display name (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 sur MITRE ATT&CK
     • Logging URI (URI de journalisation) : lien pour ouvrir l'explorateur de journaux

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

Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez que le propriétaire légitime est bien à l'origine de l'action.

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

Le plan d'intervention suivant peut être approprié pour ce résultat. Examinez attentivement les informations que vous recueillez lors de votre investigation pour déterminer la meilleure façon de résoudre les problèmes.

1. Dans le projet dans lequel 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ôte pour ajouter de 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 la suppression anormale d'un plan de sauvegarde de service de sauvegarde et de reprise après sinistre utilisé pour appliquer des règles 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 Résumé.
2. Dans l'onglet Summary (Résumé), passez en revue les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Nom de l'application: nom d'une base de données ou d'une VM connectée à 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 d'applications et de 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 sur MITRE ATT&CK
     • Logging URI (URI de journalisation) : lien pour ouvrir l'explorateur de journaux

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

Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez que le propriétaire légitime est bien à l'origine de l'action.

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

Le plan d'intervention suivant peut être approprié pour ce résultat. Examinez attentivement les informations que vous recueillez lors de votre investigation pour déterminer la meilleure façon de résoudre les problèmes.

1. Dans le projet dans lequel 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.

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 Résumé.
2. Dans l'onglet Summary (Résumé), passez en revue 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 sur MITRE ATT&CK
     • Logging URI (URI de journalisation) : lien pour ouvrir l'explorateur de journaux

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

Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez que le propriétaire légitime est bien à l'origine de l'action.

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

Le plan d'intervention suivant peut être approprié pour ce résultat. Examinez attentivement les informations que vous recueillez lors de votre investigation pour déterminer la meilleure façon de résoudre les problèmes.

1. Dans le projet dans lequel l'action a été effectuée, accédez à la console de gestion.
2. Dans l'onglet Gestionnaire d'applications, recherchez les applications concernées qui ne sont plus protégées et examinez les règles de sauvegarde pour chacune d'elles.
3. Pour ajouter à nouveau un modèle, accédez à l'onglet Plans de sauvegarde, sélectionnez Modèles, puis 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 stratégie. Une règle 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 Résumé.
2. Dans l'onglet Summary (Résumé), passez en revue les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Nom de la règle: nom d'une seule règle, qui définit 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 la stratégie a été supprimée
   • Liens associés, en particulier les champs suivants :
     • Méthode MITRE ATTACK: lien vers la documentation sur MITRE ATT&CK
     • Logging URI (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 du compte principal. Confirmez que le propriétaire légitime est bien à l'origine de l'action.

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

Le plan d'intervention suivant peut être approprié pour ce résultat. Examinez attentivement les informations que vous recueillez au cours de votre investigation afin de déterminer la meilleure façon de résoudre les problèmes. 1. Dans le projet dans lequel l'action a été effectuée, accédez à la console de gestion. 2. Dans l'onglet Gestionnaire d'applications, sélectionnez l'application concernée et vérifiez les paramètres des règles qui lui sont appliquées.

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 des détails du résultat s'ouvre dans l'onglet Résumé.
2. Dans l'onglet Summary (Résumé), passez en revue 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 d'applications et de VM.
     • Principal subject (Objet principal) : utilisateur qui a exécuté une action
   • Ressource concernée
     • Resource display name (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 sur MITRE ATT&CK
     • Logging URI (URI de journalisation) : lien pour ouvrir l'explorateur de journaux

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

Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez que le propriétaire légitime est bien à l'origine de l'action.

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

Le plan d'intervention suivant peut être approprié pour ce résultat. Examinez attentivement les informations que vous recueillez au cours de votre investigation afin de déterminer la meilleure façon de résoudre les problèmes. 1. Dans le projet dans lequel l'action a été effectuée, accédez à la console de gestion. 2. Dans l'onglet Plans de sauvegarde, sélectionnez Profils pour obtenir la liste de tous les profils. 3. Examinez les fiches pour vérifier qu'elles sont toutes en place. 4. Si le profil supprimé a été retiré par erreur, sélectionnez Créer un profil pour définir les cibles de stockage de 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 des détails du résultat s'ouvre dans l'onglet Résumé.
2. Dans l'onglet Summary (Résumé), passez en revue 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 où les sauvegardes sont stockées.
     • Principal subject (Objet principal) : utilisateur qui a exécuté une action
   • Ressource concernée
     • Resource display name (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 sur MITRE ATT&CK
     • Logging URI (URI de journalisation) : lien pour ouvrir l'explorateur de journaux

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

Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez que le propriétaire légitime est bien à l'origine de l'action.

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

Le plan d'intervention suivant peut être approprié pour ce résultat. Examinez attentivement les informations que vous recueillez au cours de votre investigation afin de déterminer la meilleure façon de résoudre les problèmes. 1. Dans le projet dans lequel l'action a été effectuée, accédez à la console de gestion. 2. Dans l'onglet "Gérer", sélectionnez Pools de stockage pour obtenir 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 individu potentiellement malveillant a demandé la suppression d'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 des détails du résultat s'ouvre dans l'onglet Résumé.
2. Dans l'onglet Summary (Résumé), passez en revue les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Nom de la règle: nom d'une seule règle, qui définit la fréquence, la planification et la durée de conservation des sauvegardes
     • Nom du modèle: nom d'un ensemble de règles qui définissent la fréquence, la 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 d'applications et de VM.
     • 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'image de back-up a été supprimée
   • Liens associés, en particulier les champs suivants :
     • Méthode MITRE ATTACK: lien vers la documentation sur MITRE ATT&CK
     • Logging URI (URI de journalisation) : lien pour ouvrir l'explorateur de journaux

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

Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez que le propriétaire légitime est bien à l'origine de l'action.

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

Le plan d'intervention suivant peut être approprié pour ce résultat. Examinez attentivement les informations que vous recueillez au cours de votre investigation afin de déterminer la meilleure façon de résoudre les problèmes. 1. Dans le projet dans lequel l'action a été effectuée, accédez à la console de gestion. 2. Accédez à l'onglet "Monitor" (Surveiller) et sélectionnez "Jobs" (Tâches) pour consulter l'état de la suppression du job de sauvegarde. 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 individu 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 des détails du résultat s'ouvre dans l'onglet Résumé.
2. Dans l'onglet Summary (Résumé), passez en revue les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Nom de la règle: nom d'une seule règle, qui définit la fréquence, la planification et la durée de conservation des sauvegardes
     • Nom du modèle: nom d'un ensemble de règles qui définissent la fréquence, la 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 d'applications et de VM.
     • Principal subject (Objet principal) : utilisateur qui a exécuté une action
   • Ressource concernée
     • Resource display name (Nom à afficher de la ressource) : le projet dans lequel les images de sauvegarde ont été supprimées
   • Liens associés, en particulier les champs suivants :
     • Méthode MITRE ATTACK: lien vers la documentation sur MITRE ATT&CK
     • Logging URI (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 du compte principal. Confirmez que le propriétaire légitime est bien à l'origine de l'action.

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

Le plan d'intervention suivant peut être approprié pour ce résultat. Examinez attentivement les informations que vous recueillez au cours de votre investigation afin de déterminer la meilleure façon de résoudre les problèmes. 1. Dans le projet dans lequel l'action a été effectuée, accédez à la console de gestion. 2. Accédez à l'onglet "Monitor" (Surveiller) et sélectionnez "Jobs" (Tâches) pour consulter l'état de la suppression du job de sauvegarde. 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 permettent de 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 pour les opérations de sauvegarde.

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

1. Ouvrez le résultat Inhibit System Recovery: Google Cloud Backup and DR remove appliance, comme indiqué dans la section Examiner les résultats. Le panneau des détails du résultat s'ouvre dans l'onglet Résumé.
2. Dans l'onglet Summary (Résumé), passez en revue 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
     • Nom à afficher pour la ressource: projet dans lequel le dispositif a été supprimé
   • Liens associés, en particulier les champs suivants :
     • Méthode MITRE ATTACK: lien vers la documentation sur MITRE ATT&CK
     • Logging URI (URI de journalisation) : lien pour ouvrir l'explorateur de journaux

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

Contactez le propriétaire du compte de service dans le champ Adresse e-mail du compte principal. Confirmez que le propriétaire légitime est bien à l'origine de l'action.

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

Le plan d'intervention suivant peut être approprié pour ce résultat. Examinez attentivement les informations que vous recueillez au cours de votre investigation afin de déterminer la meilleure façon de résoudre les problèmes. 1. Dans le projet dans lequel 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 dispositif et appliquer à nouveau 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 système configuré, il apparaît comme 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 des détails du résultat s'ouvre dans l'onglet Summary (Résumé).
2. Dans l'onglet Summary (Résumé), passez en revue les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Description: informations sur la détection
     • Principal subject (Objet principal) : un utilisateur ou un compte de service qui a correctement exécuté une action
   • Ressource concernée
     • Nom à afficher pour 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.
     • Logging URI (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. Confirmez que le propriétaire légitime est bien à l'origine de l'action.

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

Le plan d'intervention suivant peut être approprié pour ce résultat. Examinez attentivement les informations que vous recueillez lors de votre investigation pour déterminer la meilleure façon de résoudre les problèmes.

1. Dans le projet dans lequel l'action a été effectuée, accédez à la console de gestion.
2. Dans l'onglet Gestionnaire d'applications, recherchez l'application concernée pour laquelle le délai d'expiration de la sauvegarde a été réduit et vérifiez qu'il é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éterminer 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 des détails du résultat s'ouvre dans l'onglet Summary (Résumé).
2. Dans l'onglet Summary (Résumé), passez en revue les informations des sections suivantes :
   • Ce qui a été détecté, en particulier les champs suivants :
     • Description: informations sur la détection
     • Principal subject (Objet principal) : un utilisateur ou un compte de service qui a correctement 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.
     • Logging URI (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. Confirmez que le propriétaire légitime est bien à l'origine de l'action.

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

Le plan d'intervention suivant peut être approprié pour ce résultat. Examinez attentivement les informations que vous recueillez lors de votre investigation pour déterminer la meilleure façon de résoudre les problèmes.

1. Dans le projet dans lequel l'action a été effectuée, accédez à la console de gestion.
2. Dans l'onglet Gestionnaire d'applications, recherchez l'application concernée pour laquelle la fréquence des sauvegardes a été réduite et vérifiez que la modification était intentionnelle 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 des mouvements de disque suspects entre les ressources d'instance Compute Engine. Un disque de démarrage potentiellement modifié a été associé à votre Compute Engine.

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

1. Ouvrez le résultat Lateral Movement: Modify Boot Disk Attaching to Instance, comme indiqué dans la section Examiner les résultats. Le panneau des détails du résultat s'ouvre dans l'onglet 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 du compte principal: compte de service qui a effectué l'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) : la 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 du compte principal. Confirmez que le propriétaire légitime est bien à l'origine de l'action.

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

Le plan d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 pour lequel l'action a été effectuée.
• Pensez à utiliser le démarrage sécurisé pour vos instances de VM Compute Engine.
• Envisagez de supprimer le compte de service potentiellement compromis, puis d'alterner et de 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 leur accès. Avant de continuer, votre équipe de sécurité doit identifier toutes les applications concernées et collaborer avec leurs propriétaires pour assurer la continuité de l'activité.
• 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 concernée.
     • Database user name (Nom d'utilisateur de la base de données) : utilisateur PostgreSQL ayant accordé des droits excédentaires
     • Database query (Requête de base de données) : requête PostgreSQL exécutée qui a accordé les privilèges.
     • Bénéficiaires de la base de données: bénéficiaires des droits trop larges.
   • Ressource concernée, en particulier les champs suivants :
     • Resource full name (Nom complet de la ressource) : nom de la ressource de l'instance AlloyDB pour PostgreSQL concernée.
     • Nom complet du parent: nom de la ressource de l'instance AlloyDB pour PostgreSQL.
     • Nom complet du projet: projet Google Cloud contenant l'instance AlloyDB pour PostgreSQL.
   • Liens associés, en particulier les champs suivants :
     • Cloud Logging URI (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 indiquée dans la section Nom à afficher de la base de données (à l'étape 1).
   • Fonctions ou procédures. Utilisez la métacommande \df et vérifiez les droits attribués aux fonctions ou procédures de la base de données répertoriées dans la section Nom à afficher de la base de données (étape 1).

Étape 3 : Vérifier les journaux

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

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

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

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

Le plan d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 la section Bénéficiaires de la base de données jusqu'à ce que l'investigation soit terminée.
• Pour limiter l'accès à la base de données (à partir du Nom à afficher de la base de données de l'étape 1, revoke les autorisations inutiles des bénéficiaires (voir Bénéficiaires de la base de données de l'étape 1).

Privilege Escalation: AlloyDB Database Superuser Writes to User Tables

Détecte les cas où le compte super-utilisateur de base de données AlloyDB pour PostgreSQL (postgres) écrit dans des tables utilisateur. Le super-utilisateur (un rôle doté d'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 utilisateur, cela peut indiquer qu'un pirate informatique a élevé des privilèges ou qu'il a compromis l'utilisateur de base de données par défaut et qu'il modifie les données. Cela peut également indiquer des pratiques normales, mais dangereuses.

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

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

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

2. Dans l'onglet Résumé du panneau 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 concernée.
     • Database user name (Nom d'utilisateur de la base de données) : le super-utilisateur.
     • Database query (Requête de base de données) : requête SQL exécutée lors de l'écriture dans des tables utilisateur.
   • Ressource concernée, en particulier les champs suivants :
     • Resource full name (Nom complet de la ressource) : nom de la ressource de l'instance AlloyDB pour PostgreSQL concernée.
     • Nom complet du parent: nom de la ressource de l'instance AlloyDB pour PostgreSQL.
     • Nom complet du projet: projet Google Cloud contenant l'instance AlloyDB pour PostgreSQL.
   • Liens associés, en particulier les champs suivants :
     • Cloud Logging URI (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, à 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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.

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

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 : MITRE : https://attack.mitre.org/techniques/T1098/004/

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 : MITRE : https://attack.mitre.org/techniques/T1098/004/

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 définis 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 : MITRE : https://attack.mitre.org/techniques/T1078/ Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_password_leak

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 : MITRE : https://attack.mitre.org/techniques/T1078/ Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#suspicious_login

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 : MITRE : https://attack.mitre.org/techniques/T1078/ Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_hijacked

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 : MITRE : https://attack.mitre.org/techniques/T1562/ Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#2sv_disable

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 : MITRE : https://attack.mitre.org/techniques/T1078/ Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#gov_attack_warning

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 : MITRE : https://attack.mitre.org/techniques/T1098/ Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#TOGGLE_SSO_ENABLED

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 : MITRE : https://attack.mitre.org/techniques/T1098/ Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#CHANGE_SSO_SETTINGS

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 : MITRE : https://attack.mitre.org/techniques/T1562/ Détails de l'événement Workspace : https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-security-settings#ENFORCE_STRONG_AUTHENTICATION

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 peuvent pas être analysés pour les activations au niveau du projet.

Si vous êtes administrateur Google Workspace, vous pouvez utiliser les outils de sécurité du service pour résoudre ces menaces :

• Centre d'alerte Google Workspace
• Centre de sécurité Google Workspace

Ces outils incluent des alertes, un tableau de bord de sécurité et des recommandations de sécurité qui peuvent vous aider à examiner et à résoudre les menaces.

Si vous n'êtes pas administrateur Google Workspace, procédez comme suit :

• Si vous avez encore accès à votre compte, modifiez ou réinitialisez votre mot de passe et activez la validation en deux étapes.
• Contactez votre administrateur Google Workspace ou l'équipe de votre entreprise qui gère votre compte Google Workspace. Utilisez ces résultats pour indiquer qu'un compte peut être compromis.

Détection des menaces Cloud IDS

Cloud IDS: THREAT_ID

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Les résultats Cloud IDS sont générés par Cloud IDS, un service de sécurité qui surveille le trafic vers et depuis vos ressources Google Cloud pour détecter les menaces. Lorsque Cloud IDS détecte une menace, il envoie des informations sur la menace, telles que l'adresse IP source, l'adresse de destination et le numéro de port, à Event Threat Detection, qui émet ensuite une détection de la menace.

É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 Résumé, examinez les valeurs répertoriées dans les sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Protocol (Protocole) : le protocole réseau utilisé
     • Date et heure de l'événement: date et heure de l'événement
     • Description: informations supplémentaires sur le résultat
     • Gravité: 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.
     • 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 :
     • Cloud Logging URI (URI Cloud Logging) : lien vers les entrées de journalisation Cloud IDS. Ces entrées contiennent les informations nécessaires pour effectuer une recherche dans Threat Vault de Palo 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 des résultats, veuillez vous reporter à la documentation Cloud IDS sur l'examen des alertes de menace pour déterminer une réponse appropriée.

Vous pouvez trouver plus d'informations sur l'événement détecté dans l'entrée de journal d'origine en cliquant 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 des outils d’exploitation et des logiciels malveillants après la compromission initiale. Il est important de vous assurer que vos conteneurs sont immuables. Il s'agit d'un résultat de faible gravité, car votre organisation peut ne pas suivre cette bonne pratique. Il existe des résultats Execution: Added Malicious Binary Executed correspondants lorsque le hachage du binaire est un indicateur connu de compromission (IoC). Pour répondre à ce résultat, procédez comme suit :

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

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

2. Dans l'onglet Résumé, passez en revue 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 JSON et notez les champs suivants:

   • resource:
     • project_display_name: nom du projet contenant le cluster.
   • sourceProperties:
     • Pod_Namespace: nom de l'espace de noms Kubernetes du pod.
     • Pod_Name: nom du pod GKE.
     • Container_Name: nom du conteneur concerné.
     • Container_Image_Uri: nom de l'image de conteneur en cours de déploiement.
     • VM_Instance_Name: nom du nœud GKE sur lequel le pod a été exécuté.

4. Identifiez d'autres résultats survenus à un moment similaire pour ce conteneur. Les résultats associés peuvent indiquer que cette activité était malveillante au lieu d'un non-respect des bonnes pratiques.

É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 dans l'onglet Résumé des détails du résultat. Notez toutes les métadonnées concernant le cluster et son propriétaire.

4. Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.

5. Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

1. Dans la console Google Cloud, accédez à la page Charges de travail Kubernetes.

   Accéder à la page "Charges de travail Kubernetes"

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

3. Filtrez le cluster indiqué sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat et sur 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 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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.

• Si le binaire était destiné à être inclus dans le conteneur, recompilez l'image du conteneur en incluant le binaire. De cette façon, le conteneur peut être immuable.
• Sinon, contactez le propriétaire du projet dont le conteneur est compromis.
• Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

Added Library Loaded

Une bibliothèque ne faisant pas partie de l'image de conteneur d'origine a été chargée. Les pirates informatiques peuvent charger des bibliothèques malveillantes dans des programmes existants afin de contourner les protections d'exécution du code et de masquer du code malveillant. Il est important de vous assurer que vos conteneurs sont immuables. Il s'agit d'un résultat de faible gravité, car votre organisation peut ne pas suivre cette bonne pratique. Il existe des résultats Execution: Added Malicious Library Loaded correspondants lorsque le hachage du binaire est un indicateur connu de compromission (IoC). Pour répondre à ce résultat, procédez comme suit :

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

1. Ouvrez un résultat Added Library Loaded comme indiqué dans la section Examiner les résultats. Le panneau des détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Binaire du programme: chemin d'accès complet au binaire de processus qui a chargé la bibliothèque.
     • Libraries (Bibliothèques) : détails 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 :
     • Nom complet de la ressource: nom complet de la ressource du cluster.

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

4. Identifiez d'autres résultats survenus à un moment similaire pour ce conteneur. Les résultats associés peuvent indiquer que cette activité était malveillante au lieu d'un non-respect des bonnes pratiques.

É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 indiqué sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat et sur 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. 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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.

• Si la bibliothèque était censée être incluse dans le conteneur, recompilez l'image du conteneur en incluant la bibliothèque. De cette façon, le conteneur peut être immuable.
• Sinon, contactez le propriétaire du projet dont le conteneur est compromis.
• Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

Execution: Added Malicious Binary Executed

Un binaire malveillant 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 Execution: Added Malicious Binary Executed comme indiqué dans la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue 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 des conteneurs: nom de l'image de 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 dans l'onglet Résumé des détails du résultat. Notez toutes les métadonnées concernant le cluster et son propriétaire.

4. Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.

5. Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

1. Dans la console Google Cloud, accédez à la page Charges de travail Kubernetes.

   Accéder à la page "Charges de travail Kubernetes"

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

3. Filtrez le cluster indiqué sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat et sur 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 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 conteneur:

     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 VirusTotal indicator (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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 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 Execution: Added Malicious Library Loaded comme indiqué dans la section Examiner les résultats. Le panneau des détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Binaire du programme: chemin d'accès complet au binaire de processus qui a chargé la bibliothèque.
     • Libraries (Bibliothèques) : détails sur la bibliothèque ajoutée.
     • Arguments: arguments fournis lors de l'appel du binaire de processus.
     • Conteneurs: nom du conteneur concerné.
     • URI des conteneurs: nom de l'image de 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.
   • 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 dans l'onglet Résumé des détails du résultat. Notez toutes les métadonnées concernant le cluster et son propriétaire.

4. Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.

5. Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

1. Dans la console Google Cloud, accédez à la page Charges de travail Kubernetes.

   Accéder à la page "Charges de travail Kubernetes"

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

3. Filtrez le cluster indiqué sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat et sur 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. 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 conteneur:

     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 VirusTotal indicator (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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 qui a été exécuté, avec le binaire:

• Inclus dans l'image de conteneur d'origine.
• Identifiés comme malveillants d’après les renseignements sur les menaces.

L'attaquant contrôle le dépôt d'images de conteneur ou le pipeline de création, où 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 la section Examiner les résultats. Le panneau de détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue 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 des conteneurs: nom de l'image de 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 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 dans l'onglet Résumé des détails du résultat. Notez toutes les métadonnées concernant le cluster et son propriétaire.

4. Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.

5. Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

1. Dans la console Google Cloud, accédez à la page Charges de travail Kubernetes.

   Accéder à la page "Charges de travail Kubernetes"

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

3. Filtrez le cluster indiqué sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat et sur 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 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 créé à l'aide d'étain.

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

     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 VirusTotal indicator (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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 qui a été exécuté, avec le binaire:

• Inclus dans l'image de conteneur d'origine.
• Modifiés pendant l'exécution du conteneur.
• Identifiés comme malveillants d’après les renseignements sur les menaces.

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

2. Dans l'onglet Résumé, passez en revue 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 des conteneurs: nom de l'image de 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 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 dans l'onglet Résumé des détails du résultat. Notez toutes les métadonnées concernant le cluster et son propriétaire.

4. Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.

5. Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

1. Dans la console Google Cloud, accédez à la page Charges de travail Kubernetes.

   Accéder à la page "Charges de travail Kubernetes"

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

3. Filtrez le cluster indiqué sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat et sur 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 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 conteneur:

     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 VirusTotal indicator (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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 qui a été chargée, avec la bibliothèque:

• Inclus dans l'image de conteneur d'origine.
• Modifiés pendant l'exécution du conteneur.
• Identifiés comme malveillants d’après les renseignements sur les menaces.

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

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Binaire du programme: chemin d'accès complet au binaire de processus qui a chargé la bibliothèque.
     • Bibliothèques: détails sur la bibliothèque modifiée.
     • Arguments: arguments fournis lors de l'appel du binaire de processus.
     • Conteneurs: nom du conteneur concerné.
     • URI des conteneurs: nom de l'image de 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.
   • 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. Filtrez le cluster indiqué sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat et sur 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. 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 conteneur:

     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 VirusTotal indicator (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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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é le code bash exécuté comme malveillant. Les pirates informatiques peuvent utiliser bash pour transférer des outils et exécuter des commandes sans binaire. Il est important de vous assurer que vos conteneurs sont immuables. L'utilisation de scripts pour les outils de transfert peut imiter la technique du transfert depuis l'outil d'entrée utilisée par les pirates informatiques et entraîner des détections indésirables.

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 Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Binaire du programme: détails 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, et non 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: contenu du script exécuté, qui peut être tronqué pour des raisons de performances ; ceci peut vous aider dans votre enquête
       • 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é.

5. Identifiez d'autres résultats survenus à un moment similaire pour ce conteneur. Par exemple, si le script supprime un binaire, vérifiez les résultats qui s'y rapportent.

É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 dans l'onglet Résumé des détails du résultat. Notez toutes les métadonnées concernant le cluster et son propriétaire.

4. Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.

5. Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.

Étape 3 : Examiner le pod

1. Dans la console Google Cloud, accédez à la page Charges de travail Kubernetes.

   Accéder à la page "Charges de travail Kubernetes"

2. Dans la barre d'outils de la console Google Cloud, sélectionnez le projet 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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.

• Si le script apportait des modifications souhaitées au conteneur, recompilez l'image du conteneur de sorte qu'aucune modification n'est nécessaire. De cette façon, le conteneur peut être immuable.
• Sinon, contactez le propriétaire du projet dont le conteneur est compromis.
• Arrêtez ou supprimez le conteneur compromis et remplacez-le par un nouveau conteneur.

Malicious URL Observed

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Container Threat Detection a observé une URL malveillante dans la liste des 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 Résumé.

2. Dans l'onglet Résumé, passez en revue 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 ayant 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 du pod et espace de noms
   • 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 inclut les informations suivantes :
       • Projet contenant le cluster: projects/PROJECT_ID
       • Emplacement du 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 apparaît 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 la section Nom à afficher pour la ressource (resource.display_name) du résumé des résultats. La page Clusters s'ouvre.

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

5. Cliquez sur l'onglet Nœuds.

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

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 par nom de cluster que vous avez noté dans la section Nom complet de la ressource (resource.name) du résumé des résultats et, si nécessaire, sur l'espace de noms du pod (kubernetes.pods.ns) que vous avez noté.

5. Cliquez sur le nom de la charge de travail correspondant à 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 toutes les informations relatives au pod qui pourraient 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 apparaît 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 de votre 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: Examinez 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 considérée comme malveillante.
2. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Transfert d'outils d'entrée.
3. Pour élaborer un plan d'intervention, combinez les résultats de votre investigation avec la recherche MITRE.

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

Le plan d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Binaire du programme: chemin absolu du processus commencé par la redirection du flux vers un socket distant.
     • Arguments: arguments fournis lors de l'appel du binaire de processus.
   • Ressource concernée, en particulier les champs suivants :
     • Nom complet de la ressource: nom complet de la ressource du cluster.
     • Nom complet du projet:
   • 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 shell enfant. Cet événement peut indiquer qu'un pirate informatique tente d'abuser des commandes shell et des scripts.

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

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Parent process (Processus parent) : processus qui a créé de manière inattendue le processus de shell enfant.
     • Processus enfant: processus de shell enfant.
     • Arguments: arguments fournis au binaire de traitement du shell enfant.
     • Environment variables (Variables d'environnement) : variables d'environnement du binaire de traitement du shell enfant.
     • Conteneurs: nom du conteneur.
     • URI des conteneurs: URI de l'image du conteneur.
     • Pods Kubernetes: nom du pod et espace de noms
   • 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 inclut les informations suivantes :
       • Projet contenant le cluster: projects/PROJECT_ID
       • Emplacement du 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 shell enfant et le processus parent. +resource : +project_display_name: nom du projet contenant les éléments. +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 par nom de cluster que vous avez noté dans la section Nom complet de la ressource (resource.name) du résumé des résultats et, si nécessaire, en fonction de l'espace de noms du pod (kubernetes.pods.ns) que vous avez noté.

5. Cliquez sur le nom de la charge de travail correspondant à 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 toutes les informations relatives au pod qui pourraient 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: Examinez 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 conteneur, 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 ce type de résultat : Command and Scripting Interpreter: Unix Shell (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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 page Présentation de VM Threat Detection.

Execution: Cryptocurrency Mining Hash Match

VM Threat Detection a détecté des activités de minage de cryptomonnaies en mettant en correspondance les hachages de mémoire des programmes en cours d'exécution avec ceux de 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 des détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

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

     • Famille binaire: 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 de processus: nom du processus en cours d'exécution dans l'instance de VM 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 fichier JSON complet de ce résultat, cliquez sur l'onglet JSON dans la vue détaillée du résultat.

   • indicator
     • signatures:
       • memory_hash_signature: signature correspondant aux hachages de page 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 qui correspondent aux pages d'applications de cryptomonnaies connues dans la base de données de hachage de page.

É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 indiqué sur la ligne Resource full name (Nom complet de la ressource) de l'onglet Summary (Résumé) des résultats.

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 et 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. Sélectionnez le projet spécifié 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 du processus et le chemin binaire du programme détectés pour l'application sont disponibles, examinez les valeurs des lignes Binaire du programme, Arguments et Noms de processus dans l'onglet Résumé des détails des résultats 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 les fichiers importants dans l'espace de stockage. Utilisez une partie significative du nom binaire dans votre schéma 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 la section Examiner les résultats. Le panneau des détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

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

     • 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 de processus: nom des processus en cours d'exécution dans l'instance de VM associés 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:

     • Cloud Logging URI (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 Google SecOps.

3. Pour afficher le fichier JSON complet de ce résultat, cliquez sur l'onglet JSON dans la vue détaillée du résultat.

É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 indiqué sur la ligne Resource full name (Nom complet de la ressource) de l'onglet Summary (Résumé) des résultats.

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 et 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. Sélectionnez le projet spécifié dans le nom de ressource répertorié 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 d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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 du processus et le chemin binaire du programme détectés pour l'application sont disponibles, examinez les valeurs des lignes Binaire du programme, Arguments et Noms de processus dans l'onglet Résumé des détails des résultats 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 provenant d'une seule source. 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.

Malware: Malicious file on disk (YARA)

VM Threat Detection a détecté un fichier potentiellement malveillant en analysant les disques persistants d'une VM à la recherche de signatures de logiciels malveillants connus.

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

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

1. Ouvrez le résultat Malware: Malicious file on disk (YARA), comme indiqué dans la section Examiner les résultats. Le panneau des détails du résultat s'ouvre dans l'onglet Résumé.

2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants :
     • Nom de la règle YARA: règle YARA correspondante.
     • Fichiers: l'UUID de partition et le chemin relatif du fichier potentiellement malveillant qui a été détecté.
   • 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 fichier JSON complet de ce résultat, cliquez sur l'onglet JSON dans la vue détaillée du résultat.

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

   • indicator
     • signatures:
       • yaraRuleSignature: signature correspondant à la règle YARA correspondante.

É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 indiqué sur la ligne Resource full name (Nom complet de la ressource) de l'onglet Summary (Résumé) des résultats.

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 et 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. Sélectionnez le projet spécifié dans le nom de ressource répertorié 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

Vérifiez la valeur de hachage SHA-256 du fichier signalé comme malveillant sur VirusTotal. VirusTotal est un service appartenant à Alphabet qui fournit du contexte sur les fichiers, URL, domaines et adresses IP potentiellement malveillants.

Remarque :VirusTotal peut ne pas contenir de hachage pour toutes les variantes de logiciels malveillants.

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

Le plan d'intervention suivant peut être approprié pour ce constat, mais pourrait aussi 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.

1. Contactez le propriétaire de la VM.

2. Si nécessaire, localisez et supprimez le fichier potentiellement malveillant. Pour obtenir l'UUID de partition et le chemin relatif du fichier, reportez-vous au champ Fichiers de l'onglet Résumé des détails du résultat. Pour faciliter la détection et la suppression, utilisez une solution de détection et de réponse des points de terminaison.

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

   Remarque :Avec le niveau Security Command Center Enterprise, vous pouvez également effectuer cette action via un playbook de réponse aux menaces.

4. Pour une analyse détaillée, envisagez de sauvegarder les machines virtuelles et les disques persistants. Pour en savoir plus, consultez la section Options de protection des données dans la documentation Compute Engine.

5. Pour une enquête plus approfondie, envisagez d'utiliser des services de gestion des incidents tels que Mandiant.

Corriger les failles associées

Pour éviter que les menaces se reproduisent, examinez et corrigez les résultats de failles et d'erreurs de configuration associés.

Pour rechercher les 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 de mauvaise configuration, tel que 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 située à gauche du menu, sélectionnez la catégorie qui contient 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 Resource (Ressource) sont affichés dans la colonne de droite, y compris l'attribut Full name.

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 de valeurs d'attribut s'ouvre à droite et affiche toutes les valeurs trouvées pour le type d'attribut sélectionné.

7. Dans le champ Filtre, collez la valeur d'attribut que vous avez copiée à partir du résultat de menace. La liste de valeurs qui s'affiche 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 Apply (Appliquer). Le panneau Résultats de la requête de résultat est mis à jour pour n'afficher que les résultats correspondants.

9. S'il y a 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 Faille 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

Corriger les résultats d'Event Threat Detection et de Container Threat Detection ne se résume pas à 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

• Consultez la présentation d'Event Threat Detection pour en savoir plus sur le service et les menaces qu'il détecte.

• Pour en savoir plus sur le fonctionnement du service, consultez la page Présentation de Container Threat Detection.

• Consultez la présentation de VM Threat Detection pour en savoir plus sur le service et les menaces qu'il détecte.