Forense en la nube
Todo lo anterior asumía acceso físico o, como mínimo, administrativo completo al sistema: adquirir su disco, su memoria, su tráfico de red. En la nube esa premisa desaparece: no hay hardware que tocar, el proveedor controla la capa física, y buena parte de lo que antes se adquiría directamente ahora solo existe como un registro en un log que hay que haber configurado para que exista antes del incidente. Este módulo cierra la fase de red y sistemas aplicando los mismos principios a un terreno sin disco ni memoria que adquirir.
- Entender el modelo de responsabilidad compartida y qué implica para un investigador forense.
- Consultar el log central de auditoría de AWS (CloudTrail) y de Azure/M365 (Activity Log, Unified Audit Log).
- Identificar qué evidencia cloud es el equivalente funcional de una imagen de disco, un volcado de memoria o un PCAP.
- Reconocer por qué la retención de logs tiene que activarse de antemano, no después del incidente.
Descarga el paquete de evidencia, descomprímelo y lee el LEEME.md antes de empezar. Verifica el hash según el módulo 2 antes de analizar nada:
SHA-256: 3c9f36ceac4fc9db0341a0bf7631147c9034adb65693feb41ebae75bf2364459
Herramientas: jq, AWS CLI, o un editor de texto/JSON
⬇️ Descargar M16_CloudTrailAWS.zip Ver solución paso a paso →
1. Por qué el cloud cambia el modelo forense
El modelo de responsabilidad compartida reparte la seguridad entre el proveedor cloud (seguridad de la nube: el hardware físico, la virtualización, la red del proveedor) y el cliente (seguridad en la nube: su configuración, sus credenciales, sus datos). Para el analista forense, esto significa que todo lo que en los módulos 2, 3 y 8 se adquiría directamente —disco, memoria física— ahora vive del lado del proveedor, inaccesible sin su intervención. Lo que queda disponible son los logs de la plataforma y lo que el propio cliente haya configurado capturar.
2. AWS CloudTrail: el log central de la nube de Amazon
CloudTrail registra, por defecto en la mayoría de cuentas, cada llamada a la API de AWS: quién la hizo, desde qué IP, con qué credenciales, a qué hora, y con qué resultado. Es, en cierto sentido, el equivalente en la nube al Event ID 4688 del módulo 6 —creación de procesos— pero para acciones administrativas en lugar de ejecución de programas.
$ aws cloudtrail lookup-events --lookup-attributes AttributeKey=Username,AttributeValue=compromised-user --max-results 5
EventName: GetObject Bucket: finanzas-internas SourceIP: 203.0.113.44
EventName: PutBucketPolicy Bucket: finanzas-internas SourceIP: 203.0.113.44
EventName: CreateAccessKey UserName: backup-svc SourceIP: 203.0.113.44La misma IP que ya apareció en el módulo 6 (RDP), en el módulo 11 (HTTP) y en el módulo 12 (beaconing) reaparece aquí accediendo directamente a un bucket de S3 y creando una clave de acceso nueva — persistencia en la nube, el equivalente directo a la tarea programada del módulo 6, pero sobre la propia cuenta de AWS.
3. Azure y Microsoft 365: Activity Log y Unified Audit Log
| Fuente | Qué registra |
|---|---|
| Azure Activity Log | Operaciones a nivel de suscripción: creación/eliminación de recursos, cambios de configuración — el equivalente de CloudTrail en Azure. |
| Microsoft 365 Unified Audit Log | Actividad dentro de los propios servicios de M365: acceso a buzones de correo, descargas de SharePoint/OneDrive, reglas de reenvío de correo creadas. |
| Entra ID Sign-in logs | Inicios de sesión: ubicación, dispositivo, aplicación — permite detectar patrones como un impossible travel (inicios de sesión desde dos ubicaciones geográficamente incompatibles en un lapso de tiempo demasiado corto), el equivalente cloud a cruzar LogonType y origen en el Event ID 4624 del módulo 6. |
4. Qué evidencia cloud sustituye a qué artefacto on-premise
| En un equipo físico (módulos 2-11) | Equivalente en la nube |
|---|---|
| Imagen de disco (módulo 2) | Snapshot de un volumen de almacenamiento (EBS en AWS, Managed Disk en Azure) — tomado, igual que una imagen forense, en un punto concreto en el tiempo. |
| Volcado de memoria (módulo 8) | Mucho más limitado: pocas plataformas permiten un volcado de memoria completo de una instancia en marcha sin herramientas especiales instaladas de antemano en esa instancia. |
| Captura PCAP (módulo 11) | VPC Flow Logs (AWS) / NSG Flow Logs (Azure): no capturan el contenido de los paquetes, pero sí metadatos de cada conexión (origen, destino, puertos, bytes transferidos) — suficiente para detectar beaconing o exfiltración (módulo 12) aunque no para un "Follow TCP Stream" literal. |
| Write-blocker (módulo 2) | Versionado de objetos y Object Lock en S3: impide o audita la sobrescritura de un objeto, el equivalente cloud a proteger una evidencia de escritura accidental. |
5. El reto que decide si hay evidencia o no: la retención configurada de antemano
6. Consultar logs a gran escala: KQL y AWS CLI
En entornos con mucho volumen, los logs de Azure/M365 se consultan habitualmente mediante KQL (Kusto Query Language, el lenguaje de consulta de Azure Sentinel y Log Analytics), con una sintaxis pensada específicamente para filtrar y correlacionar grandes volúmenes de eventos — el mismo objetivo que psort.py cumplía sobre una timeline local en el módulo 10, aplicado ahora sobre logs que nunca llegan a bajar al equipo del analista.
$ SigninLogs
| where UserPrincipalName == "compromised-user@empresa.com"
| where ResultType == 0
| project TimeGenerated, IPAddress, Location, AppDisplayName
2026-03-14 02:04:17 203.0.113.44 Unknown (VPN/proxy) Office 365 Exchange OnlineAutoevaluación
- ¿Qué reparte el modelo de responsabilidad compartida entre proveedor y cliente, y qué significa eso para lo que un analista forense puede adquirir directamente?
- ¿Qué registra CloudTrail, y a qué artefacto de los módulos anteriores se parece más en su función?
- ¿Qué diferencia hay entre un VPC Flow Log y una captura PCAP del módulo 11, en términos de qué contenido conservan?
- ¿Por qué la ausencia de un log de CloudTrail relevante para un incidente de hace meses no es necesariamente un fallo del analista?
- ¿Qué patrón de inicio de sesión detectarías cruzando ubicación y tiempo en un Sign-in log de Entra ID, y qué principio de los módulos anteriores aplica directamente aquí?