gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-03-12 21:22:57 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation

Browse Source
This commit is contained in:
Translator
2026-02-14 19:50:16 +00:00
parent 541bbbd172
commit 8a86c1ba02
1 changed files with 51 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

64
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
View File

@@ -10,32 +10,70 @@ Für weitere Informationen siehe:
../../aws-services/aws-s3-athena-and-glacier-enum.md
{{#endref}}
### Sensitive Information
### Sensible Informationen
Manchmal wirst du in den Buckets lesbare, sensible Informationen finden können. Zum Beispiel terraform state secrets.
Manchmal kannst du lesbare, sensible Informationen in den Buckets finden. Zum Beispiel terraform state secrets.
### Pivoting
Verschiedene Plattformen könnten S3 zum Speichern sensibler Assets verwenden.\
Zum Beispiel könnte **airflow** dort **DAGs** **code** ablegen, oder **web pages** könnten direkt von S3 ausgeliefert werden. Ein Angreifer mit Schreibberechtigungen könnte **modify the code** im Bucket verwenden, um auf andere Plattformen zu **pivot**, oder durch Änderung von JS-Dateien **takeover accounts**.
Verschiedene Plattformen könnten S3 nutzen, um sensible Assets zu speichern. Zum Beispiel könnte **airflow** dort **DAGs** **code** ablegen, oder **web pages** könnten direkt von S3 ausgeliefert werden. Ein Angreifer mit Schreibrechten könnte den **code** im Bucket **modify the code**, um zu anderen Plattformen zu **pivot**, oder durch Änderungen an JS-Dateien **takeover accounts** durchführen.
### S3 Ransomware
In diesem Szenario **erstellt der Angreifer einen KMS (Key Management Service) key in seinem eigenen AWS account** oder in einem anderen kompromittierten Account. Anschließend macht er diesen **key für jeden auf der Welt zugänglich**, sodass jeder AWS-Benutzer, jede Rolle oder jedes Konto Objekte mit diesem Key verschlüsseln kann. Die Objekte können jedoch nicht entschlüsselt werden.
In diesem Szenario erstellt der **attacker creates a KMS (Key Management Service) key in their own AWS account** oder in einem anderen kompromittierten Account. Anschließend macht er diesen **key accessible to anyone in the world**, sodass jeder AWS-Benutzer, Role oder Account Objekte mit diesem Key verschlüsseln kann. Allerdings können die Objekte dann nicht entschlüsselt werden.
Der Angreifer identifiziert ein Ziel-S3-Bucket und erlangt Schreibzugriff darauf, indem er verschiedene Methoden anwendet. Das kann an einer schlecht konfigurierten, öffentlich zugänglichen Bucket liegen oder daran, dass der Angreifer Zugang zur AWS-Umgebung selbst erlangt hat. Typischerweise zielt der Angreifer auf Buckets mit sensiblen Daten ab, wie PII, PHI, Logs, Backups usw.
Der Angreifer identifiziert einen Ziel‑**S3 bucket and gains write-level access** mittels verschiedener Methoden. Das kann an einer fehlerhaften Bucket‑Konfiguration liegen, die den Bucket öffentlich zugänglich macht, oder daran, dass der Angreifer Zugriff auf die AWS‑Umgebung selbst erlangt hat. Ziel sind dabei oft Buckets mit sensiblen Daten wie PII, PHI, Logs, Backups usw.
Um festzustellen, ob ein Bucket für Ransomware geeignet ist, überprüft der Angreifer dessen Konfiguration. Dazu gehört die Kontrolle, ob **S3 Object Versioning** aktiviert ist und ob **multi-factor authentication delete (MFA delete)** aktiviert ist. Wenn Object Versioning nicht aktiviert ist, kann der Angreifer fortfahren. Ist Object Versioning aktiviert, aber MFA delete deaktiviert, kann der Angreifer **Object Versioning deaktivieren**. Sind sowohl Object Versioning als auch MFA delete aktiviert, wird es deutlich schwieriger, dieses Bucket zu verschlüsseln.
Um zu prüfen, ob ein Bucket für Ransomware geeignet ist, überprüft der Angreifer dessen Konfiguration. Dazu gehört die Kontrolle, ob **S3 Object Versioning** aktiviert ist und ob **multi-factor authentication delete (MFA delete)** aktiviert ist. Wenn Object Versioning nicht aktiviert ist, kann der Angreifer fortfahren. Wenn Object Versioning aktiviert, aber MFA delete deaktiviert ist, kann der Angreifer **Object Versioning deaktivieren**. Sind sowohl Object Versioning als auch MFA delete aktiviert, wird es für den Angreifer deutlich schwieriger, diesen Bucket zu verschlüsseln.
Über die AWS API ersetzt der Angreifer jedes Objekt im Bucket durch eine mit seinem KMS-Schlüssel verschlüsselte Kopie. Dadurch werden die Daten im Bucket effektiv verschlüsselt und ohne den Key unzugänglich.
Mithilfe der AWS API ersetzt der Angreifer dann **replaces each object in the bucket with an encrypted copy using their KMS key**, wodurch die Daten im Bucket effektiv verschlüsselt und ohne den Key unzugänglich werden.
Um den Druck zu erhöhen, plant der Angreifer die Löschung des für den Angriff verwendeten KMS-Keys. Dadurch hat das Ziel ein 7-Tage-Fenster, um seine Daten wiederherzustellen, bevor der Key gelöscht wird und die Daten dauerhaft verloren sind.
Um zusätzlichen Druck aufzubauen, plant der Angreifer die Löschung des verwendeten KMS‑Keys. Das gibt dem Opfer ein 7‑tägiges Fenster, um die Daten wiederherzustellen, bevor der Key gelöscht wird und die Daten dauerhaft verloren sind.
Abschließend könnte der Angreifer eine finale Datei hochladen, üblicherweise namens "ransom-note.txt", die Anweisungen enthält, wie das Ziel seine Dateien zurückbekommen soll. Diese Datei wird unverschlüsselt hochgeladen, um die Aufmerksamkeit des Ziels zu erregen und auf den Ransomware-Angriff hinzuweisen.
Schließlich könnte der Angreifer eine finale Datei hochladen, üblicherweise mit dem Namen "ransom-note.txt", die Anweisungen enthält, wie das Opfer seine Dateien zurückbekommen soll. Diese Datei wird ungeöffnet/ohne Verschlüsselung hochgeladen, vermutlich um die Aufmerksamkeit des Opfers zu erregen und auf den Ransomware‑Angriff hinzuweisen.
#### SSE-C (Customer-Provided Key) Ransomware (Codefinger-like)
Eine weitere Variante missbraucht **SSE-C** (S3 server-side encryption with **customer-provided keys**). Bei SSE-C liefert der **client provides the encryption key on every request** und **AWS does not store the key**. Das bedeutet, wenn ein Angreifer Objekte mit **their own SSE-C key** neu schreibt, werden die Daten des Opfers unlesbar, sofern das Opfer nicht den vom Angreifer kontrollierten Key bereitstellen kann.
- **Preconditions:** Compromised AWS credentials (or any principal with the right permissions) and the ability to **rewrite objects** (e.g., `s3:PutObject` on the target keys/prefixes). This is often paired with the ability to set destructive lifecycle policies (see below), e.g. `s3:PutLifecycleConfiguration`.
- **Attack chain:**
1. Attacker generates a random 256-bit key (AES-256) and keeps it.
2. Attacker **rewrites** existing objects (same object keys) using SSE-C headers so the stored object is now encrypted with the attacker key.
3. Victim cannot download/decrypt without providing the SSE-C key (even if IAM permissions are fine).
4. Attacker can delete the key (or simply never provide it) to make data unrecoverable.
Example (conceptual) CLI usage:
```bash
# Upload/overwrite an object encrypted with attacker-provided SSE-C key
aws s3 cp ./file s3://<BUCKET>/<KEY> \
--sse-c AES256 \
--sse-c-key <BASE64_32_BYTES>
# Download requires providing the same key again
aws s3 cp s3://<BUCKET>/<KEY> ./file \
--sse-c AES256 \
--sse-c-key <BASE64_32_BYTES>
```
##### Druck erhöhen: Lifecycle "Timer"-Missbrauch
Um Wiederherstellungsoptionen (wie alte Versionen) zu entfernen, können Angreifer SSE-C-Rewrites mit **Lifecycle-Regeln** koppeln, die Objekte nach kurzer Zeit verfallen lassen und/oder noncurrent versions löschen:
- `s3:PutLifecycleConfiguration` auf dem Bucket erlaubt einem Angreifer, Löschungen zu planen, ohne für jedes Objekt/jede Version explizite Delete-Operationen auszuführen.
- Dies ist besonders wirkungsvoll, wenn **versioning is enabled**, weil dadurch die „vorherige funktionsfähige Version“ entfernt werden kann, die sonst eine Wiederherstellung ermöglichen würde.
##### Erkennung & Gegenmaßnahmen
- Bevorzugen Sie **SSE-KMS** (oder SSE-S3) gegenüber SSE-C, es sei denn, es gibt einen triftigen betrieblichen Grund, SSE-C zuzulassen.
- Überwachen/Alarmieren Sie bei `PutObject`-Anfragen, die SSE-C-Header verwenden (CloudTrail data events für S3).
- Überwachen/Alarmieren Sie bei unerwarteten `PutBucketLifecycleConfiguration` (Lifecycle-Änderungen).
- Überwachen/Alarmieren Sie bei plötzlichen Anstiegen an Überschreib-Aktivitäten (gleiche Keys werden schnell aktualisiert) sowie bei Delete-Marker-/Versionslöschungen.
- Beschränken Sie risikoreiche Berechtigungen: Limitieren Sie `s3:PutObject` auf notwendige Präfixe; schränken Sie `s3:PutLifecycleConfiguration` und `s3:PutBucketVersioning` stark ein; erwägen Sie die Erzwingung von MFA für sensible Admin-Aktionen (falls anwendbar) und verwenden Sie separate Admin-Rollen mit Genehmigungen.
- Wiederherstellungsstrategie: Verwenden Sie **versioning**, **backups** und unveränderliche/offline-Kopien (S3 replication in ein geschütztes Konto, Backup-Vaults, etc.); schützen Sie noncurrent versions vor aggressiven Löschungen und sichern Sie Lifecycle-Änderungen mit SCPs / Guardrails.
### `s3:RestoreObject`
Ein Angreifer mit der Berechtigung `s3:RestoreObject` kann Objekte reaktivieren, die in Glacier oder Deep Archive archiviert sind, und sie vorübergehend zugänglich machen. Das ermöglicht die Wiederherstellung und Exfiltration historisch archivierter Daten (Backups, Snapshots, Logs, Zertifikate, alte Secrets), die normalerweise nicht erreichbar wären. Kombiniert der Angreifer diese Berechtigung mit Leserechten (z. B. `s3:GetObject`), kann er vollständige Kopien sensibler Daten erhalten.
Ein Angreifer mit der Berechtigung `s3:RestoreObject` kann Objekte reaktivieren, die in Glacier oder Deep Archive archiviert wurden, und sie so vorübergehend zugänglich machen. Dies ermöglicht die Wiederherstellung und Exfiltration historisch archivierter Daten (Backups, Snapshots, Logs, Zertifikate, alte Secrets), die normalerweise nicht erreichbar wären. Kombiniert der Angreifer diese Berechtigung mit Lese-Berechtigungen (z. B. `s3:GetObject`), kann er vollständige Kopien sensibler Daten erlangen.
```bash
aws s3api restore-object \
--bucket <BUCKET_NAME> \
@@ -47,7 +85,7 @@ aws s3api restore-object \
```
### `s3:Delete*`
Ein Angreifer mit der s3:Delete*-Berechtigung kann Objekte, Versionen und komplette Buckets löschen, Backups stören und sofortigen sowie irreversiblen Datenverlust, Vernichtung von Beweismitteln und Kompromittierung von Backup- oder Wiederherstellungsartefakten verursachen.
Ein Angreifer mit der Berechtigung s3:Delete* kann Objekte, Versionen und ganze Buckets löschen, Backups stören und unmittelbaren sowie irreversiblen Datenverlust verursachen, Beweise vernichten und Backup- oder Wiederherstellungsartefakte kompromittieren.
```bash
# Delete an object from a bucket
aws s3api delete-object \
@@ -64,6 +102,6 @@ aws s3api delete-object \
aws s3api delete-bucket \
--bucket <BUCKET_NAME>
```
**Für weitere Informationen** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
**Für weitere Informationen** [**siehe die Originalforschung**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
{{#include ../../../../banners/hacktricks-training.md}}