Add content from: FlareProx: Deploy Cloudflare Worker pass-through proxies for...

- Remove searchindex.js (auto-generated file)

src/SUMMARY.md

@@ -41,6 +41,7 @@
 - [Atlantis Security](pentesting-ci-cd/atlantis-security.md)
 - [Cloudflare Security](pentesting-ci-cd/cloudflare-security/README.md)
   - [Cloudflare Domains](pentesting-ci-cd/cloudflare-security/cloudflare-domains.md)
+  - [Cloudflare Workers Pass Through Proxy Ip Rotation](pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md)
   - [Cloudflare Zero Trust Network](pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md)
 - [Okta Security](pentesting-ci-cd/okta-security/README.md)
   - [Okta Hardening](pentesting-ci-cd/okta-security/okta-hardening.md)
@@ -572,3 +573,6 @@
 
 - [HackTricks Pentesting Network$$external:https://book.hacktricks.wiki/en/generic-methodologies-and-resources/pentesting-network/index.html$$]()
 - [HackTricks Pentesting Services$$external:https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-ssh.html$$]()
+
+    - [Feature Store Poisoning](pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md)
+  - [Aws Sqs Dlq Redrive Exfiltration](pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md)

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

@@ -54,6 +54,12 @@ On each Cloudflare's worker check:
 > [!WARNING]
 > 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
 
 On each R2 bucket check:

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

@@ -0,0 +1,307 @@
+# Abusing Cloudflare Workers as pass-through proxies (IP rotation, FireProx-style)
+
+{{#include ../../banners/hacktricks-training.md}}
+
+Cloudflare Workers can be deployed as transparent HTTP pass-through proxies where the upstream target URL is supplied by the client. Requests egress from Cloudflare's network so the target observes Cloudflare IPs instead of the client's. This mirrors the well-known FireProx technique on AWS API Gateway, but uses Cloudflare Workers.
+
+Key capabilities:
+- Support for all HTTP methods (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD)
+- Target can be supplied via query parameter (?url=...), a header (X-Target-URL), or even encoded in the path (e.g., /https://target)
+- Headers and body are proxied through with hop-by-hop/header filtering as needed
+- Responses are relayed back, preserving status code and most headers
+- Optional spoofing of X-Forwarded-For (if the Worker sets it from a user-controlled header)
+- Extremely fast/easy rotation by deploying multiple Worker endpoints and fanning out requests
+
+How it works (flow):
+1) Client sends an HTTP request to a Worker URL (<name>.<account>.workers.dev or a custom domain route).
+2) Worker extracts the target from either a query parameter (?url=...), the X-Target-URL header, or a path segment if implemented.
+3) Worker forwards the incoming method, headers, and body to the specified upstream URL (filtering problematic headers).
+4) Upstream response is streamed back to the client through Cloudflare; the origin sees Cloudflare egress IPs.
+
+Worker implementation example
+- Reads target URL from query param, header, or path
+- Copies a safe subset of headers and forwards the original method/body
+- Optionally sets X-Forwarded-For using a user-controlled header (X-My-X-Forwarded-For) or a random IP
+- Adds permissive CORS and handles preflight
+
+<details>
+<summary>Example Worker (JavaScript) for 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>
+
+Automating deployment and rotation with FlareProx
+FlareProx is a Python tool that uses the Cloudflare API to deploy many Worker endpoints and rotate across them. This provides FireProx-like IP rotation from Cloudflare’s network.
+
+Setup
+1) Create a Cloudflare API Token using the “Edit Cloudflare Workers” template and get your Account ID from the dashboard.
+2) Configure FlareProx:
+
+```bash
+git clone https://github.com/MrTurvey/flareprox
+cd flareprox
+pip install -r requirements.txt
+```
+
+Create config file flareprox.json:
+
+```json
+{
+  "cloudflare": {
+    "api_token": "your_cloudflare_api_token",
+    "account_id": "your_cloudflare_account_id"
+  }
+}
+```
+
+CLI usage
+- Create N Worker proxies:
+```bash
+python3 flareprox.py create --count 2
+```
+- List endpoints:
+```bash
+python3 flareprox.py list
+```
+- Health-test endpoints:
+```bash
+python3 flareprox.py test
+```
+- Delete all endpoints:
+```bash
+python3 flareprox.py cleanup
+```
+
+Routing traffic through a Worker
+- 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
+```
+- Path form (if implemented):
+```bash
+curl https://your-worker.account.workers.dev/https://httpbin.org/ip
+```
+- Method examples:
+```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 control
+If the Worker honors X-My-X-Forwarded-For, you can influence the upstream X-Forwarded-For value:
+```bash
+curl -H "X-My-X-Forwarded-For: 203.0.113.10" \
+     "https://your-worker.account.workers.dev?url=https://httpbin.org/headers"
+```
+
+Programmatic usage
+Use the FlareProx library to create/list/test endpoints and route requests from Python.
+
+<details>
+<summary>Python example: Send a POST via a random Worker endpoint</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
+- Point tooling (for example, Burp Suite) at the Worker URL.
+- Supply the real upstream using ?url= or X-Target-URL.
+- HTTP semantics (methods/headers/body) are preserved while masking your source IP behind Cloudflare.
+
+Operational notes and limits
+- Cloudflare Workers Free plan allows roughly 100,000 requests/day per account; use multiple endpoints to distribute traffic if needed.
+- Workers run on Cloudflare’s network; many targets will only see Cloudflare IPs/ASN, which can bypass naive IP allow/deny lists or geo heuristics.
+- Use responsibly and only with authorization. Respect ToS and robots.txt.
+
+Detection and mitigation (defender notes)
+If your application is the target and you wish to prevent access via generic Cloudflare-originated proxies (Workers, other Cloudflare egress):
+- Do not rely solely on IP allow/deny lists; Cloudflare Workers share Cloudflare IP space and ASN (AS13335). Blocking all Cloudflare IPs is often impractical.
+- Require strong request authentication at the application layer (tokens, HMAC-signed headers, mTLS, per-client API keys), and validate them server-side.
+- For Cloudflare-protected origins you control, consider:
+  - Authenticated Origin Pulls or mTLS between Cloudflare and origin so only your own zone can reach the origin.
+  - WAF/Firewall Rules that require a secret header or signed token and block requests missing them.
+  - API Shield (schema validation, mTLS, JWT validation) and Bot Fight Mode/Super Bot Fight Mode to reduce automated abuse.
+  - Rate limiting by path/user token; challenge or block requests lacking expected cookies/headers from your first-party app flows.
+- Monitor for anomalies: unusual user agents, inconsistent headers, rapidly shifting Cloudflare IPs, or requests to endpoints that should only be hit by your front-end.
+
+Related techniques
+- FireProx (AWS API Gateway) pioneered pass-through proxying for IP rotation and header control; Workers provide a similar pattern with Cloudflare egress.
+
+## References
+- [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-persistence/aws-lambda-persistence/aws-lambda-async-self-loop-persistence.md

@@ -1,5 +1,7 @@
 # AWS - Lambda Async Self-Loop Persistence via Destinations + Recursion Allow
 
+{{#include ../../../../banners/hacktricks-training.md}}
+
 Abuse Lambda asynchronous destinations together with the Recursion configuration to make a function continually re-invoke itself with no external scheduler (no EventBridge, cron, etc.). By default, Lambda terminates recursive loops, but setting the recursion config to Allow re-enables them. Destinations deliver on the service side for async invokes, so a single seed invoke creates a stealthy, code-free heartbeat/backdoor channel. Optionally throttle with reserved concurrency to keep noise low.
 
 Notes
@@ -99,3 +101,4 @@ aws iam delete-role-policy --role-name "$ROLE_NAME" --policy-name allow-invoke-s
 
 ## Impact
 - Single async invoke causes Lambda to continually re-invoke itself with no external scheduler, enabling stealthy persistence/heartbeat. Reserved concurrency can limit noise to a single warm execution.
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md

@@ -50,7 +50,7 @@ def generate_password():
     return password
 ```
 
-{{#include ../../../../banners/hacktricks-training.md}}
+
 
 
 
@@ -248,3 +248,4 @@ aws secretsmanager get-resource-policy --region "$R2" --secret-id "$NAME"
 # Configure attacker credentials and read
 aws secretsmanager get-secret-value --region "$R2" --secret-id "$NAME" --query SecretString --output text
 ```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md

@@ -119,3 +119,4 @@ aws ec2 delete-instance-connect-endpoint \
 > Notes
 > - The injected SSH key is only valid for ~60 seconds; send the key right before opening the tunnel/SSH.
 > - `OS_USER` must match the AMI (e.g., `ubuntu` for Ubuntu, `ec2-user` for Amazon Linux 2).
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md

@@ -55,3 +55,4 @@ curl --interface $HIJACK_IP -sS http://$PROTECTED_HOST -o /tmp/poc.out && head -
 ## Impact
 - Bypass IP allowlists and impersonate trusted hosts within the VPC by moving secondary private IPs between ENIs in the same subnet/AZ.
 - Reach internal services that gate access by specific source IPs, enabling lateral movement and data access.
+{{#include ../../../../banners/hacktricks-training.md}}

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

@@ -94,7 +94,7 @@ aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imag
 aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
 ```
 
-{{#include ../../../../banners/hacktricks-training.md}}
+
 
 
 
@@ -218,3 +218,4 @@ aws ecr put-registry-scanning-configuration --region $REGION --scan-type BASIC -
 aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value AWS_NATIVE
 ```
 
+{{#include ../../../../banners/hacktricks-training.md}}

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

@@ -60,7 +60,7 @@ aws ecs submit-attachment-state-changes ...
 
 The EC2 instance will probably also have the permission `ecr:GetAuthorizationToken` allowing it to **download images** (you could search for sensitive info in them).
 
-{{#include ../../../../banners/hacktricks-training.md}}
+
 
 
 
@@ -139,3 +139,4 @@ aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
 aws ecs deregister-task-definition ht-ebs-read
 ```
 
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-efs-mount-injection.md

@@ -1,5 +1,7 @@
 # AWS Lambda – EFS Mount Injection via UpdateFunctionConfiguration (Data Theft)
 
+{{#include ../../../../banners/hacktricks-training.md}}
+
 Abuse `lambda:UpdateFunctionConfiguration` to attach an existing EFS Access Point to a Lambda, then deploy trivial code that lists/reads files from the mounted path to exfiltrate shared secrets/config that the function previously couldn’t access.
 
 ## Requirements
@@ -75,3 +77,4 @@ An attacker with the listed permissions can mount arbitrary in-VPC EFS Access Po
 ```
 aws lambda update-function-configuration --function-name $TARGET_FN --file-system-configs [] --region $REGION || true
 ```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-function-url-public-exposure.md

@@ -1,5 +1,7 @@
 # AWS - Lambda Function URL Public Exposure (AuthType NONE + Public Invoke Policy)
 
+{{#include ../../../../banners/hacktricks-training.md}}
+
 Turn a private Lambda Function URL into a public unauthenticated endpoint by switching the Function URL AuthType to NONE and attaching a resource-based policy that grants lambda:InvokeFunctionUrl to everyone. This enables anonymous invocation of internal functions and can expose sensitive backend operations.
 
 ## Abusing it
@@ -46,3 +48,4 @@ https://e3d4wrnzem45bhdq2mfm3qgde40rjjfc.lambda-url.us-east-1.on.aws/
 aws lambda remove-permission --function-name $TARGET_FN --statement-id ht-public-url || true
 aws lambda update-function-url-config --function-name $TARGET_FN --auth-type AWS_IAM || true
 ```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-runtime-pinning-abuse.md

@@ -1,5 +1,7 @@
 # AWS Lambda – Runtime Pinning/Rollback Abuse via PutRuntimeManagementConfig
 
+{{#include ../../../../banners/hacktricks-training.md}}
+
 Abuse `lambda:PutRuntimeManagementConfig` to pin a function to a specific runtime version (Manual) or freeze updates (FunctionUpdate). This preserves compatibility with malicious layers/wrappers and can keep the function on an outdated, vulnerable runtime to aid exploitation and long-term persistence.
 
 Requirements: `lambda:InvokeFunction`, `logs:FilterLogEvents`, `lambda:PutRuntimeManagementConfig`, `lambda:GetRuntimeManagementConfig`.
@@ -11,3 +13,4 @@ Example (us-east-1):
 
 Optionally pin to a specific runtime version by extracting the Runtime Version ARN from INIT_START logs and using `--update-runtime-on Manual --runtime-version-arn <arn>`.
 
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-vpc-egress-bypass.md

@@ -1,5 +1,7 @@
 # AWS Lambda – VPC Egress Bypass by Detaching VpcConfig
 
+{{#include ../../../../banners/hacktricks-training.md}}
+
 Force a Lambda function out of a restricted VPC by updating its configuration with an empty VpcConfig (SubnetIds=[], SecurityGroupIds=[]). The function will then run in the Lambda-managed networking plane, regaining outbound internet access and bypassing egress controls enforced by private VPC subnets without NAT.
 
 ## Abusing it
@@ -61,3 +63,4 @@ Force a Lambda function out of a restricted VPC by updating its configuration wi
 ### Cleanup
 - If you created any temporary code/handler changes, restore them.
 - Optionally restore the original VpcConfig saved in /tmp/orig-vpc.json as shown above.
+{{#include ../../../../banners/hacktricks-training.md}}

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

@@ -200,4 +200,5 @@ Abuse `sagemaker:PutRecord` on a Feature Group with OnlineStore enabled to overw
 
 {{#ref}}
 feature-store-poisoning.md
-{{/ref}}
+{{/ref}}
+{{#include ../../../../banners/hacktricks-training.md}}

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

@@ -1,5 +1,7 @@
 # SageMaker Feature Store online store poisoning
 
+{{#include ../../../../banners/hacktricks-training.md}}
+
 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.
 
 ## Requirements
@@ -51,3 +53,4 @@ Expected: risk_score returns 0.99 (attacker-set), proving ability to change onli
 ## Impact
 - Real-time integrity attack: manipulate features used by production models without touching endpoints/models.
 - Confidentiality risk: read sensitive features via GetRecord from OnlineStore.
+{{#include ../../../../banners/hacktricks-training.md}}

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

@@ -88,7 +88,7 @@ aws secretsmanager update-secret-version-stage \
   --remove-from-version-id <previous-version-id>
 ```
 
-{{#include ../../../../banners/hacktricks-training.md}}
+
 
 
 
@@ -141,3 +141,4 @@ aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
 Impact
 - Rapid “smash-and-grab” of many secrets with fewer API calls, potentially bypassing alerting tuned to spikes of GetSecretValue.
 - CloudTrail logs still include one GetSecretValue event per secret retrieved by the batch.
+{{#include ../../../../banners/hacktricks-training.md}}

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

@@ -1,5 +1,7 @@
 # AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
 
+{{#include ../../../banners/hacktricks-training.md}}
+
 ## Description
 
 Abuse SQS message move tasks to steal all accumulated messages from a victim's Dead-Letter Queue (DLQ) by redirecting them to an attacker-controlled queue using `sqs:StartMessageMoveTask`. This technique exploits AWS's legitimate message recovery feature to exfiltrate sensitive data that has accumulated in DLQs over time.
@@ -158,3 +160,4 @@ Monitor CloudTrail for suspicious `StartMessageMoveTask` API calls:
 4. **Encrypt DLQs**: Use SSE-KMS with restricted key policies
 5. **Regular Cleanup**: Don't let sensitive data accumulate in DLQs indefinitely
 
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md

@@ -4,7 +4,7 @@
 
 ## Description
 
-Abuse an SQS queue resource policy to allow an attacker-controlled SNS topic to publish messages into a victim SQS queue. In the same account, an SQS subscription to an SNS topic auto-confirms; in cross-account, you must read the SubscriptionConfirmation token from the queue and call ConfirmSubscription. This enables unsolicited message injection that downstream consumers may implicitly trust.
+Abuse an SQS queue resource policy to allow an attacker-controlled SNS topic to publish messages into a victim SQS queue. In the same account, an SQS subscription to an SNS topic auto-confirms; in cross-account, you must read the SubscriptionConfirmation token from the queue and call ConfirmSubscription. This enables unsolid message injection that downstream consumers may implicitly trust.
 
 ### Requirements
 - Ability to modify the target SQS queue resource policy: `sqs:SetQueueAttributes` on the victim queue.
@@ -51,6 +51,6 @@ aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-me
 - Subscriptions won’t auto-confirm. Grant yourself temporary `sqs:ReceiveMessage` on the victim queue to read the `SubscriptionConfirmation` message and then call `sns confirm-subscription` with its `Token`.
 
 ### Impact
-**Potential Impact**: Continuous unsolicited message injection into a trusted SQS queue via SNS, potentially triggering unintended processing, data pollution, or workflow abuse.
+**Potential Impact**: Continuous unsolid message injection into a trusted SQS queue via SNS, potentially triggering unintended processing, data pollution, or workflow abuse.
 
 {{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md

@@ -286,7 +286,7 @@ Assuming we find `aws_access_key_id` and `aws_secret_access_key`, we can use the
 
 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
 
-{{#include ../../../../banners/hacktricks-training.md}}
+
 
 
 
@@ -328,3 +328,4 @@ aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
 ```
 
 Potential Impact: Theft of instance profile credentials via SSRF leading to privilege escalation and lateral movement with the EC2 role permissions.
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md

@@ -105,7 +105,7 @@ aws ecr set-repository-policy \
     --policy-text file://my-policy.json
 ```
 
-{{#include ../../../../banners/hacktricks-training.md}}
+
 
 
 
@@ -281,3 +281,4 @@ aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V2 --region $RE
 
 </details>
 
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md

@@ -343,7 +343,7 @@ aws ecs update-service-primary-task-set --cluster existing-cluster --service exi
 
 - [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods)
 
-{{#include ../../../../banners/hacktricks-training.md}}
+
 
 
 
@@ -579,3 +579,4 @@ Commands (us-east-1):
 
 
 **Potential Impact:** Attacker-controlled EC2 nodes receive victim tasks, enabling OS-level access to containers and theft of task IAM role credentials.
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md

@@ -289,7 +289,7 @@ Some lambdas are going to be **receiving sensitive info from the users in parame
 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/)
 
-{{#include ../../../../banners/hacktricks-training.md}}
+
 
 
 
@@ -357,3 +357,4 @@ Cleanup:
 ```bash
 aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION || true
 ```
+{{#include ../../../../banners/hacktricks-training.md}}