Detección sobre logs de nube: qué no detecta el proveedor

Hasta este punto del curso, el trabajo de instrumentación empieza en un host: activas una categoría de auditoría, instalas Sysmon, configuras auditd. Hay una máquina delante, con un sistema operativo al que puedes pedirle más señal. En un proveedor de nube pública esa máquina no existe, o existe pero no es donde ocurre lo importante. Cuando alguien crea una clave de acceso, cambia una política de permisos o lee un objeto de un cubo de almacenamiento, lo que ha ocurrido de verdad es una llamada a una API HTTP contra el plano de control del proveedor, y esa API ya sabe registrar lo que le piden. El problema no es de instrumentación, es de configuración: decidir qué registra ese proveedor de fábrica, qué has dejado apagado sin darte cuenta y qué llamadas concretas delatan a un atacante que ya tiene una credencial válida.

Este módulo no toca bastionado de la nube (IAM restrictivo, cifrado, redes privadas) ni arquitectura de referencia: eso pertenece a un diseño de seguridad, no a la ingeniería de detección. Aquí interesa una pregunta más estrecha y más propia de un SOC: con el registro que el proveedor ya te da, ¿qué evento concreto, con qué campo, delata cada una de las técnicas que un atacante usa una vez tiene acceso a una cuenta de nube?

Qué aprenderás

Por qué la unidad de análisis en la nube es la llamada a la API (identidad, origen, resultado) y no el proceso ni el paquete de red.
Qué registra AWS CloudTrail por defecto y qué no (eventos de gestión frente a eventos de datos), con la diferencia de coste y volumen entre ambos.
Los cuatro tipos de Cloud Audit Logs de Google Cloud y cuáles llegan desactivados de fábrica.
La diferencia entre los registros de auditoría y los de inicio de sesión de Microsoft Entra ID, y su retención real según la licencia.
Ocho casos de uso concretos, con el campo exacto que los delata en cada proveedor: uso de cuenta raíz, desactivación del propio registro de auditoría, claves de larga duración, escalado de privilegios por política, consentimiento OAuth y registro de MFA ajeno, acceso al servicio de metadatos, regiones no usadas y exposición pública de almacenamiento.
Por qué en la nube casi toda detección útil es de identidad y cómo se plantea la detección de un origen imposible.
Cómo llegan estos registros a tu SIEM y qué factor de volumen y retención complica esa tubería.
Qué hacen de verdad las herramientas de evaluación de postura de código abierto, y por qué evaluar la configuración no es lo mismo que detectar un ataque en marcha.

El cambio de modelo: la llamada a la API como unidad de análisis

Un proceso de Windows tiene un padre, una línea de comandos, un usuario de sesión y, con Sysmon, un hash. Una llamada a una API de nube tiene un equivalente con otro nombre: una identidad que la invocó (usuario, rol, cuenta de servicio), un origen (dirección IP, agente de usuario, a veces una VPC de la que salió) y un resultado (éxito, denegación, con qué parámetros exactos). Esos tres ejes, identidad, origen y resultado, son la telemetría de nube en su forma más reducida, y todo lo que sigue en este módulo es una variación sobre ellos.

La ausencia de endpoint tiene una consecuencia práctica que conviene asumir pronto: no hay nada parecido a un Sysmon que instalar para conseguir más detalle del que el proveedor ya decide dar. Puedes activar un tipo de registro que estaba apagado, pero no puedes pedirle a AWS que te cuente algo que su propia API no expone en su respuesta. La superficie de detección está limitada, de origen, por lo que el fabricante del servicio decidió registrar cuando lo diseñó, y esa decisión cambia de un servicio a otro dentro del mismo proveedor.

Este módulo cubre AWS, Google Cloud y Microsoft Entra ID (el directorio de identidades de Microsoft, antes Azure AD) porque son, hoy, los tres puntos de partida más comunes en un SOC que empieza a mirar la nube. Ni la lista de proveedores ni los nombres de sus consolas son estables: vuelvo sobre esto al final. Lo que no cambia con la misma frecuencia son los conceptos (evento de gestión frente a evento de datos, registro siempre activo frente a registro opcional) y esos son el hilo del módulo.

Qué registra cada proveedor por defecto, y qué no

Esta es la sección que más importa del módulo entero. Si el registro de acceso a datos está apagado, o si el tipo de auditoría que cubre tu caso de uso viene desactivado de fábrica, la detección correspondiente no existe por mucho Sigma bien escrito que tengas: no hay evento sobre el que dispararla.

AWS: eventos de gestión y eventos de datos

AWS CloudTrail distingue dos categorías de eventos. Los eventos de gestión (también llamados operaciones de plano de control) cubren la configuración de los recursos: crear una política IAM, lanzar una instancia, crear el propio trail de CloudTrail. Los eventos de datos (plano de datos) cubren las operaciones sobre el contenido de un recurso ya creado: leer un objeto de S3, invocar una función Lambda, escribir en una tabla de DynamoDB. La propia documentación de AWS lo resume así: los eventos de gestión «proporcionan visibilidad sobre las operaciones de gestión realizadas en los recursos de tu cuenta de AWS», y da como ejemplos AttachRolePolicy de IAM o CreateSubnet de EC2 (documentación de eventos de gestión).

La parte que de verdad importa para un SOC es el valor por defecto de cada categoría. Cito textualmente ambas páginas oficiales: «por defecto, los trails y los almacenes de eventos están configurados para registrar eventos de gestión» y, en la página de eventos de datos, «por defecto, los trails y los almacenes de eventos no registran eventos de datos. Se aplican cargos adicionales por los eventos de datos» (documentación de eventos de datos). La misma página añade que los eventos de datos «son a menudo actividades de alto volumen», lo que explica por qué AWS no los activa solos: un bucket con tráfico normal genera muchas más llamadas GetObject que cualquier cuenta genera llamadas CreateUser.

La consecuencia práctica es que, con la configuración de fábrica, ves quién creó, borró o modificó recursos, pero no ves quién leyó qué objeto dentro de un bucket S3 ni qué función Lambda se invocó y con qué parámetros. Si tu caso de uso es exfiltración de datos desde un bucket concreto, necesitas activar eventos de datos de S3 para ese bucket de forma explícita, con el coste y el volumen que eso implica.

Google Cloud: cuatro tipos de auditoría, dos de ellos apagados

Google Cloud divide sus Cloud Audit Logs en cuatro tipos. Cito la definición oficial de cada uno:

Tipo	Qué registra	¿Activo por defecto?
Admin Activity	Llamadas que modifican la configuración o los metadatos de un recurso	Sí, siempre. No se puede desactivar
System Event	Cambios de configuración hechos por los propios sistemas de Google Cloud, no por un usuario	Sí, siempre. No se puede desactivar
Data Access	Llamadas que leen la configuración, los metadatos o el contenido de un recurso	No, salvo la excepción de BigQuery
Policy Denied	Casos en los que un servicio deniega el acceso por una violación de política de seguridad	Sí, por defecto

La página oficial es explícita sobre el motivo de que Data Access venga apagado: «los registros de auditoría de acceso a datos… están desactivados por defecto porque los registros de auditoría pueden llegar a ser bastante grandes» (documentación de Cloud Audit Logs). La excepción es BigQuery, cuyos registros de Data Access sí vienen activados de fábrica, algo que conviene recordar porque rompe el patrón general y puede hacer pensar, por error, que toda la categoría está cubierta.

Traducido a un caso concreto: si nadie ha activado explícitamente Data Access para Cloud Storage o para Compute Engine, tienes un registro completo de quién creó o borró un bucket, pero ningún registro de quién leyó los objetos que hay dentro. Es la misma trampa que en AWS, con otro nombre.

Microsoft Entra ID: auditoría, inicio de sesión y una retención que caduca

Entra ID separa dos registros de actividad con propósitos distintos. Los registros de auditoría cubren cambios de configuración del directorio: usuarios, grupos, aplicaciones, licencias. Los registros de inicio de sesión cubren, como su nombre indica, los intentos de autenticación, con cuatro variantes (interactivos, no interactivos, de entidad de servicio y de identidad administrada), según la propia documentación de Microsoft (documentación de registros de inicio de sesión). Los dos se generan siempre; lo que varía por licencia no es si existen, sino cuánto tiempo los conservas antes de que desaparezcan.

La tabla oficial de retención, verificada en esta sesión, es esta:

Registro	Entra ID Free	Entra ID P1	Entra ID P2
Registros de auditoría	Siete días	30 días	30 días
Registros de inicio de sesión	Siete días	30 días	30 días
Inicios de sesión de riesgo (Identity Protection)	Siete días	30 días	90 días

Fuente: retención de datos de Microsoft Entra. La propia página lo deja sin ambigüedad: si actualizas de Free a una licencia de pago sin haber exportado antes, «solo los datos que aún estén dentro del periodo de retención gratuito (hasta siete días) están disponibles» (la retención no es retroactiva). Con la licencia más cara del catálogo, un registro de auditoría desaparece de la consola a los 30 días si no lo has sacado a otro sitio. Para un SOC que investiga algo descubierto con retraso, ese plazo se agota rápido.

Un caso especial dentro de este mismo proveedor: las cuentas de acceso de emergencia (lo que en otros sitios se llama «break glass»), pensadas para no quedarte fuera del tenant si falla la federación o el MFA de los administradores habituales. Microsoft recomienda mantener al menos dos y no depender de la sincronización con el entorno local, y su guía de gestión insiste en un punto que conecta directamente con este módulo: «monitoriza la actividad de inicio de sesión y de auditoría de las cuentas de acceso de emergencia» con alertas dedicadas para cada uso, porque una cuenta pensada para no usarse nunca es, precisamente por eso, la más fácil de vigilar sin ruido de fondo (gestión de cuentas de acceso de emergencia).

Ocho casos de uso que el proveedor no detecta por ti

Lo que sigue son ocho patrones de abuso reales, cada uno con el campo o el nombre de evento que lo delata en el proveedor donde aplica. Ninguno afirma una tasa de detección ni un porcentaje de falsos positivos: eso depende de tu entorno y de qué tan ruidosa sea tu actividad legítima con ese mismo campo.

Uso de la cuenta raíz o de una cuenta de emergencia

En AWS, cada llamada a la API queda envuelta en un elemento userIdentity que dice qué tipo de identidad hizo la petición. Uno de los valores posibles de su campo type es, literalmente, Root: «la petición se hizo con las credenciales de tu cuenta de AWS», según la propia referencia del elemento (referencia de userIdentity). El usuario raíz de AWS tiene acceso ilimitado a la cuenta y a la facturación; la propia guía prescriptiva de AWS recomienda «no usar esta cuenta y monitorizarla ante cualquier actividad» (monitorización del usuario raíz). GuardDuty tiene un hallazgo dedicado, Policy:IAMUser/RootCredentialUsage, con severidad baja por defecto (baja porque el uso legítimo también existe: hay un puñado de tareas que solo el usuario raíz puede hacer).

La lógica de detección, en Sigma, es casi literal: coincide userIdentity.type igual a Root y excluye los eventos que el propio AWS genera en nombre de la cuenta (eventType igual a AwsServiceEvent), porque algunas tareas de servicio se atribuyen a la raíz sin que haya habido una persona detrás del teclado. Es exactamente la regla real de SigmaHQ que reproduzco en el ejercicio de este módulo.

En Microsoft Entra ID el equivalente funcional es la cuenta de acceso de emergencia descrita arriba: no hay un «root» único, pero sí una cuenta con el rol de administrador global reservada para catástrofes, y su uso se vigila igual, cruzando los registros de inicio de sesión por el identificador de objeto de esa cuenta contra cualquier actividad fuera de un simulacro programado.

Desactivar o modificar el propio registro de auditoría

Este es, con diferencia, el caso de uso que más deberías priorizar: es la primera acción de un atacante competente que ya tiene permisos suficientes, porque todo lo que haga después deja de dejar rastro. En AWS, el evento a vigilar es cualquier llamada de gestión sobre el propio servicio CloudTrail con nombre StopLogging, UpdateTrail o DeleteTrail. En Google Cloud, el paralelo es modificar o eliminar el sink que exporta los registros de auditoría fuera del bucket _Required (los tipos Admin Activity y System Event no se pueden desactivar, pero el sink que los saca hacia tu SIEM sí se puede borrar, con lo que dejas de recibirlos aunque Google los siga generando). En Entra ID, el paralelo es modificar o eliminar la configuración de diagnóstico que envía los registros de auditoría y de inicio de sesión a tu Event Hub o a tu cuenta de almacenamiento.

Aquí toca una advertencia sobre el propio marco que este curso usa como referencia. MITRE ATT&CK v19 (28 de abril de 2026) dividió la antigua táctica de Defense Evasion en dos, Stealth y Defense Impairment, y de paso reorganizó varias subtécnicas de T1562 (Impair Defenses). La que cubría exactamente este caso, «Disable Cloud Logs», ya no es T1562.008: se fusionó en una técnica nueva, T1685 (Disable or Modify Tools), bajo la subtécnica T1685.002, «Disable or Modify Cloud Log», creada el 14 de abril de 2026 dentro de la táctica Defense Impairment. El propio repositorio de SigmaHQ hizo el cambio el mismo día que salió la v19: la confirmación 34c5d66c retagueó 1.612 reglas de golpe para pasar de las etiquetas antiguas de ATT&CK a las de la v19. Si encuentras hoy una regla o un artículo que todavía cite T1562.008 para este caso, no está mal escrito, está desfasado: el identificador cambió, el comportamiento que describe no.

Creación de claves de acceso de larga duración

Una credencial temporal caduca sola. Una clave de acceso de IAM no, y esa es exactamente la razón por la que un atacante la prefiere para mantener el acceso después de que cierres el vector de entrada original. La propia matriz ATT&CK lo describe en T1098.001 (Account Manipulation: Additional Cloud Credentials), con el ejemplo textual de que un atacante «puede usar la API CreateAccessKey en AWS o el comando gcloud iam service-accounts keys create en GCP para añadir claves de acceso a una cuenta». El evento a vigilar en CloudTrail es, literalmente, CreateAccessKey; en Google Cloud, la llamada al método correspondiente del servicio IAM sobre una cuenta de servicio.

Lo que hace útil esta detección no es la existencia de la llamada (crear claves es una operación legítima habitual en cualquier pipeline de automatización), sino el contexto: una clave creada por una identidad que normalmente no gestiona credenciales, sobre una cuenta de servicio con privilegios altos, o inmediatamente después de una escalada de privilegios. Sin ese contexto, alertar sobre cada CreateAccessKey en una cuenta con integración continua activa genera más ruido del que un analista puede sostener.

Cambios de política que amplían privilegios

El mismo patrón que en el punto anterior, aplicado a permisos en vez de a credenciales. ATT&CK lo cubre en T1098.003 (Account Manipulation: Additional Cloud Roles), con una frase que resume por qué importa: «con permisos suficientes, una cuenta comprometida puede obtener acceso casi ilimitado a datos y configuraciones (incluida la capacidad de restablecer las contraseñas de otros administradores)». En AWS, los nombres de evento a vigilar son PutUserPolicy, AttachUserPolicy, AttachRolePolicy y CreatePolicyVersion; en Entra ID, cualquier asignación nueva de un rol con privilegios (Global Administrator, Privileged Role Administrator) fuera del flujo habitual de Privileged Identity Management.

Este caso de uso es, de los ocho, el más difícil de afinar bien, porque la gestión de permisos legítima genera exactamente los mismos eventos que el abuso. Lo que separa una detección que un analista puede usar de una que nadie atiende es de nuevo el contexto: quién hizo el cambio, sobre qué identidad, y si esa identidad ganó de inmediato después un privilegio que antes no tenía y que usó en los minutos siguientes.

Consentimiento a una aplicación ajena y registro de un método de autenticación nuevo

Estos dos son específicos de Entra ID y suelen ir juntos en un mismo ataque. El primero es el «consentimiento ilícito» (illicit consent grant): una aplicación OAuth, a menudo disfrazada de herramienta legítima, pide permisos amplios sobre el correo o los archivos de un usuario, y ese usuario, engañado por una pantalla de consentimiento que parece normal, acepta. Queda registrado en el log de auditoría con la categoría ApplicationManagement y el nombre de actividad exacto Consent to application, según la referencia oficial de actividades auditables (referencia de actividades de auditoría de Entra). Los campos que importan para investigarlo son el identificador de la aplicación, si el consentimiento fue de administrador (aplicable a todo el tenant) o de un único usuario, y el alcance de permisos concedido.

El segundo, registrar un método de autenticación nuevo en una cuenta ajena, aparece en el mismo log bajo la categoría UserManagement, con el nombre de actividad User registered security info (existe también Admin registered security info, para cuando lo hace un administrador en nombre de otro, un caso distinto y en general legítimo). Un atacante que ya robó una sesión suele registrar su propia clave de acceso sin contraseña o su propio número de teléfono como segundo factor, precisamente para no depender de un token de sesión que puede caducar o revocarse. La señal que separa esto de un registro legítimo no está solo en el nombre del evento: está en cruzarlo con el registro de inicio de sesión de esa misma franja horaria y comprobar si la dirección IP o el dispositivo encajan con el patrón habitual del usuario.

Acceso al servicio de metadatos de la instancia desde una petición web

Toda instancia de EC2 (y su equivalente en otros proveedores) expone un servicio interno, alcanzable solo desde dentro de la propia máquina en la dirección 169.254.169.254, que entrega las credenciales temporales del rol IAM asignado a esa instancia. Si una aplicación web que corre en esa instancia tiene una vulnerabilidad de SSRF (el detalle de cómo se explota esa clase de fallo, con inyección de parámetros y validación de URL, pertenece al curso de Hacking Web), un atacante puede forzarla a hacer una petición HTTP contra esa dirección interna y hacerse con las credenciales del rol sin haber pisado nunca la máquina. ATT&CK documenta la técnica en T1552.005 (Unsecured Credentials: Cloud Instance Metadata API).

La primera versión de este servicio (IMDSv1) respondía a una simple petición GET, sin más control, lo que la hacía trivialmente vulnerable a SSRF. La versión actual (IMDSv2) exige primero una petición PUT que devuelve un token de sesión, y ese token solo viaja un salto de red por defecto (HttpPutResponseHopLimit a 1), lo que corta la mayoría de los SSRF clásicos porque estos casi nunca pueden fijar cabeceras personalizadas ni forzar un método PUT (configuración de opciones de metadatos de instancia). Que la instancia use una versión u otra queda registrado igualmente: CloudTrail añade a las llamadas hechas con esas credenciales un contexto ec2RoleDelivery que vale 1.0 si vinieron de IMDSv1 y 2.0 si vinieron de IMDSv2, así que auditar ese campo en tu propio entorno te dice qué instancias siguen expuestas al vector más simple, aunque forzar IMDSv2 ya sea bastionado y no detección.

Lo que sí detecta el SOC, sin tocar la configuración de la instancia, es el uso posterior de esas credenciales fuera de donde deberían estar. GuardDuty tiene dos hallazgos para esto: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS, cuando las credenciales de una instancia concreta se usan desde una IP fuera de AWS, y su variante .InsideAWS, cuando se usan desde otra cuenta de AWS que no es la propietaria de la instancia. El principio es el mismo que en el resto del módulo: la credencial en sí no dice nada, el origen desde el que se usa sí.

Creación de recursos en regiones que la organización no usa

Cada evento de CloudTrail lleva un campo awsRegion con la región donde se ejecutó la llamada (referencia de contenido del registro). Un atacante que consigue una credencial válida y quiere pasar desapercibido tiene un incentivo claro para operar en una región donde tu organización no tiene presencia habitual: si nunca miras esa región, nadie va a notar una instancia nueva minando criptomoneda ahí. ATT&CK lo recoge en T1535 (Unused/Unsupported Cloud Regions), con la frase «si un adversario crea recursos en una región no usada, puede ser capaz de operar sin ser detectado».

La detección aquí no depende de ningún campo exótico: basta con tener un trail multirregión (o el equivalente organizativo) y comparar el awsRegion de cada evento de creación de recursos contra una lista blanca de las regiones que tu organización usa de verdad. Es la regla más sencilla de las ocho, y también una de las que más falsos negativos genera si la lista blanca no se mantiene al día cuando el negocio abre una región nueva.

Exfiltración por permisos de lectura pública en almacenamiento

El vector clásico de exposición pública de datos en la nube no requiere robar nada: alguien cambia un permiso y el bucket queda abierto al mundo. En AWS, las llamadas a vigilar son PutBucketAcl y PutBucketPolicy, y el campo que confirma la exposición real es la lista de concesiones de la política, buscando el URI del grupo especial http://acs.amazonaws.com/groups/global/AllUsers (o su variante AuthenticatedUsers, que en la práctica también equivale a cualquiera con una cuenta de AWS). GuardDuty automatiza justo este razonamiento con el hallazgo Policy:S3/BucketPublicAccessGranted, que usa un motor de razonamiento automatizado (Zelkova) para decidir si, tras el cambio, el bucket es de verdad accesible desde fuera, no solo si la llamada tuvo ese aspecto.

En Google Cloud el paralelo es una llamada al método SetIamPolicy sobre un bucket que añade una vinculación con el miembro especial allUsers o allAuthenticatedUsers. El registro de auditoría anota este cambio en un campo policyDelta.bindingDeltas, con esta forma exacta según la documentación oficial: policyDelta: { bindingDeltas: [ action: "ADD", role: "roles/logging.privateLogViewer", member: "user:user@example.com" ] } (estructura de los registros de auditoría). Sustituye el member del ejemplo por allUsers y tienes la firma exacta de una exposición pública.

Identidad como perímetro

En una red tradicional, la mayoría de las detecciones de este curso hasta ahora dependen de dónde vive el tráfico: qué host habla con qué host, qué segmento cruza un paquete. En la nube esa frontera casi no existe: cualquier llamada a la API, hecha desde cualquier lugar del planeta con una credencial válida, llega igual de rápido al plano de control. Por eso la mayoría de las detecciones que de verdad aportan valor en un SOC de nube son de identidad (quién es, desde dónde opera, si ese origen encaja con su historial) y no de red.

El patrón más citado es el de origen imposible («impossible travel»): la misma identidad, autenticada con éxito en dos ubicaciones geográficas incompatibles con el tiempo transcurrido entre ambas. Cada proveedor lo aborda con un nombre distinto. GuardDuty lo llama UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B, «se observaron múltiples inicios de sesión de consola exitosos en todo el mundo» para el mismo usuario de IAM en una ventana de tiempo próxima. Entra ID Protection lo llama «Atypical travel», detecta «un inicio de sesión casi simultáneo desde dos partes distintas del mundo» y exige licencia Entra ID P2 para ver el detalle completo del riesgo (con licencias inferiores solo aparece un genérico «se detectó riesgo adicional», sin explicar cuál). Google Cloud lo cubre desde Security Command Center con Event Threat Detection, que incluye entre sus hallazgos el acceso de una cuenta de IAM «desde ubicaciones anómalas, según la geolocalización de las direcciones IP de origen» (visión general de Event Threat Detection).

Lo que las tres implementaciones comparten, más allá del nombre comercial, es el mismo cálculo de fondo: coger la geolocalización de la dirección IP de cada inicio de sesión exitoso y comprobar si la distancia entre dos eventos consecutivos de la misma identidad es físicamente recorrible en el tiempo que las separa. Ninguna de las tres te da ese cálculo gratis si no le das los datos que necesita: en AWS y GCP hace falta el registro de gestión con la IP de origen; en Entra ID hace falta el registro de inicio de sesión y, junto a él, la licencia adecuada para que el motor de riesgo entre en juego.

Ingesta: cómo llega esto al SIEM, y qué cuesta

Cada proveedor tiene su propia tubería de salida, y las tres comparten el mismo cuello de botella: volumen y retención van de la mano del coste, así que no hay una opción de «actívalo todo y ya decidiré después».

En AWS, un trail entrega sus eventos a un bucket de S3, y desde ahí lo habitual es enganchar una notificación de S3 (vía SNS o EventBridge) que dispare la ingesta hacia tu SIEM en cuanto llega un fichero nuevo, en vez de sondear el bucket a intervalos. Sin trail, solo tienes el historial de eventos por defecto, gratuito, pero limitado a 90 días y solo de eventos de gestión (historial de eventos de CloudTrail). Activar eventos de datos multiplica el volumen, sobre todo si el bucket que vigilas recibe tráfico alto de lectura, y ese volumen es justo lo que hay que dimensionar antes de activarlo en producción, no después.

En Google Cloud, la vía habitual es un sink de exportación que envía los registros a un topic de Pub/Sub, desde donde el SIEM (o un conector como Elastic Agent) los consume por suscripción. Para cubrir una organización entera sin configurar un sink por proyecto existen los sinks agregados, creados a nivel de organización o de carpeta con la bandera --include-children, como en este ejemplo real de la documentación (a nivel de carpeta; para organización se sustituye --folder por --organization):

gcloud logging sinks create SINK_NAME 
  pubsub.googleapis.com/projects/PROJECT_ID/topics/TOPIC_ID --include-children 
  --folder=FOLDER_ID --log-filter="logName:activity"

Fuente: sinks agregados de Cloud Logging. La retención dentro de la propia plataforma, sin exportar nada, ya varía por tipo de bucket: los registros que van al bucket _Required (Admin Activity, System Event, y algunos registros de Workspace) se quedan ahí 400 días sin que puedas cambiarlo, mientras que el bucket _Default, donde caen los Data Access que actives, se queda en 30 días salvo que configures una retención distinta (almacenamiento de entradas de registro).

En Entra ID, la vía es la configuración de diagnóstico, que puede archivar en una cuenta de almacenamiento o transmitir en tiempo casi real a un Event Hub, desde donde un SIEM como Splunk o Sentinel lo consume (transmisión de registros de Entra a un Event Hub). Dado que la retención nativa es de solo 7 o 30 días según la licencia, como vimos antes, en Entra ID esta exportación no es una mejora opcional: es la única forma de que un registro de auditoría sobreviva más allá de un mes.

Evaluar la postura no es detectar

Existe una familia de herramientas de código abierto que escanean la configuración de una cuenta de nube y avisan de fallos: un bucket público, una clave sin rotar, un grupo de seguridad abierto a cualquier IP. Se llaman genéricamente CSPM (Cloud Security Posture Management) y merece la pena nombrar algunas, con su licencia comprobada en esta sesión, porque son gratuitas y útiles, aunque no resuelven el problema de este módulo.

Herramienta	Qué hace	Licencia
Prowler	Cientos de comprobaciones de seguridad y cumplimiento sobre AWS, Azure, GCP y otros proveedores	Apache-2.0
Scout Suite	Auditoría multicloud que reúne datos de configuración y resalta zonas de riesgo	GPL-2.0
Steampipe	Consulta la configuración de tus servicios de nube con SQL, útil para construir tus propios controles	AGPL-3.0

Comprueba tú mismo, en el momento de usarlas, si siguen recibiendo actualizaciones regulares antes de apoyar en ellas ningún proceso: el ritmo de mantenimiento de un proyecto de código abierto cambia más rápido de lo que tarda este módulo en quedar desfasado. Los CIS Benchmarks para AWS, Azure y GCP son la referencia de facto para muchas de estas comprobaciones, aunque su licencia (Creative Commons Attribution-NonCommercial-ShareAlike 4.0) permite citarlos y enlazarlos, no reproducir sus tablas de controles en un sitio con publicidad como este.

Lo que ninguna de estas herramientas hace, y aquí está la distinción que importa para un ingeniero de detección, es mirar eventos según ocurren. Escanean una fotografía de la configuración en el momento en que las ejecutas y comparan esa fotografía contra un catálogo de reglas. Si un bucket estuvo público durante veinte minutos entre dos escaneos, ninguna herramienta de postura lo vio pasar; solo el registro de auditoría, consultado como flujo continuo por tu SIEM, tiene esa granularidad. Postura y detección se complementan (la primera reduce la superficie, la segunda vigila lo que queda expuesto o lo que cambia entre fotografías), pero confundirlas lleva a creer que un informe de Prowler limpio significa que no hace falta vigilar CloudTrail. No significa eso.

El límite honesto de este módulo

Los tres proveedores cambian el nombre de sus consolas, reorganizan sus menús y lanzan funciones nuevas con una frecuencia que ningún texto escrito puede seguir. La propia historia de T1685.002 contada arriba lo demuestra dentro de este mismo módulo: un identificador que llevaba años siendo la referencia estándar cambió de la noche a la mañana, y el ecosistema entero (incluido el repositorio de reglas más usado del sector) tuvo que actualizarse el mismo día. Por eso este módulo se ha escrito a nivel de concepto y de nombre de campo (userIdentity.type, policyDelta.bindingDeltas, ec2RoleDelivery), no de ruta de menú ni de captura de pantalla, y cada afirmación operativa lleva la fecha en que se comprobó. Cuando dentro de un año la consola tenga otro aspecto, el campo seguirá ahí, con el mismo nombre casi con toda seguridad, y la documentación oficial enlazada seguirá siendo la fuente que hay que abrir para el «cómo» exacto de ese momento.

Laboratorio: escribe la lógica de detección sobre BOTSv3

El dataset Boss of the SOC v3 de Splunk, ya presentado en el laboratorio del módulo 2 de este curso, incluye telemetría real de AWS entre sus más de cien tipos de origen: los sourcetypes aws:cloudtrail y aws:cloudwatch:guardduty, cargados junto al resto de la investigación de la empresa ficticia Frothly. Si ya tienes una instancia de Splunk aparte para este dataset (recuerda que BOTSv3 está pensado para Splunk, no para Wazuh), este es el ejercicio que por fin le da uso a esa parte del laboratorio.

Vas a escribir la lógica de detección, en formato de búsqueda SPL, para tres de los ocho casos de uso de este módulo. No incluyo aquí ninguna captura de resultado: cada índice de BOTSv3 puede devolver eventos distintos según cómo lo hayas cargado, así que ejecuta cada búsqueda tú mismo y verifica en tu entorno qué aparece.

Empieza por el uso de la cuenta raíz, con la traducción directa a SPL de la regla real de SigmaHQ que cito más abajo: coincide el tipo de identidad raíz y excluye los eventos generados por el propio servicio.
```
index=botsv3 sourcetype=aws:cloudtrail userIdentity.type=Root
NOT eventType=AwsServiceEvent
| table _time, eventName, eventSource, sourceIPAddress, userIdentity.arn
```

Sigue con la desactivación o modificación del trail de CloudTrail, igual de directa: busca los tres nombres de evento que tocan la configuración del propio registro.

index=botsv3 sourcetype=aws:cloudtrail eventSource=cloudtrail.amazonaws.com
(eventName=StopLogging OR eventName=UpdateTrail OR eventName=DeleteTrail)
| table _time, eventName, userIdentity.arn, sourceIPAddress, requestParameters.Name

Cierra con la exposición pública de un bucket S3. Aquí no hay una regla pública que reutilizar; la escribes con los nombres de evento y el marcador de grupo público que vimos en la sección de exfiltración: busca los dos nombres de evento que cambian permisos y filtra por la presencia del URI de acceso público en cualquiera de los campos de la política.
```
index=botsv3 sourcetype=aws:cloudtrail
(eventName=PutBucketAcl OR eventName=PutBucketPolicy)
requestParameters="*acs.amazonaws.com/groups/global/AllUsers*"
| table _time, eventName, requestParameters.bucketName, userIdentity.arn, sourceIPAddress
```

Para la primera búsqueda, compara tu versión con la regla real de la que la adapté, tomada del repositorio de SigmaHQ (licencia DRL 1.1, autor vitaliy0x1), en la revisión fijada por el commit de retagueo a ATT&CK v19 citado en este módulo:

title: AWS Root Credentials
id: 8ad1600d-e9dc-4251-b0ee-a65268f29add
status: test
description: Detects AWS root account usage
references:
    - https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html
author: vitaliy0x1
date: 2020-01-21
modified: 2022-10-09
tags:
    - attack.privilege-escalation
    - attack.initial-access
    - attack.persistence
    - attack.stealth
    - attack.t1078.004
logsource:
    product: aws
    service: cloudtrail
detection:
    selection_usertype:
        userIdentity.type: Root
    selection_eventtype:
        eventType: AwsServiceEvent
    condition: selection_usertype and not selection_eventtype
falsepositives:
    - AWS Tasks That Require AWS Account Root User Credentials https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html
level: medium

Y la segunda, contra esta, del mismo repositorio y autor:

title: AWS CloudTrail Important Change
id: 4db60cc0-36fb-42b7-9b58-a5b53019fb74
status: test
description: Detects disabling, deleting and updating of a Trail
references:
    - https://docs.aws.amazon.com/awscloudtrail/latest/userguide/best-practices-security.html
author: vitaliy0x1
date: 2020-01-21
modified: 2022-10-09
tags:
    - attack.defense-impairment
    - attack.t1685.002
logsource:
    product: aws
    service: cloudtrail
detection:
    selection_source:
        eventSource: cloudtrail.amazonaws.com
        eventName:
            - StopLogging
            - UpdateTrail
            - DeleteTrail
    condition: selection_source
falsepositives:
    - Valid change in a Trail
level: medium

Fuente de ambas reglas: aws_root_account_usage.yml y aws_cloudtrail_disable_logging.yml, repositorio SigmaHQ/sigma, licencia DRL 1.1 (recuerda: si publicas resultados de estas reglas en una vista compartida, la licencia exige mostrar el autor junto a las coincidencias). Fíjate en que ya llevan la etiqueta attack.t1685.002 y no la antigua attack.t1562.008: es la misma reorganización de la que hablaba en la sección anterior, ya reflejada en el propio repositorio.

Preguntas frecuentes

¿Necesito activar todos los eventos de datos de CloudTrail y todos los registros de Data Access de GCP desde el primer día?

No, y probablemente no deberías. Ambos son de alto volumen por diseño, así que actívalos primero sobre los recursos que de verdad concentran el riesgo (los buckets con datos sensibles, las funciones que procesan pagos) y amplía desde ahí según lo que tu presupuesto de ingesta y tu SIEM puedan digerir. Activar todo de golpe en una cuenta grande suele terminar en un volumen que nadie llega a consultar, lo que no es mejor que no tener el registro.

¿Por qué GuardDuty y Security Command Center no sustituyen este módulo?

Porque son motores de detección gestionados con su propio catálogo cerrado de hallazgos, no una vía para escribir tus propias reglas sobre eventos que a ti te importan y que ellos no cubren. Son un complemento excelente (buena parte de los hallazgos citados en este módulo son de GuardDuty, y no hace falta reescribirlos a mano si ya los tienes), pero un SOC que solo se apoya en el catálogo del proveedor deja fuera cualquier caso de uso específico de su propio negocio, que es justo lo que un ingeniero de detección debería estar aportando.

¿Este módulo sustituye tener a alguien que sepa arquitectura de nube en el equipo?

No, y no lo pretende. Aquí se asume que la cuenta ya existe, con su propia configuración de red e IAM, y el trabajo consiste en decidir qué registrar y cómo detectar sobre lo registrado. Diseñar esa arquitectura con criterios de seguridad (segmentación, privilegio mínimo, cifrado) es un trabajo previo y distinto, más cercano a la ingeniería de la nube que a la ingeniería de detección.

¿Cómo sé si mi organización tiene Entra ID P1, P2 o solo Free, y por qué me importa tanto en este módulo?

Porque cambia lo que puedes ver y durante cuánto tiempo: sin P1 o P2 pierdes el detalle de los inicios de sesión de riesgo (te quedas con un genérico «riesgo detectado» sin explicación), y sin exportar los registros a otro sitio, ninguna licencia te da más de 30 días de retención de auditoría (con Free, solo siete). Pregunta a quien administre el tenant qué licencia tiene asignada, no lo asumas por el tamaño de la organización.

¿Vale la pena escribir reglas Sigma para logsource de nube si los nombres de campo cambian tan rápido como dice el módulo?

Sí, porque lo que cambia con esa frecuencia son los nombres de las técnicas en marcos como ATT&CK y los menús de las consolas, no tanto los nombres de los campos de un evento ya estabilizado como userIdentity.type o eventName, que llevan años sin tocarse en CloudTrail. Escribir la regla contra el campo, con una etiqueta ATT&CK que revisas cuando cambie de versión, separa el trabajo de detección (estable) del trabajo de mantenimiento de etiquetas (que sí toca repetir de vez en cuando, como demuestra el propio SigmaHQ).

¿Qué hago si mi proveedor de nube no es ninguno de los tres que cubre este módulo?

Busca la misma pareja de preguntas para el tuyo: qué categorías de registro existen y cuáles vienen desactivadas por defecto, y qué campo identifica la identidad, el origen y el resultado de cada llamada. Casi todos los proveedores serios (Oracle Cloud, Alibaba Cloud, DigitalOcean) tienen algún equivalente de estos tres ejes, aunque lo llamen de otra forma; el marco de este módulo se aplica igual aunque los nombres no coincidan.

Módulo 13: Detección sobre logs de nube