Last updated
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
AWS CloudTrail zeichnet Aktivitäten in Ihrer AWS-Umgebung auf und überwacht sie. Es erfasst detaillierte Ereignisprotokolle, einschließlich wer was, wann und von wo 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, die Verbesserung der Sicherheitslage und die 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. CloudTrail-Protokolle können über Konten und Regionen aggregiert werden. CloudTrail ermöglicht die Verwendung von Protokolldateiintegrität, um zu überprüfen, ob Ihre 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, anzugeben, welche Trails protokolliert werden sollen: Management-, Daten- oder Einblickereignisse.
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 können Sie SSE mit KMS und Ihren 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
Protokolldateibenennungskonvention
Darüber hinaus werden Digest-Dateien (zur Überprüfung der Dateiintegrität) im gleichen Bucket gespeichert:
Erstellen Sie einen Trail im AWS-Konto, in dem die Protokolldateien geliefert werden sollen.
Wenden Sie Berechtigungen auf den Ziel-S3-Bucket an, um den Zugriff über Konten für CloudTrail zu ermöglichen, und erlauben Sie jedem AWS-Konto, das Zugriff benötigt.
Erstellen Sie einen neuen Trail in den anderen AWS-Konten und wählen Sie den im Schritt 1 erstellten Bucket aus.
Wenn Sie jedoch alle Protokolle im selben S3-Bucket speichern können, können Sie CloudTrail-Protokolle von mehreren Konten nicht in einem CloudWatch-Log aggregieren, das zu einem einzelnen AWS-Konto gehört.
Denken Sie 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 können Sie CloudTrail in allen Regionen aller Konten einfach konfigurieren und die Protokolle in 1 Konto zentralisieren (das Sie schützen sollten).
Sie können überprüfen, ob die Protokolle nicht verändert wurden, indem Sie folgendes ausführen:
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 Trails 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 |
|
Unbefugten Zugriff stoppen |
|
Verhindern, dass Protokolldateien gelöscht werden |
|
Der AWS Access Advisor 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 Access Advisor nutzt diese Daten, um zu zeigen, wann Dienste zuletzt aufgerufen wurden. Durch die Analyse der CloudTrail-Protokolle kann der Access Advisor 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 Access Advisor ü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 willkürlichen 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 die canarytokens.com-Zeichenfolge 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 original 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.
Die Sache 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 mit einem Fehler antworten, 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:
AWS - S3 Post ExploitationKMS ransomware
Dies ist der einfachste Weg, den vorherigen Angriff mit unterschiedlichen Berechtigungsanforderungen durchzuführen:
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)
