Cloud Forensics: Investigacion en AWS, Azure y GCP

Forense digital en la era cloud

La migracion masiva a infraestructura cloud ha transformado la forense digital. Los principios basicos siguen siendo los mismos (preservar, adquirir, analizar, documentar), pero la implementacion practica cambia radicalmente cuando no tienes acceso fisico al hardware, los recursos son efimeros y la evidencia depende de los logs que el proveedor cloud decida generar.

El modelo de responsabilidad compartida define los limites: el proveedor cloud gestiona la seguridad de la infraestructura fisica, la red y la virtualizacion. El cliente es responsable de sus datos, identidades, configuraciones y aplicaciones. En una investigacion forense, esto significa que ciertos artefactos simplemente no estan disponibles (logs del hipervisor, acceso al hardware) y debes trabajar con lo que el proveedor expone a traves de sus APIs y servicios de logging.

AWS: CloudTrail y mas alla

CloudTrail

AWS CloudTrail es el log de auditoria principal de AWS. Registra cada llamada API realizada en la cuenta de AWS, ya sea desde la consola web, la CLI, los SDKs o los servicios internos de AWS.

Cada evento de CloudTrail incluye:

La identidad del llamante (usuario IAM, rol, servicio).

La accion realizada (nombre de la API: RunInstances, PutObject, CreateUser).

Los parametros de la llamada (que recursos se afectaron).

La IP de origen de la llamada.

El timestamp.

El resultado (exito o error con codigo de error).

# Buscar eventos de un usuario especifico con AWS CLI
aws cloudtrail lookup-events \
  --lookup-attributes "AttributeKey=Username,AttributeValue=usuario_sospechoso" \
  --start-time "2026-06-01T00:00:00Z" \
  --end-time "2026-06-09T23:59:59Z"

# Buscar creacion de usuarios IAM
aws cloudtrail lookup-events \
  --lookup-attributes "AttributeKey=EventName,AttributeValue=CreateUser" \
  --start-time "2026-06-01T00:00:00Z"

# Buscar cambios en security groups
aws cloudtrail lookup-events \
  --lookup-attributes "AttributeKey=EventName,AttributeValue=AuthorizeSecurityGroupIngress" \
  --start-time "2026-06-01T00:00:00Z"

CloudTrail tiene dos niveles de eventos:

Management events (habilitados por defecto): acciones en el plano de control (crear instancias, modificar IAM, cambiar configuraciones). Cubren la mayoria de las investigaciones.

Data events (requieren configuracion explicita): acciones en el plano de datos (GetObject/PutObject en S3, Invoke en Lambda). Criticos para investigar acceso a datos, pero generan un volumen alto de logs y tienen coste adicional.

Si data events no estaban habilitados antes del incidente, no hay forma retroactiva de obtenerlos. Esta es una de las lecciones mas dolorosas de la forense cloud: la preparacion previa es imprescindible.

VPC Flow Logs

VPC Flow Logs registran el trafico de red entre los recursos de la VPC. Cada entrada documenta la IP de origen y destino, puertos, protocolo, bytes, paquetes y si el trafico fue aceptado o rechazado por los security groups y network ACLs.

# Consultar Flow Logs con CloudWatch Logs Insights
# Conexiones rechazadas desde IPs externas
fields @timestamp, srcAddr, dstAddr, dstPort, action
| filter action = "REJECT" and not isIpv4InSubnet(srcAddr, "10.0.0.0/8")
| sort @timestamp desc
| limit 100

Flow Logs no capturan el contenido del trafico (no son PCAP), pero son suficientes para detectar escaneo de puertos, conexiones a IPs de C2, movimiento lateral entre instancias y volumenes de transferencia anormales.

GuardDuty

AWS GuardDuty es un servicio de deteccion de amenazas que analiza CloudTrail, VPC Flow Logs y DNS logs para generar findings automaticos. Los findings de GuardDuty son un punto de partida valioso para la investigacion forense:

Accesos desde IPs anonimas (Tor, VPN conocidas).

Comportamiento inusual de instancias EC2 (comunicacion con dominios de C2 conocidos, mineria de criptomonedas).

Actividad IAM anomala (llamadas API inusuales, acceso desde geolocalizaciones no habituales).

Acceso no autorizado a credenciales (uso de credenciales filtradas).

Adquisicion de evidencia en AWS

Para preservar una instancia EC2 comprometida:

Primero, aisla la instancia. Cambia su security group a uno que bloquee todo el trafico excepto el necesario para el analisis forense. No termines la instancia.

Segundo, crea un snapshot del volumen EBS. El snapshot captura el estado del disco en ese momento y se puede montar en una instancia forense limpia para analisis offline.

# Crear snapshot del volumen EBS
aws ec2 create-snapshot \
  --volume-id vol-0123456789abcdef0 \
  --description "Forense: instancia comprometida caso-2026-001"

# Copiar snapshot a otra region (preservacion adicional)
aws ec2 copy-snapshot \
  --source-region eu-west-1 \
  --source-snapshot-id snap-0123456789abcdef0 \
  --destination-region eu-central-1 \
  --description "Forense backup: caso-2026-001"

Tercero, captura la memoria de la instancia si es posible. Para instancias Linux, se puede usar LiME (Linux Memory Extractor) conectandose via SSM o SSH. Para instancias Nitro, AWS no proporciona acceso directo a la memoria del hipervisor.

Cuarto, recopila los logs de CloudWatch asociados a la instancia, los logs de la aplicacion y los metadatos de la instancia (metadata service, user-data, tags).

Azure: Activity Log y diagnosticos

Azure Activity Log

Azure Activity Log es el equivalente de CloudTrail en el ecosistema Microsoft. Registra las operaciones del plano de control (ARM operations) en los recursos de Azure.

Cada entrada incluye: la operacion realizada, el recurso afectado, la identidad del llamante, el timestamp, la IP de origen y el resultado.

Activity Log retiene 90 dias de datos por defecto. Para retencion a largo plazo, los logs deben enviarse a un Log Analytics Workspace, una cuenta de almacenamiento o un Event Hub.

Azure AD Sign-in Logs

Para investigaciones de compromiso de identidad, los Sign-in Logs de Azure AD (ahora Microsoft Entra ID) son criticos. Registran cada intento de autenticacion con:

El usuario, la aplicacion, la IP de origen, la geolocalizacion, el dispositivo, el resultado (exito, fallo, MFA requerido) y los factores de riesgo detectados.

# KQL query en Log Analytics
// Logins fallidos seguidos de exito (posible fuerza bruta exitosa)
SigninLogs
| where ResultType != "0"
| summarize FailedCount=count() by UserPrincipalName, IPAddress, bin(TimeGenerated, 1h)
| where FailedCount > 10
| join kind=inner (
    SigninLogs
    | where ResultType == "0"
) on UserPrincipalName, IPAddress

Microsoft Defender for Cloud

Defender for Cloud genera alertas de seguridad que complementan los logs nativos. Las alertas cubren actividad anomala en VMs, contenedores, bases de datos, almacenamiento y redes.

Adquisicion de evidencia en Azure

Para VMs Azure, el proceso de adquisicion incluye:

Capturar el disco OS y los discos de datos creando snapshots.

Exportar los logs de diagnostico de la VM.

Recopilar los Network Watcher logs (NSG Flow Logs, packet captures).

Preservar los logs de Azure AD si el incidente involucra compromiso de identidad.

GCP: Cloud Audit Logs

Cloud Audit Logs

GCP genera cuatro tipos de audit logs:

Admin Activity logs: operaciones que modifican la configuracion o metadatos de recursos. Habilitados por defecto, sin coste, retencion 400 dias.

Data Access logs: operaciones que leen la configuracion o los datos de recursos. Requieren habilitacion explicita (excepto BigQuery), generan volumen alto y tienen coste.

System Event logs: acciones del sistema de Google que afectan la configuracion de recursos. Habilitados por defecto.

Policy Denied logs: acciones rechazadas por politicas de seguridad.

# Listar logs de admin activity con gcloud
gcloud logging read \
  'logName="projects/mi-proyecto/logs/cloudaudit.googleapis.com%2Factivity"
   AND timestamp>="2026-06-01T00:00:00Z"' \
  --limit 100 --format json

# Buscar creacion de cuentas de servicio
gcloud logging read \
  'logName="projects/mi-proyecto/logs/cloudaudit.googleapis.com%2Factivity"
   AND protoPayload.methodName="google.iam.admin.v1.CreateServiceAccount"' \
  --format json

VPC Flow Logs de GCP

Similares a los de AWS, registran metadatos de conexiones de red entre recursos de la VPC. Se configuran a nivel de subred y se almacenan en Cloud Logging.

Adquisicion de evidencia en GCP

Para instancias de Compute Engine comprometidas:

Crear un snapshot del disco persistente.

Exportar los logs de Cloud Logging para el periodo relevante.

Capturar la memoria si es posible (requiere acceso SSH a la instancia).

Preservar los metadatos de la instancia y las cuentas de servicio asociadas.

Desafios especificos de la forense cloud

Volatilidad de recursos

En entornos con auto-scaling, serverless (Lambda, Azure Functions, Cloud Functions) y contenedores, los recursos pueden existir durante minutos o segundos. Si no hay logging adecuado preconfigurado, la evidencia desaparece cuando el recurso se destruye.

Para contenedores, los logs del contenedor se pierden cuando se destruye a menos que se envien a un servicio de logging centralizado. Las imagenes de contenedor deben preservarse ya que pueden contener la version del codigo que fue explotada.

Multi-cuenta y multi-region

Las organizaciones grandes usan multiples cuentas cloud (por entorno, por equipo, por aplicacion). Una investigacion puede requerir acceso a logs de docenas de cuentas en multiples regiones. La herramienta de organizacion del proveedor (AWS Organizations, Azure Management Groups, GCP Organization) facilita la busqueda centralizada si esta configurada.

Jurisdiccion legal

Los datos en cloud pueden residir en multiples paises y estar sujetos a diferentes legislaciones. Antes de adquirir evidencia, verifica en que region estan los datos y las implicaciones legales de acceder a ellos, especialmente en investigaciones transfronterizas.

Cifrado y claves

Los proveedores cloud ofrecen cifrado en reposo por defecto, gestionado con sus propias claves (SSE-S3, Azure Storage encryption, Cloud KMS default). Si el cliente usa claves propias (CMK/BYOK), la investigacion requiere acceso a esas claves para descifrar los datos. Documenta quien tiene acceso a las claves y si las claves han sido rotadas durante el incidente.

Preparacion: lo que debes configurar antes del incidente

La forense cloud depende criticamente de la preparacion previa. Los logs que no estaban habilitados antes del incidente no pueden generarse retroactivamente.

Checklist minimo:

Habilitar CloudTrail (AWS) con data events para S3 y Lambda en todas las cuentas y regiones.

Habilitar VPC Flow Logs en todas las VPCs.

Habilitar Azure AD Sign-in Logs con retencion adecuada.

Habilitar GCP Data Access Logs para los servicios criticos.

Centralizar los logs en un servicio de almacenamiento inmutable (S3 con Object Lock, Azure Immutable Blob Storage).

Configurar alertas para actividades de alto riesgo (creacion de usuarios IAM, cambios en policies, deshabilitacion de logging).

Documentar la arquitectura cloud con diagramas actualizados de cuentas, regiones, redes y servicios.

Conclusion

La forense cloud requiere una mentalidad diferente a la forense tradicional. No puedes clonar un disco fisico, no puedes capturar la memoria del hipervisor, y muchos artefactos simplemente no existen si no fueron configurados previamente. La preparacion es la diferencia entre una investigacion exitosa y una sin respuestas.

Los tres grandes proveedores (AWS, Azure, GCP) ofrecen capacidades de logging robustas, pero cada uno tiene su propia estructura, terminologia y limitaciones. El analista DFIR que trabaja en entornos cloud necesita conocer las APIs y los servicios de logging de cada proveedor, y saber donde buscar la evidencia que responda a las preguntas del incidente.

La tendencia es clara: cada vez mas infraestructura esta en cloud, y la forense cloud deja de ser una especializacion para convertirse en un requisito basico del analista DFIR.