Forense en la Nube: Investigación de Incidentes en AWS, Azure y GCP (2026)

La forense en la nube es fundamentalmente diferente de la forense tradicional en entornos on-premise. En 2026, el perímetro está definido por IAM en lugar de firewalls físicos, los recursos son efímeros y las evidencias viven en logs de API que pueden ser manipulados o eliminados por un atacante con los permisos adecuados.

Las interrupciones de alto perfil a principios de 2026 (como las incidencias generalizadas en plataformas celulares y de software) demostraron que una mala configuración de software puede parecer un ataque. La forense separa el accidente de la actividad maliciosa.

1. Diferencias Clave con la Forense Tradicional

Aspecto	Forense Tradicional	Forense en la Nube
Evidencia principal	Disco duro, memoria RAM	Logs de API (CloudTrail, Audit Logs)
Adquisición	Apagar, clonar disco, volcado RAM	Snapshot de volumen sin apagar, exportar logs
Cadena de custodia	Firma física, hash del disco	Hash SHA-256, export timestamp, principal assertion
Retención de datos	Control total del investigador	Políticas de retención del proveedor (90-400 días)
Entorno	Estático	Efímero y elástico
Responsabilidad	Completa del investigador	Compartida con el proveedor cloud

2. Preparación Antes del Incidente

La preparación es la fase más crítica en cloud forensics. Cuando ocurre un incidente, el atacante con acceso IAM puede desactivar logs, eliminar evidencias y modificar recursos antes de que el equipo de respuesta intervenga.

Arquitectura de Logging Forense

Log	AWS	Azure	GCP
Actividad de gestión	CloudTrail Management Events (siempre activo)	Activity Log (siempre activo)	Cloud Audit Logs — Admin Activity (siempre activo, retención 400 días)
Actividad de datos	CloudTrail Data Events (hay que activarlos)	Resource Logs (hay que activarlos)	Cloud Audit Logs — Data Access (hay que activarlos)
Tráfico de red	VPC Flow Logs	NSG Flow Logs	VPC Flow Logs
Sistema	CloudWatch Logs	Log Analytics	Cloud Logging
DNS	Route 53 Resolver Query Logs	DNS Analytics	Cloud DNS Logging

Configuración Mínima Recomendada

Centralizar logs en una cuenta de seguridad dedicada a la que el atacante no tenga acceso. En AWS, usar una cuenta de logging separada con S3 Object Lock habilitado.
Activar CloudTrail Organization Trail en AWS para cubrir todas las cuentas.
Data Events para S3 y Lambda: caros pero imprescindibles. Sin ellos, no se puede determinar qué objetos S3 leyó el atacante ni qué funciones Lambda ejecutó.
VPC Flow Logs en todas las VPCs, centralizados.
Habilitar versioning y Object Lock en los buckets de logs para prevenir manipulación.
Crear un digest SHA-256 para cada archivo de exportado. Registrar el hash, la hora de exportación (UTC) y el principal que realizó la exportación.

Break Glass Account

Cada proveedor cloud debe tener una cuenta de emergencia (break glass) para incidentes:

AWS: usuario IAM en la cuenta de gestión con AdministratorAccess, hardware FIDO2 para MFA, credenciales en caja fuerte física.
Azure: cuenta de acceso de emergencia en el tenant, excluida de Conditional Access, con MFA hardware.
GCP: cuenta Super Admin con hardware MFA, separada de los administradores operativos.

3. Preservación de Evidencias

Cuando se activa un incidente, lo primero es preservar las evidencias antes de que el atacante las destruya. El atacante con acceso IAM puede ver y modificar CloudTrail, CloudWatch, Activity Log y Audit Logs.

Fase 1: Preservar Logs de Control Plane

# AWS — Exportar CloudTrail a un bucket forense
aws cloudtrail get-trail-status --name default
aws s3 sync s3://source-bucket/AWSLogs/ s3://forensic-bucket/AWSLogs/ --source-region us-east-1

# Verificar integridad con CloudTrail digest
aws cloudtrail validate-logs --trail-arn arn:aws:cloudtrail:us-east-1:ACCOUNT:trail/default \
  --start-time 2026-07-01T00:00:00Z --end-time 2026-07-05T00:00:00Z

# Azure — Exportar Activity Log a Log Analytics y almacenamiento inmutable
# Configurar Diagnostic Settings para enviar a Storage Account con WORM enable
Set-AzDiagnosticSetting -ResourceId $resourceId `
  -StorageAccountId $storageAccountId `
  -Enabled $true `
  -Category AuditLogs, Administrative, Security

Fase 2: Preservar Volúmenes de Cómputo

No apagar las instancias — la memoria volátil se pierde al apagar. En su lugar, crear snapshots forenses:

# AWS — Snapshot forense de EBS
aws ec2 create-snapshot --volume-id vol-1234567890abcdef0 \
  --description "Forensic snapshot - incident IR-2026-001" \
  --tag-specifications 'ResourceType=snapshot,Tags=[{Key=IncidentID,Value=IR-2026-001}]'

# Copiar a región de investigación aislada
aws ec2 copy-snapshot --source-region us-east-1 \
  --source-snapshot-id snap-1234567890abcdef0 \
  --destination-region us-west-2 \
  --description "Forensic copy - IR-2026-001"

# GCP — Snapshot forense de Persistent Disk
gcloud compute disks snapshot DISK_NAME \
  --snapshot-names forensic-snapshot-ir-2026-001 \
  --zone us-central1-a

# Crear disco forense en proyecto de investigación aislado
gcloud compute disks create forensic-disk \
  --source-snapshot forensic-snapshot-ir-2026-001 \
  --zone us-west2-a \
  --project forensic-project

Fase 3: Preservar Metadatos de IAM

La reconstrucción de acciones de IAM es la parte más importante de la forense cloud. Documentar:

¿Qué principal realizó cada acción?
¿A través de qué rol o política?
¿Desde qué IP y qué user-agent?
¿Qué STS AssumeRole chain se utilizó?

# AWS — Reconstruir cadena de AssumeRole
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole \
  --start-time 2026-07-01T00:00:00Z

4. Reconstrucción de la Línea de Tiempo

Una vez preservadas las evidencias, reconstruir la línea de tiempo del incidente:

// KQL — Línea de tiempo en Azure Sentinel
CloudTrail
| where TimeGenerated between (datetime(2026-07-01) .. datetime(2026-07-05))
| where EventName in ("CreateUser", "CreateAccessKey", "PutBucketPolicy", 
                      "DeleteTrail", "StopLogging", "UpdateTrail")
| project TimeGenerated, EventName, UserIdentity, SourceIPAddress, 
          ErrorCode, RequestParameters
| order by TimeGenerated asc

Patrones de ataque comunes en 2026:

Anomalous Resource Provisioning: creación repentina de instancias GPU para minado de criptomonedas
IAM Escalation: modificación de políticas para elevar privilegios
S3 Exfiltration: lectura masiva de objetos S3 desde IPs inusuales
Log Tampering: desactivación de CloudTrail/Activity Log antes de acciones maliciosas
Crypto-mining: despliegue de instancias EC2/VM de alto cómputo

5. Cadena de Custodia en la Nube

La cadena de custodia digital es más compleja en la nube porque los proveedores no proporcionan acceso al hipervisor ni a la infraestructura física.

Procedimiento:

Documentar cada exportación de log o snapshot: hora UTC, principal que ejecutó, método utilizado
Calcular hash SHA-256 de cada archivo exportado
Usar APIs de exportación con timestamp del proveedor cuando estén disponibles
Almacenar el hash, la hora y el principal exportador en un registro inmodificable
Para evidencia crítica, considerar el servicio de respuesta a incidentes del proveedor (AWS CIRT, Azure MSRC, Google Cloud IR) que puede proporcionar attestaciones del proveedor

6. Limitaciones de la Forense Cloud

Los proveedores cloud no proporcionan:

Acceso al hipervisor o infraestructura física subyacente
Forense de memoria a nivel de hipervisor
Logs de red del plano de control del proveedor
Retención extendida de logs retroactiva (si no se configuró antes del incidente, los datos pueden haber expirado)

Retenciones por defecto:

Proveedor	Log	Retención por defecto
AWS	CloudTrail Management Events	90 días (consola), 1 año+ configurable (S3)
Azure	Activity Log	90 días
GCP	Admin Activity Audit Logs	400 días

Checklist de Preparación Forense Cloud

Antes del Incidente

Logs centralizados en cuenta/tenant de seguridad dedicado
Object Lock habilitado en buckets de logs
Data Events activados para S3 y Lambda (AWS)
VPC Flow Logs activados en todas las VPCs
GuardDuty / Defender for Cloud / Security Command Center activados
Break Glass account configurada con MFA hardware y offline
Scripts de preservación de evidencias probados trimestralmente
Contactos del equipo de respuesta a incidentes del proveedor registrados

Durante el Incidente

Preservar logs de control plane antes de cualquier acción de contención
Crear snapshots forenses de todos los volúmenes involucrados
Reconstruir cadena de AssumeRole/impersonación de IAM
Documentar cada exportación con hash SHA-256 y timestamp UTC
No apagar instancias sin tomar snapshot primero

Conclusión

La forense en la nube requiere un cambio de mentalidad: de gestionar servidores a gestionar permisos. La naturaleza efímera de la nube significa que la evidencia puede desaparecer en segundos si no se está preparado con snapshots automatizados y logging centralizado. La regla más importante: asumir que el atacante tiene acceso a los logs que tú puedes ver, y diseñar una arquitectura de logging donde una cuenta de seguridad dedicada e inmutable esté fuera del alcance del adversario. En la nube, quien controla el IAM controla la evidencia.