Análisis de logs de CloudTrail: guía paso a paso

En resumen. Recopile las exportaciones, suéltelas todas en el analizador y trabaje en este orden: veredicto y cobertura (lo que la herramienta pudo y no pudo ver) → hallazgos (confirme cada uno con sus filas de evidencia) → pivotes sobre entidades (cada clave, IP y principal que tocó el atacante) → cronología (la historia, en orden) → remediación (primero la contención). Cuente con entre 30 y 60 minutos para un incidente típico de clave filtrada. Todo se ejecuta localmente en WebAssembly; ningún registro sale de su navegador.

Esta guía usa AWS Forensics porque es lo que ofrece este sitio, pero el método es el mismo sea cual sea la herramienta: Athena, CloudTrail Lake, un SIEM o jq. Las preguntas no cambian; solo cambia la rapidez con la que se responden.

Paso 1: recopilar las exportaciones

Obtenga los archivos de CloudTrail de la ventana del incidente más dos o tres días tranquilos anteriores. Dos detecciones, «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 que encuentran en los registros, de modo que sin una línea base no tienen con qué comparar. La herramienta le avisa cuando se han cargado menos de dos días de CloudTrail.

Añada todo lo demás que tenga:

• VPC Flow Logs (exfiltración por red, tráfico de minería)
• Registros de acceso al servidor de S3 o eventos de datos de S3 de CloudTrail (lecturas de objetos)
• Hallazgos de GuardDuty en JSON
• El informe de credenciales de IAM (MFA, claves del usuario raíz, usuarios creados durante el incidente)

La guía de exportación recoge los comandos para cada fuente.

Paso 2: cargarlo todo de una vez

En la página de inicio, pulse Elegir archivos o Elegir una carpeta, o suéltelos directamente. Se aceptan tal cual:

Los ZIP (incluidos los anidados) y los gzip se descomprimen en streaming, así que las exportaciones de varios gigabytes no tienen que caber en memoria. Los archivos de resumen (digest) se reconocen y se omiten. La pestaña Archivos enumera cada archivo con el formato detectado, y una sección «Archivos no analizados» explica todo lo que se ha omitido: un registro de ALB, un flow log en Parquet, un gzip truncado.

Para practicar antes, haga clic en Probar con un ejemplo: carga una exportación sintética de un incidente ficticio, claramente identificada como tal.

Paso 3: leer el veredicto y las notas de cobertura

El veredicto tiene tres niveles:

• Indicios de compromiso: al menos un hallazgo crítico, o dos hallazgos de gravedad alta con al menos una señal del lado del atacante (anomalía de acceso, reconocimiento, evasión de defensas, exfiltración, impacto o un hallazgo de GuardDuty).
• Actividad sospechosa: requiere revisión: cualquier hallazgo alto o medio, o varios bajos.
• Ningún indicio de compromiso en estos registros: no se ha activado ninguna detección.

Los hallazgos de configuración procedentes del informe de credenciales (claves del usuario raíz, usuarios sin MFA) se muestran, pero quedan fuera del veredicto: describen la postura, no la actividad.

A continuación, lea el bloque de Cobertura. «No hay eventos de datos de S3 ni registros de acceso de S3» significa que el robo de datos de los buckets no se puede evaluar, no que no haya ocurrido. Un veredicto «Ningún indicio de compromiso en estos registros» acompañado de tres advertencias de cobertura es una afirmación débil; déjelo claro en sus notas. El artículo sobre las limitaciones profundiza en ello.

Paso 4: confirmar cada hallazgo con sus evidencias

Cada hallazgo muestra su gravedad, las técnicas de MITRE ATT&CK, los parámetros extraídos (clave, principal, IP, bucket, región…), el intervalo de tiempo y los eventos de evidencia. Abra el registro original de, al menos, el primer y el último evento de evidencia.

Preguntas que debe plantearse para cada hallazgo:

1. ¿Quién? userIdentity.arn y userIdentity.accessKeyId. ¿Es una persona, un rol de CI, un servicio de AWS?
2. ¿Desde dónde? sourceIPAddress y userAgent. ¿La salida a internet corporativa, un runner de CI, un VPS?
3. ¿Tuvo éxito? La ausencia de errorCode significa éxito; AccessDenied significa que el intento falló.
4. ¿Hay un ticket de cambio? El trabajo de administración se parece al de un atacante. Pregunte a la persona que figura en el evento.

Las detecciones señalan; no demuestran. Un hallazgo «Instancias GPU lanzadas» en la cuenta de un equipo de machine learning es un martes cualquiera. El mismo hallazgo con una clave que ayer estaba en un portátil en Lyon y hoy en un VPS es un incidente.

Paso 5: pivotar sobre las entidades para delimitar el alcance

La pestaña Entidades enumera todos los principales, claves de acceso, direcciones IP, regiones, recursos y agentes de usuario de los registros, con recuentos, errores, primera y última aparición y aquello con lo que se vio cada uno. Las entidades que aparecen en hallazgos están marcadas.

El bucle de delimitación:

1. Pivote sobre la clave filtrada → anote todas las IP desde las que se usó.
2. Pivote sobre cada IP del atacante → anote todas las demás claves o principales usados desde ella.
3. Pivote sobre cada principal nuevo (un usuario que creó el atacante, un rol que asumió) → anote lo que hizo.
4. Repita hasta que no aparezca ninguna entidad nueva.

Así es como se encuentra la segunda clave de acceso que el atacante generó para su usuario de puerta trasera, que la actividad de la primera clave por sí sola no le mostraría. La investigación de una clave de acceso filtrada aplica este bucle en detalle.

Paso 6: construir la cronología

La pestaña Cronología ordena los eventos de evidencia de cada hallazgo (hasta seis por hallazgo). La pestaña Eventos contiene el conjunto completo de registros con filtros (fuente, «Solo en hallazgos», «Solo errores», «Solo escrituras») y un selector UTC/Local. Haga clic en cualquier fila para ver el registro original.

Para el expediente del caso:

• Exportación CSV de los eventos filtrados (las celdas que podrían interpretarse como fórmulas de hoja de cálculo se neutralizan);
• Informe JSON con el veredicto, los hallazgos, las evidencias y las estadísticas.

Redacte la narración en UTC y conserve las exportaciones originales junto a ella.

Paso 7: seguir la lista de remediación

La pestaña Remediación combina los pasos de remediación de todos los hallazgos, empezando por la contención, con los valores reales ya incluidos: la clave que hay que desactivar, el usuario que hay que eliminar, la región en la que hay que volver a habilitar GuardDuty. Marque los elementos a medida que avanza (el estado solo se guarda en la página).

Antes de eliminar nada, asegúrese de haber guardado lo que necesita como evidencia: las políticas insertadas de los usuarios de puerta trasera, los datos de usuario de las instancias modificadas, una instantánea de las instancias del atacante. Después, siga la Security Incident Response Guide de AWS para el resto del proceso.

Errores habituales

• Historial de eventos de una sola región. El historial de eventos es por región; a los atacantes les gustan las regiones que usted no abre.
• Sin línea base. Cargar solo el día del incidente deja ciegas las detecciones de «IP nueva» y «región nueva».
• Fiarse del sourceIPAddress de los servicios de AWS. Cuando un servicio actúa en su nombre, el campo contiene un nombre de servicio como ec2.amazonaws.com, no una IP.
• Quedarse en la primera clave. La primera clave es la vía por la que entraron, no todo lo que tienen en su poder.

Artículos relacionados

• Eventos de CloudTrail que todo analista de respuesta debe conocer
• Recorrido por un incidente ficticio: de una clave filtrada a la minería de criptomonedas
• Respuesta a incidentes en AWS: investigar una cuenta comprometida