AWS - S3 Post Exploitation

Tip

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

Unterstütze HackTricks

S3

Für weitere Informationen siehe:

AWS - S3, Athena & Glacier Enum

Sensible Informationen

Manchmal kannst du lesbare, sensible Informationen in den Buckets finden. Zum Beispiel terraform state secrets.

Pivoting

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

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

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:

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

aws s3api restore-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY> \
--restore-request '{
"Days": <NUMBER_OF_DAYS>,
"GlacierJobParameters": { "Tier": "Standard" }
}'

s3:Delete*

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.

# Delete an object from a bucket
aws s3api delete-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY>

# Delete a specific version
aws s3api delete-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY> \
--version-id <VERSION_ID>

# Delete a bucket
aws s3api delete-bucket \
--bucket <BUCKET_NAME>

Für weitere Informationen siehe die Originalforschung.

Tip

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

Unterstütze HackTricks