AWS - CloudTrail Enum
Last updated
Last updated
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
AWS CloudTrail registreer en monitor aktiwiteit binne jou AWS omgewing. Dit vang gedetailleerde gebeurtenis logs op, 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 geregistreerde 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 versoek parameters: requestParameters
Die antwoord elemente: responseElements
Gebeurtenisse word na 'n nuwe log lêer ongeveer elke 5 minute in 'n JSON lêer geskryf, hulle word deur CloudTrail gehou en uiteindelik, log lêers word aan S3 gelewer ongeveer 15min na. CloudTrail se logs kan geaggregeer word oor rekeninge en oor streke. CloudTrail laat toe om log lêer integriteit te gebruik om te kan verifieer dat jou log lêers onveranderd gebly het sedert CloudTrail dit aan jou gelewer 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 gebeurtenis keuses jou toelaat om die trail aan te dui om te log: Bestuur, data of insig gebeurtenisse.
Logs word in 'n S3 emmer gestoor. Standaard word Server Side Encryption (SSE-S3) gebruik, so AWS sal die inhoud ontsleutel vir die mense wat toegang het, maar vir addisionele sekuriteit kan jy SSE met KMS en jou eie sleutels gebruik.
Die logs 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 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 emmer wees in:
Skep 'n Trail in die AWS rekening waar jy die log lêers wil laat lewer
Pas toestemmings toe op die bestemmings S3 emmer 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 emmer in stap 1 te gebruik
Tog, selfs al kan jy al die logs in dieselfde S3 emmer stoor, kan jy nie CloudTrail logs van meerdere rekeninge in 'n CloudWatch Logs wat aan 'n enkele AWS rekening behoort, aggregeer nie.
Onthou dat 'n rekening verskillende Trails van CloudTrail geaktiveer kan hê wat dieselfde (of verskillende) logs in verskillende emmers stoor.
Wanneer 'n CloudTrail geskep word, is dit moontlik om aan te dui om cloudtrail vir al die rekeninge in die org te aktiveer en die logs in net 1 emmer 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).
Jy kan kontroleer dat die logs nie verander is deur te loop
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
CloudTrail Gebeurtenisgeskiedenis laat jou toe om in 'n tabel die logs wat opgeneem is, te inspekteer:
CloudTrail Insigte analiseer outomaties skrywe bestuur 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 Insig gebeurtenis sien. Hierdie gebeurtenisse maak om ongewone API aktiwiteit te vind en daarop te reageer makliker as ooit.
Die insigte word in dieselfde emmer as die CloudTrail logs gestoor in: BucketName/AWSLogs/AccountID/CloudTrail-Insight
CloudTrail Log Lêer Integriteit
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 ongemagtigde toegang
Gebruik IAM beleid en S3 emmer beleid
sekuriteitspan —> admin toegang
ouditeurs —> lees slegs toegang
Gebruik SSE-S3/SSE-KMS om die logs te enkripteer
Voorkom dat log lêers verwyder word
Beperk verwyder toegang met IAM en emmer beleid
Konfigureer S3 MFA verwydering
Verifieer met Log Lêer Verifikasie
AWS Toegang Adviseur 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. Toegang Adviseur gebruik hierdie data om te wys wanneer dienste laas toeganklik was. Deur CloudTrail logs te analiseer, kan Toegang Adviseur 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 toestemmings kan verminder op grond van werklike gebruikspatrone.
Daarom informeer Toegang Adviseur oor die onnodige toestemmings wat aan gebruikers gegee word sodat die admin dit kan verwyder
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:
For more information about CSV Injections check the page:
For more information about this specific technique check https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/
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 geskep is deur Canarytokens, SpaceCrab, SpaceSiren 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 genereer, 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 lyk soos dit lukraak gegenereer is, is daar 'n hoë waarskynlikheid dat dit 'n HoneyToken is.
Jy kan die Rekening ID kry van die gecodeerde binne die toegang sleutel soos hier verduidelik en die rekening ID met jou lys van Honeytokens AWS rekeninge nagaan:
Check more information in the orginal research.
Die mees effektiewe tegniek hiervoor is eintlik 'n eenvoudige een. Gebruik net die sleutel wat jy net 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 jou 'n fout sal wys wat die rekening ID en die rekening naam aandui, so jy sal in staat wees om te sien of dit 'n Honeytoken is.
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 antwoordgee 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.
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 original research.
Sekere AWS dienste sal sekere infrastruktuur genereer soos Databases of Kubernetes klusters (EKS). '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 info in:
AWS - EKS Post ExploitationIn die eerste voorbeeld word 'n enkele gebeurtenis selektor as 'n JSON-array met 'n enkele objek verskaf. Die "ReadWriteType": "ReadOnly" dui aan dat die gebeurtenis selektor slegs lees-slegs gebeurtenisse moet vasvang (so CloudTrail insigte sal nie skryf gebeurtenisse nagaan nie).
Jy kan die gebeurtenis selektor aanpas op grond van jou spesifieke vereistes.
Verwyder die S3-bucket
Verander die bucket-beleid om enige skrywe van die CloudTrail-diens te weier
Voeg 'n lewensiklusbeleid by die S3-bucket om voorwerpe te verwyder
Deaktiveer die kms-sleutel wat gebruik word om die CloudTrail-logboek te enkripteer
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 'n S3-KMS ransomware wat verduidelik word in:
AWS - S3 Post ExploitationKMS ransomware
Dit is 'n maklike manier om die vorige aanval met verskillende toestemmingsvereistes uit te voer:
AWS - KMS Post ExploitationLearn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
