Google Cloud comprometido: guía de respuesta a incidentes
Su proyecto de Google Cloud puede estar comprometido. El orden de actuación: contener la identidad, preservar los registros de auditoría, acotar y erradicar.
En resumen. Trate una sospecha de compromiso de Google Cloud primero como un incidente de identidad. Inhabilite la credencial en uso (normalmente una clave de cuenta de servicio gestionada por el usuario o una sesión de usuario), copie los Cloud Audit Logs fuera del proyecto antes de que alguien con el rol Owner pueda tocarlos y acote el alcance con una lista corta de methodNames: CreateServiceAccountKey, SetIamPolicy, setMetadata, storage.objects.get, DeleteSink. Solo después, limpie. El analizador gratuito en el navegador ejecuta esas detecciones sobre una exportación y le da un veredicto, una cronología y una lista de verificación.
La mayoría de los incidentes de Google Cloud que veo no empiezan con un exploit exótico. El Cloud Threat Horizons Report H2 2025 de Google atribuye el 47,1 % de los accesos iniciales observados en el primer semestre de 2025 a credenciales débiles o inexistentes y el 29,4 % a errores de configuración. En la práctica: un archivo de clave en un repositorio, una variable de CI impresa en un log de compilación, una VM con una contraseña débil. Después, el atacante hace lo que los permisos le dejan: asignarse Owner, lanzar mineros, leer buckets y apagar lo que podría alertarle.
Esta guía es el orden de actuación. Cada fase enlaza con un artículo detallado de la serie.
Fase 1: triaje en la primera hora
Tiene una señal: un pico de facturación, un hallazgo de Security Command Center, un correo de Google sobre una clave expuesta o un miembro de IAM extraño. Responda rápido a tres preguntas.
- ¿Qué identidad? Un correo de cuenta de servicio (
…@PROJECT.iam.gserviceaccount.com), un usuario o una cuenta personal de Gmail que no debería estar ahí. - ¿Qué credencial? Si las entradas de auditoría llevan
authenticationInfo.serviceAccountKeyName, quien llamó usó una clave gestionada por el usuario. Si llevanserviceAccountDelegationInfo, alguien suplantó una cuenta de servicio y el actor real está más arriba en la cadena. - ¿Sigue activo? Mire la última entrada de ese principal y de esa IP de origen.
Una primera consulta en Logs Explorer (Explorador de registros) basta para responder:
logName:"cloudaudit.googleapis.com"
protoPayload.authenticationInfo.principalEmail="ci-deployer@PROJECT.iam.gserviceaccount.com"
Fase 2: contener la identidad, no los síntomas
Borrar la VM de minado da sensación de avance, pero si la clave que la creó sigue funcionando, volverá en minutos. La guía de Google para credenciales comprometidas detalla las acciones por tipo de credencial. Las más importantes:
| Credencial en uso | Contención |
|---|---|
| Clave de cuenta de servicio gestionada por el usuario | Inhabilitar la clave (y borrarla cuando su ID esté anotado); rotar lo que la cuenta de servicio podía leer |
| Suplantación de identidad | Quitar a quien llama el rol Token Creator / Service Account User; inhabilitar a quien llama |
| Usuario o cuenta de Gmail en IAM | Quitar la vinculación; si es uno de sus usuarios, cerrar su sesión y restablecer la contraseña |
| Tokens OAuth (gcloud) | Revocar el token; aplicar control de sesión para el acceso a Google Cloud |
Después revise la política de IAM en busca de otros añadidos. Quien consigue Owner rara vez se queda en una sola vinculación. El artículo sobre abuso de políticas de IAM explica cómo leer los bindingDeltas para listar cada cambio.
Fase 3: preservar las pruebas antes de que caduquen o desaparezcan
Dos cosas destruyen las pruebas en la nube: la retención y el atacante.
- La retención. El bucket
_Requiredconserva los registros Admin Activity y System Event durante 400 días y no se puede modificar; el bucket_Defaultconserva todo lo demás, incluidos los registros Data Access, 30 días por defecto (cuotas y límites, descripción general del enrutamiento). - El atacante. Con el rol Owner puede borrar sinks de registros, añadir exclusiones, acortar la retención de
_Defaulto borrar registros. Vea evasión de defensas en Google Cloud.
Exporte ya, y con amplitud: todo el periodo sospechoso más unas semanas de referencia, todos los tipos de registro de auditoría y VPC Flow Logs si existen. La descarga desde la consola está limitada a 10.000 entradas (interfaz de Logs Explorer); para volúmenes mayores use gcloud logging read o copie el bucket del sink. Tipos de Cloud Audit Logs explicados cubre cada vía de exportación.
Fase 4: acotar con una lista corta de methodNames
No hace falta leer cada entrada. Un puñado de valores de protoPayload.methodName responde a casi todas las preguntas de alcance:
| Pregunta | Dónde mirar | Para profundizar |
|---|---|---|
| ¿Se creó o subió una clave? | google.iam.admin.v1.CreateServiceAccountKey, UploadServiceAccountKey | Clave de cuenta de servicio filtrada |
| ¿Quién suplantó a quién? | iamcredentials.googleapis.com GenerateAccessToken, SignBlob, SignJwt; serviceAccountDelegationInfo | Suplantación de cuentas de servicio |
| ¿Alguien obtuvo Owner? | SetIamPolicy con bindingDeltas ADD roles/owner | Abuso de SetIamPolicy |
| ¿Hay VM con puertas traseras o minando? | compute.instances.setMetadata, setCommonInstanceMetadata, compute.instances.insert con aceleradores | Abuso de Compute Engine |
| ¿Se llevaron datos? | Ráfagas de storage.objects.get, storage.setIamPermissions con allUsers, trabajos de copia de BigQuery | Exfiltración de GCS y BigQuery |
| ¿Salieron datos por la red? | VPC Flow Logs, bytes por IP externa | Análisis de VPC Flow Logs |
| ¿Le dejaron a ciegas? | DeleteSink, UpdateSink, CreateExclusion, auditConfigDeltas REMOVE | Evasión de defensas |
Pivote todo el tiempo sobre dos claves: la IP de origen (protoPayload.requestMetadata.callerIp) y el principal. Una IP de atacante que aparece con una clave de cuenta de servicio y luego con una cuenta de Gmail recién convertida en Owner une las dos fases. El analizador hace exactamente esta correlación y genera un hallazgo de «cadena de ataque» cuando la misma IP o el mismo principal pasa del acceso a acciones de toma de control.
Tenga en cuenta que callerIp no siempre es una dirección pública: Google documenta que las llamadas entre servicios de Google muestran private y que las llamadas desde VM sin IP externa pueden mostrar la dirección interna o gce-internal-ip (referencia de AuditLog).
Fase 5: erradicar y recuperar
Con el alcance claro, elimine todos los puntos de apoyo de una sola pasada; si no, el atacante lo nota y se mueve:
- borrar las claves, claves HMAC y cuentas de servicio creadas por el atacante;
- quitar las vinculaciones de IAM y restaurar las políticas de organización relajadas;
- reconstruir (no limpiar) las VM cuyos scripts de inicio o claves SSH cambiaron, después de hacer instantáneas de sus discos;
- volver a hacer privados los buckets y aplicar la prevención de acceso público;
- restaurar los sinks y el registro Data Access, idealmente hacia un sink agregado en un proyecto que los responsables de las cargas de trabajo no puedan administrar.
La lista de remediación de la herramienta se genera a partir de los hallazgos en ese orden: primero contención, luego persistencia, luego registros.
Fase 6: cerrar las brechas que lo hicieron posible
La lista posterior al incidente suele ser la misma:
- aplicar
iam.disableServiceAccountKeyCreationy migrar la CI a Workload Identity Federation; - configurar
iam.serviceAccountKeyExposureResponseenDISABLE_KEYpara que las claves que Google encuentre en sitios públicos se inhabiliten automáticamente (blog de Google Cloud); - restringir los miembros de IAM a sus dominios con el uso compartido restringido por dominio;
- habilitar los registros de auditoría Data Access al menos para IAM y Cloud Storage; el artículo sobre limitaciones explica por qué su ausencia es el callejón sin salida más habitual.
Dónde encaja el analizador
El analizador GCP Forensics toma las exportaciones de la fase 3 y realiza el acotamiento de la fase 4: 32 reglas, 5 análisis con estado y una correlación de cadena de ataque, todas publicadas en la tabla de reglas de la página. Se ejecuta en su navegador; los registros no se suben. La guía paso a paso muestra el flujo de trabajo y el caso práctico ficticio muestra el resultado sobre un incidente completo.
No sustituye al criterio. Una clave usada desde la IP de un proveedor de CI o un Owner concedido a un consultor pueden ser legítimos; confirme cada hallazgo con su responsable. Y las entradas de auditoría de GKE se apartan para Kubernetes Forensics, y las de Workspace para Google Workspace Forensics.
Preguntas frecuentes
¿Qué hay que hacer primero cuando un proyecto de Google Cloud está comprometido?
Anular la credencial que usa el atacante (inhabilitar la clave de la cuenta de servicio, suspender al usuario, revocar tokens) y, en la misma hora, copiar los registros de auditoría fuera del proyecto. Todo lo demás viene después de esos dos pasos.
¿Qué registros muestran lo que hizo un atacante en Google Cloud?
Cloud Audit Logs. Los registros Admin Activity están siempre activos y muestran cambios de configuración (IAM, VM, sinks). Los registros Data Access muestran lecturas de datos, pero están desactivados por defecto en la mayoría de los servicios. VPC Flow Logs muestra el tráfico de red de las VM si estaba habilitado en la subred.
¿Hasta cuándo se puede investigar hacia atrás?
Los registros Admin Activity y System Event se conservan 400 días en el bucket _Required. Los registros Data Access y Policy Denied van al bucket _Default, con 30 días de retención por defecto. Los datos más antiguos solo existen si un sink los exportó.
Lecturas recomendadas
- Responder a credenciales de Google Cloud comprometidas — documentación de Google Cloud.
- Prácticas recomendadas para Cloud Audit Logs — documentación de Google Cloud.
- Matriz IaaS de MITRE ATT&CK — las técnicas a las que se asignan los hallazgos.
- Cloud Threat Horizons Report H2 2025 — las estadísticas de acceso inicial de Google Cloud.