AWS - CloudTrail Enum
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
AWS CloudTrail zeichnet Aktivitäten in deiner AWS-Umgebung auf und überwacht sie. Es erfasst detaillierte Ereignisprotokolle, einschließlich wer was, wann und von wo aus getan hat, für alle Interaktionen mit AWS-Ressourcen. Dies bietet eine Prüfspur von Änderungen und Aktionen, die bei der Sicherheitsanalyse, der Compliance-Prüfung und der Verfolgung von Ressourcenänderungen hilft. CloudTrail ist entscheidend für das Verständnis des Verhaltens von Benutzern und Ressourcen, zur Verbesserung der Sicherheitslage und zur Gewährleistung der Einhaltung von Vorschriften.
Jedes protokollierte Ereignis enthält:
Den Namen der aufgerufenen API: eventName
Den aufgerufenen Dienst: eventSource
Die Zeit: eventTime
Die IP-Adresse: SourceIPAddress
Die Agentenmethode: userAgent. Beispiele:
Signing.amazonaws.com - Vom AWS Management Console
console.amazonaws.com - Root-Benutzer des Kontos
lambda.amazonaws.com - AWS Lambda
Die Anforderungsparameter: requestParameters
Die Antwortelemente: responseElements
Ereignisse werden ungefähr alle 5 Minuten in einer JSON-Datei in eine neue Protokolldatei geschrieben, sie werden von CloudTrail gehalten und schließlich werden Protokolldateien ungefähr 15 Minuten später an S3 geliefert. CloudTrails-Protokolle können über Konten und Regionen aggregiert werden. CloudTrail ermöglicht die Verwendung von Protokolldateiintegrität, um zu überprüfen, ob deine Protokolldateien seit der Lieferung durch CloudTrail unverändert geblieben sind. Es erstellt einen SHA-256-Hash der Protokolle in einer Digest-Datei. Ein SHA-256-Hash der neuen Protokolle wird jede Stunde erstellt. Beim Erstellen eines Trails ermöglichen die Ereigniswähler, den Trail anzugeben, der protokolliert werden soll: Management-, Daten- oder Einsichtsevents.
Protokolle werden in einem S3-Bucket gespeichert. Standardmäßig wird die serverseitige Verschlüsselung (SSE-S3) verwendet, sodass AWS den Inhalt für die Personen entschlüsselt, die Zugriff darauf haben, aber für zusätzliche Sicherheit kannst du SSE mit KMS und deinen eigenen Schlüsseln verwenden.
Die Protokolle werden in einem S3-Bucket mit diesem Namensformat gespeichert:
BucketName/AWSLogs/AccountID/CloudTrail/RegionName/YYY/MM/DD
Dabei ist der BucketName: aws-cloudtrail-logs-<accountid>-<random>
Beispiel: aws-cloudtrail-logs-947247140022-ffb95fe7/AWSLogs/947247140022/CloudTrail/ap-south-1/2023/02/22/
Innerhalb jedes Ordners hat jede Protokolldatei einen Namen, der diesem Format folgt: AccountID_CloudTrail_RegionName_YYYYMMDDTHHMMZ_Random.json.gz
Protokolldatei-Namenskonvention
Darüber hinaus werden Digest-Dateien (zur Überprüfung der Dateiintegrität) im gleichen Bucket gespeichert:
Erstelle einen Trail im AWS-Konto, in dem du die Protokolldateien geliefert bekommen möchtest.
Wende Berechtigungen auf den Ziel-S3-Bucket an, die den Zugriff über Konten für CloudTrail erlauben, und erlaube jedem AWS-Konto, das Zugriff benötigt.
Erstelle einen neuen Trail in den anderen AWS-Konten und wähle aus, den im Schritt 1 erstellten Bucket zu verwenden.
Wenn du jedoch alle Protokolle im selben S3-Bucket speichern kannst, kannst du CloudTrail-Protokolle von mehreren Konten nicht in einem CloudWatch-Log aggregieren, das zu einem einzelnen AWS-Konto gehört.
Denke daran, dass ein Konto verschiedene Trails von CloudTrail aktiviert haben kann, die dieselben (oder unterschiedliche) Protokolle in verschiedenen Buckets speichern.
Beim Erstellen eines CloudTrail ist es möglich, anzugeben, dass CloudTrail für alle Konten in der Organisation aktiviert werden soll und die Protokolle in nur 1 Bucket gespeichert werden:
Auf diese Weise kannst du CloudTrail in allen Regionen aller Konten einfach konfigurieren und die Protokolle in 1 Konto zentralisieren (das du schützen solltest).
Du kannst überprüfen, ob die Protokolle nicht verändert wurden, indem du folgendes ausführst:
CloudTrail kann Protokolle automatisch an CloudWatch senden, sodass Sie Warnungen einrichten können, die Sie benachrichtigen, wenn verdächtige Aktivitäten durchgeführt werden. Beachten Sie, dass zur Erlaubnis von CloudTrail, die Protokolle an CloudWatch zu senden, eine Rolle erstellt werden muss, die diese Aktion erlaubt. Wenn möglich, wird empfohlen, die Standardrolle von AWS für diese Aktionen zu verwenden. Diese Rolle ermöglicht es CloudTrail:
CreateLogStream: Dies ermöglicht das Erstellen von CloudWatch Logs-Protokollstreams
PutLogEvents: Liefert CloudTrail-Protokolle an den CloudWatch Logs-Protokollstream
Der CloudTrail-Ereignisverlauf ermöglicht es Ihnen, in einer Tabelle die aufgezeichneten Protokolle zu inspizieren:
CloudTrail Insights analysiert automatisch Schreibmanagementereignisse von CloudTrail-Tracks und benachrichtigt Sie über ungewöhnliche Aktivitäten. Wenn beispielsweise ein Anstieg der TerminateInstance-Ereignisse festgestellt wird, der von festgelegten Baselines abweicht, sehen Sie dies als Insight-Ereignis. Diese Ereignisse erleichtern das Finden und Reagieren auf ungewöhnliche API-Aktivitäten mehr denn je.
Die Einblicke werden im selben Bucket wie die CloudTrail-Protokolle gespeichert: BucketName/AWSLogs/AccountID/CloudTrail-Insight
Integrität der CloudTrail-Protokolldatei
Überprüfen, ob Protokolle manipuliert wurden (modifiziert oder gelöscht)
Verwendet Digest-Dateien (erstellt Hash für jede Datei)
SHA-256-Hashing
SHA-256 mit RSA für digitale Signatur
privater Schlüssel im Besitz von Amazon
Benötigt 1 Stunde, um eine Digest-Datei zu erstellen (jede Stunde zur vollen Stunde)
Unbefugten Zugriff stoppen
Verwenden Sie IAM-Richtlinien und S3-Bucket-Richtlinien
Sicherheitsteam —> Administratorzugriff
Prüfer —> Nur-Lesezugriff
Verwenden Sie SSE-S3/SSE-KMS, um die Protokolle zu verschlüsseln
Verhindern, dass Protokolldateien gelöscht werden
Beschränken Sie den Löschzugriff mit IAM- und Bucket-Richtlinien
Konfigurieren Sie S3 MFA-Löschen
Überprüfen Sie mit der Protokolldateivalidierung
Der AWS-Zugriffsberater stützt sich auf die letzten 400 Tage der AWS CloudTrail-Protokolle, um seine Einblicke zu gewinnen. CloudTrail erfasst eine Historie der AWS-API-Aufrufe und verwandten Ereignisse, die in einem AWS-Konto durchgeführt wurden. Der Zugriffsberater nutzt diese Daten, um zu zeigen, wann Dienste zuletzt aufgerufen wurden. Durch die Analyse der CloudTrail-Protokolle kann der Zugriffsberater bestimmen, auf welche AWS-Dienste ein IAM-Benutzer oder eine Rolle zugegriffen hat und wann dieser Zugriff stattfand. Dies hilft AWS-Administratoren, informierte Entscheidungen über die Verfeinerung von Berechtigungen zu treffen, da sie Dienste identifizieren können, die über längere Zeiträume nicht aufgerufen wurden, und potenziell zu breite Berechtigungen basierend auf realen Nutzungsmustern reduzieren können.
Daher informiert der Zugriffsberater über die unnötigen Berechtigungen, die Benutzern erteilt werden, sodass der Administrator sie entfernen kann.
Es ist möglich, eine CVS-Injektion innerhalb von CloudTrail durchzuführen, die beliebigen Code ausführt, wenn die Protokolle im CSV-Format exportiert und mit Excel geöffnet werden. Der folgende Code generiert einen Protokolleintrag mit einem schlechten Trail-Namen, der die Payload enthält:
Für weitere Informationen zu CSV-Injektionen siehe die Seite:
Für weitere Informationen zu dieser spezifischen Technik siehe https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/
Honeytokens werden erstellt, um die Exfiltration sensibler Informationen zu erkennen. Im Fall von AWS sind sie AWS-Schlüssel, deren Verwendung überwacht wird. Wenn etwas eine Aktion mit diesem Schlüssel auslöst, dann muss jemand diesen Schlüssel gestohlen haben.
Allerdings verwenden Honeytokens wie die von Canarytokens, SpaceCrab, SpaceSiren entweder erkennbare Kontonamen oder verwenden dieselbe AWS-Konto-ID für alle ihre Kunden. Daher, wenn Sie den Kontonamen und/oder die Konto-ID erhalten können, ohne dass Cloudtrail ein Protokoll erstellt, könnten Sie wissen, ob der Schlüssel ein Honeytoken ist oder nicht.
Pacu hat einige Regeln, um zu erkennen, ob ein Schlüssel zu Canarytokens, SpaceCrab, SpaceSiren** gehört:**
Wenn canarytokens.org im Rollennamen erscheint oder die Konto-ID 534261010715 in der Fehlermeldung erscheint.
Bei neueren Tests verwenden sie das Konto 717712589309 und haben immer noch den canarytokens.com-String im Namen.
Wenn SpaceCrab im Rollennamen in der Fehlermeldung erscheint.
SpaceSiren verwendet uuids, um Benutzernamen zu generieren: [a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89aAbB][a-f0-9]{3}-[a-f0-9]{12}
Wenn der Name zufällig generiert aussieht, gibt es hohe Wahrscheinlichkeiten, dass es sich um ein HoneyToken handelt.
Sie können die Konto-ID aus dem kodierten Teil des Zugriffsschlüssels erhalten, wie hier erklärt und die Konto-ID mit Ihrer Liste von Honeytokens AWS-Konten überprüfen:
Check more information in the orginal research.
Die effektivste Technik dafür ist tatsächlich eine einfache. Verwenden Sie einfach den Schlüssel, den Sie gerade gefunden haben, um auf einen Dienst in Ihrem eigenen Angreifer-Konto zuzugreifen. Dies wird CloudTrail dazu bringen, ein Protokoll in IHREM EIGENEN AWS-Konto und nicht im Konto des Opfers zu generieren.
Das Problem ist, dass die Ausgabe Ihnen einen Fehler anzeigen wird, der die Kontonummer und den Kontonamen angibt, sodass Sie sehen können, ob es sich um ein Honeytoken handelt.
In der Vergangenheit gab es einige AWS-Dienste, die keine Protokolle an CloudTrail senden (finden Sie eine Liste hier). Einige dieser Dienste werden antworten mit einem Fehler, der die ARN der Schlüsselrolle enthält, wenn jemand Unbefugtes (der Honeytoken-Schlüssel) versucht, darauf zuzugreifen.
Auf diese Weise kann ein Angreifer die ARN des Schlüssels erhalten, ohne ein Protokoll auszulösen. In der ARN kann der Angreifer die AWS-Kontonummer und den Namen sehen, es ist einfach, die Kontonummern und Namen der HoneyToken-Unternehmen zu kennen, sodass ein Angreifer auf diese Weise identifizieren kann, ob das Token ein HoneyToken ist.
Beachten Sie, dass alle öffentlichen APIs, die nicht CloudTrail-Protokolle erstellen, jetzt behoben sind, sodass Sie möglicherweise Ihre eigenen finden müssen...
Für weitere Informationen siehe die original research.
Bestimmte AWS-Dienste werden einige Infrastrukturen wie Datenbanken oder Kubernetes-Cluster (EKS) erzeugen. Ein Benutzer, der direkt mit diesen Diensten spricht (wie der Kubernetes-API), wird die AWS-API nicht verwenden, sodass CloudTrail diese Kommunikation nicht sehen kann.
Daher könnte ein Benutzer mit Zugriff auf EKS, der die URL der EKS-API entdeckt hat, ein Token lokal generieren und direkt mit dem API-Dienst sprechen, ohne von CloudTrail erkannt zu werden.
Weitere Informationen in:
AWS - EKS Post ExploitationIm ersten Beispiel wird ein einzelner Ereignis-Selector als JSON-Array mit einem einzelnen Objekt bereitgestellt. Der "ReadWriteType": "ReadOnly" zeigt an, dass der Ereignis-Selector nur schreibgeschützte Ereignisse erfassen sollte (CloudTrail-Insights werden beispielsweise keine Schreibereignisse überprüfen).
Sie können den Ereignis-Selector basierend auf Ihren spezifischen Anforderungen anpassen.
Löschen Sie den S3-Bucket
Ändern Sie die Bucket-Richtlinie, um alle Schreibvorgänge vom CloudTrail-Dienst zu verweigern
Fügen Sie eine Lebenszyklusrichtlinie zum S3-Bucket hinzu, um Objekte zu löschen
Deaktivieren Sie den KMS-Schlüssel, der zum Verschlüsseln der CloudTrail-Protokolle verwendet wird
Sie könnten einen asymmetrischen Schlüssel generieren und CloudTrail die Daten mit diesem Schlüssel verschlüsseln und den privaten Schlüssel löschen, sodass die Inhalte von CloudTrail nicht wiederhergestellt werden können. Dies ist im Grunde eine S3-KMS-Ransomware, die in folgendem erklärt wird:
AWS - S3 Post ExploitationKMS Ransomware
Dies ist der einfachste Weg, um den vorherigen Angriff mit unterschiedlichen Berechtigungsanforderungen durchzuführen:
AWS - KMS Post ExploitationLernen & Üben von AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & Üben von GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
