Investigar las amenazas y responder ante ellas

En este documento, se ofrece orientación informal para ayudarte a investigar los hallazgos de actividades sospechosas en tu entorno de Google Cloud de parte de actores potencialmente maliciosos. En este documento, también se proporcionan recursos adicionales para 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 las transmisiones de registros de Cloud Logging con indicadores de compromiso (IoC) conocidos. Los IoC, desarrollados por las fuentes de seguridad internas de Google, identifican posibles vulnerabilidades y ataques. Event Threat Detection también detecta amenazas mediante la identificación de tácticas, técnicas y procedimientos adversos conocidos en la transmisión de registros, además de 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 tus 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 resultados de amenazas en la consola de Google Cloud, sigue estos pasos:

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

   Ir a hallazgos

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

   

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

   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 de resultados 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 activos. 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. Si está disponible, el campo VirusTotal Indicator proporciona un vínculo a VirusTotal para ayudarte a investigar más a fondo los posibles problemas de seguridad.

  VirusTotal es una oferta con un precio independiente que tiene diferentes límites de uso y funciones. Usted es responsable de comprender y cumplir con las políticas de uso de la API de VirusTotal y cualquier costo asociado. Para obtener más información, consulta la documentación de VirusTotal.

  Nota: Es posible que VirusTotal no contenga hashes para todas las variantes de software malicioso.

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

Desactivación de los resultados de amenazas

Después de resolver un problema que activó un hallazgo de amenaza, Security Command Center no establece automáticamente el estado del hallazgo en INACTIVE. El estado de un hallazgo de amenaza permanece como ACTIVE, a menos que configures manualmente la propiedad state como INACTIVE.

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

Para los falsos positivos persistentes o recurrentes, crea una regla de silenciamiento. Configurar una regla de silenciamiento puede reducir la cantidad de resultados que debes gestionar, lo que facilita la identificación de una amenaza real cuando ocurre.

Para una amenaza real, 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 hallazgo y problema relacionados.

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

• Cómo silenciar resultados
• Cómo cambiar el estado de un hallazgo

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.

Esta sección no contiene respuestas para los resultados generados por 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.

Nota: Google Cloud tiene su propio mecanismo interno para identificar direcciones IP 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 hallazgo de Evasion: Access from Anonymizing Proxy, como se indica en Revisa los hallazgos. Se abrirá el panel de detalles del resultado, en el que se mostrará la pestaña Resumen.

2. En la pestaña Resumen del panel de detalles de la búsqueda, 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: Es la dirección IP del proxy desde la que se realizan los cambios.
   • Recurso afectado
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.

3. De forma opcional, haz clic en la pestaña JSON para ver campos de resultados adicionales.

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

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Para detectar Breakglass Workload Deployment Created, se examinan los Registros de auditoría de Cloud para ver si hay implementaciones en cargas de trabajo que usan la marca de emergencia para anular los controles de Autorización Binaria.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Defense Evasion: Breakglass Workload Deployment Created, como se indica en Revisa los hallazgos. Se abrirá el panel de detalles del hallazgo, en el que se mostrará 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: Es la cuenta que realizó la modificación.
     • Nombre del método: Es el método al que se llamó.
     • Pods de Kubernetes: El nombre y el espacio de nombres del pod.
   • Recurso afectado, en especial el siguiente campo:
     • Nombre visible del recurso: Es el espacio de nombres de GKE en el que se realizó la implementación.
   • Vínculos relacionados:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.

Paso 2: Comprueba los registros

1. En la pestaña Resumen de los detalles del hallazgo 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 el valor en el campo protoPayload.resourceName para identificar la solicitud de firma de certificado específica.

3. Para verificar si el principal realizó otras acciones, usa los siguientes filtros:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Reemplaza lo siguiente:

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

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

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: Defense Evasion: Breakglass Workload Deployment.
2. Para revisar los resultados relacionados, haz clic en el vínculo Resultados relacionados en 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

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Para detectar Breakglass Workload Deployment Updated, se examinan los registros de auditoría de Cloud para ver si hay actualizaciones en las cargas de trabajo que usan la marca de emergencia para anular los controles de Autorización Binaria.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Defense Evasion: Breakglass Workload Deployment Updated, como se indica en Revisa los hallazgos. Se abrirá el panel de detalles del hallazgo, en el que se mostrará 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: Es la cuenta que realizó la modificación.
     • Nombre del método: Es el método al que se llamó.
     • Pods de Kubernetes: El nombre y el espacio de nombres del pod.
   • Recurso afectado, en especial el siguiente campo:
     • Nombre visible del recurso: Es el espacio de nombres de GKE en el que se produjo la actualización.
   • Vínculos relacionados:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.

Paso 2: Comprueba los registros

1. En la pestaña Resumen de los detalles del hallazgo 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 el valor en el campo protoPayload.resourceName para identificar la solicitud de firma de certificado específica.

3. Para verificar si el principal realizó otras acciones, usa los siguientes filtros:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Reemplaza lo siguiente:

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

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

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: Defense Evasion: Breakglass Workload Deployment.
2. Para revisar los resultados relacionados, haz clic en el vínculo Resultados relacionados en 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: Manually Deleted Certificate Signing Request (CSR)

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Alguien borró de forma manual una solicitud de firma de certificado (CSR). Un controlador de recolección de elementos no utilizados quita los CSR de forma automática, pero los agentes maliciosos pueden borrarlos de forma manual para evadir la detección. Si la CSR borrada era para un certificado aprobado y emitido, el agente potencialmente malicioso ahora tiene un método de autenticación adicional para acceder al clúster. Los permisos asociados con el certificado varían según el sujeto que incluyan, pero pueden tener privilegios elevados. Kubernetes no admite la revocación de certificados. Para obtener más detalles, consulta el mensaje de registro de esta alerta.

1. Revisa los registros de auditoría en Cloud Logging y las alertas adicionales para otros eventos relacionados con esta CSR con el propósito de determinar si la CSR era approved y si su creación era una actividad esperada por parte de la principal.
2. Determina si hay otros indicios de actividad maliciosa por parte de la principal en los registros de auditoría de Cloud Logging. Por ejemplo:
   • ¿La principal que borró la CSR era diferente de la que la creó o aprobó?
   • ¿La principal intentó solicitar, crear, aprobar o borrar otras CSR?
3. Si no se esperaba una aprobación de CSR o se determina que es maliciosa, el clúster requerirá una rotación de credenciales para invalidar el certificado. Revisa la información para realizar una rotación de las credenciales del clúster.

Defense Evasion: Modify VPC Service Control

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

Los registros de auditoría se examinan para detectar cambios en los perímetros de los Controles del servicio de VPC que generarían una reducción en 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 hallazgo de Defense Evasion: Modify VPC Service Control, como se indica en Revisa los hallazgos. Se abre el panel de detalles del hallazgo, en el que se muestra la pestaña Resumen.

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: Es 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: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.

3. Haz clic en la pestaña JSON.

4. En el JSON, toma nota de 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, en 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 hallazgo, 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 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 Resultados relacionados en 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 adecuado 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.

Defense Evasion: Potential Kubernetes Pod Masquerading

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Alguien implementó un Pod con una convención de nombres similar a las cargas de trabajo predeterminadas que GKE crea para la operación normal del clúster. Esta técnica se denomina suplantación de identidad. Para obtener más detalles, consulta el mensaje de registro de esta alerta.

1. Confirma que el Pod es legítimo.
2. Determina si hay otros indicios de actividad maliciosa del Pod o la principal en los registros de auditoría de Cloud Logging.
3. Si la principal no es una cuenta de servicio (IAM o Kubernetes), comunícate con el propietario de la cuenta para confirmar si el propietario legítimo realizó la acción.
4. Si la principal es una cuenta de servicio (IAM o Kubernetes), identifica el origen de la acción para determinar su legitimidad.
5. Si el Pod no es legítimo, quítalo junto con las vinculaciones de RBAC y las cuentas de servicio asociadas que usó la carga de trabajo y que permitieron su creación.

Discovery: Can get sensitive Kubernetes object check

Un agente potencialmente malicioso intentó determinar qué objetos sensibles en GKE puede consultar mediante el comando kubectl auth can-i get. Específicamente, el atacante 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 hallazgo de Discovery: Can get sensitive Kubernetes object check como se indica en Revisa los hallazgos.

2. En los detalles del hallazgo, en la pestaña Resumen, observa los valores de los siguientes campos:

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

Paso 2: Comprueba los registros

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

2. En la página que se carga, usa los siguientes filtros para verificar si el principal realizó otras acciones:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Reemplaza lo siguiente:

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

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

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

1. Revisa las entradas del framework de 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 del principal en los registros.

3. Si la cuenta que anotaste en la fila Correo electrónico principal en los detalles del resultado 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 del MITRE.

Execution: Kubernetes Pod Created with Potential Reverse Shell Arguments

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Alguien creó un Pod que contiene comandos o argumentos comúnmente asociados con un shell inverso. Los atacantes usan shells inversos para expandir o mantener su acceso inicial a un clúster y ejecutar comandos arbitrarios. Para obtener más detalles, consulta el mensaje de registro de esta alerta.

1. Confirma que el Pod tiene una razón legítima para especificar estos comandos y argumentos.
2. Determina si hay otros indicios de actividad maliciosa del Pod o la principal en los registros de auditoría de Cloud Logging.
3. Si la principal no es una cuenta de servicio (IAM o Kubernetes), comunícate con el propietario de la cuenta para confirmar si el propietario legítimo realizó la acción.
4. Si la principal es una cuenta de servicio (IAM o Kubernetes), identifica la legitimidad de lo que provocó que la cuenta de servicio realice esta acción.
5. Si el Pod no es legítimo, quítalo junto con las vinculaciones de RBAC y las cuentas de servicio asociadas que usó la carga de trabajo y que permitieron su creación.

Execution: Suspicious Exec or Attach to a System Pod

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Alguien usó los comandos exec o attach para obtener un shell o ejecutar un comando en un contenedor que se ejecuta en el espacio de nombres kube-system. A veces, estos métodos se usan con fines de depuración legítimos. Sin embargo, kube-system namespace está diseñado para objetos del sistema creados por Kubernetes, y se debe revisar la ejecución de comandos o la creación de shells inesperadas. Para obtener más detalles, consulta el mensaje de registro de esta alerta.

1. Revisa los registros de auditoría en Cloud Logging para determinar si esta era la actividad esperada por la principal.
2. Determina si hay otros indicios de actividad maliciosa por parte del principal en los registros.

Revisa la guía para usar el principio de privilegio mínimo de los roles de RBAC y de clúster que permitieron este acceso.

Exfiltration: BigQuery Data Exfiltration

Los resultados que muestra Exfiltration: BigQuery Data Exfiltration contienen una de las 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 acceder a recursos de BigQuery.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Exfiltration: BigQuery Data Exfiltration, como se indica en Revisa los hallazgos.

2. En la pestaña Resumen del panel de detalles de búsqueda, revisa los valores que se enumeran 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: Es la cuenta que se usó para robar los datos.
     • Fuentes de robo de datos: Detalles sobre las tablas de las que se robaron datos.
     • Objetivos de robo de datos: Detalles sobre las tablas en las que se almacenaron los datos robados.
   • 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: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.
     • Chronicle: Es un vínculo a Google SecOps.

3. Haz clic en la pestaña Source Properties y revisa los campos que se muestran, principalmente los siguientes:

   • detectionCategory:
     • subRuleName: exfil_to_external_table o vpc_perimeter_violation.
   • evidence:
     • sourceLogId:
       • projectId: Es el proyecto de Google Cloud que contiene el conjunto de datos de BigQuery de origen.
   • properties
     • dataExfiltrationAttempt
       • jobLink: El vínculo al trabajo de BigQuery que robó datos.
       • query: 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 Google Security Operations

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

Solo puedes usar Google SecOps 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 resultados 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 de los hallazgos, haz clic en Investigar en Chronicle.

6. Sigue las instrucciones de la interfaz de usuario guiada de Google SecOps.

Usa las siguientes guías para realizar investigaciones en Google SecOps:

• Investiga un usuario
• Investiga un recurso

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 en el archivo JSON del 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 se asignaron a la cuenta.

Paso 4: Comprueba los registros

1. En la pestaña Resumen del panel de detalles del hallazgo, 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 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 Resultados relacionados en 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 adecuado 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 userEmail hasta que se complete la investigación.
• Para detener el robo de datos, agrega políticas de IAM restrictivas a los conjuntos de datos afectados de BigQuery (exfiltration.sources y exfiltration.targets).
• Para analizar conjuntos de datos afectados en busca de información sensible, usa Sensitive Data Protection. También puedes enviar datos de Sensitive Data Protection a Security Command Center. Según la cantidad de información, los costos de Sensitive Data Protection pueden ser significativos. Sigue las prácticas recomendadas para mantener los costos de la protección de datos sensibles bajo control.
• Para limitar el acceso a la API de BigQuery, usa los Controles del servicio de VPC.
• Para identificar y corregir funciones con demasiados permisos, usa el recomendador de IAM.

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 del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible 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. Se abre el panel de detalles del hallazgo en la pestaña Resumen.

2. En la pestaña Resumen del panel de detalles de la búsqueda, revisa los valores que se indican en las siguientes secciones:

   • Qué se detectó:
     • Correo electrónico principal: Es la cuenta que se usó para robar los datos.
     • Fuentes de robo de datos: Detalles sobre las tablas de las que se robaron datos.
     • Objetivos de robo de datos: Detalles sobre las tablas en las que se almacenaron los datos robados.
   • Recurso afectado:
     • Nombre completo del recurso: Es el nombre del recurso de BigQuery cuyos datos se robaron.
     • Nombre completo del proyecto: Es el proyecto de Google Cloud que contiene el conjunto de datos de BigQuery de origen.
   • Vínculos relacionados:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.

3. En el panel de detalles del resultado, haz clic en la pestaña JSON.

4. En el JSON, toma nota de los siguientes campos.

   • sourceProperties:
     • evidence:
       • sourceLogId:
       • projectId: Es el proyecto de Google Cloud que contiene el conjunto de datos de BigQuery de origen.
     • 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 en el JSON del resultado (en el 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 se asignan a la cuenta.

Paso 3: Comprueba los registros

1. En la pestaña Resumen del panel de detalles del hallazgo, 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 fila Resultados relacionados en 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 adecuado 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 de la pestaña Resumen de los detalles de los resultados hasta que se complete la investigación.
• Para detener el robo de datos, agrega políticas de IAM restrictivas a los conjuntos de datos afectados de BigQuery que se identifican en el campo Fuentes de robo de datos en la pestaña Resumen de los detalles del hallazgo.
• Para analizar conjuntos de datos afectados en busca de información sensible, usa Sensitive Data Protection. También puedes enviar datos de Sensitive Data Protection a Security Command Center. Según la cantidad de información, los costos de Sensitive Data Protection pueden ser significativos. Sigue las prácticas recomendadas para mantener los costos de la protección de datos sensibles bajo control.
• Para limitar el acceso a la API de BigQuery, usa los Controles del servicio de VPC.
• Si eres el propietario del bucket, considera revocar los permisos de acceso público.
• Para identificar y corregir funciones con demasiados permisos, usa el recomendador de IAM.

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 hallazgo de Exfiltration: BigQuery Data to Google Drive, como se indica en Revisa los hallazgos.

2. En la pestaña Resumen del panel de detalles de los resultados, revisa la información de las siguientes secciones:

   • Qué se detectó, lo que incluye lo siguiente:
     • Correo electrónico principal: Es la cuenta que se usó para robar los datos.
     • Fuentes de robo de datos: Detalles sobre la tabla de BigQuery desde la que se extrajeron los datos.
     • Objetivos de robo de datos: 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: Es el proyecto de Google Cloud que contiene el conjunto de datos de BigQuery de origen.
   • Vínculos relacionados, incluidos los siguientes:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.

3. Para obtener más información, haz clic en la pestaña JSON.

4. En el JSON, toma nota de los siguientes campos.

   • sourceProperties:
     • evidence:
       • sourceLogId:
       • projectId: Es el proyecto de Google Cloud que contiene el conjunto de datos de BigQuery de origen.
     • 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 en el JSON del resultado (en el 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 qué permisos se asignan a la cuenta.

Paso 3: Comprueba los registros

1. En la pestaña Resumen del panel de detalles del hallazgo, 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 Resultados relacionados en 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 adecuado 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 para la principal en el campo access.principalEmail hasta que se complete la investigación.
• Para detener el robo de datos, agrega políticas de IAM restrictivas a los conjuntos de datos afectados de BigQuery (exfiltration.sources).
• Para analizar conjuntos de datos afectados en busca de información sensible, usa Sensitive Data Protection. También puedes enviar datos de Sensitive Data Protection a Security Command Center. Según la cantidad de información, los costos de Sensitive Data Protection pueden ser significativos. Sigue las prácticas recomendadas para mantener los costos de la protección de datos sensibles bajo control.
• Para limitar el acceso a la API de BigQuery, usa los Controles del servicio de VPC.
• Para identificar y corregir funciones con demasiados permisos, usa el recomendador de IAM.

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 del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible 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: Cloud SQL Data Exfiltration, como se indica en Revisa los hallazgos. Se abre el panel de detalles del hallazgo 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 : Es la cuenta que se usó para robar los datos.
     • Fuentes de robo de datos: Detalles sobre la instancia de Cloud SQL cuyos datos se robaron
     • Objetivos de robo: Detalles sobre el bucket de Cloud Storage al que se exportaron los datos.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: Es el nombre del recurso de Cloud SQL cuyos datos se filtraron.
     • Nombre completo del proyecto: Es el proyecto de Google Cloud que contiene los datos de Cloud SQL de origen.
   • Vínculos relacionados, incluidos los siguientes:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.

3. Haz clic en la pestaña JSON.

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

   • sourceProperties:
     • evidence:
     • sourceLogId:
       • projectId: Es el proyecto de Google Cloud que contiene la instancia de Cloud SQL de origen.
     • properties
     • bucketAccess: Es si el bucket de Cloud Storage es de acceso público o externo a la organización.
     • exportScope: Es la cantidad de datos que se exportaron (la instancia completa, 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 en el JSON del hallazgo (en el 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 de los resultados (del Paso 1). Verifica qué permisos se asignaron a la cuenta.

Paso 3: Comprueba los registros

1. En la consola de Google Cloud, ve al Explorador de registros haciendo clic en el vínculo en URI de registro de Cloud (del Paso 1). 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. Revisa los resultados relacionados. Para ello, 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 adecuado 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.
  • MySQL
  • PostgreSQL
  • SQL Server
• 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 a 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 de los resultados, revisa la información de las siguientes secciones:

   • Qué se detectó, en especial los siguientes campos:
     • Correo electrónico principal: Es la cuenta que se usó para robar los datos.
     • Fuentes de robo: Detalles de la instancia de Cloud SQL a partir de la cual se creó la copia de seguridad
     • Objetivos 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: Es el nombre del recurso de la copia de seguridad que se restableció.
     • Nombre completo del proyecto: Es el proyecto de Google Cloud que contiene la instancia de Cloud SQL a partir de la que se creó la copia de seguridad.

3. Vínculos relacionados, en especial los siguientes campos:

   • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
   • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
   • Resultados relacionados: Vínculos a los resultados relacionados.

4. Haz clic en la pestaña JSON.

5. En el JSON, toma nota de 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 BigQuery de origen.
   • 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 en el JSON del resultado (en el 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 se asignan a la cuenta.

Paso 3: Comprueba los registros

1. En la consola de Google Cloud, ve al Explorador de registros haciendo clic en el vínculo en URI de registro de Cloud (del Paso 1). 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 los 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 adecuado 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 de la pestaña Resumen de los detalles del hallazgo 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.
  • MySQL
  • PostgreSQL
  • SQL Server
• 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 cuando 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 hallazgo de Exfiltration: Cloud SQL Over-Privileged Grant, como se indica en Revisa los hallazgos.

2. En la pestaña Resumen del panel de detalles de los resultados, revisa la información de 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 PostgreSQL de Cloud SQL que se vio afectada.
     • Nombre de usuario de la base de datos: Es el usuario de PostgreSQL que otorgó privilegios excesivos.
     • Consulta de la base de datos: Es la consulta de PostgreSQL que se ejecutó y que otorgó los privilegios.
     • Beneficiarios de la base de datos: los beneficiarios de los privilegios excesivos.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: Es el nombre del recurso de la instancia de Cloud SQL para PostgreSQL afectada.
     • Nombre completo del elemento superior: Es el nombre del recurso de la instancia de PostgreSQL de Cloud SQL.
     • Nombre completo del proyecto: Es el proyecto de Google Cloud que contiene la instancia de PostgreSQL de Cloud SQL.
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.

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. Lista y muestra los privilegios de acceso para lo siguiente:
   • Bases de datos Usa el metacomando \l o \list y verifica qué privilegios se asignaron 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 asignaron a las funciones o los procedimientos en la base de datos que se enumeran en Nombre visible de la base de datos (del Paso 1).

Paso 3: Comprueba los registros

1. En la consola de Google Cloud, ve al Explorador de registros haciendo clic en el vínculo en URI de registro de Cloud (del Paso 1). 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, con 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 de MITRE ATT&CK para este tipo de resultado: Robo de datos en el servicio web.
2. Para determinar si se necesitan pasos de solución adicionales, 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 adecuado 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 con concesiones con 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 (del Nombre visible de la base de datos del Paso 1, retira los permisos innecesarios de los beneficiarios (del Beneficiarios de la base de datos del Paso 1.

Initial Access: Database Superuser Writes to User Tables

Detecta cuando la cuenta de superusuario de la base de datos de Cloud SQL (postgres para PostgreSQL y root para MySQL) escribe en las tablas de usuario. Por lo general, no se debe usar el superusuario (un rol con acceso muy amplio) para escribir en las tablas de usuario. Se debe usar una cuenta de usuario con acceso más limitado para la actividad diaria normal. Cuando un superusuario escribe en una tabla de usuarios, eso podría indicar que un atacante tiene privilegios elevados o comprometió al usuario de la base de datos predeterminado 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 de los resultados, revisa la información de 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 MySQL o PostgreSQL de Cloud SQL que se vio afectada.
     • Nombre de usuario de la base de datos: El superusuario.
     • Consulta de base de datos: Es 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: Es el nombre del recurso de la instancia de Cloud SQL afectada.
     • Nombre completo superior: Es el nombre del recurso de la instancia de Cloud SQL.
     • Nombre completo del proyecto: Es el proyecto de Google Cloud que contiene la instancia de Cloud SQL.
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.

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. Usa los siguientes filtros para verificar los registros de pgaudit de PostgreSQL o los registros de auditoría de Cloud SQL para MySQL, que contienen las consultas que ejecuta el superusuario:
   • protoPayload.request.user="SUPERUSER"

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: Robo de datos en el servicio web.
2. Para determinar si se necesitan pasos de solución adicionales, 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 adecuado 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.

• Revisa los usuarios que tienen permitido conectarse a la base de datos.

  • Para PostgreSQL, consulta Crea y administra usuarios.
  • Para MySQL, consulta Administra usuarios con autenticación integrada.

• Considera cambiar la contraseña del superusuario.

  • Para PostgreSQL, consulta Establece una contraseña para el usuario predeterminado.
  • Para MySQL, consulta Establece una contraseña para el usuario predeterminado.

• Considera crear un usuario nuevo con acceso limitado para los diferentes tipos de consultas que se usan en la instancia.

  • Otorga al usuario nuevo solo los permisos necesarios para ejecutar sus consultas.

    • Para PostgreSQL, consulta Grant (comando).
    • Para MySQL, consulta Control de acceso y administración de cuentas.

  • Actualiza las credenciales de los clientes que se conectan a la instancia de Cloud SQL

Initial Access: Anonymous GKE resource created from the internet

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Detecta cuando un actor potencialmente malicioso usó uno de los siguientes usuarios o grupos de usuarios predeterminados de Kubernetes para crear un nuevo recurso de Kubernetes en el clúster:

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

Estos usuarios y grupos son, en realidad, anónimos. Una vinculación de control de acceso basado en roles (RBAC) en tu clúster le otorgó a ese usuario permiso para crear esos recursos en el clúster.

Revisa el recurso creado y la vinculación de RBAC asociada para asegurarte de que la vinculación sea necesaria. Si no es necesario, quítalo. Para obtener más detalles, consulta el mensaje de registro de este hallazgo.

Para mitigar este problema, consulta Evita los roles y los grupos predeterminados.

Initial Access: GKE resource modified anonymously from the internet

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Detecta cuando un actor potencialmente malicioso usó uno de los siguientes usuarios o grupos de usuarios predeterminados de Kubernetes para modificar un recurso de Kubernetes en el clúster:

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

Estos usuarios y grupos son, en realidad, anónimos. Una vinculación de control de acceso basado en roles (RBAC) en tu clúster le otorgó a ese usuario permiso para modificar esos recursos en el clúster.

Revisa el recurso modificado y la vinculación de RBAC asociada para asegurarte de que la vinculación sea necesaria. Si no es necesario, quítalo. Para obtener más detalles, consulta el mensaje de registro de este hallazgo.

Para mitigar este problema, consulta Evita los roles y los grupos predeterminados.

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 estuvo 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 hallazgo de Initial Access: Dormant Service Account Action, como se indica en Revisa los hallazgos.

2. En los detalles del hallazgo, en la pestaña Resumen, observa los valores de los siguientes campos.

   En Qué se detectó, encontrarás lo siguiente:

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

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

1. Usa herramientas de cuenta de servicio, como el Analizador de actividades, 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 adecuado 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 vulnerada, además de rotar y borrar todas las claves de acceso de la cuenta de servicio del proyecto potencialmente vulnerado. Después de la eliminación, las aplicaciones que usan la cuenta de servicio para la autenticación pierden el acceso. Antes de continuar, tu 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 estuvo 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 hallazgo de Initial Access: Dormant Service Account Key Created, como se indica en Revisa los hallazgos.

2. En los detalles del hallazgo, en la pestaña Resumen, observa los valores de los siguientes campos.

   En Qué se detectó, encontrarás lo siguiente:

   • Correo electrónico principal: Es el usuario que creó la clave de la cuenta de servicio.

   En Recurso afectado, haz lo siguiente:

   • Nombre visible del recurso: Es la clave de cuenta de servicio inactiva que se creó recientemente.
   • Nombre completo del proyecto: Es el proyecto en el que reside esa cuenta de servicio inactiva.

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

1. Usa herramientas de cuenta de servicio, como el Analizador de actividades, 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 adecuado 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 cuenta de servicio recién creada en la página Cuentas de servicio.
• Considera borrar la cuenta de servicio potencialmente vulnerada, además de rotar y borrar todas las claves de acceso de la cuenta de servicio del proyecto potencialmente vulnerado. Después de la eliminación, las aplicaciones que usan la cuenta de servicio para la autenticación pierden el acceso. Antes de continuar, tu 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 roles con demasiados permisos, 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 una que se publicó en Internet público. Por ejemplo, las claves de cuentas de servicio a menudo se publican por error en el repositorio público de GitHub.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Initial Access: Leaked Service Account Key Used, como se indica en Revisa los hallazgos.

2. En los detalles del hallazgo, en la pestaña Resumen, observa los valores de los siguientes campos.

   En Qué se detectó, encontrarás lo siguiente:

   • Correo electrónico principal: Es la cuenta de servicio que se usó en esta acción.
   • Nombre del servicio: Es el nombre de la API del servicio de Google Cloud al que accedió la cuenta de servicio.
   • Nombre del método: Es el nombre del método de la acción.
   • Nombre de la clave de la cuenta de servicio: Es la clave de la cuenta de servicio filtrada que se usó 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: Es 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 de la búsqueda. 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 hallazgo.

Paso 3: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado 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.
• Quita la página web o el repositorio de GitHub en el que se publicó la clave de la cuenta de servicio.
• Considera borrar la cuenta de servicio vulnerada.
• Rota y borra todas las claves de acceso de la cuenta de servicio del proyecto potencialmente vulnerado. Después de la eliminación, las aplicaciones que usan la cuenta de servicio para la autenticación pierden el acceso. Antes de borrarlas, tu 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.

Initial Access: Excessive Permission Denied Actions

Detecta eventos en los que un principal activa repetidamente 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 hallazgo de Initial Access: Excessive Permission Denied Actions, como se indica en Revisa los hallazgos.

2. En los detalles de los resultados, en la pestaña Resumen, observa los valores de los siguientes campos.

   En Qué se detectó, encontrarás lo siguiente:

   • Correo electrónico del principal: Es el principal que activó varios errores de permiso denegado.
   • Nombre del servicio: Es 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: Es el método al que se llamó cuando ocurrió el último error de permiso denegado.

3. En los detalles de los resultados, en la pestaña Source Properties, observa los valores de los siguientes campos en el JSON:

   • properties.failedActions: Los errores de permiso denegado que se produjeron. Para cada entrada, los detalles 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 de la búsqueda.

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 adecuado 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.
• Borra los recursos del proyecto que creó esa cuenta, como instancias desconocidas de Compute Engine, instantáneas, cuentas de servicio y usuarios de IAM, etcétera.
• Comunícate con el propietario del proyecto en el que se encuentra la cuenta y, posiblemente, bórrala o inhabilitala.

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 de los resultados, revisa la información de las siguientes secciones:

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

     • IP del emisor: Es la dirección IP que inició el ataque.
     • Nombre de usuario: Es la cuenta que accedió.

   • Recurso afectado

   • Vínculos relacionados, en especial los siguientes campos:

     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.
     • Chronicle: Es un vínculo a Google SecOps.

3. Haz clic en la pestaña JSON.

4. En el JSON, toma nota de 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 Google Security Operations

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

Solo puedes usar Google SecOps 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 hallazgo.

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

6. Sigue las instrucciones de la interfaz de usuario guiada de Google SecOps.

Usa las siguientes guías para realizar investigaciones en Google SecOps:

• Investiga un usuario
• Investiga una dirección IP
• Investiga un recurso

Paso 3: Revisa los permisos y la configuración

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

   Ir al panel

2. Selecciona el proyecto que se especifica 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 del flujo de VPC relacionados con la dirección IP que aparece en la fila Correo electrónico principal de la pestaña Resumen de los detalles de los resultados 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 los resultados relacionados, haz clic en el vínculo Resultados relacionados en 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 adecuado 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 las claves SSH, consulta Cómo restringir las claves SSH de las VMs. 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 las activaciones a nivel del 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. Se abre el panel de detalles del hallazgo 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: Es la cuenta que realizó los cambios.
   • Recurso afectado
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.

3. En el panel de detalles, haz clic en la pestaña JSON.

4. En el JSON, toma nota de 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 hallazgo, 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, 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: Failed Attempt to Approve Kubernetes Certificate Signing Request (CSR)

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Alguien intentó aprobar de forma manual una solicitud de firma de certificado (CSR), pero la acción falló. Crear un certificado para la autenticación del clúster es un método común que usan los atacantes para crear acceso persistente a un clúster comprometido. Los permisos asociados con el certificado varían según el sujeto que incluyan, pero pueden ser de alto privilegio. Para obtener más detalles, consulta el mensaje de registro de esta alerta.

1. Revisa los registros de auditoría en Cloud Logging y las alertas adicionales para otros eventos relacionados con la CSR con el propósito de determinar si se approved y emitió alguna CSR, y si las acciones relacionadas con esta son una actividad esperada por parte de la principal.
2. Determina si hay otros indicios de actividad maliciosa por parte de la principal en los registros de auditoría de Cloud Logging. Por ejemplo:
   • ¿La principal que intentó aprobar la CSR era diferente de la que la creó?
   • ¿La principal intentó solicitar, crear, aprobar o borrar otras CSR?
3. Si no se esperaba una aprobación de CSR o se determina que es maliciosa, el clúster requerirá una rotación de credenciales para invalidar el certificado. Revisa la información para realizar una rotación de las credenciales del clúster.

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

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Alguien aprobó de forma manual una solicitud de firma de certificado (CSR). Crear un certificado para la autenticación del clúster es un método común que usan los atacantes para crear acceso persistente a un clúster comprometido. Los permisos asociados con el certificado varían según el sujeto que incluyan, pero pueden ser de alto privilegio. Para obtener más detalles, consulta el mensaje de registro de esta alerta.

1. Revisa los registros de auditoría en Cloud Logging y las alertas adicionales de otros eventos relacionados con la CSR con el propósito de determinar si las acciones relacionadas con esta son una actividad esperada por parte de la principal.
2. Determina si hay otros indicios de actividad maliciosa por parte de la principal en los registros de auditoría de Cloud Logging. Por ejemplo:
   • ¿La principal que aprobó la CSR era diferente de la que la creó?
   • ¿La CSR especificó un firmante integrado, pero finalmente se debe aprobar de forma manual porque no cumple con los criterios del firmante?
   • ¿La principal intentó solicitar, crear, aprobar o borrar otras CSR?
3. Si no se esperaba una aprobación de CSR o se determina que es maliciosa, el clúster requerirá una rotación de credenciales para invalidar el certificado. Revisa la información para realizar una rotación de las credenciales del clúster.

Credential Access: Privileged Group Opened To Public

Este hallazgo no está disponible para las activaciones a nivel del 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. Se abre el panel de detalles del hallazgo 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: Es la cuenta que realizó los cambios, que podría estar comprometida.
   • Recurso afectado
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.
   1. Haz clic en la pestaña JSON.
   2. En el JSON, toma nota de 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 hallazgo, 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, 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: Secrets Accessed in Kubernetes Namespace

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Detecta cuándo se usó la cuenta de servicio de Kubernetes default de un Pod para acceder a objetos Secret en el clúster. La cuenta de servicio de Kubernetes default no debería tener acceso a los objetos Secret, a menos que hayas otorgado ese acceso de forma explícita con un objeto Role o ClusterRole.

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. Se abre el panel de detalles del hallazgo 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: Es la cuenta que realizó los cambios, que podría estar 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, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.
   1. Haz clic en la pestaña JSON.
   2. En el JSON, toma nota de 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, revócalo.

   Necesitas permisos específicos para administrar roles en 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 hallazgo, 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, 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. Se abre el panel de detalles del hallazgo 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:
     • IP de origen: Es la dirección IP sospechosa de criptominería.
     • 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 de IANA asociado con la conexión.
   • Recurso afectado
   • Vínculos relacionados, incluidos los siguientes campos:
     • URI de Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.
     • Flow Analyzer (versión preliminar): Es un vínculo a la función Flow Analyzer de Network Intelligence Center. Este campo solo se muestra cuando los registros de flujo de VPC están habilitados.

3. En la vista de detalles del hallazgo, haz clic en la pestaña Propiedades de origen.

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. Selecciona el proyecto que se especifica 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 adecuado 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 búsquedas 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 hallazgo de Initial Access: Log4j Compromise Attempt como se indica en Revisa detalles de hallazgos. Se abre el panel de detalles del hallazgo 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, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.
   • En la vista de detalles del resultado, haz clic en la pestaña JSON.

   • En el JSON, toma nota de 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, ve al Explorador de registros haciendo clic en el vínculo en el campo URI de registro de Cloud del paso 1.

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 Resultados relacionados en 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 adecuado 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.

• Actualiza a la última versión de Log4j2.
• Sigue las recomendaciones de Google Cloud para investigar y responder a la vulnerabilidad “Log4j 2 de Apache”.
• Implementa las técnicas de mitigación recomendadas en las Vulnerabilidades de seguridad Log4j de Apache.
• Si usas Google Cloud Armor, implementa cve-canary rule en una política de seguridad de Google Cloud Armor nueva o existente. Para obtener más información, consulta la regla de WAF de Google Cloud Armor para ayudar a mitigar la vulnerabilidad de Apache Log4j.

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. Se abre el panel de detalles del hallazgo 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:
     • Nombre completo del recurso: Es el nombre completo del recurso de la instancia de Compute Engine que es vulnerable a la RCE de Log4j.
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.

3. En la vista de detalles del resultado, haz clic en la pestaña JSON.

4. En el JSON, toma nota de 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, ve al Explorador de registros haciendo clic en el vínculo en el campo URI de registro de Cloud del paso 1.

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 Resultados relacionados en 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 adecuado 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.

• Actualiza a la última versión de Log4j2.
• Sigue las recomendaciones de Google Cloud para investigar y responder a la vulnerabilidad “Log4j 2 de Apache”.
• Implementa las técnicas de mitigación recomendadas en las Vulnerabilidades de seguridad Log4j de Apache.
• Si usas Google Cloud Armor, implementa cve-canary rule en una política de seguridad de Google Cloud Armor nueva o existente. Para obtener más información, consulta la regla de WAF de Google Cloud Armor para ayudar a mitigar la vulnerabilidad de Apache Log4j.

Leaked credentials

Este hallazgo no está disponible para las activaciones a nivel del 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. Se abre el panel de detalles del hallazgo 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 Source Properties 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 adecuado 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. Actualmente, Event Threat Detection proporciona detección general de software malicioso (Malware: Bad IP y Malware: Bad Domain) y detectores particularmente para el 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 hallazgos 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 hallazgo Malware: Bad IP, como se indica en Revisa los hallazgos. Se abre el panel de detalles del hallazgo 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:
     • Dominio del indicador: En el caso de los resultados Bad domain, es el dominio que activó el resultado.
     • IP del indicador: En el caso de los resultados de Bad IP, es la dirección IP que activó el resultado.
     • IP de origen: En el caso de los resultados de Bad IP, es una dirección IP de comando y control de software malicioso conocida.
     • Puerto de origen: En el caso de los resultados de Bad IP, es el puerto de origen de la conexión.
     • IP de destino: En el caso de los resultados de Bad IP, es la dirección IP de destino del software malicioso.
     • Puerto de destino: En el caso de los resultados de Bad IP, es el puerto de destino de la conexión.
     • Protocolo: Para los resultados de Bad IP, el número de protocolo de IANA asociado con la conexión.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: Es 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 hallazgo.
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.
     • Chronicle: Es un vínculo a Google SecOps.
     • Indicador de VirusTotal: Es un vínculo a la página de análisis de VirusTotal.
     • Flow Analyzer (versión preliminar): Es un vínculo a la función Flow Analyzer de Network Intelligence Center. Este campo solo se muestra cuando los registros de flujo de VPC están habilitados.

   1. Haz clic en la pestaña JSON y observa el siguiente campo:

      • evidence:
      • sourceLogId:
        • projectID: Es 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 Google Security Operations

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

Solo puedes usar Google SecOps 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 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 hallazgo Malware: Bad IP. Se abrirá el panel de detalles del hallazgo.

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

6. Sigue las instrucciones de la interfaz de usuario guiada de Google SecOps.

Usa las siguientes guías para realizar investigaciones en Google SecOps:

• Investiga una dirección IP
• Investiga un recurso

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. Selecciona el proyecto que se especifica 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 hallazgo, 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 del flujo de VPC relacionados con la dirección IP en 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 el proyecto que aparece en projectId.
     • SOURCE_IP con la dirección IP que aparece en la fila IP de origen en la pestaña Resumen de los detalles del hallazgo.

Paso 5: Verifica Flow Analyzer

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Debes habilitar los registros de flujo de VPC para realizar el siguiente proceso.

1. Asegúrate de haber actualizado tu bucket de registros para usar el Análisis de registros. Para obtener instrucciones, consulta Cómo actualizar un bucket para usar Log Analytics. No se cobra ningún costo adicional para actualizar.

2. En la consola de Google Cloud, ve a la página Flow Analyzer:

   Ve a Flow Analyzer

   También puedes acceder a Flow Analyzer a través del vínculo URL de Flow Analyzer en la sección Vínculos relacionados de la pestaña Resumen del panel Detalles de la búsqueda.

3. Para investigar más la información relacionada con el resultado de Event Threat Detection, usa el selector de intervalo de tiempo en la barra de acciones para cambiar el período. El período debe reflejar el momento en que se informó el hallazgo por primera vez. Por ejemplo, si el hallazgo se informó en las últimas 2 horas, puedes establecer el período en Últimas 6 horas. Esto garantiza que el período en el Analizador de flujo incluya el momento en que se informó el hallazgo.

4. Filtra el analizador de flujo para mostrar los resultados adecuados de la dirección IP asociada con el hallazgo de IP maliciosa:

   1. En el menú Filtro de la fila Fuente de la sección Consulta, selecciona IP.

   2. En el campo Valor, ingresa la dirección IP asociada con el hallazgo y haz clic en Run New Query.

      Si el analizador de flujo no muestra ningún resultado para la dirección IP, borra el filtro de la fila Fuente y vuelve a ejecutar la consulta con el mismo filtro en la fila Destino.

5. Analiza los resultados. Para obtener información adicional sobre un flujo específico, haz clic en Detalles en la tabla Todos los flujos de datos para abrir el panel Detalles del flujo.

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: Resolución dinámica y comando y control.
2. Para revisar los resultados relacionados, haz clic en el vínculo Resultados relacionados en 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 verificar las URLs y los dominios marcados en VirusTotal, haz clic en el vínculo 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.
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 adecuado 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.

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 asignaciones anómalos:

• Invitar a un usuario externo, como 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
• Se agregó una cuenta de servicio desde fuera de tu organización o proyecto

El hallazgo IAM Anomalous Grant es único, ya que incluye subreglas que proporcionan información más específica sobre cada instancia de este hallazgo. 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 sus severidades:

• external_service_account_added_to_policy:
  • HIGH, si se otorgó un rol de alta sensibilidad o un rol de sensibilidad media a nivel de la organización. Para obtener más información, consulta Roles de alta sensibilidad.
  • MEDIUM, si se otorgó un rol de sensibilidad media Para obtener más información, consulta Roles de sensibilidad media.
• external_member_invited_to_policy: HIGH
• external_member_added_to_policy:
  • HIGH, si se otorgó un rol de alta sensibilidad o un rol de sensibilidad media a nivel de la organización. Para obtener más información, consulta Roles de alta sensibilidad.
  • MEDIUM, si se otorgó un rol de sensibilidad media Para obtener más información, consulta Roles 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. Se abre el panel de detalles del hallazgo 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: Es la dirección de correo electrónico del usuario o la cuenta de servicio que asignó el rol.

   • Recurso afectado

   • Vínculos relacionados, en especial los siguientes campos:

     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.
     • Indicador de VirusTotal: Es un vínculo a la página de análisis de VirusTotal.
     • Chronicle: Es un vínculo a Google SecOps.

3. Haz clic en la pestaña JSON. Se mostrará el JSON completo del hallazgo.

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

   • detectionCategory:
     • subRuleName: Información más específica sobre el tipo de subvención anómala que se produjo. La subregla determina la clasificación de gravedad de este hallazgo.
   • evidence:
     • sourceLogId:
     • projectId: El ID del proyecto que contiene el hallazgo.
   • properties:
     • sensitiveRoleGrant:
       • bindingDeltas:
       • Action: Es la acción que realiza 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 Google Security Operations

Puedes usar Google Security Operations para investigar este resultado. Google SecOps es un servicio de Google Cloud que te permite investigar amenazas y alternar por entidades relacionadas en un cronograma fácil de usar. Google SecOps 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 del 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 de la búsqueda.

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

6. Sigue las instrucciones de la interfaz de usuario guiada de Google SecOps.

Usa las siguientes guías para realizar investigaciones en Google SecOps:

• Investiga un usuario
• Investiga un recurso

Paso 3: Comprueba los registros

1. En la pestaña Resumen del panel de detalles del hallazgo, 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 de MITRE ATT&CK para este tipo de resultado: Cuentas válidas: Cuentas de Cloud.
2. Para revisar los resultados relacionados, haz clic en el vínculo de la fila Resultados relacionados en 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 adecuado 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 un rol de suplantación 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 estuvo 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 hallazgo de Persistence: Impersonation Role Granted for Dormant Service Account, como se indica en Revisa los hallazgos.

2. En los detalles del hallazgo, en la pestaña Resumen, observa los valores de los siguientes campos.

   En Qué se detectó, encontrarás lo siguiente:

   • Correo electrónico principal: Es el usuario que realizó la acción de otorgamiento.
   • Offensive access grants.Principal name: El principal al que se le otorgó el rol de suplantación

   En Recurso afectado, haz lo siguiente:

   • Nombre visible del recurso: La cuenta de servicio inactiva como recurso
   • Nombre completo del proyecto: Es el proyecto en el que reside esa cuenta de servicio inactiva.

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

1. Usa herramientas de cuenta de servicio, como el Analizador de actividades, 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 hallazgo, 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 adecuado 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 suplantación otorgado recientemente del miembro de destino.
• Considera borrar la cuenta de servicio potencialmente vulnerada, además de rotar y borrar todas las claves de acceso de la cuenta de servicio del proyecto potencialmente vulnerado. Después de la eliminación, las aplicaciones que usan la cuenta de servicio para la autenticación pierden el acceso. Antes de continuar, tu 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 roles con demasiados permisos, usa el recomendador de IAM.

Persistence: Unmanaged Account Granted Sensitive Role

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Detecta eventos en los que se otorga un rol sensible a una cuenta no administrada. Los administradores del sistema no pueden controlar las cuentas no administradas. Por ejemplo, cuando el empleado correspondiente dejó la empresa, el administrador no puede borrar la cuenta. Por lo tanto, otorgar roles 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 hallazgo de Persistence: Unmanaged Account Granted Sensitive Role, como se indica en Revisa los hallazgos.

2. En los detalles del hallazgo, en la pestaña Resumen, observa los valores de los siguientes campos.

   En Qué se detectó, encontrarás lo siguiente:

   • Correo electrónico principal: Es el usuario que realizó la acción de otorgamiento.
   • Offensive access grants.Principal name: Es la cuenta no administrada que recibe la concesión.
   • Otorgamiento de acceso infractor.Rol otorgado: 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. Consulta con el propietario del campo Offending access grants.Principal name para comprender el origen de la cuenta no administrada.

Paso 3: Comprueba los registros

1. En la pestaña Resumen del panel de detalles del hallazgo, 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 adecuado 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 otorgado recientemente de la cuenta no administrada.
• Considera convertir la cuenta no administrada en una cuenta administrada con la herramienta de transferencia y transfiérela al control de los administradores del sistema.

Persistence: New API Method

Se detectó actividad administrativa anómala de una persona potencialmente maliciosa en una organización, carpeta o proyecto. La actividad anómala puede ser una de las siguientes:

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

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Persistence: New API Method como se indica en Revisa los resultados.

2. En los detalles de los resultados, en la pestaña Resumen, observa los valores de los siguientes campos:

   • En Qué se detectó, haz lo siguiente:
     • Correo electrónico principal: Es la cuenta que realizó la llamada.
     • Nombre del servicio: Es el nombre de la API del servicio de Google Cloud que se usa en la acción.
     • Nombre del método: Es el método al que se llamó.
   • En Recurso afectado, haz lo siguiente:
     • Nombre visible del recurso: Es el nombre del recurso afectado, que puede ser el mismo que el 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 en la que se realizó la actividad.

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

1. Revisa las entradas del framework de MITRE ATT&CK para este tipo de resultado: Persistencia.
2. Investiga si la acción estaba justificada en la organización, la carpeta o el proyecto, y si el propietario legítimo de la cuenta la realizó. La organización, la carpeta o el proyecto se muestran en la fila Ruta de acceso de recursos, y la cuenta se muestra en la fila Correo electrónico principal.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Persistence: New Geography

Este hallazgo no está disponible para las activaciones a nivel del 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 hallazgo de Persistence: New Geography, como se indica en Revisa los detalles de hallazgos antes en esta página. Se abre el panel de detalles del hallazgo 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: Es el proyecto que contiene la cuenta de usuario que puede estar comprometida.
• Vínculos relacionados, en especial los siguientes campos:
  • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
  • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
  • Resultados relacionados: Vínculos a los resultados relacionados.

1. En la vista de detalles del resultado, haz clic en la pestaña JSON.

2. En el archivo JSON, toma nota de los siguientes campos sourceProperties:

   • affectedResources:
     • gcpResourceName: el recurso afectado
   • evidence:
     • sourceLogId:
     • projectId: El ID del proyecto que contiene el hallazgo.
   • properties:
     • anomalousLocation:
     • anomalousLocation: 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 para el comportamiento normal.
     • typicalGeolocations: 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 en el archivo JSON del 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 verifica los roles otorgados.

Paso 3: Comprueba los registros

1. En la pestaña Resumen del panel de detalles del hallazgo, 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 de framework de MITRE ATT&CK para 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 adecuado 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 las activaciones a nivel del 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 hallazgo de Persistence: New User Agent, como se indica en Revisa los detalles de hallazgos antes en esta página. Se abre el panel de detalles del hallazgo 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: Es el proyecto que contiene la cuenta de servicio que puede estar comprometida.
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.
   1. En la vista de detalles del resultado, haz clic en la pestaña JSON.
   2. En el JSON, toma nota de los siguientes campos.
   • projectId: El proyecto que contiene la cuenta de servicio que puede estar comprometida.
   • callerUserAgent: El usuario-agente anómalo.
   • anomalousSoftwareClassification: Es el tipo de software.
   • notSeenInLast: Es el período que se usa para establecer un modelo de referencia para el 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 hallazgo 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 de la pestaña Resumen de los detalles del hallazgo.

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

Paso 3: Comprueba los registros

1. En la pestaña Resumen del panel de detalles del hallazgo, 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 adecuado 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 derivar privilegios, un agente potencialmente malicioso intentó modificar un objeto de control de acceso basado en roles (RBAC) ClusterRole, RoleBinding o ClusterRoleBinding del rol sensible cluster-admin a través de una solicitud PUT o PATCH.

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Privilege Escalation: Changes to sensitive Kubernetes RBAC objects como se indica en Revisa los resultados. Se abre el panel de detalles del hallazgo 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: Es la cuenta que realizó la llamada.
     • Nombre del método: Es el método al que se llamó.
     • Vinculaciones de Kubernetes: La vinculación sensible de Kubernetes o el ClusterRoleBinding que se modificó.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre visible del recurso: Es el clúster de Kubernetes en el que se produjo la acción.
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.

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, anota los detalles de la vinculación.

Paso 2: Comprueba los registros

1. En la pestaña Resumen de los detalles del hallazgo 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 de Nombre del método era un método PATCH, verifica el cuerpo de la solicitud para ver qué propiedades se modificaron.

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

3. Para verificar si el principal realizó otras acciones, usa los siguientes filtros:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Reemplaza lo siguiente:

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

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

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

1. Revisa las entradas del framework de MITRE ATT&CK para este tipo de resultado: Elevación de privilegios
2. Confirma la sensibilidad del objeto y si la modificación está justificada.
3. En las vinculaciones, puedes comprobar el sujeto y determinar si necesita el rol al que está vinculado.
4. Determina si hay otros indicios de actividad maliciosa por parte del 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 el origen 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 del MITRE.

Privilege Escalation: Create Kubernetes CSR for master cert

Para derivar privilegios, un actor potencialmente malicioso creó una solicitud de firma de certificado (CSR) de instancia principal de Kubernetes, que le da acceso cluster-admin.

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Privilege Escalation: Create Kubernetes CSR for master cert como se indica en Revisa los resultados. Se abre el panel de detalles del hallazgo 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: Es la cuenta que realizó la llamada.
     • Nombre del método: Es el método al que se llamó.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre visible del recurso: Es el clúster de Kubernetes en el que se produjo la acción.
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.

Paso 2: Comprueba los registros

1. En la pestaña Resumen de los detalles del hallazgo 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 el valor en el campo protoPayload.resourceName para identificar la solicitud de firma de certificado específica.

3. Para verificar si el principal realizó otras acciones, usa los siguientes filtros:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Reemplaza lo siguiente:

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

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

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

1. Revisa las entradas del framework de MITRE ATT&CK para este tipo de resultado: Elevación de privilegios.
2. Investiga si se justificaba otorgar 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 el origen 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 del MITRE.

Privilege Escalation: Creation of sensitive Kubernetes bindings

Para derivar privilegios, una persona potencialmente maliciosa intentó crear un objeto RoleBinding o ClusterRoleBinding nuevo para el rol cluster-admin.

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Privilege Escalation: Creation of sensitive Kubernetes bindings como se indica en Revisa los resultados. Se abre el panel de detalles del hallazgo 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: Es 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: Es el clúster de Kubernetes en el que se produjo la acción.
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.

Paso 2: Comprueba los registros

1. En la pestaña Resumen de los detalles del hallazgo 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. Para verificar si el principal realizó otras acciones, usa los siguientes filtros:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Reemplaza lo siguiente:

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

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

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

1. Revisa las entradas del framework de MITRE ATT&CK para este tipo de resultado: Elevación de privilegios.
2. Confirma la sensibilidad de la vinculación creada y si los roles son necesarios para los sujetos.
3. En las vinculaciones, puedes comprobar el sujeto y determinar si necesita el rol al que está vinculado.
4. Determina si hay otros indicios de actividad maliciosa por parte del 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 el origen 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 del MITRE.

Privilege Escalation: Effectively Anonymous Users Granted GKE Cluster Access

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Alguien creó una vinculación de RBAC que hace referencia a uno de los siguientes usuarios o grupos:

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

Estos usuarios y grupos son, en realidad, anónimos y se deben evitar cuando se crean vinculaciones de roles o vinculaciones de roles de clúster a cualquier rol de RBAC. Revisa la vinculación para asegurarte de que sea necesaria. Si no es necesario, quítala. Para obtener más detalles, consulta el mensaje de registro de este hallazgo.

1. Revisa cualquier vinculación creada que otorgue permisos al usuario system:anonymous, al grupo system:unauthenticated group o al grupo system:authenticated.
2. Determina si hay otros indicios de actividad maliciosa por parte de la principal en los registros de auditoría de Cloud Logging.

Si hay indicios de actividad maliciosa, revisa la información para investigar y quitar las vinculaciones que permitieron este acceso.

Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials

Para derivar privilegios, un agente potencialmente malicioso realizó una consulta para una solicitud de firma de certificado (CSR), con el comando kubectl, usando 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 hallazgo de Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials como se indica en Revisa los resultados. Se abre el panel de detalles del hallazgo 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: Es la cuenta que realizó la llamada.
     • Nombre del método: Es el método al que se llamó.
   • En Recurso afectado, haz lo siguiente:
     • Nombre visible del recurso: Es el clúster de Kubernetes en el que se produjo la acción.
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.

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 hallazgo 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 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 de MITRE ATT&CK para este tipo de resultado: Elevación de privilegios.
2. Si la CSR específica está disponible en la entrada de registro, investiga la sensibilidad del certificado y si la acción estaba justificada.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Privilege Escalation: Launch of privileged Kubernetes container

Un agente potencialmente malicioso creó un Pod que tiene contenedores con privilegios o contenedores 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. Para obtener más información, consulta la referencia de la API principal de SecurityContext v1 en la documentación de Kubernetes.

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Privilege Escalation: Launch of privileged Kubernetes container como se indica en Revisa los resultados. Se abre el panel de detalles del hallazgo 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: Es 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: Es el clúster de Kubernetes en el que se produjo la acción.
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.

3. En la pestaña JSON, anota los valores de los campos de resultados:

   • findings.kubernetes.pods[].containers: El contenedor con privilegios apareció dentro del Pod.

Paso 2: Comprueba los registros

1. En la pestaña Resumen de los detalles del hallazgo 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. Para verificar si el principal realizó otras acciones, usa los siguientes filtros:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Reemplaza lo siguiente:

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

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

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

1. Revisa las entradas del framework de MITRE ATT&CK para este tipo de resultado: Elevación de privilegios.
2. Confirma que el contenedor que se creó requiere acceso a los recursos del host y a las capacidades del kernel.
3. Determina si hay otros indicios de actividad maliciosa por parte del 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 el origen 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 del MITRE.

Privilege Escalation: Dormant Service Account Granted Sensitive Role

Detecta eventos en los que se otorga un rol de IAM sensible a una cuenta de servicio administrada por el usuario inactiva. En este contexto, una cuenta de servicio se considera inactiva si estuvo 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 hallazgo de Privilege Escalation: Dormant Service Account Granted Sensitive Role, como se indica en Revisa los hallazgos.

2. En los detalles del hallazgo, en la pestaña Resumen, observa los valores de los siguientes campos.

   En Qué se detectó, encontrarás lo siguiente:

   • Correo electrónico principal: Es el usuario que realizó la acción de otorgamiento.
   • Offensive access grants.Principal name: La cuenta de servicio inactiva que recibió el rol sensible
   • Offensive access grants.Role granted: El rol de IAM sensible que se asigna

   En Recurso afectado, haz lo siguiente:

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

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

1. Usa herramientas de cuenta de servicio, como el Analizador de actividades, 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 hallazgo, 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 adecuado 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 asignado recientemente de la cuenta de servicio inactiva.
• Considera borrar la cuenta de servicio potencialmente vulnerada, además de rotar y borrar todas las claves de acceso de la cuenta de servicio del proyecto potencialmente vulnerado. Después de la eliminación, los recursos que usan la cuenta de servicio para la autenticación pierden 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 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 con demasiados permisos, usa el recomendador de IAM.

Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity

Para detectar el uso de identidad anómalo de la cuenta de servicio, se examinan los registros de auditoría de la actividad del administrador para ver si se produjo alguna anomalía en una solicitud de robo de identidad de cuenta de servicio.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity, como se indica en Revisa los hallazgos. Se abre el panel de detalles del hallazgo 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: Es la cuenta de servicio final en la solicitud de suplantación que se usó para acceder a Google Cloud.
     • Nombre del servicio: Es el nombre de la API del servicio de Google Cloud involucrado en la solicitud de robo de identidad.
     • Nombre del método: Es el método al que se llamó.
     • Información de delegación de la cuenta de servicio: Detalles de las cuentas de servicio en la cadena de delegación. El principal que se encuentra en la parte inferior de la lista es el emisor de la solicitud de robo de identidad.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: Es el nombre del clúster.
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.

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 se vio comprometida alguna cuenta.
3. Comunícate con el propietario del llamador de robo 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 adecuado 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 vulnerada, además de rotar y borrar todas las claves de acceso de la cuenta de servicio del proyecto potencialmente vulnerado. Después de la eliminación, los recursos que usan la cuenta de servicio para la autenticación pierden 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 roles con demasiados permisos, usa el recomendador de IAM.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity

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

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity, como se indica en Revisa los hallazgos. Se abre el panel de detalles del hallazgo 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: Es la cuenta de servicio final en la solicitud de suplantación que se usó para acceder a Google Cloud.
     • Nombre del servicio: Es el nombre de la API del servicio de Google Cloud involucrado en la solicitud de robo de identidad.
     • Nombre del método: Es el método al que se llamó.
     • Información de delegación de la cuenta de servicio: Detalles de las cuentas de servicio en la cadena de delegación. El principal que se encuentra en la parte inferior de la lista es el emisor de la solicitud de robo de identidad.
   • Recurso afectado
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.

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 se vio comprometida alguna cuenta.
3. Comunícate con el propietario del llamador de robo 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 adecuado 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 vulnerada, además de rotar y borrar todas las claves de acceso de la cuenta de servicio del proyecto potencialmente vulnerado. Después de la eliminación, los recursos que usan la cuenta de servicio para la autenticación pierden 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 roles con demasiados permisos, usa el recomendador de IAM.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access

Para detectar Anomalous Multistep Service Account Delegation, 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 una cuenta de servicio.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access, como se indica en Revisa los hallazgos. Se abre el panel de detalles del hallazgo 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: Es la cuenta de servicio final en la solicitud de suplantación que se usó para acceder a Google Cloud.
     • Nombre del servicio: Es el nombre de la API del servicio de Google Cloud involucrado en la solicitud de robo de identidad.
     • Nombre del método: Es el método al que se llamó.
     • Información de delegación de la cuenta de servicio: Detalles de las cuentas de servicio en la cadena de delegación. El principal que se encuentra en la parte inferior de la lista es el emisor de la solicitud de robo de identidad.
   • Recurso afectado
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.

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 se vio comprometida alguna cuenta.
3. Comunícate con el propietario del llamador de robo 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 adecuado 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 vulnerada, además de rotar y borrar todas las claves de acceso de la cuenta de servicio del proyecto potencialmente vulnerado. Después de la eliminación, los recursos que usan la cuenta de servicio para la autenticación pierden 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 roles con demasiados permisos, usa el recomendador de IAM.

Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity

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

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity, como se indica en Revisa los hallazgos. Se abre el panel de detalles del hallazgo 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: Es la cuenta de servicio final en la solicitud de suplantación que se usó para acceder a Google Cloud.
     • Nombre del servicio: Es el nombre de la API del servicio de Google Cloud involucrado en la solicitud de robo de identidad.
     • Nombre del método: Es el método al que se llamó.
     • Información de delegación de la cuenta de servicio: Detalles de las cuentas de servicio en la cadena de delegación. El principal que se encuentra en la parte inferior de la lista es el emisor de la solicitud de robo de identidad.

   • Recurso afectado

   • Vínculos relacionados, en especial los siguientes campos:

     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.

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 se vio comprometida alguna cuenta.
3. Comunícate con el propietario del llamador de robo 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 adecuado 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 vulnerada, además de rotar y borrar todas las claves de acceso de la cuenta de servicio del proyecto potencialmente vulnerado. Después de la eliminación, los recursos que usan la cuenta de servicio para la autenticación pierden 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 roles con demasiados permisos, usa el recomendador de IAM.

Privilege Escalation: Anomalous Service Account Impersonator for Data Access

Para detectar un uso de identidad anómalo de la cuenta de servicio, se examinan los registros de auditoría de acceso a datos para ver si se produjo alguna anomalía en una solicitud de uso de identidad de cuenta de servicio.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Privilege Escalation: Anomalous Service Account Impersonator for Data Access, como se indica en Revisa los hallazgos.

2. En los detalles de los resultados, en la pestaña Resumen, observa los valores de los siguientes campos.

   En Qué se detectó, encontrarás lo siguiente:

   • Correo electrónico principal: Es la cuenta de servicio final en la solicitud de suplantación que se usó para acceder a Google Cloud.
   • Nombre del servicio: Es el nombre de la API del servicio de Google Cloud involucrado en la solicitud de robo de identidad.
   • Nombre del método: Es el método al que se llamó.
   • Información de delegación de la cuenta de servicio: Detalles de las cuentas de servicio en la cadena de delegación. El principal que se encuentra en la parte inferior de la lista es el emisor de la solicitud de robo 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 se vio comprometida alguna cuenta.
3. Comunícate con el propietario del llamador de robo 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 adecuado 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 vulnerada, además de rotar y borrar todas las claves de acceso de la cuenta de servicio del proyecto potencialmente vulnerado. Después de la eliminación, los recursos que usan la cuenta de servicio para la autenticación pierden 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 roles con demasiados permisos, usa el recomendador de IAM.

Privilege Escalation: ClusterRole with Privileged Verbs

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Alguien creó un objeto ClusterRole de RBAC que contiene los verbos bind, escalate o impersonate. Un sujeto vinculado a un rol con estos verbos puede robar la identidad de otros usuarios con privilegios más altos, vincularse a objetos Role o ClusterRole adicionales que contengan permisos adicionales, o bien modificar sus propios permisos ClusterRole. Esto podría provocar que esos sujetos obtengan privilegios cluster-admin. Para obtener más detalles, consulta el mensaje de registro de esta alerta.

1. Revisa el ClusterRole y el ClusterRoleBindings asociado para verificar si los sujetos realmente requieren estos permisos.
2. Si es posible, evita crear roles que involucren los verbos bind, escalate o impersonate.
3. Determina si hay otros indicios de actividad maliciosa por parte de la principal en los registros de auditoría de Cloud Logging.
4. Cuando asignes permisos en un rol de RBAC, usa el principio de privilegio mínimo y otorga los permisos mínimos necesarios para realizar una tarea. Con el uso del principio de privilegio mínimo, se reduce el potencial de elevación de privilegios si tu clúster se ve comprometido y reduce la probabilidad de que un acceso desmedido provoque un incidente de seguridad.

Privilege Escalation: ClusterRoleBinding to Privileged Role

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Alguien creó un ClusterRoleBinding de RBAC que hace referencia al ClusterRole system:controller:clusterrole-aggregation-controller predeterminado. Este ClusterRole predeterminado tiene el verbo escalate, que permite que los sujetos modifiquen los privilegios de sus propios roles, lo que permite la elevación de privilegios. Para obtener más detalles, consulta el mensaje de registro de esta alerta.

1. Revisa cualquier ClusterRoleBinding que haga referencia a la ClusterRole de system:controller:clusterrole-aggregation-controller.
2. Revisa las modificaciones en el ClusterRole de system:controller:clusterrole-aggregation-controller.
3. Determina si hay otros indicios de actividad maliciosa por parte del principal que creó el ClusterRoleBinding en los registros de auditoría de Cloud Logging.

Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Alguien implementó un Pod con una convención de nombres similar a las herramientas comunes que se usan para evadir contenedores o ejecutar otros ataques en el clúster. Para obtener más detalles, consulta el mensaje de registro de esta alerta.

1. Confirma que el Pod es legítimo.
2. Determina si hay otros indicios de actividad maliciosa del Pod o la principal en los registros de auditoría de Cloud Logging.
3. Si la principal no es una cuenta de servicio (IAM o Kubernetes), comunícate con el propietario de la cuenta para confirmar si el propietario legítimo realizó la acción.
4. Si la principal es una cuenta de servicio (IAM o Kubernetes), identifica el origen de la acción para determinar su legitimidad.
5. Si el Pod no es legítimo, quítalo junto con las vinculaciones de RBAC y las cuentas de servicio asociadas que usó la carga de trabajo y que permitieron su creación.

Privilege Escalation: Workload Created with a Sensitive Host Path Mount

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Alguien creó una carga de trabajo que contiene una activación de volumen hostPath en una ruta de acceso sensible en el sistema de archivos del nodo host. El acceso a estas rutas de acceso en el sistema de archivos del host se puede usar para acceder a información privilegiada o sensible en el nodo y para escapar de contenedores. Si es posible, no permitas ningún volumen hostPath en tu clúster. Para obtener más detalles, consulta el mensaje de registro de esta alerta.

1. Revisa la carga de trabajo para determinar si este volumen de hostPath es necesario para la funcionalidad prevista. Si es así, asegúrate de que la ruta de acceso sea al directorio más específico posible. Por ejemplo, /etc/myapp/myfiles en lugar de / o /etc.
2. Determina si hay otros indicios de actividad maliciosa relacionados con esta carga de trabajo en los registros de auditoría de Cloud Logging.

Para bloquear las activaciones de volumen de hostPath en el clúster, consulta la guía para aplicar los estándares de seguridad de Pods.

Privilege Escalation: Workload with shareProcessNamespace enabled

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Alguien implementó una carga de trabajo con la opción shareProcessNamespace establecida en true, lo que permite que todos los contenedores compartan el mismo espacio de nombres de proceso de Linux. Esto podría permitir que un contenedor no confiable o comprometido escale privilegios accediendo y controlando las variables de entorno, la memoria y otros datos sensibles de los procesos que se ejecutan en otros contenedores. Algunas cargas de trabajo pueden requerir que esta funcionalidad funcione por motivos legítimos, como el manejo de registros de contenedores laterales o la depuración de contenedores. Para obtener más detalles, consulta el mensaje de registro de esta alerta.

1. Confirma que la carga de trabajo realmente requiere acceso a un espacio de nombres de proceso compartido para todos los contenedores en la carga de trabajo.
2. Verifica si hay otros indicios de actividad maliciosa por parte de la principal en los registros de auditoría de Cloud Logging.
3. Si la principal no es una cuenta de servicio (IAM o Kubernetes), comunícate con el propietario de la cuenta para confirmar si realizó la acción.
4. Si la principal es una cuenta de servicio (IAM o Kubernetes), identifica la legitimidad de lo que provocó que la cuenta de servicio realice esta acción.

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 hallazgo de Discovery: Service Account Self-Investigation, como se indica en Revisa los detalles de hallazgos antes en esta página. Se abre el panel de detalles del hallazgo 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 resultado. La gravedad es HIGH si la llamada a la API que activó este resultado no estaba 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 emisor: Es la dirección IP interna o externa.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso:
     • Nombre completo del proyecto: Es el proyecto que contiene las credenciales de la cuenta que se podrían filtrar.
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.
   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 archivo JSON del 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 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 pestaña Resumen del panel de detalles del hallazgo, 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 adecuado 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

La Detección de eventos de amenazas examina los registros de auditoría para detectar la eliminación de 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 con él.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Inhibit System Recovery: Deleted Google Cloud Backup and DR host, como se detalla en Revisa los hallazgos. Se abre el panel de detalles del hallazgo 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: Es el nombre de una base de datos o VM conectada a la copia de seguridad y la DR.
     • Nombre de host: Es el nombre de un host conectado a la copia de seguridad y la DR.
     • Asunto principal: Es un usuario que ejecutó correctamente una acción.
   • Recurso afectado
     • Nombre visible del recurso: Es el proyecto en el que se borró el host.
   • 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: Es un 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 con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

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 del servicio de Backup and DR que se usa para aplicar políticas de copia de seguridad a una aplicación.

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Inhibit System Recovery: Google Cloud Backup and DR remove plan, como se detalla en Revisa los hallazgos. Se abre el panel de detalles del hallazgo 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: Es el nombre de una base de datos o VM conectada a la copia de seguridad y la DR.
     • Nombre del perfil: Especifica el destino de almacenamiento para las copias de seguridad de los datos de la aplicación y la VM.
     • Nombre de la plantilla: Es el nombre de un conjunto de políticas que definen la frecuencia, el programa y el tiempo de retención de las copias de seguridad.
   • Recurso afectado
     • Nombre visible del recurso: Es 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: Es un 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 con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

1. En el proyecto en el que se realizó la acción, navega a la consola de administración.
2. En la pestaña App Manager, 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 base para las copias de seguridad que se puede aplicar a varias aplicaciones.

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Inhibit System Recovery: Google Cloud Backup and DR delete template, como se detalla en Revisa los hallazgos. Se abre el panel de detalles del hallazgo 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: Es el nombre de un conjunto de políticas que definen la frecuencia, el programa y el tiempo de retención de las copias de seguridad.
     • Asunto principal: Es un usuario que ejecutó correctamente una acción.
   • Recurso afectado
     • Nombre visible del recurso: Es 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: Es un 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 con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

1. En el proyecto en el que se realizó la acción, navega a la consola de administración.
2. En la pestaña App Manager, 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 de copia de seguridad, 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 crea una copia de seguridad y dónde se almacena.

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Inhibit System Recovery: Google Cloud Backup and DR delete policy, como se detalla en Revisa los hallazgos. Se abre el panel de detalles del hallazgo 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: Es el nombre de una sola política, que define la frecuencia, la programación y el tiempo de retención de las copias de seguridad.
     • Asunto principal: Es un usuario que ejecutó correctamente una acción.
   • Recurso afectado
     • Nombre visible del recurso: Es 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: Es un 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 con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados. 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 aplicaciones, selecciona la aplicación afectada y revisa la configuración de Política que se aplicó a ella.

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 las copias de seguridad.

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Inhibit System Recovery: Google Cloud Backup and DR delete profile, como se detalla en Revisa los hallazgos. Se abre el panel de detalles del hallazgo 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 la aplicación y la VM.
     • Asunto principal: Es un usuario que ejecutó correctamente una acción.
   • Recurso afectado
     • Nombre visible del recurso: Es 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: Es un 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 con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados. 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 ver una lista de todos los perfiles. 3. Revisa los perfiles para verificar que estén todos los perfiles obligatorios. 4. Si el perfil eliminado se quitó por error, selecciona Crear perfil para definir los destinos de almacenamiento de 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. Un grupo de almacenamiento asocia un bucket de Cloud Storage con las copias de seguridad y la DR.

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Inhibit System Recovery: Google Cloud Backup and DR delete storage pool, como se detalla en Revisa los hallazgos. Se abre el panel de detalles del hallazgo 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: Es un usuario que ejecutó correctamente una acción.
   • 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: Es un 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 con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados. 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 ver una lista de todos los grupos de almacenamiento. 3. Revisa las asociaciones del grupo de almacenamiento con los dispositivos de copia de seguridad. 4. Si un dispositivo activo no tiene un grupo de almacenamiento asociado, selecciona Agregar grupo de OnVault para volver a agregarlo.

Data Destruction: Google Cloud Backup and DR expire image

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

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Inhibit System Recovery: Google Cloud Backup and DR expire image, como se detalla en Revisa los hallazgos. Se abre el panel de detalles del hallazgo 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: Es el nombre de una sola política, que define la frecuencia, el programa y el tiempo de retención de las copias de seguridad.
     • Nombre de la plantilla: Es el nombre de un conjunto de políticas que definen la frecuencia, el programa 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 la aplicación y la VM.
     • Asunto principal: Es un usuario que ejecutó correctamente una acción.
   • Recurso afectado
     • Nombre visible del recurso: Es el proyecto en el que se borró la imagen de la 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: Es un 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 con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados. 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 Monitor y selecciona Trabajos para revisar el estado del trabajo de eliminación de copias de seguridad. 3. Si no se autoriza una tarea de eliminación, navega a los permisos de IAM para revisar los usuarios que tienen acceso a los datos de las copias de seguridad.

Data Destruction: Google Cloud Backup and DR expire all images

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

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Inhibit System Recovery: Google Cloud Backup and DR expire all images, como se detalla en Revisa los hallazgos. Se abre el panel de detalles del hallazgo 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: Es el nombre de una sola política, que define la frecuencia, el programa y el tiempo de retención de las copias de seguridad.
     • Nombre de la plantilla: Es el nombre de un conjunto de políticas que definen la frecuencia, el programa 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 la aplicación y la VM.
     • Asunto principal: Es un usuario que ejecutó correctamente una acción.
   • Recurso afectado
     • Nombre visible del recurso: Es el proyecto en el que se borraron las imágenes de la 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: Es un 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 con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados. 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 Monitor y selecciona Trabajos para revisar el estado del trabajo de eliminación de copias de seguridad. 3. Si no se autoriza una tarea de eliminación, navega a los permisos de IAM para revisar los usuarios que tienen acceso a los datos de las copias 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 hallazgo de Inhibit System Recovery: Google Cloud Backup and DR remove appliance, como se detalla en Revisa los hallazgos. Se abre el panel de detalles del hallazgo 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: Es el nombre de una base de datos o VM conectada a la copia de seguridad y la DR.
     • Asunto principal: Es un usuario que ejecutó correctamente una acción.
   • Recurso afectado
     • Nombre visible del recurso: Es 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: Es un 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 con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados. 1. En el proyecto en el que se realizó la acción, navega a la consola de administración. 2. En la pestaña App Manager, 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 nuevo dispositivo y volver a aplicar protecciones a las apps no protegidas, navega a Backup and 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ú Almacenamiento, configura cada dispositivo nuevo con un destino de almacenamiento. Después de configurar un dispositivo, este aparecerá como una opción cuando crees un perfil para tus aplicaciones.

Impact: Google Cloud Backup and DR reduced backup expiration

La Detección de amenazas en eventos examina los registros de auditoría para detectar si se redujo la fecha de vencimiento de una copia de seguridad en un dispositivo del servicio de copia de seguridad y DR.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Impact: Google Cloud Backup and DR reduced backup expiration, como se detalla en Revisa los hallazgos. Se abre el panel de detalles del hallazgo 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:
     • Descripción: Información sobre la detección
     • Sujeto principal: Un usuario o una cuenta de servicio que ejecutó correctamente una acción.
   • Recurso afectado
     • Nombre visible del recurso: Es el proyecto en el que se redujo el vencimiento de la copia de seguridad.
   • Vínculos relacionados, en especial los siguientes campos:
     • Método MITRE ATTACK: Es un vínculo a la documentación de MITRE ATT&CK.
     • URI de Logging: Es un 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 Asunto 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 con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

1. En el proyecto en el que se realizó la acción, navega a la consola de administración.
2. En la pestaña App Manager, busca la aplicación afectada para la que se redujo el vencimiento de la copia de seguridad y verifica que el principal haya sido el responsable del vencimiento.
3. Para iniciar una nueva copia de seguridad de la aplicación, selecciona Administrar configuraciones de copia de seguridad para crear una copia de seguridad según demanda o programar una nueva.

Impact: Google Cloud Backup and DR reduced backup frequency

Event Threat Detection examina los registros de auditoría para detectar si se modificó el plan de copia de seguridad para reducir su frecuencia.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Impact: Google Cloud Backup and DR reduced backup frequency, como se detalla en Revisa los hallazgos. Se abre el panel de detalles del hallazgo 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:
     • Descripción: Información sobre la detección
     • Sujeto principal: Un usuario o una cuenta de servicio que ejecutó correctamente una acción.
   • Recurso afectado
     • Nombre visible del recurso: Es el proyecto en el que se redujo la frecuencia de las copias de seguridad.
   • Vínculos relacionados, en especial los siguientes campos:
     • Método MITRE ATTACK: Es un vínculo a la documentación de MITRE ATT&CK.
     • URI de Logging: Es un 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 Asunto 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 con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

1. En el proyecto en el que se realizó la acción, navega a la consola de administración.
2. En la pestaña App Manager, busca la aplicación afectada para la que se redujo la frecuencia de las copias de seguridad y verifica que el administrador haya realizado el cambio de forma intencional.
3. Para iniciar una nueva copia de seguridad de la aplicación, selecciona Administrar configuraciones de copia de seguridad para crear una copia de seguridad según demanda o programar una nueva.

Impact: Suspicious Kubernetes Container Names - Coin Mining

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Alguien implementó un Pod con una convención de nombres similar a la de los mineros de criptomonedas comunes. Es posible que un atacante que haya logrado acceso inicial al clúster intente usar sus recursos para la minería de criptomonedas. Para obtener más detalles, consulta el mensaje de registro de esta alerta.

1. Confirma que el Pod es legítimo.
2. Determina si hay otros indicios de actividad maliciosa del Pod o la principal en los registros de auditoría de Cloud Logging.
3. Si la principal no es una cuenta de servicio (IAM o Kubernetes), comunícate con el propietario de la cuenta para confirmar si el propietario legítimo realizó la acción.
4. Si la principal es una cuenta de servicio (IAM o Kubernetes), identifica el origen de la acción para determinar su legitimidad.
5. Si el Pod no es legítimo, quítalo junto con las vinculaciones de RBAC y las cuentas de servicio asociadas que usó la carga de trabajo y que permitieron su creación.

Lateral Movement: Modified Boot Disk Attached to Instance

Los registros de auditoría se examinan para detectar movimientos de disco sospechosos entre los recursos de la instancia de Compute Engine. Se adjuntó un disco de arranque potencialmente modificado a tu instancia de Compute Engine.

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Lateral Movement: Modify Boot Disk Attaching to Instance, como se detalla en Revisa los hallazgos. Se abre el panel de detalles del hallazgo en la pestaña Resumen.

2. En la pestaña Resumen, toma nota de los valores de los siguientes campos.

   En Qué se detectó, encontrarás lo siguiente:

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

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

1. Usa herramientas de cuenta de servicio, como el Analizador de actividades, 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 adecuado 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 usar el inicio seguro para tus instancias de VM de Compute Engine.
• Considera borrar la cuenta de servicio potencialmente vulnerada, además de rotar y borrar todas las claves de acceso de la cuenta de servicio del proyecto potencialmente vulnerado. Después de la eliminación, las aplicaciones que usan la cuenta de servicio para la autenticación pierden el acceso. Antes de continuar, tu 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 cuando se otorgan todos los privilegios de una base de datos de AlloyDB para 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 hallazgo de Privilege Escalation: AlloyDB Over-Privileged Grant, como se indica en Revisa los hallazgos.

2. En la pestaña Resumen del panel de detalles de los resultados, revisa la información de 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 que se vio afectada.
     • Nombre de usuario de la base de datos: Es el usuario de PostgreSQL que otorgó privilegios excesivos.
     • Consulta de la base de datos: Es la consulta de PostgreSQL que se ejecutó y que otorgó los privilegios.
     • Beneficiarios de la base de datos: los beneficiarios de los privilegios excesivos.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: Es 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: Es el proyecto de Google Cloud que contiene la instancia de AlloyDB para PostgreSQL.
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un 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. Lista y muestra los privilegios de acceso para lo siguiente:
   • Bases de datos Usa el metacomando \l o \list y verifica qué privilegios se asignaron 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 asignaron a las funciones o los procedimientos en la base de datos que se enumeran en Nombre visible de la base de datos (del Paso 1).

Paso 3: Comprueba los registros

1. En la consola de Google Cloud, ve al Explorador de registros haciendo clic en el vínculo en URI de registro de Cloud (del Paso 1). 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, con 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 de MITRE ATT&CK para este tipo de resultado: Robo de datos en el servicio web.
2. Para determinar si se necesitan pasos de solución adicionales, 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 adecuado 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 con concesiones con 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 (del Nombre visible de la base de datos del Paso 1, retira los permisos innecesarios de los beneficiarios (del Beneficiarios de la base de datos del Paso 1.

Privilege Escalation: AlloyDB Database Superuser Writes to User Tables

Detecta cuando la cuenta de superusuario de la base de datos de AlloyDB para PostgreSQL (postgres) escribe en tablas de usuarios. Por lo general, el superusuario (un rol con acceso muy amplio) no se debe usar para escribir en tablas de usuarios. Se debe usar una cuenta de usuario con acceso más limitado para la actividad diaria normal. Cuando un superusuario escribe en una tabla de usuarios, eso podría indicar que un atacante tiene privilegios elevados o que comprometió al usuario de la base de datos predeterminado 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 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 de los resultados, revisa la información de 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 que se vio afectada.
     • Nombre de usuario de la base de datos: Es el superusuario.
     • Consulta de base de datos: Es 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: Es 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: Es el proyecto de Google Cloud que contiene la instancia de AlloyDB para PostgreSQL.
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un 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 de AlloyDB para PostgreSQL relevante.
2. Verifica los registros de pgaudit de PostgreSQL, que contienen las consultas que ejecuta el superusuario, con los siguientes filtros:
   • protoPayload.request.user="postgres"

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: Robo de datos en el servicio web.
2. Para determinar si se necesitan pasos de solución adicionales, 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 adecuado 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.

• Revisa los usuarios que tienen permiso para conectarse a la base de datos.
• Considera cambiar la contraseña del superusuario.
• Considera crear un usuario nuevo con acceso limitado para los diferentes tipos de consultas que se usan en la instancia.
  • Otorga al usuario nuevo solo los permisos necesarios para ejecutar sus consultas.
  • Actualiza las credenciales de los clientes que se conectan a la instancia de AlloyDB para PostgreSQL

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

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

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 se encuentran 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 hallazgo no está disponible si activas Security Command Center a nivel del 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: MITRE: https://attack.mitre.org/techniques/T1078/ Detalles del evento de Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_password_leak

Initial Access: Suspicious Login Blocked

Este hallazgo no está disponible si activas Security Command Center a nivel del 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: MITRE: https://attack.mitre.org/techniques/T1078/ Detalles del evento de Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#suspicious_login

Initial Access: Account Disabled Hijacked

Este hallazgo no está disponible si activas Security Command Center a nivel del 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: MITRE: https://attack.mitre.org/techniques/T1078/ Detalles del evento de Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_hijacked

Impair Defenses: Two Step Verification Disabled

Este hallazgo no está disponible si activas Security Command Center a nivel del 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: MITRE: https://attack.mitre.org/techniques/T1562/ Detalles del evento de Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#2sv_disable

Initial Access: Government Based Attack

Este hallazgo no está disponible si activas Security Command Center a nivel del 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: MITRE: https://attack.mitre.org/techniques/T1078/ Detalles del evento de Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#gov_attack_warning

Persistence: SSO Enablement Toggle

Este hallazgo no está disponible si activas Security Command Center a nivel del 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: MITRE: https://attack.mitre.org/techniques/T1098/ Detalles del evento de Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#TOGGLE_SSO_ENABLED

Persistence: SSO Settings Changed

Este hallazgo no está disponible si activas Security Command Center a nivel del 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: MITRE: https://attack.mitre.org/techniques/T1098/ Detalles del evento de Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#CHANGE_SSO_SETTINGS

Impair Defenses: Strong Authentication Disabled

Este hallazgo no está disponible si activas Security Command Center a nivel del 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: MITRE: https://attack.mitre.org/techniques/T1562/ Detalles del evento de Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-security-settings#ENFORCE_STRONG_AUTHENTICATION

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 en busca de activaciones a nivel del proyecto.

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

• Centro de alertas de Google Workspace
• Centro de seguridad de Google Workspace

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:

• Si aún tienes acceso a la cuenta, cambia o restablece la contraseña y activa la verificación en dos pasos.
• Comunícate con el administrador de Google Workspace o con el equipo de la empresa que administra la cuenta. Usa estos hallazgos como indicación de que una cuenta podría estar comprometida.

Detecciones de amenazas del IDS de Cloud

Cloud IDS: THREAT_ID

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Los resultados del IDS de Cloud los genera el IDS de Cloud, que es un servicio de seguridad que supervisa el tráfico hacia y desde tus recursos de Google Cloud en busca de amenazas. Cuando Cloud IDS detecta una amenaza, envía información sobre ella, 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 hallazgo de Cloud IDS: THREAT_ID, como se indica en Revisa los hallazgos.

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

   • Qué se detectó, en especial los siguientes campos:
     • Protocolo: Es el protocolo de red que se usa.
     • Hora del evento: Es la hora en que ocurrió el evento.
     • Descripción: Más información sobre el hallazgo
     • Gravedad: Indica la gravedad de la alerta.
     • IP de destino: Es la IP de destino del tráfico de red.
     • Puerto de destino: Es el puerto de destino del tráfico de red.
     • IP de origen: Es la IP de origen del tráfico de red.
     • Puerto de origen: Es 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, en especial los siguientes campos:
     • URI de Cloud Logging: Es un vínculo a las entradas de registro de Cloud IDS. Estas entradas tienen la información necesaria para buscar en el Threat Vault de Palo Alto Networks.
   • Servicio de detección
     • Categoría de 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: Busca métodos de ataque y respuesta

Después de revisar los detalles del hallazgo, consulta la documentación de 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 hallazgo.

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. Una práctica recomendada importante es garantizar que tus contenedores sean inmutables. Este es un hallazgo de gravedad baja, ya que es posible que tu organización no esté siguiendo esta práctica recomendada. Hay resultados Execution: Added Malicious Binary Executed correspondientes cuando el hash del binario es un indicador de compromiso (IoC) conocido. Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre un hallazgo de Added Binary Executed como se indica en Revisa los resultados. Se abre el panel de detalles del hallazgo 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 absoluta del objeto binario agregado.
     • Argumentos: Son los argumentos proporcionados 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, incluido el número de proyecto, la ubicación y el nombre del clúster.
   • Vínculos relacionados, en especial los siguientes campos:
     • Indicador de VirusTotal: Es un vínculo a la página de análisis de VirusTotal.

3. Haz clic en JSON y observa los siguientes campos:

   • resource:
     • project_display_name: Es el nombre del proyecto que contiene el clúster.
   • sourceProperties:
     • Pod_Namespace: 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 implementa.
     • VM_Instance_Name: Es el nombre del nodo de GKE en el que se ejecutó el Pod.

4. Identifica otros resultados que se produjeron en un momento similar para este contenedor. Los hallazgos relacionados pueden indicar que esta actividad fue maliciosa, en lugar de un incumplimiento de las prácticas recomendadas.

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 hallazgo. 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 hallazgo y el espacio de nombres de pods 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 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 verificar el valor de hash SHA-256 del binario marcado como malicioso en VirusTotal, haz clic en el vínculo en el indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URLs, dominios y direcciones IP potencialmente maliciosos.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE y el análisis de VirusTotal.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado 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.

• Si el objetivo era incluir el objeto binario en el contenedor, vuelve a compilar la imagen del contenedor con el objeto binario incluido. De esta manera, el contenedor puede ser inmutable.
• De lo contrario, 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. Una práctica recomendada importante es garantizar que tus contenedores sean inmutables. Este es un hallazgo de baja gravedad, ya que es posible que tu organización no esté siguiendo esta práctica recomendada. Hay hallazgos Execution: Added Malicious Library Loaded correspondientes cuando el hash del binario es un indicador de compromiso (IoC) conocido. Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre un hallazgo de Added Library Loaded como se indica en Revisa los resultados. Se abre el panel de detalles del hallazgo 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 proceso binario que cargó la biblioteca.
     • Bibliotecas: Detalles sobre la biblioteca agregada.
     • Argumentos: Son los argumentos proporcionados cuando se invoca el objeto binario del proceso.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: Es el nombre completo del recurso del clúster.
   • Vínculos relacionados, en especial los siguientes campos:
     • Indicador de VirusTotal: Es un vínculo a la página de análisis de VirusTotal.

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: 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: El nombre del nodo de GKE en el que se ejecutó el Pod.

4. Identifica otros resultados que se produjeron en un momento similar para este contenedor. Los hallazgos relacionados pueden indicar que esta actividad fue maliciosa, en lugar de un incumplimiento de las prácticas recomendadas.

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 hallazgo y el espacio de nombres de pods 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 verificar el valor de hash SHA-256 del binario marcado como malicioso en VirusTotal, haz clic en el vínculo en el indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URLs, dominios y direcciones IP potencialmente maliciosos.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE y el análisis de VirusTotal.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado 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.

• Si la biblioteca estaba destinada a incluirse en el contenedor, vuelve a compilar la imagen del contenedor con la biblioteca incluida. De esta manera, el contenedor puede ser inmutable.
• De lo contrario, 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 hallazgo de Execution: Added Malicious Binary Executed como se indica en Revisa los resultados. Se abre el panel de detalles del hallazgo 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 absoluta del objeto binario agregado.
     • Argumentos: Son los argumentos proporcionados cuando se invoca el objeto binario agregado.
     • Contenedores: Es el nombre del contenedor afectado.
     • URI de contenedores: 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, incluido el número de proyecto, la ubicación y el nombre del clúster.
   • Vínculos relacionados, en especial los siguientes campos:
     • Indicador de VirusTotal: Es un 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 hallazgo. 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 hallazgo y el espacio de nombres de pods 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 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 verificar el valor de hash SHA-256 del binario marcado como malicioso en VirusTotal, haz clic en el vínculo en el indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URLs, dominios y direcciones IP potencialmente maliciosos.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE y el análisis de VirusTotal.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado 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 hallazgo de Execution: Added Malicious Library Loaded como se indica en Revisa los resultados. Se abre el panel de detalles del hallazgo 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 proceso binario que cargó la biblioteca.
     • Bibliotecas: Detalles sobre la biblioteca agregada.
     • Argumentos: Son los argumentos proporcionados cuando se invoca el objeto binario del proceso.
     • Contenedores: Es el nombre del contenedor afectado.
     • URI de contenedores: 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.
   • Vínculos relacionados, en especial los siguientes campos:
     • Indicador de VirusTotal: Es un 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 hallazgo. 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 hallazgo y el espacio de nombres de pods 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 verificar el valor de hash SHA-256 del binario marcado como malicioso en VirusTotal, haz clic en el vínculo en el indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URLs, dominios y direcciones IP potencialmente maliciosos.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE y el análisis de VirusTotal.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado 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 contenido:

• Se incluye en la imagen del contenedor original.
• Se identifica como malicioso en función de la inteligencia sobre amenazas.

El atacante tiene el control del repositorio de imágenes de contenedor o de la canalización de creación, en la que se inyecta el binario malicioso en la imagen del contenedor. Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre un hallazgo de Execution: Built in Malicious Binary Executed como se indica en Revisa los resultados. Se abre el panel de detalles del hallazgo 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 absoluta del objeto binario integrado.
     • Argumentos: Son los argumentos proporcionados cuando se invoca el objeto binario integrado.
     • Contenedores: Es el nombre del contenedor afectado.
     • URI de contenedores: 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, incluido el número de proyecto, la ubicación y el nombre del clúster.
   • Vínculos relacionados, en especial los siguientes campos:
     • Indicador de VirusTotal: Es un vínculo a la página de análisis de VirusTotal.

3. Haz clic en 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 hallazgo. 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 hallazgo y el espacio de nombres de pods 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 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 local para almacenar el objeto binario malicioso de tin 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 verificar el valor de hash SHA-256 del binario marcado como malicioso en VirusTotal, haz clic en el vínculo en el indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URLs, dominios y direcciones IP potencialmente maliciosos.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE y el análisis de VirusTotal.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado 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: Malicious Python executed

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Un modelo de aprendizaje automático identificó el código de Python ejecutado como malicioso. Los atacantes pueden usar Python para transferir herramientas y ejecutar comandos sin objetos binarios. Una práctica recomendada importante es garantizar que tus contenedores sean inmutables. El uso de secuencias de comandos para transferir herramientas puede imitar la técnica del atacante de transferencia de herramientas de entrada y generar detecciones no deseadas.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre un hallazgo de Execution: Malicious Python executed como se indica en Revisa los resultados. Se abre el panel de detalles del hallazgo 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: 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 de secuencias de comandos literales, por ejemplo, python3 -c.
     • Argumentos: Son los argumentos proporcionados cuando se invoca la secuencia de comandos.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: Es el nombre completo del recurso del clúster, incluido el número de proyecto, la ubicación y el nombre del clúster.
   • Vínculos relacionados, en especial los siguientes campos:
     • Indicador de VirusTotal: Es un vínculo a la página de análisis de VirusTotal.

3. En la vista de detalles del resultado, haz clic en la pestaña JSON.

4. En el JSON, toma nota de los siguientes campos.

   • finding:
     • processes:
     • script:
       • contents: Es el contenido de la secuencia de comandos ejecutada, que podría truncarse por motivos de rendimiento. Esto puede ayudarte en la investigación.
       • sha256: Es el hash SHA-256 de script.contents.
   • resource:
     • project_display_name: Es el nombre del proyecto que contiene el recurso.
   • sourceProperties:
     • Pod_Namespace: 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.

5. Identifica otros resultados que se produjeron en un momento similar para este contenedor. Por ejemplo, si la secuencia de comandos descarta un objeto binario, busca resultados relacionados con él.

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 hallazgo. 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 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 verificar el valor de hash SHA-256 del binario marcado como malicioso en VirusTotal, haz clic en el vínculo en el indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URLs, dominios y direcciones IP potencialmente maliciosos.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE y el análisis de VirusTotal.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado 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.

• Si Python estaba realizando los cambios deseados en el contenedor, vuelve a compilar la imagen del contenedor de modo que no se necesiten cambios. De esta manera, el contenedor puede ser immutable.
• De lo contrario, 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 contenido:

• Se incluye en la imagen del contenedor original.
• Se modifican durante el entorno de ejecución del contenedor.
• Se identifica como malicioso en función de la inteligencia sobre 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 hallazgo de Execution: Modified Malicious Binary Executed como se indica en Revisa los resultados. Se abre el panel de detalles del hallazgo 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 absoluta del objeto binario modificado.
     • Argumentos: Son los argumentos proporcionados cuando se invoca el objeto binario modificado.
     • Contenedores: Es el nombre del contenedor afectado.
     • URI de contenedores: 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, incluido el número de proyecto, la ubicación y el nombre del clúster.
   • Vínculos relacionados, en especial los siguientes campos:
     • Indicador de VirusTotal: Es un vínculo a la página de análisis de VirusTotal.

3. Haz clic en 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 hallazgo. 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 hallazgo y el espacio de nombres de pods 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 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 verificar el valor de hash SHA-256 del binario marcado como malicioso en VirusTotal, haz clic en el vínculo en el indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URLs, dominios y direcciones IP potencialmente maliciosos.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE y el análisis de VirusTotal.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado 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:

• Se incluye en la imagen del contenedor original.
• Se modifican durante el entorno de ejecución del contenedor.
• Se identifica como malicioso en función de la inteligencia sobre 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 hallazgo de Execution: Modified Malicious Library Loaded como se indica en Revisa los resultados. Se abre el panel de detalles del hallazgo 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 proceso binario que cargó la biblioteca.
     • Bibliotecas: Detalles sobre la biblioteca modificada.
     • Argumentos: Son los argumentos proporcionados cuando se invoca el objeto binario del proceso.
     • Contenedores: Es el nombre del contenedor afectado.
     • URI de contenedores: 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.
   • Vínculos relacionados, en especial los siguientes campos:
     • Indicador de VirusTotal: Es un 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 hallazgo y el espacio de nombres de pods 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 verificar el valor de hash SHA-256 del binario marcado como malicioso en VirusTotal, haz clic en el vínculo en el indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URLs, dominios y direcciones IP potencialmente maliciosos.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE y el análisis de VirusTotal.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado 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ó el código de Bash ejecutado como malicioso. Los atacantes pueden usar Bash para transferir herramientas y ejecutar comandos sin objetos binarios. Una práctica recomendada importante es garantizar que tus contenedores sean inmutables. El uso de secuencias de comandos para transferir herramientas puede imitar la técnica del atacante de transferencia de herramientas de entrada y generar detecciones no deseadas.

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. Se abre el panel de detalles del hallazgo 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: 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 de secuencias de comandos literales, por ejemplo, bash -c.
     • Argumentos: Son los argumentos proporcionados cuando se invoca la secuencia de comandos.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: Es el nombre completo del recurso del clúster, incluido el número de proyecto, la ubicación y el nombre del clúster.
   • Vínculos relacionados, en especial los siguientes campos:
     • Indicador de VirusTotal: Es un vínculo a la página de análisis de VirusTotal.

3. En la vista de detalles del resultado, haz clic en la pestaña JSON.

4. En el JSON, toma nota de los siguientes campos.

   • finding:
     • processes:
     • script:
       • contents: Es el contenido de la secuencia de comandos ejecutada, que podría truncarse por motivos de rendimiento. Esto puede ayudarte en la investigación.
       • sha256: Es el hash SHA-256 de script.contents.
   • resource:
     • project_display_name: Es el nombre del proyecto que contiene el recurso.
   • sourceProperties:
     • Pod_Namespace: 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.

5. Identifica otros resultados que se produjeron en un momento similar para este contenedor. Por ejemplo, si la secuencia de comandos descarta un objeto binario, busca resultados relacionados con él.

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 hallazgo. 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 verificar el valor de hash SHA-256 del binario marcado como malicioso en VirusTotal, haz clic en el vínculo en el indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URLs, dominios y direcciones IP potencialmente maliciosos.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE y el análisis de VirusTotal.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado 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.

• Si la secuencia de comandos estaba realizando los cambios deseados en el contenedor, vuelve a compilar la imagen del contenedor de modo que no se necesiten cambios. De esta manera, el contenedor puede ser inmutable.
• De lo contrario, 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

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Container Threat Detection 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 hallazgo, sigue estos pasos.

Paso 1: Revisa los detalles del hallazgo

1. Abre un hallazgo de Malicious URL Observed como se indica en Revisa los resultados. Se abre el panel de detalles del hallazgo 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:
     • URI: Es el URI malicioso observado.
     • Objeto binario agregado: Es la ruta de acceso completa del proceso binario que recibió los argumentos que contienen la URL maliciosa.
     • Argumentos: Son los argumentos proporcionados cuando se invoca el objeto binario del proceso.
     • Variables de entorno: Son las variables de entorno que estaban vigentes cuando se invocó el objeto binario del proceso.
     • Containers: Es el nombre del contenedor.
     • Pods de Kubernetes: El nombre y el espacio de nombres del pod.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre visible del recurso: Es el nombre del recurso afectado.
     • Nombre completo del recurso: Es el nombre completo del recurso del clúster. El nombre de recurso completo incluye la siguiente información:
       • El proyecto que contiene el clúster: projects/PROJECT_ID
       • Es la ubicación en la que se encuentra el clúster: zone/ZONE o locations/LOCATION.
       • El nombre del clúster: projects/CLUSTER_NAME
   • Vínculos relacionados, en especial los siguientes campos:
     • Indicador de VirusTotal: Es un vínculo a la página de análisis de VirusTotal.

3. En la pestaña JSON, en el atributo sourceProperties, ten en cuenta 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 problema. Se abrirá la página Clústeres.

4. En la sección Metadatos de la página Detalles del clúster, toma nota de la información definida por el usuario que podría 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. De los nodos enumerados, selecciona el que coincida con el valor de VM_Instance_Name que anotaste en el JSON de hallazgo anterior.

7. En la pestaña Detalles de la página Detalles del nodo, en la sección Anotaciones, anota 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 de resultados, 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 hallazgos y, si es necesario, el Espacio de nombres (kubernetes.pods.ns) del pod 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 archivo JSON del resultado antes. 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. Busca los registros de 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 en el resumen de hallazgos anterior.

   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 de MITRE ATT&CK para este tipo de resultado: Transferencia de herramientas de Ingress.
3. Para verificar el valor de hash SHA-256 del binario marcado como malicioso en VirusTotal, haz clic en el vínculo en el indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URLs, 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 y el análisis de VirusTotal.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado 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. Se abre el panel de detalles del hallazgo 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:
     • Programa binario: Es la ruta de acceso absoluta del proceso que se inició con el redireccionamiento de transmisión a un socket remoto.
     • Argumentos: Son los argumentos proporcionados cuando se invoca el objeto binario del proceso.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: Es el nombre completo del recurso del clúster.
     • Nombre completo del proyecto: Es el proyecto de Google Cloud afectado.
   • Vínculos relacionados, en especial los siguientes campos:
     • Indicador de VirusTotal: Es un vínculo a la página de análisis de VirusTotal.

3. En la vista de detalles del resultado, haz clic en la pestaña JSON.

4. En el JSON, toma nota de los siguientes campos.

   • resource:
     • project_display_name: Es el nombre del proyecto que contiene el recurso.
   • sourceProperties:
     • Pod_Namespace: 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 verificar el valor de hash SHA-256 del binario marcado como malicioso en VirusTotal, haz clic en el vínculo en el indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URLs, dominios y direcciones IP potencialmente maliciosos.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE y el análisis de VirusTotal.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado 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

Container Threat Detection observó un proceso que generó un proceso de shell secundario de forma inesperada. Este evento puede indicar que un atacante está intentando abusar de los comandos y las secuencias de comandos de shell.

Para responder a este hallazgo, sigue estos pasos.

Paso 1: Revisa los detalles del hallazgo

1. Abre un hallazgo de Unexpected Child Shell como se indica en Revisa los resultados. Se abre el panel de detalles del hallazgo 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:
     • 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 proceso binario del shell secundario.
     • Containers: Es el nombre del contenedor.
     • URI de contenedores: Es el URI de la imagen del contenedor.
     • Pods de Kubernetes: El nombre y el espacio de nombres del pod.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre visible del recurso: Es el nombre del recurso afectado.
     • Nombre completo del recurso: Es el nombre completo del recurso del clúster. El nombre de recurso completo incluye la siguiente información:
       • El proyecto que contiene el clúster: projects/PROJECT_ID
       • Es la ubicación en la que se encuentra el clúster: zone/ZONE o locations/LOCATION.
       • El nombre del clúster: projects/CLUSTER_NAME
   • Vínculos relacionados, en especial los siguientes campos:
     • Indicador de VirusTotal: Es un vínculo a la página de análisis de VirusTotal.

3. Haz clic en la pestaña JSON y observa los siguientes campos:

+processes: Es un array que contiene todos los procesos relacionados con el hallazgo. 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: 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 de resultados, 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 hallazgos y, si es necesario, el Espacio de nombres (kubernetes.pods.ns) del pod 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 archivo JSON de resultados antes. 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 un 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 de MITRE ATT&CK para este tipo de resultado: intérprete de comandos y secuencias de comandos: shell de Unix.
2. Para verificar el valor de hash SHA-256 del binario marcado como malicioso en VirusTotal, haz clic en el vínculo en el indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URLs, dominios y direcciones IP potencialmente maliciosos.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE y el análisis de VirusTotal.

Paso 7: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado 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 VM Threat Detection

Para obtener más información sobre VM Threat Detection, consulta Descripción general de VM Threat Detection.

Defense Evasion: Rootkit

VM Threat Detection detectó una combinación de indicadores que coinciden con un rootkit en modo kernel conocido en una instancia de VM de Compute Engine.

La categoría de resultados Defense Evasion: Rootkit es un superconjunto de las siguientes categorías de resultados. Por lo tanto, esta sección también se aplica a estas categorías de resultados.

• Defense Evasion: Unexpected ftrace handler (vista previa)
• Defense Evasion: Unexpected interrupt handler (vista previa)
• Defense Evasion: Unexpected kernel code modification (vista previa)
• Defense Evasion: Unexpected kernel modules (vista previa)
• Defense Evasion: Unexpected kernel read-only data modification (vista previa)
• Defense Evasion: Unexpected kprobe handler (vista previa)
• Defense Evasion: Unexpected processes in runqueue (vista previa)
• Defense Evasion: Unexpected system call handler (vista previa)

Para responder a estos resultados, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo, como se indica en Revisa los resultados. Se abre el panel de detalles del hallazgo 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 rootkit de kernel: Es el nombre de la familia del rootkit que se detectó, por ejemplo, Diamorphine.
     • Páginas de código de kernel inesperadas: Indica si las páginas de código de kernel están presentes en regiones de código de kernel o módulo donde no se esperan.
     • Controlador de llamada del sistema inesperado: Indica si los controladores de llamadas del sistema están presentes en regiones de código de kernel o módulo donde no se esperan.

   • Recurso afectado, en especial el siguiente campo:

     • Nombre completo del recurso: Es 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, haz clic en la pestaña JSON en la vista de detalles del resultado.

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

3. Revisa los registros en busca de signos de intrusión en la instancia de VM afectada. Por ejemplo, verifica si hay actividades sospechosas o desconocidas, y signos de credenciales vulneradas.

Paso 3: Revisa los permisos y la configuración

1. En la pestaña Resumen de los detalles de los resultados, en el campo Nombre completo del recurso, haz clic en el vínculo.
2. Revisa los detalles de la instancia de VM, incluida la configuración de red y acceso.

Paso 4: Inspecciona la VM afectada

Sigue las instrucciones que se indican en Cómo inspeccionar una VM en busca de signos de manipulación de la memoria del kernel.

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

1. Revisa las entradas del framework de MITRE ATT&CK para evasión de defensa.
2. 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 adecuado 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.

1. Comunícate con el propietario de la VM.

2. Si es necesario, detén la instancia comprometida y reemplázala por una nueva.

3. Para el análisis forense, considera crear una copia de seguridad de las máquinas virtuales y los discos persistentes. Para obtener más información, consulta Opciones de protección de datos en la documentación de Compute Engine.

4. Borra la instancia de VM.

5. Para realizar una investigación más exhaustiva, considera usar servicios de respuesta ante incidentes, como Mandiant.

Execution: Cryptocurrency Mining Hash Match

VM Threat Detection detectó actividades de minería de criptomonedas haciendo coincidir los hashes de memoria de los programas en ejecución con los hashes de memoria de software de minería de criptomonedas conocido.

Para responder a estos resultados, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre un hallazgo de Execution: Cryptocurrency Mining Hash Match, como se indica en Revisa los hallazgos. Se abre el panel de detalles del hallazgo 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:

     • Familia binaria: Es la aplicación de criptomoneda que se detectó.
     • Programa binario: Es la ruta de acceso absoluta del proceso.
     • Argumentos: Son los argumentos proporcionados cuando se invoca el objeto binario del proceso.
     • Nombres de procesos: Es el nombre del proceso que se ejecuta en la instancia de VM asociada 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 hallazgo. Si VM Threat Detection no puede reconocer el kernel (por ejemplo, si el kernel está compilado de forma personalizada), no se propaga el campo processes del hallazgo.

   • Recurso afectado, en especial los siguientes campos:

     • Nombre completo del recurso: Es 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, haz clic en la pestaña JSON en la vista de detalles del resultado.

   • indicator
     • signatures:
       • memory_hash_signature: Es una firma que corresponde a los valores hash de las páginas de memoria.
       • detections
         • binary: Es el nombre del objeto binario de la aplicación de criptomoneda, por ejemplo, linux--x86-64_ethminer_0.19.0_alpha.0_cuda10.0.
         • percent_pages_matched: Es el porcentaje de páginas de la memoria que coinciden con las páginas de las aplicaciones de criptomoneda conocidas en la base de datos de hash de 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 hallazgo.

3. Revisa los registros en busca de signos de intrusión en la instancia de VM afectada. Por ejemplo, busca actividades sospechosas o desconocidas, y signos de credenciales vulneradas.

Paso 3: Revisa los permisos y la configuración

1. En la pestaña Resumen de los detalles de los resultados, en el campo Nombre completo del recurso, haz clic en el vínculo.
2. Revisa los detalles de la instancia de VM, incluida la configuración de red y acceso.

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

1. Revisa las entradas del framework de MITRE ATT&CK para 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 adecuado 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 la aplicación es una aplicación de minería:

   • Si el nombre del proceso y la ruta de acceso binaria de la aplicación detectada están disponibles, ten en cuenta los valores de las filas Program binary, Arguments y Process names en la pestaña Summary de los detalles del hallazgo en tu investigación.

   • Si los detalles del proceso no están disponibles, verifica si el nombre binario de la firma de hash de memoria puede proporcionar pistas. Considera un objeto binario llamado linux-x86-64_xmrig_2.14.1. Puedes usar el comando grep para buscar archivos notables en el almacenamiento. Usa una parte significativa del nombre 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 uso alto de CPU, para ver si hay alguno que no reconozcas. Determina si las aplicaciones asociadas son aplicaciones de minería.

   • Busca cadenas comunes que usen las aplicaciones de minería, como btc.com, ethminer, xmrig, cpuminer y randomx, en los archivos del almacenamiento. Para obtener más ejemplos de cadenas que puedes buscar, consulta Nombres de software y reglas de YARA y la documentación relacionada de cada software que se indica.

3. Si determinas que la aplicación es una aplicación de minería y su proceso aún se está ejecutando, finaliza el proceso. Busca el ejecutable binario 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 nueva.

Execution: Cryptocurrency Mining YARA Rule

VM Threat Detection detectó actividades de minería de criptomonedas a través de la coincidencia de patrones de memoria, como las constantes de prueba de trabajo, que el software de minería de criptomonedas usa.

Para responder a estos resultados, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre un hallazgo de Execution: Cryptocurrency Mining YARA Rule, como se indica en Revisa los resultados. Se abre el panel de detalles del hallazgo 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 regla de YARA: Es la regla que se activa para los detectores de YARA.
     • Programa binario: Es la ruta de acceso absoluta del proceso.
     • Argumentos: Son los argumentos proporcionados cuando se invoca el objeto binario del proceso.
     • Nombres de procesos: Es el nombre de los procesos que se ejecutan en la instancia de VM asociada 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 hallazgo. Si VM Threat Detection no puede reconocer el kernel (por ejemplo, si el kernel está compilado de forma personalizada), no se propaga el campo processes del hallazgo.

   • Recurso afectado, en especial los siguientes campos:

     • Nombre completo del recurso: Es el nombre completo del recurso de la instancia de VM afectada, incluido el ID del proyecto que la contiene.

   • Vínculos relacionados, en especial los siguientes campos:

     • URI de Cloud Logging: Es un vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: Es un vínculo a la documentación de MITRE ATT&CK.
     • Resultados relacionados: Vínculos a los resultados relacionados.
     • Indicador de VirusTotal: Es un vínculo a la página de análisis de VirusTotal.
     • Chronicle: Es un vínculo a Google SecOps.

3. Para ver el JSON completo de este resultado, haz clic en la pestaña JSON en la vista de detalles del resultado.

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

3. Revisa los registros en busca de signos de intrusión en la instancia de VM afectada. Por ejemplo, busca actividades sospechosas o desconocidas, y signos de credenciales vulneradas.

Paso 3: Revisa los permisos y la configuración

1. En la pestaña Resumen de los detalles de los resultados, en el campo Nombre completo del recurso, haz clic en el vínculo.
2. Revisa los detalles de la instancia de VM, incluida la configuración de red y acceso.

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

1. Revisa las entradas del framework de MITRE ATT&CK para 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 adecuado 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 la aplicación es una aplicación de minería:

   • Si el nombre del proceso y la ruta de acceso binaria de la aplicación detectada están disponibles, ten en cuenta los valores de las filas Program binary, Arguments y Process names en la pestaña Summary de los detalles del hallazgo en tu investigación.

   • Examina los procesos en ejecución, en especial los que tienen un uso alto de CPU, para ver si hay alguno que no reconozcas. Determina si las aplicaciones asociadas son aplicaciones de minería.

   • Busca cadenas comunes que usen las aplicaciones de minería, como btc.com, ethminer, xmrig, cpuminer y randomx, en los archivos del almacenamiento. Para obtener más ejemplos de cadenas que puedes buscar, consulta Nombres de software y reglas de YARA y la documentación relacionada de cada software que se indica.

3. Si determinas que la aplicación es una aplicación de minería y su proceso aún se está ejecutando, finaliza el proceso. Busca el ejecutable binario 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 nueva.

Execution: cryptocurrency mining combined detection

VM Threat Detection detectó varias categorías de resultados 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.

Para responder a un hallazgo combinado, sigue las instrucciones de respuesta para Execution: Cryptocurrency Mining YARA Rule y Execution: Cryptocurrency Mining Hash Match findings.

Malware: Malicious file on disk (YARA)

Virtual Machine Threat Detection detectó un archivo potencialmente malicioso a través del análisis de los discos persistentes de una VM en busca de firmas de software malicioso conocidas.

Para responder a estos resultados, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo de Malware: Malicious file on disk (YARA), como se indica en Revisa los resultados. Se abre el panel de detalles del hallazgo 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 regla de YARA: Es la regla de YARA que se encontró.
     • Files: El UUID de la partición y la ruta de acceso relativa del archivo potencialmente malicioso que se detectó.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: Es 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, haz clic en la pestaña JSON en la vista de detalles del resultado.

4. En el JSON, ten en cuenta los siguientes campos:

   • indicator
     • signatures:
       • yaraRuleSignature: Es una firma que corresponde a la regla de YARA que se encontró.

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

3. Revisa los registros en busca de signos de intrusión en la instancia de VM afectada. Por ejemplo, busca actividades sospechosas o desconocidas, y signos de credenciales vulneradas.

Paso 3: Revisa los permisos y la configuración

1. En la pestaña Resumen de los detalles de los resultados, en el campo Nombre completo del recurso, haz clic en el vínculo.
2. Revisa los detalles de la instancia de VM, incluida la configuración de red y acceso.

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

Para verificar el valor de hash SHA-256 del binario marcado como malicioso en VirusTotal, haz clic en el vínculo en el indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URLs, dominios y direcciones IP potencialmente maliciosos.

Paso 5: Implementa tu respuesta

El siguiente plan de respuesta podría ser adecuado 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.

1. Comunícate con el propietario de la VM.

2. Si es necesario, busca y borra el archivo potencialmente malicioso. Para obtener el UUID de la partición y la ruta de acceso relativa del archivo, consulta el campo Files en la pestaña Summary de los detalles del hallazgo. Para ayudar con la detección y la eliminación, usa una solución de detección y respuesta de extremos.

3. Si es necesario, detén la instancia comprometida y reemplázala por una nueva.

   Nota: Con el nivel Security Command Center Enterprise, también puedes realizar esta acción a través de una guía de respuesta a amenazas.

4. Para el análisis forense, considera crear una copia de seguridad de las máquinas virtuales y los discos persistentes. Para obtener más información, consulta Opciones de protección de datos en la documentación de Compute Engine.

5. Para realizar una investigación más exhaustiva, considera usar servicios de respuesta ante incidentes, como Mandiant.

Corrige vulnerabilidades relacionadas

Para evitar que se repitan amenazas, revisa y corrige los hallazgos de vulnerabilidades y parámetros de configuración incorrectos relacionados.

Para encontrar hallazgos relacionados, sigue estos pasos:

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

   Ir a hallazgos

2. Revisa el resultado de amenaza y copia el valor de un atributo que sea probable que aparezca en cualquier resultado de vulnerabilidad o configuración incorrecta relacionada, 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 filtros que se encuentra en el lado izquierdo del menú, selecciona la categoría que contiene el atributo que anotaste en el hallazgo de amenazas.

   Por ejemplo, si anotaste el nombre completo del recurso afectado, selecciona Recurso. Los tipos de atributos de la categoría Recurso se muestran en la columna de la derecha, incluido el atributo Nombre completo.

6. En los atributos que se muestran, selecciona el tipo de atributo que anotaste en el hallazgo de amenazas. A la derecha, se abre un panel de búsqueda de valores de atributos que muestra todos los valores encontrados del tipo de atributo seleccionado.

7. En el campo Filtro, pega el valor del atributo que copiaste del resultado de la 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 Aplicar. El panel Resultados de la búsqueda se actualiza para mostrar solo los hallazgos que coinciden.

9. Si hay muchos resultados, selecciónalos seleccionando filtros adicionales en el panel Filtros rápidos.

   Por ejemplo, para mostrar solo los hallazgos de las clases Vulnerability y Misconfiguration que contienen los valores de atributo seleccionados, desplázate hacia abajo hasta la sección Clase del resultado del panel Filtros rápidos y selecciona Vulnerabilidad y Parámetro de configuración incorrecto.

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 hallazgos de Event Threat Detection y Container Threat Detection no es tan fácil como corregir errores de configuración y 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?

• Consulta la descripción general de Event Threat Detection para obtener más información sobre el servicio y las amenazas que detecta.

• Consulta la descripción general de Container Threat Detection para obtener información sobre cómo funciona el servicio.

• Consulta la descripción general de VM Threat Detection para obtener más información sobre el servicio y las amenazas que detecta.