f

Author: carlospolop

.github/workflows/translate_all.yml

@@ -262,9 +262,6 @@ jobs:
           git rev-parse --abbrev-ref HEAD
           echo "Syncing $BRANCH to S3"
           aws s3 sync ./book s3://hacktricks-cloud/$BRANCH --delete
-          echo "Uploading root ads.txt"
-          aws s3 cp ./ads.txt s3://hacktricks-cloud/ads.txt --content-type text/plain --cache-control max-age=300
-          aws s3 cp ./ads.txt s3://hacktricks-cloud/en/ads.txt --content-type text/plain --cache-control max-age=300
           echo "Sync completed"
           echo "Cat 3 files from the book"
           find . -type f -name 'index.html' -print | head -n 3 | xargs -r cat

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

@@ -33,6 +33,47 @@ To add further pressure, the attacker schedules the deletion of the KMS key used
 
 Finally, the attacker could upload a final file, usually named "ransom-note.txt," which contains instructions for the target on how to retrieve their files. This file is uploaded without encryption, likely to catch the target's attention and make them aware of the ransomware attack.
 
+#### SSE-C (Customer-Provided Key) Ransomware (Codefinger-like)
+
+Another variant is abusing **SSE-C** (S3 server-side encryption with **customer-provided keys**). With SSE-C, the **client provides the encryption key on every request** and **AWS does not store the key**. This means that if an attacker rewrites objects using **their own SSE-C key**, the victim's data becomes unreadable unless the victim can provide that attacker-controlled key.
+
+- **Preconditions:** Compromised AWS credentials (or any principal with the right permissions) and the ability to **rewrite objects** (e.g., `s3:PutObject` on the target keys/prefixes). This is often paired with the ability to set destructive lifecycle policies (see below), e.g. `s3:PutLifecycleConfiguration`.
+- **Attack chain:**
+  1. Attacker generates a random 256-bit key (AES-256) and keeps it.
+  2. Attacker **rewrites** existing objects (same object keys) using SSE-C headers so the stored object is now encrypted with the attacker key.
+  3. Victim cannot download/decrypt without providing the SSE-C key (even if IAM permissions are fine).
+  4. Attacker can delete the key (or simply never provide it) to make data unrecoverable.
+
+Example (conceptual) CLI usage:
+
+```bash
+# Upload/overwrite an object encrypted with attacker-provided SSE-C key
+aws s3 cp ./file s3://<BUCKET>/<KEY> \
+  --sse-c AES256 \
+  --sse-c-key <BASE64_32_BYTES>
+
+# Download requires providing the same key again
+aws s3 cp s3://<BUCKET>/<KEY> ./file \
+  --sse-c AES256 \
+  --sse-c-key <BASE64_32_BYTES>
+```
+
+##### Adding Pressure: Lifecycle "Timer" Abuse
+
+To remove recovery options (like old versions), attackers can pair SSE-C rewrites with **lifecycle rules** that expire objects and/or delete noncurrent versions after a short period:
+
+- `s3:PutLifecycleConfiguration` on the bucket lets an attacker schedule deletions without issuing explicit delete operations for every object/version.
+- This is especially impactful when **versioning is enabled**, because it can remove the "previous good version" that would otherwise allow recovery.
+
+##### Detection & Mitigations
+
+- Prefer **SSE-KMS** (or SSE-S3) over SSE-C unless you have a strong operational reason to allow SSE-C.
+- Monitor/alert on `PutObject` requests using SSE-C headers (CloudTrail data events for S3).
+- Monitor/alert on unexpected `PutBucketLifecycleConfiguration` (lifecycle changes).
+- Monitor/alert on sudden spikes in overwrite activity (same keys updated rapidly) and delete-marker/version deletions.
+- Restrict high-risk permissions: Limit `s3:PutObject` to necessary prefixes; strongly restrict `s3:PutLifecycleConfiguration` and `s3:PutBucketVersioning`; consider requiring MFA for sensitive admin actions (where applicable) and use separate admin roles with approvals.
+- Recovery posture: Use **versioning**, **backups**, and immutable/offline copies (S3 replication to protected account, backup vaults, etc.); protect noncurrent versions from aggressive deletion and guard lifecycle changes with SCPs / guardrails.
+
 ### `s3:RestoreObject`
 
 An attacker with the s3:RestoreObject permission can reactivate objects archived in Glacier or Deep Archive, making them temporarily accessible. This enables recovery and exfiltration of historically archived data (backups, snapshots, logs, certifications, old secrets) that would normally be out of reach. If the attacker combines this permission with read permissions (e.g., s3:GetObject), they can obtain full copies of sensitive data.
@@ -74,6 +115,3 @@ aws s3api delete-bucket \
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-
-
-