AWS - CloudTrail Enum
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
AWS CloudTrail registra y monitorea la actividad dentro de tu entorno AWS. Captura registros de eventos detallados, incluyendo quién hizo qué, cuándo y desde dónde, para todas las interacciones con los recursos de AWS. Esto proporciona un rastro de auditoría de cambios y acciones, ayudando en el análisis de seguridad, auditoría de cumplimiento y seguimiento de cambios en los recursos. CloudTrail es esencial para entender el comportamiento de usuarios y recursos, mejorar las posturas de seguridad y asegurar el cumplimiento regulatorio.
Cada evento registrado contiene:
El nombre de la API llamada: eventName
El servicio llamado: eventSource
La hora: eventTime
La dirección IP: SourceIPAddress
El método del agente: userAgent. Ejemplos:
Signing.amazonaws.com - Desde la Consola de Administración de AWS
console.amazonaws.com - Usuario root de la cuenta
lambda.amazonaws.com - AWS Lambda
Los parámetros de la solicitud: requestParameters
Los elementos de la respuesta: responseElements
Los eventos se escriben en un nuevo archivo de registro aproximadamente cada 5 minutos en un archivo JSON, son retenidos por CloudTrail y finalmente, los archivos de registro son entregados a S3 aproximadamente 15 minutos después. Los registros de CloudTrail pueden ser agregados a través de cuentas y regiones. CloudTrail permite usar la integridad del archivo de registro para poder verificar que tus archivos de registro no han cambiado desde que CloudTrail te los entregó. Crea un hash SHA-256 de los registros dentro de un archivo de resumen. Un hash sha-256 de los nuevos registros se crea cada hora. Al crear un Trail, los selectores de eventos te permitirán indicar el tipo de eventos a registrar: eventos de gestión, de datos o de información.
Los registros se guardan en un bucket de S3. Por defecto, se utiliza el cifrado del lado del servidor (SSE-S3), por lo que AWS descifrará el contenido para las personas que tengan acceso a él, pero para mayor seguridad puedes usar SSE con KMS y tus propias claves.
Los registros se almacenan en un bucket de S3 con este formato de nombre:
BucketName/AWSLogs/AccountID/CloudTrail/RegionName/YYY/MM/DD
Siendo el BucketName: aws-cloudtrail-logs-<accountid>-<random>
Ejemplo: aws-cloudtrail-logs-947247140022-ffb95fe7/AWSLogs/947247140022/CloudTrail/ap-south-1/2023/02/22/
Dentro de cada carpeta, cada registro tendrá un nombre siguiendo este formato: AccountID_CloudTrail_RegionName_YYYYMMDDTHHMMZ_Random.json.gz
Convención de Nombres de Archivos de Registro
Además, los archivos de resumen (para verificar la integridad del archivo) estarán dentro del mismo bucket en:
Crea un Trail en la cuenta de AWS donde deseas que se entreguen los archivos de registro.
Aplica permisos al bucket de S3 de destino permitiendo el acceso entre cuentas para CloudTrail y permite a cada cuenta de AWS que necesite acceso.
Crea un nuevo Trail en las otras cuentas de AWS y selecciona usar el bucket creado en el paso 1.
Sin embargo, incluso si puedes guardar todos los registros en el mismo bucket de S3, no puedes agregar registros de CloudTrail de múltiples cuentas en un CloudWatch Logs perteneciente a una sola cuenta de AWS.
Recuerda que una cuenta puede tener diferentes Trails de CloudTrail habilitados almacenando los mismos (o diferentes) registros en diferentes buckets.
Al crear un CloudTrail, es posible indicar que se active CloudTrail para todas las cuentas en la organización y obtener los registros en solo 1 bucket:
De esta manera, puedes configurar fácilmente CloudTrail en todas las regiones de todas las cuentas y centralizar los registros en 1 cuenta (que deberías proteger).
Puedes verificar que los registros no han sido alterados ejecutando
CloudTrail puede enviar automáticamente registros a CloudWatch para que puedas establecer alertas que te adviertan cuando se realicen actividades sospechosas. Ten en cuenta que para permitir que CloudTrail envíe los registros a CloudWatch, se necesita crear un rol que permita esa acción. Si es posible, se recomienda usar el rol predeterminado de AWS para realizar estas acciones. Este rol permitirá a CloudTrail:
CreateLogStream: Esto permite crear flujos de registro de CloudWatch Logs
PutLogEvents: Entregar registros de CloudTrail al flujo de registro de CloudWatch Logs
El Historial de Eventos de CloudTrail te permite inspeccionar en una tabla los registros que han sido grabados:
CloudTrail Insights analiza automáticamente los eventos de gestión de escritura de los senderos de CloudTrail y te alerta sobre actividades inusuales. Por ejemplo, si hay un aumento en los eventos de TerminateInstance que difiere de las líneas base establecidas, lo verás como un evento de Insight. Estos eventos hacen que encontrar y responder a actividades inusuales de API sea más fácil que nunca.
Las perspectivas se almacenan en el mismo bucket que los registros de CloudTrail en: BucketName/AWSLogs/AccountID/CloudTrail-Insight
Integridad del Archivo de Registro de CloudTrail
Validar si los registros han sido manipulados (modificados o eliminados)
Utiliza archivos de resumen (crea un hash para cada archivo)
Hashing SHA-256
SHA-256 con RSA para firma digital
clave privada propiedad de Amazon
Toma 1 hora crear un archivo de resumen (hecho en la hora cada hora)
Detener el acceso no autorizado
Usar políticas de IAM y políticas de bucket de S3
equipo de seguridad —> acceso de administrador
auditores —> acceso solo de lectura
Usar SSE-S3/SSE-KMS para cifrar los registros
Prevenir que los archivos de registro sean eliminados
Restringir el acceso de eliminación con políticas de IAM y de bucket
Configurar la eliminación MFA de S3
Validar con la Validación de Archivos de Registro
AWS Access Advisor se basa en los últimos 400 días de registros de AWS CloudTrail para recopilar sus perspectivas. CloudTrail captura un historial de llamadas a la API de AWS y eventos relacionados realizados en una cuenta de AWS. Access Advisor utiliza estos datos para mostrar cuándo se accedió por última vez a los servicios. Al analizar los registros de CloudTrail, Access Advisor puede determinar qué servicios de AWS ha accedido un usuario o rol de IAM y cuándo ocurrió ese acceso. Esto ayuda a los administradores de AWS a tomar decisiones informadas sobre refinar permisos, ya que pueden identificar servicios que no se han accedido durante períodos prolongados y potencialmente reducir permisos excesivamente amplios basados en patrones de uso reales.
Por lo tanto, Access Advisor informa sobre los permisos innecesarios que se están otorgando a los usuarios para que el administrador pueda eliminarlos.
Es posible realizar una inyección CVS dentro de CloudTrail que ejecutará código arbitrario si los registros se exportan en CSV y se abren con Excel. El siguiente código generará una entrada de registro con un nombre de Trail incorrecto que contiene la carga útil:
Para más información sobre inyecciones CSV, consulta la página:
Para más información sobre esta técnica específica, consulta https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/
Los Honeytokens se crean para detectar la exfiltración de información sensible. En el caso de AWS, son claves de AWS cuyo uso se monitorea, si algo activa una acción con esa clave, entonces alguien debe haber robado esa clave.
Sin embargo, los Honeytokens como los creados por Canarytokens, SpaceCrab, SpaceSiren están utilizando un nombre de cuenta reconocible o usando el mismo ID de cuenta de AWS para todos sus clientes. Por lo tanto, si puedes obtener el nombre de la cuenta y/o el ID de la cuenta sin hacer que Cloudtrail genere ningún registro, podrías saber si la clave es un honeytoken o no.
Pacu tiene algunas reglas para detectar si una clave pertenece a Canarytokens, SpaceCrab, SpaceSiren:
Si canarytokens.org aparece en el nombre del rol o el ID de cuenta 534261010715 aparece en el mensaje de error.
Probándolos más recientemente, están usando la cuenta 717712589309 y aún tiene la cadena canarytokens.com en el nombre.
Si SpaceCrab aparece en el nombre del rol en el mensaje de error.
SpaceSiren utiliza uuids para generar nombres de usuario: [a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89aAbB][a-f0-9]{3}-[a-f0-9]{12}
Si el nombre parece generado aleatoriamente, hay altas probabilidades de que sea un HoneyToken.
Puedes obtener el ID de Cuenta del codificado dentro de la clave de acceso como se explica aquí y verificar el ID de cuenta con tu lista de cuentas de Honeytokens de AWS:
Check more information in the investigación original.
La técnica más efectiva para esto es en realidad una simple. Solo usa la clave que acabas de encontrar para acceder a algún servicio dentro de tu propia cuenta de atacante. Esto hará que CloudTrail genere un registro dentro de TU PROPIA cuenta de AWS y no dentro de las víctimas.
La cuestión es que la salida te mostrará un error que indica el ID de la cuenta y el nombre de la cuenta, por lo que podrás ver si es un Honeytoken.
En el pasado, había algunos servicios de AWS que no envían registros a CloudTrail (encuentra una lista aquí). Algunos de esos servicios responderán con un error que contiene el ARN del rol de la clave si alguien no autorizado (la clave honeytoken) intenta acceder a él.
De esta manera, un atacante puede obtener el ARN de la clave sin activar ningún registro. En el ARN, el atacante puede ver el ID de la cuenta de AWS y el nombre, es fácil conocer el ID y los nombres de las cuentas de las empresas del HoneyToken, así que de esta manera un atacante puede identificar si el token es un HoneyToken.
Ten en cuenta que todas las API públicas descubiertas que no estaban creando registros de CloudTrail ahora están arregladas, así que tal vez necesites encontrar las tuyas...
Para más información, consulta la investigación original.
Ciertos servicios de AWS generarán alguna infraestructura como Bases de Datos o clústeres de Kubernetes (EKS). Un usuario hablando directamente con esos servicios (como la API de Kubernetes) no usará la API de AWS, por lo que CloudTrail no podrá ver esta comunicación.
Por lo tanto, un usuario con acceso a EKS que haya descubierto la URL de la API de EKS podría generar un token localmente y hablar con el servicio de API directamente sin ser detectado por Cloudtrail.
Más información en:
AWS - EKS Post ExploitationEn el primer ejemplo, se proporciona un único selector de eventos como un array JSON con un solo objeto. El "ReadWriteType": "ReadOnly" indica que el selector de eventos solo debe capturar eventos de solo lectura (por lo que los insights de CloudTrail no estarán verificando eventos de escritura, por ejemplo).
Puedes personalizar el selector de eventos según tus requisitos específicos.
Eliminar el bucket S3
Cambiar la política del bucket para denegar cualquier escritura del servicio CloudTrail
Agregar una política de ciclo de vida al bucket S3 para eliminar objetos
Deshabilitar la clave KMS utilizada para cifrar los registros de CloudTrail
Podrías generar una clave asimétrica y hacer que CloudTrail cifre los datos con esa clave y eliminar la clave privada para que el contenido de CloudTrail no pueda ser recuperado. Esto es básicamente un ransomware S3-KMS explicado en:
AWS - S3 Post ExploitationRansomware KMS
Esta es una forma más fácil de realizar el ataque anterior con diferentes requisitos de permisos:
AWS - KMS Post ExploitationAprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
