Investigar amenazas y responder ante ellas

En este tema, se ofrece orientación informal para ayudarte a investigar las amenazas y responder a ellas, y a usar recursos adicionales con el fin de agregar contexto a los hallazgos de Security Command Center. Sigue estos pasos para comprender lo que sucedió durante un posible ataque y desarrollar respuestas posibles para los recursos afectados.

No se garantiza que las técnicas de esta página sean efectivas contra cualquier amenaza anterior, actual o futura que te encuentres. Consulta Soluciona amenazas para comprender por qué Security Command Center no proporciona una guía oficial de solución de amenazas.

Antes de comenzar

Necesitas funciones adecuadas de Identity and Access Management (IAM) para ver o editar los resultados y los registros, y modificar los recursos de Google Cloud. Si encuentras errores de acceso en Security Command Center, solicita asistencia a tu administrador y consulta Control de acceso a fin de obtener información sobre las funciones. A fin de resolver errores de recursos, consulta la documentación de los productos afectados.

Comprende los resultados de las amenazas

Event Threat Detection produce resultados de seguridad mediante la coincidencia de eventos en tus transmisiones de registros de Cloud Logging con indicadores de compromiso (IoC) conocidos. Los IoC, desarrollados por fuentes de seguridad internas de Google, identifican vulnerabilidades y ataques potenciales. Event Threat Detection también detecta amenazas a través de la identificación de tácticas, técnicas y procedimientos adversarios conocidos en tu transmisión de registro y mediante la detección de desviaciones del comportamiento pasado de tu organización o proyecto. Si activas el nivel Premium de Security Command Center a nivel de la organización, Event Threat Detection también puede analizar los registros de Google Workspace.

Container Threat Detection genera hallazgos mediante la recopilación y el análisis del comportamiento observado de bajo nivel en el kernel invitado de los contenedores.

Los resultados se escriben en Security Command Center. Si activas el nivel Premium de Security Command Center a nivel de la organización, también puedes configurar los resultados para que se escriban en Cloud Logging.

Revisa los resultados

Para revisar los hallazgos de amenazas en la consola de Google Cloud, sigue estos pasos:

  1. En la consola de Google Cloud, ve a la página Resultados de Security Command Center.

    Ir a resultados

  2. Si es necesario, selecciona tu proyecto, organización o carpeta de Google Cloud.

    Selector de proyectos

  3. En la sección Filtros rápidos, haz clic en un filtro apropiado para mostrar el resultado que necesitas en la tabla Resultados de la consulta de los resultados. Por ejemplo, si seleccionas Event Threat Detection o Container Threat Detection en la subsección Nombre visible de la fuente, solo los resultados del servicio seleccionado aparecen en los resultados.

    La tabla se propaga con los hallazgos de la fuente que seleccionaste.

  4. Para ver los detalles de un resultado específico, haz clic en el nombre del resultado en Category. El panel de detalles del resultado se expande para mostrar un resumen de los detalles del resultado.

  5. Para ver la definición JSON del resultado, haz clic en la pestaña JSON.

Los resultados proporcionan los nombres y los identificadores numéricos de los recursos involucrados en un incidente, junto con las variables de entorno y las propiedades de los elementos. Puedes usar esa información para aislar con rapidez los recursos afectados y determinar el alcance potencial de un evento.

Para ayudarte en la investigación, los hallazgos de las amenazas también contienen vínculos a los siguientes recursos externos:

  • Entradas del framework de MITRE ATT&CK. En el framework, se explican las técnicas de los ataques a los recursos en la nube y se proporciona orientación para solucionarlos.
  • VirusTotal, un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URL, dominios y direcciones IP potencialmente maliciosos.

En las siguientes secciones, se describen las respuestas posibles a los resultados de las amenazas.

Desactivación de hallazgos de amenazas

Después de resolver un problema que activó un hallazgo de amenaza, Security Command Center no establece automáticamente el estado del resultado en INACTIVE. El estado del hallazgo de una amenaza sigue siendo ACTIVE, a menos que configures de forma manual la propiedad state en INACTIVE.

En el caso de un falso positivo, considera dejar el estado del resultado como ACTIVE y, en su lugar, silenciarlo.

En el caso de los falsos positivos persistentes o recurrentes, crea una regla de silenciamiento. Configurar una regla de silencio puede reducir la cantidad de hallazgos que necesitas administrar, lo que facilita la identificación de una amenaza verdadera cuando se produce una.

Para una amenaza verdadera, antes de establecer el estado del hallazgo en INACTIVE, elimina la amenaza y completa una investigación exhaustiva de la amenaza detectada, el alcance de la intrusión y cualquier otro resultado y problema relacionado.

Para silenciar un hallazgo o cambiar su estado, consulta los siguientes temas:

Respuestas de Detección de eventos de amenazas

Para obtener más información sobre Event Threat Detection, consulta cómo funciona Event Threat Detection.

En esta sección, no se incluyen respuestas para los resultados que generan los módulos personalizados de Event Threat Detection, ya que tu organización define las acciones recomendadas para esos detectores.

Evasion: Access from Anonymizing Proxy

El acceso anómalo a partir de un proxy anónimo se detecta mediante el análisis de los Registros de auditoría de Cloud para las modificaciones del servicio de Google Cloud que se originaron en las direcciones IP de proxy anónimas, como las direcciones IP de Tor.

Para responder a estos resultados, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un resultado de Evasion: Access from Anonymizing Proxy, como se indica en Revisa los resultados. Se abrirá el panel de los detalles del resultado, que mostrará la pestaña Resumen.
  2. En la pestaña Resumen del panel de detalles del resultado, revisa los valores enumerados en las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Correo electrónico principal: La cuenta que realizó los cambios (una cuenta potencialmente comprometida).
      • IP: La dirección IP del proxy desde la que se realizan los cambios.
    • Recurso afectado
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
  3. De manera opcional, haz clic en la pestaña JSON para ver más campos de resultado.

Paso 2: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada de framework de MITRE ATT&CK de este tipo de resultado: Proxy: Multi-hop Proxy.
  2. Comunícate con el propietario de la cuenta en el campo principalEmail. Confirma si el propietario legítimo realizó la acción.
  3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Defense Evasion: Breakglass Workload Deployment Created

Breakglass Workload Deployment Created se detecta cuando se examinan los registros de auditoría de Cloud para ver si hay alguna implementación en las cargas de trabajo que usan la marca de emergencia para anular los controles de la autorización binaria.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado de Defense Evasion: Breakglass Workload Deployment Created, como se indica en Revisa los resultados. Se abrirá el panel de los detalles de los resultados y se mostrará la pestaña Summary.
  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Correo electrónico principal: La cuenta que realizó la modificación.
      • Nombre del método: El método al que se llamó.
      • Pods de Kubernetes: El nombre del Pod y el espacio de nombres
    • Recurso afectado, en especial el siguiente campo:
      • Nombre visible del recurso: El espacio de nombres de GKE en el que se produjo la implementación.
    • Vínculos relacionados:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.

Paso 2: Comprueba los registros

  1. En la pestaña Resumen de los detalles del resultado en la consola de Google Cloud, haz clic en el vínculo del campo URI de Cloud Logging para ir al Explorador de registros.
  2. Comprueba el valor en el campo protoPayload.resourceName para identificar la solicitud de firma de certificado específica.
  3. Verifica otras acciones que realizó la principal con los siguientes filtros:

    • resource.labels.cluster_name="CLUSTER_NAME"
    • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

      Reemplaza lo siguiente:

    • CLUSTER_NAME: El valor que anotaste en el campo Nombre visible del recurso en los detalles del resultado.

    • PRINCIPAL_EMAIL: El valor que anotaste en el campo Correo electrónico principal en los detalles del resultado.

Paso 3: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada del framework MITRE ATT&CK para este tipo de resultado: Defense Evasion: Evasión de Defensa: Implementación de la carga de trabajo de emergencia.
  2. Para revisar los resultados relacionados, haz clic en el vínculo de la sección Resultados relacionados de la fila Resultados relacionados de la pestaña Resumen de los detalles del resultado.
  3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Defense Evasion: Breakglass Workload Deployment Updated

Breakglass Workload Deployment Updated se detecta cuando se examinan los registros de auditoría de Cloud para ver si hay alguna actualización en las cargas de trabajo que usan la marca de emergencia para anular los controles de la autorización binaria.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado de Defense Evasion: Breakglass Workload Deployment Updated, como se indica en Revisa los resultados. Se abrirá el panel de los detalles de los resultados y se mostrará la pestaña Summary.
  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Correo electrónico principal: La cuenta que realizó la modificación.
      • Nombre del método: El método al que se llamó.
      • Pods de Kubernetes: El nombre del Pod y el espacio de nombres
    • Recurso afectado, en especial el siguiente campo:
      • Nombre visible del recurso: El espacio de nombres de GKE en el que se produjo la actualización
    • Vínculos relacionados:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.

Paso 2: Comprueba los registros

  1. En la pestaña Resumen de los detalles del resultado en la consola de Google Cloud, haz clic en el vínculo del campo URI de Cloud Logging para ir al Explorador de registros.
  2. Comprueba el valor en el campo protoPayload.resourceName para identificar la solicitud de firma de certificado específica.
  3. Verifica otras acciones que realizó la principal con los siguientes filtros:

    • resource.labels.cluster_name="CLUSTER_NAME"
    • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

      Reemplaza lo siguiente:

    • CLUSTER_NAME: El valor que anotaste en el campo Nombre visible del recurso en los detalles del resultado.

    • PRINCIPAL_EMAIL: El valor que anotaste en el campo Correo electrónico principal en los detalles del resultado.

Paso 3: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada del framework MITRE ATT&CK para este tipo de resultado: Defense Evasion: Evasión de Defensa: Implementación de la carga de trabajo de emergencia.
  2. Para revisar los resultados relacionados, haz clic en el vínculo de la sección Resultados relacionados de la fila Resultados relacionados de la pestaña Resumen de los detalles del resultado.
  3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Defense Evasion: Modify VPC Service Control

Este hallazgo no está disponible para activaciones a nivel de proyecto.

Los registros de auditoría se examinan para detectar cambios en los perímetros de los Controles del servicio de VPC que podrían reducir la protección que ofrece ese perímetro. Estos son algunos ejemplos:

  • Se quita un proyecto de un perímetro
  • Se agrega una política de nivel de acceso a un perímetro existente.
  • Se agregan uno o más servicios a la lista de servicios accesibles.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado de Defense Evasion: Modify VPC Service Control, como se indica en Revisa los resultados. Se abrirá el panel de los detalles del resultado, que mostrará la pestaña Resumen (Summary).
  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial el siguiente campo:
      • Correo electrónico principal: La cuenta que realizó la modificación.
    • Recurso afectado, en especial el siguiente campo:
      • Nombre completo del recurso: Es el nombre del perímetro de los Controles del servicio de VPC que se modificó.
    • Vínculos relacionados:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
  3. Haz clic en la pestaña JSON.

  4. En el archivo JSON, observa los siguientes campos.

    • sourceProperties
      • properties
        • name: el nombre del perímetro de los Controles del servicio de VPC que se modificó
        • policyLink: Es el vínculo a la política de acceso que controla el perímetro.
        • delta: Son los cambios, ya sea REMOVE o ADD, a un perímetro que redujo su protección.
        • restricted_resources: Son los proyectos que siguen las restricciones de este perímetro. La protección se reduce si quitas un proyecto
        • restricted_services: Son los servicios cuya ejecución está prohibida según las restricciones de este perímetro. La protección se reduce si quitas un servicio restringido
        • allowed_services: Son los servicios que pueden ejecutarse según las restricciones de este perímetro. La protección se reduce si agregas un servicio permitido
        • access_levels: Son los niveles de acceso que están configurados para permitir el acceso a los recursos bajo el perímetro. La protección se reduce si agregas más niveles de acceso.

Paso 2: Comprueba los registros

  1. En la pestaña Resumen del panel de detalles del resultado, haz clic en el vínculo URI de Cloud Logging para abrir el Explorador de registros.
  2. Encuentra los registros de actividad del administrador relacionados con los cambios de los Controles del servicio de VPC mediante los siguientes filtros:
    • protoPayload.methodName:"AccessContextManager.UpdateServicePerimeter"
    • protoPayload.methodName:"AccessContextManager.ReplaceServicePerimeters"

Paso 3: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada del framework de MITRE ATT&CK de este tipo de resultado: Defense Evasion: Modify Authentication Process.
  2. Para revisar los resultados relacionados, haz clic en el vínculo de la sección Resultados relacionados de la fila Resultados relacionados de la pestaña Resumen de los detalles del resultado.
  3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 4: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario de la política y el perímetro de los Controles del servicio de VPC.
  • Considera revertir los cambios del perímetro hasta que se complete la investigación.
  • Considera revocar las funciones de Access Context Manager en la principal que modificó el perímetro hasta que se complete la investigación.
  • Investiga cómo se usaron las protecciones reducidas. Por ejemplo, si la “API del Servicio de transferencia de datos de BigQuery” está habilitada o agregada como un servicio permitido, verifica quién comenzó a usar ese servicio y qué se transfiere.

Discovery: Can get sensitive Kubernetes object check

Un atacante potencialmente malicioso intentó determinar qué objetos sensibles de GKE puede consultar mediante el comando kubectl auth can-i get. En particular, el actor ejecutó cualquiera de los siguientes comandos:

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

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado de Discovery: Can get sensitive Kubernetes object check como se indica en Revisa los resultados.
  2. En los detalles del resultado, en la pestaña Resumen, anota los valores de los siguientes campos:

    • En Qué se detectó, haz lo siguiente:
      • Revisiones de acceso de Kubernetes: La información solicitada de revisión de acceso, basada en el recurso k8s SelfSubjectAccessReview.
      • Correo electrónico principal: La cuenta que realizó la llamada.
    • En Recurso afectado, haz lo siguiente:
      • Nombre visible del recurso: El clúster de Kubernetes en el que se produjo la acción.
    • En Vínculos relacionados, haz lo siguiente:
      • URI de Cloud Logging: Vincula a entradas de Logging.

Paso 2: Comprueba los registros

  1. En la pestaña Resumen del panel de detalles del resultado, haz clic en el vínculo URI de Cloud Logging para abrir el Explorador de registros.
  2. En la página que se carga, revisa si hay otras acciones que realizó la principal con los siguientes filtros:

    • resource.labels.cluster_name="CLUSTER_NAME"
    • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

      Reemplaza lo siguiente:

    • CLUSTER_NAME: El valor que anotaste en el campo Nombre visible del recurso en los detalles del resultado.

    • PRINCIPAL_EMAIL: El valor que anotaste en el campo Correo electrónico principal en los detalles del resultado.

Paso 3: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework MITRE ATT&CK para este tipo de resultado: descubrimiento.
  2. Confirma la sensibilidad del objeto consultado y determina si hay otros indicios de actividad maliciosa por parte de la principal en los registros.
  3. Si la cuenta que anotaste en la fila Correo electrónico principal en los detalles de búsqueda no es una cuenta de servicio, comunícate con el propietario de la cuenta para confirmar si el propietario legítimo realizó la acción.

    Si el correo electrónico principal es una cuenta de servicio (IAM o Kubernetes), identifica la fuente de la revisión de acceso para determinar su legitimidad.

  4. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación de MITRE.

Exfiltration: BigQuery Data Exfiltration

Los resultados que muestra Exfiltration: BigQuery Data Exfiltration contienen una de dos subreglas posibles. Cada subregla tiene una gravedad diferente:

  • Subregla exfil_to_external_table con gravedad = HIGH:
    • Se guardó un recurso fuera de tu organización o proyecto.
  • Subregla vpc_perimeter_violation con gravedad = LOW:
    • Los Controles del servicio de VPC bloquearon una operación de copia o un intento de acceso a los recursos de BigQuery.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado Exfiltration: BigQuery Data Exfiltration, como se indica en Revisa los resultados.
  2. En la pestaña Resumen del panel de detalles del resultado, revisa los valores enumerados en las siguientes secciones:

    • Qué se detectó:
      • Gravedad: La gravedad es HIGH para la subregla exfil_to_external_table o LOW para la subregla vpc_perimeter_violation.
      • Correo electrónico principal: La cuenta que se usa para robar los datos.
      • Fuentes de robo de datos: Detalles sobre las tablas de las que se extrajeron los datos.
      • Objetivos de robo de datos: Detalles sobre las tablas en las que se almacenaron los datos exfiltrados.
    • Recurso afectado:
      • Nombre completo del recurso: Es el nombre completo del recurso del proyecto, la carpeta o la organización de la que se extrajeron los datos.
    • Vínculos relacionados:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
      • Chronicle: Vínculo a Chronicle
  3. Haz clic en la pestaña Propiedades fuente y revisa los campos que se muestran, en especial:

    • detectionCategory:
      • subRuleName: Puede ser exfil_to_external_table o vpc_perimeter_violation.
    • evidence:
      • sourceLogId:
        • projectId: Es el proyecto de Google Cloud que contiene el conjunto de datos de origen de BigQuery.
    • properties
      • dataExfiltrationAttempt
        • jobLink: Es el vínculo al trabajo de BigQuery que robó datos.
        • query: Es la consulta en SQL que se ejecuta en el conjunto de datos de BigQuery.
  4. De manera opcional, haz clic en la pestaña JSON para obtener la lista completa de las propiedades JSON del resultado.

Paso 2: Investiga en Chronicle

Puedes usar Chronicle para investigar este resultado. Chronicle es un servicio de Google Cloud que te permite investigar amenazas y alternar por entidades relacionadas en un cronograma unificado. Chronicle enriquece los datos de los resultados, lo que te permite identificar indicadores de interés y simplificar las investigaciones.

Solo puedes usar Chronicle si activas Security Command Center a nivel de la organización.

  1. Ve a la pestaña Resultados de Security Command Center en la consola de Google Cloud.

    Ir a hallazgos

  2. En el panel Filtros rápidos, desplázate hacia abajo hasta Nombre visible de la fuente.

  3. En la sección Nombre visible de la fuente, selecciona Event Threat Detection.

    La tabla se propaga con los hallazgos de Event Threat Detection.

  4. En la tabla, en categoría, haz clic en un hallazgo de Exfiltration: BigQuery Data Exfiltration. Se abrirá el panel de detalles del resultado.

  5. En la sección Vínculos relacionados del panel de detalles del resultado, haz clic en Investigar en Chronicle.

  6. Sigue las instrucciones de la interfaz de usuario guiada de Chronicle.

Usa las siguientes guías para realizar investigaciones en Chronicle:

Paso 3: Revisa los permisos y la configuración

  1. En la consola de Google Cloud, ve a la página IAM.

    Ir a IAM

  2. Si es necesario, selecciona el proyecto que aparece en el campo projectId del JSON de resultado.

  3. En la página que aparece, en el cuadro Filtro, ingresa la dirección de correo electrónico que aparece en Correo electrónico principal y verifica qué permisos están asignados a la cuenta.

Paso 4: Comprueba los registros

  1. En la pestaña Resumen del panel de detalles del resultado, haz clic en el vínculo URI de Cloud Logging para abrir el Explorador de registros.
  2. Encuentra los registros de actividad del administrador relacionados con trabajos de BigQuery mediante los siguientes filtros:

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

Paso 5: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada del framework de MITRE ATT&CK para este tipo de resultado: Robo de datos en el servicio web: robo de datos en Cloud Storage.
  2. Para revisar los resultados relacionados, haz clic en el vínculo de la sección Resultados relacionados de la fila Resultados relacionados de la pestaña Resumen de los detalles del resultado. Los hallazgos relacionados son del mismo tipo de hallazgos en la misma instancia y red.
  3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 6: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

Exfiltration: BigQuery Data Extraction

El robo de datos de BigQuery se detecta mediante la examinación de los registros de auditoría en dos situaciones:

  • Un recurso se guarda en un bucket de Cloud Storage fuera de tu organización.
  • Un recurso se guarda en un bucket de Cloud Storage de acceso público que pertenece a tu organización.

En el caso de las activaciones a nivel de proyecto del nivel Premium de Security Command Center, este hallazgo está disponible solo si el nivel Estándar está habilitado en la organización superior.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un hallazgo de Exfiltration: BigQuery Data Extraction, como se indica en Revisa los hallazgos. El panel de detalles del resultado se abre en la pestaña Resumen.
  2. En la pestaña Resumen del panel de detalles del resultado, revisa los valores enumerados en las siguientes secciones:

    • Qué se detectó:
      • Correo electrónico principal: La cuenta que se usa para robar los datos.
      • Fuentes de robo de datos: Detalles sobre las tablas de las que se extrajeron los datos.
      • Objetivos de robo de datos: Detalles sobre las tablas en las que se almacenaron los datos exfiltrados.
    • Recurso afectado:
      • Nombre completo del recurso: Es el nombre del recurso de BigQuery cuyos datos se exfiltraron.
      • Nombre completo del proyecto: El proyecto de Google Cloud que contiene el conjunto de datos de origen de BigQuery.
    • Vínculos relacionados:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
  3. En el panel de detalles del resultado, haz clic en la pestaña JSON.

  4. En el archivo JSON, observa los siguientes campos.

    • sourceProperties:
      • evidence:
        • sourceLogId:
        • projectId: Es el proyecto de Google Cloud que contiene el conjunto de datos de origen de BigQuery.
      • properties:
        • extractionAttempt:
        • jobLink: Es el vínculo al trabajo de BigQuery que robó datos.

Paso 2: Revisa los permisos y la configuración

  1. En la consola de Google Cloud, ve a la página IAM.

    Ir a IAM

  2. Si es necesario, selecciona el proyecto que aparece en el campo projectId del JSON de resultado (del Paso 1).

  3. En la página que aparece, en el cuadro Filtro, ingresa la dirección de correo electrónico que aparece en Correo electrónico principal (del Paso 1) y verifica qué permisos están asignados a la cuenta.

Paso 3: Comprueba los registros

  1. En la pestaña Resumen del panel de detalles del resultado, haz clic en el vínculo URI de Cloud Logging para abrir el Explorador de registros.
  2. Busca los registros de actividad del administrador relacionados con los trabajos de BigQuery mediante los siguientes filtros:
    • protoPayload.methodName="Jobservice.insert"
    • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Paso 4: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada del framework de MITRE ATT&CK para este tipo de resultado: Robo de datos en el servicio web: robo de datos en Cloud Storage.
  2. Haz clic en el vínculo de la fila Resultados relacionados de la pestaña Resumen de los detalles del resultado para revisar los resultados relacionados. Los hallazgos relacionados son del mismo tipo de hallazgos en la misma instancia y red.
  3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 5: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

Exfiltration: BigQuery Data to Google Drive

El robo de datos de BigQuery se detecta mediante el análisis de los registros de auditoría para la siguiente situación:

  • Un recurso se guarda en una carpeta de Google Drive.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un resultado de Exfiltration: BigQuery Data to Google Drive, como se indica en Revisa los resultados.
  2. En la pestaña Resumen del panel de detalles del resultado, revisa la información en las siguientes secciones:

    • Qué se detectó, incluidos los siguientes:
      • Correo electrónico principal: La cuenta que se usa para robar los datos.
      • Fuentes de robo de datos: Detalles sobre la tabla de BigQuery de la que se extrajeron los datos.
      • Objetivos de robo de datos: Son detalles sobre el destino en Google Drive.
    • Recurso afectado, incluidos los siguientes:
      • Nombre completo del recurso: Es el nombre del recurso de BigQuery cuyos datos se robaron.
      • Nombre completo del proyecto: El proyecto de Google Cloud que contiene el conjunto de datos de origen de BigQuery.
    • Vínculos relacionados, incluidos los siguientes:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
  3. Para obtener más información, haz clic en la pestaña JSON.

  4. En el archivo JSON, observa los siguientes campos.

    • sourceProperties:
      • evidence:
        • sourceLogId:
        • projectId: Es el proyecto de Google Cloud que contiene el conjunto de datos de origen de BigQuery.
      • properties:
        • extractionAttempt:
        • jobLink: el vínculo al trabajo de BigQuery que robó datos

Paso 2: Revisa los permisos y la configuración

  1. En la consola de Google Cloud, ve a la página IAM.

    Ir a IAM

  2. Si es necesario, selecciona el proyecto que aparece en el campo projectId del JSON de resultado (del Paso 1).

  3. En la página que aparece, en el cuadro Filtro, ingresa la dirección de correo electrónico que aparece en access.principalEmail (del Paso 1) y verifica los permisos que se asignaron a la cuenta.

Paso 3: Comprueba los registros

  1. En la pestaña Resumen del panel de detalles del resultado, haz clic en el vínculo URI de Cloud Logging para abrir el Explorador de registros.
  2. Busca los registros de actividad del administrador relacionados con los trabajos de BigQuery mediante los siguientes filtros:
    • protoPayload.methodName="Jobservice.insert"
    • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Paso 4: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada del framework de MITRE ATT&CK para este tipo de resultado: Robo de datos en el servicio web: robo de datos en Cloud Storage.
  2. Para revisar los resultados relacionados, haz clic en el vínculo de la sección Resultados relacionados de la fila Resultados relacionados de la pestaña Resumen de los detalles del resultado. Los hallazgos relacionados son del mismo tipo de hallazgos en la misma instancia y red.
  3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 5: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

Exfiltration: Cloud SQL Data Exfiltration

El robo de datos de Cloud SQL se detecta mediante el análisis de los registros de auditoría en dos situaciones:

  • Los datos de la instancia publicada se exportan a un bucket de Cloud Storage fuera de la organización.
  • Datos de instancia en vivo exportados a un bucket de Cloud Storage que pertenece a la organización y que es de acceso público.

Se admiten todos los tipos de instancias de Cloud SQL.

En el caso de las activaciones a nivel de proyecto del nivel Premium de Security Command Center, este hallazgo está disponible solo si el nivel Estándar está habilitado en la organización superior.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un resultado de Exfiltration: Cloud SQL Data Exfiltration, como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen (Summary).
  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Correo electrónico principal : La cuenta que se usa para robar los datos.
      • Fuentes de robo de datos: Son detalles sobre la instancia de Cloud SQL cuyos datos se robaron.
      • Destinos de robo de datos: Detalles sobre el bucket de Cloud Storage al que se exportaron los datos
    • Recurso afectado, en especial los siguientes campos:
      • Nombre completo del recurso: El nombre del recurso de Cloud SQL cuyos datos se exfiltraron.
      • Nombre completo del proyecto: El proyecto de Google Cloud que contiene los datos de origen de Cloud SQL.
    • Vínculos relacionados, incluidos los siguientes:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
  3. Haz clic en la pestaña JSON.

  4. En el archivo JSON del resultado, observa los siguientes campos:

    • sourceProperties:
      • evidence:
      • sourceLogId:
        • projectId: Es el proyecto de Google Cloud que contiene el conjunto de datos de origen de BigQuery.
      • properties
      • bucketAccess: Es si el bucket de Cloud Storage es de acceso público o externo a la organización.
      • exportScope: Cantidad de datos que se exportaron, como toda la instancia, una o más bases de datos, una o más tablas o un subconjunto especificado por una consulta

Paso 2: Revisa los permisos y la configuración

  1. En la consola de Google Cloud, ve a la página IAM.

    Ir a IAM

  2. Si es necesario, selecciona el proyecto de la instancia que aparece en el campo projectId del JSON del resultado (del Paso 1).

  3. En la página que aparece, en el cuadro Filtro, ingresa la dirección de correo electrónico que aparece en la fila Correo electrónico principal en la pestaña Resumen de los detalles del resultado (del Paso 1). Verifica qué permisos están asignados a la cuenta.

Paso 3: Comprueba los registros

  1. En la consola de Google Cloud, haz clic en el vínculo en URI de Cloud Logging (del Paso 1) para ir al Explorador de registros. En la página Explorador de registros, se incluyen todos los registros relacionados con la instancia de Cloud SQL relevante.

Paso 4: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada del framework de MITRE ATT&CK para este tipo de resultado: Robo de datos en el servicio web: robo de datos en Cloud Storage.
  2. Para revisar los resultados relacionados, haz clic en el vínculo de la fila Resultados relacionados que se describió en el Paso 1. Los resultados relacionados tienen el mismo tipo de resultado en la misma instancia de Cloud SQL.
  3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 5: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto del cual se robaron datos.
  • Considera revocar los permisos de access.principalEmail hasta que se complete la investigación.
  • Para detener el robo de datos, agrega políticas de IAM restringidas a las instancias de Cloud SQL afectadas.
  • Para limitar el acceso a la API de Administrador de Cloud SQL y exportar desde ella, usa los Controles del servicio de VPC.
  • Para identificar y corregir funciones con demasiados permisos, usa el recomendador de IAM.

Exfiltration: Cloud SQL Restore Backup to External Organization

El robo de datos de una copia de seguridad de Cloud SQL se detecta mediante el análisis de los registros de auditoría para determinar si los datos de la copia de seguridad se restablecieron en una instancia de Cloud SQL fuera de la organización o el proyecto. Se admiten todos los tipos de instancias y copias de seguridad de Cloud SQL.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un resultado de Exfiltration: Cloud SQL Restore Backup to External Organization, como se indica en Revisa los resultados.
  2. En la pestaña Resumen del panel de detalles del resultado, revisa la información en las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Correo electrónico principal: La cuenta que se usa para robar los datos.
      • Fuentes de robo de datos: Son detalles sobre la instancia de Cloud SQL a partir de la cual se creó la copia de seguridad.
      • Destinos de robo de datos: Detalles sobre la instancia de Cloud SQL a la que se restablecieron los datos de la copia de seguridad
    • Recurso afectado, en especial los siguientes campos:
      • Nombre completo del recurso: El nombre del recurso de la copia de seguridad que se restableció.
      • Nombre completo del proyecto: El proyecto de Google Cloud que contiene la instancia de Cloud SQL a partir de la cual se creó la copia de seguridad.
  3. Vínculos relacionados, especialmente los siguientes campos:

    • URI de Cloud Logging: Vincula a entradas de Logging.
    • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
    • Resultados relacionados: vínculos a cualquier resultado relacionado.
  4. Haz clic en la pestaña JSON.

  5. En el archivo JSON, observa los siguientes campos.

    • resource:
      • parent_name: el nombre del recurso de la instancia de Cloud SQL a partir de la cual se creó la copia de seguridad.
    • evidence:
      • sourceLogId:
        • projectId: Es el proyecto de Google Cloud que contiene el conjunto de datos de origen de BigQuery.
    • properties:
      • restoreToExternalInstance:
        • backupId: el ID de la ejecución de la copia de seguridad que se restableció

Paso 2: Revisa los permisos y la configuración

  1. En la consola de Google Cloud, ve a la página IAM.

    Ir a IAM

  2. Si es necesario, selecciona el proyecto de la instancia que aparece en el campo projectId del JSON de resultado (del Paso 1).

  3. En la página que aparece, en el cuadro Filtro, ingresa la dirección de correo electrónico que aparece en Correo electrónico principal (del Paso 1) y verifica qué permisos están asignados a la cuenta.

Paso 3: Comprueba los registros

  1. En la consola de Google Cloud, haz clic en el vínculo en URI de Cloud Logging (del paso 1) para ir al Explorador de registros. En la página Explorador de registros, se incluyen todos los registros relacionados con la instancia de Cloud SQL relevante.

Paso 4: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada del framework de MITRE ATT&CK para este tipo de resultado: Robo de datos en el servicio web: robo de datos en Cloud Storage.
  2. Haz clic en el vínculo de la fila Resultados relacionados para revisar resultados relacionados. (del Paso 1). Los resultados relacionados tienen el mismo tipo de resultado en la misma instancia de Cloud SQL.
  3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 5: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto del cual se robaron datos.
  • Considera revocar los permisos de la principal que aparece en la fila Correo electrónico principal en la pestaña Resumen de los detalles del resultado hasta que se complete la investigación.
  • Para detener el robo de datos, agrega políticas de IAM restringidas a las instancias de Cloud SQL afectadas.
  • Para limitar el acceso a la API de Cloud SQL Admin, usa los Controles del servicio de VPC.
  • Para identificar y corregir funciones con demasiados permisos, usa el recomendador de IAM.

Exfiltration: Cloud SQL Over-Privileged Grant

Detecta cuándo se otorgan todos los privilegios de una base de datos de PostgreSQL (o todas las funciones o procedimientos de una base de datos) a uno o más usuarios de la base de datos.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado Exfiltration: Cloud SQL Over-Privileged Grant, como se indica en Revisa los resultados.
  2. En la pestaña Resumen del panel de detalles del resultado, revisa la información en las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Nombre visible de la base de datos: Es el nombre de la base de datos en la instancia de PostgreSQL en Cloud SQL afectada.
      • Nombre de usuario de la base de datos: El usuario de PostgreSQL que otorgó privilegios excesivos.
      • Consulta de la base de datos: Es la consulta de PostgreSQL ejecutada que otorgó los privilegios.
      • Beneficiarios de la base de datos: Los beneficiarios de privilegios demasiado amplios.
    • Recurso afectado, en especial los siguientes campos:
      • Nombre completo del recurso: El nombre del recurso de la instancia de PostgreSQL de Cloud SQL que se vio afectada.
      • Nombre completo superior: el nombre del recurso de la instancia de PostgreSQL de Cloud SQL.
      • Nombre completo del proyecto: El proyecto de Google Cloud que contiene la instancia de PostgreSQL de Cloud SQL.
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
  3. Para ver el JSON completo del resultado, haz clic en la pestaña JSON.

Paso 2: Revisa los privilegios de la base de datos

  1. Conéctate a la base de datos de PostgreSQL.
  2. Enumera y muestra los privilegios de acceso para lo siguiente:
    • Bases de datos. Usa el metacomando \l o \list y verifica qué privilegios están asignados para la base de datos que aparece en Nombre visible de la base de datos (del paso 1).
    • Funciones o procedimientos Usa el metacomando \df y verifica qué privilegios se asignan a las funciones o los procedimientos de la base de datos que aparece en Nombre visible de la base de datos (del Paso 1).

Paso 3: Comprueba los registros

  1. En la consola de Google Cloud, haz clic en el vínculo en URI de Cloud Logging (del paso 1) para ir al Explorador de registros. En la página Explorador de registros, se incluyen todos los registros relacionados con la instancia de Cloud SQL relevante.
  2. En el Explorador de registros, verifica los registros pgaudit de PostgreSQL, que registran las consultas ejecutadas en la base de datos, mediante los siguientes filtros:
    • protoPayload.request.database="var class="edit">database"

Paso 4: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada del framework MITRE ATT&CK para este tipo de resultado: Exfiltration Over Web Service.
  2. Para determinar si se necesitan pasos de corrección adicionales, combina los resultados de tu investigación con la investigación de MITRE.

Paso 5: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario de la instancia que tiene otorgamientos de privilegios excesivos.
  • Considera revocar todos los permisos de los beneficiarios que se enumeran en Beneficiarios de la base de datos hasta que se complete la investigación.
  • Para limitar el acceso a la base de datos (de la sección Nombre visible de la base de datos del Paso 1, revoke los permisos innecesarios de los beneficiarios (de los Beneficiarios de la base de datos del Paso 1).

Initial Access: Database Superuser Writes to User Tables

Detecta cuándo la cuenta de superusuario de la base de datos de Cloud SQL (postgres para PostgreSQL y root para MySQL) escribe en tablas de usuario. Por lo general, el superusuario (una función con acceso muy amplio) no debe usarse para escribir en las tablas de usuarios. Se debe usar una cuenta de usuario con acceso más limitado para realizar actividades diarias normales. Cuando un superusuario escribe en una tabla de usuario, eso podría indicar que un atacante escaló privilegios o que puso en riesgo al usuario predeterminado de la base de datos y está modificando datos. También podría indicar prácticas normales pero no seguras.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un resultado de Initial Access: Database Superuser Writes to User Tables, como se indica en Revisa los resultados.
  2. En la pestaña Resumen del panel de detalles del resultado, revisa la información en las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Nombre visible de la base de datos: Es el nombre de la base de datos en la instancia de PostgreSQL o MySQL de Cloud SQL afectada.
      • Nombre de usuario de la base de datos: el superusuario.
      • Consulta de base de datos: La consulta en SQL que se ejecuta mientras se escribe en las tablas de usuario.
    • Recurso afectado, en especial los siguientes campos:
      • Nombre completo del recurso: El nombre del recurso de la instancia de Cloud SQL que se vio afectada.
      • Nombre completo superior: el nombre del recurso de la instancia de Cloud SQL.
      • Nombre completo del proyecto: El proyecto de Google Cloud que contiene la instancia de Cloud SQL.
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
  3. Para ver el JSON completo del resultado, haz clic en la pestaña JSON.

Paso 2: Comprueba los registros

  1. En la consola de Google Cloud, ve al Explorador de registros mediante un clic en el vínculo en cloudLoggingQueryURI (del Paso 1). En la página Explorador de registros, se incluyen todos los registros relacionados con la instancia de Cloud SQL relevante.
  2. Verifica los registros de pgaudit de PostgreSQL o los registros de auditoría de Cloud SQL para MySQL, que contienen las consultas que ejecutó el superusuario mediante los siguientes filtros:
    • protoPayload.request.user="SUPERUSER"

Paso 3: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada del framework MITRE ATT&CK para este tipo de resultado: Exfiltration Over Web Service.
  2. Para determinar si se necesitan pasos de corrección adicionales, combina los resultados de tu investigación con la investigación de MITRE.

Paso 4: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

Initial Access: Dormant Service Account Action

Detecta eventos en los que una cuenta de servicio administrada por el usuario inactiva activó una acción. En este contexto, una cuenta de servicio se considera inactiva si ha estado inactiva durante más de 180 días.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado Initial Access: Dormant Service Account Action, como se indica en Revisa los resultados.
  2. En los detalles del resultado, en la pestaña Resumen, anota los valores de los siguientes campos.

    En Qué se detectó, haz lo siguiente:

    • Correo electrónico principal: La cuenta de servicio inactiva que realizó la acción
    • Nombre del servicio: El nombre de la API del servicio de Google Cloud al que accedió la cuenta de servicio
    • Nombre del método: El método al que se llamó

Paso 2: Investiga los métodos de ataque y respuesta

  1. Usa las herramientas de la cuenta de servicio, como el Analizador de actividad, para investigar la actividad de la cuenta de servicio inactiva.
  2. Comunícate con el propietario de la cuenta de servicio en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.

Paso 3: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se realizó la acción.
  • Considera borrar la cuenta de servicio potencialmente comprometida y rotar y borrar todas las claves de acceso a la cuenta de servicio para el proyecto potencialmente comprometido. Después de la eliminación, las aplicaciones que usan la cuenta de servicio para la autenticación pierden el acceso. Antes de continuar, el equipo de seguridad debe identificar todas las aplicaciones afectadas y trabajar con los propietarios de las aplicaciones para garantizar la continuidad del negocio.
  • Trabaja con tu equipo de seguridad para identificar recursos desconocidos, incluidos instancias de Compute Engine, instantáneas, cuentas de servicio y usuarios de IAM. Borra los recursos que no se crearon con cuentas autorizadas.
  • Responde las notificaciones de la asistencia de Google Cloud.
  • Para limitar quién puede crear cuentas de servicio, usa el Servicio de políticas de la organización.
  • Para identificar y corregir funciones con demasiados permisos, usa el recomendador de IAM.

Initial Access: Dormant Service Account Key Created

Detecta eventos en los que se crea una clave de cuenta de servicio administrada por el usuario inactiva. En este contexto, una cuenta de servicio se considera inactiva si ha estado inactiva durante más de 180 días.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado Initial Access: Dormant Service Account Key Created, como se indica en Revisa los resultados.
  2. En los detalles del resultado, en la pestaña Resumen, anota los valores de los siguientes campos.

    En Qué se detectó, haz lo siguiente:

    • Correo electrónico principal: El usuario que creó la clave de la cuenta de servicio

    En Recurso afectado, haz lo siguiente:

    • Nombre visible del recurso: La clave de cuenta de servicio inactiva recién creada
    • Nombre completo del proyecto: el proyecto donde reside esa cuenta de servicio inactiva

Paso 2: Investiga los métodos de ataque y respuesta

  1. Usa las herramientas de la cuenta de servicio, como el Analizador de actividad, para investigar la actividad de la cuenta de servicio inactiva.
  2. Comunícate con el propietario del campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.

Paso 3: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se realizó la acción.
  • Quita el acceso del propietario del correo electrónico principal si está comprometido.
  • Invalida la clave de la cuenta de servicio recién creada en la página Cuentas de servicio.
  • Considera borrar la cuenta de servicio potencialmente comprometida y rotar y borrar todas las claves de acceso a la cuenta de servicio para el proyecto potencialmente comprometido. Después de la eliminación, las aplicaciones que usan la cuenta de servicio para la autenticación pierden el acceso. Antes de continuar, el equipo de seguridad debe identificar todas las aplicaciones afectadas y trabajar con los propietarios de las aplicaciones para garantizar la continuidad del negocio.
  • Trabaja con tu equipo de seguridad para identificar recursos desconocidos, incluidos instancias de Compute Engine, instantáneas, cuentas de servicio y usuarios de IAM. Borra los recursos que no se crearon con cuentas autorizadas.
  • Responde las notificaciones de Atención al cliente de Cloud.
  • Para limitar quién puede crear cuentas de servicio, usa el Servicio de políticas de la organización.
  • Para identificar y corregir funciones demasiado permisivas, usa el recomendador de IAM.

Initial Access: Leaked Service Account Key Used

Detecta eventos en los que se usa una clave de cuenta de servicio filtrada para autenticar la acción. En este contexto, una clave de cuenta de servicio filtrada es aquella que se publicó en la Internet pública. Por ejemplo, las claves de cuentas de servicio se suelen publicar por error en un repositorio público de GitHub.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado Initial Access: Leaked Service Account Key Used, como se indica en Revisa los resultados.
  2. En los detalles del resultado, en la pestaña Resumen, anota los valores de los siguientes campos.

    En Qué se detectó, haz lo siguiente:

    • Correo electrónico principal: La cuenta de servicio que se usa en esta acción
    • Nombre del servicio: El nombre de la API del servicio de Google Cloud al que accedió la cuenta de servicio
    • Nombre del método: El nombre del método de la acción
    • Nombre de la clave de la cuenta de servicio: La clave de la cuenta de servicio filtrada que se usa para autenticar esta acción
    • Descripción: Es la descripción de lo que se detectó, incluida la ubicación en la Internet pública donde se puede encontrar la clave de la cuenta de servicio.

    En Recurso afectado, haz lo siguiente:

    • Nombre visible del recurso: El recurso involucrado en la acción

Paso 2: Comprueba los registros

  1. En la consola de Google Cloud, haz clic en el vínculo en URI de Cloud Logging para ir al Explorador de registros.
  2. En la barra de herramientas de la consola de Google Cloud, selecciona tu organización o proyecto.
  3. En la página que se carga, busca los registros relacionados con el siguiente filtro:

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

    Reemplaza PRINCIPAL_EMAIL por el valor que anotaste en el campo Correo electrónico principal en los detalles del resultado. Reemplaza SERVICE_ACCOUNT_KEY_NAME por el valor que anotaste en el campo Nombre de la clave de la cuenta de servicio en los detalles del resultado.

Paso 3: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Revoca la clave de la cuenta de servicio de inmediato en la página Cuentas de servicio.
  • Elimina la página web o el repositorio de GitHub donde se publica la clave de la cuenta de servicio.
  • Considera borrar la cuenta de servicio comprometida.
  • Rota y borra todas las claves de acceso a la cuenta de servicio del proyecto potencialmente comprometido. Después de la eliminación, las aplicaciones que usan la cuenta de servicio para la autenticación pierden el acceso. Antes de borrarla, tu equipo de seguridad debe identificar todas las aplicaciones afectadas y trabajar con los propietarios de aplicaciones para garantizar la continuidad del negocio.
  • Trabaja con tu equipo de seguridad para identificar recursos desconocidos, incluidos instancias de Compute Engine, instantáneas, cuentas de servicio y usuarios de IAM. Borra los recursos que no se crearon con cuentas autorizadas.
  • Responde las notificaciones de Atención al cliente de Cloud.

Initial Access: Excessive Permission Denied Actions

Detecta eventos en los que una principal activa de forma repetida errores de permiso denegado en varios métodos y servicios.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado Initial Access: Excessive Permission Denied Actions, como se indica en Revisa los resultados.
  2. En los detalles del resultado, en la pestaña Resumen, anota los valores de los siguientes campos.

    En Qué se detectó, haz lo siguiente:

    • Correo electrónico principal: La principal que activó varios errores de permiso denegado
    • Nombre del servicio: El nombre de la API del servicio de Google Cloud en el que se produjo el último error de permiso denegado
    • Nombre del método: El método al que se llamó cuando se produjo el último error de denegación de permiso
  3. En los detalles del resultado, en la pestaña Propiedades fuente, anota los valores de los siguientes campos en el JSON:

    • properties.failedActions: los errores de permiso denegado que se produjeron. Los detalles de cada entrada incluyen el nombre del servicio, el nombre del método, la cantidad de intentos fallidos y la hora en que se produjo el error por última vez. Se muestra un máximo de 10 entradas.

Paso 2: Comprueba los registros

  1. En la consola de Google Cloud, haz clic en el vínculo en URI de Cloud Logging para ir al Explorador de registros.
  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto.
  3. En la página que se carga, busca los registros relacionados con el siguiente filtro:

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

    Reemplaza PRINCIPAL_EMAIL por el valor que anotaste en el campo Correo electrónico principal en los detalles del resultado.

Paso 3: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada de framework de MITRE ATT&CK de este tipo de hallazgo: Cuentas válidas: Cuentas de Cloud.
  2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 4: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario de la cuenta en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.
  • Borrar los recursos del proyecto que haya creado esa cuenta, como instancias desconocidas de Compute Engine, instantáneas, cuentas de servicio, usuarios de IAM, etcétera
  • Comunícate con el propietario del proyecto que tiene la cuenta y bórrala o inhabilita la cuenta.

Brute Force: SSH

Detección de fuerza bruta SSH exitosa en un host Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un hallazgo de Brute Force: SSH, como se indica en Revisa los hallazgos.
  2. En la pestaña Resumen del panel de detalles del resultado, revisa la información en las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:

      • IP del llamador: La dirección IP que inició el ataque.
      • Nombre de usuario: La cuenta con la que se accedió
    • Recurso afectado

    • Vínculos relacionados, especialmente los siguientes campos:

      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
      • Chronicle: Vínculo a Chronicle
  3. Haz clic en la pestaña JSON.

  4. En el archivo JSON, observa los siguientes campos.

    • sourceProperties:
      • evidence:
        • sourceLogId: El ID del proyecto y la marca de tiempo para identificar la entrada de registro
        • projectId: el proyecto que contiene el hallazgo
      • properties:
        • attempts:
        • Attempts: la cantidad de intentos de acceso
          • username: la cuenta con la que accediste
          • vmName: Es el nombre de la máquina virtual.
          • authResult: el resultado de la autenticación de SSH

Paso 2: Investiga en Chronicle

Puedes usar Chronicle para investigar este resultado. Chronicle es un servicio de Google Cloud que te permite investigar amenazas y alternar por entidades relacionadas en un cronograma fácil de usar. Chronicle enriquece los datos de los resultados, lo que te permite identificar indicadores de interés y simplificar las investigaciones.

Solo puedes usar Chronicle si activas Security Command Center a nivel de la organización.

  1. Ve a la pestaña Resultados de Security Command Center en la consola de Google Cloud.

    Ir a hallazgos

  2. En el panel Filtros rápidos, desplázate hacia abajo hasta Nombre visible de la fuente.

  3. En la sección Nombre visible de la fuente, selecciona Event Threat Detection.

    Una tabla se propaga con los resultados para el tipo de fuente que seleccionaste.

  4. En la tabla, en categoría, haz clic en un hallazgo de Brute Force: SSH. Se abrirá el panel de detalles del resultado.

  5. En la sección Vínculos relacionados del panel de detalles del resultado, haz clic en Investigar en Chronicle.

  6. Sigue las instrucciones de la interfaz de usuario guiada de Chronicle.

Usa las siguientes guías para realizar investigaciones en Chronicle:

Paso 3: Revisa los permisos y la configuración

  1. En la consola de Google Cloud, ve al Panel.

    Ir al panel

  2. Haz clic en la lista desplegable Seleccionar desde en la parte superior de la página. En la ventana Seleccionar una opción que aparece, elige el proyecto que aparece en projectId.

  3. Navega a la tarjeta Recursos y haz clic en Compute Engine.

  4. Haz clic en la instancia de VM que coincide con el nombre y la zona en vmName. Revisa los detalles de la instancia, incluida la configuración de red y acceso.

  5. En el panel de navegación, haz clic en Red de VPC y, luego, en Firewall. Quita o inhabilita las reglas de firewall cos demasiados permisos en el puerto 22.

Paso 4: Comprueba los registros

  1. En la consola de Google Cloud, haz clic en el vínculo en URI de Cloud Logging para ir al Explorador de registros.
  2. En la página que se carga, busca los registros de flujo de VPC relacionados con la dirección IP que aparece en la fila Correo electrónico principal en la pestaña Resumen de los detalles del resultado mediante el siguiente filtro:
    • logName="projects/projectId/logs/syslog"
    • labels."compute.googleapis.com/resource_name"="vmName"

Paso 5: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada de framework de MITRE ATT&CK de este tipo de hallazgo: Cuentas válidas: Cuentas locales.
  2. Para revisar resultados relacionados, haz clic en el vínculo de la sección Resultados relacionados de la fila Resultados relacionados de la pestaña Resumen de los detalles del resultado. Los hallazgos relacionados tienen el mismo tipo de resultado, y la misma instancia y red.
  3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 6: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se aplicó fuerza bruta de forma exitosa.
  • Investiga la instancia potencialmente comprometida y quita cualquier software malicioso que se haya descubierto. Para ayudar con la detección y la eliminación, usa una solución de detección y respuesta de extremos.
  • Considera inhabilitar el acceso SSH a la VM. Para obtener información sobre cómo inhabilitar claves SSH, consulta Restringe las claves SSH de las VM. Este paso puede interrumpir el acceso autorizado a la VM, por lo que debes considerar las necesidades de tu organización antes de continuar.
  • Usa la autenticación SSH solo con claves autorizadas.
  • Bloquea las reglas de firewall o usa Google Cloud Armor para bloquear las direcciones IP maliciosas. Puedes habilitar Google Cloud Armor en la página Servicios integrados de Security Command Center. Según la cantidad de información, los costos de Google Cloud Armor pueden ser significativos. Consulta la guía de precios de Google Cloud Armor para obtener más información.

Credential Access: External Member Added To Privileged Group

Este hallazgo no está disponible para activaciones a nivel de proyecto.

Detecta cuando se agrega un miembro externo a un Grupo de Google con privilegios (un grupo de permisos o funciones sensibles). Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un hallazgo de Credential Access: External Member Added To Privileged Group como se indica en Revisa los hallazgos. El panel de detalles del resultado se abre en la pestaña Resumen.

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Correo electrónico principal: La cuenta que realizó los cambios.
    • Recurso afectado
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
  3. En el panel de detalles, haz clic en la pestaña JSON.

  4. En el archivo JSON, observa los siguientes campos.

    • groupName: Es el Grupo de Google en el que se realizaron los cambios.
    • externalMember: Es el miembro externo recién agregado.
    • sensitiveRoles: Son las funciones sensibles asociadas con este grupo.

Paso 2: Revisa los miembros del grupo

  1. Ve a Grupos de Google.

    Ve a Grupos de Google.

  2. Haz clic en el nombre del grupo que deseas revisar.

  3. En el menú de navegación, haz clic en Miembros.

  4. Si el miembro externo recién agregado no debería estar en este grupo, haz clic en la casilla de verificación junto al nombre del miembro y, luego, selecciona Quitar miembro o Bloquear miembro.

    Para quitar miembros, debes ser administrador de Google Workspace o tener la función de Propietario o Administrador en el Grupo de Google. Para obtener más información, consulta Asigna funciones a los miembros de un grupo.

Paso 3: Comprueba los registros

  1. En la pestaña Resumen del panel de detalles del resultado, haz clic en el vínculo URI de Cloud Logging para abrir el Explorador de registros.
  2. Si es necesario, selecciona tu proyecto.

    Selector de proyectos

  3. En la página que se carga, verifica los registros de los cambios de membresía de los Grupos de Google mediante los siguientes filtros:

    • protoPayload.methodName="google.apps.cloudidentity.groups.v1.MembershipsService.UpdateMembership"
    • protoPayload.authenticationInfo.principalEmail="principalEmail"

Paso 4: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada de framework de MITRE ATT&CK para este tipo de hallazgo: cuentas válidas.
  2. Para determinar si se necesitan pasos de solución adicionales, combina los resultados de la investigación con la investigación del MITRE.

Credential Access: Privileged Group Opened To Public

Este hallazgo no está disponible para activaciones a nivel de proyecto.

Detecta cuando un Grupo de Google con privilegios (un grupo al que se le otorgan funciones o permisos sensibles) se cambia para que sea accesible al público en general. Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un hallazgo de Credential Access: Privileged Group Opened To Public como se indica en Revisa los hallazgos. El panel de detalles del resultado se abre en la pestaña Resumen.

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Correo electrónico principal: La cuenta que realizó los cambios, que podría verse comprometida.
    • Recurso afectado
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
    1. Haz clic en la pestaña JSON.
    2. En el archivo JSON, observa los siguientes campos.
    • groupName: Es el Grupo de Google en el que se realizaron los cambios.
    • sensitiveRoles: Son las funciones sensibles asociadas con este grupo.
    • whoCanJoin: Es la configuración de unión del grupo.

Paso 2: Revisa la configuración de acceso de los grupos

  1. Ve a la Consola del administrador de Grupos de Google. Debes ser administrador de Google Workspace para acceder a la consola.

    Ir a la Consola del administrador

  2. En el panel de navegación, haz clic en Directorio y, luego, selecciona Grupos.

  3. Haz clic en el nombre del grupo que deseas revisar.

  4. Haz clic en Configuración de acceso y, luego, en Quién puede unirse al grupo, revisa la configuración de unión del grupo.

  5. En el menú desplegable, si es necesario, cambia la configuración de unión.

Paso 3: Comprueba los registros

  1. En la pestaña Resumen del panel de detalles del resultado, haz clic en el vínculo URI de Cloud Logging para abrir el Explorador de registros.
  2. Si es necesario, selecciona tu proyecto.

    Selector de proyectos

  3. En la página que se carga, verifica los registros de la configuración del Grupo de Google mediante los siguientes filtros:

    • protoPayload.methodName="google.admin.AdminService.changeGroupSetting"
    • protoPayload.authenticationInfo.principalEmail="principalEmail"

Paso 4: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada de framework de MITRE ATT&CK para este tipo de hallazgo: cuentas válidas.
  2. Para determinar si se necesitan pasos de solución adicionales, combina los resultados de la investigación con la investigación del MITRE.

Credential Access: Sensitive Role Granted To Hybrid Group

Detecta cuándo se otorgan funciones o permisos sensibles a un Grupo de Google con miembros externos. Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un hallazgo de Credential Access: Sensitive Role Granted To Hybrid Group como se indica en Revisa los hallazgos. El panel de detalles del resultado se abre en la pestaña Resumen (Summary).

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Correo electrónico principal: La cuenta que realizó los cambios, que podría verse comprometida.
    • Recurso afectado, en especial los siguientes campos:
      • Nombre completo del recurso: Es el recurso en el que se otorgó el rol nuevo.
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
    1. Haz clic en la pestaña JSON.
    2. En el archivo JSON, observa los siguientes campos.
    • groupName: Es el Grupo de Google en el que se realizaron los cambios.
    • bindingDeltas: Son los roles sensibles que se otorgaron recientemente a este grupo.

Paso 2: Revisa los permisos del grupo

  1. Ve a la página de IAM en la consola de Google Cloud.

    Ir a IAM

  2. En el campo Filtro, ingresa el nombre de la cuenta que aparece en groupName.

  3. Revisa las funciones sensibles otorgadas al grupo.

  4. Si el rol sensible recién agregado no es necesario, revoca el rol.

    Necesitas permisos específicos para administrar los roles de tu organización o proyecto. Para obtener más información, consulta Permisos necesarios.

Paso 3: Comprueba los registros

  1. En la pestaña Resumen del panel de detalles del resultado, haz clic en el vínculo URI de Cloud Logging para abrir el Explorador de registros.
  2. Si es necesario, selecciona tu proyecto.

    Selector de proyectos

  3. En la página que se carga, verifica los registros de la configuración del Grupo de Google mediante los siguientes filtros:

    • protoPayload.methodName="SetIamPolicy"
    • protoPayload.authenticationInfo.principalEmail="principalEmail"

Paso 4: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada de framework de MITRE ATT&CK para este tipo de hallazgo: cuentas válidas.
  2. Para determinar si se necesitan pasos de solución adicionales, combina los resultados de la investigación con la investigación del MITRE.

Malware: Cryptomining Bad IP

El software malicioso se detecta mediante el examen de los registros del flujo de VPC y de los registros de Cloud DNS para las conexiones a dominios de control y comandos conocidos, y a direcciones IP. Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un hallazgo de Malware: Cryptomining Bad IP, como se indica en Revisa los hallazgos. El panel de detalles del resultado se abre en la pestaña Resumen (Summary).

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • IP de origen: la dirección IP de criptominería que se sospecha
      • Puerto de origen: Es el puerto de origen de la conexión, si está disponible.
      • IP de destino: Es la dirección IP de destino.
      • Puerto de destino: Es el puerto de destino de la conexión, si está disponible.
      • Protocolo: Es el protocolo IANA que está asociado con la conexión.
    • Recurso afectado
    • Vínculos relacionados, incluidos los siguientes campos:
      • URI de Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
  3. En la vista detallada del resultado, haz clic en la pestaña Propiedades fuente.

  4. Expande properties y anota los valores del proyecto y la instancia en el siguiente campo:

    • instanceDetails: Anota el ID del proyecto y el nombre de la instancia de Compute Engine. El ID del proyecto y el nombre de la instancia aparecen como se muestra en el siguiente ejemplo:

      /projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME
  5. Para ver el JSON completo del resultado, haz clic en la pestaña JSON.

Paso 2: Revisa los permisos y la configuración

  1. En la consola de Google Cloud, ve a la página Panel.

    Ir al panel

  2. Haz clic en la lista desplegable Seleccionar desde en la parte superior de la página. En la ventana Seleccionar una opción que aparece, elige el proyecto que aparece en properties_project_id.

  3. Navega a la tarjeta Recursos y haz clic en Compute Engine.

  4. Haz clic en la instancia de VM que coincide con properties_sourceInstance. Investiga la instancia potencialmente comprometida en busca de software malicioso.

  5. En el panel de navegación, haz clic en Red de VPC y, luego, en Firewall. Quita o inhabilita las reglas de firewall con demasiados permisos.

Paso 3: Comprueba los registros

  1. En la consola de Google Cloud, ve al Explorador de registros.

    Ir al Explorador de registros

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto.

  3. En la página que se carga, busca los registros del flujo de VPC relacionados con Properties_ip_0 mediante el siguiente filtro:

    • 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")

Paso 4: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework de MITRE ATT&CK para este tipo de resultado: usurpación de recursos.
  2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 5: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto que contiene software malicioso.
  • Investiga la instancia potencialmente comprometida y quita cualquier software malicioso que se haya descubierto. Para ayudar con la detección y la eliminación, usa una solución de detección y respuesta de extremos.
  • Si es necesario, detén la instancia comprometida y reemplázala por una nueva.
  • Bloquea las reglas de firewall o usa Google Cloud Armor para bloquear las direcciones IP maliciosas. Puedes habilitar Google Cloud Armor en la página Servicios integrados de Security Command Center. Según el volumen de datos, los costos de Google Cloud Armor pueden ser significativos. Consulta la guía de precios de Google Cloud Armor para obtener más información.

Initial Access: Log4j Compromise Attempt

Este resultado se genera cuando se detectan las lookups de asignación de nombres de Java y la interfaz de directorio (JNDI) dentro de los encabezados o parámetros de URL. Estas búsquedas pueden indicar intentos de explotación de Log4Shell. Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un resultado de Initial Access: Log4j Compromise Attempt, como se indica en Revisa los detalles del resultado. El panel de detalles del resultado se abre en la pestaña Resumen.

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó
    • Recurso afectado
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
    • En la vista detallada del resultado, haz clic en la pestaña JSON.
    • En el archivo JSON, observa los siguientes campos.

    • properties

      • loadBalancerName: Es el nombre del balanceador de cargas que recibió la búsqueda de JNDI.
      • requestUrl: es la URL de la solicitud HTTP. Si está presente, contiene una búsqueda de JNDI.
      • requestUserAgent: El usuario-agente que envió la solicitud HTTP. Si está presente, contiene una búsqueda de JNDI.
      • refererUrl: La URL de la página que envió la solicitud HTTP. Si está presente, contiene una búsqueda de JNDI.

Paso 2: Comprueba los registros

  1. En la consola de Google Cloud, haz clic en el vínculo del campo URI de Cloud Logging del paso 1 para ir al Explorador de registros.
  2. En la página que se carga, verifica los campos httpRequest para tokens de string como ${jndi:ldap:// que puedan indicar posibles intentos de explotación.

    Consulta CVE-2021-44228: Detecta explotaciones de Log4Shell en la documentación de Logging para ver las strings de ejemplo que se deben buscar y una consulta de ejemplo.

Paso 3: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada del framework de MITRE ATT&CK para este tipo de resultado: Exploit Public-Facing Application.
  2. Para revisar los resultados relacionados, haz clic en el vínculo de la sección Resultados relacionados de la fila Resultados relacionados de la pestaña Resumen de los detalles del resultado. Los resultados relacionados son el mismo tipo de resultado, la misma instancia y red.
  3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 4: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

Active Scan: Log4j Vulnerable to RCE

Los analizadores de vulnerabilidades de Log4j compatibles realizan búsquedas de JNDI ofuscadas en parámetros de HTTP, URL y campos de texto con devoluciones de llamada a dominios controlados por los escáneres. Este resultado se genera cuando se encuentran consultas de DNS en dominios sin ofuscar. Estas consultas solo ocurren si una búsqueda de JNDI se realizó correctamente, lo que indica una vulnerabilidad Log4j activa. Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un hallazgo de Active Scan: Log4j Vulnerable to RCE como se indica en Revisa detalles de hallazgos. El panel de detalles del resultado se abre en la pestaña Resumen.

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó
    • Recurso afectado, en especial el siguiente campo:
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
  3. En la vista detallada del resultado, haz clic en la pestaña JSON.

  4. En el archivo JSON, observa los siguientes campos.

    • properties
      • scannerDomain: es el dominio que usa el analizador como parte de la búsqueda de JNDI. Este te indica qué analizador identificó la vulnerabilidad.
      • sourceIp: es la dirección IP que se usa para realizar la consulta de DNS.
      • vpcName: Es el nombre de la red en la instancia en la que se realizó la consulta de DNS.

Paso 2: Comprueba los registros

  1. En la consola de Google Cloud, haz clic en el vínculo del campo URI de Cloud Logging del paso 1 para ir al Explorador de registros.
  2. En la página que se carga, verifica los campos httpRequest para tokens de string como ${jndi:ldap:// que puedan indicar posibles intentos de explotación.

    Consulta CVE-2021-44228: Detecta explotaciones de Log4Shell en la documentación de Logging para ver las strings de ejemplo que se deben buscar y una consulta de ejemplo.

Paso 3: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada del framework de MITRE ATT&CK para este tipo de resultado: Aprovechamiento de Remote Services.
  2. Para revisar los resultados relacionados, haz clic en el vínculo de la sección Resultados relacionados de la fila Resultados relacionados de la pestaña Resumen de los detalles del resultado. Los hallazgos relacionados tienen el mismo tipo de resultado, y la misma instancia y red.
  3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 4: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

Leaked credentials

Este hallazgo no está disponible para activaciones a nivel de proyecto.

Este hallazgo se genera cuando las credenciales de la cuenta de servicio de Google Cloud se filtran en línea o se ven vulneradas. Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un hallazgo de account_has_leaked_credentials como se indica en Revisa detalles de hallazgos. El panel de detalles del resultado se abre en la pestaña Resumen.

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

  • Qué se detectó
  • Recurso afectado
  1. Haz clic en la pestaña Propiedades fuente y observa los siguientes campos:

    • Compromised_account: la cuenta de servicio potencialmente comprometida
    • Project_identifier: el proyecto que contiene las credenciales de la cuenta que se podrían filtrar
    • URL: el vínculo al repositorio de GitHub
  2. Para ver el JSON completo del resultado, haz clic en la pestaña JSON.

Paso 2: revisa los permisos del proyecto y de la cuenta de servicio

  1. En la consola de Google Cloud, ve a la página IAM.

    Ir a IAM

  2. Si es necesario, selecciona el proyecto que aparece en Project_identifier.

  3. En la página que aparece, en el cuadro Filtro, ingresa el nombre de la cuenta que aparece en Compromised_account y verifica los permisos asignados.

  4. En la consola de Google Cloud, ve a la página Cuentas de servicio.

    Ir a Cuentas de servicio

  5. En la página que aparece, en el cuadro Filtro, ingresa el nombre de la cuenta de servicio comprometida y verifica las claves y las fechas de creación de las claves de la cuenta de servicio.

Paso 3: Comprueba los registros

  1. En la consola de Google Cloud, ve al Explorador de registros.

    Ir al Explorador de registros

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto.

  3. En la página que se carga, usa los siguientes filtros para verificar los registros en busca de actividad de los recursos de IAM nuevos o actualizados:

    • 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"

Paso 4: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada de framework de MITRE ATT&CK de este tipo de hallazgo: Cuentas válidas: Cuentas de Cloud.
  2. Haz clic en el vínculo de relatedFindingURI para revisar los hallazgos relacionados. Los hallazgos relacionados tienen el mismo tipo de resultado, y la misma instancia y red.
  3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 5: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto del cual se filtraron las credenciales.
  • Considera borrar la cuenta de servicio vulnerada, además de rotar y borrar todas las claves de acceso de la cuenta de servicio del proyecto vulnerado. Después de la eliminación, los recursos que usan la cuenta de servicio para la autenticación perderán el acceso. Antes de continuar, tu equipo de seguridad debe identificar todos los recursos afectados y trabajar con los propietarios de los recursos para garantizar la continuidad del negocio.
  • Trabaja con tu equipo de seguridad para identificar recursos desconocidos, incluidos instancias de Compute Engine, instantáneas, cuentas de servicio y usuarios de IAM. Borra los recursos que no se crearon con cuentas autorizadas.
  • Responde las notificaciones de la asistencia de Google Cloud.
  • Para limitar quién puede crear cuentas de servicio, usa el Servicio de políticas de la organización.
  • Para identificar y corregir funciones con demasiados permisos, usa el recomendador de IAM.
  • Abre el vínculo URL y borra las credenciales filtradas. Recopila más información sobre la cuenta vulnerada y comunícate con el propietario.

Malware

El software malicioso se detecta mediante el examen de los registros del flujo de VPC y de los registros de Cloud DNS para las conexiones a dominios de control y comandos conocidos, y a direcciones IP. En la actualidad, Event Threat Detection proporciona detección general de software malicioso (Malware: Bad IP y Malware: Bad Domain) y detectores, en particular, software malicioso relacionado con Log4j (Log4j Malware: Bad IP y Log4j Malware: Bad Domain).

En los siguientes pasos, se describe cómo investigar y responder a los resultados basados en IP. Los pasos de solución son similares para los resultados basados en dominios.

Paso 1: Revisa los detalles del hallazgo

  1. Abre el hallazgo de software malicioso relevante. En los siguientes pasos, se usa el resultado Malware: Bad IP, como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen (Summary).

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Dominio del indicador: Para los resultados de Bad domain, el dominio que los activó.
      • IP del indicador: Para los resultados de Bad IP, la dirección IP que los activó.
      • IP de origen: para los resultados de Bad IP, un comando de software malicioso conocido y una dirección IP de control.
      • Puerto de origen: para los resultados de Bad IP, el puerto de origen de la conexión.
      • IP de destino: para los resultados de Bad IP, la dirección IP de destino del software malicioso.
      • Puerto de destino: para los resultados de Bad IP, el puerto de destino de la conexión.
      • Protocolo: Para los resultados de Bad IP, el número de protocolo IANA asociado con la conexión.
    • Recurso afectado, en especial los siguientes campos:
      • Nombre completo del recurso: El nombre completo del recurso de la instancia de Compute Engine afectada.
      • Nombre completo del proyecto: Es el nombre completo del recurso del proyecto que contiene el resultado.
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
      • Chronicle: Vínculo a Chronicle
      • Indicador de VirusTotal: Vínculo a la página de análisis de VirusTotal.
    1. Haz clic en la pestaña JSON y observa el siguiente campo:

      • evidence:
      • sourceLogId:
        • projectID: El ID del proyecto en el que se detectó el problema.
      • properties:
      • InstanceDetails: Es la dirección del recurso de la instancia de Compute Engine.

Paso 2: Investiga en Chronicle

Puedes usar Chronicle para investigar este resultado. Chronicle es un servicio de Google Cloud que te permite investigar amenazas y alternar por entidades relacionadas en un cronograma fácil de usar. Chronicle enriquece los datos de los resultados, lo que te permite identificar indicadores de interés y simplificar las investigaciones.

Solo puedes usar Chronicle si activas Security Command Center a nivel de la organización.

  1. Ve a la pestaña Resultados de Security Command Center en la consola de Google Cloud.

    Ir a hallazgos

  2. En el panel Filtros rápidos, desplázate hacia abajo hasta Nombre visible de la fuente.

  3. En la sección Nombre visible de la fuente, selecciona Event Threat Detection.

    Una tabla se propaga con los resultados para el tipo de fuente que seleccionaste.

  4. En la tabla, en Categoría, haz clic en el resultado Malware: Bad IP. Se abrirá el panel de detalles del hallazgo.

  5. En la sección Vínculos relacionados del panel de detalles del resultado, haz clic en Investigar en Chronicle.

  6. Sigue las instrucciones de la interfaz de usuario guiada de Chronicle.

Usa las siguientes guías para realizar investigaciones en Chronicle:

Paso 3: Revisa los permisos y la configuración

  1. En la consola de Google Cloud, ve a la página Panel.

    Ir al panel

  2. Haz clic en la lista desplegable Seleccionar desde en la parte superior de la página. En la ventana Seleccionar desde que aparece, en el campo Buscar proyectos y carpetas, ingresa el número de proyecto que se muestra en la fila Nombre completo del proyecto en la pestaña Resumen.

  3. Navega a la tarjeta Recursos y haz clic en Compute Engine.

  4. Haz clic en la instancia de VM que coincide con el nombre y la zona en Nombre completo del recurso. Revisa los detalles de la instancia, incluida la configuración de red y acceso.

  5. En el panel de navegación, haz clic en Red de VPC y, luego, en Firewall. Quita o inhabilita las reglas de firewall con demasiados permisos.

Paso 4: Comprueba los registros

  1. En la pestaña Resumen del panel de detalles del resultado, haz clic en el vínculo URI de Cloud Logging para abrir el Explorador de registros.
  2. En la página que se carga, busca los registros de flujo de VPC relacionados con la dirección IP en la IP de origen mediante el siguiente filtro:

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

      Reemplaza lo siguiente:

      • PROJECT_ID con la selección del proyecto que se muestra en projectId.
      • SOURCE_IP por la dirección IP que aparece en la fila IP de origen en la pestaña Resumen de los detalles del resultado.

Paso 5: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework de MITRE ATT&CK para este tipo de resultado: Resolución dinámica y comando y control.
  2. Para revisar los resultados relacionados, haz clic en el vínculo de la sección Resultados relacionados de la fila Resultados relacionados de la pestaña Resumen de los detalles del resultado. Los hallazgos relacionados tienen el mismo tipo de resultado, y la misma instancia y red.
  3. Haz clic en el vínculo del indicador de VirusTotal para verificar las URLs y los dominios marcados en VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URL, dominios y direcciones IP potencialmente maliciosos.
  4. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 6: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto que contiene software malicioso.
  • Investiga la instancia potencialmente comprometida y quita cualquier software malicioso que se haya descubierto. Para ayudar con la detección y la eliminación, usa una solución de detección y respuesta de extremos.
  • Para realizar un seguimiento de la actividad y las vulnerabilidades que permitieron la inserción de software malicioso, verifica los registros de auditoría y los registros de sistema asociados con la instancia comprometida.
  • Si es necesario, detén la instancia comprometida y reemplázala por una nueva.
  • Bloquea las reglas de firewall o usa Google Cloud Armor para bloquear las direcciones IP maliciosas. Puedes habilitar Google Cloud Armor en la página Servicios integrados de Security Command Center. Según el volumen de datos, los costos de Google Cloud Armor pueden ser significativos. Consulta la guía de precios de Google Cloud Armor para obtener más información.
  • Para controlar el acceso y el uso de imágenes de VM, usa la política de IAM de VM protegida y de imágenes confiables.

Malware: Outgoing DoS

Event Threat Detection detecta el posible uso de una instancia para iniciar un ataque de denegación del servicio (DoS) mediante el análisis de los registros del flujo de VPC. Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un hallazgo de Malware: Outgoing DoS como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen (Summary).

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó
      • IP de origen: la dirección IP de origen de la actividad de DoS
      • Puerto de origen: Es el puerto de origen de la conexión.
      • IP de destino: la dirección IP de destino de la actividad de DoS
      • Puerto de destino: Es el puerto de destino de la conexión.
    • Recurso afectado
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
    1. En la vista detallada del resultado, haz clic en la pestaña JSON.
    2. En el archivo JSON, observa los siguientes campos.
    • sourceInstanceDetails: la instancia de VM de Compute Engine afectada

Paso 2: Revisa los permisos y la configuración

  1. En la consola de Google Cloud, ve a la página Panel.

    Ir al panel

  2. Haz clic en la lista desplegable Seleccionar desde en la parte superior de la página. En la ventana Seleccionar una opción que aparece, elige el ID del proyecto que aparece en sourceInstanceDetails.

  3. Navega a la tarjeta Recursos y haz clic en Compute Engine.

  4. Haz clic en la instancia de VM que coincide con el nombre y la zona de la instancia en sourceInstanceDetails. Revisa los detalles de la instancia, incluida la configuración de red y acceso.

  5. En el panel de navegación, haz clic en Red de VPC y, luego, en Firewall. Quita o inhabilita las reglas de firewall con demasiados permisos.

Paso 3: Comprueba los registros

  1. En la pestaña Resumen del panel de detalles del resultado, haz clic en el vínculo URI de Cloud Logging para abrir el Explorador de registros.
  2. En la página que se carga, busca los registros de flujo de VPC relacionados con la dirección IP en srcIP mediante el siguiente filtro:

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

      Reemplaza lo siguiente:

      • PROJECT_ID por el ID del proyecto en el que se encontró el problema
      • SOURCE_IP por la dirección IP que aparece en el campo srcIP en el JSON de resultado
      • DESTINATION_IP por la dirección IP que aparece en el campo destIp en el JSON de resultado

Paso 4: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework de MITRE ATT&CK para este tipo de resultado: denegación de servicio de la red.
  2. Para revisar los resultados relacionados, haz clic en el vínculo de la sección Resultados relacionados de la fila Resultados relacionados de la pestaña Resumen de los detalles del resultado. Los hallazgos relacionados tienen el mismo tipo de resultado, y la misma instancia y red.
  3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 5: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto que experimenta tráfico de DoS saliente.
  • Investiga la instancia potencialmente comprometida y quita cualquier software malicioso que se haya descubierto. Para ayudar con la detección y la eliminación, usa una solución de detección y respuesta de extremos.
  • Para realizar un seguimiento de la actividad y las vulnerabilidades que permitieron la inserción de software malicioso, verifica los registros de auditoría y los registros de sistema asociados con la instancia comprometida.
  • Si es necesario, detén la instancia comprometida y reemplázala por una nueva.
  • Bloquea las reglas de firewall o usa Google Cloud Armor para bloquear las direcciones IP maliciosas. Puedes habilitar Google Cloud Armor en la página Servicios integrados de Security Command Center. Según el volumen de datos, los costos de Google Cloud Armor pueden ser significativos. Consulta la guía de precios de Google Cloud Armor para obtener más información.
  • Para controlar el acceso y el uso de imágenes de VM, usa la política de IAM de VM protegida y de imágenes confiables.

Persistence: IAM Anomalous Grant

Los registros de auditoría se examinan para detectar la adición de asignaciones de funciones de IAM (IAM) que podrían considerarse sospechosas.

Los siguientes son ejemplos de otorgamientos anómalos:

  • Invitar a un usuario externo (por ejemplo, un usuario de gmail.com) como propietario del proyecto desde la consola de Google Cloud
  • Una cuenta de servicio que otorga permisos sensibles
  • Una función personalizada que otorga permisos sensibles
  • Una cuenta de servicio agregada desde fuera de tu organización o proyecto

El resultado IAM Anomalous Grant es único, ya que incluye subreglas que proporcionan información más específica sobre cada instancia de este resultado. La clasificación de gravedad de este resultado depende de la subregla. Cada subregla puede requerir una respuesta diferente.

En la siguiente lista, se muestran todas las subreglas posibles y la gravedad de estos:

  • external_service_account_added_to_policy:
    • HIGH, si se otorgó una función muy sensible o si se otorgó una función de sensibilidad media a nivel de la organización. Para obtener más información, consulta Roles altamente sensibles.
    • MEDIUM, si se otorgó un rol de sensibilidad media. Para obtener más información, consulta Funciones de sensibilidad media.
  • external_member_invited_to_policy: HIGH
  • external_member_added_to_policy:
    • HIGH, si se otorgó una función muy sensible o si se otorgó una función de sensibilidad media a nivel de la organización. Para obtener más información, consulta Roles altamente sensibles.
    • MEDIUM, si se otorgó un rol de sensibilidad media. Para obtener más información, consulta Funciones de sensibilidad media.
  • custom_role_given_sensitive_permissions: MEDIUM
  • service_account_granted_sensitive_role_to_member: HIGH
  • policy_modified_by_default_compute_service_account: HIGH

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un hallazgo de Persistence: IAM Anomalous Grant como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen (Summary).

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Correo electrónico principal: Dirección de correo electrónico de la cuenta de servicio o usuario que asignó el rol.
    • Recurso afectado

    • Vínculos relacionados, especialmente los siguientes campos:

      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
      • Indicador de VirusTotal: Vínculo a la página de análisis de VirusTotal.
      • Chronicle: Vínculo a Chronicle
  3. Haz clic en la pestaña JSON. Se muestra el JSON completo del resultado.

  4. En el archivo JSON del resultado, observa los siguientes campos:

    • detectionCategory:
      • subRuleName: Información más específica sobre el tipo de otorgamiento anómalo que se produjo. La subregla determina la clasificación de gravedad de este resultado.
    • evidence:
      • sourceLogId:
      • projectId: El ID del proyecto que contiene el resultado.
    • properties:
      • sensitiveRoleGrant:
        • bindingDeltas:
        • Action: Es la acción que realizó el usuario.
        • Role: Es el rol asignado al usuario.
        • member: Es la dirección de correo electrónico del usuario que recibió el rol.

Paso 2: Investiga en Chronicle

Puedes usar Chronicle para investigar este resultado. Chronicle es un servicio de Google Cloud que te permite investigar amenazas y alternar por entidades relacionadas en un cronograma fácil de usar. Chronicle enriquece los datos de los resultados, lo que te permite identificar indicadores de interés y simplificar las investigaciones.

No puedes investigar los resultados de Security Command Center en Chronicle si activas Security Command Center a nivel de proyecto.

  1. Ve a la pestaña Resultados de Security Command Center en la consola de Google Cloud.

    Ir a hallazgos

  2. En el panel Filtros rápidos, desplázate hacia abajo hasta Nombre visible de la fuente.

  3. En la sección Nombre visible de la fuente, selecciona Event Threat Detection.

    Una tabla se propaga con los resultados para el tipo de fuente que seleccionaste.

  4. En la tabla, en categoría, haz clic en un hallazgo de Persistence: IAM Anomalous Grant. Se abrirá el panel de detalles para la búsqueda.

  5. En la sección Vínculos relacionados del panel de detalles del resultado, haz clic en Investigar en Chronicle.

  6. Sigue las instrucciones de la interfaz de usuario guiada de Chronicle.

Usa las siguientes guías para realizar investigaciones en Chronicle:

Paso 3: Comprueba los registros

  1. En la pestaña Resumen del panel de detalles del resultado, haz clic en el vínculo URI de Cloud Logging para abrir el Explorador de registros.
  2. En la página que se carga, busca recursos de IAM nuevos o actualizados mediante los siguientes filtros:
    • protoPayload.methodName="SetIamPolicy"
    • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
    • protoPayload.methodName="google.iam.admin.v1.CreateRole"

Paso 4: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework MITRE ATT&CK para este tipo de resultado: Cuentas válidas: cuentas de nube.
  2. Para revisar los resultados relacionados, haz clic en el vínculo de la fila Resultados relacionados de la pestaña Resumen de los detalles del resultado. Los resultados relacionados son el mismo tipo de resultado y la misma instancia y red.
  3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 5: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se encuentra la cuenta vulnerada.
  • Borra la cuenta de servicio vulnerada, y rota y borra todas las claves de acceso de la cuenta de servicio del proyecto vulnerado. Después de la eliminación, los recursos que usan la cuenta de servicio para la autenticación perderán el acceso.
  • Borra los recursos del proyecto creados por cuentas no autorizadas, como instancias desconocidas de Compute Engine, instantáneas, cuentas de servicio y usuarios de IAM.
  • Para restringir la adición de usuarios de gmail.com, usa la política de la organización.
  • Para identificar y corregir funciones con demasiados permisos, usa el recomendador de IAM.

Persistence: Impersonation Role Granted for Dormant Service Account

Detecta eventos en los que se otorga una función de suplantación de identidad a una principal que le permite a esa principal suplantar una cuenta de servicio administrada por el usuario inactiva. En este hallazgo, la cuenta de servicio inactiva es el recurso afectado, y una cuenta de servicio se considera inactiva si ha estado inactiva durante más de 180 días.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado Persistence: Impersonation Role Granted for Dormant Service Account, como se indica en Revisa los resultados.
  2. En los detalles del resultado, en la pestaña Resumen, anota los valores de los siguientes campos.

    En Qué se detectó, haz lo siguiente:

    • Correo electrónico principal: El usuario que realizó la acción de otorgamiento
    • El acceso infractor otorga.Nombre principal: La principal a la que se le otorgó el rol de suplantación de identidad

    En Recurso afectado, haz lo siguiente:

    • Nombre visible del recurso: la cuenta de servicio inactiva como un recurso
    • Nombre completo del proyecto: el proyecto donde reside esa cuenta de servicio inactiva

Paso 2: Investiga los métodos de ataque y respuesta

  1. Usa las herramientas de la cuenta de servicio, como el Analizador de actividad, para investigar la actividad de la cuenta de servicio inactiva.
  2. Comunícate con el propietario del campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.

Paso 3: Comprueba los registros

  1. En la pestaña Resumen del panel de detalles del resultado, en Vínculos relacionados, haz clic en el vínculo URI de Cloud Logging para abrir el Explorador de registros.

Paso 4: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se realizó la acción.
  • Quita el acceso del propietario del correo electrónico principal si está comprometido.
  • Quita el nuevo rol de suplantación de identidad otorgado del miembro objetivo.
  • Considera borrar la cuenta de servicio potencialmente comprometida y rotar y borrar todas las claves de acceso a la cuenta de servicio para el proyecto potencialmente comprometido. Después de la eliminación, las aplicaciones que usan la cuenta de servicio para la autenticación pierden el acceso. Antes de continuar, el equipo de seguridad debe identificar todas las aplicaciones afectadas y trabajar con los propietarios de las aplicaciones para garantizar la continuidad del negocio.
  • Trabaja con tu equipo de seguridad para identificar recursos desconocidos, incluidos instancias de Compute Engine, instantáneas, cuentas de servicio y usuarios de IAM. Borra los recursos que no se crearon con cuentas autorizadas.
  • Responde las notificaciones de Atención al cliente de Cloud.
  • Para limitar quién puede crear cuentas de servicio, usa el Servicio de políticas de la organización.
  • Para identificar y corregir funciones demasiado permisivas, usa el recomendador de IAM.

Persistence: Unmanaged Account Granted Sensitive Role

Detecta eventos en los que se otorga una función sensible a una cuenta no administrada. Los administradores del sistema no pueden controlar las cuentas no administradas. Por ejemplo, cuando el empleado correspondiente abandonó la empresa, el administrador no puede borrar la cuenta. Por lo tanto, otorgar funciones sensibles a cuentas no administradas crea un posible riesgo de seguridad para la organización.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado Persistence: Unmanaged Account Granted Sensitive Role, como se indica en Revisa los resultados.
  2. En los detalles del resultado, en la pestaña Resumen, anota los valores de los siguientes campos.

    En Qué se detectó, haz lo siguiente:

    • Correo electrónico principal: El usuario que realizó la acción de otorgamiento
    • Otorgamiento de acceso infractor.Nombre principal: La cuenta no administrada que recibe la concesión
    • Otorgamiento de acceso denegado.Role: el rol sensible otorgado

Paso 2: Investiga los métodos de ataque y respuesta

  1. Comunícate con el propietario del campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.
  2. Verifica con el propietario del campo Offend access Grants.Principal name y comprende el origen de la cuenta no administrada.

Paso 3: Comprueba los registros

  1. En la pestaña Resumen del panel de detalles del resultado, en Vínculos relacionados, haz clic en el vínculo URI de Cloud Logging para abrir el Explorador de registros.

Paso 4: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se realizó la acción.
  • Quita el acceso del propietario del correo electrónico principal si está comprometido.
  • Quita el rol sensible recientemente otorgado de la cuenta no administrada.
  • Considera convertir la cuenta no administrada en una cuenta administrada con la herramienta de transferencia y trasladar esta cuenta al control de los administradores del sistema.

Persistence: New API Method

Se detectó actividad del administrador anómala por parte de un actor potencialmente malicioso en una organización, carpeta o proyecto. La actividad anómala puede ser cualquiera de las siguientes opciones:

  • Actividad nueva de una principal en una organización, carpeta o proyecto
  • Actividad que una principal no vio en un tiempo en una organización, carpeta o proyecto

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado de Persistence: New API Method como se indica en Revisa los resultados.
  2. En los detalles del resultado, en la pestaña Resumen, anota los valores de los siguientes campos:

    • En Qué se detectó, haz lo siguiente:
      • Correo electrónico principal: La cuenta que realizó la llamada
      • Nombre del servicio: El nombre de la API del servicio de Google Cloud que se usó en la acción
      • Nombre del método: El método al que se llamó
    • En Recurso afectado, haz lo siguiente:
      • Nombre visible del recurso: El nombre del recurso afectado, que puede ser igual al nombre de la organización, la carpeta o el proyecto
      • Ruta de acceso del recurso: Es la ubicación en la jerarquía de recursos donde se llevó a cabo la actividad.

Paso 2: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del marco MITRE ATT&CK para este tipo de resultado: Persistencia.
  2. Investiga si la acción fue justificada en la organización, carpeta o proyecto y si la acción fue llevada a cabo por el propietario legítimo de la cuenta. La organización, la carpeta o el proyecto se muestra en la fila Ruta de acceso del recurso y la cuenta se muestra en la fila Correo electrónico principal.
  3. Para desarrollar un plan de respuesta, combine los resultados de su investigación con la investigación del MITRE.

Persistence: New Geography

Este hallazgo no está disponible para activaciones a nivel de proyecto.

Un usuario o una cuenta de servicio de IAM accede a Google Cloud desde una ubicación anómala, según la ubicación geográfica de la dirección IP solicitante.

Paso 1: Revisa los detalles del hallazgo

  1. Abre un resultado de Persistence: New Geography, como se indica en la sección Revisa los detalles de los resultados más arriba en esta página. El panel de detalles del resultado se abre en la pestaña Resumen.

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

  • Qué se detectó, en especial los siguientes campos:
    • Correo electrónico principal: La cuenta de usuario potencialmente comprometida.
  • Recurso afectado, en especial los siguientes campos:
    • Nombre completo del proyecto: El proyecto que contiene la cuenta de usuario potencialmente comprometida.
  • Vínculos relacionados, especialmente los siguientes campos:
    • URI de Cloud Logging: Vincula a entradas de Logging.
    • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
    • Resultados relacionados: vínculos a cualquier resultado relacionado.
  1. En la vista detallada del resultado, haz clic en la pestaña JSON.
  2. En el JSON, ten en cuenta los siguientes campos sourceProperties:

    • affectedResources:
      • gcpResourceName: el recurso afectado
    • evidence:
      • sourceLogId:
      • projectId: El ID del proyecto que contiene el resultado.
    • properties:
      • anomalousLocation:
      • anomalousLocation: Es la ubicación actual estimada del usuario.
      • callerIp: Es la dirección IP externa.
      • notSeenInLast: Es el período que se usa para establecer un modelo de referencia del comportamiento normal.
      • typicalGeolocations: Son las ubicaciones en las que el usuario suele acceder a los recursos de Google Cloud.

Paso 2: revise los permisos del proyecto y de la cuenta

  1. En la consola de Google Cloud, ve a la página IAM.

    Ir a IAM

  2. Si es necesario, selecciona el proyecto que aparece en el campo projectID del JSON de resultado.

  3. En la página que aparece, en el cuadro Filtro, ingresa el nombre de la cuenta que aparece en Correo electrónico principal y marca los roles otorgados.

Paso 3: Comprueba los registros

  1. En la pestaña Resumen del panel de detalles del resultado, haz clic en el vínculo URI de Cloud Logging para abrir el Explorador de registros.
  2. Si es necesario, selecciona tu proyecto.
  3. En la página que se carga, usa los siguientes filtros para verificar los registros en busca de actividad de los recursos de IAM nuevos o actualizados:
    • protoPayload.methodName="SetIamPolicy"
    • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
    • protoPayload.methodName="google.iam.admin.v1.CreateRole"
    • protoPayload.authenticationInfo.principalEmail="principalEmail"

Paso 4: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada del framework MITRE ATT&CK para este tipo de resultado: Cuentas válidas: cuentas de nube.
  2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 5: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se encuentra la cuenta vulnerada.
  • Revisa los campos anomalousLocation, typicalGeolocations y notSeenInLast para verificar si el acceso es anormal y si la cuenta se vio comprometida.
  • Borra los recursos del proyecto creados por cuentas no autorizadas, como instancias desconocidas de Compute Engine, instantáneas, cuentas de servicio y usuarios de IAM.
  • Para restringir la creación de nuevos recursos a regiones específicas, consulta Restringe ubicaciones de recursos.
  • Para identificar y corregir funciones con demasiados permisos, usa el recomendador de IAM.

Persistence: New User Agent

Este hallazgo no está disponible para activaciones a nivel de proyecto.

Una cuenta de servicio de IAM accede a Google Cloud que usa software sospechoso, como lo indica un usuario-agente anómalo.

Paso 1: Revisa los detalles del hallazgo

  1. Abre un resultado de Persistence: New User Agent, como se indica en la sección Revisa los detalles de los resultados que se encuentra más arriba en esta página. El panel de detalles del resultado se abre en la pestaña Resumen.

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Correo electrónico principal: La cuenta de servicio potencialmente comprometida.
    • Recurso afectado, en especial los siguientes campos:
      • Nombre completo del proyecto: El proyecto que contiene la cuenta de servicio potencialmente comprometida.
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
    1. En la vista detallada del resultado, haz clic en la pestaña JSON.
    2. En el archivo JSON, observa los siguientes campos.
    • projectId: Es el proyecto que contiene la cuenta de servicio potencialmente comprometida.
    • callerUserAgent: El usuario-agente anómalo.
    • anomalousSoftwareClassification: Es el tipo de software.
    • notSeenInLast: El período que se usa para establecer un modelo de referencia del comportamiento normal

Paso 2: revise los permisos del proyecto y de la cuenta

  1. En la consola de Google Cloud, ve a la página IAM.

    Ir a IAM

  2. Si es necesario, selecciona el proyecto que aparece en projectId.

  3. En la página que aparece, en el cuadro Filtro, ingresa el nombre de la cuenta que aparece en la fila Correo electrónico principal en la pestaña Resumen de los detalles del resultado y verifica los roles otorgados.

  4. En la consola de Google Cloud, ve a la página Cuentas de servicio.

    Ir a Cuentas de servicio

  5. En la página que aparece, en el cuadro Filtro, ingresa el nombre de la cuenta que aparece en la fila Correo electrónico principal en la pestaña Resumen de los detalles del resultado.

  6. Verifica las claves de la cuenta de servicio y las fechas de creación de las claves.

Paso 3: Comprueba los registros

  1. En la pestaña Resumen del panel de detalles del resultado, haz clic en el vínculo URI de Cloud Logging para abrir el Explorador de registros.
  2. Si es necesario, selecciona tu proyecto.
  3. En la página que se carga, usa los siguientes filtros para verificar los registros en busca de actividad de los recursos de IAM nuevos o actualizados:
    • 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"

Paso 4: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada de framework de MITRE ATT&CK de este tipo de hallazgo: Cuentas válidas: Cuentas de Cloud.
  2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 5: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se encuentra la cuenta vulnerada.
  • Revisa los campos de anomalousSoftwareClassification, callerUserAgent y behaviorPeriod para verificar si el acceso es anormal y si la cuenta se vio comprometida.
  • Borra los recursos del proyecto creados por cuentas no autorizadas, como instancias desconocidas de Compute Engine, instantáneas, cuentas de servicio y usuarios de IAM.
  • Para restringir la creación de nuevos recursos a regiones específicas, consulta Restringe ubicaciones de recursos.
  • Para identificar y corregir funciones con demasiados permisos, usa el recomendador de IAM.

Privilege Escalation: Changes to sensitive Kubernetes RBAC objects

Para escalar el privilegio, un actor potencialmente malicioso intentó modificar un objeto de control de acceso basado en funciones (RBAC) ClusterRole o ClusterRoleBinding de la función sensible cluster-admin mediante una solicitud PUT o PATCH.

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado Privilege Escalation: Changes to sensitive Kubernetes RBAC objects como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen.

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Correo electrónico principal: La cuenta que realizó la llamada.
      • Nombre del método: El método al que se llamó.
      • Vinculaciones de Kubernetes: La vinculación sensible de Kubernetes o ClusterRoleBinding que se modificó.
    • Recurso afectado, en especial los siguientes campos:
      • Nombre visible del recurso: El clúster de Kubernetes en el que se produjo la acción.
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
  3. En la sección Qué se detectó, haz clic en el nombre de la vinculación en la fila Vinculaciones de Kubernetes. Se muestran los detalles de la vinculación.

  4. En la vinculación que se muestra, ten en cuenta los detalles de la vinculación.

Paso 2: Comprueba los registros

  1. En la pestaña Resumen de los detalles del resultado en la consola de Google Cloud, haz clic en el vínculo del campo URI de Cloud Logging para ir al Explorador de registros.
  2. Si el valor en Nombre del método era un método PATCH, verifica el cuerpo de la solicitud para ver qué propiedades se modificaron.

    En las llamadas a update (PUT), se envía todo el objeto en la solicitud, por lo que los cambios no son tan claros.

  3. Verifica otras acciones que realizó la principal con los siguientes filtros:

    • resource.labels.cluster_name="CLUSTER_NAME"
    • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

      Reemplaza lo siguiente:

    • CLUSTER_NAME: El valor que anotaste en el campo Nombre visible del recurso en los detalles del resultado.

    • PRINCIPAL_EMAIL: El valor que anotaste en el campo Correo electrónico principal en los detalles del resultado.

Paso 3: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework MITRE ATT&CK para este tipo de resultado: Escalación de privilegios.
  2. Confirma la sensibilidad del objeto y si la modificación está justificada.
  3. Para las vinculaciones, puedes verificar el sujeto y, luego, investigar si necesita la función a la que está vinculado.
  4. Determina si hay otros indicios de actividad maliciosa por parte de la principal en los registros.
  5. Si el correo electrónico principal no es una cuenta de servicio, comunícate con el propietario de la cuenta para confirmar si el propietario legítimo realizó la acción.

    Si el correo electrónico principal es una cuenta de servicio (IAM o Kubernetes), identifica la fuente de la modificación para determinar su legitimidad.

  6. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación de MITRE.

Privilege Escalation: Create Kubernetes CSR for master cert

Para escalar el privilegio, un actor potencialmente malicioso creó una solicitud de firma de certificado (CSR) principal de Kubernetes, que le otorga acceso de cluster-admin.

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado Privilege Escalation: Create Kubernetes CSR for master cert como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen (Summary).

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Correo electrónico principal: La cuenta que realizó la llamada.
      • Nombre del método: El método al que se llamó.
    • Recurso afectado, en especial los siguientes campos:
      • Nombre visible del recurso: El clúster de Kubernetes en el que se produjo la acción.
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.

Paso 2: Comprueba los registros

  1. En la pestaña Resumen de los detalles del resultado en la consola de Google Cloud, haz clic en el vínculo del campo URI de Cloud Logging para ir al Explorador de registros.
  2. Comprueba el valor en el campo protoPayload.resourceName para identificar la solicitud de firma de certificado específica.
  3. Verifica otras acciones que realizó la principal con los siguientes filtros:

    • resource.labels.cluster_name="CLUSTER_NAME"
    • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

      Reemplaza lo siguiente:

    • CLUSTER_NAME: El valor que anotaste en el campo Nombre visible del recurso en los detalles del resultado.

    • PRINCIPAL_EMAIL: El valor que anotaste en el campo Correo electrónico principal en los detalles del resultado.

Paso 3: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework MITRE ATT&CK para este tipo de resultado: Escalación de privilegios.
  2. Investiga si se justificó darle acceso a cluster-admin.
  3. Si el correo electrónico principal no es una cuenta de servicio, comunícate con el propietario de la cuenta para confirmar si el propietario legítimo realizó la acción.

    Si el correo electrónico principal es una cuenta de servicio (IAM o Kubernetes), identifica la fuente de la acción para determinar su legitimidad.

  4. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación de MITRE.

Privilege Escalation: Creation of sensitive Kubernetes bindings

Para escalar el privilegio, una persona posiblemente malintencionada intentó crear un objeto RoleBinding o ClusterRoleBinding nuevo para la función cluster-admin.

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado Privilege Escalation: Creation of sensitive Kubernetes bindings como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen.

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Correo electrónico principal: La cuenta que realizó la llamada.
      • Vinculaciones de Kubernetes: La vinculación sensible de Kubernetes o ClusterRoleBinding que se creó.
    • Recurso afectado, en especial los siguientes campos:
      • Nombre visible del recurso: El clúster de Kubernetes en el que se produjo la acción.
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.

Paso 2: Comprueba los registros

  1. En la pestaña Resumen de los detalles del resultado en la consola de Google Cloud, haz clic en el vínculo del campo URI de Cloud Logging para ir al Explorador de registros.
  2. Verifica otras acciones que realizó la principal con los siguientes filtros:

    • resource.labels.cluster_name="CLUSTER_NAME"
    • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

      Reemplaza lo siguiente:

    • CLUSTER_NAME: El valor que anotaste en el campo Nombre visible del recurso en los detalles del resultado.

    • PRINCIPAL_EMAIL: El valor que anotaste en el campo Correo electrónico principal en los detalles del resultado.

Paso 3: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework MITRE ATT&CK para este tipo de resultado: Escalación de privilegios.
  2. Confirma la sensibilidad de la vinculación creada y si las funciones son necesarias para los sujetos.
  3. Para las vinculaciones, puedes verificar el sujeto y, luego, investigar si necesita la función a la que está vinculado.
  4. Determina si hay otros indicios de actividad maliciosa por parte de la principal en los registros.
  5. Si el correo electrónico principal no es una cuenta de servicio, comunícate con el propietario de la cuenta para confirmar si el propietario legítimo realizó la acción.

    Si el correo electrónico principal es una cuenta de servicio (IAM o Kubernetes), identifica la fuente de la acción para determinar su legitimidad.

  6. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación de MITRE.

Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials

Para escalar el privilegio, un posible actor malicioso consultó una solicitud de firma de certificado (CSR) con el comando kubectl, mediante credenciales de arranque comprometidas.

El siguiente es un ejemplo de un comando que detecta esta regla:

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

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen.

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Correo electrónico principal: La cuenta que realizó la llamada.
      • Nombre del método: El método al que se llamó.
    • En Recurso afectado, haz lo siguiente:
      • Nombre visible del recurso: El clúster de Kubernetes en el que se produjo la acción.
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.

Paso 2: Comprueba los registros

Si el nombre del método, que anotaste en el campo Nombre del método en los detalles del resultado, es un método GET, haz lo siguiente:

  1. En la pestaña Resumen de los detalles del resultado en la consola de Google Cloud, haz clic en el vínculo del campo URI de Cloud Logging para ir al Explorador de registros.
  2. Comprueba el valor en el campo protoPayload.resourceName para identificar la solicitud de firma de certificado específica.

Paso 3: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework MITRE ATT&CK para este tipo de resultado: Escalación de privilegios.
  2. Si la CSR específica está disponible en la entrada de registro, investiga la confidencialidad del certificado y si se justificó la acción.
  3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación de MITRE.

Privilege Escalation: Launch of privileged Kubernetes container

Un actor potencialmente malicioso creó un Pod que contiene contenedores con privilegios o con capacidades de elevación de privilegios.

Un contenedor con privilegios tiene el campo privileged configurado como true. Un contenedor con capacidades de elevación de privilegios tiene el campo allowPrivilegeEscalation configurado como true. Si deseas obtener más información, consulta la referencia de la API de SecurityContext v1 core en la documentación de Kubernetes.

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado Privilege Escalation: Launch of privileged Kubernetes container como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen.

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Correo electrónico principal: La cuenta que realizó la llamada.
      • Pods de Kubernetes: El Pod recién creado con contenedores con privilegios.
    • Recurso afectado, en especial los siguientes campos:
      • Nombre visible del recurso: El clúster de Kubernetes en el que se produjo la acción.
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
  3. En la pestaña JSON, anota los valores de los campos de resultado:

    • findings.kubernetes.pods[].containers: el contenedor con privilegios activado dentro del pod.

Paso 2: Comprueba los registros

  1. En la pestaña Resumen de los detalles del resultado en la consola de Google Cloud, haz clic en el vínculo del campo URI de Cloud Logging para ir al Explorador de registros.
  2. Verifica otras acciones que realizó la principal con los siguientes filtros:

    • resource.labels.cluster_name="CLUSTER_NAME"
    • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

      Reemplaza lo siguiente:

    • CLUSTER_NAME: El valor que anotaste en el campo Nombre visible del recurso en los detalles del resultado.

    • PRINCIPAL_EMAIL: El valor que anotaste en el campo Correo electrónico principal en los detalles del resultado.

Paso 3: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework MITRE ATT&CK para este tipo de resultado: Escalación de privilegios.
  2. Confirma que el contenedor creado requiere acceso a los recursos de host y las capacidades del kernel.
  3. Determina si hay otros indicios de actividad maliciosa por parte de la principal en los registros.
  4. Si el correo electrónico principal no es una cuenta de servicio, comunícate con el propietario de la cuenta para confirmar si el propietario legítimo realizó la acción.

    Si el correo electrónico principal es una cuenta de servicio (IAM o Kubernetes), identifica la fuente de la acción para determinar su legitimidad.

  5. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación de MITRE.

Privilege Escalation: Dormant Service Account Granted Sensitive Role

Detecta eventos en los que se otorga un rol sensible de IAM a una cuenta de servicio administrada por el usuario inactiva. En este contexto, una cuenta de servicio se considera inactiva si ha estado inactiva durante más de 180 días.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado Privilege Escalation: Dormant Service Account Granted Sensitive Role, como se indica en Revisa los resultados.
  2. En los detalles del resultado, en la pestaña Resumen, anota los valores de los siguientes campos.

    En Qué se detectó, haz lo siguiente:

    • Correo electrónico principal: El usuario que realizó la acción de otorgamiento
    • Otorgamiento de acceso ofensivo: La cuenta de servicio inactiva que recibió el rol sensible
    • Otorgamiento de acceso fraudulento. Role otorgado: Es el rol sensible de IAM que se asigna.

    En Recurso afectado, haz lo siguiente:

    • Nombre visible del recurso: La organización, la carpeta o el proyecto en el que se otorgó el rol sensible de IAM a la cuenta de servicio inactiva.

Paso 2: Investiga los métodos de ataque y respuesta

  1. Usa las herramientas de la cuenta de servicio, como el Analizador de actividad, para investigar la actividad de la cuenta de servicio inactiva.
  2. Comunícate con el propietario del campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.

Paso 3: Comprueba los registros

  1. En la pestaña Resumen del panel de detalles del resultado, en Vínculos relacionados, haz clic en el vínculo URI de Cloud Logging para abrir el Explorador de registros.

Paso 4: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se realizó la acción.
  • Quita el acceso del propietario del correo electrónico principal si está comprometido.
  • Quita el rol de IAM sensible recientemente asignado de la cuenta de servicio inactiva.
  • Considera borrar la cuenta de servicio potencialmente comprometida y rotar y borrar todas las claves de acceso a la cuenta de servicio para el proyecto potencialmente comprometido. Después de la eliminación, los recursos que usan la cuenta de servicio para la autenticación pierden el acceso. Antes de continuar, el equipo de seguridad debe identificar todos los recursos afectados y trabajar con los propietarios de los recursos para garantizar la continuidad del negocio.
  • Trabaja con tu equipo de seguridad para identificar recursos desconocidos, incluidos instancias de Compute Engine, instantáneas, cuentas de servicio y usuarios de IAM. Borra los recursos que no se crearon con cuentas autorizadas.
  • Responde las notificaciones de Atención al cliente de Cloud.
  • Para limitar quién puede crear cuentas de servicio, usa el Servicio de políticas de la organización.
  • Para identificar y corregir funciones demasiado permisivas, usa el recomendador de IAM.

Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity

El robo de identidad anómalo de la cuenta de servicio se detecta cuando se examinan los registros de auditoría de actividad del administrador para ver si se produjo alguna anomalía en una solicitud de suplantación de identidad de la cuenta de servicio.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity, como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen (Summary).

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Correo electrónico principal: La cuenta de servicio final en la solicitud de suplantación de identidad que se usó para acceder a Google Cloud.
      • Nombre del servicio: El nombre de la API del servicio de Google Cloud involucrado en la solicitud de suplantación de identidad.
      • Nombre del método: El método al que se llamó.
      • Información de delegación de la cuenta de servicio: Son los detalles de las cuentas de servicio en la cadena de delegación, la principal en la parte inferior de la lista es el emisor de la solicitud de suplantación de identidad.
    • Recurso afectado, en especial los siguientes campos:
      • Nombre completo del recurso: Es el nombre del clúster.
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.

Paso 2: Investiga los métodos de ataque y respuesta

  1. Comunícate con el propietario de la cuenta de servicio en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.
  2. Investiga los principales de la cadena de delegación para verificar si la solicitud es anormal y si alguna cuenta está comprometida.
  3. Comunícate con el propietario del llamador de suplantación de identidad en la lista Información de delegación de la cuenta de servicio. Confirma si el propietario legítimo realizó la acción.

Paso 3: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se realizó la acción.
  • Considera borrar la cuenta de servicio potencialmente comprometida y rotar y borrar todas las claves de acceso a la cuenta de servicio para el proyecto potencialmente comprometido. Después de la eliminación, los recursos que usan la cuenta de servicio para la autenticación pierden el acceso. Antes de continuar, el equipo de seguridad debe identificar todos los recursos afectados y trabajar con los propietarios de los recursos para garantizar la continuidad del negocio.
  • Trabaja con tu equipo de seguridad para identificar recursos desconocidos, incluidos instancias de Compute Engine, instantáneas, cuentas de servicio y usuarios de IAM. Borra los recursos que no se crearon con cuentas autorizadas.
  • Responde las notificaciones de la asistencia de Google Cloud.
  • Para limitar quién puede crear cuentas de servicio, usa el Servicio de políticas de la organización.
  • Para identificar y corregir funciones demasiado permisivas, usa el recomendador de IAM.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity

Anomalous Multistep Service Account Delegation se detecta si examinas los registros de auditoría de actividad del administrador para ver si se produjo alguna anomalía en una solicitud de suplantación de identidad de la cuenta de servicio.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity, como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen.

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Correo electrónico principal: La cuenta de servicio final en la solicitud de suplantación de identidad que se usó para acceder a Google Cloud.
      • Nombre del servicio: El nombre de la API del servicio de Google Cloud involucrado en la solicitud de suplantación de identidad.
      • Nombre del método: El método al que se llamó.
      • Información de delegación de la cuenta de servicio: Son los detalles de las cuentas de servicio en la cadena de delegación, la principal en la parte inferior de la lista es el emisor de la solicitud de suplantación de identidad.
    • Recurso afectado
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.

Paso 2: Investiga los métodos de ataque y respuesta

  1. Comunícate con el propietario de la cuenta de servicio en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.
  2. Investiga los principales de la cadena de delegación para verificar si la solicitud es anormal y si alguna cuenta está comprometida.
  3. Comunícate con el propietario del llamador de suplantación de identidad en la lista Información de delegación de la cuenta de servicio. Confirma si el propietario legítimo realizó la acción.

Paso 3: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se realizó la acción.
  • Considera borrar la cuenta de servicio potencialmente comprometida y rotar y borrar todas las claves de acceso a la cuenta de servicio para el proyecto potencialmente comprometido. Después de la eliminación, los recursos que usan la cuenta de servicio para la autenticación pierden el acceso. Antes de continuar, el equipo de seguridad debe identificar todos los recursos afectados y trabajar con los propietarios de los recursos para garantizar la continuidad del negocio.
  • Trabaja con tu equipo de seguridad para identificar recursos desconocidos, incluidos instancias de Compute Engine, instantáneas, cuentas de servicio y usuarios de IAM. Borra los recursos que no se crearon con cuentas autorizadas.
  • Responde las notificaciones de la asistencia de Google Cloud.
  • Para limitar quién puede crear cuentas de servicio, usa el Servicio de políticas de la organización.
  • Para identificar y corregir funciones demasiado permisivas, usa el recomendador de IAM.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access

Anomalous Multistep Service Account Delegation se detecta si examinas los registros de auditoría de acceso a los datos para ver si se produjo alguna anomalía en una solicitud de suplantación de identidad de la cuenta de servicio.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access, como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen (Summary).

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Correo electrónico principal: La cuenta de servicio final en la solicitud de suplantación de identidad que se usó para acceder a Google Cloud
      • Nombre del servicio: El nombre de la API del servicio de Google Cloud involucrado en la solicitud de suplantación de identidad
      • Nombre del método: El método al que se llamó
      • Información de delegación de la cuenta de servicio: Son los detalles de las cuentas de servicio en la cadena de delegación; la principal que está al final de la lista es el emisor de la solicitud de suplantación de identidad.
    • Recurso afectado
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.

Paso 2: Investiga los métodos de ataque y respuesta

  1. Comunícate con el propietario de la cuenta de servicio en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.
  2. Investiga los principales de la cadena de delegación para verificar si la solicitud es anormal y si alguna cuenta está comprometida.
  3. Comunícate con el propietario del llamador de suplantación de identidad en la lista Información de delegación de la cuenta de servicio. Confirma si el propietario legítimo realizó la acción.

Paso 3: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se realizó la acción.
  • Considera borrar la cuenta de servicio potencialmente comprometida y rotar y borrar todas las claves de acceso a la cuenta de servicio para el proyecto potencialmente comprometido. Después de la eliminación, los recursos que usan la cuenta de servicio para la autenticación pierden el acceso. Antes de continuar, el equipo de seguridad debe identificar todos los recursos afectados y trabajar con los propietarios de los recursos para garantizar la continuidad del negocio.
  • Trabaja con tu equipo de seguridad para identificar recursos desconocidos, incluidos instancias de Compute Engine, instantáneas, cuentas de servicio y usuarios de IAM. Borra los recursos que no se crearon con cuentas autorizadas.
  • Responde las notificaciones de la asistencia de Google Cloud.
  • Para limitar quién puede crear cuentas de servicio, usa el Servicio de políticas de la organización.
  • Para identificar y corregir funciones demasiado permisivas, usa el recomendador de IAM.

Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity

Anomalous Service Account Impersonator se detecta si examinas los registros de auditoría de actividad del administrador para ver si se produjo alguna anomalía en una solicitud de suplantación de identidad de la cuenta de servicio.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity, como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen (Summary).

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, especialmente los siguientes campos:

      • Correo electrónico principal: La cuenta de servicio final en la solicitud de suplantación de identidad que se usó para acceder a Google Cloud
      • Nombre del servicio: El nombre de la API del servicio de Google Cloud involucrado en la solicitud de suplantación de identidad
      • Nombre del método: El método al que se llamó
      • Información de delegación de la cuenta de servicio: Son los detalles de las cuentas de servicio en la cadena de delegación; la principal que está al final de la lista es el emisor de la solicitud de suplantación de identidad.
    • Recurso afectado

    • Vínculos relacionados, especialmente los siguientes campos:

      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.

Paso 2: Investiga los métodos de ataque y respuesta

  1. Comunícate con el propietario de la cuenta de servicio en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.
  2. Investiga los principales de la cadena de delegación para verificar si la solicitud es anormal y si alguna cuenta está comprometida.
  3. Comunícate con el propietario del llamador de suplantación de identidad en la lista Información de delegación de la cuenta de servicio. Confirma si el propietario legítimo realizó la acción.

Paso 3: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se realizó la acción.
  • Considera borrar la cuenta de servicio potencialmente comprometida y rotar y borrar todas las claves de acceso a la cuenta de servicio para el proyecto potencialmente comprometido. Después de la eliminación, los recursos que usan la cuenta de servicio para la autenticación pierden el acceso. Antes de continuar, el equipo de seguridad debe identificar todos los recursos afectados y trabajar con los propietarios de los recursos para garantizar la continuidad del negocio.
  • Trabaja con tu equipo de seguridad para identificar recursos desconocidos, incluidos instancias de Compute Engine, instantáneas, cuentas de servicio y usuarios de IAM. Borra los recursos que no se crearon con cuentas autorizadas.
  • Responde las notificaciones de la asistencia de Google Cloud.
  • Para limitar quién puede crear cuentas de servicio, usa el Servicio de políticas de la organización.
  • Para identificar y corregir funciones demasiado permisivas, usa el recomendador de IAM.

Privilege Escalation: Anomalous Service Account Impersonator for Data Access

El robo de identidad de cuentas de servicio anómalo se detecta cuando se examinan los registros de auditoría de acceso a los datos para ver si se produjo alguna anomalía en una solicitud de suplantación de identidad de la cuenta de servicio.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado Privilege Escalation: Anomalous Service Account Impersonator for Data Access, como se indica en Revisa los resultados.
  2. En los detalles del resultado, en la pestaña Resumen, anota los valores de los siguientes campos.

    En Qué se detectó, haz lo siguiente:

    • Correo electrónico principal: La cuenta de servicio final en la solicitud de suplantación de identidad que se usó para acceder a Google Cloud
    • Nombre del servicio: El nombre de la API del servicio de Google Cloud involucrado en la solicitud de suplantación de identidad
    • Nombre del método: El método al que se llamó
    • Información de delegación de la cuenta de servicio: Son los detalles de las cuentas de servicio en la cadena de delegación; la principal que está al final de la lista es el emisor de la solicitud de suplantación de identidad.

Paso 2: Investiga los métodos de ataque y respuesta

  1. Comunícate con el propietario de la cuenta de servicio en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.
  2. Investiga los principales de la cadena de delegación para verificar si la solicitud es anormal y si alguna cuenta está comprometida.
  3. Comunícate con el propietario del llamador de suplantación de identidad en la lista Información de delegación de la cuenta de servicio. Confirma si el propietario legítimo realizó la acción.

Paso 3: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se realizó la acción.
  • Considera borrar la cuenta de servicio potencialmente comprometida y rotar y borrar todas las claves de acceso a la cuenta de servicio para el proyecto potencialmente comprometido. Después de la eliminación, los recursos que usan la cuenta de servicio para la autenticación pierden el acceso. Antes de continuar, el equipo de seguridad debe identificar todos los recursos afectados y trabajar con los propietarios de los recursos para garantizar la continuidad del negocio.
  • Trabaja con tu equipo de seguridad para identificar recursos desconocidos, incluidos instancias de Compute Engine, instantáneas, cuentas de servicio y usuarios de IAM. Borra los recursos que no se crearon con cuentas autorizadas.
  • Responde las notificaciones de la asistencia de Google Cloud.
  • Para limitar quién puede crear cuentas de servicio, usa el Servicio de políticas de la organización.
  • Para identificar y corregir funciones demasiado permisivas, usa el recomendador de IAM.

Service account self-investigation

Se usa una credencial de la cuenta de servicio para investigar las funciones y los permisos asociados con esa misma cuenta de servicio. Este hallazgo indica que las credenciales de la cuenta de servicio pueden estar comprometidas y se debe tomar medidas inmediatas.

Paso 1: Revisa los detalles del hallazgo

  1. Abre un resultado de Discovery: Service Account Self-Investigation, como se indica en la sección Revisa los detalles de los resultados que se encuentra más arriba en esta página. El panel de detalles del resultado se abre en la pestaña Resumen.

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Gravedad: El nivel de riesgo asignado al hallazgo. La gravedad es HIGH si la llamada a la API que activó este resultado no está autorizada: la cuenta de servicio no tiene permiso para consultar sus propios permisos de IAM con la API de projects.getIamPolicy.
      • Correo electrónico principal: La cuenta de servicio potencialmente comprometida.
      • IP del llamador: la dirección IP interna o externa
    • Recurso afectado, en especial los siguientes campos:
      • Nombre completo del recurso:
      • Nombre completo del proyecto: El proyecto que contiene las credenciales de la cuenta potencialmente filtradas.
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
    1. Para ver el JSON completo del resultado, haz clic en la pestaña JSON.

Paso 2: revisa los permisos del proyecto y de la cuenta de servicio

  1. En la consola de Google Cloud, ve a la página IAM.

    Ir a IAM

  2. Si es necesario, selecciona el proyecto que aparece en el campo projectID del JSON de resultado.

  3. En la página que aparece, en el cuadro Filtro, ingresa el nombre de la cuenta que aparece en Correo electrónico principal y marca los permisos asignados.

  4. En la consola de Google Cloud, ve a la página Cuentas de servicio.

    Ir a Cuentas de servicio

  5. En la página que aparece, en el cuadro Filtro, ingresa el nombre de la cuenta de servicio comprometida y verifica las claves y las fechas de creación de las claves de la cuenta de servicio.

Paso 3: Comprueba los registros

  1. En la pestaña Resumen del panel de detalles del resultado, haz clic en el vínculo URI de Cloud Logging para abrir el Explorador de registros.
  2. Si es necesario, selecciona tu proyecto.
  3. En la página que se carga, usa los siguientes filtros para verificar los registros en busca de actividad de los recursos de IAM nuevos o actualizados:
    • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
    • protoPayload.methodName="SetIamPolicy"
    • protoPayload.authenticationInfo.principalEmail="principalEmail"

Paso 4: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada del framework de MITRE ATT&CK para este tipo de resultado: Descubrimiento de los grupos de permisos: grupos de Cloud.
  2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 5: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se encuentra la cuenta vulnerada.
  • Borra la cuenta de servicio vulnerada, y rota y borra todas las claves de acceso de la cuenta de servicio del proyecto vulnerado. Después de la eliminación, los recursos que usan la cuenta de servicio para la autenticación perderán el acceso.
  • Borra los recursos del proyecto que creó la cuenta vulnerada, como instancias desconocidas de Compute Engine, instantáneas, cuentas de servicio y usuarios de IAM.

Inhibit System Recovery: Deleted Google Cloud Backup and DR host

Event Threat Detection examina los registros de auditoría para detectar la eliminación de los hosts que ejecutan aplicaciones protegidas por el servicio de copia de seguridad y DR. Después de borrar un host, no se puede crear una copia de seguridad de las aplicaciones asociadas a este.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado de Inhibit System Recovery: Deleted Google Cloud Backup and DR host, como se detalla en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen.
  2. En la pestaña Resumen, revisa la información de las siguientes secciones:
    • Qué se detectó, en especial los siguientes campos:
      • Nombre de la aplicación: El nombre de una base de datos o VM conectada a la copia de seguridad y DR
      • Nombre de host: el nombre de un host conectado a copia de seguridad y DR
      • Asunto principal: Un usuario que ejecutó una acción correctamente
    • Recurso afectado
      • Nombre visible del recurso: El proyecto en el que se borró el host.
    • Vínculos relacionados, especialmente los siguientes campos:
      • Método MITRE ATTACK: Vínculo a la documentación de MITRE ATT&CK.
      • URI de Logging: Vínculo para abrir el Explorador de registros.

Paso 2: Investiga los métodos de ataque y respuesta

Comunícate con el propietario de la cuenta de servicio en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.

Paso 3: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado para este hallazgo. Evalúa cuidadosamente la información que recopilas en tu investigación para determinar la mejor manera de resolver los hallazgos.

  1. En el proyecto en el que se realizó la acción, navega a la consola de administración.
  2. Confirma que el host borrado ya no esté en la lista de hosts de copia de seguridad y DR.
  3. Selecciona la opción Agregar host para volver a agregar el host borrado.

Inhibit System Recovery: Google Cloud Backup and DR remove plan

Security Command Center examina los registros de auditoría para detectar la eliminación anómala de un plan de copia de seguridad, que se usa para aplicar un conjunto de políticas de copias de seguridad a una aplicación.

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado de Inhibit System Recovery: Google Cloud Backup and DR remove plan, como se detalla en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen.
  2. En la pestaña Resumen, revisa la información de las siguientes secciones:
    • Qué se detectó, en especial los siguientes campos:
      • Nombre de la aplicación: El nombre de una base de datos o VM conectada a la copia de seguridad y DR
      • Nombre del perfil: Especifica el destino de almacenamiento para las copias de seguridad de los datos de aplicaciones y VM.
      • Nombre de la plantilla: El nombre de un conjunto de políticas que definen la frecuencia, la programación y el tiempo de retención de las copias de seguridad
    • Recurso afectado
      • Nombre visible del recurso: El proyecto en el que se borró el plan.
    • Vínculos relacionados, en especial los siguientes campos:
      • Método MITRE ATTACK: vínculo a la documentación de MITRE ATT&CK
      • URI de Logging: Vínculo para abrir el Explorador de registros

Paso 2: Investiga los métodos de ataque y respuesta

Comunícate con el propietario de la cuenta de servicio en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.

Paso 3: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado para este hallazgo. Evalúa cuidadosamente la información que recopilas en tu investigación para determinar la mejor manera de resolver los hallazgos.

  1. En el proyecto en el que se realizó la acción, navega a la consola de administración.
  2. En la pestaña Administrador de apps, busca las aplicaciones afectadas que ya no están protegidas y revisa las políticas de copia de seguridad de cada una.

Inhibit System Recovery: Google Cloud Backup and DR delete template

Security Command Center examina los registros de auditoría para detectar la eliminación anómala de una plantilla. Una plantilla es una configuración básica para copias de seguridad que se pueden aplicar a varias aplicaciones.

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado de Inhibit System Recovery: Google Cloud Backup and DR delete template, como se detalla en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen.
  2. En la pestaña Resumen, revisa la información de las siguientes secciones:
    • Qué se detectó, en especial los siguientes campos:
      • Nombre de la plantilla: El nombre de un conjunto de políticas que definen la frecuencia, la programación y el tiempo de retención de las copias de seguridad
      • Asunto principal: Un usuario que ejecutó una acción correctamente
    • Recurso afectado
      • Nombre visible del recurso: El proyecto en el que se borró la plantilla.
    • Vínculos relacionados, en especial los siguientes campos:
      • Método MITRE ATTACK: vínculo a la documentación de MITRE ATT&CK
      • URI de Logging: Vínculo para abrir el Explorador de registros

Paso 2: Investiga los métodos de ataque y respuesta

Comunícate con el propietario de la cuenta de servicio en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.

Paso 3: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado para este hallazgo. Evalúa cuidadosamente la información que recopilas en tu investigación para determinar la mejor manera de resolver los hallazgos. 1. En el proyecto en el que se realizó la acción, navega a la consola de administración. 2. En la pestaña Administrador de apps, busca las aplicaciones afectadas que ya no están protegidas y revisa las políticas de copia de seguridad de cada una. 3. Para volver a agregar una plantilla, navega a la pestaña Planes alternativos, selecciona Plantillas y, luego, la opción Crear plantilla.

Inhibit System Recovery: Google Cloud Backup and DR delete policy

Los registros de auditoría se examinan para detectar la eliminación de una política. Una política define cómo se realiza una copia de seguridad y dónde se almacena.

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado de Inhibit System Recovery: Google Cloud Backup and DR delete policy, como se detalla en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen.
  2. En la pestaña Resumen, revisa la información de las siguientes secciones:
    • Qué se detectó, en especial los siguientes campos:
      • Nombre de la política: El nombre de una sola política, que define la frecuencia, la programación y el tiempo de retención de la copia de seguridad
      • Asunto principal: Un usuario que ejecutó una acción correctamente
    • Recurso afectado
      • Nombre visible del recurso: El proyecto en el que se borró la política.
    • Vínculos relacionados, en especial los siguientes campos:
      • Método MITRE ATTACK: Vínculo a la documentación de MITRE ATT&CK.
      • URI de Logging: Vínculo para abrir el Explorador de registros.

Paso 2: Investiga los métodos de ataque y respuesta

Comunícate con el propietario de la cuenta de servicio en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.

Paso 3: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado para este hallazgo. Evalúa cuidadosamente la información que recopilas en tu investigación para determinar la mejor manera de resolver los hallazgos. 1. En el proyecto en el que se realizó la acción, navega a la consola de administración. 2. En la pestaña Administrador de apps, selecciona la aplicación afectada y revisa la configuración de Políticas que se aplica a esa aplicación.

Inhibit System Recovery: Google Cloud Backup and DR delete profile

Los registros de auditoría se examinan para detectar la eliminación de un perfil. Un perfil define qué grupos de almacenamiento se usan para almacenar copias de seguridad.

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado de Inhibit System Recovery: Google Cloud Backup and DR delete profile, como se detalla en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen.
  2. En la pestaña Resumen, revisa la información de las siguientes secciones:
    • Qué se detectó, en especial los siguientes campos:
      • Nombre del perfil: Especifica el destino de almacenamiento para las copias de seguridad de los datos de aplicaciones y VM.
      • Asunto principal: Un usuario que ejecutó una acción correctamente
    • Recurso afectado
      • Nombre visible del recurso: El proyecto en el que se borró el perfil.
    • Vínculos relacionados, en especial los siguientes campos:
      • Método MITRE ATTACK: Vínculo a la documentación de MITRE ATT&CK.
      • URI de Logging: Vínculo para abrir el Explorador de registros.

Paso 2: Investiga los métodos de ataque y respuesta

Comunícate con el propietario de la cuenta de servicio en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.

Paso 3: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado para este hallazgo. Evalúa cuidadosamente la información que recopilas en tu investigación para determinar la mejor manera de resolver los hallazgos. 1. En el proyecto en el que se realizó la acción, navega a la consola de administración. 2. En la pestaña Planes de copia de seguridad, selecciona Perfiles para obtener una lista de todos los perfiles. 3. Revisa los perfiles para verificar que todos los perfiles obligatorios estén implementados. 4. Si el perfil borrado se quitó por error, selecciona Crear perfil (Create Profile) para definir objetivos de almacenamiento para tus dispositivos de copia de seguridad y DR.

Inhibit System Recovery: Google Cloud Backup and DR delete storage pool

Los registros de auditoría se examinan para detectar la eliminación de un grupo de almacenamiento. El grupo de almacenamiento asocia un bucket de Cloud Storage con la copia de seguridad y DR.

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado de Inhibit System Recovery: Google Cloud Backup and DR delete storage pool, como se detalla en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen.
  2. En la pestaña Resumen, revisa la información de las siguientes secciones:
    • Qué se detectó, en especial los siguientes campos:
      • Nombre del grupo de almacenamiento: Es el nombre de los buckets de almacenamiento en los que se almacenan las copias de seguridad.
      • Asunto principal: Un usuario que ejecutó una acción correctamente
    • Recurso afectado
      • Nombre visible del recurso: El proyecto en el que se borró el grupo de almacenamiento.
    • Vínculos relacionados, en especial los siguientes campos:
      • Método MITRE ATTACK: Vínculo a la documentación de MITRE ATT&CK.
      • URI de Logging: Vínculo para abrir el Explorador de registros.

Paso 2: Investiga los métodos de ataque y respuesta

Comunícate con el propietario de la cuenta de servicio en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.

Paso 3: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado para este hallazgo. Evalúa cuidadosamente la información que recopilas en tu investigación para determinar la mejor manera de resolver los hallazgos. 1. En el proyecto en el que se realizó la acción, navega a la consola de administración. 2. En la pestaña Administrar, selecciona Grupos de almacenamiento para obtener una lista de todos los grupos de almacenamiento. 3. Revisa las asociaciones del grupo de almacenamiento con dispositivos de copia de seguridad. 4. Si un dispositivo activo no tiene un grupo de almacenamiento asociado, selecciona Agregar grupo OnVault para volver a agregarlo.

Data Destruction: Google Cloud Backup and DR expire image

Un actor potencialmente malicioso solicitó borrar una imagen de copia de seguridad.

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado de Inhibit System Recovery: Google Cloud Backup and DR expire image, como se detalla en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen.
  2. En la pestaña Resumen, revisa la información de las siguientes secciones:
    • Qué se detectó, en especial los siguientes campos:
      • Nombre de la política: El nombre de una sola política, que define la frecuencia, la programación y el tiempo de retención de la copia de seguridad
      • Nombre de la plantilla: El nombre de un conjunto de políticas que definen la frecuencia, la programación y el tiempo de retención de las copias de seguridad
      • Nombre del perfil: Especifica el destino de almacenamiento para las copias de seguridad de los datos de aplicaciones y VM.
      • Asunto principal: Un usuario que ejecutó una acción correctamente
    • Recurso afectado
      • Nombre visible del recurso: El proyecto en el que se borró la imagen de copia de seguridad.
    • Vínculos relacionados, en especial los siguientes campos:
      • Método MITRE ATTACK: Vínculo a la documentación de MITRE ATT&CK.
      • URI de Logging: Vínculo para abrir el Explorador de registros.

Paso 2: Investiga los métodos de ataque y respuesta

Comunícate con el propietario de la cuenta de servicio en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.

Paso 3: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado para este hallazgo. Evalúa cuidadosamente la información que recopilas en tu investigación para determinar la mejor manera de resolver los hallazgos. 1. En el proyecto en el que se realizó la acción, navega a la consola de administración. 2. Navega a la pestaña Supervisar y selecciona Trabajos para revisar el estado del trabajo de eliminación de la copia de seguridad. 3. Si no se autoriza un trabajo de eliminación, navega a los permisos de IAM para revisar los usuarios que tienen acceso a los datos de copia de seguridad.

Data Destruction: Google Cloud Backup and DR expire all images

Un atacante potencialmente malicioso solicitó eliminar todas las imágenes de copia de seguridad asociadas con una aplicación.

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado de Inhibit System Recovery: Google Cloud Backup and DR expire all images, como se detalla en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen.
  2. En la pestaña Resumen, revisa la información de las siguientes secciones:
    • Qué se detectó, en especial los siguientes campos:
      • Nombre de la política: El nombre de una sola política, que define la frecuencia, la programación y el tiempo de retención de la copia de seguridad
      • Nombre de la plantilla: El nombre de un conjunto de políticas que definen la frecuencia, la programación y el tiempo de retención de las copias de seguridad
      • Nombre del perfil: Especifica el destino de almacenamiento para las copias de seguridad de los datos de aplicaciones y VM.
      • Asunto principal: Un usuario que ejecutó una acción correctamente
    • Recurso afectado
      • Nombre visible del recurso: El proyecto en el que se borraron las imágenes de copia de seguridad.
    • Vínculos relacionados, en especial los siguientes campos:
      • Método MITRE ATTACK: Vínculo a la documentación de MITRE ATT&CK.
      • URI de Logging: Vínculo para abrir el Explorador de registros.

Paso 2: Investiga los métodos de ataque y respuesta

Comunícate con el propietario de la cuenta de servicio en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.

Paso 3: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado para este hallazgo. Evalúa cuidadosamente la información que recopilas en tu investigación para determinar la mejor manera de resolver los hallazgos. 1. En el proyecto en el que se realizó la acción, navega a la consola de administración. 2. Navega a la pestaña Supervisar y selecciona Trabajos para revisar el estado del trabajo de eliminación de la copia de seguridad. 3. Si no se autoriza un trabajo de eliminación, navega a los permisos de IAM para revisar los usuarios que tienen acceso a los datos de copia de seguridad.

Data Destruction: Google Cloud Backup and DR remove appliance

Los registros de auditoría se examinan para detectar la eliminación de un dispositivo de copia de seguridad y recuperación. Un dispositivo de copia de seguridad y recuperación es un componente fundamental para las operaciones de copia de seguridad.

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado de Inhibit System Recovery: Google Cloud Backup and DR remove appliance, como se detalla en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen.
  2. En la pestaña Resumen, revisa la información de las siguientes secciones:
    • Qué se detectó, en especial los siguientes campos:
      • Nombre del dispositivo: El nombre de una base de datos o VM conectada a la copia de seguridad y DR
      • Asunto principal: Un usuario que ejecutó una acción correctamente
    • Recurso afectado
      • Nombre visible del recurso: El proyecto en el que se borró el dispositivo.
    • Vínculos relacionados, en especial los siguientes campos:
      • Método MITRE ATTACK: Vínculo a la documentación de MITRE ATT&CK.
      • URI de Logging: Vínculo para abrir el Explorador de registros.

Paso 2: Investiga los métodos de ataque y respuesta

Comunícate con el propietario de la cuenta de servicio en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.

Paso 3: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado para este hallazgo. Evalúa cuidadosamente la información que recopilas en tu investigación para determinar la mejor manera de resolver los hallazgos. 1. En el proyecto en el que se realizó la acción, navega a la consola de administración. 2. En la pestaña Administrador de apps, busca las aplicaciones afectadas que ya no están protegidas y revisa las políticas de copia de seguridad de cada una. 3. Para crear un dispositivo nuevo y volver a aplicar protecciones a las apps desprotegidas, navega a Copia de seguridad y DR en la consola de Google Cloud y selecciona la opción Implementar otro dispositivo de copia de seguridad o recuperación. 4. En el menú Storage, configura cada dispositivo nuevo con un destino de almacenamiento. Después de configurar un dispositivo, aparece como una opción cuando crea un perfil para sus aplicaciones.

Lateral Movement: Modified Boot Disk Attached to Instance

Los registros de auditoría se examinan para detectar movimientos sospechosos del disco entre los recursos de las instancias de Compute Engine. Se conectó un disco de arranque potencialmente modificado a Compute Engine.

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado de Lateral Movement: Modify Boot Disk Attaching to Instance, como se detalla en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen.
  2. En la pestaña Resumen, anota los valores de los siguientes campos.

    En Qué se detectó, haz lo siguiente:

    • Correo electrónico principal: La cuenta de servicio que realizó la acción
    • Nombre del servicio: El nombre de la API del servicio de Google Cloud al que accedió la cuenta de servicio
    • Nombre del método: El método al que se llamó

Paso 2: Investiga los métodos de ataque y respuesta

  1. Usa herramientas de la cuenta de servicio, como el Analizador de actividad, para investigar la actividad de la cuenta de servicio asociada.
  2. Comunícate con el propietario de la cuenta de servicio en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.

Paso 3: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se realizó la acción.
  • Puedes usar el inicio seguro para las instancias de Compute Engine
  • Considera borrar la cuenta de servicio potencialmente comprometida y rotar y borrar todas las claves de acceso a la cuenta de servicio para el proyecto potencialmente comprometido. Después de la eliminación, las aplicaciones que usan la cuenta de servicio para la autenticación pierden el acceso. Antes de continuar, el equipo de seguridad debe identificar todas las aplicaciones afectadas y trabajar con los propietarios de las aplicaciones para garantizar la continuidad del negocio.
  • Trabaja con tu equipo de seguridad para identificar recursos desconocidos, incluidos instancias de Compute Engine, instantáneas, cuentas de servicio y usuarios de IAM. Borra los recursos que no se crearon con cuentas autorizadas.
  • Responde las notificaciones de la asistencia de Google Cloud.

Privilege Escalation: AlloyDB Over-Privileged Grant

Detecta cuándo se otorgan a uno o más usuarios de bases de datos todos los privilegios sobre una base de datos de AlloyDB para PostgreSQL (o todas las funciones o procedimientos de una base de datos).

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre el resultado Privilege Escalation: AlloyDB Over-Privileged Grant, como se indica en Revisa los resultados.
  2. En la pestaña Resumen del panel de detalles del resultado, revisa la información en las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Nombre visible de la base de datos: Es el nombre de la base de datos de la instancia de AlloyDB para PostgreSQL afectada.
      • Nombre de usuario de la base de datos: El usuario de PostgreSQL que otorgó privilegios excesivos.
      • Consulta de la base de datos: Es la consulta de PostgreSQL ejecutada que otorgó los privilegios.
      • Beneficiarios de la base de datos: Los beneficiarios de privilegios demasiado amplios.
    • Recurso afectado, en especial los siguientes campos:
      • Nombre completo del recurso: El nombre del recurso de la instancia de AlloyDB para PostgreSQL que se vio afectada.
      • Nombre completo superior: Es el nombre del recurso de la instancia de AlloyDB para PostgreSQL.
      • Nombre completo del proyecto: El proyecto de Google Cloud que contiene la instancia de AlloyDB para PostgreSQL
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
  3. Para ver el JSON completo del resultado, haz clic en la pestaña JSON.

Paso 2: Revisa los privilegios de la base de datos

  1. Conéctate a la instancia de AlloyDB para PostgreSQL.
  2. Enumera y muestra los privilegios de acceso para lo siguiente:
    • Bases de datos. Usa el metacomando \l o \list y verifica qué privilegios están asignados para la base de datos que aparece en Nombre visible de la base de datos (del paso 1).
    • Funciones o procedimientos Usa el metacomando \df y verifica qué privilegios se asignan a las funciones o los procedimientos de la base de datos que aparece en Nombre visible de la base de datos (del Paso 1).

Paso 3: Comprueba los registros

  1. En la consola de Google Cloud, haz clic en el vínculo en URI de Cloud Logging (del paso 1) para ir al Explorador de registros. En la página Explorador de registros, se incluyen todos los registros relacionados con la instancia de Cloud SQL relevante.
  2. En el Explorador de registros, verifica los registros pgaudit de PostgreSQL, que registran las consultas ejecutadas en la base de datos, mediante los siguientes filtros:
    • protoPayload.request.database="var class="edit">database"

Paso 4: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada del framework MITRE ATT&CK para este tipo de resultado: Exfiltration Over Web Service.
  2. Para determinar si se necesitan pasos de corrección adicionales, combina los resultados de tu investigación con la investigación de MITRE.

Paso 5: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario de la instancia que tiene otorgamientos de privilegios excesivos.
  • Considera revocar todos los permisos de los beneficiarios que se enumeran en Beneficiarios de la base de datos hasta que se complete la investigación.
  • Para limitar el acceso a la base de datos (de la sección Nombre visible de la base de datos del Paso 1, revoke los permisos innecesarios de los beneficiarios (de los Beneficiarios de la base de datos del Paso 1).

Privilege Escalation: AlloyDB Database Superuser Writes to User Tables

Detecta cuándo la cuenta de superusuario de la base de datos de AlloyDB para PostgreSQL (postgres) escribe en tablas de usuarios. Por lo general, el superusuario (una función con acceso muy amplio) no se debe usar para escribir en las tablas de usuarios. Se debe usar una cuenta de usuario con acceso más limitado para realizar actividades diarias normales. Cuando un superusuario escribe en una tabla de usuario, eso podría indicar que un atacante escaló privilegios o que comprometió al usuario predeterminado de la base de datos y está modificando datos. También podría indicar prácticas normales pero inseguras.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un resultado de Privilege Escalation: AlloyDB Database Superuser Writes to User Tables, como se indica en Revisa los resultados.
  2. En la pestaña Resumen del panel de detalles del resultado, revisa la información en las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Nombre visible de la base de datos: Es el nombre de la base de datos de la instancia de AlloyDB para PostgreSQL afectada.
      • Nombre de usuario de la base de datos: el superusuario.
      • Consulta de base de datos: La consulta en SQL que se ejecuta mientras se escribe en las tablas de usuario.
    • Recurso afectado, en especial los siguientes campos:
      • Nombre completo del recurso: El nombre del recurso de la instancia de AlloyDB para PostgreSQL que se vio afectada.
      • Nombre completo superior: Es el nombre del recurso de la instancia de AlloyDB para PostgreSQL.
      • Nombre completo del proyecto: El proyecto de Google Cloud que contiene la instancia de AlloyDB para PostgreSQL
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
  3. Para ver el JSON completo del resultado, haz clic en la pestaña JSON.

Paso 2: Comprueba los registros

  1. En la consola de Google Cloud, ve al Explorador de registros mediante un clic en el vínculo en cloudLoggingQueryURI (del Paso 1). En la página Explorador de registros, se incluyen todos los registros relacionados con la instancia relevante de AlloyDB para PostgreSQL.
  2. Verifica los registros de pgaudit de PostgreSQL, que contienen las consultas que ejecutó el superusuario, mediante los siguientes filtros:
    • protoPayload.request.user="postgres"

Paso 3: Investiga los métodos de ataque y respuesta

  1. Revisa la entrada del framework MITRE ATT&CK para este tipo de resultado: Exfiltration Over Web Service.
  2. Para determinar si se necesitan pasos de corrección adicionales, combina los resultados de tu investigación con la investigación de MITRE.

Paso 4: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

Detecciones de metadatos del administrador de Compute Engine

Persistence: GCE Admin Added SSH Key

Descripción Acciones
La clave de metadatos de instancia de Compute Engine ssh-keys se cambió en una instancia establecida. La clave de metadatos de instancia de Compute Engine ssh-keys se modificó en una instancia que se creó hace más de siete días. Verifica si el cambio lo realizó de manera intencional un miembro o si un adversario lo implementó para agregar un nuevo acceso a tu organización.

Verifica los registros mediante los siguientes filtros:

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

Reemplaza lo siguiente:

  • INSTANCE_ID: el gceInstanceId que se muestra en el resultado
  • ORGANIZATION_ID: El ID de tu organización.

Eventos de investigación que activan este resultado:

Persistence: GCE Admin Added Startup Script

Descripción Acciones
La clave de metadatos startup-script o startup-script-url de la instancia de Compute Engine se cambió en una instancia establecida. La clave de metadatos de instancia de Compute Engine startup-script o startup-script-url se modificó en una instancia que se creó hace más de siete días. Verifica si el cambio lo realizó de manera intencional un miembro o si un adversario lo implementó para agregar un nuevo acceso a tu organización.

Verifica los registros mediante los siguientes filtros:

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

Reemplaza lo siguiente:

  • INSTANCE_ID: el gceInstanceId que se muestra en el resultado
  • ORGANIZATION_ID: El ID de tu organización.

Eventos de investigación que activan este resultado:

Detecciones de registros de Google Workspace

Si compartes tus registros de Google Workspace con Cloud Logging, Event Threat Detection genera hallazgos para varias amenazas de Google Workspace. Debido a que los registros de Google Workspace están a nivel de la organización, Event Threat Detection solo puede analizarlos si activas Security Command Center a nivel de la organización.

Event Threat Detection enriquece los eventos de registro y escribe los hallazgos en Security Command Center. En la siguiente tabla, se incluyen amenazas de Google Workspace, entradas relevantes del framework de MITRE ATT&CK y detalles sobre los eventos que activan resultados. También puedes verificar los registros mediante filtros específicos y combinar toda la información para responder a las amenazas de Google Workspace.

Initial Access: Disabled Password Leak

Este resultado no está disponible si activas Security Command Center a nivel de proyecto.

Descripción Acciones
Se inhabilitó la cuenta de un miembro porque se detectó un filtrado de contraseñas. Restablece las contraseñas de las cuentas afectadas y recomienda a los miembros que usen contraseñas seguras y únicas para las cuentas corporativas.

Verifica los registros mediante los siguientes filtros:

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

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

Reemplaza ORGANIZATION_ID por el ID de tu organización.

Eventos de investigación que activan este resultado:

Initial Access: Suspicious Login Blocked

Este resultado no está disponible si activas Security Command Center a nivel de proyecto.

Descripción Acciones
Se detectó y bloqueó un acceso sospechoso a la cuenta de un miembro. Los adversarios podrían intentar acceder a esta cuenta. Asegúrate de que la cuenta de usuario siga los lineamientos de seguridad de tu organización en términos de contraseñas seguras y autenticación de varios factores.

Verifica los registros mediante los siguientes filtros:

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

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

Reemplaza ORGANIZATION_ID por el ID de tu organización.

Eventos de investigación que activan este resultado:

Initial Access: Account Disabled Hijacked

Este resultado no está disponible si activas Security Command Center a nivel de proyecto.

Descripción Acciones
Se suspendió la cuenta de un miembro debido a una actividad sospechosa. Esta cuenta fue usurpada. Restablece la contraseña de la cuenta y alienta a los usuarios a crear contraseñas únicas y seguras para las cuentas corporativas.

Verifica los registros mediante los siguientes filtros:

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

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

Reemplaza ORGANIZATION_ID por el ID de tu organización.

Eventos de investigación que activan este resultado:

Impair Defenses: Two Step Verification Disabled

Este resultado no está disponible si activas Security Command Center a nivel de proyecto.

Descripción Acciones
Un miembro inhabilitó la verificación en dos pasos. Verifica si el usuario tenía la intención de inhabilitar la verificación en dos pasos. Si tu organización requiere la verificación en dos pasos, asegúrate de que el usuario la habilite de inmediato.

Verifica los registros mediante los siguientes filtros:

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

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

Reemplaza ORGANIZATION_ID por el ID de tu organización.

Eventos de investigación que activan este resultado:

Initial Access: Government Based Attack

Este resultado no está disponible si activas Security Command Center a nivel de proyecto.

Descripción Acciones
Es posible que atacantes respaldados por el Gobierno hayan intentado vulnerar una cuenta de un miembro o una computadora. Los adversarios podrían intentar acceder a esta cuenta. Asegúrate de que la cuenta de usuario siga los lineamientos de seguridad de tu organización en términos de contraseñas seguras y autenticación de varios factores.

Verifica los registros mediante los siguientes filtros:

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

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

Reemplaza ORGANIZATION_ID por el ID de tu organización.

Eventos de investigación que activan este resultado:

Persistence: SSO Enablement Toggle

Este resultado no está disponible si activas Security Command Center a nivel de proyecto.

Descripción Acciones
Se inhabilitó la configuración de habilitación del SSO (inicio de sesión único) en la cuenta de administrador. Se cambió la configuración del SSO de tu organización. Verifica si el cambio lo realizó de manera intencional un miembro o si un adversario lo implementó para agregar un nuevo acceso a tu organización.

Verifica los registros mediante los siguientes filtros:

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

protopayload.metadata.event.parameter.value=DOMAIN_NAME

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

Reemplaza lo siguiente:

  • DOMAIN_NAME: el domainName que se muestra en el resultado
  • ORGANIZATION_ID: El ID de tu organización.

Eventos de investigación que activan este resultado:

Persistence: SSO Settings Changed

Este resultado no está disponible si activas Security Command Center a nivel de proyecto.

Descripción Acciones
Se cambió la configuración de SSO para la cuenta de administrador. Se cambió la configuración del SSO de tu organización. Verifica si el cambio lo realizó de manera intencional un miembro o si un adversario lo implementó para agregar un nuevo acceso a tu organización.

Verifica los registros mediante los siguientes filtros:

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

protopayload.metadata.event.parameter.value=DOMAIN_NAME

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

Reemplaza lo siguiente:

  • DOMAIN_NAME: el domainName que se muestra en el resultado
  • ORGANIZATION_ID: El ID de tu organización.

Eventos de investigación que activan este resultado:

Impair Defenses: Strong Authentication Disabled

Este resultado no está disponible si activas Security Command Center a nivel de proyecto.

Descripción Acciones
Se inhabilitó la verificación en dos pasos para la organización. La verificación en dos pasos ya no es necesaria para tu organización. Averigua si se trata de un cambio de política intencional por parte de un administrador o si se trata de un intento de un adversario para facilitar la usurpación de una cuenta.

Verifica los registros mediante los siguientes filtros:

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

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

Reemplaza ORGANIZATION_ID por el ID de tu organización.

Eventos de investigación que activan este resultado:

Responde a las amenazas de Google Workspace

Los resultados de Google Workspace solo están disponibles para las activaciones de Security Command Center a nivel de la organización. Los registros de Google Workspace no se pueden analizar para detectar activaciones a nivel de proyecto.

Si eres administrador de Google Workspace, puedes usar las herramientas de seguridad del servicio para resolver estas amenazas:

Las herramientas incluyen alertas, un panel de seguridad y recomendaciones de seguridad. Además, pueden ayudarte a investigar y solucionar amenazas.

Si no eres administrador de Google Workspace, haz lo siguiente:

Detecciones de amenazas del IDS de Cloud

Cloud IDS: THREAT_ID

Los hallazgos de IDS de Cloud se generan a través del IDS de Cloud, que es un servicio de seguridad que supervisa el tráfico desde y hacia tus recursos de Google Cloud en busca de amenazas. Cuando el IDS de Cloud detecta una amenaza, envía información sobre la amenaza, como la dirección IP de origen, la dirección de destino y el número de puerto, a Event Threat Detection, que luego emite un hallazgo de amenaza.

Paso 1: Revisa los detalles del hallazgo
  1. Abre el resultado Cloud IDS: THREAT_ID, como se indica en Revisa los resultados.

  2. En los detalles del resultado, en la pestaña Resumen, revisa los valores enumerados en las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Protocolo: El protocolo de red que se usa
      • Hora del evento: Momento en el que ocurrió el evento
      • Descripción: Más información sobre el hallazgo
      • Gravedad: La gravedad de la alerta
      • IP de destino: la IP de destino del tráfico de red
      • Puerto de destino: el puerto de destino del tráfico de red
      • IP de origen: la IP de origen del tráfico de red
      • Puerto de origen: el puerto de origen del tráfico de red
    • Recurso afectado, en especial los siguientes campos:
      • Nombre completo del recurso: Es el proyecto que contiene la red con la amenaza.
    • Vínculos relacionados, especialmente los siguientes campos:
      • URI de Cloud Logging: Vincula a las entradas de Logging del IDS de Cloud. Estas entradas tienen la información necesaria para buscar en Threat Vault de Palo Alto Networks.
    • Servicio de detección
      • Categoría del hallazgo: El nombre de la amenaza del IDS de Cloud
  3. Para ver el JSON completo del resultado, haz clic en la pestaña JSON.

Paso 2: Buscar métodos de ataque y respuesta

Después de revisar los detalles del hallazgo, consulta la documentación del IDS de Cloud sobre cómo investigar alertas de amenazas para determinar una respuesta adecuada.

Para obtener más información sobre el evento detectado en la entrada de registro original, haz clic en el vínculo del campo URI de Cloud Logging en los detalles del resultado.

Respuestas de detección de amenazas a contenedores

Para obtener más información sobre Container Threat Detection, consulta cómo funciona Container Threat Detection.

Added Binary Executed

Se ejecutó un objeto binario que no era parte de la imagen del contenedor original. Los atacantes suelen instalar herramientas de explotación y software malicioso después del compromiso inicial. Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un resultado de Added Binary Executed como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen (Summary).

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Objeto binario del programa: La ruta de acceso absoluta del objeto binario agregado.
      • Argumentos: Son los argumentos que se proporcionan cuando se invoca el objeto binario agregado.
    • Recurso afectado, en especial los siguientes campos:
      • Nombre completo del recurso: Es el nombre completo del recurso del clúster, incluidos el número del proyecto, la ubicación y el nombre del clúster.
  3. Haz clic en el archivo JSON y observa los siguientes campos:

    • resource:
      • project_display_name: Es el nombre del proyecto que contiene el clúster.
    • sourceProperties:
      • Pod_Namespace: Es el nombre del espacio de nombres de Kubernetes del Pod.
      • Pod_Name: Es el nombre del Pod de GKE.
      • Container_Name: Es el nombre del contenedor afectado.
      • Container_Image_Uri: Es el nombre de la imagen de contenedor que se implementará.
      • VM_Instance_Name: Es el nombre del nodo de GKE en el que se ejecutó el Pod.

Paso 2: Revisa el clúster y el nodo

  1. En la consola de Google Cloud, ve a la página Clústeres de Kubernetes.

    Ir a los clústeres de Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Selecciona el clúster que aparece en la fila Nombre completo del recurso en la pestaña Resumen de los detalles del resultado. Toma nota de los metadatos sobre el clúster y su propietario.

  4. Haz clic en la pestaña Nodos. Selecciona el nodo que aparece en VM_Instance_Name.

  5. Haz clic en la pestaña Detalles y anota la anotación container.googleapis.com/instance_id.

Paso 3: Revisa el pod

  1. En la consola de Google Cloud, ve a la página Cargas de trabajo de Kubernetes.

    Ir a Cargas de trabajo en Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Filtra el clúster que aparece en la fila Nombre completo del recurso en la pestaña Resumen de los detalles del resultado y el espacio de nombres del Pod que aparece en Pod_Namespace, si es necesario.

  4. Selecciona el pod que aparece en Pod_Name. Toma nota de los metadatos del Pod y su propietario.

Paso 4: Comprueba los registros

  1. En la consola de Google Cloud, ve al Explorador de registros.

    Ir al Explorador de registros

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Selecciona Seleccionar período en el período de interés.

  4. En la página que se carga, haz lo siguiente:

    1. Busca los registros de Pod para Pod_Name mediante el siguiente filtro:
      • 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. Encuentra los registros de auditoría del clúster mediante el siguiente filtro:
      • 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. Busca los registros de la consola de los nodos de GKE mediante el siguiente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Paso 5: Investiga el contenedor en ejecución

Si el contenedor aún está en ejecución, es posible investigar el entorno del contenedor directamente.

  1. Ve a la consola de Google Cloud.

    Abrir la consola de Google Cloud

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Haz clic en Activate Cloud Shell (Activar Cloud Shell) .

  4. Obtén credenciales de GKE para tu clúster mediante la ejecución de los siguientes comandos.

    Para clústeres zonales:

      gcloud container clusters get-credentials cluster_name --zone location --project project_name
    

    Para clústeres regionales:

      gcloud container clusters get-credentials cluster_name --region location --project project_name
    

    Reemplaza lo siguiente:

    • cluster_name: el clúster que aparece en resource.labels.cluster_name
    • location: la ubicación que aparece en resource.labels.location
    • project_name: el nombre del proyecto que aparece en resource.project_display_name
  5. Para recuperar el objeto binario agregado, ejecuta lo siguiente:

      kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
    

    Reemplaza local_file por una ruta de archivo local con el fin de almacenar el objeto binario agregado.

  6. Conéctate al entorno del contenedor mediante la ejecución del siguiente comando:

      kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
    

    Este comando requiere que el contenedor tenga una shell instalada en /bin/sh.

Paso 6: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework de MITRE ATT&CK para este tipo de resultado: transferencia de herramientas de Ingress, API nativa.
  2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se encuentra el contenedor vulnerado.
  • Detén o borra el contenedor comprometido y reemplázalo por un contenedor nuevo.

Added Library Loaded

Se cargó una biblioteca que no formaba parte de la imagen del contenedor original. Los atacantes podrían cargar bibliotecas maliciosas en programas existentes para omitir las protecciones de ejecución de código y ocultar código malicioso. Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un resultado de Added Library Loaded como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen.

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Objeto binario del programa: Es la ruta de acceso completa del objeto binario del proceso que cargó la biblioteca.
      • Bibliotecas: Detalles sobre la biblioteca agregada
      • Argumentos: Son los argumentos que se proporcionan cuando se invoca el objeto binario de proceso.
    • Recurso afectado, en especial los siguientes campos:
  3. Haz clic en la pestaña JSON y observa los siguientes campos:

    • resource:
      • project_display_name: Es el nombre del proyecto que contiene el recurso.
    • sourceProperties:
      • Pod_Namespace: Es el nombre del espacio de nombres de Kubernetes del Pod.
      • Pod_Name: Es el nombre del Pod de GKE.
      • Container_Name: Es el nombre del contenedor afectado.
      • Container_Image_Uri: Es el nombre de la imagen de contenedor que se ejecuta.
      • VM_Instance_Name: Es el nombre del nodo de GKE en el que se ejecutó el Pod.

Paso 2: Revisa el clúster y el nodo

  1. En la consola de Google Cloud, ve a la página Clústeres de Kubernetes.

    Ir a los clústeres de Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Selecciona el clúster enumerado en resource.name. Toma nota de los metadatos sobre el clúster y su propietario.

  4. Haz clic en la pestaña Nodos. Selecciona el nodo que aparece en VM_Instance_Name.

  5. Haz clic en la pestaña Detalles y anota la anotación container.googleapis.com/instance_id.

Paso 3: Revisa el pod

  1. En la consola de Google Cloud, ve a la página Cargas de trabajo de Kubernetes.

    Ir a Cargas de trabajo en Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Filtra el clúster que aparece en la fila Nombre completo del recurso en la pestaña Resumen de los detalles del resultado y el espacio de nombres del Pod que aparece en Pod_Namespace, si es necesario.

  4. Selecciona el pod que aparece en Pod_Name. Toma nota de los metadatos del Pod y su propietario.

Paso 4: Comprueba los registros

  1. En la consola de Google Cloud, ve al Explorador de registros.

    Ir al Explorador de registros

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Selecciona Seleccionar período en el período de interés.

  4. En la página que se carga, haz lo siguiente:

    1. Busca los registros de Pod para Pod_Name mediante el siguiente filtro:
      • 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. Encuentra los registros de auditoría del clúster mediante el siguiente filtro:
      • 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. Busca los registros de la consola de los nodos de GKE mediante el siguiente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Paso 5: Investiga el contenedor en ejecución

Si el contenedor aún está en ejecución, es posible investigar el entorno del contenedor directamente.

  1. Ve a la consola de Google Cloud.

    Abrir la consola de Google Cloud

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Haz clic en Activate Cloud Shell (Activar Cloud Shell) .

  4. Obtén las credenciales de GKE para tu clúster mediante la ejecución de los siguientes comandos.

    Para clústeres zonales:

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

    Para clústeres regionales:

      gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
    
  5. Recupera la biblioteca agregada mediante la ejecución del siguiente comando:

      kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
    

    Reemplaza local_file por una ruta de archivo local para almacenar la biblioteca agregada.

  6. Conéctate al entorno del contenedor mediante la ejecución del siguiente comando:

      kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
    

    Este comando requiere que el contenedor tenga una shell instalada en /bin/sh.

Paso 6: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework de MITRE ATT&CK para este tipo de resultado: Transferencia de herramientas de Ingress, módulos compartidos.
  2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se encuentra el contenedor vulnerado.
  • Detén o borra el contenedor comprometido y reemplázalo por un contenedor nuevo.

Execution: Added Malicious Binary Executed

Se ejecutó un objeto binario malicioso que no formaba parte de la imagen del contenedor original. Los atacantes suelen instalar herramientas de explotación y software malicioso después del compromiso inicial. Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un resultado de Execution: Added Malicious Binary Executed como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen (Summary).

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Objeto binario del programa: La ruta de acceso absoluta del objeto binario agregado.
      • Argumentos: Son los argumentos que se proporcionan cuando se invoca el objeto binario agregado.
      • Contenedores: El nombre del contenedor afectado.
      • URI de contenedor: Es el nombre de la imagen de contenedor que se implementará.
    • Recurso afectado, en especial los siguientes campos:
      • Nombre completo del recurso: Es el nombre completo del recurso del clúster, incluidos el número del proyecto, la ubicación y el nombre del clúster.
    • Vínculos relacionados, especialmente los siguientes campos:
      • Indicador de VirusTotal: Vínculo a la página de análisis de VirusTotal.
  3. Haz clic en la pestaña JSON y observa los siguientes campos:

    • sourceProperties:
      • VM_Instance_Name: Es el nombre del nodo de GKE en el que se ejecutó el Pod.

Paso 2: Revisa el clúster y el nodo

  1. En la consola de Google Cloud, ve a la página Clústeres de Kubernetes.

    Ir a los clústeres de Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Selecciona el clúster que aparece en la fila Nombre completo del recurso en la pestaña Resumen de los detalles del resultado. Toma nota de los metadatos sobre el clúster y su propietario.

  4. Haz clic en la pestaña Nodos. Selecciona el nodo que aparece en VM_Instance_Name.

  5. Haz clic en la pestaña Detalles y anota la anotación container.googleapis.com/instance_id.

Paso 3: Revisa el pod

  1. En la consola de Google Cloud, ve a la página Cargas de trabajo de Kubernetes.

    Ir a Cargas de trabajo en Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Filtra el clúster que aparece en la fila Nombre completo del recurso en la pestaña Resumen de los detalles del resultado y el espacio de nombres del Pod que aparece en Pod_Namespace, si es necesario.

  4. Selecciona el pod que aparece en Pod_Name. Toma nota de los metadatos del Pod y su propietario.

Paso 4: Comprueba los registros

  1. En la consola de Google Cloud, ve al Explorador de registros.

    Ir al Explorador de registros

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Selecciona Seleccionar período en el período de interés.

  4. En la página que se carga, haz lo siguiente:

    1. Busca los registros de Pod para Pod_Name mediante el siguiente filtro:
      • 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. Encuentra los registros de auditoría del clúster mediante el siguiente filtro:
      • 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. Busca los registros de la consola de los nodos de GKE mediante el siguiente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Paso 5: Investiga el contenedor en ejecución

Si el contenedor aún está en ejecución, es posible investigar el entorno del contenedor directamente.

  1. Ve a la consola de Google Cloud.

    Abrir la consola de Google Cloud

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Haz clic en Activate Cloud Shell (Activar Cloud Shell) .

  4. Obtén credenciales de GKE para tu clúster mediante la ejecución de los siguientes comandos.

    Para clústeres zonales:

      gcloud container clusters get-credentials cluster_name --zone location --project project_name
    

    Para clústeres regionales:

      gcloud container clusters get-credentials cluster_name --region location --project project_name
    

    Reemplaza lo siguiente:

    • cluster_name: el clúster que aparece en resource.labels.cluster_name
    • location: la ubicación que aparece en resource.labels.location
    • project_name: el nombre del proyecto que aparece en resource.project_display_name
  5. Recupera el objeto binario malicioso agregado:

      kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
    

    Reemplaza local_file por una ruta local para almacenar el objeto binario malicioso agregado.

  6. Conéctate al entorno del contenedor:

      kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
    

    Este comando requiere que el contenedor tenga una shell instalada en /bin/sh.

Paso 6: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework de MITRE ATT&CK para este tipo de resultado: transferencia de herramientas de Ingress, API nativa.
  2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.
  3. Para verificar el valor de hash SHA-256 del objeto binario marcado como malicioso en VirusTotal, haz clic en el vínculo que aparece en el indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URL, dominios y direcciones IP potencialmente maliciosos.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se encuentra el contenedor vulnerado.
  • Detén o borra el contenedor comprometido y reemplázalo por un contenedor nuevo.

Execution: Added Malicious Library Loaded

Se cargó una biblioteca maliciosa que no formaba parte de la imagen del contenedor original. Los atacantes podrían cargar bibliotecas maliciosas en programas existentes para omitir las protecciones de ejecución de código y ocultar código malicioso. Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un resultado de Execution: Added Malicious Library Loaded como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen.

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Objeto binario del programa: Es la ruta de acceso completa del objeto binario del proceso que cargó la biblioteca.
      • Bibliotecas: Detalles sobre la biblioteca agregada
      • Argumentos: Son los argumentos que se proporcionan cuando se invoca el objeto binario de proceso.
      • Contenedores: El nombre del contenedor afectado.
      • URI de contenedor: Es el nombre de la imagen de contenedor que se implementará.
    • Recurso afectado, en especial los siguientes campos:
    • Vínculos relacionados, especialmente los siguientes campos:
      • Indicador de VirusTotal: Vínculo a la página de análisis de VirusTotal.
  3. Haz clic en la pestaña JSON y observa los siguientes campos:

    • sourceProperties:
      • VM_Instance_Name: Es el nombre del nodo de GKE en el que se ejecutó el Pod.

Paso 2: Revisa el clúster y el nodo

  1. En la consola de Google Cloud, ve a la página Clústeres de Kubernetes.

    Ir a los clústeres de Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Selecciona el clúster que aparece en la fila Nombre completo del recurso en la pestaña Resumen de los detalles del resultado. Toma nota de los metadatos sobre el clúster y su propietario.

  4. Haz clic en la pestaña Nodos. Selecciona el nodo que aparece en VM_Instance_Name.

  5. Haz clic en la pestaña Detalles y anota la anotación container.googleapis.com/instance_id.

Paso 3: Revisa el pod

  1. En la consola de Google Cloud, ve a la página Cargas de trabajo de Kubernetes.

    Ir a Cargas de trabajo en Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Filtra el clúster que aparece en la fila Nombre completo del recurso en la pestaña Resumen de los detalles del resultado y el espacio de nombres del Pod que aparece en Pod_Namespace, si es necesario.

  4. Selecciona el pod que aparece en Pod_Name. Toma nota de los metadatos del Pod y su propietario.

Paso 4: Comprueba los registros

  1. En la consola de Google Cloud, ve al Explorador de registros.

    Ir al Explorador de registros

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Selecciona Seleccionar período en el período de interés.

  4. En la página que se carga, haz lo siguiente:

    1. Busca los registros de Pod para Pod_Name mediante el siguiente filtro:
      • 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. Encuentra los registros de auditoría del clúster mediante el siguiente filtro:
      • 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. Busca los registros de la consola de los nodos de GKE mediante el siguiente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Paso 5: Investiga el contenedor en ejecución

Si el contenedor aún está en ejecución, es posible investigar el entorno del contenedor directamente.

  1. Ve a la consola de Google Cloud.

    Abrir la consola de Google Cloud

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Haz clic en Activate Cloud Shell (Activar Cloud Shell) .

  4. Obtén las credenciales de GKE para tu clúster mediante la ejecución de los siguientes comandos.

    Para clústeres zonales:

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

    Para clústeres regionales:

      gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
    
  5. Recupera la biblioteca maliciosa agregada:

      kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
    

    Reemplaza local_file por una ruta local para almacenar la biblioteca maliciosa agregada.

  6. Conéctate al entorno del contenedor:

      kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
    

    Este comando requiere que el contenedor tenga una shell instalada en /bin/sh.

Paso 6: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework de MITRE ATT&CK para este tipo de resultado: Transferencia de herramientas de Ingress, módulos compartidos.
  2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.
  3. Para verificar el valor de hash SHA-256 de la biblioteca marcada como maliciosa en VirusTotal, haz clic en el vínculo del indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URL, dominios y direcciones IP potencialmente maliciosos.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se encuentra el contenedor vulnerado.
  • Detén o borra el contenedor comprometido y reemplázalo por un contenedor nuevo.

Execution: Built in Malicious Binary Executed

Un objeto binario que se ejecutó, con el siguiente objeto:

  • Incluido en la imagen del contenedor original.
  • Identificado como malicioso según la inteligencia de amenazas.

El atacante tiene el control del repositorio de imágenes de contenedor o la canalización de creación, en la que el objeto binario malicioso se inserta en la imagen del contenedor. Para responder a este resultado, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un resultado de Execution: Built in Malicious Binary Executed como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen (Summary).

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Objeto binario del programa: Es la ruta de acceso absoluta del objeto binario integrado.
      • Argumentos: Son los argumentos que se proporcionan cuando se invoca el objeto binario integrado.
      • Contenedores: El nombre del contenedor afectado.
      • URI de contenedor: Es el nombre de la imagen de contenedor que se implementará.
    • Recurso afectado, en especial los siguientes campos:
      • Nombre completo del recurso: Es el nombre completo del recurso del clúster, incluidos el número del proyecto, la ubicación y el nombre del clúster.
    • Vínculos relacionados, especialmente los siguientes campos:
      • Indicador de VirusTotal: Vínculo a la página de análisis de VirusTotal.
  3. Haz clic en el archivo JSON y observa los siguientes campos:

    • sourceProperties:
      • VM_Instance_Name: Es el nombre del nodo de GKE en el que se ejecutó el Pod.

Paso 2: Revisa el clúster y el nodo

  1. En la consola de Google Cloud, ve a la página Clústeres de Kubernetes.

    Ir a los clústeres de Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Selecciona el clúster que aparece en la fila Nombre completo del recurso en la pestaña Resumen de los detalles del resultado. Toma nota de los metadatos sobre el clúster y su propietario.

  4. Haz clic en la pestaña Nodos. Selecciona el nodo que aparece en VM_Instance_Name.

  5. Haz clic en la pestaña Detalles y anota la anotación container.googleapis.com/instance_id.

Paso 3: Revisa el pod

  1. En la consola de Google Cloud, ve a la página Cargas de trabajo de Kubernetes.

    Ir a Cargas de trabajo en Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Filtra el clúster que aparece en la fila Nombre completo del recurso en la pestaña Resumen de los detalles del resultado y el espacio de nombres del Pod que aparece en Pod_Namespace, si es necesario.

  4. Selecciona el pod que aparece en Pod_Name. Toma nota de los metadatos del Pod y su propietario.

Paso 4: Comprueba los registros

  1. En la consola de Google Cloud, ve al Explorador de registros.

    Ir al Explorador de registros

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Selecciona Seleccionar período en el período de interés.

  4. En la página que se carga, haz lo siguiente:

    1. Busca los registros de Pod para Pod_Name mediante el siguiente filtro:
      • 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. Encuentra los registros de auditoría del clúster mediante el siguiente filtro:
      • 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. Busca los registros de la consola de los nodos de GKE mediante el siguiente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Paso 5: Investiga el contenedor en ejecución

Si el contenedor aún está en ejecución, es posible investigar el entorno del contenedor directamente.

  1. Ve a la consola de Google Cloud.

    Abrir la consola de Google Cloud

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Haz clic en Activate Cloud Shell (Activar Cloud Shell) .

  4. Obtén credenciales de GKE para tu clúster mediante la ejecución de los siguientes comandos.

    Para clústeres zonales:

      gcloud container clusters get-credentials cluster_name --zone location --project project_name
    

    Para clústeres regionales:

      gcloud container clusters get-credentials cluster_name --region location --project project_name
    

    Reemplaza lo siguiente:

    • cluster_name: el clúster que aparece en resource.labels.cluster_name
    • location: la ubicación que aparece en resource.labels.location
    • project_name: el nombre del proyecto que aparece en resource.project_display_name
  5. Recupera el objeto binario malicioso integrado:

      kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
    

    Reemplaza local_file por una ruta de acceso local para almacenar el objeto binario malicioso compilado.

  6. Conéctate al entorno del contenedor:

      kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
    

    Este comando requiere que el contenedor tenga una shell instalada en /bin/sh.

Paso 6: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework de MITRE ATT&CK para este tipo de resultado: transferencia de herramientas de Ingress, API nativa.
  2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.
  3. Para verificar el valor de hash SHA-256 del objeto binario marcado como malicioso en VirusTotal, haz clic en el vínculo que aparece en el indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URL, dominios y direcciones IP potencialmente maliciosos.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se encuentra el contenedor vulnerado.
  • Detén o borra el contenedor comprometido y reemplázalo por un contenedor nuevo.

Execution: Modified Malicious Binary Executed

Un objeto binario que se ejecutó, con el siguiente objeto:

  • Incluido en la imagen del contenedor original.
  • Se modifica durante el entorno de ejecución del contenedor.
  • Identificado como malicioso según la inteligencia de amenazas.

Los atacantes suelen instalar herramientas de explotación y software malicioso después del compromiso inicial. Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un resultado de Execution: Modified Malicious Binary Executed como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen (Summary).

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Objeto binario del programa: Es la ruta de acceso absoluta del objeto binario modificado.
      • Argumentos: Son los argumentos que se proporcionan cuando se invoca el objeto binario modificado.
      • Contenedores: El nombre del contenedor afectado.
      • URI de contenedor: Es el nombre de la imagen de contenedor que se implementará.
    • Recurso afectado, en especial los siguientes campos:
      • Nombre completo del recurso: Es el nombre completo del recurso del clúster, incluidos el número del proyecto, la ubicación y el nombre del clúster.
    • Vínculos relacionados, especialmente los siguientes campos:
      • Indicador de VirusTotal: Vínculo a la página de análisis de VirusTotal.
  3. Haz clic en el archivo JSON y observa los siguientes campos:

    • sourceProperties:
      • VM_Instance_Name: Es el nombre del nodo de GKE en el que se ejecutó el Pod.

Paso 2: Revisa el clúster y el nodo

  1. En la consola de Google Cloud, ve a la página Clústeres de Kubernetes.

    Ir a los clústeres de Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Selecciona el clúster que aparece en la fila Nombre completo del recurso en la pestaña Resumen de los detalles del resultado. Toma nota de los metadatos sobre el clúster y su propietario.

  4. Haz clic en la pestaña Nodos. Selecciona el nodo que aparece en VM_Instance_Name.

  5. Haz clic en la pestaña Detalles y anota la anotación container.googleapis.com/instance_id.

Paso 3: Revisa el pod

  1. En la consola de Google Cloud, ve a la página Cargas de trabajo de Kubernetes.

    Ir a Cargas de trabajo en Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Filtra el clúster que aparece en la fila Nombre completo del recurso en la pestaña Resumen de los detalles del resultado y el espacio de nombres del Pod que aparece en Pod_Namespace, si es necesario.

  4. Selecciona el pod que aparece en Pod_Name. Toma nota de los metadatos del Pod y su propietario.

Paso 4: Comprueba los registros

  1. En la consola de Google Cloud, ve al Explorador de registros.

    Ir al Explorador de registros

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Selecciona Seleccionar período en el período de interés.

  4. En la página que se carga, haz lo siguiente:

    1. Busca los registros de Pod para Pod_Name mediante el siguiente filtro:
      • 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. Encuentra los registros de auditoría del clúster mediante el siguiente filtro:
      • 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. Busca los registros de la consola de los nodos de GKE mediante el siguiente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Paso 5: Investiga el contenedor en ejecución

Si el contenedor aún está en ejecución, es posible investigar el entorno del contenedor directamente.

  1. Ve a la consola de Google Cloud.

    Abrir la consola de Google Cloud

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Haz clic en Activate Cloud Shell (Activar Cloud Shell) .

  4. Obtén credenciales de GKE para tu clúster mediante la ejecución de los siguientes comandos.

    Para clústeres zonales:

      gcloud container clusters get-credentials cluster_name --zone location --project project_name
    

    Para clústeres regionales:

      gcloud container clusters get-credentials cluster_name --region location --project project_name
    

    Reemplaza lo siguiente:

    • cluster_name: el clúster que aparece en resource.labels.cluster_name
    • location: la ubicación que aparece en resource.labels.location
    • project_name: el nombre del proyecto que aparece en resource.project_display_name
  5. Recupera el objeto binario malicioso modificado:

      kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
    

    Reemplaza local_file por una ruta de acceso local para almacenar el objeto binario malicioso modificado.

  6. Conéctate al entorno del contenedor:

      kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
    

    Este comando requiere que el contenedor tenga una shell instalada en /bin/sh.

Paso 6: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework de MITRE ATT&CK para este tipo de resultado: transferencia de herramientas de Ingress, API nativa.
  2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.
  3. Para verificar el valor de hash SHA-256 del objeto binario marcado como malicioso en VirusTotal, haz clic en el vínculo que aparece en el indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URL, dominios y direcciones IP potencialmente maliciosos.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se encuentra el contenedor vulnerado.
  • Detén o borra el contenedor comprometido y reemplázalo por un contenedor nuevo.

Execution: Modified Malicious Library Loaded

Una biblioteca que se cargó, con la biblioteca:

  • Incluido en la imagen del contenedor original.
  • Se modifica durante el entorno de ejecución del contenedor.
  • Identificado como malicioso según la inteligencia de amenazas.

Los atacantes podrían cargar bibliotecas maliciosas en programas existentes para omitir las protecciones de ejecución de código y ocultar código malicioso. Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un resultado de Execution: Modified Malicious Library Loaded como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen.

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Objeto binario del programa: Es la ruta de acceso completa del objeto binario del proceso que cargó la biblioteca.
      • Bibliotecas: Son detalles sobre la biblioteca modificada.
      • Argumentos: Son los argumentos que se proporcionan cuando se invoca el objeto binario de proceso.
      • Contenedores: El nombre del contenedor afectado.
      • URI de contenedor: Es el nombre de la imagen de contenedor que se implementará.
    • Recurso afectado, en especial los siguientes campos:
    • Vínculos relacionados, especialmente los siguientes campos:
      • Indicador de VirusTotal: Vínculo a la página de análisis de VirusTotal.
  3. Haz clic en la pestaña JSON y observa los siguientes campos:

    • sourceProperties:
      • VM_Instance_Name: Es el nombre del nodo de GKE en el que se ejecutó el Pod.

Paso 2: Revisa el clúster y el nodo

  1. En la consola de Google Cloud, ve a la página Clústeres de Kubernetes.

    Ir a los clústeres de Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Selecciona el clúster enumerado en resource.name. Toma nota de los metadatos sobre el clúster y su propietario.

  4. Haz clic en la pestaña Nodos. Selecciona el nodo que aparece en VM_Instance_Name.

  5. Haz clic en la pestaña Detalles y anota la anotación container.googleapis.com/instance_id.

Paso 3: Revisa el pod

  1. En la consola de Google Cloud, ve a la página Cargas de trabajo de Kubernetes.

    Ir a Cargas de trabajo en Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Filtra el clúster que aparece en la fila Nombre completo del recurso en la pestaña Resumen de los detalles del resultado y el espacio de nombres del Pod que aparece en Pod_Namespace, si es necesario.

  4. Selecciona el pod que aparece en Pod_Name. Toma nota de los metadatos del Pod y su propietario.

Paso 4: Comprueba los registros

  1. En la consola de Google Cloud, ve al Explorador de registros.

    Ir al Explorador de registros

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Selecciona Seleccionar período en el período de interés.

  4. En la página que se carga, haz lo siguiente:

    1. Busca los registros de Pod para Pod_Name mediante el siguiente filtro:
      • 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. Encuentra los registros de auditoría del clúster mediante el siguiente filtro:
      • 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. Busca los registros de la consola de los nodos de GKE mediante el siguiente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Paso 5: Investiga el contenedor en ejecución

Si el contenedor aún está en ejecución, es posible investigar el entorno del contenedor directamente.

  1. Ve a la consola de Google Cloud.

    Abrir la consola de Google Cloud

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Haz clic en Activate Cloud Shell (Activar Cloud Shell) .

  4. Obtén las credenciales de GKE para tu clúster mediante la ejecución de los siguientes comandos.

    Para clústeres zonales:

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

    Para clústeres regionales:

      gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
    
  5. Recupera la biblioteca maliciosa modificada:

      kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
    

    Reemplaza local_file por una ruta local para almacenar la biblioteca maliciosa modificada.

  6. Conéctate al entorno del contenedor:

      kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
    

    Este comando requiere que el contenedor tenga una shell instalada en /bin/sh.

Paso 6: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework de MITRE ATT&CK para este tipo de resultado: Transferencia de herramientas de Ingress, módulos compartidos.
  2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.
  3. Para verificar el valor de hash SHA-256 de la biblioteca marcada como maliciosa en VirusTotal, haz clic en el vínculo del indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URL, dominios y direcciones IP potencialmente maliciosos.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se encuentra el contenedor vulnerado.
  • Detén o borra el contenedor comprometido y reemplázalo por un contenedor nuevo.

Malicious Script Executed

Un modelo de aprendizaje automático identificó una secuencia de comandos Bash ejecutada como maliciosa. Los atacantes pueden usar Bash para transferir herramientas y ejecutar comandos sin objetos binarios.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un hallazgo de Malicious Script Executed como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen (Summary).

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Objeto binario del programa: Detalles sobre el intérprete que invocó la secuencia de comandos.
      • Secuencia de comandos: Es la ruta de acceso absoluta del nombre de la secuencia de comandos en el disco. Este atributo solo aparece para secuencias de comandos escritas en el disco, no para la ejecución literal de secuencia de comandos, por ejemplo, bash -c.
      • Argumentos: Son los argumentos que se proporcionan cuando se invoca la secuencia de comandos.
    • Recurso afectado, en especial los siguientes campos:
      • Nombre completo del recurso: El nombre completo del recurso del clúster, incluidos el número del proyecto, la ubicación y el nombre del clúster
  3. En la vista detallada del resultado, haz clic en la pestaña JSON.

  4. En el archivo JSON, observa los siguientes campos.

    • finding:
      • processes:
      • script:
        • contents: Prefijo del contenido del archivo de la secuencia de comandos ejecutada, que puede ayudar en la investigación. El contenido podría truncarse por motivos de rendimiento
        • sha256: El hash SHA-256 de script.contents
    • resource:
      • project_display_name: Es el nombre del proyecto que contiene el recurso.
    • sourceProperties:
      • Pod_Namespace: Es el nombre del espacio de nombres de Kubernetes del Pod.
      • Pod_Name: Es el nombre del Pod de GKE.
      • Container_Name: Es el nombre del contenedor afectado.
      • Container_Image_Uri: Es el nombre de la imagen de contenedor que se ejecuta.
      • VM_Instance_Name: Es el nombre del nodo de GKE en el que se ejecutó el Pod.

Paso 2: Revisa el clúster y el nodo

  1. En la consola de Google Cloud, ve a la página Clústeres de Kubernetes.

    Ir a los clústeres de Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Selecciona el clúster que aparece en la fila Nombre completo del recurso en la pestaña Resumen de los detalles del resultado. Toma nota de los metadatos sobre el clúster y su propietario.

  4. Haz clic en la pestaña Nodos. Selecciona el nodo que aparece en VM_Instance_Name.

  5. Haz clic en la pestaña Detalles y anota la anotación container.googleapis.com/instance_id.

Paso 3: Revisa el pod

  1. En la consola de Google Cloud, ve a la página Cargas de trabajo de Kubernetes.

    Ir a Cargas de trabajo en Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Filtra el clúster enumerado en resource.name y el espacio de nombres de pods enumerado en Pod_Namespace, si es necesario.

  4. Selecciona el pod que aparece en Pod_Name. Toma nota de los metadatos del Pod y su propietario.

Paso 4: Comprueba los registros

  1. En la consola de Google Cloud, ve al Explorador de registros.

    Ir al Explorador de registros

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Selecciona Seleccionar período en el período de interés.

  4. En la página que se carga, haz lo siguiente:

    1. Busca los registros de Pod para Pod_Name mediante el siguiente filtro:
      • 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. Encuentra los registros de auditoría del clúster mediante el siguiente filtro:
      • 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. Busca los registros de la consola de los nodos de GKE mediante el siguiente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Paso 5: Investiga el contenedor en ejecución

Si el contenedor aún está en ejecución, es posible investigar el entorno del contenedor directamente.

  1. En la consola de Google Cloud, ve a la página Clústeres de Kubernetes.

    Ir a los clústeres de Kubernetes

  2. Haz clic en el nombre del clúster que se muestra en resource.labels.cluster_name.

  3. En la página Clústeres, haz clic en Conectar y, luego, en Ejecutar en Cloud Shell.

    Cloud Shell se inicia y agrega comandos para el clúster en la terminal.

  4. Presiona Intro y, si aparece el cuadro de diálogo Autorizar Cloud Shell, haz clic en Autorizar.

  5. Conéctate al entorno del contenedor mediante la ejecución del siguiente comando:

      kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
    

    Este comando requiere que el contenedor tenga una shell instalada en /bin/sh.

Paso 6: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework de MITRE ATT&CK para este tipo de resultado: intérprete de comandos y secuencias de comandos, transferencia de herramientas Ingress.
  2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se encuentra el contenedor vulnerado.
  • Detén o borra el contenedor comprometido y reemplázalo por un contenedor nuevo.

Malicious URL Observed

La detección de amenazas a contenedores observó una URL maliciosa en la lista de argumentos de un proceso ejecutable. Los atacantes pueden cargar software malicioso o bibliotecas maliciosas a través de URLs maliciosas.

Para responder a este resultado, realiza los siguientes pasos.

Paso 1: Revisa los detalles del hallazgo

  1. Abre un hallazgo de Malicious URL Observed como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen (Summary).

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • URI: Es el URI malicioso observado.
      • Objeto binario agregado: La ruta de acceso completa del objeto binario del proceso que recibió los argumentos que contienen la URL maliciosa.
      • Argumentos: Son los argumentos que se proporcionan cuando se invoca el objeto binario del proceso.
      • Variables de entorno: Son las variables de entorno que estaban activas cuando se invocó el objeto binario del proceso.
      • Contenedores: Es el nombre del contenedor.
      • Pods de Kubernetes: El nombre del Pod y el espacio de nombres
    • Recurso afectado, en especial los siguientes campos:
      • Nombre visible del recurso: Es el nombre del recurso afectado.
      • Nombre completo del recurso: El nombre completo del recurso del clúster. El nombre completo del recurso incluye la siguiente información:
        • El proyecto que contiene el clúster: projects/PROJECT_ID
        • La ubicación en la que se encuentra el clúster: zone/ZONE o locations/LOCATION
        • El nombre del clúster: projects/CLUSTER_NAME
  3. En la pestaña JSON, en el atributo sourceProperties, observa el valor de la propiedad VM_Instance_Name.

Paso 2: Revisa el clúster y el nodo

  1. En la consola de Google Cloud, ve a la página Clústeres de Kubernetes.

    Ir a los clústeres de Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en Nombre completo del recurso (resource.name), si es necesario. El nombre del proyecto aparece después de /projects/ en el nombre completo del recurso.

  3. Haz clic en el nombre del clúster que anotaste en Nombre visible del recurso (resource.display_name) del resumen del resultado. Se abrirá la página Clústeres.

  4. En la sección Metadatos de la página **Detalles del clúster, anota cualquier información definida por el usuario que pueda ser útil para resolver la amenaza, como la información que identifica al propietario del clúster.

  5. Haz clic en la pestaña Nodos.

  6. En los nodos de la lista, selecciona el nodo que coincida con el valor de VM_Instance_Name que anotaste antes en el resultado JSON.

  7. En la pestaña Detalles de la página Detalles del nodo, en la sección Anotaciones, observa el valor de la anotación container.googleapis.com/instance_id.

Paso 3: Revisa el pod

  1. En la consola de Google Cloud, ve a la página Cargas de trabajo de Kubernetes.

    Ir a Cargas de trabajo en Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que anotaste en el Nombre completo del recurso (resource.name) del clúster en el resumen, si es necesario.

  3. Haz clic en Mostrar cargas de trabajo del sistema.

  4. Filtra la lista de cargas de trabajo según el nombre del clúster que anotaste en Nombre completo del recurso (resource.name) del resumen de resultados y, si es necesario, el Espacio de nombres del Pod (kubernetes.pods.ns) que anotaste.

  5. Haz clic en el nombre de la carga de trabajo que coincida con el valor de la propiedad VM_Instance_Name que anotaste en el JSON del resultado anteriormente. Se abrirá la página Detalles del Pod.

  6. En la página Detalles del Pod, anota cualquier información sobre el Pod que pueda ayudarte a resolver la amenaza.

Paso 4: Comprueba los registros

  1. En la consola de Google Cloud, ve al Explorador de registros.

    Ir al Explorador de registros

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en Nombre completo del recurso (resource.name), si es necesario.

  3. Selecciona Seleccionar período en el período de interés.

  4. En la página que se carga, haz lo siguiente:

    1. Encuentra los registros del Pod para tu Pod (kubernetes.pods.name) con el siguiente filtro:
      • 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. Encuentra los registros de auditoría del clúster mediante el siguiente filtro:
      • 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. Busca los registros de la consola de los nodos de GKE mediante el siguiente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

Paso 5: Investiga el contenedor en ejecución

Si el contenedor aún está en ejecución, es posible investigar el entorno del contenedor directamente.

  1. En la consola de Google Cloud, ve a la página Clústeres de Kubernetes.

    Ir a los clústeres de Kubernetes

  2. Haz clic en el nombre del clúster que se muestra en resource.labels.cluster_name.

  3. En la página Clústeres, haz clic en Conectar y, luego, en Ejecutar en Cloud Shell.

    Cloud Shell se inicia y agrega comandos para el clúster en la terminal.

  4. Presiona Intro y, si aparece el cuadro de diálogo Autorizar Cloud Shell, haz clic en Autorizar.

  5. Conéctate al entorno del contenedor mediante la ejecución del siguiente comando:

      kubectl exec --namespace=POD_NAMESPACE -ti POD_NAME -c CONTAINER_NAME -- /bin/sh
    

    Reemplaza CONTAINER_NAME por el nombre del contenedor que anotaste antes en el resumen de resultados.

    Este comando requiere que el contenedor tenga una shell instalada en /bin/sh.

Paso 6: Investiga los métodos de ataque y respuesta

  1. Consulta el estado del sitio de Navegación segura para obtener detalles sobre por qué la URL se clasifica como maliciosa.
  2. Revisa las entradas del framework MITRE ATT&CK para este tipo de resultado: transferencia de herramienta de entrada.
  3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación de MITRE.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se encuentra el contenedor vulnerado.
  • Detén o borra el contenedor comprometido y reemplázalo por un contenedor nuevo.

Reverse Shell

Es un proceso iniciado con redireccionamiento de transmisión a un socket remoto conectado. La generación de un shell conectado a la red puede permitir que un atacante realice acciones arbitrarias después de un compromiso inicial limitado. Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un hallazgo de Reverse Shell como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen (Summary).

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Objeto binario del programa: Es la ruta de acceso absoluta del proceso que se inicia con redireccionamiento de transmisión a un socket remoto.
      • Argumentos: Son los argumentos que se proporcionan cuando se invoca el objeto binario del proceso.
    • Recurso afectado, en especial los siguientes campos:
    • En la vista detallada del resultado, haz clic en la pestaña JSON.
    • En el archivo JSON, observa los siguientes campos.
    • resource:
      • project_display_name: Es el nombre del proyecto que contiene el recurso.
    • sourceProperties:
      • Pod_Namespace: Es el nombre del espacio de nombres de Kubernetes del Pod.
      • Pod_Name: Es el nombre del Pod de GKE.
      • Container_Name: Es el nombre del contenedor afectado.
      • VM_Instance_Name: Es el nombre del nodo de GKE en el que se ejecutó el Pod.
      • Reverse_Shell_Stdin_Redirection_Dst_Ip: la dirección IP remota de la conexión
      • Reverse_Shell_Stdin_Redirection_Dst_Port: el puerto remoto
      • Reverse_Shell_Stdin_Redirection_Src_Ip: la dirección IP local de la conexión
      • Reverse_Shell_Stdin_Redirection_Src_Port: el puerto local
      • Container_Image_Uri: Es el nombre de la imagen de contenedor que se ejecuta.

Paso 2: Revisa el clúster y el nodo

  1. En la consola de Google Cloud, ve a la página Clústeres de Kubernetes.

    Ir a los clústeres de Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Selecciona el clúster enumerado en resource.name. Toma nota de los metadatos sobre el clúster y su propietario.

  4. Haz clic en la pestaña Nodos. Selecciona el nodo que aparece en VM_Instance_Name.

  5. Haz clic en la pestaña Detalles y anota la anotación container.googleapis.com/instance_id.

Paso 3: Revisa el pod

  1. En la consola de Google Cloud, ve a la página Cargas de trabajo de Kubernetes.

    Ir a Cargas de trabajo en Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Filtra el clúster enumerado en resource.name y el espacio de nombres de pods enumerado en Pod_Namespace, si es necesario.

  4. Selecciona el pod que aparece en Pod_Name. Toma nota de los metadatos del Pod y su propietario.

Paso 4: Comprueba los registros

  1. En la consola de Google Cloud, ve al Explorador de registros.

    Ir al Explorador de registros

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Selecciona Seleccionar período en el período de interés.

  4. En la página que se carga, haz lo siguiente:

    1. Busca los registros de Pod para Pod_Name mediante el siguiente filtro:
      • 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. Encuentra los registros de auditoría del clúster mediante el siguiente filtro:
      • 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. Busca los registros de la consola de los nodos de GKE mediante el siguiente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Paso 5: Investiga el contenedor en ejecución

Si el contenedor aún está en ejecución, es posible investigar el entorno del contenedor directamente.

  1. Ve a la consola de Google Cloud.

    Abrir la consola de Google Cloud

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Haz clic en Activate Cloud Shell (Activar Cloud Shell) .

  4. Obtén las credenciales de GKE para tu clúster mediante la ejecución de los siguientes comandos.

    Para clústeres zonales:

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

    Para clústeres regionales:

      gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
    
  5. Inicia un shell dentro del entorno del contenedor mediante la ejecución de lo siguiente:

      kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
    

    Este comando requiere que el contenedor tenga una shell instalada en /bin/sh.

    Para ver todos los procesos que se ejecutan en el contenedor, ejecuta el siguiente comando en el shell del contenedor:

      ps axjf
    

    Este comando requiere que el contenedor tenga /bin/ps instalado.

Paso 6: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework de MITRE ATT&CK para este tipo de resultado: intérprete de comandos y secuencias de comandos, transferencia de herramientas Ingress.
  2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se encuentra el contenedor vulnerado.
  • Detén o borra el contenedor comprometido y reemplázalo por un contenedor nuevo.

Unexpected Child Shell

La detección de amenazas a contenedores observó un proceso que generó inesperadamente un proceso de shell secundario. Este evento podría indicar que un atacante intenta abusar de los comandos y las secuencias de comandos de shell.

Para responder a este resultado, realiza los siguientes pasos.

Paso 1: Revisa los detalles del hallazgo

  1. Abre un resultado de Unexpected Child Shell como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen (Summary).

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, en especial los siguientes campos:
      • Proceso superior: Es el proceso que creó de forma inesperada el proceso de shell secundario.
      • Proceso secundario: Es el proceso de shell secundario.
      • Argumentos: Son los argumentos proporcionados al objeto binario del proceso de shell secundario.
      • Variables de entorno: Son las variables de entorno del objeto binario del proceso de shell secundario.
      • Contenedores: Es el nombre del contenedor.
      • URI de contenedor: Es el URI de la imagen del contenedor.
      • Pods de Kubernetes: El nombre del Pod y el espacio de nombres
    • Recurso afectado, en especial los siguientes campos:
      • Nombre visible del recurso: Es el nombre del recurso afectado.
      • Nombre completo del recurso: El nombre completo del recurso del clúster. El nombre completo del recurso incluye la siguiente información:
        • El proyecto que contiene el clúster: projects/PROJECT_ID
        • La ubicación en la que se encuentra el clúster: zone/ZONE o locations/LOCATION
        • El nombre del clúster: projects/CLUSTER_NAME
  3. Haz clic en la pestaña JSON y observa los siguientes campos:

+processes: Un array que contiene todos los procesos relacionados con el resultado. Este array incluye el proceso de shell secundario y el proceso superior. +resource: +project_display_name: Es el nombre del proyecto que contiene los recursos. +sourceProperties: +VM_Instance_Name: Es el nombre del nodo de GKE en el que se ejecutó el Pod.

Paso 2: Revisa el clúster y el nodo

  1. En la consola de Google Cloud, ve a la página Clústeres de Kubernetes.

    Ir a los clústeres de Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name, si es necesario.

  3. Selecciona el clúster enumerado en resource.name. Toma nota de los metadatos sobre el clúster y su propietario.

  4. Haz clic en la pestaña Nodos. Selecciona el nodo que aparece en VM_Instance_Name.

  5. Haz clic en la pestaña Detalles y anota la anotación container.googleapis.com/instance_id.

Paso 3: Revisa el pod

  1. En la consola de Google Cloud, ve a la página Cargas de trabajo de Kubernetes.

    Ir a Cargas de trabajo en Kubernetes

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que anotaste en el Nombre completo del recurso (resource.name) del clúster en el resumen, si es necesario.

  3. Haz clic en Mostrar cargas de trabajo del sistema.

  4. Filtra la lista de cargas de trabajo por el nombre del clúster que anotaste en Nombre completo del recurso (resource.name) del resumen de resultados y, si es necesario, el Espacio de nombres del Pod (kubernetes.pods.ns) que anotaste.

  5. Haz clic en el nombre de la carga de trabajo que coincida con el valor de la propiedad VM_Instance_Name que anotaste en el JSON del resultado. Se abrirá la página Detalles del Pod.

  6. En la página Detalles del Pod, anota cualquier información sobre el Pod que pueda ayudarte a resolver la amenaza.

Paso 4: Comprueba los registros

  1. En la consola de Google Cloud, ve al Explorador de registros.

    Ir al Explorador de registros

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name.

  3. Selecciona Seleccionar período en el período de interés.

  4. En la página que se carga, haz lo siguiente:

    1. Busca los registros de Pod para Pod_Name mediante el siguiente filtro:
      • 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. Encuentra los registros de auditoría del clúster mediante el siguiente filtro:
      • 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. Busca los registros de la consola de los nodos de GKE mediante el siguiente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Paso 5: Investiga el contenedor en ejecución

Si el contenedor aún está en ejecución, es posible investigar el entorno del contenedor directamente.

  1. Ve a la consola de Google Cloud.

    Abrir la consola de Google Cloud

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en resource.project_display_name.

  3. Haz clic en Activate Cloud Shell (Activar Cloud Shell) .

  4. Obtén las credenciales de GKE para tu clúster mediante la ejecución de los siguientes comandos.

    Para los clústeres zonales, ejecuta lo siguiente:

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

    Para los clústeres regionales, ejecuta lo siguiente:

      gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
    
  5. Para iniciar una shell dentro del entorno del contenedor, ejecuta lo siguiente:

      kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
    

    Este comando requiere que el contenedor tenga una shell instalada en /bin/sh.

    Para ver todos los procesos que se ejecutan en el contenedor, ejecuta el siguiente comando en el shell del contenedor:

      ps axjf
    

    Este comando requiere que el contenedor tenga /bin/ps instalado.

Paso 6: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework MITRE ATT&CK para este tipo de resultado: Intérprete de comandos y secuencias de comandos: shell de Unix.
  2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

  • Comunícate con el propietario del proyecto en el que se encuentra el contenedor vulnerado.
  • Detén o borra el contenedor comprometido y reemplázalo por un contenedor nuevo.

Respuesta de detección de amenazas a VM

Para obtener más información sobre la detección de amenazas de VM, consulta la descripción general de la detección de amenazas de VM.

Execution: Cryptocurrency Mining Hash Match

VM Threat Detection detectó actividades de minería de criptomonedas mediante la coincidencia de los hashes de memoria de los programas en ejecución con los hash de la memoria del software conocido de minería de criptomonedas.

Para responder a estos resultados, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un resultado de Execution: Cryptocurrency Mining Hash Match, como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen.

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, especialmente los siguientes campos:

      • Familia binaria: Es la aplicación de criptomonedas que se detectó.
      • Objeto binario del programa: Es la ruta de acceso absoluta del proceso.
      • Argumentos: Son los argumentos que se proporcionan cuando se invoca el objeto binario del proceso.
      • Nombres de procesos: Es el nombre del proceso en ejecución en la instancia de VM asociado con las coincidencias de firmas detectadas.

      VM Threat Detection puede reconocer compilaciones de kernel de las principales distribuciones de Linux. Si puede reconocer la compilación del kernel de la VM afectada, puede identificar los detalles del proceso de la aplicación y propagar el campo processes del resultado. Si VM Threat Detection no puede reconocer el kernel (por ejemplo, si está compilado de forma personalizada), el campo processes del resultado no se propaga.

    • Recurso afectado, especialmente los siguientes campos:

      • Nombre completo del recurso: El nombre completo del recurso de la instancia de VM afectada, incluido el ID del proyecto que la contiene.
  3. Para ver el JSON completo de este resultado, en la vista detallada del resultado, haz clic en la pestaña JSON.

    • indicator
      • signatures:
        • memory_hash_signature: Una firma que corresponde a los hashes de la página de memoria.
        • detections
          • binary: Es el nombre del objeto binario de la aplicación de criptomonedas, por ejemplo, linux--x86-64_ethminer_0.19.0_alpha.0_cuda10.0.
          • percent_pages_matched: Es el porcentaje de páginas en la memoria que coinciden con las páginas en aplicaciones de criptomonedas conocidas en la base de datos de hash de la página.

Paso 2: Comprueba los registros

  1. En la consola de Google Cloud, ve al Explorador de registros.

    Ir al Explorador de registros

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que contiene la instancia de VM, como se especifica en la fila Nombre completo del recurso en la pestaña Resumen de los detalles del resultado.

  3. Revisa los registros en busca de intrusiones en la instancia de VM afectada. Por ejemplo, revisa si hay actividades sospechosas o desconocidas y signos de credenciales comprometidas.

Paso 3: Revisa los permisos y la configuración

  1. En la consola de Google Cloud, ve a la página Panel.

    Ir al panel

  2. Haz clic en la lista desplegable Seleccionar desde en la parte superior de la página. En la ventana Seleccionar desde que aparece, elige el proyecto que se identifica en la fila Nombre completo del recurso en la pestaña Resumen de los detalles del resultado.

  3. Navega a la tarjeta Recursos y haz clic en Compute Engine.

  4. Haz clic en la instancia de VM que coincide con el proyecto que se identifica en Nombre completo del recurso. Revisa los detalles de la instancia, incluida la configuración de red y acceso.

Paso 4: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework MITRE ATT&CK para su ejecución.
  2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 5: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

Para ayudar con la detección y la eliminación, usa una solución de detección y respuesta de extremos.

  1. Comunícate con el propietario de la VM.
  2. Confirma si se trata de una aplicación de minería:

    • Si el nombre del proceso de la aplicación detectada y la ruta de acceso binaria están disponibles, considera los valores de las filas Programa binario, Argumentos y Nombres de procesos en la pestaña Resumen de los detalles del resultado de tu investigación.

    • Si los detalles del proceso no están disponibles, verifica si el nombre binario de la firma de hash de la memoria puede proporcionar pistas. Considera un objeto binario llamado linux-x86-64_xmrig_2.14.1. Puedes usar el comando grep para buscar archivos destacados en el almacenamiento. Usa una parte significativa del nombre del objeto binario en tu patrón de búsqueda, en este caso, xmrig. Examina los resultados de la búsqueda.

    • Examina los procesos en ejecución, en especial los que tienen un alto uso de CPU, para ver si hay alguno que no reconoces. Determinar si las aplicaciones asociadas son aplicaciones de minería

    • Busca en los archivos almacenados las cadenas comunes que usan las aplicaciones de minería, como btc.com, ethminer, xmrig, cpuminer y randomx. Para obtener más ejemplos de cadenas que puedes buscar, consulta Nombres de software y reglas YARA y la documentación relacionada para cada software enumerado.

  3. Si determinas que la aplicación es una aplicación de minería y que su proceso aún se está ejecutando, finaliza el proceso. Localiza el objeto binario ejecutable de la aplicación en el almacenamiento de la VM y bórralo.

  4. Si es necesario, detén la instancia comprometida y reemplázala por una instancia nueva.

Execution: Cryptocurrency Mining YARA Rule

VM Threat Detection detectó actividades de minería de criptomonedas mediante patrones de memoria coincidentes, como las constantes de prueba de trabajo, que se conocen por usar en el software de minería de criptomonedas.

Para responder a estos resultados, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

  1. Abre un resultado de Execution: Cryptocurrency Mining YARA Rule, como se indica en Revisa los resultados. El panel de detalles del resultado se abre en la pestaña Resumen.

  2. En la pestaña Resumen, revisa la información de las siguientes secciones:

    • Qué se detectó, especialmente los siguientes campos:

      • Nombre de la regla YARA: Es la regla activada para los detectores YARA.
      • Objeto binario del programa: Es la ruta de acceso absoluta del proceso.
      • Argumentos: Son los argumentos que se proporcionan cuando se invoca el objeto binario del proceso.
      • Nombres de procesos: El nombre de los procesos en ejecución en la instancia de VM que está asociado con las coincidencias de firmas detectadas.

      VM Threat Detection puede reconocer compilaciones de kernel de las principales distribuciones de Linux. Si puede reconocer la compilación del kernel de la VM afectada, puede identificar los detalles del proceso de la aplicación y propagar el campo processes del resultado. Si VM Threat Detection no puede reconocer el kernel (por ejemplo, si está compilado de forma personalizada), el campo processes del resultado no se propaga.

    • Recurso afectado, especialmente los siguientes campos:

      • Nombre completo del recurso: El nombre completo del recurso de la instancia de VM afectada, incluido el ID del proyecto que la contiene.
    • Vínculos relacionados, especialmente los siguientes campos:

      • URI de Cloud Logging: Vincula a entradas de Logging.
      • Método MITRE ATT&CK: Vínculo a la documentación de MITRE ATT&CK.
      • Resultados relacionados: vínculos a cualquier resultado relacionado.
      • Indicador de VirusTotal: Vínculo a la página de análisis de VirusTotal.
      • Chronicle: Vínculo a Chronicle
  3. Para ver el JSON completo de este resultado, en la vista detallada del resultado, haz clic en la pestaña JSON.

Paso 2: Comprueba los registros

  1. En la consola de Google Cloud, ve al Explorador de registros.

    Ir al Explorador de registros

  2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que contiene la instancia de VM, como se especifica en la fila Nombre completo del recurso en la pestaña Resumen de los detalles del resultado.

  3. Revisa los registros en busca de intrusiones en la instancia de VM afectada. Por ejemplo, revisa si hay actividades sospechosas o desconocidas y signos de credenciales comprometidas.

Paso 3: Revisa los permisos y la configuración

  1. En la consola de Google Cloud, ve a la página Panel.

    Ir al panel

  2. Haz clic en la lista desplegable Seleccionar desde en la parte superior de la página. En la ventana Seleccionar desde que aparece, elige el proyecto que está incluido en el nombre del recurso que aparece en la fila Nombre completo del recurso en la pestaña Resumen de los detalles del resultado.

  3. Navega a la tarjeta Recursos y haz clic en Compute Engine.

  4. Haz clic en la instancia de VM que coincide con resourceName. Revisa los detalles de la instancia, incluida la configuración de red y acceso.

Paso 4: Investiga los métodos de ataque y respuesta

  1. Revisa las entradas del framework MITRE ATT&CK para su ejecución.
  2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 5: Implementa tu respuesta

El siguiente plan de respuesta podría ser apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

Para ayudar con la detección y la eliminación, usa una solución de detección y respuesta de extremos.

  1. Comunícate con el propietario de la VM.
  2. Confirma si se trata de una aplicación de minería:

    • Si el nombre del proceso de la aplicación detectada y la ruta de acceso binaria están disponibles, considera los valores de las filas Programa binario, Argumentos y Nombres de procesos en la pestaña Resumen de los detalles del resultado de tu investigación.

    • Examina los procesos en ejecución, en especial los que tienen un alto uso de CPU, para ver si hay alguno que no reconoces. Determinar si las aplicaciones asociadas son aplicaciones de minería

    • Busca en los archivos almacenados las cadenas comunes que usan las aplicaciones de minería, como btc.com, ethminer, xmrig, cpuminer y randomx. Para obtener más ejemplos de cadenas que puedes buscar, consulta Nombres de software y reglas YARA y la documentación relacionada para cada software enumerado.

  3. Si determinas que la aplicación es una aplicación de minería y que su proceso aún se está ejecutando, finaliza el proceso. Localiza el objeto binario ejecutable de la aplicación en el almacenamiento de la VM y bórralo.

  4. Si es necesario, detén la instancia comprometida y reemplázala por una instancia nueva.

Execution: cryptocurrency mining combined detection

La detección de amenazas de VM detectó varias categorías de hallazgos en un solo día desde una sola fuente. Una sola aplicación puede activar Execution: Cryptocurrency Mining YARA Rule y Execution: Cryptocurrency Mining Hash Match findings de forma simultánea.

A fin de responder a un resultado combinado, sigue las instrucciones de respuesta para Execution: Cryptocurrency Mining YARA Rule y Execution: Cryptocurrency Mining Hash Match findings.

Para evitar que las amenazas vuelvan a ocurrir, revisa y corrige los hallazgos de vulnerabilidades y parámetros de configuración incorrectos relacionados.

Para encontrar resultados relacionados, sigue estos pasos:

  1. En la consola de Google Cloud, ve a la página Resultados de Security Command Center.

    Ir a resultados

  2. Revisa el hallazgo de amenazas y copia el valor de un atributo que probablemente aparezca en cualquier vulnerabilidad relacionada o resultado de configuración incorrecta, como la dirección de correo electrónico principal o el nombre del recurso afectado.

  3. En la página Resultados, haz clic en Editar consulta para abrir el Editor de consultas.

  4. Haga clic en Agregar filtro. Se abrirá el menú Seleccionar filtro.

  5. En la lista de categorías de filtro en el lado izquierdo del menú, selecciona la categoría que contiene el atributo que anotaste en el resultado de amenazas.

    Por ejemplo, si anotaste el nombre completo del recurso afectado, selecciona Recurso. Los tipos de atributos de la categoría Resource se muestran en la columna de la derecha, incluido el atributo Full name.

  6. En los atributos que se muestran, selecciona el tipo de atributo que anotaste en el hallazgo de amenazas. A la derecha, se abrirá un panel de búsqueda de valores de atributos en el que se mostrarán todos los valores encontrados del tipo de atributo seleccionado.

  7. En el campo Filtro, pega el valor del atributo que copiaste del hallazgo de amenaza. La lista de valores que se muestra se actualiza para mostrar solo los valores que coinciden con el valor pegado.

  8. En la lista de valores que se muestran, selecciona uno o más valores y haz clic en Apply. El panel Resultados de la consulta de resultados se actualiza para mostrar solo los resultados de coincidencias.

  9. Si hay muchos hallazgos en los resultados, fíltralos seleccionando filtros adicionales del panel Filtros rápidos.

    Por ejemplo, para mostrar solo los resultados de las clases Vulnerability y Misconfiguration que contienen los valores de los atributos seleccionados, desplázate hacia abajo hasta la sección Clase de resultados del panel Filtros rápidos y selecciona Vulnerabilidad y Configuración incorrecta.

Además de los indicadores de compromiso proporcionados por Google, los usuarios que son clientes de Palo Alto Networks pueden integrar AutoFocus Threat Intelligence de Palo Alto Networks con Event Threat Detection. AutoFocus es un servicio de inteligencia de amenazas que proporciona información sobre las amenazas de red. Para obtener más información, visita la página AutoFocus en la consola de Google Cloud.

Cómo solucionar las amenazas

Solucionar los resultados de Event Threat Detection y Container Threat Detection no es tan simple como corregir las configuraciones incorrectas y las vulnerabilidades que identifica Security Command Center.

Los errores de configuración y las infracciones de cumplimiento identifican debilidades en los recursos que podrían aprovecharse. Por lo general, los errores de configuración tienen correcciones conocidas y fáciles de implementar, como habilitar un firewall o rotar una clave de encriptación.

Las amenazas se diferencian de las vulnerabilidades porque son dinámicas y señalan un posible ataque activo a uno o más recursos. Es posible que una recomendación de solución no sea efectiva para proteger tus recursos porque es posible que no se conozcan los métodos exactos usados para lograr la vulnerabilidad.

Por ejemplo, un resultado de Added Binary Executed indica que se inició un objeto binario no autorizado en un contenedor. Una recomendación básica de solución podría recomendarte poner en cuarentena el contenedor y borrar el objeto binario, pero eso podría no resolver la causa raíz subyacente que permitió que el atacante acceda a ejecutar el objeto binario. Debes averiguar cómo se dañó la imagen del contenedor para corregir la vulnerabilidad. Para determinar si el archivo se agregó a través de un puerto mal configurado o mediante otros medios, se requiere una investigación exhaustiva. Es posible que un analista con conocimiento de nivel experto sobre tu sistema deba revisarlo para detectar debilidades.

Las personas que actúan de mala fe atacan recursos mediante técnicas diferentes, por lo que aplicar una solución para un ataque específico podría no ser eficaz en comparación con las variaciones de ese ataque. Por ejemplo, en respuesta a un resultado de Brute Force: SSH, puedes reducir los niveles de permiso para algunas cuentas de usuario a fin de limitar el acceso a los recursos. Sin embargo, las contraseñas poco seguras aún pueden proporcionar una ruta de acceso de ataque.

La variedad de vectores de ataque dificulta la tarea de proporcionar pasos de solución que funcionen en todas las situaciones. La función de Security Command Center en tu plan de seguridad en la nube sirve para identificar los recursos afectados casi en tiempo real, informarte a qué amenazas te enfrentas, y proporcionar evidencia y contexto para ayudarte con las investigaciones. Sin embargo, el personal de seguridad debe usar la información exhaustiva en los hallazgos de Security Command Center para determinar las mejores formas de solucionar problemas y proteger los recursos frente a ataques futuros.

¿Qué sigue?