Límites de CloudTrail: lo que el análisis de logs no revela
Lo que CloudTrail, VPC Flow Logs y los registros de acceso de S3 no guardan, dónde fallan las líneas base y cómo redactar conclusiones honestas sin evidencias.
En resumen. Los registros recogen llamadas a la API y metadatos de red; no recogen intenciones, ni cargas útiles, ni lo que ocurrió dentro de una instancia. CloudTrail no registra las lecturas de objetos de S3 salvo que se hayan configurado los eventos de datos; el historial de eventos solo conserva 90 días de eventos de administración; los registros de flujo omiten el DNS hacia el resolvedor de Amazon y el tráfico hacia los metadatos de instancia; los registros de acceso de S3 se entregan sin garantía. Las detecciones basadas en líneas base están ciegas si no hay días tranquilos antes del incidente. Redacte conclusiones acordes con la cobertura: "no hay evidencias de X en las fuentes disponibles, que cubren Y", nunca "X no ocurrió" cuando X no podía haberse visto.
Un veredicto basado en registros (de un SIEM, de consultas de Athena o del analizador de este sitio) es una afirmación sobre los registros, no sobre la cuenta. Este artículo enumera las lagunas que aparecen en casi todas las investigaciones en AWS, para que acaben en el informe y no en una sorpresa seis meses después.
Lo que CloudTrail no ve
| Laguna | Por qué | Qué hacer |
|---|---|---|
| Lecturas y escrituras de objetos de S3 | Los eventos de datos están desactivados de forma predeterminada y se facturan aparte | Revise los selectores del trail; utilice los registros de acceso al servidor de S3 si estaban activados |
| Invocaciones de Lambda, lecturas de elementos de DynamoDB | También son eventos de datos | Lo mismo |
| Cualquier cosa con más de 90 días de antigüedad si no hay trail | Límite del historial de eventos | Un trail o CloudTrail Lake para el futuro |
| Lo que se ejecutó dentro de una instancia o un contenedor | CloudTrail solo registra el plano de control | Análisis forense del host, EDR, registros del sistema operativo; en EKS, el registro de auditoría de Kubernetes (kubernetesforensics.com) |
Los datos de usuario completos de RunInstances | Se registran como <sensitiveDataRemoved> | Recupérelos de la instancia |
| Eventos de servicios o acciones no cubiertos | La cobertura varía según el servicio | Servicios compatibles con CloudTrail |
| El orden dentro de un archivo | Los eventos no se entregan en orden (conceptos de CloudTrail) | Ordene siempre por eventTime |
La entrega tampoco es instantánea: CloudTrail suele entregar los eventos en unos cinco minutos, sin garantía (cómo funciona CloudTrail). Una recopilación hecha segundos después de la última acción del atacante puede no incluirla.
Lo que los registros de red no ven
Los VPC Flow Logs nunca registran el tráfico hacia el servidor DNS de Amazon, hacia el servicio de metadatos de instancia en 169.254.169.254, Time Sync, DHCP ni ARP (limitaciones). Por tanto:
- la tunelización DNS a través del resolvedor de la VPC es invisible (la fuente para eso son los registros de consultas de Route 53 Resolver);
- el robo de credenciales de rol de instancia desde IMDS no deja ningún flujo; su rastro, si lo hay, es el uso de esas credenciales en otro lugar, que GuardDuty señala con hallazgos
InstanceCredentialExfiltration; - las descargas de S3 y de otras API realizadas desde internet nunca atraviesan su VPC.
Los registros de acceso al servidor de S3 se entregan sin garantía; AWS indica que un registro puede llegar tarde o no llegar nunca (documentación). Son útiles para volúmenes y patrones, pero más débiles como prueba de que una solicitud concreta no se produjo.
Puntos ciegos de identidad
- Los usuarios federados y de SSO aparecen como sesiones de rol asumido; quién era la persona real consta en los registros del proveedor de identidad (para Okta, consulte oktaforensics.com; para Microsoft Entra ID, m365forensics.com).
- El encadenamiento de roles reparte a un mismo actor entre varias sesiones; siga las respuestas de
AssumeRoleysessionContext.sessionIssuer. - Los servicios de AWS que actúan en su nombre muestran el nombre de un servicio en
sourceIPAddress; un atacante que utiliza un servicio (CloudFormation, Lambda) para actuar de forma indirecta se parece a ese servicio. - Salida a internet compartida. El NAT de una oficina o el rango de IP de un proveedor de CI hacen que las detecciones de "IP nueva" generen ruido; un punto de conexión VPN que el atacante también utiliza las deja ciegas.
- Sin geolocalización en los registros. CloudTrail registra direcciones IP, no países ni ASN. El analizador tampoco enriquece las IP, así que "inicio de sesión desde un país nuevo" no se detecta; los hallazgos de GuardDuty aportan ese contexto cuando está disponible.
Dónde fallan las detecciones
La detección basada en reglas, incluida la del analizador, tiene modos de fallo previsibles:
- Las líneas base necesitan historial. "Clave de acceso de larga duración usada desde una IP nueva" y "Actividad en una región no utilizada antes" comparan con el primer día de actividad de los registros que se cargan. Si carga solo el día del incidente, no verán nada, o lo verán todo.
- Se puede quedar por debajo de los umbrales. 29 llamadas List distintas en diez minutos no activarán una regla de "30 en 10 minutos"; 99 descargas por hora no activarán una regla de "100 por hora". Un atacante paciente es más difícil de atrapar que uno que ejecuta un script.
- La administración legítima se parece a un ataque. Crear usuarios, asociar políticas o lanzar instancias GPU son tareas normales. Las detecciones señalan; las personas confirman.
- Técnicas desconocidas. Las reglas cubren rutas de ataque conocidas. El archivo de reglas del analizador enumera lo que está cubierto; todo lo demás requiere una revisión manual de los eventos en bruto.
Redactar conclusiones honestas
Vincule cada conclusión a la cobertura. Una plantilla que funciona:
Entre [inicio] y [fin] se revisaron los eventos de administración de CloudTrail de las cuentas […] en todas las regiones, los eventos de datos de S3 de los buckets […] y los VPC Flow Logs de las VPC […]. Los eventos de datos de S3 no estaban activados para los buckets […]; para esos buckets no es posible determinar el acceso a los objetos. No se encontraron evidencias de [actividad] en las fuentes revisadas.
Deje constancia también de la zona horaria (UTC), los hashes de las exportaciones, las herramientas y versiones utilizadas y cada laguna: trails detenidos, regiones que faltan, grupos de registros eliminados. El artículo sobre evasión de defensas explica cómo delimitar un hueco creado por el atacante.
Cerrar las lagunas para la próxima vez
- Un trail multirregión (o de organización) con validación de archivos de registro, almacenado en una cuenta separada y protegida.
- Eventos de datos de S3 para los buckets que contienen datos sensibles, al menos para las lecturas.
- VPC Flow Logs en todas las VPC, incluidas las VPC predeterminadas de las regiones que no utiliza, o bien una política de control de servicios que deniegue esas regiones.
- GuardDuty en todas las regiones habilitadas, con los hallazgos exportados a S3.
- Una retención que supere el tiempo que tarda en detectar un incidente.
La Security Incident Response Guide de AWS trata a fondo la parte de preparación. Para la investigación en sí, empiece por la visión general de la respuesta a incidentes.