# AWS - S3 Post Exploitation

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

## S3

Per maggiori informazioni consulta:

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

### Informazioni sensibili

A volte potrai trovare informazioni sensibili leggibili nei bucket. Per esempio, terraform state secrets.

### Pivoting

Diverse piattaforme possono usare S3 per memorizzare asset sensibili.\
Per esempio, **airflow** potrebbe memorizzare lì il **DAGs code**, oppure **web pages** potrebbero essere servite direttamente da S3. Un attaccante con permessi di scrittura potrebbe **modify the code** dal bucket per **pivot** verso altre piattaforme, o **takeover accounts** modificando file JS.

### S3 Ransomware

In questo scenario, l'**attaccante crea una KMS (Key Management Service) key nel proprio account AWS** o in un altro account compromesso. Rende quindi questa **key accessibile a chiunque nel mondo**, permettendo a qualsiasi utente, ruolo o account AWS di cifrare oggetti usando questa key. Tuttavia, gli oggetti non possono essere decifrati.

L'attaccante individua un target **S3 bucket e ottiene accesso in scrittura** su di esso usando vari metodi. Questo può essere dovuto a una cattiva configurazione del bucket che lo espone pubblicamente o all'attaccante che guadagna accesso all'ambiente AWS stesso. Tipicamente l'attaccante prende di mira bucket che contengono informazioni sensibili come PII, PHI, log, backup e altro.

Per determinare se il bucket può essere preso di mira per ransomware, l'attaccante verifica la sua configurazione. Questo include controllare se **S3 Object Versioning** è abilitato e se **multi-factor authentication delete (MFA delete)** è abilitato. Se Object Versioning non è abilitato, l'attaccante può procedere. Se Object Versioning è abilitato ma MFA delete è disabilitato, l'attaccante può **disabilitare Object Versioning**. Se sia Object Versioning che MFA delete sono abilitati, diventa più difficile per l'attaccante ransomware quel specifico bucket.

Usando l'AWS API, l'attaccante **sostituisce ogni oggetto nel bucket con una copia cifrata usando la propria KMS key**. Questo cifra effettivamente i dati nel bucket, rendendoli inaccessibili senza la key.

Per aumentare la pressione, l'attaccante programma la cancellazione della KMS key usata nell'attacco. Questo dà al target una finestra di 7 giorni per recuperare i dati prima che la key venga cancellata e i dati vadano perduti in modo permanente.

Infine, l'attaccante potrebbe caricare un file finale, solitamente chiamato "ransom-note.txt", che contiene istruzioni per il target su come recuperare i propri file. Questo file viene caricato senza cifratura, probabilmente per attirare l'attenzione del target e renderlo consapevole dell'attacco ransomware.

#### SSE-C (Customer-Provided Key) Ransomware (Codefinger-like)

Un'altra variante è l'abuso di **SSE-C** (S3 server-side encryption with **customer-provided keys**). Con SSE-C, il **client fornisce la chiave di cifratura ad ogni richiesta** e **AWS non memorizza la chiave**. Questo significa che se un attaccante riscrive oggetti usando **la propria SSE-C key**, i dati della vittima diventano illeggibili a meno che la vittima non possa fornire quella chiave controllata dall'attaccante.

- **Precondizioni:** Credenziali AWS compromesse (o qualsiasi principal con i permessi corretti) e la capacità di **rewrite objects** (es., `s3:PutObject` sulle chiavi/prefissi target). Questo è spesso abbinato alla capacità di impostare lifecycle policies distruttive (vedi sotto), es. `s3:PutLifecycleConfiguration`.
- **Catena di attacco:**
1. L'attaccante genera una chiave casuale a 256-bit (AES-256) e la conserva.
2. L'attaccante **riscrive** gli oggetti esistenti (stesse object keys) usando header SSE-C in modo che l'oggetto memorizzato sia ora cifrato con la key dell'attaccante.
3. La vittima non può scaricare/decifrare senza fornire la SSE-C key (anche se i permessi IAM sono a posto).
4. L'attaccante può cancellare la key (o semplicemente non fornirla mai) per rendere i dati irrimediabili.

Esempio (concettuale) di utilizzo CLI:
```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>
```
##### Aumentare la pressione: abuso del "timer" del ciclo di vita

Per rimuovere opzioni di ripristino (come versioni precedenti), gli attaccanti possono abbinare riscritture SSE-C con **regole del ciclo di vita** che fanno scadere gli oggetti e/o cancellano le versioni non correnti dopo un breve periodo:

- `s3:PutLifecycleConfiguration` sul bucket permette a un attaccante di pianificare cancellazioni senza eseguire operazioni di delete esplicite per ogni oggetto/versione.
- Questo è particolarmente impattante quando **versioning è abilitato**, perché può rimuovere la "versione precedente valida" che altrimenti permetterebbe il ripristino.

##### Rilevamento & Mitigazioni

- Preferire **SSE-KMS** (o SSE-S3) rispetto a SSE-C a meno che non ci sia una forte esigenza operativa per consentire SSE-C.
- Monitorare/allertare le richieste `PutObject` che usano header SSE-C (CloudTrail data events per S3).
- Monitorare/allertare su `PutBucketLifecycleConfiguration` inaspettati (modifiche al lifecycle).
- Monitorare/allertare su picchi improvvisi nell'attività di overwrite (stesse chiavi aggiornate rapidamente) e su delete-marker/cancellazioni di versioni.
- Restringere i permessi ad alto rischio: limitare `s3:PutObject` ai prefissi necessari; restringere fortemente `s3:PutLifecycleConfiguration` e `s3:PutBucketVersioning`; considerare di richiedere MFA per azioni amministrative sensibili (quando applicabile) e usare ruoli amministrativi separati con approvazioni.
- Approccio al recupero: usare **versioning**, **backup** e copie immutabili/offline (S3 replication verso account protetto, vault di backup, ecc.); proteggere le versioni non correnti dalle cancellazioni aggressive e tutelare le modifiche al lifecycle con SCPs / guardrails.

### `s3:RestoreObject`

Un attaccante con il permesso `s3:RestoreObject` può riattivare oggetti archiviati in Glacier o Deep Archive, rendendoli temporaneamente accessibili. Questo abilita il ripristino e l'exfiltration di dati storicamente archiviati (backup, snapshot, log, certificazioni, vecchi segreti) che normalmente sarebbero fuori portata. Se l'attaccante combina questo permesso con permessi di lettura (es. `s3:GetObject`), può ottenere copie complete di dati sensibili.
```bash
aws s3api restore-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY> \
--restore-request '{
"Days": <NUMBER_OF_DAYS>,
"GlacierJobParameters": { "Tier": "Standard" }
}'
```
### `s3:Delete*`

Un attacker con il permesso s3:Delete* può eliminare oggetti, versioni e interi bucket, interrompere i backup e causare perdita di dati immediata e irreversibile, distruzione di prove e compromissione di backup o recovery artifacts.
```bash
# Delete an object from a bucket
aws s3api delete-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY>

# Delete a specific version
aws s3api delete-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY> \
--version-id <VERSION_ID>

# Delete a bucket
aws s3api delete-bucket \
--bucket <BUCKET_NAME>
```
**Per maggiori informazioni** [**consulta la ricerca originale**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**

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