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 e monitora a atividade dentro do seu ambiente AWS. Ele captura logs de eventos detalhados, incluindo quem fez o quê, quando e de onde, para todas as interações com os recursos AWS. Isso fornece um histórico de auditoria de mudanças e ações, ajudando na análise de segurança, auditoria de conformidade e rastreamento de mudanças de recursos. O CloudTrail é essencial para entender o comportamento de usuários e recursos, melhorar as posturas de segurança e garantir a conformidade regulatória.
Cada evento registrado contém:
O nome da API chamada: eventName
O serviço chamado: eventSource
O tempo: eventTime
O endereço IP: SourceIPAddress
O método do agente: userAgent. Exemplos:
Signing.amazonaws.com - Do AWS Management Console
console.amazonaws.com - Usuário root da conta
lambda.amazonaws.com - AWS Lambda
Os parâmetros da solicitação: requestParameters
Os elementos da resposta: responseElements
Os eventos são escritos em um novo arquivo de log aproximadamente a cada 5 minutos em um arquivo JSON, eles são mantidos pelo CloudTrail e, finalmente, os arquivos de log são entregues ao S3 aproximadamente 15 minutos depois. Os logs do CloudTrail podem ser agregados entre contas e entre regiões. O CloudTrail permite usar a integridade do arquivo de log para poder verificar se seus arquivos de log permaneceram inalterados desde que o CloudTrail os entregou a você. Ele cria um hash SHA-256 dos logs dentro de um arquivo de digestão. Um hash sha-256 dos novos logs é criado a cada hora. Ao criar um Trail, os seletores de eventos permitirão que você indique o tipo de evento a ser registrado: eventos de gerenciamento, dados ou insights.
Os logs são salvos em um bucket S3. Por padrão, a Criptografia do Lado do Servidor é usada (SSE-S3), então a AWS descriptografa o conteúdo para as pessoas que têm acesso a ele, mas para segurança adicional, você pode usar SSE com KMS e suas próprias chaves.
Os logs são armazenados em um bucket S3 com este formato de nome:
BucketName/AWSLogs/AccountID/CloudTrail/RegionName/YYY/MM/DD
Sendo o BucketName: aws-cloudtrail-logs-<accountid>-<random>
Exemplo: aws-cloudtrail-logs-947247140022-ffb95fe7/AWSLogs/947247140022/CloudTrail/ap-south-1/2023/02/22/
Dentro de cada pasta, cada log terá um nome seguindo este formato: AccountID_CloudTrail_RegionName_YYYYMMDDTHHMMZ_Random.json.gz
Log File Naming Convention
Além disso, arquivos de digestão (para verificar a integridade do arquivo) estarão dentro do mesmo bucket em:
Crie um Trail na conta AWS onde você deseja que os arquivos de log sejam entregues
Aplique permissões ao bucket S3 de destino permitindo acesso entre contas para o CloudTrail e permita que cada conta AWS que precisa de acesso
Crie um novo Trail nas outras contas AWS e selecione usar o bucket criado na etapa 1
No entanto, mesmo que você possa salvar todos os logs no mesmo bucket S3, não é possível agregar logs do CloudTrail de várias contas em um CloudWatch Logs pertencente a uma única conta AWS.
Lembre-se de que uma conta pode ter diferentes Trails do CloudTrail ativados armazenando os mesmos (ou diferentes) logs em diferentes buckets.
Ao criar um CloudTrail, é possível indicar para ativar o cloudtrail para todas as contas na org e obter os logs em apenas 1 bucket:
Dessa forma, você pode facilmente configurar o CloudTrail em todas as regiões de todas as contas e centralizar os logs em 1 conta (que você deve proteger).
Você pode verificar se os logs não foram alterados executando
CloudTrail pode enviar logs automaticamente para o CloudWatch, permitindo que você configure alertas que o avisem quando atividades suspeitas forem realizadas. Observe que, para permitir que o CloudTrail envie os logs para o CloudWatch, uma role precisa ser criada que permita essa ação. Se possível, é recomendável usar a role padrão da AWS para realizar essas ações. Essa role permitirá que o CloudTrail:
CreateLogStream: Isso permite criar streams de log do CloudWatch Logs
PutLogEvents: Entregar logs do CloudTrail para o stream de log do CloudWatch Logs
O Histórico de Eventos do CloudTrail permite que você inspecione em uma tabela os logs que foram registrados:
CloudTrail Insights automaticamente analisa eventos de gerenciamento de escrita dos trilhos do CloudTrail e avisa você sobre atividades incomuns. Por exemplo, se houver um aumento nos eventos TerminateInstance que difere das linhas de base estabelecidas, você verá isso como um evento de Insight. Esses eventos tornam mais fácil do que nunca encontrar e responder a atividades incomuns de API.
Os insights são armazenados no mesmo bucket que os logs do CloudTrail em: BucketName/AWSLogs/AccountID/CloudTrail-Insight
Integridade do Arquivo de Log do CloudTrail
Validar se os logs foram adulterados (modificados ou excluídos)
Usa arquivos de digestão (cria hash para cada arquivo)
Hashing SHA-256
SHA-256 com RSA para assinatura digital
chave privada de propriedade da Amazon
Leva 1 hora para criar um arquivo de digestão (feito a cada hora)
Parar acesso não autorizado
Usar políticas IAM e políticas de bucket S3
equipe de segurança —> acesso administrativo
auditores —> acesso somente leitura
Usar SSE-S3/SSE-KMS para criptografar os logs
Prevenir a exclusão de arquivos de log
Restringir acesso de exclusão com políticas IAM e de bucket
Configurar exclusão MFA do S3
Validar com Validação de Arquivo de Log
O Aconselhador de Acesso da AWS depende dos últimos 400 dias de logs do CloudTrail da AWS para reunir seus insights. O CloudTrail captura um histórico de chamadas de API da AWS e eventos relacionados feitos em uma conta da AWS. O Aconselhador de Acesso utiliza esses dados para mostrar quando os serviços foram acessados pela última vez. Ao analisar os logs do CloudTrail, o Aconselhador de Acesso pode determinar quais serviços da AWS um usuário ou role IAM acessou e quando esse acesso ocorreu. Isso ajuda os administradores da AWS a tomar decisões informadas sobre refinar permissões, pois podem identificar serviços que não foram acessados por longos períodos e potencialmente reduzir permissões excessivamente amplas com base em padrões de uso reais.
Portanto, o Aconselhador de Acesso informa sobre as permissões desnecessárias sendo concedidas aos usuários para que o administrador possa removê-las
É possível realizar uma injeção CSV dentro do CloudTrail que executará código arbitrário se os logs forem exportados em CSV e abertos com o Excel. O seguinte código gerará uma entrada de log com um nome de Trail ruim contendo a carga útil:
Para mais informações sobre Injeções CSV, consulte a página:
Para mais informações sobre esta técnica específica, consulte https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/
Honeytokens são criados para detectar a exfiltração de informações sensíveis. No caso da AWS, eles são chaves da AWS cujo uso é monitorado, se algo acionar uma ação com essa chave, então alguém deve ter roubado essa chave.
No entanto, Honeytokens como os criados por Canarytokens, SpaceCrab, SpaceSiren estão usando nomes de conta reconhecíveis ou usando o mesmo ID de conta da AWS para todos os seus clientes. Portanto, se você conseguir obter o nome da conta e/ou ID da conta sem fazer o Cloudtrail criar nenhum log, você poderia saber se a chave é um honeytoken ou não.
Pacu tem algumas regras para detectar se uma chave pertence a Canarytokens, SpaceCrab, SpaceSiren:
Se canarytokens.org aparecer no nome da função ou o ID da conta 534261010715 aparecer na mensagem de erro.
Testando-os mais recentemente, eles estão usando a conta 717712589309 e ainda tem a string canarytokens.com no nome.
Se SpaceCrab aparecer no nome da função na mensagem de erro
SpaceSiren usa uuids para gerar nomes de usuário: [a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89aAbB][a-f0-9]{3}-[a-f0-9]{12}
Se o nome parecer gerado aleatoriamente, há altas probabilidades de que seja um HoneyToken.
Você pode obter o ID da Conta a partir do codificado dentro da chave de acesso como explicado aqui e verificar o ID da conta com sua lista de contas Honeytokens da AWS:
Confira mais informações na pesquisa original.
A técnica mais eficaz para isso é, na verdade, uma simples. Basta usar a chave que você acabou de encontrar para acessar algum serviço dentro da sua própria conta de atacantes. Isso fará com que o CloudTrail gere um log dentro da SUA PRÓPRIA conta AWS e não dentro da conta das vítimas.
A questão é que a saída mostrará um erro indicando o ID da conta e o nome da conta, então você poderá ver se é um Honeytoken.
No passado, havia alguns serviços AWS que não enviavam logs para o CloudTrail (encontre uma lista aqui). Alguns desses serviços responderão com um erro contendo o ARN do papel da chave se alguém não autorizado (a chave honeytoken) tentar acessá-lo.
Dessa forma, um atacante pode obter o ARN da chave sem acionar nenhum log. No ARN, o atacante pode ver o ID da conta AWS e o nome, é fácil saber os IDs e nomes das contas das empresas do HoneyToken, assim um atacante pode identificar se o token é um HoneyToken.
Observe que todas as APIs públicas descobertas que não estavam criando logs do CloudTrail agora foram corrigidas, então talvez você precise encontrar as suas próprias...
Para mais informações, consulte a pesquisa original.
Certos serviços AWS irão gerar alguma infraestrutura como Bancos de Dados ou clusters Kubernetes (EKS). Um usuário falando diretamente com esses serviços (como a API do Kubernetes) não usará a API AWS, então o CloudTrail não será capaz de ver essa comunicação.
Portanto, um usuário com acesso ao EKS que descobriu a URL da API do EKS poderia gerar um token localmente e falar diretamente com o serviço da API sem ser detectado pelo Cloudtrail.
Mais informações em:
No primeiro exemplo, um único seletor de eventos é fornecido como um array JSON com um único objeto. O "ReadWriteType": "ReadOnly" indica que o seletor de eventos deve capturar apenas eventos de leitura (então as análises do CloudTrail não verificarão eventos de escrita, por exemplo).
Você pode personalizar o seletor de eventos com base em seus requisitos específicos.
Excluir o bucket S3
Alterar a política do bucket para negar quaisquer gravações do serviço CloudTrail
Adicionar política de ciclo de vida ao bucket S3 para excluir objetos
Desativar a chave KMS usada para criptografar os logs do CloudTrail
Você poderia gerar uma chave assimétrica e fazer o CloudTrail criptografar os dados com essa chave e deletar a chave privada para que o conteúdo do CloudTrail não possa ser recuperado. Isso é basicamente um ransomware S3-KMS explicado em:
Ransomware KMS
Esta é uma maneira mais fácil de realizar o ataque anterior com diferentes requisitos de permissões:
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
