Examiner et contrer les menaces

Cet article fournit des conseils informels pour vous aider à examiner et à contrer les menaces, ainsi qu'à utiliser des ressources supplémentaires pour mettre en contexte les résultats de Security Command Center. En suivant ces étapes, vous pouvez comprendre ce qui s'est passé lors d'une attaque potentielle et développer les réponses possibles pour les ressources affectées.

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

Avant de commencer

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

Comprendre les menaces détectées

Event Threat Detection produit des résultats de sécurité en faisant correspondre les événements de votre journal Cloud Logging vers les 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 aussi les menaces en identifiant les adversaires connus des tactiques, techniques et procédures dans votre flux de journalisation et en détectant déviations par rapport au comportement passé de votre organisation ou de votre projet. Si vous activez 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 observés de bas niveau dans le noyau invité des conteneurs.

Les résultats sont écrits dans Security Command Center. Si vous activez Security Command Center Premium 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 Google Cloud Console, accédez à la page Résultats de Security Command Center.

   Accéder

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

   

3. Dans la section Filtres rapides, cliquez sur un filtre approprié à afficher le résultat dont vous avez besoin dans la table Résultats de la requête de résultat. Pour Par exemple, si vous sélectionnez Event Threat Detection ou Container Threat Detection dans la sous-section Nom à afficher pour la source, seuls les résultats du le 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

Après avoir résolu un problème à l’origine de la détection d’une menace, Security Command Center ne définit pas automatiquement l'état du résultat à 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 ignorez 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 dont vous avez besoin. à gérer, ce qui permet d'identifier plus facilement une vraie menace lorsqu'elle se produit.

Pour une menace réelle, avant de définir l'état du résultat sur INACTIVE, éliminer la menace et procéder à une analyse approfondie la menace détectée, l'étendue de l'intrusion et tout autre élément connexe ; et les problèmes à résoudre.

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

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

Evasion: Access from Anonymizing Proxy

Les accès anormaux d'un proxy anonyme sont détectés en consultant les journaux Cloud Audit pour examiner les modifications apportées aux services Google Cloud provenant d'adresses IP de proxy anonymes, telles que les adresses IP Tor.

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

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

1. Ouvrez un résultat Evasion: Access from Anonymizing Proxy, comme indiqué dans Examiner les résultats. Le panneau du résultat contenant des informations détaillées, ce qui affiche l'onglet Summary (Résumé).

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

   • Ce qui a été détecté, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Adresse e-mail du compte principal: compte qui a apporté les modifications (une adresse e-mail via un compte piraté).
     • IP: adresse IP du proxy où les modifications sont effectuées.
   • Ressource concernée
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 a été détecté en examinant Cloud Audit Logs pour voir si des déploiements de charges de travail utilisent l'option "bris de glace" pour ignorer 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 les détails du résultat s'affichent, affichant 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: <ph type="x-smartling-placeholder">
     </ph>
     • 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: <ph type="x-smartling-placeholder">
     </ph>
     • Nom à afficher pour la ressource: espace de noms GKE où le déploiement s'est produit.
   • Liens associés : <ph type="x-smartling-placeholder">
     </ph>
     • 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 Champ URI Cloud Logging.
2. Vérifiez la valeur du champ protoPayload.resourceName pour identifier le demande de signature de certificat spécifique.

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

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Remplacez les éléments suivants :

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

   • PRINCIPAL_EMAIL: la valeur que vous avez notée dans le Champ Adresse e-mail du compte principal dans les 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: Éviction 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 de la section Résultats associés. Sur la ligne Résultats associés de l'onglet Récapitulatif les détails de la recherche.
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 a été détecté en examinant Cloud Audit Logs pour vérifier si des mises à jour sont disponibles pour les charges de travail qui utilisent l'option "bris de glace" pour ignorer 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 les détails du résultat s'affichent, affichant 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: <ph type="x-smartling-placeholder">
     </ph>
     • 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: <ph type="x-smartling-placeholder">
     </ph>
     • Nom à afficher pour la ressource: espace de noms GKE où la mise à jour a eu lieu.
   • Liens associés : <ph type="x-smartling-placeholder">
     </ph>
     • 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 Champ URI Cloud Logging.
2. Vérifiez la valeur du champ protoPayload.resourceName pour identifier le demande de signature de certificat spécifique.

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

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Remplacez les éléments suivants :

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

   • PRINCIPAL_EMAIL: la valeur que vous avez notée dans le Champ Adresse e-mail du compte principal dans les 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: Éviction 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 de la section Résultats associés. Sur la ligne Résultats associés de l'onglet Récapitulatif les détails de la recherche.
3. Pour élaborer un plan d'intervention, combinez vos résultats d'enquête avec les recherches MITRE.

Defense Evasion: Manually Deleted Certificate Signing Request (CSR)

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.

Quelqu'un a supprimé manuellement une demande de signature de certificat (CSR). Les chargés de clientèle sont automatiquement supprimés par un contrôleur de récupération de mémoire, mais les acteurs malveillants peuvent les supprimer manuellement afin d'échapper à la détection. Si la requête de signature de certificat supprimée concernait a déjà été approuvé et délivré, l'acteur potentiellement malveillant dispose désormais d'un une méthode d'authentification supplémentaire pour accéder au cluster. Les autorisations associés au certificat varient en fonction de l’objet qu’ils ont inclus, mais peut être hautement privilégié. Kubernetes n'est pas compatible avec les certificats ou la révocation. Pour en savoir plus, consultez le message de journal de cette alerte.

1. Examiner les journaux d'audit dans Cloud Logging et les alertes supplémentaires pour d'autres liés à cette requête de signature de certificat pour déterminer si elle était approved et si la La création d'un requête de signature de certificat correspondait à une activité attendue du compte principal.
2. Déterminez s'il existe d'autres signes d'activité malveillante dans les journaux d'audit de Cloud Logging. Exemple :
   • Le compte principal qui a supprimé la requête de signature de certificat est-il différent de celui qui a créé la demande ? ou l'ont approuvée ?
   • Le compte principal a-t-il essayé de demander, de créer, d'approuver ou de supprimer ? avec d'autres conseillers clientèle ?
3. Si l'approbation du conseiller clientèle n'était pas attendue ou si elle est jugée malveillante, le nécessite une rotation des identifiants pour invalider le certificat. Suivez les conseils pour effectuer une rotation des identifiants du cluster.

Defense Evasion: Modify VPC Service Control

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

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

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

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

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

1. Ouvrez le résultat Defense Evasion: Modify VPC Service Control comme indiqué. dans l'article Examiner les résultats. Le panneau du résultat contenant des informations détaillées, ce qui affiche 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: <ph type="x-smartling-placeholder">
     </ph>
     • Adresse e-mail du compte principal: compte qui a effectué la modification.
   • Ressource concernée, en particulier le champ suivant: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: nom du périmètre VPC Service Controls. qui a été modifiée.
   • Liens associés : <ph type="x-smartling-placeholder">
     </ph>
     • 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: modifications, REMOVE ou ADD, sur un périmètre qui a réduit sa protection
       • restricted_resources : projets qui respectent les restrictions de ce périmètre. La protection est réduite si vous supprimez un projet
       • restricted_services : services dont l'exécution est interdite par les restrictions de ce périmètre. La protection est réduite si vous supprimez un service restreint
       • allowed_services : services autorisés à s'exécuter sous les restrictions de ce périmètre. La protection est réduite si vous ajoutez un service autorisé
       • access_levels : niveaux d'accès configurés pour autoriser l'accès aux ressources situées sous le périmètre La protection est réduite si vous ajoutez d'autres niveaux d'accès

Étape 2 : Vérifier les journaux

1. Dans l'onglet Résumé du panneau des détails du résultat, cliquez sur l'icône Lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
2. Rechercher les journaux des activités d'administration liés aux modifications apportées à VPC Service Controls à l'aide de les filtres suivants: <ph type="x-smartling-placeholder">
   </ph>
   • 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 de la section Résultats associés. Sur la ligne Résultats associés de l'onglet Récapitulatif les détails de la recherche.
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.

Defense Evasion: Potential Kubernetes Pod Masquerading

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.

Quelqu'un a déployé un pod avec une convention d'attribution de noms semblable aux charges de travail par défaut créés par GKE pour le fonctionnement normal du cluster. Cette technique s'appelle masqué. Pour en savoir plus, consultez le message de journal associé à cette alerte.

1. Vérifiez que le pod est légitime.
2. Déterminez s'il existe d'autres signes d'activité malveillante en provenance du pod dans les journaux d'audit de Cloud Logging.
3. Si le compte principal n'est pas un compte de service (IAM ou Kubernetes), contactez le propriétaire du compte pour vérifier si le propriétaire légitime mené l'action.
4. Si le compte principal est un compte de service (IAM ou Kubernetes), identifier la source de l'action afin de déterminer sa légitimité.
5. Si le pod n'est pas légitime, supprimez-le ainsi que tout RBAC associé et comptes de service utilisés par la charge de travail et qui lui ont permis création.

Discovery: Can get sensitive Kubernetes object check

Un acteur potentiellement malveillant a tenté de déterminer quels objets sensibles dans GKE qu'ils peuvent 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 en tant que indiquée dans la section Examiner les résultats.

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

   • Sous Ce qui a été détecté: <ph type="x-smartling-placeholder">
     </ph>
     • Examens d'accès Kubernetes: informations sur les examens d'accès demandés en fonction des SelfSubjectAccessReview ressource k8s.
     • Adresse e-mail du compte principal: compte qui a passé l'appel.
   • Sous Ressource concernée: <ph type="x-smartling-placeholder">
     </ph>
     • Resource display name (Nom à afficher pour la ressource) : le cluster Kubernetes dans lequel l'action s'est produit.
   • Sous Liens associés: <ph type="x-smartling-placeholder">
     </ph>
     • 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 l'icône Lien URI Cloud Logging pour ouvrir l'explorateur de journaux.

2. Sur la page qui s'affiche, vérifiez si d'autres actions ont été 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: la valeur que vous avez notée dans le Champ Nom à afficher de la ressource dans les détails du résultat.

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

3. Si le compte que vous avez noté à la ligne Adresse e-mail du compte principal obtenir des détails n'est pas un compte de service, contactez le propriétaire du compte pour vérifier si le propriétaire légitime mené 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 leur légitimité.

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

Execution: Kubernetes Pod Created with Potential Reverse Shell Arguments

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.

Quelqu'un a créé un pod contenant des commandes ou des arguments couramment associés via une interface système inversée. Attaquants utiliser des shells inversés pour développer ou conserver leur accès initial à un cluster ; pour exécuter des commandes arbitraires. Pour en savoir plus, consultez le message de journal correspondant alerte.

1. Confirmer que le pod a une raison légitime de spécifier ces commandes .
2. Déterminez s'il existe d'autres signes d'activité malveillante en provenance du pod dans les journaux d'audit de Cloud Logging.
3. Si le compte principal n'est pas un compte de service (IAM ou Kubernetes), contactez le propriétaire du compte pour vérifier si le propriétaire légitime mené l'action.
4. Si le compte principal est un compte de service (IAM ou Kubernetes), afin d'identifier la légitimité à l'origine de cette opération action
5. Si le pod n'est pas légitime, supprimez-le ainsi que tout RBAC associé et comptes de service utilisés par la charge de travail et qui lui ont permis création.

Execution: Suspicious Exec or Attach to a System Pod

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.

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

1. Consulter les journaux d'audit dans Cloud Logging pour déterminer si c'était attendu l'activité du compte principal.
2. Déterminez s'il existe d'autres signes d'activité malveillante principal dans les journaux.

Consultez les conseils sur l'utilisation du principe du moindre privilège pour les rôles RBAC et les clusters ayant autorisé cet accès.

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 possède selon le niveau de gravité:

• Sous-règle exfil_to_external_table dont la gravité est définie sur HIGH: <ph type="x-smartling-placeholder">
  </ph>
  • 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: <ph type="x-smartling-placeholder">
  </ph>
  • VPC Service Controls a bloqué une opération de copie ou une tentative d'accès aux ressources BigQuery.

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

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

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

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

   • Ce qui a été détecté : <ph type="x-smartling-placeholder">
     </ph>
     • Severity (Gravité) : la gravité correspond à HIGH pour la sous-règle. exfil_to_external_table ou 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 a été exfiltrée.
     • Cibles d'exfiltration: informations sur les tables où l'exfiltration a été effectuée ont été stockées.
   • Ressource concernée: <ph type="x-smartling-placeholder">
     </ph>
     • Resource full name (Nom complet de la ressource) : nom complet de la ressource du projet dossier ou organisation à partir duquel les données ont été exfiltrées.
   • Liens associés : <ph type="x-smartling-placeholder">
     </ph>
     • 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 examinez les champs affichés. notamment:

   • detectionCategory :
     • subRuleName: soit exfil_to_external_table, soit vpc_perimeter_violation
   • evidence :
     • sourceLogId :
       • projectId: projet Google Cloud qui contient l'ensemble de données BigQuery source.
   • properties
     • dataExfiltrationAttempt
       • jobLink: lien vers la tâche BigQuery que exfiltré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 enquêter sur ce problème. trouver. Google SecOps est un service Google Cloud qui vous permet analysent les menaces et réorientent les entités associées calendrier. Google SecOps enrichit les données de résultats, ce qui vous permet d'identifier des indicateurs d'intérêt et de simplifier les enquêtes.

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 de le résultat s'ouvre.

5. Dans la section Liens associés du panneau des détails du résultat, cliquez sur Examinez 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 de la pour trouver JSON.

3. Sur la page qui s'affiche, saisissez l'adresse e-mail dans le champ Filtre. figurant 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 l'icône Lien URI Cloud Logging pour ouvrir l'explorateur de journaux.

2. Rechercher les journaux des activités d'administration associés aux jobs BigQuery à l'aide de les 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 de la section Résultats associés. Sur la ligne Résultats associés de l'onglet Récapitulatif les détails de la recherche. 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 rechercher des informations sensibles dans les ensembles de données impactés, utilisez Sensitive Data Protection. Vous pouvez également envoyer des données sensibles sur la protection des données vers Security Command Center. En fonction de la quantité d'informations, Les coûts liés à la protection des données sensibles peuvent être importants. Suivez les bonnes pratiques pour conserver les coûts liés à la protection des données sensibles sous contrôle.
• 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 le 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. Panneau des détails du résultat ouvre l'onglet Résumé.

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

   • Ce qui a été détecté : <ph type="x-smartling-placeholder">
     </ph>
     • 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 a été exfiltrée.
     • Cibles d'exfiltration: informations sur les tables où l'exfiltration a été effectuée ont été stockées.
   • Ressource concernée: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: le nom de la ressource BigQuery ressource dont les données ont été exfiltrées.
     • Nom complet du projet: il s'agit du projet Google Cloud qui qui contient l'ensemble de données BigQuery source.
   • Liens associés : <ph type="x-smartling-placeholder">
     </ph>
     • 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 qui contient l'ensemble de données BigQuery source.
     • properties :
       • extractionAttempt :
       • jobLink: lien vers la tâche BigQuery que exfiltré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 de la à la recherche JSON (issue de l'étape 1).

3. Sur la page qui s'affiche, saisissez l'adresse e-mail dans le champ Filtre. figurant dans la section Adresse e-mail du compte principal (issue de l'étape 1) et vérifier quelles autorisations sont 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 l'icône Lien URI Cloud Logging pour ouvrir l'explorateur de journaux.
2. Recherchez les journaux d'activité d'administration liés aux tâches BigQuery à l'aide des filtres suivants :
   • protoPayload.methodName="Jobservice.insert"
   • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

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

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exfiltration over Web Service: Exfiltration to Cloud Storage (Exfiltration via service Web : Exfiltration vers Cloud Storage).
2. Examinez les résultats associés en cliquant sur le lien Sur la ligne Résultats associés de l'onglet Récapitulatif les détails de la recherche. 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. pour le compte principal indiqué sur la ligne Adresse e-mail du compte principal 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, identifiés Dans le champ Sources d'exfiltration de l'onglet Résumé de les détails de la recherche.
• Pour rechercher des informations sensibles dans les ensembles de données impactés, utilisez Sensitive Data Protection. Vous pouvez également envoyer des données sensibles sur la protection des données vers Security Command Center. En fonction de la quantité d'informations, Les coûts liés à la protection des données sensibles peuvent être importants. Suivez les bonnes pratiques pour conserver les coûts liés à la protection des données sensibles sous contrôle.
• 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, en tant que indiquée dans la section Examiner les résultats.

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

   • Ce qui a été détecté, y compris: <ph type="x-smartling-placeholder">
     </ph>
     • Adresse e-mail du compte principal: compte utilisé pour exfiltrer les données.
     • Sources d'exfiltration: informations détaillées sur BigQuery table à 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: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: le nom de la ressource BigQuery dont les données ont été exfiltrées.
     • Nom complet du projet: il s'agit du projet Google Cloud qui qui contient l'ensemble de données BigQuery source.
   • Liens associés, y compris: <ph type="x-smartling-placeholder">
     </ph>
     • 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 qui contient 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 de la à la recherche JSON (issue de l'étape 1).

3. Sur la page qui s'affiche, saisissez l'adresse e-mail dans le champ Filtre. indiqué dans access.principalEmail (de l'étape 1) et vérifier quelles autorisations sont 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 l'icône 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 section Résultats associés. Sur la ligne Résultats associés de l'onglet Récapitulatif les détails de la recherche. 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 rechercher des informations sensibles dans les ensembles de données impactés, utilisez Sensitive Data Protection. Vous pouvez également envoyer des données sensibles sur la protection des données vers Security Command Center. En fonction de la quantité d'informations, Les coûts liés à la protection des données sensibles peuvent être importants. Suivez les bonnes pratiques pour conserver les coûts liés à la protection des données sensibles sous contrôle.
• 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 le 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 l'article Examiner les résultats. Le panneau des détails ouvre 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: <ph type="x-smartling-placeholder">
     </ph>
     • Adresse e-mail du compte principal : compte utilisé pour exfiltrer les données.
     • Sources d'exfiltration: informations détaillées sur Cloud SQL. dont les données ont été exfiltrées.
     • Cibles d'exfiltration: informations détaillées sur Cloud Storage bucket vers lequel les données ont été exportées.
   • Ressource concernée, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: nom de la ressource Cloud SQL. dont les données ont été exfiltrées.
     • Nom complet du projet: il s'agit du projet Google Cloud qui qui contient les données Cloud SQL sources.
   • Liens associés, y compris: <ph type="x-smartling-placeholder">
     </ph>
     • 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 qui contient l'instance Cloud SQL source.
     • properties
     • bucketAccess : indique si le bucket Cloud Storage est accessible au public ou externe à l'organisation.
     • exportScope: quantité de données exportées, par exemple l'instance entière, une ou plusieurs bases de données, une ou plusieurs tables, ou un sous-ensemble spécifié par une requête)

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

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

   Accéder à IAM

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

3. Sur la page qui s'affiche, saisissez l'adresse e-mail dans le champ Filtre. sur la ligne Adresse e-mail du compte principal de l'onglet Récapitulatif les détails du résultat (étape 1). Vérifier les informations les autorisations sont attribuées au compte.

Étape 3 : Vérifier les journaux

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

É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 section Résultats associés. décrite à l'étape 1). Associée de résultats ont le même type de résultat sur le même Compute Engine.
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

Pour détecter l'exfiltration de données d'une sauvegarde Cloud SQL, examinez journaux d'audit pour déterminer si les données de la sauvegarde ont été restaurées Instance Cloud SQL externe à l'organisation ou au projet. Tout 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 dans les sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 les données de sauvegarde ont été restaurées.
   • Ressource concernée, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: nom de ressource de la sauvegarde qui a été ont été restaurées.
     • Nom complet du projet: le 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 qui contient 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 dans le résultat JSON (voir l'étape 1).

3. Sur la page qui s'affiche, saisissez l'adresse e-mail dans le champ Filtre. figurant dans la section Adresse e-mail du compte principal (issue de l'étape 1) et vérifier quelles autorisations sont attribuées au compte.

Étape 3 : Vérifier les journaux

1. Dans la console Google Cloud, accédez à l'explorateur de journaux en cliquant sur le lien dans l'URI Cloud Logging (depuis É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. (à partir de É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.
• Envisagez de révoquer les autorisations du compte principal. qui figure sur la ligne Adresse e-mail du compte principal de 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 quand tous les privilèges sur une base de données PostgreSQL fonctions ou procédures d'une base de données) sont attribuées à une ou plusieurs utilisateurs.

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

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

1. Ouvrir 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, examinez les informations dans les sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Database display name (Nom à afficher de la base de données) : nom de la base de données dans le 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 pour accorder le de droits.
     • Bénéficiaires de la base de données: bénéficiaires des droits trop larges.
   • Ressource concernée, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: nom de la ressource Cloud SQL. Instance PostgreSQL affectée.
     • Nom complet du parent: nom de la ressource de l'instance Cloud SQL Instance PostgreSQL.
     • Nom complet du projet: le projet Google Cloud contenant l'instance PostgreSQL Cloud SQL.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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. Utiliser la métacommande \l ou \list et vérifiez les droits attribués à la base de données Nom à afficher de la base de données (provenant de l'étape 1).
   • Fonctions ou procédures. Utilisez la métacommande \df et vérifier les droits attribués aux fonctions ou aux procédures dans le base de données répertoriée dans Nom à afficher de la base de données (de É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 (depuis É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 à 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'enquête soit terminée.
• Pour limiter l'accès à la base de données (dans Nom à afficher de la base de données de Étape 1, révoquer inutile autorisations accordées aux bénéficiaires (voir la section Bénéficiaires de la base de données de É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 à l'utilisateur tableaux. Le super-utilisateur (un rôle avec un accès très large) ne devrait généralement pas être pour écrire dans des tables utilisateur. Un compte utilisateur avec un accès plus limité doit être utilisé pour une activité quotidienne normale. Lorsqu'un super-utilisateur écrit dans une table utilisateur, cela peut indiquent qu'un pirate informatique a élevé des privilèges ou a compromis par défaut et modifie les données. Cela peut également indiquer un niveau normal, mais pratiques non sécurisées.

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, examinez les informations dans les sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Database display name (Nom à afficher de la base de données) : nom de la base de données dans le 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: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: nom de la ressource Cloud SQL. qui a été affectée.
     • Nom complet du parent: nom de la ressource de l'instance Cloud SQL Compute Engine.
     • Nom complet du projet: le projet Google Cloud contenant l'instance Cloud SQL.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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. Vérifier les journaux pgaudit pour PostgreSQL ou l'audit Cloud SQL pour MySQL Les journaux contenant les requêtes exécutées par le super-utilisateur à l'aide des filtres suivants: <ph type="x-smartling-placeholder">
   </ph>
   • 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 Créer et gérer des utilisateurs
  • Pour MySQL, consultez Gérer les utilisateurs avec l'authentification intégrée

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

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

• Envisagez de créer un utilisateur à accès limité pour les différents types de requêtes utilisé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 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 services Kubernetes suivants : les utilisateurs ou groupes d'utilisateurs par défaut pour créer une ressource Kubernetes dans le cluster:

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

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

Examinez la ressource créée et la liaison RBAC associée pour vous assurer que la liaison est nécessaire. Si la liaison n'est pas nécessaire, supprimez-la. Pour plus consultez le message de journal pour ce résultat.

Pour atténuer ce problème, consultez Évitez 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 services Kubernetes suivants : utilisateurs ou groupes d'utilisateurs par défaut pour modifier une ressource Kubernetes dans le cluster:

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

Ces utilisateurs et groupes sont effectivement anonymes. Un accès basé sur des rôles de contrôle (RBAC) dans votre cluster a été autorisé à modifier ces ressources dans le cluster.

Examinez la ressource modifiée et la liaison RBAC associée pour vous assurer que la liaison est nécessaire. Si la liaison n'est pas nécessaire, supprimez-la. Pour plus consultez le message de journal pour ce résultat.

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

Initial Access: Dormant Service Account Action

Détecte les événements où un service dormant géré par l'utilisateur account a déclenché une action. Dans ce contexte, un compte de service 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. Ouvrir Initial Access: Dormant Service Account Action , comme indiqué dans la section Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Résumé, notez les valeurs de les 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 le compte de service outils, comme Activité d'analyse, 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 les applications qui utilisent le compte de service pour s'authentifier perdent y accéder. Avant de continuer, votre équipe de sécurité doit identifier tous les applications et collaborent 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ù un service dormant géré par l'utilisateur account est créée. Dans ce contexte, un compte de service 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. Ouvrir Initial Access: Dormant Service Account Key Created , comme indiqué dans la section Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Résumé, notez les valeurs de les 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 le compte de service outils, comme Activité d'analyse, 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é du compte de service nouvellement créée dans 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 les applications qui utilisent le compte de service pour s'authentifier perdent y accéder. Avant de continuer, votre équipe de sécurité doit identifier tous les applications et collaborent 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 IAM l'outil de recommandation.

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 action. Dans ce contexte, une clé de compte de service divulguée est celle qui a été publiée sur l'Internet public. Par exemple, les clés de compte de service sont souvent publié sur le 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. Ouvrir Initial Access: Leaked Service Account Key Used , comme indiqué dans la section Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Résumé, notez les valeurs de les 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 dans les détails du résultat. Remplacez SERVICE_ACCOUNT_KEY_NAME par la valeur que vous avez notée dans dans le champ Nom de la clé du 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 la clé de compte de service immédiatement 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 les applications qui utilisent le compte de service pour s'authentifier perdent y accéder. Avant de procéder à la suppression, votre équipe de sécurité doit identifier tous les éléments concernés applications et collaborent 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 à plusieurs reprises un accès refusé des erreurs 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. Ouvrir Initial Access: Excessive Permission Denied Actions , comme indiqué dans la section Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Résumé, notez les valeurs du paramètre les 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 Propriétés sources, notez les valeurs de les champs suivants dans le fichier JSON:

   • properties.failedActions: les erreurs d'autorisation refusée qui se sont produites. Pour chaque entrée, les détails comprennent 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 dans les 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. Confirmer si le propriétaire légitime a mené l’action.
• Supprimer les ressources de projet créées par ce compte, comme celles que vous ne connaissez pas Instances, instantanés, comptes de service, utilisateurs IAM, etc. Compute Engine
• contacter le propriétaire du projet disposant du compte, et éventuellement supprimer ou désactiver 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, examinez les informations dans les 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 enquêter sur ce problème. trouver. Google SecOps est un service Google Cloud qui vous permet analyser les menaces et passer d'une entité similaire à une autre dans un environnement calendrier. Google SecOps enrichit les données de résultats, ce qui vous permet d'identifier des indicateurs d'intérêt et de simplifier les enquêtes.

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 Examinez 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 qui figure sur la ligne Adresse e-mail du compte principal Résumé des détails du résultat avec le filtre suivant: <ph type="x-smartling-placeholder">
   </ph>
   • 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: <ph type="x-smartling-placeholder">
     </ph>
     • Adresse e-mail du compte principal: compte ayant effectué les modifications
   • Ressource concernée
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 l'icône 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: Failed Attempt to Approve Kubernetes Certificate Signing Request (CSR)

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.

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

1. Examiner les journaux d'audit dans Cloud Logging et les alertes supplémentaires relatives aux autres requêtes de signature de certificat pour déterminer si une demande de signature de certificat a été approved et a été émise, et si un conseiller clientèle les actions associées sont l'activité attendue du compte principal.
2. Déterminez s'il existe d'autres signes d'activité malveillante dans les journaux d'audit de Cloud Logging. Exemple :
   • Le compte principal qui a tenté d'approuver la requête de signature de certificat est-il différent de celui-ci ? qui l'a créé ?
   • Le compte principal a-t-il essayé de demander, de créer, d'approuver ou de supprimer ? avec d'autres conseillers clientèle ?
3. Si l'approbation du conseiller clientèle n'était pas attendue ou si elle est jugée malveillante, le nécessite une rotation des identifiants pour invalider le certificat. Suivez les conseils pour effectuer une rotation des identifiants du cluster.

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

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.

Quelqu'un a approuvé manuellement une demande de signature de certificat (CSR). Créer un par certificat d'authentification de cluster est une méthode courante créer un accès persistant à un cluster compromis. Les autorisations associées avec le certificat varient en fonction de l’objet qu’ils ont inclus, mais peuvent être très privilégiés. Pour en savoir plus, consultez le message de journal de cette alerte.

1. Examiner les journaux d'audit dans Cloud Logging et les alertes supplémentaires relatives aux autres requêtes de signature de certificat pour déterminer si les actions liées au conseiller clientèle sont attendues le compte principal.
2. Déterminez s'il existe d'autres signes d'activité malveillante dans les journaux d'audit de Cloud Logging. Exemple :
   • Le compte principal qui a approuvé la requête de signature de certificat est-il différent de celui qui a créé la demande ? ?
   • Le chargé de clientèle a-t-il spécifié un signataire intégré, mais doit en fin de compte être approuvée parce qu'elle ne répondait pas aux critères du signataire ?
   • Le compte principal a-t-il essayé de demander, de créer, d'approuver ou de supprimer ? avec d'autres conseillers clientèle ?
3. Si aucune approbation de la requête de signature de certificat n'était attendue ou s'il est déterminé qu'il est malveillant, le cluster exigera une rotation des identifiants pour invalider le certificat. Suivez les conseils pour effectuer une rotation des identifiants du cluster.

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: <ph type="x-smartling-placeholder">
     </ph>
     • Adresse e-mail du compte principal: compte qui a effectué les modifications, ce qui pourrait être compromis.
   • Ressource concernée
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 l'icône 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 quand un pod default compte de service Kubernetes a été utilisé pour accéder aux objets Secret du cluster. L'API Kubernetes default compte de service ne doit pas avoir accès aux objets Secret, sauf si vous avec 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 des détails ouvre 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: <ph type="x-smartling-placeholder">
     </ph>
     • Adresse e-mail du compte principal: compte qui a effectué les modifications, ce qui pourrait être compromis.
   • Ressource concernée, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: la ressource pour laquelle le nouveau rôle a été attribué.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 l'icône 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 des détails ouvre 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: <ph type="x-smartling-placeholder">
     </ph>
     • 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, si disponibles.
     • Protocole: IANA qui est associé à la connexion.
   • Ressource concernée
   • Liens associés, y compris les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 la section champ suivant:

   • instanceDetails: notez l'ID du projet et le nom du Instance Compute Engine. L'ID du projet et le nom de l'instance apparaissent comme illustré dans l'exemple suivant:

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

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

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

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

   Accéder au tableau de bord

2. 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 recherches Java Naming and Directory Interface (JNDI) dans les en-têtes ou les paramètres d'URL sont détectés. Ces recherches peuvent indiquer des tentatives d'exploitation Log4Shell. Pour répondre à ce résultat, procédez comme suit :

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

1. Ouvrez un résultat Initial Access: Log4j Compromise Attempt, comme indiqué dans Examiner les détails des résultats Détails panneau du résultat ouvre l'onglet Synthèse.

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: <ph type="x-smartling-placeholder">
     </ph>
     • 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 recherche JNDI
     • requestUrl : URL de la requête HTTP. Le cas échéant, cela contient une recherche JNDI.
     • requestUserAgent : user-agent qui a envoyé la requête HTTP. Si ce champ est présent, il contient une recherche JNDI.
     • refererUrl : URL de la page qui a envoyé la requête HTTP. Si il contient une recherche JNDI.

Étape 2 : Vérifier les journaux

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

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

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

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

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

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

Le plan 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.
• Suivez les recommandations de Google Cloud pour examiner la situation et y répondre. dans le cluster "Apache Log4j 2" la faille de sécurité.
• Mettre en œuvre les techniques d'atténuation recommandées dans Failles de sécurité dans 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 Règle WAF Google Cloud Armor permettant de limiter la faille 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. Détails panneau du résultat ouvre l'onglet Synthèse.

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: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: le nom complet de la ressource Instance Compute Engine vulnérable à la RCE Log4j.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 de l'instance où la requête DNS a été faite.

Étape 2 : Vérifier les journaux

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

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

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

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

1. Examinez l'entrée du framework MITRE ATT&CK pour ce type de résultat : Exploitation des services à distance.
2. Examinez les résultats associés en cliquant sur le lien de la section Résultats associés. Sur la ligne Résultats associés de l'onglet Récapitulatif les détails de la recherche. 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.
• Suivez les recommandations de Google Cloud pour examiner la situation et y répondre. dans le cluster "Apache Log4j 2" la faille de sécurité.
• Mettre en œuvre les techniques d'atténuation recommandées dans Failles de sécurité dans 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 Règle WAF Google Cloud Armor permettant de limiter la faille 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. 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 les 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 enquêter et pour répondre aux résultats basés sur l'adresse IP. 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 Malware: Bad IP, comme indiqué dans Examiner les résultats. Le panneau des détails ouvre 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: <ph type="x-smartling-placeholder">
     </ph>
     • Domaine de l'indicateur: pour les résultats Bad domain, le domaine qui a déclenché le résultat.
     • Adresse IP de l'indicateur: pour les résultats Bad IP, l'adresse IP qui a déclenché le résultat.
     • Adresse IP source: pour les résultats Bad IP, une commande de logiciel malveillant connue et de contrôle de l'adresse IP.
     • Port source: pour les résultats Bad IP, le port source de .
     • Adresse IP de destination: pour les résultats Bad IP, l'adresse IP cible des logiciels malveillants.
     • Port de destination: port de destination pour les résultats Bad IP de la connexion.
     • Protocole: pour les résultats Bad IP, le Protocole de l'IANA associé à la connexion.
   • Ressource concernée, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Resource full name (Nom complet de la ressource) : nom complet de la ressource concernée Instance Compute Engine.
     • Nom complet du projet: nom complet de la ressource du projet que qui contient le résultat.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 Compute Engine.

Étape 2: Enquêtez sur Google Security Operations

Vous pouvez utiliser Google Security Operations pour enquêter sur ce problème. trouver. Google SecOps est un service Google Cloud qui vous permet analyser les menaces et passer d'une entité similaire à une autre dans un environnement calendrier. Google SecOps enrichit les données de résultats, ce qui vous permet d'identifier des indicateurs d'intérêt et de simplifier les enquêtes.

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 Examinez 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é à la ligne Nom complet du projet. dans l'onglet Récapitulatif.

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

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

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

Étape 4 : Vérifier les journaux

1. Dans l'onglet Résumé du panneau des détails du résultat, cliquez sur l'icône 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 avec le projet répertorié dans projectId.
     • SOURCE_IP par l'adresse IP indiquée sur la ligne Adresse IP source dans l'onglet Résumé des détails du résultat.

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

1. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat : Résolution dynamique et Commande et contrôle.
2. Examinez les résultats associés en cliquant sur le lien de la section Résultats associés. Sur la ligne Résultats associés de l'onglet Récapitulatif les détails de la recherche. 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 par 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.
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 des détails ouvre l'onglet Résumé.

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

   • Ce qui a été détecté <ph type="x-smartling-placeholder">
     </ph>
     • 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: <ph type="x-smartling-placeholder">
     </ph>
     • 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 d'instance et à la zone dans sourceInstanceDetails Examiner les détails de l'instance, y compris le réseau et les paramètres 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 l'icône 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 adresse 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 dans le résultat JSON.
     • DESTINATION_IP par l'adresse IP répertoriée ; dans le champ destIp dans le 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 de la section Résultats associés. Sur la ligne Résultats associés de l'onglet Récapitulatif les détails de la recherche. 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 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é attribué ou si une sensibilité moyenne a été attribué au niveau de l'organisation. Pour en savoir plus, consultez Rôles très sensibles.
  • MEDIUM, si un rôle de sensibilité moyenne a été accordé. Pour plus d'informations, voir 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é attribué ou si une sensibilité moyenne a été attribué au niveau de l'organisation. Pour en savoir plus, consultez Rôles très sensibles.
  • MEDIUM, si un rôle de sensibilité moyenne a été accordé. Pour plus d'informations, voir 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 des détails ouvre 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: <ph type="x-smartling-placeholder">
     </ph>
     • Adresse e-mail du compte principal: adresse e-mail de l'utilisateur ou du compte de service qui qui vous a 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 de une autorisation anormale qui s'est produite. La sous-règle détermine le niveau de gravité de ce résultat.
   • evidence :
     • sourceLogId :
     • projectId: ID du projet contenant le résultat.
   • properties :
     • sensitiveRoleGrant :
       • bindingDeltas :
       • Action: action 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 enquêter sur ce problème. trouver. Google SecOps est un service Google Cloud qui vous permet analyser les menaces et passer d'une entité similaire à une autre dans un environnement calendrier. Google SecOps enrichit les données de résultats, ce qui vous permet d'identifier des indicateurs d'intérêt et de simplifier les enquêtes.

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

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

   Accéder

2. Dans le panneau Filtres rapides, faites défiler la page 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 de ouvre les résultats.

5. Dans la section Liens associés du panneau des détails du résultat, cliquez sur Examinez 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 l'icône 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 section Résultats associés. dans l'onglet Résumé des détails du résultat. Les résultats associés sont le même type de résultat et la même instance et du 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 autorise ce compte principal pour emprunter l'identité d'un service dormant géré par l'utilisateur compte. Dans ce résultat, le compte de service dormant est le compte ressource, et un compte de service est considéré comme inactif s'il n'a 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. Ouvrir Persistence: Impersonation Role Granted for Dormant Service Account , comme indiqué dans la section Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Résumé, notez les valeurs de les 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 le compte de service outils, comme Activité d'analyse, 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 les applications qui utilisent le compte de service pour s'authentifier perdent y accéder. Avant de continuer, votre équipe de sécurité doit identifier tous les applications et collaborent 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 IAM l'outil de recommandation.

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 le l'employé correspondant a quitté l'entreprise, l'administrateur ne peut pas supprimer le compte. L'attribution de rôles sensibles à des comptes non gérés crée donc un risque risque de sécurité pour l'organisation.

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

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

1. Ouvrir Persistence: Unmanaged Account Granted Sensitive Role , comme indiqué dans la section Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Résumé, notez les valeurs de les 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. Consultez le propriétaire du champ Offending access grants.Principal name (Nom du compte principal). 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. et déplacer ce compte sous le contrôle des administrateurs système.

Persistence: New API Method

Une activité d'administration anormale d'un acteur potentiellement malveillant a été détectée dans un organisation, dossier ou 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é: <ph type="x-smartling-placeholder">
     </ph>
     • 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: <ph type="x-smartling-placeholder">
     </ph>
     • 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 Examiner les détails des résultats plus tôt dans cette section . 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: <ph type="x-smartling-placeholder">
  </ph>
  • Adresse e-mail du compte principal: compte utilisateur potentiellement piraté.
• Ressource concernée, en particulier les champs suivants: <ph type="x-smartling-placeholder">
  </ph>
  • Nom complet du projet: le nom du projet contenant le nom d'un compte utilisateur piraté.
• Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
  </ph>
  • 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 auxquels l'utilisateur accède habituellement 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 de la pour trouver JSON.

3. Sur la page qui s'affiche, saisissez le nom du compte dans le champ Filtre. répertoriés 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 l'icône 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 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é, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Adresse e-mail du compte principal: compte de service potentiellement piraté.
   • Ressource concernée, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet du projet: le nom du projet contenant le nom compte de service compromis.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 projet potentiellement compromis de service géré.
   • callerUserAgent: user-agent anormal
   • anomalousSoftwareClassification: type de logiciel
   • notSeenInLast: période utilisée pour établir une référence pour une comportemental.

É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, saisissez le nom du compte dans le champ Filtre. figurant sur la ligne Adresse e-mail du compte principal de l'onglet Récapitulatif des détails du résultat et vérifier 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, saisissez le nom du compte dans le champ Filtre. figurant sur la ligne Adresse e-mail du compte principal de l'onglet Récapitulatif des détails des résultats.

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 l'icône 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 élever un droit, un individu potentiellement malveillant a tenté de modifier un Accès basé sur des rôles ClusterRole, RoleBinding ou ClusterRoleBinding l'objet de contrôle (RBAC) du cluster-admin sensible à l'aide d'une requête PUT ou PATCH.

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

1. Ouvrir 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: <ph type="x-smartling-placeholder">
     </ph>
     • 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: les liens Kubernetes sensibles ou ClusterRoleBinding qui a été modifié.
   • Ressource concernée, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Resource display name (Nom à afficher pour la ressource) : le cluster Kubernetes dans lequel l'action s'est produit.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 Champ URI Cloud Logging.

2. Si la valeur dans Method name était une méthode PATCH, vérifiez la requête corps 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 le demande, donc les changements ne sont pas aussi clairs.

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

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Remplacez les éléments suivants :

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

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

5. Si l'adresse e-mail principale n'est pas compte de service, contactez son propriétaire pour vérifier si le que le propriétaire légitime a effectué 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 leur légitimité.

6. Pour élaborer un plan d'intervention, combinez les résultats de votre enquête avec étude MITRE.

Privilege Escalation: Create Kubernetes CSR for master cert

Pour élever des privilèges, un individu potentiellement malveillant a créé un maître Kubernetes requête de signature de certificat (CSR), ce qui lui donne cluster-admin y accéder.

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

1. Ouvrir Privilege Escalation: Create Kubernetes CSR for master cert comme indiqué dans la section Examiner les résultats. Le panneau des détails ouvre 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: <ph type="x-smartling-placeholder">
     </ph>
     • 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: <ph type="x-smartling-placeholder">
     </ph>
     • Resource display name (Nom à afficher pour la ressource) : le cluster Kubernetes dans lequel l'action s'est produit.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 Champ URI Cloud Logging.
2. Vérifiez la valeur du champ protoPayload.resourceName pour identifier le demande de signature de certificat spécifique.

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

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Remplacez les éléments suivants :

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

   • PRINCIPAL_EMAIL: la valeur que vous avez notée dans le Champ Adresse e-mail du compte principal dans les 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 compte de service, contactez son propriétaire pour vérifier si le que le propriétaire légitime a effectué 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 leur légitimité.

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

Privilege Escalation: Creation of sensitive Kubernetes bindings

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

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

1. Ouvrir 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: <ph type="x-smartling-placeholder">
     </ph>
     • Adresse e-mail du compte principal: compte qui a passé l'appel.
     • Liaisons Kubernetes: les liens Kubernetes sensibles ou ClusterRoleBinding qui a été créé.
   • Ressource concernée, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Resource display name (Nom à afficher pour la ressource) : le cluster Kubernetes dans lequel l'action s'est produit.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 Champ URI Cloud Logging.

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

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Remplacez les éléments suivants :

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

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

5. Si l'adresse e-mail principale n'est pas compte de service, contactez son propriétaire pour vérifier si le que le propriétaire légitime a effectué 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 leur légitimité.

6. Pour élaborer un plan d'intervention, combinez les résultats de votre enquête avec étude MITRE.

Privilege Escalation: Effectively Anonymous Users Granted GKE Cluster Access

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.

Quelqu'un a créé une liaison RBAC qui fait référence à l'un des utilisateurs ou groupes suivants:

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

Ces utilisateurs et groupes sont effectivement anonymes et doivent être évités lorsque créer des liaisons de rôles de cluster ou de rôles RBAC vers n'importe quel rôle RBAC. Consultez les pour s'assurer qu'elle est nécessaire. Si la liaison n'est pas nécessaire, supprimez Pour en savoir plus, consultez le message de journal de ce résultat.

1. Examinez les liaisons créées qui ont accordé des autorisations system:anonymous utilisateur, system:unauthenticated group ou Groupe system:authenticated.
2. Déterminez s'il existe d'autres signes d'activité malveillante dans les journaux d'audit de Cloud Logging.

En cas de signes d'activité malveillante, consultez les conseils pour examiner et supprimer les liaisons ayant autorisé cet accès.

Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials

Pour élever un droit d'accès, un individu potentiellement malveillant a demandé un certificat de signature (CSR), à l'aide de la commande kubectl, en utilisant dont les identifiants d'amorçage sont 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. Ouvrir 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: <ph type="x-smartling-placeholder">
     </ph>
     • 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: <ph type="x-smartling-placeholder">
     </ph>
     • Resource display name (Nom à afficher pour la ressource) : le cluster Kubernetes dans lequel l'action s'est produit.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 Nom de la méthode du résultat des détails, 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 Champ URI Cloud Logging.
2. Vérifiez la valeur du champ protoPayload.resourceName pour identifier le demande de signature de certificat spécifique.

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

1. Examinez les entrées du framework MITRE ATT&CK pour ce type de résultat: Élévation des privilèges.
2. Si la requête de signature de certificat spécifique est disponible dans le l'entrée de journal, examinez la sensibilité de l'entrée certificat et si l’action était justifiée.
3. Pour élaborer un plan d'intervention, combinez les résultats de votre enquête avec étude MITRE.

Privilege Escalation: Launch of privileged Kubernetes container

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

Le champ privileged d'un conteneur privilégié est défini sur true Un conteneur doté de capacités d'élévation des privilèges Champ allowPrivilegeEscalation défini sur true. Pour plus consultez la section SecurityContext v1 core dans la documentation de Kubernetes.

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

1. Ouvrir 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: <ph type="x-smartling-placeholder">
     </ph>
     • 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: <ph type="x-smartling-placeholder">
     </ph>
     • Resource display name (Nom à afficher pour la ressource) : le cluster Kubernetes dans lequel l'action s'est produit.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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: le conteneur privilégié a été tourné 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 Champ URI Cloud Logging.

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

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Remplacez les éléments suivants :

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

   • PRINCIPAL_EMAIL: la valeur que vous avez notée dans le Champ Adresse e-mail du compte principal dans les 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érifier que le conteneur créé nécessite un accès aux ressources de l'hôte du noyau.
3. Déterminez s'il existe d'autres signes d'activité malveillante principal dans les journaux.

4. Si l'adresse e-mail principale n'est pas un service votre compte, contactez son propriétaire pour vérifier s'il est légitime le propriétaire a effectué 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 leur légitimité.

5. Pour élaborer un plan d'intervention, combinez les résultats de votre enquête avec étude MITRE.

Privilege Escalation: Dormant Service Account Granted Sensitive Role

Détecte les événements où un rôle IAM sensible est attribué à un service géré par l'utilisateur inactif compte. Dans ce contexte, un compte de service 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. Ouvrir Privilege Escalation: Dormant Service Account Granted Sensitive Role , comme indiqué dans la section Examiner les résultats.

2. Dans les détails du résultat, dans l'onglet Résumé, notez les valeurs de les 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 le compte de service outils, comme Activité d'analyse, 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 les ressources qui utilisent le compte de service pour l'authentification perdent y accéder. Avant de continuer, votre équipe de sécurité doit identifier tous les des ressources et collaborent avec les propriétaires de ressources 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 IAM l'outil de recommandation.

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 l'administrateur Journaux d'audit des activités pour voir si une anomalie s'est produite dans un compte de service demande d'usurpation d'identité.

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

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

1. Ouvrez le résultat Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity, comme indiqué dans Examiner les résultats. Le panneau des détails ouvre 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: <ph type="x-smartling-placeholder">
     </ph>
     • Adresse e-mail du compte principal: compte de service final dans l'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: les détails des comptes de service dans le de délégation, le principal en bas de la liste est l'appelant de la demande d'usurpation d'identité.
   • Ressource concernée, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: nom du cluster.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 est anormale et si la sécurité d'un compte a été compromise.
3. Contactez le propriétaire de l'appelant d'emprunt d'identité dans le compte de service liste d'informations sur la délégation. Confirmez si le propriétaire légitime a mené la 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 les ressources qui utilisent le compte de service pour l'authentification perdent y accéder. Avant de continuer, votre équipe de sécurité doit identifier tous les des ressources et collaborent avec les propriétaires de ressources 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.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity

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

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

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

1. Ouvrez le résultat Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity, comme indiqué dans Examiner les résultats. Le panneau 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: <ph type="x-smartling-placeholder">
     </ph>
     • Adresse e-mail du compte principal: compte de service final dans l'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: les détails des comptes de service dans le de délégation, le principal en bas de la liste est l'appelant de la demande d'usurpation d'identité.
   • Ressource concernée
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 est anormale et si la sécurité d'un compte a été compromise.
3. Contactez le propriétaire de l'appelant d'emprunt d'identité dans le compte de service liste d'informations sur la délégation. Confirmez si le propriétaire légitime a mené la 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 les ressources qui utilisent le compte de service pour l'authentification perdent y accéder. Avant de continuer, votre équipe de sécurité doit identifier tous les des ressources et collaborent avec les propriétaires de ressources 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.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access

Anomalous Multistep Service Account Delegation a été détecté lors de l'examen des données Accéder aux journaux d'audit pour voir si une anomalie s'est produite dans un compte de service demande d'usurpation d'identité.

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

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

1. Ouvrez le résultat Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access, comme indiqué dans Examiner les résultats. Le panneau des détails ouvre 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: <ph type="x-smartling-placeholder">
     </ph>
     • Adresse e-mail du compte principal: compte de service final dans l'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: les détails des comptes de service dans le de délégation, le principal en bas de la liste est l'appelant de la demande d'usurpation d'identité
   • Ressource concernée
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 est anormale et si la sécurité d'un compte a été compromise.
3. Contactez le propriétaire de l'appelant d'emprunt d'identité dans le compte de service liste d'informations sur la délégation. Confirmez si le propriétaire légitime a mené la 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 les ressources qui utilisent le compte de service pour l'authentification perdent y accéder. Avant de continuer, votre équipe de sécurité doit identifier tous les des ressources et collaborent avec les propriétaires de ressources 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.

Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity

Anomalous Service Account Impersonator a été détecté en examinant l'administrateur Journaux d'audit des activités pour voir si une anomalie s'est produite dans un compte de service demande d'usurpation d'identité.

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

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

1. Ouvrez le résultat Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity, comme indiqué dans Examiner les résultats. Le panneau des détails ouvre 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 l'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: les détails des comptes de service dans le de délégation, le principal en bas de la liste est l'appelant de la demande d'usurpation 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 est anormale et si la sécurité d'un compte a été compromise.
3. Contactez le propriétaire de l'appelant d'emprunt d'identité dans le compte de service liste d'informations sur la délégation. Confirmez si le propriétaire légitime a mené la 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 les ressources qui utilisent le compte de service pour l'authentification perdent y accéder. Avant de continuer, votre équipe de sécurité doit identifier tous les des ressources et collaborent avec les propriétaires de ressources 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.

Privilege Escalation: Anomalous Service Account Impersonator for Data Access

Un emprunt d'identité de compte de service anormal est détecté en examinant l'accès aux données Journaux d'audit pour voir si des anomalies se sont produites lors de l'emprunt d'identité d'un compte de service requête.

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

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

1. Ouvrir le Privilege Escalation: Anomalous Service Account Impersonator for Data Access , comme indiqué dans la section Examiner les résultats.

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

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

   • Adresse e-mail du compte principal: compte de service final dans l'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: les détails des comptes de service dans le de délégation, le principal en bas de la liste est l'appelant de la demande d'usurpation 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 est anormale et si la sécurité d'un compte a été compromise.
3. Contactez le propriétaire de l'appelant d'emprunt d'identité dans le compte de service liste d'informations sur la délégation. Confirmez si le propriétaire légitime a mené la 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 les ressources qui utilisent le compte de service pour l'authentification perdent y accéder. Avant de continuer, votre équipe de sécurité doit identifier tous les des ressources et collaborent avec les propriétaires de ressources 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.

Privilege Escalation: ClusterRole with Privileged Verbs

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.

Quelqu'un a créé un objet RBAC ClusterRole contenant les éléments bind, escalate ou Verbes impersonate. Un sujet lié à un rôle avec ces verbes peut usurper l'identité d'autres utilisateurs disposant de droits plus élevés, associer à d'autres Role ou ClusterRole contenant des autorisations supplémentaires, ou qui modifient les leurs Autorisations ClusterRole. Cela pourrait amener ces sujets à gagner Droits cluster-admin. Pour en savoir plus, consultez le message de journal correspondant alerte.

1. Examinez les ClusterRole et les ClusterRoleBindings associés pour vérifier si les sujets ont réellement besoin de ces autorisations.
2. Si possible, évitez de créer des rôles qui impliquent les rôles bind, escalate ou Verbes impersonate.
3. Déterminez s'il existe d'autres signes d'activité malveillante dans les journaux d'audit de Cloud Logging.
4. Lorsque vous attribuez des autorisations dans un rôle RBAC, un privilège et n’accorde que les autorisations minimales nécessaires pour effectuer une tâche. En utilisant le principe du moindre privilège réduit le potentiel de privilège une escalade en cas de compromission de votre cluster, ce qui réduit la probabilité un accès excessif entraîne un incident de sécurité.

Privilege Escalation: ClusterRoleBinding to Privileged 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.

Quelqu'un a créé un RBAC ClusterRoleBinding qui fait référence au rôle par défaut system:controller:clusterrole-aggregation-controller, ClusterRole. Ce par défaut ClusterRole contient le verbe escalate, qui permet aux sujets de modifier les droits de leurs propres rôles, ce qui permet une élévation des privilèges. Pour plus consultez le message de journal de cette alerte.

1. Examinez tous les ClusterRoleBinding qui font référence au system:controller:clusterrole-aggregation-controller, ClusterRole.
2. Passez en revue les éventuelles modifications system:controller:clusterrole-aggregation-controller ClusterRole.
3. Déterminez s'il existe d'autres signes d'activité malveillante principal qui a créé l'ClusterRoleBinding dans les journaux d'audit dans Cloud Logging.

Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape

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.

Quelqu'un a déployé un pod avec une convention d'attribution de noms semblable à celle des outils courants s'échappe du conteneur ou pour exécuter d'autres attaques sur le cluster. Pour en savoir plus, consultez le message de journal associé à cette alerte.

1. Vérifiez que le pod est légitime.
2. Déterminez s'il existe d'autres signes d'activité malveillante en provenance du pod dans les journaux d'audit de Cloud Logging.
3. Si le compte principal n'est pas un compte de service (IAM ou Kubernetes), contactez le propriétaire du compte pour vérifier si le propriétaire légitime mené l'action.
4. Si le compte principal est un compte de service (IAM ou Kubernetes), identifier la source de l'action afin de déterminer sa légitimité.
5. Si le pod n'est pas légitime, supprimez-le ainsi que tout RBAC associé et comptes de service utilisés par la charge de travail et qui lui ont permis création.

Privilege Escalation: Workload Created with a Sensitive Host Path Mount

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.

Quelqu'un a créé une charge de travail contenant un montage de volume hostPath sur un un chemin d'accès sensible sur le système de fichiers du nœud hôte. Accès à ces chemins sur l'hôte peut être utilisé pour accéder à des informations privilégiées ou sensibles sur le et pour les échappements de conteneur. Si possible, n'autorisez aucun volume hostPath. dans votre cluster. Pour en savoir plus, consultez le message de journal de cette alerte.

1. Examinez la charge de travail pour déterminer si ce volume hostPath est nécessaire pour la fonctionnalité prévue. Si c'est le cas, assurez-vous que le chemin d'accès répertoire spécifique possible. Par exemple, /etc/myapp/myfiles au lieu de /. ou /etc.
2. Déterminez s'il existe d'autres signes d'activité malveillante à ce sujet. dans les journaux d'audit de Cloud Logging.

Pour bloquer les installations de volume hostPath dans le cluster, consultez les conseils sur l'application des normes de sécurité des pods.

Privilege Escalation: Workload with shareProcessNamespace enabled

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.

Un utilisateur a déployé une charge de travail avec l'option shareProcessNamespace définie sur true, ce qui permet à tous les conteneurs de partager le même espace de noms de processus Linux. Ce pourrait permettre à un conteneur non approuvé ou compromis d’élever ses privilèges en qui accèdent aux variables d'environnement, à la mémoire et à d'autres des données provenant de processus s'exécutant dans d'autres conteneurs. Certaines charges de travail peuvent nécessiter cette fonctionnalité pour des raisons légitimes, comme la gestion des journaux des conteneurs side-car ou de débogage. Pour en savoir plus, consultez le journal pour cette alerte.

1. Confirmer que la charge de travail nécessite réellement l'accès à un processus partagé pour tous les conteneurs de la charge de travail.
2. Vérifiez s'il existe d'autres signes d'activité malveillante de la part du compte principal dans les journaux d'audit dans Cloud Logging.
3. Si le compte principal n'est pas un compte de service (IAM ou Kubernetes), contactez le propriétaire du compte pour savoir s'il a bien effectué action.
4. Si le compte principal est un compte de service (IAM ou Kubernetes), afin d'identifier la légitimité à l'origine de cette opération action.

Service account self-investigation

Des identifiants de compte de service sont utilisés pour examiner les rôles et les autorisations associés à ce même compte de service. Ce résultat indique que les identifiants du compte de service pourraient être compromis et qu'une action immédiate doit être effectuée.

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

1. Ouvrez un résultat Discovery: Service Account Self-Investigation, comme indiqué. dans la section Examiner les détails des résultats. . 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: <ph type="x-smartling-placeholder">
     </ph>
     • Gravité: niveau de risque attribué au résultat La gravité est HIGH si l'appel d'API qui a déclenché ce résultat était non autorisé : le compte de service n'est pas autorisé à et interroger ses propres autorisations IAM 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: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource:
     • Nom complet du projet: le nom du projet contenant le projet potentiellement divulgué à l'aide d'identifiants de compte de service.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 de la pour trouver JSON.

3. Sur la page qui s'affiche, saisissez le nom du compte dans le champ Filtre. figurant 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 l'icône 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 sont des applications en cours d'exécution protégées par le service de sauvegarde et de reprise après sinistre. Après la suppression d'un hôte, les applications associées à l'hôte ne peuvent pas être sauvegardées.

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

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

1. Ouvrir Inhibit System Recovery: Deleted Google Cloud Backup and DR host , comme détaillé 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: <ph type="x-smartling-placeholder">
   </ph>
   • Ce qui a été détecté, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 <ph type="x-smartling-placeholder">
     </ph>
     • 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: <ph type="x-smartling-placeholder">
     </ph>
     • 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. Attention évaluer les informations que vous recueillez lors de votre enquête 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. 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 du 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. Ouvrir Inhibit System Recovery: Google Cloud Backup and DR remove plan , comme détaillé dans la section Examiner les résultats. Détails panneau du résultat ouvre l'onglet Synthèse.
2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes: <ph type="x-smartling-placeholder">
   </ph>
   • Ce qui a été détecté, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 <ph type="x-smartling-placeholder">
     </ph>
     • Nom à afficher pour la ressource: projet dans lequel le plan a été supprimé
   • Les liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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. Attention d’évaluer les informations que vous recueillez lors de votre enquête afin de déterminer la meilleure moyen de résoudre les résultats.

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 d’examiner les règles de sauvegarde pour chacune.

Inhibit System Recovery: Google Cloud Backup and DR delete template

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

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

1. Ouvrir Inhibit System Recovery: Google Cloud Backup and DR delete template , comme détaillé dans la section Examiner les résultats. Détails panneau du résultat ouvre l'onglet Synthèse.
2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes: <ph type="x-smartling-placeholder">
   </ph>
   • Ce qui a été détecté, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 <ph type="x-smartling-placeholder">
     </ph>
     • Resource display name (Nom à afficher de la ressource) : projet dans lequel le modèle a été supprimé
   • Les liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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. Attention d’évaluer les informations que vous recueillez lors de votre enquête afin de déterminer la meilleure moyen de résoudre les résultats.

1. Dans le projet où l'action a été effectuée, accédez à la console de gestion Google Cloud.
2. Dans l'onglet Gestionnaire d'applications, recherchez les applications concernées qui ne sont plus protégées et d’examiner les règles de sauvegarde pour chacune.
3. Pour ajouter à nouveau un modèle, accédez à l'onglet Plans de sauvegarde, puis 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. Ouvrir Inhibit System Recovery: Google Cloud Backup and DR delete policy , comme détaillé dans la section Examiner les résultats. Détails panneau du résultat ouvre l'onglet Synthèse.
2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes: <ph type="x-smartling-placeholder">
   </ph>
   • Ce qui a été détecté, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Nom de la règle: nom d'une seule règle, qui définit la sauvegarde la fréquence, le calendrier et la durée de conservation
     • Principal subject (Objet principal) : utilisateur qui a exécuté une action
   • Ressource concernée <ph type="x-smartling-placeholder">
     </ph>
     • Resource display name (Nom à afficher de la ressource) : projet dans lequel la stratégie a été supprimée
   • Les liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 Résumé, passez en revue les informations des sections suivantes: <ph type="x-smartling-placeholder">
   </ph>
   • Ce qui a été détecté, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 <ph type="x-smartling-placeholder">
     </ph>
     • Resource display name (Nom à afficher pour la ressource) : projet dans lequel le profil a été supprimé
   • Les liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 profils pour vous assurer qu'ils sont tous 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 Résumé, passez en revue les informations des sections suivantes: <ph type="x-smartling-placeholder">
   </ph>
   • Ce qui a été détecté, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 <ph type="x-smartling-placeholder">
     </ph>
     • Resource display name (Nom à afficher pour la ressource) : projet dans lequel le pool de stockage a été supprimé
   • Les liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 Résumé, passez en revue les informations des sections suivantes: <ph type="x-smartling-placeholder">
   </ph>
   • Ce qui a été détecté, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Nom de la règle: nom d'une seule règle, qui définit la fréquence, la programmation et la durée de conservation des sauvegardes
     • Nom du modèle: nom d'un ensemble de règles qui définissent la fréquence, la 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 <ph type="x-smartling-placeholder">
     </ph>
     • Resource display name (Nom à afficher de la ressource) : projet dans lequel l'image de back-up a été supprimée
   • Les liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 Résumé, passez en revue les informations des sections suivantes: <ph type="x-smartling-placeholder">
   </ph>
   • Ce qui a été détecté, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Nom de la règle: nom d'une seule règle, qui définit la fréquence, la programmation et la durée de conservation des sauvegardes
     • Nom du modèle: nom d'un ensemble de règles qui définissent la fréquence, la 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 <ph type="x-smartling-placeholder">
     </ph>
     • Resource display name (Nom à afficher de la ressource) : le projet dans lequel les images de sauvegarde ont été supprimées
   • Les liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 Résumé, passez en revue les informations des sections suivantes: <ph type="x-smartling-placeholder">
   </ph>
   • Ce qui a été détecté, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 <ph type="x-smartling-placeholder">
     </ph>
     • Resource display name (Nom à afficher pour la ressource) : projet dans lequel le dispositif a été supprimé
   • Les liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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, définissez une cible de stockage pour chaque nouveau dispositif. 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 pour 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. Ouvrir Impact: Google Cloud Backup and DR reduced backup expiration , comme détaillé dans la section Examiner les résultats. La le panneau des détails du résultat s'ouvre sur l'onglet Résumé.
2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes: <ph type="x-smartling-placeholder">
   </ph>
   • Ce qui a été détecté, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Description: informations sur la détection
     • Principal subject (Objet principal) : un utilisateur ou un compte de service qui a réussi a exécuté une action
   • Ressource concernée <ph type="x-smartling-placeholder">
     </ph>
     • 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: <ph type="x-smartling-placeholder">
     </ph>
     • 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. Attention d’évaluer les informations que vous recueillez lors de votre enquête afin de déterminer la meilleure moyen de résoudre les résultats.

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 une sauvegarde. la date d'expiration a été réduite et vérifiez qu'elle était prévue par le principal.
3. Pour lancer une nouvelle sauvegarde de l'application, sélectionnez Gérer les configurations de sauvegarde pour créer une sauvegarde à la demande ou pour planifier une nouvelle sauvegarde.

Impact: Google Cloud Backup and DR reduced backup frequency

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

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

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

1. Ouvrir Impact: Google Cloud Backup and DR reduced backup frequency , comme détaillé dans la section Examiner les résultats. La le panneau des détails du résultat s'ouvre sur l'onglet Résumé.
2. Dans l'onglet Résumé, passez en revue les informations des sections suivantes: <ph type="x-smartling-placeholder">
   </ph>
   • Ce qui a été détecté, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Description: informations sur la détection
     • Principal subject (Objet principal) : un utilisateur ou un compte de service qui a réussi a exécuté une action
   • Ressource concernée <ph type="x-smartling-placeholder">
     </ph>
     • Nom à afficher de la ressource: projet dans lequel la fréquence de sauvegarde a été réduit.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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. Attention d’évaluer les informations que vous recueillez lors de votre enquête afin de déterminer la meilleure moyen de résoudre les résultats.

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 une sauvegarde. la fréquence d’exposition a été réduite et de vérifier que le changement était prévu par principal.
3. Pour lancer une nouvelle sauvegarde de l'application, sélectionnez Gérer les configurations de sauvegarde pour créer une sauvegarde à la demande ou pour planifier une nouvelle sauvegarde.

Impact: Suspicious Kubernetes Container Names - Coin Mining

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.

Quelqu'un a déployé un pod avec une convention d'attribution de noms semblable à celle des cryptomonnaies courantes des mineurs de monnaie. Il peut s'agir d'une tentative de la part d'un attaquant l'accès au cluster afin d'utiliser ses ressources pour le minage de cryptomonnaie. Pour en savoir plus, consultez le message de journal de cette alerte.

1. Vérifiez que le pod est légitime.
2. Déterminez s'il existe d'autres signes d'activité malveillante en provenance du pod dans les journaux d'audit de Cloud Logging.
3. Si le compte principal n'est pas un compte de service (IAM ou Kubernetes), contactez le propriétaire du compte pour vérifier si le propriétaire légitime mené l'action.
4. Si le compte principal est un compte de service (IAM ou Kubernetes), identifier la source de l'action afin de déterminer sa légitimité.
5. Si le pod n'est pas légitime, supprimez-le ainsi que tout RBAC associé et comptes de service utilisés par la charge de travail et qui lui ont permis création.

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 Résumé, notez les valeurs des les 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 le compte de service outils, comme Activité d'analyse, 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.
• Envisagez d'utiliser le démarrage sécurisé de aux 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 les applications qui utilisent le compte de service pour s'authentifier perdent y accéder. Avant de continuer, votre équipe de sécurité doit identifier tous les applications et collaborent 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 quand tous les droits sur une base de données AlloyDB pour PostgreSQL (ou tous) fonctions ou procédures d'une base de données) sont attribuées à une ou plusieurs utilisateurs.

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

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

1. Ouvrir 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, examinez les informations dans les sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Database display name (Nom à afficher de la base de données) : nom de la base de données dans le 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 pour accorder le de droits.
     • Bénéficiaires de la base de données: bénéficiaires des droits trop larges.
   • Ressource concernée, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: nom de la ressource AlloyDB pour PostgreSQL qui a été affectée.
     • Nom complet du parent: nom de la ressource AlloyDB pour PostgreSQL Compute Engine.
     • Nom complet du projet: le projet Google Cloud contenant l'instance AlloyDB pour PostgreSQL.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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. Utiliser la métacommande \l ou \list et vérifiez les droits attribués à la base de données Nom à afficher de la base de données (provenant de l'étape 1).
   • Fonctions ou procédures. Utilisez la métacommande \df et vérifier les droits attribués aux fonctions ou aux procédures dans le base de données répertoriée dans Nom à afficher de la base de données (de É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 (depuis É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 à 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'enquête soit terminée.
• Pour limiter l'accès à la base de données (dans Nom à afficher de la base de données de Étape 1, révoquer inutile autorisations accordées aux bénéficiaires (voir la section Bénéficiaires de la base de données de Étape 1.

Privilege Escalation: AlloyDB Database Superuser Writes to User Tables

Détecte les cas où le compte super-utilisateur de la base de données AlloyDB pour PostgreSQL (postgres) écrit dans des tables utilisateur. Le super-utilisateur (rôle doté d'un accès très large) ne doivent pas être utilisées pour écrire dans des tables utilisateur. Un compte utilisateur avec un accès plus limité doit être utilisé pour une activité quotidienne normale. Lorsqu'un super-utilisateur écrit à un utilisateur qui pourrait indiquer qu'un pirate informatique a élever ses privilèges ou qu'il a compromis l’utilisateur de la base de données par défaut et modifie les données. Elle pourrait également indiquent 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, examinez les informations dans les sections suivantes:

   • Ce qui a été détecté, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Database display name (Nom à afficher de la base de données) : nom de la base de données dans le 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: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: nom de la ressource AlloyDB pour PostgreSQL qui a été affectée.
     • Nom complet du parent: nom de la ressource AlloyDB pour PostgreSQL Compute Engine.
     • Nom complet du projet: le projet Google Cloud contenant l'instance AlloyDB pour PostgreSQL.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 aux Instance AlloyDB pour PostgreSQL.
2. Rechercher les journaux pgaudit de PostgreSQL, qui contiennent les requêtes exécuté par le superutilisateur, à l'aide des filtres suivants: <ph type="x-smartling-placeholder">
   </ph>
   • 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 avec 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. Les journaux Google Workspace étant au niveau de l'organisation, Event Threat Detection ne peut les analyser que si vous activez Security Command Center au niveau de l'organisation.

Event Threat Detection enrichit les événements des journaux et écrit les résultats dans Security Command Center. Le tableau suivant contient les menaces Google Workspace, les entrées pertinentes du framework MITRE ATT&CK et les détails des événements qui déclenchent des résultats. Vous pouvez également vérifier les journaux à l'aide de filtres spécifiques et combiner toutes les informations pour répondre aux menaces Google Workspace.

Initial Access: Disabled Password Leak

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

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 qu'au niveau de l'organisation de Security Command Center. 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 de Cloud IDS sont générées par Cloud IDS, un service de sécurité qui surveille le trafic à destination et en provenance Ressources Google Cloud contre les menaces Lorsque Cloud IDS détecte un la menace, il envoie des informations sur la menace, telles que l'adresse IP source, adresse de destination et numéro de port à Event Threat Detection, qui émet ensuite une découverte de menace.

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

1. Ouvrir le résultat Cloud IDS: THREAT_ID, comme indiqué dans Examiner les résultats.

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

   • Ce qui a été détecté, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: projet contenant le réseau présentant la menace
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Cloud Logging URI (URI Cloud Logging) : lien vers Cloud IDS Logging entrées : ces entrées contiennent les informations nécessaires pour effectuer une recherche. Palo Alto Networks Threat Vault
   • Service de détection <ph type="x-smartling-placeholder">
     </ph>
     • 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 passé en revue les résultats, veuillez consulter le Documentation Cloud IDS sur l'examen des alertes de menace pour déterminer une réponse appropriée.

Vous trouverez plus d'informations sur l'événement détecté dans le journal d'origine en cliquant sur le lien dans le champ URI Cloud Logging du fichier plus de détails.

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. Ce est un résultat de faible gravité, car il se peut que votre organisation ne suive pas ce les bonnes pratiques. Il existe des les résultats Execution: Added Malicious Binary Executed lorsque le hachage du binaire est un indicateur connu de compromission (IoC). Pour répondre à ce constat, effectuer les opérations suivantes:

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

1. Ouvrez un résultat Added Binary Executed comme indiqué dans Examiner les résultats. Le panneau des détails ouvre 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: <ph type="x-smartling-placeholder">
     </ph>
     • 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: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: nom complet de la ressource. du cluster, y compris son numéro, son emplacement et son nom.

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 où Pod 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 Resource full name (Nom complet de la ressource) dans 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é sur la ligne Nom complet de la ressource dans Onglet Summary (Résumé) des détails du résultat et de l'espace de noms du pod 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 la 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 des outils 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 il se peut que votre organisation ne la respecte pas. Il y a les 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 Examiner les résultats. Le panneau des détails ouvre 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: <ph type="x-smartling-placeholder">
     </ph>
     • Binaire du programme: chemin complet du binaire de processus qui a chargé le bibliothèque.
     • Libraries (Bibliothèques) : détails sur la bibliothèque ajoutée.
     • Arguments: arguments fournis lors de l'appel du processus binaire.
   • Ressource concernée, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 où Pod 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 répertorié sur la ligne Nom complet de la ressource dans Onglet Summary (Résumé) des détails du résultat et de l'espace de noms du pod 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 des outils 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 était exécuté. Les pirates informatiques installent généralement les outils d'exploitation et les logiciels malveillants après le piratage initial. Pour répondre à ce résultat, procédez comme suit :

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

1. Ouvrez un résultat Execution: Added Malicious Binary Executed comme indiqué dans Examiner les résultats. Le panneau des détails ouvre 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: <ph type="x-smartling-placeholder">
     </ph>
     • 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: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: nom complet de la ressource. du cluster, y compris son numéro, son emplacement et son nom.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 où Pod 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 Resource full name (Nom complet de la ressource) dans 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é sur la ligne Nom complet de la ressource dans Onglet Summary (Résumé) des détails du résultat et de l'espace de noms du pod 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 la 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 des outils 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 par 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 Examiner les résultats. Le panneau des détails ouvre 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: <ph type="x-smartling-placeholder">
     </ph>
     • Binaire du programme: chemin complet du binaire de processus qui a chargé le bibliothèque.
     • Libraries (Bibliothèques) : détails sur la bibliothèque ajoutée.
     • Arguments: arguments fournis lors de l'appel du processus binaire.
     • 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: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: nom complet de la ressource. du cluster.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 où Pod 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 Resource full name (Nom complet de la ressource) dans 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é sur la ligne Nom complet de la ressource dans Onglet Summary (Résumé) des détails du résultat et de l'espace de noms du pod 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 les fichiers malveillants ajoutés bibliothèque.

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

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

1. Ouvrez un résultat Execution: Built in Malicious Binary Executed comme indiqué dans Examiner les résultats. Le panneau des détails ouvre 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: <ph type="x-smartling-placeholder">
     </ph>
     • 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: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: nom complet de la ressource. du cluster, y compris son numéro, son emplacement et son nom.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 où Pod 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 Resource full name (Nom complet de la ressource) dans 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é sur la ligne Nom complet de la ressource dans Onglet Summary (Résumé) des détails du résultat et de l'espace de noms du pod 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 la 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 des outils 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 par 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: Malicious Python executed

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.

Un modèle de machine learning a identifié du code Python exécuté comme malveillant. Les pirates informatiques peuvent utiliser Python pour transférer des outils et exécuter des commandes sans binaires. 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 Execution: Malicious Python executed comme indiqué dans Examiner les résultats. Le panneau des détails ouvre 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: <ph type="x-smartling-placeholder">
     </ph>
     • Binaire du programme: détails sur l'interpréteur qui a appelé le script.
     • Script: chemin absolu vers le nom du script sur le disque. ce L'attribut n'apparaît que pour les scripts écrits sur le disque, pas pour les valeurs littérales l'exécution d'un script, par exemple python3 -c.
     • Arguments: arguments fournis lors de l'appel du script.
   • Ressource concernée, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: nom complet de la ressource. du cluster, y compris son numéro, son emplacement et son nom nom

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 pour des raisons de performances. cela peut vous aider à enquêter
       • 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 où Pod 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 Resource full name (Nom complet de la ressource) dans Onglet Résumé des détails du résultat. Notez 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 Python a apporté les modifications voulues 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.

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 Examiner les résultats. Le panneau des détails ouvre 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: <ph type="x-smartling-placeholder">
     </ph>
     • 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: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: nom complet de la ressource. du cluster, y compris son numéro, son emplacement et son nom.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 où Pod 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 Resource full name (Nom complet de la ressource) dans 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é sur la ligne Nom complet de la ressource dans Onglet Summary (Résumé) des détails du résultat et de l'espace de noms du pod 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 la 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 des outils 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 par 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 Examiner les résultats. Le panneau des détails ouvre 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: <ph type="x-smartling-placeholder">
     </ph>
     • Binaire du programme: chemin complet du binaire de processus qui a chargé le bibliothèque.
     • Bibliothèques: détails sur la bibliothèque modifiée.
     • Arguments: arguments fournis lors de l'appel du processus binaire.
     • 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: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: nom complet de la ressource. du cluster.
   • Liens associés, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 où Pod 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 répertorié sur la ligne Nom complet de la ressource dans Onglet Summary (Résumé) des détails du résultat et de l'espace de noms du pod 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 le fichier malveillant modifié bibliothèque.

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 des outils 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 par 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 attaquants peuvent utiliser Bash pour transférer des outils et exécuter des commandes sans binaires. 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 des détails ouvre 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: <ph type="x-smartling-placeholder">
     </ph>
     • Binaire du programme: détails sur l'interpréteur qui a appelé le script.
     • Script: chemin absolu vers le nom du script sur le disque. ce L'attribut n'apparaît que pour les scripts écrits sur le disque, pas pour les valeurs littérales l'exécution d'un script (par exemple, bash -c).
     • Arguments: arguments fournis lors de l'appel du script.
   • Ressource concernée, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Nom complet de la ressource: nom complet de la ressource. du cluster, y compris son numéro, son emplacement et son nom nom

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 pour des raisons de performances. cela peut vous aider à enquêter
       • 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 où Pod 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 Resource full name (Nom complet de la ressource) dans Onglet Résumé des détails du résultat. Notez 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 des 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 d'arguments d'une processus exécutable. Les attaquants peuvent charger des logiciels malveillants ou des bibliothèques malveillantes par le biais d'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 des détails ouvre 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: <ph type="x-smartling-placeholder">
     </ph>
     • URI: URI malveillant observé.
     • Binaire ajouté: chemin complet du binaire de processus reçu. les arguments contenant l'URL malveillante.
     • Arguments: arguments fournis lors de l'appel du binaire de processus.
     • Environment variables (Variables d'environnement) : les variables d'environnement qui se trouvaient dans 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: <ph type="x-smartling-placeholder">
     </ph>
     • 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 éléments suivants : informations: <ph type="x-smartling-placeholder">
       </ph>
       • 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, dans l'attribut sourceProperties, notez la valeur de la propriété VM_Instance_Name.

É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 projet apparaît après /projects/ dans le nom complet de la ressource.

3. Cliquez sur le nom du cluster que vous avez noté dans Nom à afficher pour la ressource. (resource.display_name) du résumé des résultats. Les clusters s'ouvre.

4. Dans la section Métadonnées de la page **Détails du cluster, notez les des informations définies par l'utilisateur qui pourraient aider comme des informations permettant d'identifier le propriétaire du cluster.

5. Cliquez sur l'onglet Nœuds.

6. Dans la liste des nœuds, sélectionnez le nœud 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 Annotations, notez la valeur du paramètre 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 la trouver un résumé, 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é Nom complet de la ressource (resource.name) du résumé des résultats et, si nécessaire, l'espace de noms du pod (kubernetes.pods.ns) que vous avez noté.

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

6. Sur la page Détails du pod, notez les informations concernant le pod peut vous aider à neutraliser 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 de la commande 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é dans le résumé des résultats plus tôt.

   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. Vérifiez 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 des outils Ingress.
3. Pour élaborer un plan d'intervention, combinez les résultats de votre enquête avec étude 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 des détails ouvre 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: <ph type="x-smartling-placeholder">
     </ph>
     • Binaire du programme: chemin absolu du processus commencé par redirection de flux vers un socket distant.
     • Arguments: arguments fournis lors de l'appel du binaire de processus.
   • Ressource concernée, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • 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 où Pod 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 des 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 Examiner les résultats. Le panneau des détails ouvre 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: <ph type="x-smartling-placeholder">
     </ph>
     • 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: <ph type="x-smartling-placeholder">
     </ph>
     • 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 éléments suivants : informations: <ph type="x-smartling-placeholder">
       </ph>
       • 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 composants. +sourceProperties: +VM_Instance_Name: nom du nœud GKE où Pod 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 la trouver un résumé, 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é Nom complet de la ressource (resource.name) pour le résumé des résultats et, si nécessaire, 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 VM_Instance_Name. que vous avez notée précédemment dans le résultat JSON. Détails du pod s'ouvre.

6. Sur la page Détails du pod, notez les informations concernant le pod peut vous aider à neutraliser 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 Présentation de VM Threat Detection

Execution: Cryptocurrency Mining Hash Match

VM Threat Detection a détecté des activités de minage de cryptomonnaie en faisant correspondre la mémoire des hachages de programmes en cours d'exécution contre des hachages de mémoire de minage de cryptomonnaie connu logiciels.

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 principaux systèmes Linux distributions. 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 et reconnaît le noyau. Par exemple, s'il est personnalisé, build : le champ processes du résultat n'est pas renseigné.

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

     • Resource full name (Nom complet de la ressource) : nom complet de la ressource concernée l'instance de VM, y compris l'ID du projet qui la contient.

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

   • indicator
     • signatures :
       • memory_hash_signature: signature correspondant à la mémoire les hachages de pages.
       • detections
         • binary: nom de l'application de cryptomonnaie binaire (par exemple, linux--x86-64_ethminer_0.19.0_alpha.0_cuda10.0
         • percent_pages_matched: pourcentage de pages en mémoire correspondant aux pages d'applications de cryptomonnaies connues la base de données de hachage de la 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 Nom complet de la ressource l'onglet Résumé des détails du résultat.

3. Recherchez des signes d'intrusion dans les journaux sur l'instance de VM concernée. Pour Vérifiez par exemple la présence d'activités suspectes ou inconnues, ainsi que des signes de identifiants piratés.

É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 Sur la ligne Nom complet de la ressource dans l'onglet Résumé du les détails de la recherche.

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

4. Cliquez sur l'instance de VM correspondant au projet identifié. 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.

É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 de l'application détectée sont disponibles, prenez en compte les valeurs spécifiées dans le binaire du programme, les arguments et Lignes des noms de processus dans l'onglet Résumé des détails du résultat dans votre enquête.

   • Si les détails du processus ne sont pas disponibles, vérifiez si le nom binaire du fichier 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 grep pour rechercher les fichiers importants dans le stockage. Utilisez une partie significative le nom binaire dans votre modèle de recherche, dans ce cas, xmrig. Examinez le dans 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. Localiser le fichier exécutable de l'application dans l'espace de stockage de la VM, puis le supprimer.

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 sur la VM. associée aux correspondances de signature détectées.

     VM Threat Detection peut reconnaître les builds de noyau des principaux systèmes Linux distributions. 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 et reconnaît le noyau. Par exemple, s'il est personnalisé, build : le champ processes du résultat n'est pas renseigné.

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

     • Resource full name (Nom complet de la ressource) : nom complet de la ressource concernée l'instance de VM, 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 pour ce résultat, dans la vue détaillée de cliquez sur l'onglet JSON.

Étape 2 : Vérifier les journaux

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

   Accéder à l'explorateur de journaux

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

3. Recherchez des signes d'intrusion dans les journaux sur l'instance de VM concernée. Pour Vérifiez par exemple la présence d'activités suspectes ou inconnues, ainsi que des signes de identifiants piratés.

É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 listé 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 de l'application détectée sont disponibles, prenez en compte les valeurs spécifiées dans le binaire du programme, les arguments et Lignes des noms de processus dans l'onglet Résumé des détails du résultat dans votre enquête.

   • 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. Localiser le fichier exécutable de l'application dans l'espace de stockage de la VM, puis le supprimer.

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 sein d'une même à partir d'une source unique. Une même application peut déclencher simultanément Execution: Cryptocurrency Mining YARA Rule et Execution: Cryptocurrency Mining Hash Match findings

Pour répondre à un résultat combiné, suivez les instructions pour les deux 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 le des disques persistants afin d'identifier les 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 Récapitulatif 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: <ph type="x-smartling-placeholder">
     </ph>
     • Nom de la règle YARA: règle YARA correspondante.
     • Fichiers: l'UUID de partition et le chemin d'accès relatif du un fichier malveillant a été détecté.
   • Ressource concernée, en particulier les champs suivants: <ph type="x-smartling-placeholder">
     </ph>
     • Resource full name (Nom complet de la ressource) : nom complet de la ressource concernée l'instance de VM, y compris l'ID du projet qui la contient.

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

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

   • indicator
     • signatures :
       • yaraRuleSignature: une signature correspondant à la règle YARA qui a trouvé une correspondance.

É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 Nom complet de la ressource l'onglet Résumé des détails du résultat.

3. Recherchez des signes d'intrusion dans les journaux sur l'instance de VM concernée. Pour Vérifiez par exemple la présence d'activités suspectes ou inconnues, ainsi que des signes de identifiants piratés.

É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 listé 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 : La valeur VirusTotal est un service appartenant à Alphabet qui fournit du contexte sur des fichiers potentiellement malveillants, URL, domaines et adresses IP.

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 UUID de partition et le chemin relatif du fichier, reportez-vous au champ Fichiers sur l'onglet Résumé des détails du résultat. Pour faciliter la détection et 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 par le biais d'une réponse aux menaces playbook.

4. Pour l'analyse médico-légale, pensez à sauvegarder les machines virtuelles et les disques persistants standards. Pour en savoir plus, consultez l'article Protection des données options de la console Compute Engine dans la documentation Google Cloud.

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 la faille associée et d'erreurs de configuration.

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

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

   Accéder

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

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 la menace trouver.

   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 les suivants : affiché dans la colonne de droite, y compris le champ Nom complet .

6. Parmi les attributs affichés, sélectionnez le type d'attribut dans les résultats 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 à partir de laquelle vous avez copié les valeurs. la détection de la menace. La liste des valeurs affichée est mise à jour les valeurs qui correspondent à la valeur collée.

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

9. S'il y a beaucoup de résultats dans les résultats, filtrez les résultats par Sélectionnez des filtres supplémentaires dans le panneau Filtres rapides.

   Par exemple, pour n'afficher que Vulnerability et Misconfiguration résultats de classe contenant les valeurs des attributs sélectionnés, Faites défiler la page jusqu'à la section Trouver un cours des Filtres rapides. panneau, 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 le AutoFocus de la console Google Cloud.

Résoudre les menaces

Corriger les résultats d'Event Threat Detection et de Container Threat Detection n'est pas aussi simple comme la correction des erreurs de configuration et des vulnérabilités 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.

Étape suivante

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

• Voir Présentation de Container Threat Detection pour découvrir le fonctionnement du service.

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