gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 22:51:09 -07:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Translator
2026-02-14 19:50:14 +00:00
parent b424141d56
commit 02b5cf538f
1 changed files with 51 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
+51 -12
View File
@@ -12,30 +12,69 @@ Per maggiori informazioni consulta:
### Informazioni sensibili
Talvolta potrai trovare informazioni sensibili leggibili nei bucket. Per esempio, i segreti dello terraform state.
A volte potrai trovare informazioni sensibili leggibili nei bucket. Per esempio, terraform state secrets.
### Pivoting
Different platforms could be using S3 to store sensitive assets.\
For example, **airflow** could be storing **DAGs** **code** in there, or **web pages** could be directly served from S3. Un attaccante con permessi di scrittura potrebbe **modificare il code** presente nel bucket per **pivot** verso altre piattaforme, o **takeover accounts** modificando file JS.
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 poi questa **key accessibile a chiunque al mondo**, permettendo a qualsiasi user, role o account AWS di criptare oggetti usando questa key. Tuttavia, gli oggetti non possono essere decriptati.
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 identifica un bucket S3 target e ottiene accesso in scrittura su di esso usando vari metodi. Questo può avvenire a causa di una cattiva configurazione del bucket che lo espone pubblicamente o perché l'attaccante ha ottenuto accesso all'environment AWS stesso. Tipicamente l'attaccante prende di mira bucket che contengono informazioni sensibili come PII, PHI, logs, backup e altro.
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 è vulnerabile al 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 criptare con ransomware quel bucket specifico.
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'API AWS, 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.
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 concede al target una finestra di 7 giorni per recuperare i dati prima che la key venga eliminata e i dati vadano persi in modo permanente.
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 file. Questo file viene caricato senza cifratura, probabilmente per attirare l'attenzione del target e renderlo consapevole dell'attacco ransomware.
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 permette il recupero e l'exfiltration di dati storicamente archiviati (backup, snapshot, logs, 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.
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> \
@@ -47,7 +86,7 @@ aws s3api restore-object \
```
### `s3:Delete*`
Un attaccante con il permesso s3:Delete* può cancellare oggetti, versioni e interi bucket, interrompere i backup e causare perdita di dati immediata e irreversibile, distruzione di prove e compromissione degli artefatti di backup o di recovery.
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 \
@@ -64,6 +103,6 @@ aws s3api delete-object \
aws s3api delete-bucket \
--bucket <BUCKET_NAME>
```
**Per maggiori informazioni** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
**Per maggiori informazioni** [**consulta la ricerca originale**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
{{#include ../../../../banners/hacktricks-training.md}}