Investigar las amenazas y responder ante ellas

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

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

Antes de comenzar

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

Comprende los resultados de las amenazas

Event Threat Detection produce hallazgos de seguridad mediante la coincidencia de eventos en tu registro de Cloud Logging transmisiones a 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 identificando amenazas adversarias conocidas tácticas, técnicas y procedimientos en tu transmisión de registro y desviaciones del comportamiento anterior de tu organización o proyecto. Si activas Nivel Premium de Security Command Center a nivel de la organización, Event Threat Detection también pueden analizar tus registros de Google Workspace.

Container Threat Detection genera hallazgos recopilando y analizando el comportamiento observado de bajo nivel el kernel invitado de los contenedores.

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

Revisa los resultados

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

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

   Ir a hallazgos

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

   

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

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

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

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

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

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

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

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

Desactivación de hallazgos de amenazas

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

Para un falso positivo, considera dejar el estado del hallazgo como ACTIVE y, en su lugar, silenciará el hallazgo.

Para los falsos positivos persistentes o recurrentes, crea una regla de silencio. Configurar una regla de silencio puede reducir la cantidad de resultados que necesitas de gestionarlo, lo que facilita la identificación de una verdadera amenaza cuando se produce.

Si se trata de una amenaza real, antes de establecer el estado del hallazgo en INACTIVE, eliminar la amenaza y completar una investigación exhaustiva del amenaza detectada, el alcance de la intrusión y cualquier otro hallazgo relacionado y problemas.

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

• Cómo silenciar los resultados
• Cambia el estado de un resultado

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 módulos personalizados para Event Threat Detection, ya que tu organización define las acciones recomendadas para esos detectores.

Evasion: Access from Anonymizing Proxy

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

Para responder a estos resultados, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre un hallazgo Evasion: Access from Anonymizing Proxy, como se indica en Revisa los resultados. El panel para el hallazgo se abrirán los detalles, que muestra la pestaña Resumen.

2. En la pestaña Resumen del panel de detalles del hallazgo, revisa el valores que se enumeran en las siguientes secciones:

   • Qué se detectó, en especial los siguientes campos:
     • Correo electrónico principal: la cuenta que realizó los cambios (una posible cuenta hackeada).
     • IP: la dirección IP del proxy donde se realizan los cambios de la imagen de la que se originó.
   • Recurso afectado
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Vínculo a las entradas de Logging
     • Método MITRE ATT&CK: vínculo a la documentación de MITRE ATT&CK.
     • Hallazgos relacionados: vínculos a cualquier resultado relacionado.

3. De manera 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.

Breakglass Workload Deployment Created se detecta a través del análisis de los Registros de auditoría de Cloud para ver si hay implementaciones en cargas de trabajo que usen la marca de emergencia para anular Controles de Autorización Binaria

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo Defense Evasion: Breakglass Workload Deployment Created. como se indica en Revisa los resultados. El panel de Se abrirán los detalles de los resultados, que se mostrarán en la pestaña Resumen.

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

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

Paso 2: Comprueba los registros

1. En la pestaña Resumen de los detalles de los hallazgos, En la consola de Google Cloud, ve al Explorador de registros haciendo clic en el vínculo Campo URI de Cloud Logging.
2. Verifica el valor en el campo protoPayload.resourceName para identificar la una solicitud de firma de certificado específica.

3. Para verificar otras acciones que realizó la principal, utiliza lo siguiente 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 resultado.

   • 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 marco de trabajo MITRE ATT&CK para este tipo de hallazgo: Evasión de defensa: implementación de la carga de trabajo de anulación de emergencia.
2. Haz clic en el vínculo de Hallazgos relacionados para revisar los resultados relacionados. en la fila Resultados relacionados de la pestaña Resumen de la para encontrar detalles.
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.

Breakglass Workload Deployment Updated se detecta a través del análisis de 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 Controles de Autorización Binaria

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo Defense Evasion: Breakglass Workload Deployment Updated. como se indica en Revisa los resultados. El panel de Se abrirán los detalles de los resultados, que se mostrarán en la pestaña Resumen.

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

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

Paso 2: Comprueba los registros

1. En la pestaña Resumen de los detalles de los hallazgos, En la consola de Google Cloud, ve al Explorador de registros haciendo clic en el vínculo Campo URI de Cloud Logging.
2. Verifica el valor en el campo protoPayload.resourceName para identificar la una solicitud de firma de certificado específica.

3. Para verificar otras acciones que realizó la principal, utiliza lo siguiente 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 resultado.

   • 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 marco de trabajo MITRE ATT&CK para este tipo de hallazgo: Evasión de defensa: implementación de la carga de trabajo de anulación de emergencia.
2. Haz clic en el vínculo de Hallazgos relacionados para revisar los resultados relacionados. en la fila Resultados relacionados de la pestaña Resumen de la para encontrar detalles.
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ó manualmente una solicitud de firma de certificado (CSR). Los CSR son que un controlador de recolección de elementos no utilizados quita automáticamente, pero los agentes maliciosos podría eliminarlos manualmente para evadir la detección. Si la CSR borrada era para un 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 la asignatura que hayan incluido, pero puede tener muchos privilegios. Kubernetes no admite certificados y revocación de responsabilidades. Para obtener más detalles, consulta el mensaje de registro de esta alerta.

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

Defense Evasion: Modify VPC Service Control

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

Los registros de auditoría se examinan para detectar cambios en los perímetros de los Controles del servicio de VPC que reduciría 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 Defense Evasion: Modify VPC Service Control, como se indica en Revisión de los resultados. El panel para el hallazgo se abrirán los detalles, que 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: 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: Vínculo a las entradas de Logging
     • Método MITRE ATT&CK: vínculo a la documentación de MITRE ATT&CK.
     • Hallazgos relacionados: vínculos a cualquier resultado relacionado.

3. Haz clic en la pestaña JSON.

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

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

Paso 2: Comprueba los registros

1. En la pestaña Resumen (Summary) del panel de detalles de los hallazgos, haz clic en el Vínculo del URI de Cloud Logging para abrir el Explorador de registros.
2. Encuentra los registros de actividad del administrador relacionados con los cambios en 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. Haz clic en el vínculo de Hallazgos relacionados para revisar los resultados relacionados. en la fila Resultados relacionados de la pestaña Resumen de la para encontrar detalles.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 4: Implementa tu respuesta

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

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

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 nomenclatura similar a las cargas de trabajo predeterminadas. que GKE crea para el funcionamiento normal de clústeres. Esta técnica se denomina masquerading. Para obtener más detalles, el mensaje de registro de esta alerta.

1. Confirma que el Pod es legítimo.
2. Determinar si hay otros indicios de actividad maliciosa en el Pod o principal en los registros de auditoría en 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 es llevaron a cabo la acción.
4. Si la principal es una cuenta de servicio (IAM o Kubernetes), identificar la fuente de la acción para determinar su legitimidad.
5. Si el Pod no es legítimo, quítalo, junto con cualquier RBAC asociado. vinculaciones y cuentas de servicio que usó la carga de trabajo y que permitieron de la creación de cuentas de servicio.

Discovery: Can get sensitive Kubernetes object check

Un agente potencialmente malicioso trató de determinar en qué objetos sensibles había GKE que pueden 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. Abrir el hallazgo Discovery: Can get sensitive Kubernetes object check como se dirige en Cómo revisar los resultados.

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

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

Paso 2: Comprueba los registros

1. En la pestaña Resumen (Summary) del panel de detalles de los hallazgos, haz clic en el Vínculo del URI de Cloud Logging para abrir el Explorador de registros.

2. En la página que se carga, comprueba otras acciones realizadas por la principal usando 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 resultado.

   • 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 marco de MITRE ATT&CK para este tipo de hallazgo: Descubrimiento
2. Confirma la sensibilidad del objeto consultado y determina si hay y otros signos de actividad maliciosa por parte del principal en los registros.

3. Si la cuenta que anotaste en la fila Correo electrónico principal en la finding details no es una cuenta de servicio, comunícate con el propietario de la cuenta para confirmar si es llevaron a cabo 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 tu investigación con Investigación de 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 una shell inversa. Atacantes usar shells inversas para expandir o mantener su acceso inicial a un clúster y para ejecutar comandos arbitrarios. Para obtener más detalles, consulta el mensaje de registro de esta alerta.

1. Confirmar que el Pod tenga un motivo legítimo para especificar estos comandos argumentos.
2. Determinar si hay otros indicios de actividad maliciosa en el Pod o principal en los registros de auditoría en 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 es llevaron a cabo la acción.
4. Si la principal es una cuenta de servicio (IAM o Kubernetes), identificar la legitimidad de lo que causó que la cuenta de servicio realizara esta acción acción
5. Si el Pod no es legítimo, quítalo, junto con cualquier RBAC asociado. vinculaciones y cuentas de servicio que usó la carga de trabajo y que permitieron de la creación de cuentas de servicio.

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. Estos métodos son a veces se usan con fines legítimos de depuración. Sin embargo, kube-system namespace está destinado a objetos del sistema creados por Kubernetes y a los la ejecución del comando o la creación del shell. 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 esto era lo esperado. y la actividad de la cuenta principal.
2. Determinar si existen otros indicios de actividad maliciosa por parte del principal en los registros.

Revisa la guía sobre el uso del principio de privilegio mínimo para los roles de RBAC y los roles 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 un gravedad diferente:

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

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

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

2. En la pestaña Resumen del panel de detalles del hallazgo, revisa el 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 usa para robar los datos.
     • Fuentes de robo de datos: detalles sobre las tablas de las que provienen los datos fue exfiltrado.
     • Objetivos de robo de datos: Detalles sobre las tablas que se robaron de que se almacenaron los datos.
   • Recurso afectado:
     • Nombre completo del recurso: el nombre completo del recurso del proyecto. la carpeta u organización de la que se robaron los datos.
   • Vínculos relacionados:
     • URI de Cloud Logging: Vínculo a las entradas de Logging
     • Método MITRE ATT&CK: vínculo a la documentación de MITRE ATT&CK.
     • Hallazgos relacionados: vínculos a cualquier resultado relacionado.
     • Chronicle: Vínculo a Google SecOps.

3. Haz clic en la pestaña Propiedades de la fuente y revisa los campos que se muestran. especialmente:

   • detectionCategory:
     • subRuleName: Puede ser exfil_to_external_table o vpc_perimeter_violation
   • evidence:
     • sourceLogId:
       • projectId: Es el proyecto de Google Cloud que que contiene el conjunto de datos de origen de BigQuery.
   • properties
     • dataExfiltrationAttempt
       • jobLink: Es el vínculo al trabajo de BigQuery que los datos exfiltrados.
       • query: Es la consulta en SQL que se ejecuta en el conjunto de datos de BigQuery.

4. De manera opcional, haz clic en la pestaña JSON para ver la lista completa de Propiedades JSON del hallazgo

Paso 2: Investiga en Google Security Operations

Puedes usar Google Security Operations para investigar este problema hallazgo. Google SecOps es un servicio de Google Cloud que te permite investigar amenazas y recurrir a entidades relacionadas en una organización en el cronograma. Google SecOps enriquece los datos de los hallazgos, lo que te permite identificar los indicadores de interés y simplifican 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 completa con los hallazgos de Event Threat Detection.

4. En la tabla, en categoría, haz clic en un hallazgo de Exfiltration: BigQuery Data Exfiltration. El panel de detalles de se abre el hallazgo.

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

6. Sigue las instrucciones de la interfaz de usuario guiada de 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 de la buscando JSON.

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

Paso 4: Comprueba los registros

1. En la pestaña Resumen (Summary) del panel de detalles de los hallazgos, haz clic en el Vínculo del URI de Cloud Logging para abrir el Explorador de registros.

2. Encuentra registros de actividad del administrador relacionados con trabajos de BigQuery mediante los siguientes filtros:

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

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

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

Paso 6: Implementa tu respuesta

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

• 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 los conjuntos de datos afectados en busca de información sensible, usa Protección de datos sensibles. También puedes enviar Sensitive Data Protection to 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 lo siguiente: 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.

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

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre un hallazgo de Exfiltration: BigQuery Data Extraction, como se indica en Revisa los hallazgos. El panel de detalles del hallazgo se abrirá la pestaña Resumen.

2. En la pestaña Resumen del panel de detalles del hallazgo, revisa el valores que se enumeran en las siguientes secciones:

   • Qué se detectó:
     • Correo electrónico principal: Es la cuenta que se usa para robar los datos.
     • Fuentes de robo de datos: detalles sobre las tablas de las que provienen los datos fue exfiltrado.
     • Objetivos de robo de datos: Detalles sobre las tablas que se robaron de que se almacenaron los datos.
   • Recurso afectado:
     • Nombre completo del recurso: El nombre de la instancia de BigQuery recurso cuyos datos se robaron.
     • Nombre completo del proyecto: El proyecto de Google Cloud que que contiene el conjunto de datos de origen de BigQuery.
   • Vínculos relacionados:
     • URI de Cloud Logging: Vínculo a las entradas de Logging
     • Método MITRE ATT&CK: vínculo a la documentación de MITRE ATT&CK.
     • Hallazgos relacionados: vínculos a cualquier resultado relacionado.

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

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

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

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 de la para encontrar JSON (del paso 1).

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

Paso 3: Comprueba los registros

1. En la pestaña Resumen (Summary) del panel de detalles de los hallazgos, haz clic en el Vínculo del 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. Hacer clic en el vínculo para revisar los resultados relacionados en la fila Resultados relacionados de la pestaña Resumen de la para encontrar detalles. Los hallazgos relacionados son del mismo tipo de hallazgos en la misma instancia y red.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 5: Implementa tu respuesta

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

• Comunícate con el propietario del proyecto del cual se robaron datos.
• Considera revocar permisos. para la principal que aparece en la fila Correo electrónico principal en la La pestaña Resumen (Summary) de los detalles de los hallazgos hasta que se completa la investigación.
• Para detener los robos de datos, agregar políticas de IAM restrictivas a los conjuntos de datos de BigQuery afectados que se identifican en el campo Fuentes de robo de datos de la pestaña Resumen de la para encontrar detalles.
• Para analizar los conjuntos de datos afectados en busca de información sensible, usa Protección de datos sensibles. También puedes enviar Sensitive Data Protection to 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 lo siguiente: 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. Abrir un hallazgo Exfiltration: BigQuery Data to Google Drive, como se dirige en Cómo revisar los resultados.

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

   • Qué se detectó, incluido lo siguiente:
     • Correo electrónico principal: Es la cuenta que se usa para robar los datos.
     • Fuentes de robo de datos: detalles sobre BigQuery tabla de la que se robaron los datos.
     • Objetivos de robo de datos: Detalles sobre el destino en Google Drive
   • Recurso afectado, incluido lo siguiente:
     • Nombre completo del recurso: El nombre del recurso de BigQuery cuyos datos se exfiltrados.
     • Nombre completo del proyecto: El proyecto de Google Cloud que que contiene el conjunto de datos de origen de BigQuery.
   • Vínculos relacionados, entre ellos:
     • URI de Cloud Logging: Vínculo a las entradas de Logging
     • Método MITRE ATT&CK: vínculo a la documentación de MITRE ATT&CK.
     • Hallazgos relacionados: vínculos a cualquier resultado relacionado.

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

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

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

Paso 2: Revisa los permisos y la configuración

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

   Ir a IAM

2. Si es necesario, selecciona el proyecto que aparece en el campo projectId de la para encontrar JSON (del paso 1).

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

Paso 3: Comprueba los registros

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

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

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

Paso 5: Implementa tu respuesta

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

• 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 los conjuntos de datos afectados en busca de información sensible, usa Protección de datos sensibles. También puedes enviar Sensitive Data Protection to 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 lo siguiente: 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.

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

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre un resultado de Exfiltration: Cloud SQL Data Exfiltration, como se indica en Revisión de los resultados. El panel de detalles del de resultados se abre en la pestaña Resumen.

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

   • Qué se detectó, en especial los siguientes campos:
     • Correo electrónico principal : la cuenta utilizada para robar los datos.
     • Fuentes de robo de datos: detalles sobre Cloud SQL instancia cuyos datos se robaron.
     • Objetivos de robo de datos: detalles sobre Cloud Storage bucket al que se exportaron los datos.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: El nombre del recurso de Cloud SQL. cuyos datos fueron exfiltrados.
     • Nombre completo del proyecto: El proyecto de Google Cloud que contiene los datos de origen de Cloud SQL.
   • Vínculos relacionados, entre ellos:
     • URI de Cloud Logging: Vínculo a las entradas de Logging
     • Método MITRE ATT&CK: vínculo a la documentación de MITRE ATT&CK.
     • Hallazgos relacionados: vínculos a cualquier resultado relacionado.

3. Haz clic en la pestaña JSON.

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

   • sourceProperties:
     • evidence:
     • sourceLogId:
       • projectId: Es el proyecto de Google Cloud que 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: La cantidad de datos que se exportaron, por ejemplo: toda la instancia, una o más bases de datos, una o más tablas o un subconjunto especificado por una consulta)

Paso 2: Revisa los permisos y la configuración

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

   Ir a IAM

2. Si es necesario, selecciona el proyecto de la instancia que aparece en la Campo projectId en el hallazgo JSON (del paso 1).

3. En la página que aparece, ingresa la dirección de correo electrónico en el cuadro Filtro. que aparece en la fila Correo electrónico principal en la pestaña Resumen de la para buscar detalles (del Paso 1). Comprueba qué permisos se asignan a la cuenta.

Paso 3: Comprueba los registros

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

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 Hallazgos relacionados para revisar los resultados relacionados. que se describió en el Paso 1). Relacionados tienen el mismo tipo de resultado en la misma instancia de Cloud SQL instancia.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 5: Implementa tu respuesta

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

• Comunícate con el propietario del proyecto del cual se robaron datos.
• Considera revocar los permisos de access.principalEmail hasta que se complete la investigación.
• Para detener el robo de datos, agrega políticas de IAM restringidas a las instancias de Cloud SQL afectadas.
  • 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 examinando registros de auditoría para determinar si los datos de la copia de seguridad Instancia de Cloud SQL fuera de la organización o el proyecto. Todas Se admiten instancias de Cloud SQL y tipos de copias de seguridad.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre un resultado de Exfiltration: Cloud SQL Restore Backup to External Organization, como se indica en Revisa los resultados.

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

   • Qué se detectó, en especial los siguientes campos:
     • Correo electrónico principal: Es la cuenta que se usa para robar los datos.
     • Fuentes de robo de datos: detalles sobre la instancia de Cloud SQL en la que se creó la copia de seguridad.
     • Destinos de robo de datos: detalles sobre la instancia de Cloud SQL se restablecieron los datos de la copia de seguridad.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: el nombre del recurso de la copia de seguridad que se restaurado.
     • Nombre completo del proyecto: El proyecto de Google Cloud que contiene instancia de Cloud SQL desde la que se creó la copia de seguridad.

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

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

4. Haz clic en la pestaña JSON.

5. En JSON, ten en cuenta 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 que contiene el conjunto de datos de origen de BigQuery.
   • properties:
     • restoreToExternalInstance:
       • backupId: el ID de la ejecución de la copia de seguridad que se restableció

Paso 2: Revisa los permisos y la configuración

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

   Ir a IAM

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

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

Paso 3: Comprueba los registros

1. En la consola de Google Cloud, haz clic en el botón para ir al Explorador de registros. el vínculo en el URI de Cloud Logging (desde 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. Para revisar los resultados relacionados, haz clic en el vínculo de la fila Hallazgos relacionados. (desde Paso 1). Los resultados relacionados tienen el mismo tipo de resultado en la misma instancia de Cloud SQL.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 5: Implementa tu respuesta

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

• Comunícate con el propietario del proyecto del cual se robaron datos.
• Considera revocar los permisos de la principal. que aparece en la fila Correo electrónico principal en la pestaña Resumen de los detalles de los hallazgos 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 si todos los privilegios de una base de datos de PostgreSQL (o todos funciones o procedimientos en una base de datos) se otorgan a una o más bases de datos usuarios.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abrir Exfiltration: Cloud SQL Over-Privileged Grant hallazgo, como se indica en Revisa los resultados.

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

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

3. Para ver el JSON completo del hallazgo, haz clic en la pestaña JSON.

Paso 2: Revisa los privilegios de la base de datos

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

Paso 3: Comprueba los registros

1. En la consola de Google Cloud, haz clic en el botón para ir al Explorador de registros. el vínculo en el URI de Cloud Logging (desde 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 ejecutaste consultas 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 marco de trabajo MITRE ATT&CK para este tipo de hallazgo: Robo por Servicio Web.
2. Para determinar si se necesitan pasos de corrección adicionales, combina los resultados de tu investigación con los de MITRE en la investigación.

Paso 5: Implementa tu respuesta

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

• Comunícate con el propietario de la instancia que tenga otorgamientos con privilegios excesivos.
• Considera revocar todos los permisos para los beneficiarios que se indican en Beneficiarios de la base de datos hasta que finalice la investigación.
• Limitar el acceso a la base de datos (desde Database display name de Paso 1, revocar innecesaria permisos de los beneficiarios (de los beneficiarios de la base de datos de Paso 1:

Initial Access: Database Superuser Writes to User Tables

Detecta cuándo la cuenta de superusuario de la base de datos de Cloud SQL (postgres) para PostgreSQL y root para MySQL) escribe al usuario tablas. Por lo general, el superusuario (un rol con un acceso muy amplio) no debería ser que se usa 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, podría indicar que un atacante ha escalado privilegios o ha comprometido la usuario predeterminado de la base de datos y modifica los datos. También puede indicar que es normal, pero prácticas no seguras.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre un resultado de Initial Access: Database Superuser Writes to User Tables, como se indica en Revisa los resultados.

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

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

3. Para ver el JSON completo del hallazgo, 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. Revisa los registros de pgaudit de PostgreSQL o de la auditoría de Cloud SQL para MySQL registros, que contienen las consultas que ejecutó el superusuario, mediante los siguientes filtros:
   • protoPayload.request.user="SUPERUSER"

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

1. Revisa la entrada del marco de trabajo MITRE ATT&CK para este tipo de hallazgo: Robo por Servicio Web.
2. Para determinar si se necesitan pasos de corrección adicionales, combina los resultados de tu investigación con los de MITRE en la investigación.

Paso 4: Implementa tu respuesta

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

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

  • Para PostgreSQL, consulta Cómo crear y administrar usuarios
  • Para MySQL, consulta Administra usuarios con autenticación integrada

• Considera cambiar la contraseña del superusuario.

  • Para PostgreSQL, consulta Establece la contraseña para el usuario predeterminado
  • Para MySQL, consulta Establece la 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 Otorgar (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 cuándo un agente potencialmente malicioso usó uno de los siguientes objetos de Kubernetes usuarios o grupos de usuarios predeterminados para crear un nuevo recurso de Kubernetes en el clúster:

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

Estos usuarios y grupos son efectivamente anónimos. Un acceso basado en roles (RBAC) en tu clúster le otorgó permiso de usuario esos recursos en el clúster.

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

Para mitigar este problema, consulta Evita los roles y 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 cuándo un agente potencialmente malicioso usó uno de los siguientes objetos de Kubernetes usuarios o grupos de usuarios predeterminados para modificar un recurso de Kubernetes en el clúster:

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

Estos usuarios y grupos son efectivamente anónimos. Un acceso basado en roles de acceso (RBAC) en tu clúster, con el permiso de ese usuario para modificarla esos recursos en el clúster.

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

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

Initial Access: Dormant Service Account Action

Detecta eventos donde un servicio inactivo administrado por el usuario cuenta activó una acción. En este contexto, una cuenta de servicio es se considera inactivo si ha estado inactivo por más de 180 días.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abrir Initial Access: Dormant Service Account Action hallazgo, como se indica en Revisa los resultados.

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

   En Qué se detectó, haz lo siguiente:

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

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

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

Paso 3: Implementa tu respuesta

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

• Comunícate con el propietario del proyecto en el que se realizó la acción.
• Considera borrar la cuenta de servicio potencialmente comprometida, y rotarla y borrarla todas las claves de acceso de cuentas de servicio para el proyecto potencialmente comprometido. Después del la eliminación, las aplicaciones que usan la cuenta de servicio para la autenticación pierden el acceso a los datos. Antes de continuar, tu equipo de seguridad debe identificar todos los aplicaciones y trabajar con los propietarios de estas 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 a cualquier notificación del equipo de 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 donde un servicio inactivo administrado por el usuario account. En este contexto, una cuenta de servicio es se considera inactivo si ha estado inactivo por más de 180 días.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abrir Initial Access: Dormant Service Account Key Created hallazgo, como se indica en Revisa los resultados.

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

   En Qué se detectó, haz lo siguiente:

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

   En Recurso afectado, realiza lo siguiente:

   • Nombre visible del recurso: la clave de la cuenta de servicio inactiva recién creada
   • Nombre completo del proyecto: El proyecto en el que reside esa cuenta de servicio inactiva

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

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

Paso 3: Implementa tu respuesta

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

• Comunícate con el propietario del proyecto en el que se realizó la acción.
• Quita el acceso del propietario del correo electrónico principal si está comprometido.
• Invalida la clave de la cuenta de servicio recién creada en la Página de cuentas de servicio.
• Considera borrar la cuenta de servicio potencialmente comprometida, y rotarla y borrarla todas las claves de acceso de cuentas de servicio para el proyecto potencialmente comprometido. Después del la eliminación, las aplicaciones que usan la cuenta de servicio para la autenticación pierden el acceso a los datos. Antes de continuar, tu equipo de seguridad debe identificar todos los aplicaciones y trabajar con los propietarios de estas 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 a 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 los roles demasiado permisivos, usa IAM recomendador.

Initial Access: Leaked Service Account Key Used

Detecta eventos en los que se utiliza 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ó a la Internet pública. Por ejemplo, las claves de cuenta de servicio suelen publicado en un repositorio público de GitHub.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abrir Initial Access: Leaked Service Account Key Used hallazgo, como se indica en Revisa los resultados.

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

   En Qué se detectó, haz lo siguiente:

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

   En Recurso afectado, realiza lo siguiente:

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

Paso 2: Comprueba los registros

1. En la consola de Google Cloud, haz clic en el botón para ir al Explorador de registros. el vínculo en el URI de Cloud Logging.
2. En la barra de herramientas de la consola de Google Cloud, selecciona tu organización o proyecto.

3. En la página que se carga, busca los registros relacionados con el siguiente filtro:

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

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

Paso 3: Implementa tu respuesta

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

• Revoca la clave de la cuenta de servicio de inmediato en la Página de cuentas de servicio.
• Elimina la página web o el repositorio de GitHub en el que se publica la clave de la cuenta de servicio.
• Considera borrar la cuenta de servicio comprometida.
• Rota y borra todas las claves de acceso de las cuentas de servicio del proyecto potencialmente comprometido. Después del la eliminación, las aplicaciones que usan la cuenta de servicio para la autenticación pierden el acceso a los datos. Antes de borrar, tu equipo de seguridad debe identificar todos los afectados aplicaciones y trabajar con los propietarios de estas 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 a las notificaciones de Atención al cliente de Cloud.

Initial Access: Excessive Permission Denied Actions

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

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abrir Initial Access: Excessive Permission Denied Actions hallazgo, como se indica en Revisa los resultados.

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

   En Qué se detectó, haz lo siguiente:

   • Correo electrónico principal: La principal que activó varios errores de permisos denegados
   • Nombre del servicio: el nombre de la API del servicio de Google Cloud en el que se produjo el último error de permiso denegado
   • Nombre del método: Es el método al que se llamó cuando se produjo el último error de permiso denegado.

3. En los detalles de los hallazgos, en la pestaña Propiedades de la fuente, anota 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 ocurrió 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 botón para ir al Explorador de registros. el vínculo en el URI de Cloud Logging.
2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto.

3. En la página que se carga, busca los registros relacionados con el siguiente filtro:

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

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

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

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

Paso 4: Implementa tu respuesta

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

• Comunícate con el propietario de la cuenta en el campo Correo electrónico principal. Confirmar si el propietario legítimo realizó la acción.
• Borrar recursos del proyecto creados por esa cuenta, como los que no conoces Instancias de Compute Engine, instantáneas, cuentas de servicio, usuarios de IAM, etcétera.
• Comunicarse con el propietario del proyecto que tiene la cuenta y eliminarlo o inhabilitarlo la cuenta.

Brute Force: SSH

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

Paso 1: Revisa los detalles del hallazgo

1. Abre un hallazgo de Brute Force: SSH, como se indica en Revisa los hallazgos.

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

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

     • IP del llamador: la dirección IP que inició el ataque
     • Nombre de usuario: Es la cuenta con la que accediste.

   • Recurso afectado

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

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

3. Haz clic en la pestaña JSON.

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

   • sourceProperties:
     • evidence:
       • sourceLogId: Es 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 problema hallazgo. Google SecOps es un servicio de Google Cloud que te permite investigar amenazas y pasar por entidades relacionadas de una forma fácil de usar en el cronograma. Google SecOps enriquece los datos de los hallazgos, lo que te permite identificar los indicadores de interés y simplifican 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 del resultado, 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 botón para ir al Explorador de registros. el vínculo en el URI de Cloud Logging.
2. En la página que se carga, busca los registros de flujo de VPC relacionados con la IP. que aparece en la fila Correo electrónico principal de la Pestaña Resumen (Summary) 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 hallazgos relacionados, haz clic en el vínculo de Resultados relacionados en la fila Resultados relacionados, en la pestaña Resumen de los detalles de los hallazgos. Los hallazgos relacionados tienen el mismo tipo de resultado, y la misma instancia y red.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 6: Implementa tu respuesta

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

• Comunícate con el propietario del proyecto en el que se aplicó fuerza bruta de forma exitosa.
• Investiga la instancia potencialmente comprometida y quita cualquier software malicioso que se haya descubierto. Para ayudar con la detección y la eliminación, usa una solución de detección y respuesta de extremos.
• Considera inhabilitar el acceso SSH a la VM. Para información sobre la inhabilitación de claves SSH, consulta Restringir claves SSH de 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 activaciones a nivel de proyecto.

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

Paso 1: Revisa los detalles del hallazgo

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

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

   • Qué se detectó, en especial los siguientes campos:
     • Correo electrónico principal: la cuenta que realizó los cambios
   • Recurso afectado
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Vínculo a las entradas de Logging
     • Método MITRE ATT&CK: vínculo a la documentación de MITRE ATT&CK.
     • Hallazgos relacionados: vínculos a cualquier resultado relacionado.

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

4. En JSON, ten en cuenta 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 (Summary) del panel de detalles de los hallazgos, haz clic en el Vínculo del 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 manualmente una solicitud de firma de certificado (CSR), pero Falló la acción. Crear un certificado para la autenticación del clúster es un proceso método para que los atacantes creen acceso persistente a un clúster comprometido. El los permisos asociados con el certificado varían según el asunto al que incluidos, pero pueden tener muchos privilegios. Para obtener más detalles, consulta el mensaje de registro para esta alerta.

1. Revisar los registros de auditoría en Cloud Logging y las alertas adicionales para otros CSR eventos relacionados para determinar si se approved y se emitió alguna CSR acciones relacionadas son la actividad esperada de la principal.
2. Determinar si existen otros indicios de actividad maliciosa por parte del principal en los registros de auditoría en Cloud Logging. Por ejemplo:
   • ¿El director que intentó aprobar la CSR fue diferente del que ¿quién lo creó?
   • ¿La principal intentó solicitar, crear, aprobar o borrar? con otros CSRs?
3. Si no se esperaba la aprobación del CSR o se determina que es maliciosa, el clúster requerirá una rotación de credenciales para invalidar el certificado. Revisa la guía para realizar una rotación de las credenciales de tu 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ó manualmente una solicitud de firma de certificado (CSR). Creación de un para la autenticación de clústeres es un método común para que los atacantes crear acceso persistente a un clúster comprometido. Los permisos asociados con el certificado varían según la asignatura que hayan incluido, pero pueden con muchos privilegios. Para obtener más detalles, consulta el mensaje de registro de esta alerta.

1. Revisar los registros de auditoría en Cloud Logging y las alertas adicionales para otros CSR eventos relacionados para determinar si se espera que las acciones relacionadas con la CSR se realicen el principal.
2. Determinar si existen otros indicios de actividad maliciosa por parte del principal en los registros de auditoría en Cloud Logging. Por ejemplo:
   • ¿El director que aprobó la CSR era diferente del que creó ?
   • ¿La CSR especificó un firmante integrado, pero finalmente se tuvo que aprobado porque no cumplía con los criterios del firmante?
   • ¿La principal intentó solicitar, crear, aprobar o borrar? con otros CSRs?
3. Si no se esperaba una aprobación del CSR o se determina que es maliciosa, el clúster requerirá una rotación de credenciales para invalidar el certificado. Revisa la guía para realizar una rotación de las credenciales de tu clúster.

Credential Access: Privileged Group Opened To Public

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

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

Paso 1: Revisa los detalles del hallazgo

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

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

   • Qué se detectó, en especial los siguientes campos:
     • Correo electrónico principal: la cuenta que realizó los cambios, que podrían estar comprometidos.
   • Recurso afectado
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Vínculo a las entradas de Logging
     • Método MITRE ATT&CK: vínculo a la documentación de MITRE ATT&CK.
     • Hallazgos relacionados: vínculos a cualquier resultado relacionado.
   1. Haz clic en la pestaña JSON.
   2. En JSON, ten en cuenta 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 (Summary) del panel de detalles de los hallazgos, haz clic en el Vínculo del 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 los Pods de un Pod default cuenta de servicio de Kubernetes se usó para acceder a los objetos Secret del clúster. El Kubernetes default de servicio no debería tener acceso a los objetos Secret, a menos que otorgaste ese acceso con un objeto Role o un objeto 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. El panel de detalles del de resultados se abre en la pestaña Resumen.

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

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

Paso 2: Revisa los permisos del grupo

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

   Ir a IAM

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

3. Revisa las funciones sensibles otorgadas al grupo.

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

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

Paso 3: Comprueba los registros

1. En la pestaña Resumen (Summary) del panel de detalles de los hallazgos, haz clic en el Vínculo del 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. El panel de detalles del de resultados se abre en la pestaña Resumen.

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

   • Qué se detectó, en especial los siguientes campos:
     • IP de origen: la dirección IP de criptominería sospechosa.
     • Puerto de origen: el puerto de origen de la conexión, si está disponible.
     • IP de destino: la dirección IP de destino
     • Puerto de destino: el puerto de destino de la conexión, si disponibles.
     • Protocolo: IANA protocolo asociado a la conexión.
   • Recurso afectado
   • Vínculos relacionados, incluidos los siguientes campos:
     • URI de registro: Vínculo a las entradas de Logging.
     • Método MITRE ATT&CK: vínculo a la documentación de MITRE ATT&CK.
     • Hallazgos relacionados: vínculos a cualquier resultado relacionado.

3. En la vista detallada del hallazgo, haz clic en la pestaña Propiedades fuente.

4. Expande las propiedades y anota los valores de proyecto y de instancia en el siguiente campo:

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

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

5. Para ver el JSON completo del hallazgo, 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 apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

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

Initial Access: Log4j Compromise Attempt

Este resultado se genera cuando se detectan las 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 Initial Access: Log4j Compromise Attempt, como se indica en Revisar los detalles de los hallazgos. Los detalles del hallazgo se abre en la pestaña Resumen.

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

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

   • En JSON, ten en cuenta los siguientes campos.

   • properties

     • loadBalancerName: Es el nombre del balanceador de cargas que se recibió. la búsqueda de JNDI
     • requestUrl: es la URL de la solicitud HTTP. Si está presente, contiene una búsqueda 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 contiene una búsqueda de JNDI.

Paso 2: Comprueba los registros

1. En la consola de Google Cloud, haz clic en el botón para ir al Explorador de registros. el vínculo en el campo URI de Cloud Logging 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. Haz clic en el vínculo de Hallazgos relacionados para revisar los resultados relacionados. en la fila Resultados relacionados de la pestaña Resumen de la para encontrar detalles. Los resultados relacionados son del mismo tipo y el misma instancia y red.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 4: Implementa tu respuesta

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

• Actualiza a la última versión de Log4j2.
• Sigue las recomendaciones de Google Cloud para investigar y responder al “Apache Log4j 2” vulnerabilidad.
• Implementar las técnicas de mitigación recomendadas en Vulnerabilidades de seguridad de Apache Log4j.
• 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 Regla de WAF de Google Cloud Armor para 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. Los detalles del hallazgo se abre en la pestaña Resumen.

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

   • Qué se detectó
   • Recurso afectado, en especial el siguiente campo:
     • Nombre completo del recurso: 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: Vínculo a las entradas de Logging
     • Método MITRE ATT&CK: vínculo a la documentación de MITRE ATT&CK.
     • Hallazgos relacionados: vínculos a cualquier resultado relacionado.

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

4. En JSON, ten en cuenta 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. en la nube.

Paso 2: Comprueba los registros

1. En la consola de Google Cloud, haz clic en el botón para ir al Explorador de registros. el vínculo en el campo URI de Cloud Logging 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. Haz clic en el vínculo de Hallazgos relacionados para revisar los resultados relacionados. en la fila Resultados relacionados de la pestaña Resumen de la para encontrar detalles. Los hallazgos relacionados tienen el mismo tipo de resultado, y la misma instancia y red.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 4: Implementa tu respuesta

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

• Actualiza a la última versión de Log4j2.
• Sigue las recomendaciones de Google Cloud para investigar y responder al “Apache Log4j 2” vulnerabilidad.
• Implementar las técnicas de mitigación recomendadas en Vulnerabilidades de seguridad de Apache Log4j.
• 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 Regla de WAF de Google Cloud Armor para mitigar la vulnerabilidad de Apache Log4j.

Leaked credentials

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

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

Paso 1: Revisa los detalles del hallazgo

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

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

• Qué se detectó
• Recurso afectado

1. Haz clic en la pestaña Propiedades de la fuente y observa los siguientes campos:

   • Compromised_account: la cuenta de servicio potencialmente comprometida
   • Project_identifier: el proyecto que contiene las credenciales de la cuenta que se podrían filtrar
   • URL: el vínculo al repositorio de GitHub

2. Para ver el JSON completo del hallazgo, haz clic en la pestaña JSON.

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

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

   Ir a IAM

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

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

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

   Ir a Cuentas de servicio

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

Paso 3: Comprueba los registros

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

   Ir al Explorador de registros

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

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

   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • resource.type="gce_instance" AND log_name="projects/Project_identifier/logs/cloudaudit.googleapis.com%2Factivity"
   • protoPayload.methodName="InsertProjectOwnershipInvite"
   • protoPayload.authenticationInfo.principalEmail="Compromised_account"

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

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

Paso 5: Implementa tu respuesta

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

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

Malware

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

Los siguientes pasos describen cómo investigar y responder a 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 la hallazgo de Malware: Bad IP, como se indica en Revisa los resultados. El panel de detalles del de resultados se abre en la pestaña Resumen.

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

   • Qué se detectó, en especial los siguientes campos:
     • Dominio del indicador: para los resultados de Bad domain, el dominio que que activó el hallazgo.
     • IP del indicador: para los resultados de Bad IP, la dirección IP que que activó el hallazgo.
     • IP de origen: para los resultados de Bad IP, un comando de software malicioso conocido y controlar la dirección IP.
     • Puerto de origen: para los hallazgos de Bad IP, el puerto de origen del conexión.
     • IP de destino: para los resultados de Bad IP, la dirección IP de destino del software malicioso.
     • Puerto de destino: para los hallazgos de Bad IP, el puerto de destino de la conexión.
     • Protocolo: para los resultados de Bad IP, el Protocolo IANA número asociado con la conexión.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: el nombre completo del recurso del afectado instancia de Compute Engine.
     • Nombre completo del proyecto: el nombre completo del recurso del proyecto que contiene el hallazgo.
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Vínculo a las entradas de Logging
     • Método MITRE ATT&CK: vínculo a la documentación de MITRE ATT&CK.
     • Hallazgos relacionados: vínculos a cualquier resultado relacionado.
     • Chronicle: Vínculo a Google SecOps.
     • Indicador de VirusTotal: Vínculo a la página de análisis de VirusTotal.

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

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

Paso 2: Investiga en Google Security Operations

Puedes usar Google Security Operations para investigar este problema hallazgo. Google SecOps es un servicio de Google Cloud que te permite investigar amenazas y pasar por entidades relacionadas de una forma fácil de usar en el cronograma. Google SecOps enriquece los datos de los hallazgos, lo que te permite identificar los indicadores de interés y simplifican 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 el hallazgo Malware: Bad IP. Se abrirá el panel de detalles de los hallazgos.

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

6. Sigue las instrucciones de la interfaz de usuario guiada de 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 coincida 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 (Summary) del panel de detalles de los hallazgos, haz clic en el Vínculo del URI de Cloud Logging para abrir el Explorador de registros.

2. En la página que se carga, busca los registros de flujo de VPC relacionados con la IP. en IP de origen con 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 mediante la selección del proyecto en la lista en projectId.
     • SOURCE_IP por la dirección IP que aparece en La fila IP de origen en la pestaña Resumen de los detalles de los hallazgos.

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

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

Paso 6: Implementa tu respuesta

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

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

Malware: Outgoing DoS

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

Paso 1: Revisa los detalles del hallazgo

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

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

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

Paso 2: Revisa los permisos y la configuración

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

   Ir al panel

2. Selecciona el proyecto que se especifica en sourceInstanceDetails

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

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

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

Paso 3: Comprueba los registros

1. En la pestaña Resumen (Summary) del panel de detalles de los hallazgos, haz clic en el Vínculo del URI de Cloud Logging para abrir el Explorador de registros.

2. En la página que se carga, busca los registros de flujo de VPC relacionados con la IP. dirección en srcIP con el siguiente filtro:

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

     Reemplaza lo siguiente:

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

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

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

Paso 5: Implementa tu respuesta

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

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

Persistence: IAM Anomalous Grant

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

Los siguientes son ejemplos de otorgamientos anómalos:

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

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

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

• external_service_account_added_to_policy:
  • HIGH, si se otorgó un rol muy sensible o si tiene una sensibilidad media el rol de IAM a nivel de la organización. Para obtener más información, consulta Roles muy sensibles.
  • MEDIUM, si se otorgó un rol de sensibilidad media Para obtener más información, ver Roles de sensibilidad media.
• external_member_invited_to_policy: HIGH
• external_member_added_to_policy:
  • HIGH, si se otorgó un rol muy sensible o si tiene una sensibilidad media el rol de IAM a nivel de la organización. Para obtener más información, consulta Roles muy sensibles.
  • MEDIUM, si se otorgó un rol de sensibilidad media Para obtener más información, ver 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. El panel de detalles del de resultados se abre en la pestaña Resumen.

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

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

   • Recurso afectado

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

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

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

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

   • detectionCategory:
     • subRuleName: información más específica sobre el tipo de otorgamiento anómalo que ocurrió. La subregla determina la gravedad clasificación de este hallazgo.
   • evidence:
     • sourceLogId:
     • projectId: Es el ID del proyecto que contiene el hallazgo.
   • properties:
     • sensitiveRoleGrant:
       • bindingDeltas:
       • Action: Es la acción que realiza el usuario.
       • Role: Es la función asignada 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 problema hallazgo. Google SecOps es un servicio de Google Cloud que te permite investigar amenazas y pasar por entidades relacionadas de una forma fácil de usar en el cronograma. Google SecOps enriquece los datos de los hallazgos, lo que te permite identificar los indicadores de interés y simplifican las investigaciones.

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

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

   Ir a hallazgos

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

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

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

4. En la tabla, en categoría, haz clic en un hallazgo de Persistence: IAM Anomalous Grant. El panel de detalles de se abre.

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

6. Sigue las instrucciones de la interfaz de usuario guiada de 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 (Summary) del panel de detalles de los hallazgos, haz clic en el Vínculo del 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 marco de MITRE ATT&CK para este tipo de hallazgo: Cuentas válidas: Cuentas de Cloud.
2. Haz clic en el vínculo de Hallazgos relacionados para revisar los resultados relacionados. en la pestaña Resumen de los detalles de los resultados. Los resultados relacionados son el mismo tipo de resultado y la misma instancia y la red.
3. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 5: Implementa tu respuesta

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

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

Persistence: Impersonation Role Granted for Dormant Service Account

Detecta eventos en los que se otorga un rol de suplantación de identidad a una principal que permite a la principal para que actúe como un servicio inactivo administrado por el usuario cuenta de servicio. En este hallazgo, la cuenta de servicio inactiva es recurso, y una cuenta de servicio se considera inactiva si tiene ha estado inactiva durante más de 180 días.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abrir Persistence: Impersonation Role Granted for Dormant Service Account hallazgo, como se indica en Revisa los resultados.

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

   En Qué se detectó, haz lo siguiente:

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

   En Recurso afectado, realiza lo siguiente:

   • Nombre visible del recurso: la cuenta de servicio inactiva como recurso
   • Nombre completo del proyecto: El proyecto en el que reside esa cuenta de servicio inactiva

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

1. Usar la cuenta de servicio de desarrollo de software, como Actividad Analizador, 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 de los hallazgos, en Vínculos relacionados Haz clic en el vínculo URI de Cloud Logging para abrir el Explorador de registros.

Paso 4: Implementa tu respuesta

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

• Comunícate con el propietario del proyecto en el que se realizó la acción.
• Quita el acceso del propietario del correo electrónico principal si está comprometido.
• Quita el rol de suplantación de identidad otorgado recientemente al miembro objetivo.
• Considera borrar la cuenta de servicio potencialmente comprometida, y rotarla y borrarla todas las claves de acceso de cuentas de servicio para el proyecto potencialmente comprometido. Después del la eliminación, las aplicaciones que usan la cuenta de servicio para la autenticación pierden el acceso a los datos. Antes de continuar, tu equipo de seguridad debe identificar todos los aplicaciones y trabajar con los propietarios de estas 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 a 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 los roles demasiado permisivos, usa IAM recomendador.

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 abandonó la empresa, el administrador no puede eliminar la cuenta. Por lo tanto, otorgar roles sensibles a cuentas no administradas crea un riesgo de seguridad para la organización.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abrir Persistence: Unmanaged Account Granted Sensitive Role hallazgo, como se indica en Revisa los resultados.

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

   En Qué se detectó, haz lo siguiente:

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

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

1. Comunícate con el propietario del campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.
2. Verifica con el propietario del campo Ofensa de permisos de acceso.Nombre principal, comprender el origen de la cuenta no administrada.

Paso 3: Comprueba los registros

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

Paso 4: Implementa tu respuesta

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

• Comunícate con el propietario del proyecto en el que se realizó la acción.
• Quita el acceso del propietario del correo electrónico principal si está comprometido.
• Quita el rol sensible recién otorgado de la cuenta no administrada.
• Considera convertir la cuenta no administrada en una cuenta administrada con la Herramienta para transferir. y mover esta cuenta bajo el control de los administradores del sistema.

Persistence: New API Method

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

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

Paso 1: Revisa los detalles del hallazgo

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

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

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

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

1. Revisa las entradas del marco de trabajo MITRE ATT&CK para este tipo de hallazgo: 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 del recurso y la cuenta se muestra en la fila Correo electrónico principal.
3. Para desarrollar un plan de respuesta, combina los resultados de tu investigación con la investigación de MITRE.

Persistence: New Geography

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

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

Paso 1: Revisa los detalles del hallazgo

1. Abre un hallazgo Persistence: New Geography, como se indica en Revisamos los detalles de los hallazgos antes de esta . El panel de detalles para el hallazgo se abre en la pestaña Resumen.

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

• Qué se detectó, en especial los siguientes campos:
  • Correo electrónico principal: La cuenta de usuario potencialmente hackeada.
• Recurso afectado, en especial los siguientes campos:
  • Nombre completo del proyecto: El proyecto que contiene el cuenta de usuario hackeada.
• Vínculos relacionados, en especial los siguientes campos:
  • URI de Cloud Logging: Vínculo a las entradas de Logging
  • Método MITRE ATT&CK: vínculo a la documentación de MITRE ATT&CK.
  • Hallazgos relacionados: vínculos a cualquier resultado relacionado.

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

2. En JSON, ten en cuenta los siguientes campos sourceProperties:

   • affectedResources:
     • gcpResourceName: el recurso afectado
   • evidence:
     • sourceLogId:
     • projectId: El ID del proyecto que contiene el resultado.
   • properties:
     • anomalousLocation:
     • anomalousLocation: Es la ubicación actual estimada del usuario.
     • callerIp: Es la dirección IP externa.
     • notSeenInLast: Es el período que se usa para establecer un modelo de referencia para comportamiento normal.
     • typicalGeolocations: Son las ubicaciones a las que el usuario suele acceder. 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 de la buscando JSON.

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

Paso 3: Comprueba los registros

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

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

1. Revisa la entrada del marco de trabajo 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 apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

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

Persistence: New User Agent

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

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

Paso 1: Revisa los detalles del hallazgo

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

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

   • Qué se detectó, en especial los siguientes campos:
     • Correo electrónico principal: La cuenta de servicio potencialmente comprometida.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del proyecto: El proyecto que contiene el cuenta de servicio comprometida.
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Vínculo a las entradas de Logging
     • Método MITRE ATT&CK: vínculo a la documentación de MITRE ATT&CK.
     • Hallazgos relacionados: vínculos a cualquier resultado relacionado.
   1. En la vista de detalles del hallazgo, haz clic en la pestaña JSON.
   2. En JSON, ten en cuenta los siguientes campos.
   • projectId: El proyecto que contiene el proyecto posiblemente comprometido cuenta de servicio.
   • 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 la normalidad. de tu modelo.

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, ingresa el nombre de la cuenta en el cuadro Filtro. que aparece en la fila Correo electrónico principal en la pestaña Resumen de los detalles de los hallazgos 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, ingresa el nombre de la cuenta en el cuadro Filtro. que aparece en la fila Correo electrónico principal en la pestaña Resumen de los detalles del hallazgo.

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

Paso 3: Comprueba los registros

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

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

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

Paso 5: Implementa tu respuesta

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

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

Privilege Escalation: Changes to sensitive Kubernetes RBAC objects

Para elevar privilegios, un agente potencialmente malicioso trató de modificar una Acceso según el rol de ClusterRole, RoleBinding o ClusterRoleBinding objeto de control (RBAC) del cluster-admin sensible rol con una solicitud PUT o PATCH.

Paso 1: Revisa los detalles del hallazgo

1. Abrir Privilege Escalation: Changes to sensitive Kubernetes RBAC objects hallazgo, como se indica en Cómo revisar los resultados. El panel de detalles para el hallazgo se abre en la pestaña Resumen.

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

   • Qué se detectó, en especial los siguientes campos:
     • Correo electrónico principal: la cuenta que realizó la llamada
     • Nombre del método: Es el método que se llamó.
     • Vinculaciones de Kubernetes: los atributos sensibles enlace o ClusterRoleBinding que se modificó.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre visible del recurso: El clúster de Kubernetes en el que se realizó la acción para determinar si se produjo un error.
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Vínculo a las entradas de Logging
     • Método MITRE ATT&CK: vínculo a la documentación de MITRE ATT&CK.
     • Hallazgos relacionados: vínculos a cualquier resultado relacionado.

3. En la sección Qué se detectó, haz clic en el nombre de la vinculación. en la fila de Vinculaciones de Kubernetes. Se muestran los detalles de la vinculación.

4. En la vinculación que se muestra, observa los detalles de vinculación.

Paso 2: Comprueba los registros

1. En la pestaña Resumen de los detalles de los hallazgos, En la consola de Google Cloud, ve al Explorador de registros haciendo clic en el vínculo Campo URI de Cloud Logging.

2. Si el valor en Method name era un método PATCH, verifica la solicitud. body para ver qué propiedades se modificaron.

   En las llamadas update (PUT), el objeto completo se envía en el para que los cambios no sean tan claros.

3. Para verificar otras acciones que realizó la principal, utiliza lo siguiente 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 resultado.

   • 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 marco de MITRE ATT&CK para este tipo de hallazgo: Elevación de privilegios
2. Confirma la sensibilidad del objeto y si la modificación está justificada.
3. En el caso de las vinculaciones, puedes verificar el sujeto e investigar si necesita el rol al que está vinculado.
4. Determinar si existen otros indicios de actividad maliciosa por parte del principal en los registros.

5. Si el correo electrónico principal no es de servicio, comunícate con el propietario de la cuenta para confirmar si si el propietario legítimo realizó la acción.

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

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

Privilege Escalation: Create Kubernetes CSR for master cert

Para elevar privilegios, un agente potencialmente malicioso creó una instancia principal de Kubernetes solicitud de firma de certificado (CSR), lo que les da cluster-admin el acceso a los datos.

Paso 1: Revisa los detalles del hallazgo

1. Abrir Privilege Escalation: Create Kubernetes CSR for master cert hallazgo, como se indica en Cómo revisar los resultados. El panel de detalles del de resultados se abre en la pestaña Resumen.

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

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

Paso 2: Comprueba los registros

1. En la pestaña Resumen de los detalles de los hallazgos, En la consola de Google Cloud, ve al Explorador de registros haciendo clic en el vínculo Campo URI de Cloud Logging.
2. Verifica el valor en el campo protoPayload.resourceName para identificar la una solicitud de firma de certificado específica.

3. Para verificar otras acciones que realizó la principal, utiliza lo siguiente 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 resultado.

   • 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 marco de MITRE ATT&CK para este tipo de hallazgo: Elevación de privilegios.
2. Investiga si se justifica otorgar el acceso a cluster-admin.

3. Si el correo electrónico principal no es de servicio, comunícate con el propietario de la cuenta para confirmar si 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 tu investigación con Investigación de MITRE.

Privilege Escalation: Creation of sensitive Kubernetes bindings

Para elevar privilegios, un agente potencialmente malicioso trató de crear un nuevo Objeto RoleBinding o ClusterRoleBinding para cluster-admin en el área de la seguridad en la nube.

Paso 1: Revisa los detalles del hallazgo

1. Abrir Privilege Escalation: Creation of sensitive Kubernetes bindings hallazgo, como se indica en Cómo revisar los resultados. El panel de detalles para el hallazgo se abre en la pestaña Resumen.

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

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

Paso 2: Comprueba los registros

1. En la pestaña Resumen de los detalles de los hallazgos, En la consola de Google Cloud, ve al Explorador de registros haciendo clic en el vínculo Campo URI de Cloud Logging.

2. Para verificar otras acciones que realizó la principal, utiliza lo siguiente 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 resultado.

   • 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 marco de MITRE ATT&CK para este tipo de hallazgo: Elevación de privilegios.
2. Confirma la sensibilidad de la vinculación creada y si los roles son necesarios para los sujetos.
3. En el caso de las vinculaciones, puedes verificar el sujeto e investigar si necesita el rol al que está vinculado.
4. Determinar si existen otros indicios de actividad maliciosa por parte del principal en los registros.

5. Si el correo electrónico principal no es de servicio, comunícate con el propietario de la cuenta para confirmar si 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 tu investigación con Investigación de 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 efectivamente anónimos y deberían evitarse cuando crear vinculaciones de roles o del clúster a cualquier rol de RBAC. Revisa el la vinculación para garantizar que sea necesario. Si la vinculación no es necesaria, quita que la modifica. Para obtener más detalles, consulta el mensaje de registro de este resultado.

1. Revisa las vinculaciones creadas que otorgaron permisos Usuario de system:anonymous, system:unauthenticated group o Grupo system:authenticated.
2. Determinar si existen otros indicios de actividad maliciosa por parte del principal en los registros de auditoría en Cloud Logging.

Si hay indicios de actividad maliciosa, revisa la guía para investigar y quitar las vinculaciones que permitieron este acceso.

Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials

Para elevar privilegios, un agente potencialmente malicioso solicitó un certificado Authorization request (CSR), con el comando kubectl, con 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. Abrir Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials hallazgo, como se indica en Cómo revisar los resultados. El panel de detalles para el hallazgo se abre en la pestaña Resumen.

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

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

Paso 2: Comprueba los registros

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

1. En la pestaña Resumen de los detalles de los hallazgos, En la consola de Google Cloud, ve al Explorador de registros haciendo clic en el vínculo Campo URI de Cloud Logging.
2. Verifica el valor en el campo protoPayload.resourceName para identificar la una solicitud de firma de certificado específica.

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

1. Revisa las entradas del marco de MITRE ATT&CK para este tipo de hallazgo: Elevación de privilegios.
2. Si la CSR específica se encuentra disponible en el una entrada de registro, investiga la sensibilidad certificado y si la acción estaba justificada.
3. Para desarrollar un plan de respuesta, combina los resultados de tu investigación con Investigación de MITRE.

Privilege Escalation: Launch of privileged Kubernetes container

Un agente potencialmente malicioso creó un Pod que contiene contenedores 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 la El campo allowPrivilegeEscalation se estableció en true. Para ver más consulta la documentación de referencia de SecurityContext Referencia de la API v1 core en la documentación de Kubernetes.

Paso 1: Revisa los detalles del hallazgo

1. Abrir Privilege Escalation: Launch of privileged Kubernetes container hallazgo, como se indica en Cómo revisar los resultados. El panel de detalles para el hallazgo se abre en la pestaña Resumen.

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

   • Qué se detectó, en especial los siguientes campos:
     • Correo electrónico principal: la cuenta que realizó la llamada
     • Pods de Kubernetes: El pod recién creado con contenedores con privilegios
   • Recurso afectado, en especial los siguientes campos:
     • Nombre visible del recurso: El clúster de Kubernetes en el que se realizó la acción para determinar si se produjo un error.
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Vínculo a las entradas de Logging
     • Método MITRE ATT&CK: vínculo a la documentación de MITRE ATT&CK.
     • Hallazgos relacionados: vínculos a cualquier resultado relacionado.

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

   • findings.kubernetes.pods[].containers: el contenedor con privilegios convertido en el Pod.

Paso 2: Comprueba los registros

1. En la pestaña Resumen de los detalles de los hallazgos, En la consola de Google Cloud, ve al Explorador de registros haciendo clic en el vínculo Campo URI de Cloud Logging.

2. Para verificar otras acciones que realizó la principal, utiliza lo siguiente 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 resultado.

   • 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 marco de MITRE ATT&CK para este tipo de hallazgo: Elevación de privilegios.
2. Confirma que el contenedor que se creó requiere acceso a los recursos del host y kernel.
3. Determinar si existen otros indicios de actividad maliciosa por parte del principal en los registros.

4. Si el correo electrónico principal no es un servicio comunícate con el propietario de la cuenta para confirmar si el propietario 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 tu investigación con Investigación de MITRE.

Privilege Escalation: Dormant Service Account Granted Sensitive Role

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

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abrir Privilege Escalation: Dormant Service Account Granted Sensitive Role hallazgo, como se indica en Revisa los resultados.

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

   En Qué se detectó, haz lo siguiente:

   • Correo electrónico principal: El usuario que realizó la acción de otorgamiento
   • Otorgamiento de acceso infractor.Nombre principal: La cuenta de servicio inactiva que recibió el rol sensible
   • Otorgamiento de acceso infractor. Función otorgada: El rol de IAM sensible que se asigna.

   En Recurso afectado, realiza 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. Usar la cuenta de servicio de desarrollo de software, como Actividad Analizador, 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 de los hallazgos, en Vínculos relacionados Haz clic en el vínculo URI de Cloud Logging para abrir el Explorador de registros.

Paso 4: Implementa tu respuesta

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

• Comunícate con el propietario del proyecto en el que se realizó la acción.
• Quita el acceso del propietario del correo electrónico principal si está comprometido.
• Quita el rol sensible de IAM recién asignado de la cuenta de servicio inactiva.
• Considera borrar la cuenta de servicio potencialmente comprometida, y rotarla y borrarla todas las claves de acceso de cuentas de servicio para el proyecto potencialmente comprometido. Después del eliminación, los recursos que usan la cuenta de servicio para la autenticación pierden el acceso a los datos. Antes de continuar, tu equipo de seguridad debe identificar todos los y trabaja 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 a 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 los roles demasiado permisivos, usa IAM recomendador.

Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity

El robo de identidad anómalo de la cuenta de servicio se detecta examinando el administrador Registros de auditoría de actividad para ver si ocurrió alguna anomalía en una cuenta de servicio de identidad.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

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

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

   • Qué se detectó, en especial los siguientes campos:
     • Correo electrónico principal: la cuenta de servicio final en la suplantación de identidad que se usó para acceder a Google Cloud.
     • Nombre del servicio: El nombre de la API del servicio de Google Cloud involucrado en la solicitud de suplantación de identidad.
     • Nombre del método: Es el método que se llamó.
     • Información de delegación de cuentas de servicio: Los detalles de las cuentas de servicio en la de la cadena de delegación, el principal al final de la lista es el llamador de la solicitud de suplantación.
   • 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: Vínculo a las entradas de Logging
     • Método MITRE ATT&CK: vínculo a la documentación de MITRE ATT&CK.
     • Hallazgos relacionados: vínculos a cualquier resultado relacionado.

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

1. Comunícate con el propietario de la cuenta de servicio en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.
2. Investiga los principales de la cadena de delegación para verificar si es anormal y si alguna cuenta fue vulnerada.
3. Comunícate con el propietario de la persona que realizó la llamada de suplantación de identidad en la Cuenta de servicio información de delegación. Confirma si el propietario legítimo realizó acción.

Paso 3: Implementa tu respuesta

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

• Comunícate con el propietario del proyecto en el que se realizó la acción.
• Considera borrar la cuenta de servicio potencialmente comprometida, y rotarla y borrarla todas las claves de acceso de cuentas de servicio para el proyecto potencialmente comprometido. Después del eliminación, los recursos que usan la cuenta de servicio para la autenticación pierden el acceso a los datos. Antes de continuar, tu equipo de seguridad debe identificar todos los y trabaja 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 a cualquier notificación del equipo de 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 demasiado permisivos, usa el recomendador de IAM.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity

Anomalous Multistep Service Account Delegation se detecta examinando el archivo Registros de auditoría de actividad del administrador, para ver si ocurrió alguna anomalía en una cuenta de servicio de identidad.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

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

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

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

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

1. Comunícate con el propietario de la cuenta de servicio en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.
2. Investiga los principales de la cadena de delegación para verificar si es anormal y si alguna cuenta fue vulnerada.
3. Comunícate con el propietario de la persona que realizó la llamada de suplantación de identidad en la Cuenta de servicio información de delegación. Confirma si el propietario legítimo realizó acción.

Paso 3: Implementa tu respuesta

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

• Comunícate con el propietario del proyecto en el que se realizó la acción.
• Considera borrar la cuenta de servicio potencialmente comprometida, y rotarla y borrarla todas las claves de acceso de cuentas de servicio para el proyecto potencialmente comprometido. Después del eliminación, los recursos que usan la cuenta de servicio para la autenticación pierden el acceso a los datos. Antes de continuar, tu equipo de seguridad debe identificar todos los y trabaja 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 a cualquier notificación del equipo de 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 demasiado permisivos, usa el recomendador de IAM.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access

Anomalous Multistep Service Account Delegation se detecta examinando los datos Acceder a los registros de auditoría para ver si ocurrió alguna anomalía en una cuenta de servicio de identidad.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

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

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

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

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

1. Comunícate con el propietario de la cuenta de servicio en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.
2. Investiga los principales de la cadena de delegación para verificar si es anormal y si alguna cuenta fue vulnerada.
3. Comunícate con el propietario de la persona que realizó la llamada de suplantación de identidad en la Cuenta de servicio información de delegación. Confirma si el propietario legítimo realizó acción.

Paso 3: Implementa tu respuesta

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

• Comunícate con el propietario del proyecto en el que se realizó la acción.
• Considera borrar la cuenta de servicio potencialmente comprometida, y rotarla y borrarla todas las claves de acceso de cuentas de servicio para el proyecto potencialmente comprometido. Después del eliminación, los recursos que usan la cuenta de servicio para la autenticación pierden el acceso a los datos. Antes de continuar, tu equipo de seguridad debe identificar todos los y trabaja 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 a cualquier notificación del equipo de 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 demasiado permisivos, usa el recomendador de IAM.

Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity

Anomalous Service Account Impersonator se detecta examinando el panel de administración Registros de auditoría de actividad para ver si ocurrió alguna anomalía en una cuenta de servicio de identidad.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

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

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

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

     • Correo electrónico principal: la cuenta de servicio final en la suplantación de identidad solicitud que se usó para acceder a Google Cloud
     • Nombre del servicio: el nombre de la API del servicio de Google Cloud involucrado en la solicitud de suplantación de identidad
     • Nombre del método: Es el método que se llamó.
     • Información de delegación de cuentas de servicio: Los detalles de las cuentas de servicio en la de la cadena de delegación, el principal al final de la lista es el llamador de la solicitud de suplantación

   • Recurso afectado

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

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

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

1. Comunícate con el propietario de la cuenta de servicio en el campo Correo electrónico principal. Confirma si el propietario legítimo realizó la acción.
2. Investiga los principales de la cadena de delegación para verificar si es anormal y si alguna cuenta fue vulnerada.
3. Comunícate con el propietario de la persona que realizó la llamada de suplantación de identidad en la Cuenta de servicio información de delegación. Confirma si el propietario legítimo realizó acción.

Paso 3: Implementa tu respuesta

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

• Comunícate con el propietario del proyecto en el que se realizó la acción.
• Considera borrar la cuenta de servicio potencialmente comprometida, y rotarla y borrarla todas las claves de acceso de cuentas de servicio para el proyecto potencialmente comprometido. Después del eliminación, los recursos que usan la cuenta de servicio para la autenticación pierden el acceso a los datos. Antes de continuar, tu equipo de seguridad debe identificar todos los y trabaja 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 a cualquier notificación del equipo de 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 demasiado permisivos, usa el recomendador de IAM.

Privilege Escalation: Anomalous Service Account Impersonator for Data Access

La suplantación de identidad de cuenta de servicio anómala se detecta a través del análisis del Registros de auditoría para ver si se produjo alguna anomalía en la suplantación de identidad de una cuenta de servicio para cada solicitud.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abierta Privilege Escalation: Anomalous Service Account Impersonator for Data Access hallazgo, como se indica en Revisa los resultados.

2. En los detalles de los hallazgos, en la pestaña Resumen, anota los siguientes valores: .

   En Qué se detectó, haz lo siguiente:

   • Correo electrónico principal: la cuenta de servicio final en la suplantación de identidad solicitud que se usó para acceder a Google Cloud
   • Nombre del servicio: el nombre de la API del servicio de Google Cloud involucrado en la solicitud de suplantación de identidad
   • Nombre del método: Es el método que se llamó.
   • Información de delegación de cuentas de servicio: Los detalles de las cuentas de servicio en la de la cadena de delegación, el principal al final de la lista es el llamador de la solicitud de suplantación

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 es anormal y si alguna cuenta fue vulnerada.
3. Comunícate con el propietario de la persona que realizó la llamada de suplantación de identidad en la Cuenta de servicio información de delegación. Confirma si el propietario legítimo realizó acción.

Paso 3: Implementa tu respuesta

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

• Comunícate con el propietario del proyecto en el que se realizó la acción.
• Considera borrar la cuenta de servicio potencialmente comprometida, y rotarla y borrarla todas las claves de acceso de cuentas de servicio para el proyecto potencialmente comprometido. Después del eliminación, los recursos que usan la cuenta de servicio para la autenticación pierden el acceso a los datos. Antes de continuar, tu equipo de seguridad debe identificar todos los y trabaja 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 a cualquier notificación del equipo de 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 demasiado permisivos, 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 bind, escalate o Verbos impersonate. Un sujeto vinculado a un rol con estos verbos puede suplantar la identidad de otros usuarios con mayores privilegios y vincularse a Role adicionales o ClusterRole que contengan permisos adicionales, o que modifiquen los suyos Permisos ClusterRole. Esto podría llevar a que esos sujetos cluster-admin privilegios. Para obtener más detalles, consulta el mensaje de registro de esta alerta.

1. Revisa el ClusterRole y el ClusterRoleBindings asociado para comprobar si los sujetos realmente requieren estos permisos.
2. Si es posible, evita crear roles que involucren bind, escalate o impersonate verbos.
3. Determinar si existen otros indicios de actividad maliciosa por parte del principal en los registros de auditoría en Cloud Logging.
4. Cuando asignes permisos en un rol de RBAC, usa el principio de los y otorga los permisos mínimos necesarios para realizar una tarea. Usando el principio de privilegio mínimo reduce las posibilidades de si el clúster está comprometido y reduce la probabilidad de que un acceso excesivo provoca 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 valor predeterminado ClusterRole de system:controller:clusterrole-aggregation-controller. Esta el ClusterRole predeterminado tiene el verbo escalate, que permite a los sujetos modificar los privilegios de sus propias funciones, lo que permite la elevación de privilegios. Para ver más detalles, consulta el mensaje de registro de esta alerta.

1. Revisa cualquier ClusterRoleBinding que haga referencia a ClusterRole de system:controller:clusterrole-aggregation-controller.
2. Revisa las modificaciones que se hayan realizado en el system:controller:clusterrole-aggregation-controller (ClusterRole).
3. Determinar si existen otros indicios de actividad maliciosa por parte del principal que creó el ClusterRoleBinding en los registros de auditoría en 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 nomenclatura similar a las herramientas comunes que se usan para de escapes de contenedores o ejecutar otros ataques en el clúster. Para obtener más detalles, el mensaje de registro de esta alerta.

1. Confirma que el Pod es legítimo.
2. Determinar si hay otros indicios de actividad maliciosa en el Pod o principal en los registros de auditoría en 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 es llevaron a cabo la acción.
4. Si la principal es una cuenta de servicio (IAM o Kubernetes), identificar la fuente de la acción para determinar su legitimidad.
5. Si el Pod no es legítimo, quítalo, junto con cualquier RBAC asociado. vinculaciones y cuentas de servicio que usó la carga de trabajo y que permitieron de la creación de cuentas de servicio.

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 sensible en el sistema de archivos del nodo host. Acceso a estas rutas de acceso en el host se puede usar para acceder a información confidencial o confidencial y para escapes de contenedores. Si es posible, no permitas ningún volumen de hostPath. en tu clúster. Para obtener más detalles, consulta el mensaje de registro de esta alerta.

1. Revisa la carga de trabajo a fin de determinar si este volumen hostPath es necesario para la funcionalidad prevista. Si es así, asegúrate de que la ruta sea la más directorio específico posible. Por ejemplo, /etc/myapp/myfiles en lugar de /. o /etc.
2. Determina si hay otros indicios de actividad maliciosa relacionados con esto de los registros de auditoría en 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 los 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 procesos de Linux. Esta podría permitir que un contenedor no confiable o comprometido derive los privilegios el acceso a las variables de entorno, la memoria y otros datos datos de procesos que se ejecutan en otros contenedores. Algunas cargas de trabajo pueden requerir esta funcionalidad para operar por razones legítimas, como el manejo de registros contenedores de sidecar o contenedores de depuración. Para obtener más detalles, consulta el registro para esta alerta.

1. Confirmar que la carga de trabajo realmente requiera acceso a un proceso compartido espacio de nombres para todos los contenedores en la carga de trabajo.
2. Comprueba si hay otros indicios de actividad maliciosa por parte del principal en los registros de auditoría en 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), identificar la legitimidad de lo que causó que la cuenta de servicio realizara esta acción 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 resultado de Discovery: Service Account Self-Investigation, como se indica en la sección Revisa los detalles de los hallazgos, que se encuentra más arriba, . El panel de detalles para el hallazgo se abre en la pestaña Resumen.

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

   • Qué se detectó, en especial los siguientes campos:
     • Gravedad: el nivel de riesgo asignado al hallazgo. La gravedad es HIGH si la llamada a la API que activó este hallazgo sin autorización, la cuenta de servicio no tiene permiso para consultar sus propios permisos de IAM con el API de projects.getIamPolicy.
     • Correo electrónico principal: La cuenta de servicio potencialmente comprometida.
     • IP del llamador: la dirección IP interna o externa
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso:
     • Nombre completo del proyecto: El proyecto que contiene la posible filtración las credenciales de tu cuenta.
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Vínculo a las entradas de Logging
     • Método MITRE ATT&CK: vínculo a la documentación de MITRE ATT&CK.
     • Hallazgos relacionados: vínculos a cualquier resultado relacionado.
   1. Para ver el JSON completo del hallazgo, 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 de la buscando JSON.

3. En la página que aparece, ingresa el nombre de la cuenta en el cuadro Filtro. aparecen 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 (Summary) del panel de detalles de los hallazgos, haz clic en el Vínculo del URI de Cloud Logging para abrir el Explorador de registros.
2. Si es necesario, selecciona tu proyecto.
3. En la página que se carga, usa los siguientes filtros para verificar los registros en busca de actividad de los recursos de IAM nuevos o actualizados:
   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

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

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

Paso 5: Implementa tu respuesta

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

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

Inhibit System Recovery: Deleted Google Cloud Backup and DR host

Event Threat Detection examina los registros de auditoría para detectar la eliminación de hosts que no 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 que están asociadas al host.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abrir Inhibit System Recovery: Deleted Google Cloud Backup and DR host hallazgo, como se detalla en Revisa los resultados. El panel de detalles para el hallazgo se abre en la pestaña Resumen.
2. En la pestaña Resumen, revisa la información de las siguientes secciones:
   • Qué se detectó, en especial los siguientes campos:
     • Nombre de la aplicación: el nombre de una base de datos o VM conectada a una copia de seguridad y a DR
     • Nombre de host: Es el nombre de un host conectado a la copia de seguridad y DR.
     • Sujeto principal: Un usuario que ejecutó una acción correctamente.
   • Recurso afectado
     • Nombre visible del recurso: El proyecto en el que se borró el host.
   • Vínculos relacionados, en especial los siguientes campos:
     • Método MITRE ATTACK: Vínculo a la documentación de MITRE ATT&CK
     • URI de registro: 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 apropiado para este hallazgo. Con cuidado evaluar la información que recopilas en tu investigación para determinar la mejor manera de resolver los hallazgos.

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

Inhibit System Recovery: Google Cloud Backup and DR remove plan

Security Command Center examina los registros de auditoría para detectar la eliminación anómala de un Plan de copias de seguridad del Servicio de copia de seguridad y DR que se usa para aplicar políticas de este tipo a una aplicación.

Paso 1: Revisa los detalles del hallazgo

1. Abrir Inhibit System Recovery: Google Cloud Backup and DR remove plan hallazgo, como se detalla en Revisa los resultados. Los detalles del hallazgo se abre en la pestaña Resumen.
2. En la pestaña Resumen, revisa la información de las siguientes secciones:
   • Qué se detectó, en especial los siguientes campos:
     • Nombre de la aplicación: el nombre de una base de datos o VM conectada a una copia de seguridad y a DR
     • Nombre del perfil: Especifica el destino de almacenamiento para las copias de seguridad de los datos de aplicaciones y de 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: 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 registro: 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 apropiado para este hallazgo. Con cuidado evaluar la información recopilada durante la investigación para determinar la mejor forma de resolver los hallazgos.

1. En el proyecto en el que se realizó la acción, navega a la consola de administración.
2. En la pestaña Administrador de aplicaciones, busca las aplicaciones afectadas que ya no están disponibles. y revisar las políticas de copias de seguridad para cada uno.

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 un plantilla. Una plantilla es una configuración base para las copias de seguridad que se pueden aplicar múltiples aplicaciones.

Paso 1: Revisa los detalles del hallazgo

1. Abrir Inhibit System Recovery: Google Cloud Backup and DR delete template hallazgo, como se detalla en Revisa los resultados. Los detalles del hallazgo se abre en la pestaña Resumen.
2. En la pestaña Resumen, revisa la información de las siguientes secciones:
   • Qué se detectó, en especial los siguientes campos:
     • Nombre de la plantilla: 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.
     • Sujeto principal: Un usuario que ejecutó una acción correctamente.
   • Recurso afectado
     • Nombre visible del recurso: el proyecto en el que se borró la plantilla
   • Vínculos relacionados, en especial los siguientes campos:
     • Método MITRE ATTACK: Vínculo a la documentación de MITRE ATT&CK
     • URI de registro: 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 apropiado para este hallazgo. Con cuidado evaluar la información recopilada durante la investigación para determinar la mejor forma de resolver los hallazgos.

1. En el proyecto en el que se realizó la acción, navega a consola de administración.
2. En la pestaña Administrador de aplicaciones, busca las aplicaciones afectadas que ya no están disponibles. y revisar las políticas de copias de seguridad para cada uno.
3. Para volver a agregar una plantilla, navega a la pestaña Planes de creación de copias de seguridad, selecciona Templates, luego selecciona la opción Crear Plantilla.

Inhibit System Recovery: Google Cloud Backup and DR delete policy

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

Paso 1: Revisa los detalles del hallazgo

1. Abrir Inhibit System Recovery: Google Cloud Backup and DR delete policy hallazgo, como se detalla en Revisa los resultados. Los detalles del hallazgo se abre en la pestaña Resumen.
2. En la pestaña Resumen, revisa la información de las siguientes secciones:
   • Qué se detectó, en especial los siguientes campos:
     • Nombre de la política: Es el nombre de una sola política, que define la copia de seguridad. la frecuencia, el programa y el tiempo de retención
     • Sujeto principal: Un usuario que ejecutó una acción correctamente.
   • Recurso afectado
     • Nombre visible del recurso: El proyecto en el que se borró la política
   • Vínculos relacionados, en especial los siguientes campos:
     • Método MITRE ATTACK: Vínculo a la documentación de MITRE ATT&CK
     • URI de registro: 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 apropiado para este hallazgo. Evalúa con cuidado la información recopilada durante tu investigación para determinar la mejor manera de resolver los hallazgos. 1. En el proyecto en el que se realizó la acción, navega a la consola de administración. 2. En la pestaña Administrador de aplicaciones, selecciona la aplicación afectada y revisa la configuración de la Política aplicada a esa aplicación.

Inhibit System Recovery: Google Cloud Backup and DR delete profile

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

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo Inhibit System Recovery: Google Cloud Backup and DR delete profile, como se detalla en Revisa los resultados. El panel de detalles para el hallazgo se abre en la pestaña Resumen.
2. En la pestaña Resumen, revisa la información de las siguientes secciones:
   • Qué se detectó, en especial los siguientes campos:
     • Nombre del perfil: Especifica el destino de almacenamiento para las copias de seguridad de los datos de aplicaciones y de VM.
     • Sujeto principal: Un usuario que ejecutó una acción correctamente.
   • Recurso afectado
     • Nombre visible del recurso: El proyecto en el que se borró el perfil.
   • Vínculos relacionados, en especial los siguientes campos:
     • Método MITRE ATTACK: Vínculo a la documentación de MITRE ATT&CK
     • URI de registro: 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 apropiado para este hallazgo. Evalúa con cuidado la información recopilada durante tu investigación para determinar la mejor manera de resolver los hallazgos. 1. En el proyecto en el que se realizó la acción, navega a la consola de administración. 2. En la pestaña Backup Plans, selecciona Profiles para ver una lista de todos los perfiles. 3. Revisa los perfiles para verificar que todos los perfiles obligatorios estén en su lugar. 4. Si el perfil borrado se quitó por error, selecciona Crear perfil para definir los objetivos 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 la copia de seguridad y la DR.

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo Inhibit System Recovery: Google Cloud Backup and DR delete storage pool, como se detalla en Revisa los resultados. El panel de detalles para el hallazgo se abre en la pestaña Resumen.
2. En la pestaña Resumen, revisa la información de las siguientes secciones:
   • Qué se detectó, en especial los siguientes campos:
     • Nombre del grupo de almacenamiento: Es el nombre de los buckets de almacenamiento en los que se almacenan las copias de seguridad.
     • Sujeto principal: Un usuario que ejecutó una acción correctamente.
   • Recurso afectado
     • Nombre visible del recurso: El proyecto en el que se borró el grupo de almacenamiento.
   • Vínculos relacionados, en especial los siguientes campos:
     • Método MITRE ATTACK: Vínculo a la documentación de MITRE ATT&CK
     • URI de registro: 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 apropiado para este hallazgo. Evalúa con cuidado la información recopilada durante tu investigación para determinar la mejor manera de resolver los hallazgos. 1. En el proyecto en el que se realizó la acción, navega a la consola de administración. 2. En la pestaña Administrar, selecciona Grupos de almacenamiento para ver una lista de todos los grupos de almacenamiento. 3. Revisa las asociaciones de los grupos de almacenamiento con dispositivos de copia de seguridad. 4. Si un dispositivo activo no tiene un grupo de almacenamiento asociado, selecciona Agregar grupo OnVault para volver a agregarlo.

Data Destruction: Google Cloud Backup and DR expire image

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

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo Inhibit System Recovery: Google Cloud Backup and DR expire image, como se detalla en Revisa los resultados. El panel de detalles para el hallazgo se abre en la pestaña Resumen.
2. En la pestaña Resumen, revisa la información de las siguientes secciones:
   • Qué se detectó, en especial los siguientes campos:
     • Nombre de la política: El nombre de una sola política, que define la frecuencia, el programa y el tiempo de retención de la copia 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 aplicaciones y de VM.
     • Sujeto principal: Un usuario que ejecutó una acción correctamente.
   • Recurso afectado
     • Nombre visible del recurso: El proyecto en el que se borró la imagen de copia de seguridad
   • Vínculos relacionados, en especial los siguientes campos:
     • Método MITRE ATTACK: Vínculo a la documentación de MITRE ATT&CK
     • URI de registro: 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 apropiado para este hallazgo. Evalúa con cuidado la información recopilada durante tu investigación para determinar la mejor manera de resolver los hallazgos. 1. En el proyecto en el que se realizó la acción, navega a la consola de administración. 2. Navega a la pestaña Supervisar y selecciona Trabajos para revisar el estado del trabajo de eliminación de la copia de seguridad. 3. Si un trabajo de eliminación no está autorizado, navega a los permisos de IAM para revisar a los usuarios que tienen acceso a los datos de la copia de seguridad.

Data Destruction: Google Cloud Backup and DR expire all images

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

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo Inhibit System Recovery: Google Cloud Backup and DR expire all images, como se detalla en Revisa los resultados. El panel de detalles para el hallazgo se abre en la pestaña Resumen.
2. En la pestaña Resumen, revisa la información de las siguientes secciones:
   • Qué se detectó, en especial los siguientes campos:
     • Nombre de la política: El nombre de una sola política, que define la frecuencia, el programa y el tiempo de retención de la copia 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 aplicaciones y de VM.
     • Sujeto principal: Un usuario que ejecutó una acción correctamente.
   • Recurso afectado
     • Nombre visible del recurso: El proyecto en el que se borraron las imágenes de copia de seguridad
   • Vínculos relacionados, en especial los siguientes campos:
     • Método MITRE ATTACK: Vínculo a la documentación de MITRE ATT&CK
     • URI de registro: 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 apropiado para este hallazgo. Evalúa con cuidado la información recopilada durante tu investigación para determinar la mejor manera de resolver los hallazgos. 1. En el proyecto en el que se realizó la acción, navega a la consola de administración. 2. Navega a la pestaña Supervisar y selecciona Trabajos para revisar el estado del trabajo de eliminación de la copia de seguridad. 3. Si un trabajo de eliminación no está autorizado, navega a los permisos de IAM para revisar a los usuarios que tienen acceso a los datos de la copia de seguridad.

Data Destruction: Google Cloud Backup and DR remove appliance

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

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo Inhibit System Recovery: Google Cloud Backup and DR remove appliance, como se detalla en Revisa los resultados. El panel de detalles para el hallazgo se abre en la pestaña Resumen.
2. En la pestaña Resumen, revisa la información de las siguientes secciones:
   • Qué se detectó, en especial los siguientes campos:
     • Nombre del dispositivo: El nombre de una base de datos o VM conectada a copia de seguridad y DR
     • Sujeto principal: Un usuario que ejecutó una acción correctamente.
   • Recurso afectado
     • Nombre visible del recurso: El proyecto en el que se borró el dispositivo
   • Vínculos relacionados, en especial los siguientes campos:
     • Método MITRE ATTACK: Vínculo a la documentación de MITRE ATT&CK
     • URI de registro: 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 apropiado para este hallazgo. Evalúa con cuidado la información recopilada durante tu investigación para determinar la mejor manera de resolver los hallazgos. 1. En el proyecto en el que se realizó la acción, navega a la consola de administración. 2. En la pestaña Administrador de aplicaciones, 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 desprotegidas, navega a Copia de seguridad y DR en la consola de Google Cloud y selecciona la opción Implementar otro dispositivo de copia de seguridad o recuperación. 4. En el menú Almacenamiento, configure cada dispositivo nuevo con un objetivo de almacenamiento. Después de configurar un dispositivo, aparece como opción cuando creas un perfil para tus aplicaciones.

Impact: Google Cloud Backup and DR reduced backup expiration

Event Threat Detection examina los registros de auditoría para detectar si la fecha de vencimiento para una copia de seguridad en un dispositivo de servicio de copia de seguridad y DR.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abrir Impact: Google Cloud Backup and DR reduced backup expiration hallazgo, como se detalla en Revisa los resultados. El 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 se completó correctamente ejecutó una acción
   • Recurso afectado
     • Nombre visible del recurso: El proyecto en el que se vence el vencimiento de la copia de seguridad se redujo.
   • Vínculos relacionados, en especial los siguientes campos:
     • Método MITRE ATTACK: Vínculo a la documentación de MITRE ATT&CK.
     • URI de registro: 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 apropiado para este hallazgo. Con cuidado evaluar la información recopilada durante la investigación para determinar la mejor forma de resolver los hallazgos.

1. En el proyecto en el que se realizó la acción, navega a la consola de administración.
2. En la pestaña App Manager, busca la aplicación afectada para la cual se creó la copia de seguridad. se redujo la fecha de vencimiento y verificarás que la fecha de vencimiento fue prevista por principal.
3. Para iniciar una nueva copia de seguridad de la aplicación, selecciona Administra los parámetros de configuración de copia de seguridad para crear una copia de seguridad a pedido o en programar una copia de seguridad nueva.

Impact: Google Cloud Backup and DR reduced backup frequency

Event Threat Detection examina los registros de auditoría para detectar si el plan de copias de seguridad tiene para reducir la frecuencia de las copias de seguridad.

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abrir Impact: Google Cloud Backup and DR reduced backup frequency hallazgo, como se detalla en Revisa los resultados. El 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 se completó correctamente ejecutó una acción
   • Recurso afectado
     • Nombre visible del recurso: El proyecto en el que la frecuencia de la copia de seguridad se redujo.
   • Vínculos relacionados, en especial los siguientes campos:
     • Método MITRE ATTACK: Vínculo a la documentación de MITRE ATT&CK.
     • URI de registro: 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 apropiado para este hallazgo. Con cuidado evaluar la información recopilada durante la investigación para determinar la mejor forma de resolver los hallazgos.

1. En el proyecto en el que se realizó la acción, navega a la consola de administración.
2. En la pestaña App Manager, busca la aplicación afectada para la cual se creó la copia de seguridad. se redujo la frecuencia y verificar que el cambio fue intencional principal.
3. Para iniciar una nueva copia de seguridad de la aplicación, selecciona Administra los parámetros de configuración de copia de seguridad para crear una copia de seguridad a pedido o en programar una copia de seguridad 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 nomenclatura similar a la de criptomonedas comunes. mineros de monedas. Este puede ser el intento de un atacante que logró acceso al clúster para usar sus recursos en 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. Determinar si hay otros indicios de actividad maliciosa en el Pod o principal en los registros de auditoría en 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 es llevaron a cabo la acción.
4. Si la principal es una cuenta de servicio (IAM o Kubernetes), identificar la fuente de la acción para determinar su legitimidad.
5. Si el Pod no es legítimo, quítalo, junto con cualquier RBAC asociado. vinculaciones y cuentas de servicio que usó la carga de trabajo y que permitieron de la creación de cuentas de servicio.

Lateral Movement: Modified Boot Disk Attached to Instance

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

Paso 1: Revisa los detalles del hallazgo

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

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

   En Qué se detectó, haz lo siguiente:

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

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

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

Paso 3: Implementa tu respuesta

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

• Comunícate con el propietario del proyecto en el que se realizó la acción.
• Considera usar Inicio seguro para tus Instancias de VM de Compute Engine.
• Considera borrar la cuenta de servicio potencialmente comprometida, y rotarla y borrarla todas las claves de acceso de cuentas de servicio para el proyecto potencialmente comprometido. Después del la eliminación, las aplicaciones que usan la cuenta de servicio para la autenticación pierden el acceso a los datos. Antes de continuar, tu equipo de seguridad debe identificar todos los aplicaciones y trabajar con los propietarios de estas 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 a cualquier notificación del equipo de asistencia de Google Cloud.

Privilege Escalation: AlloyDB Over-Privileged Grant

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

Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abrir Privilege Escalation: AlloyDB Over-Privileged Grant hallazgo, como se indica en Revisa los resultados.

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

   • Qué se detectó, en especial los siguientes campos:
     • Nombre visible de la base de datos: El nombre de la base de datos en la Instancia de AlloyDB para PostgreSQL afectada.
     • Nombre de usuario de la base de datos: el usuario de PostgreSQL que otorgó privilegios excesivos.
     • Consulta de base de datos: la consulta de PostgreSQL ejecutada que otorgó el privilegios.
     • Beneficiarios de la base de datos: Son los beneficiarios de los privilegios demasiado amplios.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: Es el nombre del recurso de AlloyDB para PostgreSQL. que se vio afectada.
     • Nombre completo superior: Es el nombre del recurso de AlloyDB para PostgreSQL. instancia.
     • Nombre completo del proyecto: 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: Vínculo a las entradas de Logging
     • Método MITRE ATT&CK: vínculo a la documentación de MITRE ATT&CK.

3. Para ver el JSON completo del hallazgo, haz clic en la pestaña JSON.

Paso 2: Revisa los privilegios de la base de datos

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

Paso 3: Comprueba los registros

1. En la consola de Google Cloud, haz clic en el botón para ir al Explorador de registros. el vínculo en el URI de Cloud Logging (desde 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 ejecutaste consultas 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 marco de trabajo MITRE ATT&CK para este tipo de hallazgo: Robo por Servicio Web.
2. Para determinar si se necesitan pasos de corrección adicionales, combina los resultados de tu investigación con los de MITRE en la investigación.

Paso 5: Implementa tu respuesta

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

• Comunícate con el propietario de la instancia que tenga otorgamientos con privilegios excesivos.
• Considera revocar todos los permisos para los beneficiarios que se indican en Beneficiarios de la base de datos hasta que finalice la investigación.
• Limitar el acceso a la base de datos (desde Database display name de Paso 1, revocar innecesaria permisos de los beneficiarios (de los beneficiarios de la base de datos de Paso 1:

Privilege Escalation: AlloyDB Database Superuser Writes to User Tables

Detecta cuándo la cuenta de superusuario de la base de datos de AlloyDB para PostgreSQL (postgres) escribe en tablas de usuarios. Por lo general, el superusuario (un rol con un acceso muy amplio) no debe usarse para escribir en tablas de usuarios. Una cuenta de usuario con acceso más limitado debe usarse para actividades diarias normales. Cuando un superusuario escribe a un usuario que podría indicar que un atacante tiene privilegios escalados o tiene ha comprometido al usuario predeterminado de la base de datos y modifica los datos. También podría indican 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 del hallazgo, revisa el información en las siguientes secciones:

   • Qué se detectó, en especial los siguientes campos:
     • Nombre visible de la base de datos: El nombre de la base de datos en la Instancia de AlloyDB para PostgreSQL afectada.
     • Nombre de usuario de la base de datos: el superusuario.
     • Consulta de base de datos: la consulta en SQL que se ejecutaba mientras se escribe en las tablas de usuarios.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: Es el nombre del recurso de AlloyDB para PostgreSQL. que se vio afectada.
     • Nombre completo superior: Es el nombre del recurso de AlloyDB para PostgreSQL. instancia.
     • Nombre completo del proyecto: 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: Vínculo a las entradas de Logging
     • Método MITRE ATT&CK: vínculo a la documentación de MITRE ATT&CK.

3. Para ver el JSON completo del hallazgo, 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 las instancia de AlloyDB para PostgreSQL.
2. Revisa los registros de pgaudit de PostgreSQL que contienen las consultas ejecutado por el superusuario, mediante los siguientes filtros:
   • protoPayload.request.user="postgres"

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

1. Revisa la entrada del marco de trabajo MITRE ATT&CK para este tipo de hallazgo: Robo por Servicio Web.
2. Para determinar si se necesitan pasos de corrección adicionales, combina los resultados de tu investigación con los de MITRE en la investigación.

Paso 4: Implementa tu respuesta

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

• Revisa los usuarios que pueden conectarse a la base de datos.
• Considera cambiar la contraseña para el 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 están a nivel de la organización, Event Threat Detection solo puede analizarlos si activas Security Command Center a nivel de la organización.

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

Initial Access: Disabled Password Leak

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

Descripción	Acciones
Se inhabilitó la cuenta de un miembro porque se detectó un filtrado de contraseñas.	Restablece las contraseñas de las cuentas afectadas y recomienda a los miembros que usen contraseñas seguras y únicas para las cuentas corporativas.	Verifica los registros mediante los siguientes filtros: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Reemplaza ORGANIZATION_ID por el ID de tu organización.
		Eventos de investigación que activan este resultado: 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 de proyecto.

Descripción	Acciones
Se detectó y bloqueó un acceso sospechoso a la cuenta de un miembro.	Los adversarios podrían intentar acceder a esta cuenta. Asegúrate de que la cuenta de usuario siga los lineamientos de seguridad de tu organización en términos de contraseñas seguras y autenticación de varios factores.	Verifica los registros mediante los siguientes filtros: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Reemplaza ORGANIZATION_ID por el ID de tu organización.
		Eventos de investigación que activan este resultado: 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 de proyecto.

Descripción	Acciones
Se suspendió la cuenta de un miembro debido a una actividad sospechosa.	Esta cuenta fue usurpada. Restablece la contraseña de la cuenta y alienta a los usuarios a crear contraseñas únicas y seguras para las cuentas corporativas.	Verifica los registros mediante los siguientes filtros: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Reemplaza ORGANIZATION_ID por el ID de tu organización.
		Eventos de investigación que activan este resultado: 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 de proyecto.

Descripción	Acciones
Un miembro inhabilitó la verificación en dos pasos.	Verifica si el usuario tenía la intención de inhabilitar la verificación en dos pasos. Si tu organización requiere la verificación en dos pasos, asegúrate de que el usuario la habilite de inmediato.	Verifica los registros mediante los siguientes filtros: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Reemplaza ORGANIZATION_ID por el ID de tu organización.
		Eventos de investigación que activan este resultado: 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 de proyecto.

Descripción	Acciones
Es posible que atacantes respaldados por el Gobierno hayan intentado vulnerar una cuenta de un miembro o una computadora.	Los adversarios podrían intentar acceder a esta cuenta. Asegúrate de que la cuenta de usuario siga los lineamientos de seguridad de tu organización en términos de contraseñas seguras y autenticación de varios factores.	Verifica los registros mediante los siguientes filtros: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Reemplaza ORGANIZATION_ID por el ID de tu organización.
		Eventos de investigación que activan este resultado: 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 de proyecto.

Descripción	Acciones
Se inhabilitó la configuración de habilitación del SSO (inicio de sesión único) en la cuenta de administrador.	Se cambió la configuración del SSO de tu organización. Verifica si el cambio lo realizó de manera intencional un miembro o si un adversario lo implementó para agregar un nuevo acceso a tu organización.	Verifica los registros mediante los siguientes filtros: protopayload.resource.labels.service="admin.googleapis.com" protopayload.metadata.event.parameter.value=DOMAIN_NAME logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Reemplaza lo siguiente: DOMAIN_NAME: el domainName que se muestra en el resultado ORGANIZATION_ID: El ID de tu organización.
		Eventos de investigación que activan este resultado: 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 de proyecto.

Descripción	Acciones
Se cambió la configuración de SSO para la cuenta de administrador.	Se cambió la configuración del SSO de tu organización. Verifica si el cambio lo realizó de manera intencional un miembro o si un adversario lo implementó para agregar un nuevo acceso a tu organización.	Verifica los registros mediante los siguientes filtros: protopayload.resource.labels.service="admin.googleapis.com" protopayload.metadata.event.parameter.value=DOMAIN_NAME logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Reemplaza lo siguiente: DOMAIN_NAME: el domainName que se muestra en el resultado ORGANIZATION_ID: El ID de tu organización.
		Eventos de investigación que activan este resultado: 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 de proyecto.

Descripción	Acciones
Se inhabilitó la verificación en dos pasos para la organización.	La verificación en dos pasos ya no es necesaria para tu organización. Averigua si se trata de un cambio de política intencional por parte de un administrador o si se trata de un intento de un adversario para facilitar la usurpación de una cuenta.	Verifica los registros mediante los siguientes filtros: protopayload.resource.labels.service="admin.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Reemplaza ORGANIZATION_ID por el ID de tu organización.
		Eventos de investigación que activan este resultado: 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 hallazgos de Google Workspace solo están disponibles a nivel de la organización activaciones de Security Command Center. Los registros de Google Workspace no se pueden se analizan en busca de activaciones a nivel de 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 de 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 hallazgos de IDS de Cloud están generados por el IDS de Cloud un servicio de seguridad que supervisa el tráfico desde y hacia tu Recursos de Google Cloud para detectar amenazas. Cuando el IDS de Cloud detecta envía información sobre la amenaza, como la dirección IP de origen, dirección de destino y número de puerto, a Event Threat Detection, que hallazgo de una amenaza.

Paso 1: Revisa los detalles del hallazgo

1. Abierta el hallazgo Cloud IDS: THREAT_ID, como se indica en Revisa los resultados.

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

   • Qué se detectó, en especial los siguientes campos:
     • Protocol: el protocolo de red usado
     • Hora del evento: Cuándo ocurrió el evento
     • Descripción: Más información sobre el hallazgo
     • Gravedad: Indica la gravedad de la alerta.
     • IP de destino: la IP de destino del tráfico de red
     • Puerto de destino: el puerto de destino del tráfico de red
     • IP de origen: 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: El proyecto que contiene la red con la amenaza.
   • Vínculos relacionados, en especial los siguientes campos:
     • URI de Cloud Logging: Vínculo a IDS de Cloud Logging entradas: estas tienen la información necesaria para buscar Palo Alto Networks Bóveda de amenazas
   • Servicio de detección
     • Categoría de hallazgo: El nombre de la amenaza del IDS de Cloud

3. Para ver el JSON completo del hallazgo, haz clic en la pestaña JSON.

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

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

Puedes encontrar más información sobre el evento detectado en el registro original haciendo clic en el vínculo del campo URI de Cloud Logging del resultado más detalles.

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 malware después del ataque inicial. Una práctica recomendada importante es asegurarse de que los contenedores sean inmutables. Esta es un hallazgo de gravedad baja, porque es posible que tu organización no esté siguiendo práctica recomendada. Existen correspondencias Execution: Added Malicious Binary Executed cuando el hash del El objeto 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. El panel de detalles del de resultados se abre en la pestaña Resumen.

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

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

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

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

4. Identifica otros hallazgos que ocurrieron en un momento similar para este contenedor. Los hallazgos relacionados podrían indicar que esta actividad fue maliciosa, en lugar de un error de seguir 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 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 del Pod se incluye en Pod_Namespace, si es necesario.

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

Paso 4: Comprueba los registros

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

   Ir al Explorador de registros

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

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

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

   1. Busca los registros de Pod para Pod_Name mediante el siguiente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Encuentra los registros de auditoría del clúster mediante el siguiente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Busca los registros de la consola de los nodos de GKE mediante el siguiente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Paso 5: Investiga el contenedor en ejecución

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

1. Ve a la consola de Google Cloud.

   Abrir la consola de Google Cloud

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

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

4. Obtén credenciales de GKE para tu clúster ejecutando el 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 marco de MITRE ATT&CK para este tipo de hallazgo: Transferencia de herramienta de Ingress, API nativa:
2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 7: Implementa tu respuesta

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

• Si el objeto binario está destinado a incluirse 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 que tiene el contenedor comprometido.
• 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 asegurarse de que los contenedores sean inmutables. Este es un hallazgo de gravedad baja, porque es posible que tu organización no esté siguiendo esta práctica recomendada. Existen resultados correspondientes de Execution: Added Malicious Library Loaded cuando el hash del objeto 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. El panel de detalles del de resultados se abre en la pestaña Resumen.

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

   • Qué se detectó, en especial los siguientes campos:
     • Objeto binario del programa: Es la ruta completa del objeto binario del proceso que cargó el objeto biblioteca.
     • Bibliotecas: Detalles sobre la biblioteca agregada
     • Arguments: los argumentos proporcionados cuando se invoca el proceso binario.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: el nombre completo del recurso del clúster.

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

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

4. Identifica otros hallazgos que ocurrieron en un momento similar para este contenedor. Los hallazgos relacionados podrían indicar que esta actividad fue maliciosa, en lugar de un error de seguir 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 del Pod se incluye 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 marco de MITRE ATT&CK para este tipo de hallazgo: Transferencia de herramienta de Ingress, Módulos Compartidos.
2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 7: Implementa tu respuesta

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

• Si se pretendía incluir la biblioteca 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 que tiene el contenedor comprometido.
• Detén o borra el contenedor comprometido y reemplázalo por un contenedor nuevo.

Execution: Added Malicious Binary Executed

Se usó un objeto binario malicioso que no formaba parte de la imagen del contenedor original ejecutado. 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. El panel de detalles del de resultados se abre en la pestaña Resumen.

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

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

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

   • sourceProperties:
     • VM_Instance_Name: Es el nombre del nodo de GKE en el que Pod ejecutado.

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 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 del Pod se incluye en Pod_Namespace, si es necesario.

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

Paso 4: Comprueba los registros

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

   Ir al Explorador de registros

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

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

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

   1. Busca los registros de Pod para Pod_Name mediante el siguiente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Encuentra los registros de auditoría del clúster mediante el siguiente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Busca los registros de la consola de los nodos de GKE mediante el siguiente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Paso 5: Investiga el contenedor en ejecución

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

1. Ve a la consola de Google Cloud.

   Abrir la consola de Google Cloud

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

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

4. Obtén credenciales de GKE para tu clúster ejecutando el 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 de acceso 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 marco de MITRE ATT&CK para este tipo de hallazgo: Transferencia de herramienta de Ingress, API nativa:
2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.
3. Comprueba el valor de hash SHA-256 del objeto binario marcado como malicioso en VirusTotal por haciendo clic en el vínculo del indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URL, dominios y direcciones IP potencialmente maliciosos.

Paso 7: Implementa tu respuesta

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

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

Execution: Added Malicious Library Loaded

Se cargó una biblioteca maliciosa que no era 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. El panel de detalles del de resultados se abre en la pestaña Resumen.

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

   • Qué se detectó, en especial los siguientes campos:
     • Objeto binario del programa: Es la ruta completa del objeto binario del proceso que cargó el objeto biblioteca.
     • Bibliotecas: Detalles sobre la biblioteca agregada
     • Arguments: los argumentos proporcionados cuando se invoca el proceso binario.
     • Contenedores: El nombre del contenedor afectado.
     • URI de contenedores: Es el nombre de la imagen de contenedor que se implementa.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: el nombre completo del recurso del clúster.
   • Vínculos relacionados, en especial los siguientes campos:
     • Indicador de VirusTotal: Vínculo a la página de análisis de VirusTotal.

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

   • sourceProperties:
     • VM_Instance_Name: Es el nombre del nodo de GKE en el que Pod ejecutado.

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 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 del Pod se incluye 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 el contenido malicioso que se agregó. biblioteca.

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 marco de MITRE ATT&CK para este tipo de hallazgo: Transferencia de herramienta de Ingress, Módulos Compartidos.
2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.
3. Comprueba el valor de hash SHA-256 de la biblioteca marcada como maliciosa en VirusTotal por haciendo clic en el vínculo del indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URL, dominios y direcciones IP potencialmente maliciosos.

Paso 7: Implementa tu respuesta

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

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

Execution: Built in Malicious Binary Executed

Un objeto binario que se ejecutó, con el siguiente objeto:

• Incluido en la imagen del contenedor original.
• Se identificó como malicioso en función de la inteligencia de amenazas.

El atacante controla el repositorio de imágenes del contenedor o la canalización de creación. en el que el binario malicioso se inyecta 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. El panel de detalles del de resultados se abre en la pestaña Resumen.

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

   • Qué se detectó, en especial los siguientes campos:
     • Objeto binario del programa: Es la ruta de acceso absoluta del objeto binario integrado.
     • Arguments: Son los argumentos que se proporcionan cuando se invoca el objeto binario integrado.
     • Contenedores: El nombre del contenedor afectado.
     • URI de contenedores: Es el nombre de la imagen de contenedor que se implementa.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: el nombre completo del recurso del clúster, incluidos el número, la ubicación y el nombre del proyecto.
   • Vínculos relacionados, en especial los siguientes campos:
     • Indicador de VirusTotal: 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 Pod ejecutado.

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 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 del Pod se incluye en Pod_Namespace, si es necesario.

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

Paso 4: Comprueba los registros

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

   Ir al Explorador de registros

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

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

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

   1. Busca los registros de Pod para Pod_Name mediante el siguiente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Encuentra los registros de auditoría del clúster mediante el siguiente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Busca los registros de la consola de los nodos de GKE mediante el siguiente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Paso 5: Investiga el contenedor en ejecución

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

1. Ve a la consola de Google Cloud.

   Abrir la consola de Google Cloud

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

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

4. Obtén credenciales de GKE para tu clúster ejecutando el siguientes comandos.

   Para clústeres zonales:

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

   Para clústeres regionales:

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

   Reemplaza lo siguiente:

   • cluster_name: el clúster que aparece en resource.labels.cluster_name
   • location: la ubicación que aparece en resource.labels.location
   • project_name: el nombre del proyecto que aparece en resource.project_display_name

5. Recupera el objeto binario malicioso integrado:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   Reemplaza local_file por una ruta de acceso local para almacenar el objeto binario malicioso integrado.

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 marco de MITRE ATT&CK para este tipo de hallazgo: Transferencia de herramienta de Ingress, API nativa:
2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.
3. Comprueba el valor de hash SHA-256 del objeto binario marcado como malicioso en VirusTotal por haciendo clic en el vínculo del indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URL, dominios y direcciones IP potencialmente maliciosos.

Paso 7: Implementa tu respuesta

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

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

Execution: 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 archivos binarios. Una práctica recomendada importante es asegurarse de que los 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 dar como resultado 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. El panel de detalles del de resultados se abre en la pestaña Resumen.

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

   • Qué se detectó, en especial los siguientes campos:
     • Objeto binario del programa: Detalles sobre el intérprete que invocó el guion.
     • Secuencia de comandos: Es la ruta de acceso absoluta del nombre de la secuencia de comandos en el disco. este solo aparece para secuencias de comandos escritas en el disco, no para literales la ejecución de secuencias de comandos, 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: el nombre completo del recurso del clúster, lo que incluye el número, la ubicación y el clúster nombre

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

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

   • finding:
     • processes:
     • script:
       • contents: Contenido de la secuencia de comandos ejecutada, que podría truncarse por por motivos de rendimiento; esto puede ayudar en tu investigación
       • sha256: El hash SHA-256 de script.contents
   • resource:
     • project_display_name: Es el nombre del proyecto que contiene. el recurso.
   • sourceProperties:
     • Pod_Namespace: Es el nombre del espacio de nombres de Kubernetes del Pod.
     • Pod_Name: Es el nombre del Pod de GKE.
     • Container_Name: Es el nombre del contenedor afectado.
     • Container_Image_Uri: Es el nombre de la imagen de contenedor que se ejecuta.
     • VM_Instance_Name: Es el nombre del nodo de GKE en el que Pod ejecutado.

5. Identifica otros hallazgos que ocurrieron en un momento similar para este contenedor. Por ejemplo, si la secuencia de comandos descarta un objeto binario, busca hallazgos 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 La pestaña Resumen de los detalles del hallazgo Ten en cuenta 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 Autoriza Cloud Shell, Haz clic en Autorizar.

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

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

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

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

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

Paso 7: Implementa tu respuesta

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

• Si Python estaba realizando los cambios deseados en el contenedor, vuelve a compilar la imagen del contenedor para que no se necesiten cambios. De esta manera, el contenedor puede ser inmutable.
• De lo contrario, comunícate con el propietario del proyecto que tiene el contenedor comprometido.
• Detén o borra el contenedor comprometido y reemplázalo por un contenedor nuevo.

Execution: Modified Malicious Binary Executed

Un objeto binario que se ejecutó, con el siguiente objeto:

• Incluido en la imagen del contenedor original.
• Se modifican durante el entorno de ejecución del contenedor.
• Se identificó como malicioso en función de la inteligencia de amenazas.

Los atacantes suelen instalar herramientas de explotación y software malicioso después del compromiso inicial. Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre un hallazgo de Execution: Modified Malicious Binary Executed como se indica en Revisa los resultados. El panel de detalles del de resultados se abre en la pestaña Resumen.

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

   • Qué se detectó, en especial los siguientes campos:
     • Objeto binario del programa: Es la ruta de acceso absoluta del objeto binario modificado.
     • Argumentos: Son los argumentos que se proporcionan cuando se invoca el objeto binario modificado.
     • Contenedores: El nombre del contenedor afectado.
     • URI de contenedores: Es el nombre de la imagen de contenedor que se implementa.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: el nombre completo del recurso del clúster, incluidos el número, la ubicación y el nombre del proyecto.
   • Vínculos relacionados, en especial los siguientes campos:
     • Indicador de VirusTotal: 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 Pod ejecutado.

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 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 del Pod se incluye en Pod_Namespace, si es necesario.

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

Paso 4: Comprueba los registros

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

   Ir al Explorador de registros

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

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

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

   1. Busca los registros de Pod para Pod_Name mediante el siguiente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Encuentra los registros de auditoría del clúster mediante el siguiente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Busca los registros de la consola de los nodos de GKE mediante el siguiente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Paso 5: Investiga el contenedor en ejecución

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

1. Ve a la consola de Google Cloud.

   Abrir la consola de Google Cloud

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

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

4. Obtén credenciales de GKE para tu clúster ejecutando el 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 marco de MITRE ATT&CK para este tipo de hallazgo: Transferencia de herramienta de Ingress, API nativa:
2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.
3. Comprueba el valor de hash SHA-256 del objeto binario marcado como malicioso en VirusTotal por haciendo clic en el vínculo del indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URL, dominios y direcciones IP potencialmente maliciosos.

Paso 7: Implementa tu respuesta

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

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

Execution: Modified Malicious Library Loaded

Una biblioteca que se cargó, con la biblioteca:

• Incluido en la imagen del contenedor original.
• Se modifican durante el entorno de ejecución del contenedor.
• Se identificó como malicioso en función de la inteligencia de amenazas.

Los atacantes podrían cargar bibliotecas maliciosas en programas existentes para omitir las protecciones de ejecución de código y ocultar código malicioso. Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre un hallazgo de Execution: Modified Malicious Library Loaded como se indica en Revisa los resultados. El panel de detalles del de resultados se abre en la pestaña Resumen.

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

   • Qué se detectó, en especial los siguientes campos:
     • Objeto binario del programa: Es la ruta completa del objeto binario del proceso que cargó el objeto biblioteca.
     • Bibliotecas: Detalles sobre la biblioteca modificada
     • Arguments: los argumentos proporcionados cuando se invoca el proceso binario.
     • Contenedores: El nombre del contenedor afectado.
     • URI de contenedores: Es el nombre de la imagen de contenedor que se implementa.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: el nombre completo del recurso del clúster.
   • Vínculos relacionados, en especial los siguientes campos:
     • Indicador de VirusTotal: Vínculo a la página de análisis de VirusTotal.

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

   • sourceProperties:
     • VM_Instance_Name: Es el nombre del nodo de GKE en el que Pod ejecutado.

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 del Pod se incluye 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 de acceso local para almacenar el contenido malicioso modificado biblioteca.

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 marco de MITRE ATT&CK para este tipo de hallazgo: Transferencia de herramienta de Ingress, Módulos Compartidos.
2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.
3. Comprueba el valor de hash SHA-256 de la biblioteca marcada como maliciosa en VirusTotal por haciendo clic en el vínculo del indicador de VirusTotal. VirusTotal es un servicio que es propiedad de Alphabet y proporciona contexto sobre archivos, URL, dominios y direcciones IP potencialmente maliciosos.

Paso 7: Implementa tu respuesta

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

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

Malicious Script Executed

Un modelo de aprendizaje automático identificó el código Bash ejecutado como malicioso. Los atacantes pueden utilizar Bash para transferir herramientas y ejecutar comandos sin archivos binarios. Una práctica recomendada importante es asegurarse de que los 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 dar como resultado 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. El panel de detalles del de resultados se abre en la pestaña Resumen.

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

   • Qué se detectó, en especial los siguientes campos:
     • Objeto binario del programa: Detalles sobre el intérprete que invocó el guion.
     • Secuencia de comandos: Es la ruta de acceso absoluta del nombre de la secuencia de comandos en el disco. este solo aparece para secuencias de comandos escritas en el disco, no para literales la ejecución de la secuencia de comandos, 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: el nombre completo del recurso del clúster, lo que incluye el número, la ubicación y el clúster nombre

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

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

   • finding:
     • processes:
     • script:
       • contents: Contenido de la secuencia de comandos ejecutada, que podría truncarse por por motivos de rendimiento; esto puede ayudar en tu investigación
       • sha256: El hash SHA-256 de script.contents
   • resource:
     • project_display_name: Es el nombre del proyecto que contiene. el recurso.
   • sourceProperties:
     • Pod_Namespace: Es el nombre del espacio de nombres de Kubernetes del Pod.
     • Pod_Name: Es el nombre del Pod de GKE.
     • Container_Name: Es el nombre del contenedor afectado.
     • Container_Image_Uri: Es el nombre de la imagen de contenedor que se ejecuta.
     • VM_Instance_Name: Es el nombre del nodo de GKE en el que Pod ejecutado.

5. Identifica otros hallazgos que ocurrieron en un momento similar para este contenedor. Por ejemplo, si la secuencia de comandos descarta un objeto binario, busca hallazgos 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 La pestaña Resumen de los detalles del hallazgo Ten en cuenta 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 marco de MITRE ATT&CK para este tipo de hallazgo: Intérprete de comandos y secuencias de comandos, Transferencia de la herramienta de Ingress.
2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 7: Implementa tu respuesta

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

• Si la secuencia de comandos estaba realizando los cambios deseados en el contenedor, vuelve a compilar la imagen del contenedor, de manera que no se necesiten cambios. De esta manera, el contenedor puede ser inmutable.
• De lo contrario, comunícate con el propietario del proyecto que tiene el contenedor comprometido.
• 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 una ejecutable. Los atacantes pueden cargar software malicioso o bibliotecas maliciosas a través de URLs maliciosas.

Para responder a este hallazgo, realiza los siguientes pasos.

Paso 1: Revisa los detalles del hallazgo

1. Abre un hallazgo de Malicious URL Observed como se indica en Revisa los resultados. El panel de detalles del de resultados se abre en la pestaña Resumen.

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

   • Qué se detectó, en especial los siguientes campos:
     • URI: El URI malicioso observado.
     • Objeto binario agregado: Es la ruta de acceso completa del objeto binario del proceso que se recibió. los argumentos que contienen la URL maliciosa.
     • Arguments: Son los argumentos que se proporcionan cuando se invoca el objeto binario del proceso.
     • Variables de entorno: Son las variables de entorno que estaban en efecto cuando se invocó el objeto binario del proceso.
     • Contenedores: El nombre del contenedor.
     • Pods de Kubernetes: El nombre del Pod y el espacio de nombres
   • Recurso afectado, en especial los siguientes campos:
     • Nombre visible del recurso: El nombre del recurso afectado.
     • Nombre completo del recurso: el nombre completo del recurso del clúster. El nombre completo del recurso incluye lo siguiente: información:
       • El proyecto que contiene el clúster: projects/PROJECT_ID
       • La ubicación en la que se encuentra el clúster: zone/ZONE o locations/LOCATION
       • El nombre del clúster: projects/CLUSTER_NAME

3. En la pestaña JSON, en el atributo sourceProperties, 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 proyecto aparece después de /projects/ en el nombre completo del recurso.

3. Haz clic en el nombre del clúster que anotaste en Nombre visible del recurso. (resource.display_name) del resumen del resultado. Los Clústeres se abre esta página.

4. En la sección Metadatos de la página **Detalles del clúster, anota cualquier de la información definida por el usuario que podría ser útil para resolver el de una amenaza de seguridad potencial, como la información que identifica al propietario del clúster.

5. Haz clic en la pestaña Nodos.

6. De los nodos de la lista, selecciona el nodo coincide con el valor de VM_Instance_Name que anotaste en el resultado JSON anterior.

7. En la pestaña Detalles de la página Detalles del nodo, en la Anotaciones, ten en cuenta el valor 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 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 resultados y, si necesario, el Espacio de nombres del Pod (kubernetes.pods.ns) que anotaste.

5. Haz clic en el nombre de la carga de trabajo que coincida con el valor de VM_Instance_Name. que anotaste en el hallazgo JSON anterior. Los detalles del Pod se abre esta página.

6. En la página Detalles del Pod, anota cualquier información sobre el Pod que puede ayudarte a resolver la amenaza.

Paso 4: Comprueba los registros

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

   Ir al Explorador de registros

2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que aparece en Nombre completo del recurso (resource.name), si es necesario.

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

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

   1. Encuentra los registros de tu Pod (kubernetes.pods.name) con 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 del resultado 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. Verifica el estado del sitio de Navegación segura. para obtener detalles sobre por qué la URL se clasificó como maliciosa.
2. Revisa las entradas del marco de MITRE ATT&CK para este tipo de hallazgo: Transferencia de herramienta de entrada.
3. Para desarrollar un plan de respuesta, combina los resultados de tu investigación con Investigación de MITRE.

Paso 7: Implementa tu respuesta

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

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

Reverse Shell

Es un proceso iniciado con redireccionamiento de transmisión a un socket remoto conectado. La generación de un shell conectado a la red puede permitir que un atacante realice acciones arbitrarias después de un compromiso inicial limitado. Para responder a este hallazgo, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre un hallazgo de Reverse Shell como se indica en Revisa los resultados. El panel de detalles del de resultados se abre en la pestaña Resumen.

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

   • Qué se detectó, en especial los siguientes campos:
     • Objeto binario del programa: Es la ruta de acceso absoluta del proceso que comenzó con y el redireccionamiento de transmisión a un socket remoto.
     • Arguments: Son los argumentos que se proporcionan cuando se invoca el objeto binario del proceso.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: el nombre completo del recurso del clúster.
     • Nombre completo del proyecto:
   • En la vista de detalles del hallazgo, haz clic en la pestaña JSON.
   • En JSON, ten en cuenta los siguientes campos.
   • resource:
     • project_display_name: Es el nombre del proyecto que contiene. el recurso.
   • sourceProperties:
     • Pod_Namespace: Es el nombre del espacio de nombres de Kubernetes del Pod.
     • Pod_Name: Es el nombre del Pod de GKE.
     • Container_Name: Es el nombre del contenedor afectado.
     • VM_Instance_Name: Es el nombre del nodo de GKE en el que Pod ejecutado.
     • 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 marco de MITRE ATT&CK para este tipo de hallazgo: Intérprete de comandos y secuencias de comandos, Transferencia de la herramienta de Ingress.
2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 7: Implementa tu respuesta

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

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

Unexpected Child Shell

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

Para responder a este hallazgo, realiza los siguientes pasos.

Paso 1: Revisa los detalles del hallazgo

1. Abre un hallazgo de Unexpected Child Shell como se indica en Revisa los resultados. El panel de detalles del de resultados se abre en la pestaña Resumen.

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

   • Qué se detectó, en especial los siguientes campos:
     • Proceso superior: Es el proceso que creó inesperadamente el proceso de shell secundario.
     • Proceso secundario: Es el proceso de shell secundario.
     • Argumentos: Son los argumentos proporcionados al objeto binario del proceso de shell secundario.
     • Variables de entorno: Son las variables de entorno del objeto binario del proceso de shell secundario.
     • Contenedores: El nombre del contenedor.
     • URI de contenedores: Es el URI de imagen del contenedor.
     • Pods de Kubernetes: El nombre del Pod y el espacio de nombres
   • Recurso afectado, en especial los siguientes campos:
     • Nombre visible del recurso: El nombre del recurso afectado.
     • Nombre completo del recurso: el nombre completo del recurso del clúster. El nombre completo del recurso incluye lo siguiente: información:
       • El proyecto que contiene el clúster: projects/PROJECT_ID
       • La ubicación en la que se encuentra el clúster: zone/ZONE o locations/LOCATION
       • El nombre del clúster: projects/CLUSTER_NAME

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

+processes: Es un array que contiene todos los procesos relacionados con el resultado. Este array incluye el proceso de shell secundario y el proceso superior. resource más: +project_display_name: El nombre del proyecto que contiene los elementos. sourceProperties más: +VM_Instance_Name: El nombre del nodo de GKE en el que Pod ejecutado.

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 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 resultados y, si necesario, el Espacio de nombres del Pod (kubernetes.pods.ns) que anotaste.

5. Haz clic en el nombre de la carga de trabajo que coincida con el valor de VM_Instance_Name. que anotaste en el hallazgo JSON anterior. Los detalles del Pod se abre esta página.

6. En la página Detalles del Pod, anota cualquier información sobre el Pod que puede ayudarte a resolver la amenaza.

Paso 4: Comprueba los registros

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

   Ir al Explorador de registros

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

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

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

   1. Busca los registros de Pod para Pod_Name mediante el siguiente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Encuentra los registros de auditoría del clúster mediante el siguiente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Busca los registros de la consola de los nodos de GKE mediante el siguiente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Paso 5: Investiga el contenedor en ejecución

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

1. Ve a la consola de Google Cloud.

   Abrir la consola de Google Cloud

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

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

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

   Para los clústeres zonales, ejecuta lo siguiente:

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

   Para los clústeres regionales, ejecuta lo siguiente:

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

5. Para iniciar una shell dentro del entorno del contenedor, ejecuta lo siguiente:

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

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

   Para ver todos los procesos que se ejecutan en el contenedor, ejecuta el siguiente comando en el shell del contenedor:

     ps axjf
   

   Este comando requiere que el contenedor tenga /bin/ps instalado.

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

1. Revisa las entradas del marco de MITRE ATT&CK para este tipo de hallazgo: Intérprete de comandos y secuencias de comandos: shell de Unix.
2. Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.

Paso 7: Implementa tu respuesta

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

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

Respuesta de detección de amenazas de VM

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

Execution: Cryptocurrency Mining Hash Match

VM Threat Detection detectó actividades de minería de criptomonedas por coincidencia de memoria. hashes de programas en ejecución contra hashes de memoria de minería de criptomonedas software.

Para responder a estos resultados, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre un resultado de Execution: Cryptocurrency Mining Hash Match, como se indica en Revisa los resultados. El panel de detalles para el hallazgo se abre en la pestaña Resumen.

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

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

     • Familia binaria: La aplicación de criptomonedas que se detectó
     • Objeto binario del programa: Es la ruta de acceso absoluta del proceso.
     • Arguments: Son los argumentos que se proporcionan 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 firma detectadas.

     VM Threat Detection puede reconocer compilaciones de kernel de las principales versiones de Linux distribuciones. 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 volver a acceder al kernel (por ejemplo, si el kernel es personalizado) Compilar, el campo processes del hallazgo no se propaga.

   • Recurso afectado, en especial los siguientes campos:

     • Nombre completo del recurso: el nombre completo del recurso del afectado Instancia de VM, incluido el ID del proyecto que la contiene.

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

   • indicator
     • signatures:
       • memory_hash_signature: Una firma que corresponde a la memoria hashes de la página.
       • detections
         • binary: Es el nombre de la aplicación de criptomonedas. binario, por ejemplo, linux--x86-64_ethminer_0.19.0_alpha.0_cuda10.0
         • percent_pages_matched: El porcentaje de páginas en la memoria que coincidan con páginas en aplicaciones de criptomonedas conocidas en el de hash de la página.

Paso 2: Comprueba los registros

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

   Ir al Explorador de registros

2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que contenga la instancia de VM, como se especifica en la fila Nombre completo del recurso en la la pestaña Resumen de los detalles de los resultados.

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

Paso 3: Revisa los permisos y la configuración

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

   Ir al panel

2. Selecciona el proyecto que se especifica en La fila Nombre completo del recurso en la pestaña Resumen de la para encontrar detalles.

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

4. Haz clic en la instancia de VM que coincida con el proyecto identificado. en Nombre completo del recurso. Revisar instancia incluidos los detalles, incluida la configuración de red y de 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 apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

Para ayudar con la detección y la eliminación, usa una solución de detección y respuesta de extremos.

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

2. Confirma si la aplicación es una aplicación minera:

   • Si el nombre del proceso y la ruta binaria de la aplicación detectada están disponibles, ten en cuenta los valores en Program binary, Arguments y Filas Nombres de procesos en la pestaña Resumen de los detalles de los resultados en tu investigación.

   • Si los detalles del proceso no están disponibles, comprueba si el nombre binario del la firma de hash de memoria puede proporcionar pistas. Considera un objeto binario llamado linux-x86-64_xmrig_2.14.1 Puedes usar la grep para buscar archivos destacados en Storage. Usa una porción significativa de el nombre del objeto binario en tu patrón de búsqueda, en este caso, xmrig. Examina los en los resultados de la búsqueda.

   • Examina los procesos en ejecución, en especial los que tienen un alto uso de CPU. para ver si hay alguno que no reconoces. Determina si el valor aplicaciones asociadas son aplicaciones mineras.

   • Buscar los archivos del almacenamiento en busca de cadenas comunes que las aplicaciones de minería usar, como btc.com, ethminer, xmrig, cpuminer y randomx. Para ver más ejemplos de cadenas que puedes buscar, consulta Nombres de software y reglas YARA y la documentación relacionada para cada software mencionado.

3. Si determinas que la aplicación es una aplicación minera y su proceso aún se está ejecutando, finaliza el proceso. Ubica el archivo ejecutable de la aplicación binario en el almacenamiento de la VM y borrarlo.

4. Si es necesario, detén la instancia comprometida y reemplazarla por una nueva.

Execution: Cryptocurrency Mining YARA Rule

VM Threat Detection detectó actividades de minería de criptomonedas por coincidencia de memoria. como las constantes de prueba de trabajo, que usan las criptomonedas software de minería de agua.

Para responder a estos resultados, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre un resultado de Execution: Cryptocurrency Mining YARA Rule, como se indica en Revisa los resultados. El panel de detalles para el hallazgo se abre en la pestaña Resumen.

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

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

     • Nombre de la regla YARA: la regla activada para los detectores YARA.
     • Objeto binario del programa: Es la ruta de acceso absoluta del proceso.
     • Arguments: Son los argumentos que se proporcionan cuando se invoca el objeto binario del proceso.
     • Nombres de procesos: Es el nombre de los procesos que se ejecutan en la VM. instancia asociada con las coincidencias de firma detectadas.

     VM Threat Detection puede reconocer compilaciones de kernel de las principales versiones de Linux distribuciones. 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 volver a acceder al kernel (por ejemplo, si el kernel es personalizado) Compilar, el campo processes del hallazgo no se propaga.

   • Recurso afectado, en especial los siguientes campos:

     • Nombre completo del recurso: el nombre completo del recurso del afectado Instancia de VM, incluido el ID del proyecto que la contiene.

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

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

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

Paso 2: Comprueba los registros

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

   Ir al Explorador de registros

2. En la barra de herramientas de la consola de Google Cloud, selecciona el proyecto que contenga la instancia de VM, como se especifica en la fila Nombre completo del recurso en la la pestaña Resumen de los detalles de los resultados.

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

Paso 3: Revisa los permisos y la configuración

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

   Ir al panel

2. Selecciona el proyecto que se especifica en el nombre del recurso que aparece en el La fila Nombre completo del recurso (Resource full name) en la pestaña Resumen de los detalles de los hallazgos.

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

4. Haz clic en la instancia de VM que coincide con resourceName. Revisar instancia incluidos los detalles, incluida la configuración de red y de 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 apropiado para este hallazgo, pero también podría afectar las operaciones. Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.

Para ayudar con la detección y la eliminación, usa una solución de detección y respuesta de extremos.

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

2. Confirma si la aplicación es una aplicación minera:

   • Si el nombre del proceso y la ruta binaria de la aplicación detectada están disponibles, ten en cuenta los valores en Program binary, Arguments y Filas Nombres de procesos en la pestaña Resumen de los detalles de los resultados en tu investigación.

   • Examina los procesos en ejecución, en especial los que tienen un alto uso de CPU. para ver si hay alguno que no reconoces. Determina si el valor aplicaciones asociadas son aplicaciones mineras.

   • Buscar los archivos del almacenamiento en busca de cadenas comunes que las aplicaciones de minería usar, como btc.com, ethminer, xmrig, cpuminer y randomx. Para ver más ejemplos de cadenas que puedes buscar, consulta Nombres de software y reglas YARA y la documentación relacionada para cada software mencionado.

3. Si determinas que la aplicación es una aplicación minera y su proceso aún se está ejecutando, finaliza el proceso. Ubica el archivo ejecutable de la aplicación binario en el almacenamiento de la VM y borrarlo.

4. Si es necesario, detén la instancia comprometida y reemplazarla por una nueva.

Execution: cryptocurrency mining combined detection

VM Threat Detection detectó múltiples categorías de hallazgos en un solo día desde una única fuente. Una sola aplicación puede activar simultáneamente Execution: Cryptocurrency Mining YARA Rule y Execution: Cryptocurrency Mining Hash Match findings

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

Malware: Malicious file on disk (YARA)

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

Para responder a estos resultados, haz lo siguiente:

Paso 1: Revisa los detalles del hallazgo

1. Abre el hallazgo Malware: Malicious file on disk (YARA), como se indica en Opinión de los resultados. El panel de detalles para el hallazgo se abre en la pestaña Resumen.

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

   • Qué se detectó, en especial los siguientes campos:
     • Nombre de la regla YARA: Es la regla de YARA que coincidió.
     • Files: el UUID de la partición y la ruta de acceso relativa de la el archivo malicioso que se detectó.
   • Recurso afectado, en especial los siguientes campos:
     • Nombre completo del recurso: el nombre completo del recurso del afectado Instancia de VM, incluido el ID del proyecto que la contiene.

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

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

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

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 contenga la instancia de VM, como se especifica en la fila Nombre completo del recurso en la la pestaña Resumen de los detalles de los resultados.

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

Paso 3: Revisa los permisos y la configuración

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

   Ir al panel

2. Selecciona el proyecto que se especifica en el nombre del recurso que aparece en el La fila Nombre completo del recurso (Resource full name) en la pestaña Resumen de los detalles de los hallazgos.

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

4. Haz clic en la instancia de VM que coincide con resourceName. Revisar instancia incluidos los detalles, incluida la configuración de red y de acceso.

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

Comprueba el valor de hash SHA-256 del archivo marcado como malicioso en VirusTotal. VirusTotal es un servicio propiedad de Alphabet que proporciona contexto sobre archivos URLs, dominios y direcciones IP.

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

Paso 5: Implementa tu respuesta

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

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

2. Si es necesario, ubica y borra el archivo potencialmente malicioso. Para obtener la UUID de partición y la ruta de acceso relativa del archivo, consulta el campo Archivos en la pestaña Resumen de los detalles de los resultados. Para ayudar con la detección y el uso de una solución de detección y respuesta de endpoints.

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

   Nota: Con el nivel de Security Command Center Enterprise, también puedes realizar lo siguiente: a través de una respuesta ante amenazas manual.

4. Para el análisis forense, considere crear una copia de seguridad de las máquinas virtuales y de Compute Engine. Para obtener más información, consulta Protección de datos de comandos en la Compute Engine en la documentación de Google Cloud.

5. Para una mayor investigación, considere usar servicios de respuesta ante incidentes como Mandiant:

Corrige vulnerabilidades relacionadas

Para ayudar a evitar que vuelvan a ocurrir amenazas, revisa y corrige las vulnerabilidades relacionadas y de parámetros de configuración incorrectos.

Para encontrar cualquier resultado relacionado, sigue estos pasos:

1. En la consola de Google Cloud, ve a Security Command Center Hallazgos.

   Ir a hallazgos

2. Revisa el hallazgo de amenaza y copia el valor de un atributo que es probable que aparezca en una vulnerabilidad relacionada o una configuración incorrecta como la dirección de correo electrónico principal o el nombre del grupo recurso.

3. En la página Hallazgos, abre el Editor de consultas haciendo clic en Editar consulta.

4. Haga clic en Agregar filtro. Se abrirá el menú Seleccionar filtro.

5. En la lista de categorías de filtro en la parte izquierda del menú, selecciona la categoría que contiene el atributo que anotaste en la amenaza hallazgo.

   Por ejemplo, si anotaste el nombre completo del recurso afectado, selecciona Recurso. Los tipos de atributo de la categoría Recurso son los siguientes: que se muestra en la columna de la derecha, incluido Nombre completo .

6. En los atributos que se muestran, selecciona el tipo de atributo que deseas indicadas en el hallazgo de amenaza. Se abrirá un panel de búsqueda de valores de atributos a la derecha y muestra todos los valores encontrados del tipo de atributo seleccionado.

7. En el campo Filtro, pega el valor del atributo que copiaste. el hallazgo de amenaza. La lista de valores que se muestra se actualiza para mostrar solo los valores que coincidan 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 resultados de coincidencias.

9. Si hay muchos hallazgos en los resultados, filtra los hallazgos por seleccionar filtros adicionales en el panel Filtros rápidos.

   Por ejemplo, para mostrar solo Vulnerability y Misconfiguration. resultados de clase que contengan los valores de atributos seleccionados desplázate hacia abajo hasta la sección Clase de resultado de Filtros rápidos. y selecciona Vulnerabilidad y Configuración incorrecta.

Además de los indicadores de compromiso proporcionados por Google, los usuarios que son clientes de Palo Alto Networks pueden integrar AutoFocus Threat Intelligence de Palo Alto Networks con Event Threat Detection. AutoFocus es un servicio de inteligencia de amenazas que proporciona información sobre las amenazas de red. Para obtener más información, visita el AutoFocus en la consola de Google Cloud.

Cómo solucionar las amenazas

Remediar los hallazgos de Event Threat Detection y Container Threat Detection no es tan simple. como corregir errores de configuración y vulnerabilidades 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 Descripción general de Event Threat Detection para obtener más información sobre el servicio y las amenazas que detecta.

• Consulta Descripción general de Container Threat Detection para saber cómo funciona el servicio.

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