Translated ['src/pentesting-cloud/pentesting-cloud-methodology.md', 'src

src/pentesting-cloud/confidential-computing/luks2-header-malleability-null-cipher-abuse.md

@@ -0,0 +1,141 @@
+# LUKS2 Header Malleability and Null-Cipher Abuse in Confidential VMs
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## TL;DR
+
+- Viele Linux-basierte Confidential VMs (CVMs), die auf AMD SEV-SNP oder Intel TDX laufen, verwenden LUKS2 für persistenten Speicher. Der on-disk LUKS2-Header ist malleable und nicht gegen storage-adjacent Angreifer integritätsgeschützt.
+- Wenn die Verschlüsselung des Header-Datensegments auf einen null cipher gesetzt ist (z. B. "cipher_null-ecb"), akzeptiert cryptsetup das und der Guest liest/schreibt transparent Klartext, während er glaubt, die Festplatte sei verschlüsselt.
+- Bis einschließlich cryptsetup 2.8.0 konnten null ciphers für keyslots verwendet werden; seit 2.8.1 werden sie für keyslots mit nicht-leerem Passwort abgelehnt, aber null ciphers sind weiterhin für volume segments erlaubt.
+- Remote attestation misst üblicherweise VM-Code/Config, nicht veränderliche externe LUKS-Header; ohne explizite Validierung/Measurement kann ein Angreifer mit Schreibzugriff auf die Disk Klartext-I/O erzwingen.
+
+## Background: LUKS2 on-disk format (what matters for attackers)
+
+- Ein LUKS2-Device beginnt mit einem Header, gefolgt von verschlüsselten Daten.
+- Der Header enthält zwei identische Kopien eines binären Abschnitts und einen JSON-Metadatenabschnitt sowie einen oder mehrere keyslots.
+- Die JSON-Metadaten definieren:
+  - welche keyslots aktiviert sind und deren wrapping KDF/cipher
+  - segments, die den Datenbereich beschreiben (cipher/mode)
+  - digests (z. B. Hash des volume key zur Verifikation von Passphrasen)
+- Typische sichere Werte: keyslot KDF argon2id; keyslot- und data segment-Verschlüsselung aes-xts-plain64.
+
+Quickly inspect the segment cipher directly from JSON:
+```bash
+# Read JSON metadata and print the configured data segment cipher
+cryptsetup luksDump --type luks2 --dump-json-metadata /dev/VDISK \
+| jq -r '.segments["0"].encryption'
+```
+## Root cause
+
+- LUKS2-Header sind nicht gegen Manipulationen des Speichers authentifiziert. Ein Host-/Storage-Angreifer kann die von cryptsetup akzeptierten JSON-Metadaten umschreiben.
+- Seit cryptsetup 2.8.0 werden Header akzeptiert, die die Verschlüsselung eines Segments auf cipher_null-ecb setzen. Der null cipher ignoriert Schlüssel und liefert Klartext zurück.
+- Bis einschließlich 2.8.0 konnten null ciphers auch für keyslots verwendet werden (ein keyslot öffnet sich mit jeder Passphrase). Seit 2.8.1 werden null ciphers für keyslots mit nicht-leeren Passwörtern abgelehnt, bleiben aber für Segmente erlaubt. Allein das Ändern des Segment-Ciphers führt auch nach 2.8.1 weiterhin zu Klartext-I/O.
+
+## Threat model: why attestation didn’t save you by default
+
+- CVMs sollen Vertraulichkeit, Integrität und Authentizität in einem nicht vertrauenswürdigen Host sicherstellen.
+- Remote attestation misst üblicherweise das VM-Image und die Launch-Konfiguration, nicht den veränderlichen LUKS-Header, der auf nicht vertrauenswürdigem Speicher liegt.
+- Wenn deine CVM einem on-disk Header ohne robuste Validierung/attestation vertraut, kann ein Storage-Angreifer ihn auf einen null cipher ändern und dein Guest wird ein Klartext-Volume ohne Fehler mounten.
+
+## Exploitation (storage write access required)
+
+Preconditions:
+- Schreibzugriff auf das LUKS2-verschlüsselte Blockgerät der CVM.
+- Der Guest verwendet den on-disk LUKS2-Header ohne robuste Validierung/attestation.
+
+Steps (high level):
+1) Lese das Header-JSON und identifiziere die Definition des Datensegments. Beispielziel-Feld: segments["0"].encryption.
+2) Setze die Verschlüsselung des Datensegments auf einen null cipher, z.B. cipher_null-ecb. Belasse keyslot-Parameter und Digest-Struktur unverändert, sodass die übliche Passphrase des Guests weiterhin „funktioniert“.
+3) Aktualisiere beide Header-Kopien und die zugehörigen Header-Digests, sodass der Header selbstkonsistent ist.
+4) Beim nächsten Boot führt der Guest cryptsetup aus, entsperrt erfolgreich den vorhandenen keyslot mit seiner Passphrase und mountet das Volume. Da der Segment-Cipher ein null cipher ist, sind alle Lese-/Schreibvorgänge Klartext.
+
+Variant (pre-2.8.1 keyslot abuse): wenn area.encryption eines keyslots ein null cipher ist, öffnet er sich mit jeder Passphrase. Kombiniere das mit einem null segment cipher für nahtlosen Klartext-Zugriff, ohne das Guest-Secret zu kennen.
+
+## Robust mitigations (avoid TOCTOU with detached headers)
+
+Behandle on-disk LUKS-Header stets als nicht vertrauenswürdige Eingabe. Verwende detached-header mode, damit Validierung und Öffnen dieselben vertrauenswürdigen Bytes aus geschütztem RAM verwenden:
+```bash
+# Copy header into protected memory (e.g., tmpfs) and open from there
+cryptsetup luksHeaderBackup --header-backup-file /tmp/luks_header /dev/VDISK
+cryptsetup open --type luks2 --header /tmp/luks_header /dev/VDISK --key-file=key.txt
+```
+Dann erzwinge eine (oder mehrere) der folgenden Maßnahmen:
+
+1) Den gesamten Header mit einem MAC sichern
+- Berechne/verifiziere vor der Verwendung einen MAC über den gesamten Header.
+- Öffne das Volume nur, wenn der MAC verifiziert ist.
+- Beispiele in der Praxis: Flashbots tdx-init und Fortanix Salmiac nutzen MAC-basierte Verifikation.
+
+2) Strikte JSON-Validierung (abwärtskompatibel)
+- Dump JSON-Metadaten und validiere eine strikte allowlist von Parametern (KDF, ciphers, segment count/type, flags).
+```bash
+#!/bin/bash
+set -e
+# Store header in confidential RAM fs
+cryptsetup luksHeaderBackup --header-backup-file /tmp/luks_header $BLOCK_DEVICE
+# Dump JSON metadata header to a file
+cryptsetup luksDump --type luks2 --dump-json-metadata /tmp/luks_header > header.json
+# Validate the header
+python validate.py header.json
+# Open the cryptfs using key.txt
+cryptsetup open --type luks2 --header /tmp/luks_header $BLOCK_DEVICE --key-file=key.txt
+```
+<details>
+<summary>Beispiel-Validator (sichere Felder erzwingen)</summary>
+```python
+from json import load
+import sys
+with open(sys.argv[1], "r") as f:
+header = load(f)
+if len(header["keyslots"]) != 1:
+raise ValueError("Expected 1 keyslot")
+if header["keyslots"]["0"]["type"] != "luks2":
+raise ValueError("Expected luks2 keyslot")
+if header["keyslots"]["0"]["area"]["encryption"] != "aes-xts-plain64":
+raise ValueError("Expected aes-xts-plain64 encryption")
+if header["keyslots"]["0"]["kdf"]["type"] != "argon2id":
+raise ValueError("Expected argon2id kdf")
+if len(header["tokens"]) != 0:
+raise ValueError("Expected 0 tokens")
+if len(header["segments"]) != 1:
+raise ValueError("Expected 1 segment")
+if header["segments"]["0"]["type"] != "crypt":
+raise ValueError("Expected crypt segment")
+if header["segments"]["0"]["encryption"] != "aes-xts-plain64":
+raise ValueError("Expected aes-xts-plain64 encryption")
+if "flags" in header["segments"]["0"] and header["segments"]["0"]["flags"]:
+raise ValueError("Segment contains unexpected flags")
+```
+</details>
+
+3) Header messen/attestieren
+- Entferne zufällige Salts/Digests und messe den bereinigten Header in TPM/TDX/SEV PCRs oder KMS policy state.
+- Gib Entschlüsselungskeys nur frei, wenn der gemessene Header einem genehmigten, sicheren Profil entspricht.
+
+Operational guidance:
+- Enforce detached header + MAC oder strenge Validierung; vertraue niemals direkt auf on-disk Header.
+- Empfänger von Attestierungen sollten pre-patch Framework-Versionen in allow-lists ablehnen.
+
+## Hinweise zu Versionen und Position der Maintainer
+
+- Die Maintainer von cryptsetup haben klargestellt, dass LUKS2 nicht dafür ausgelegt ist, Integrität gegen Manipulationen des Speichers in diesem Kontext bereitzustellen; null ciphers werden zur Abwärtskompatibilität beibehalten.
+- cryptsetup 2.8.1 (Oct 19, 2025) lehnt null ciphers für keyslots mit nicht-leeren Passwörtern ab, erlaubt aber weiterhin null ciphers für segments.
+
+## Schnelle Checks und Triage
+
+- Prüfe, ob die Segmentverschlüsselung auf einen null cipher gesetzt ist:
+```bash
+cryptsetup luksDump --type luks2 --dump-json-metadata /dev/VDISK \
+| jq -r '.segments | to_entries[] | "segment=" + .key + ", enc=" + .value.encryption'
+```
+- Überprüfen Sie keyslot- und Segment-Algorithmen, bevor Sie das Volume öffnen. Wenn Sie MAC nicht durchführen können, erzwingen Sie eine strikte JSON-Validierung und öffnen Sie das Volume mit dem getrennten Header aus dem geschützten Speicher.
+
+## Referenzen
+
+- [Vulnerabilities in LUKS2 disk encryption for confidential VMs (Trail of Bits)](https://blog.trailofbits.com/2025/10/30/vulnerabilities-in-luks2-disk-encryption-for-confidential-vms/)
+- [cryptsetup issue #954 (null cipher acceptance and integrity considerations)](https://gitlab.com/cryptsetup/cryptsetup/-/issues/954)
+- [CVE-2025-59054](https://nvd.nist.gov/vuln/detail/CVE-2025-59054)
+- [CVE-2025-58356](https://nvd.nist.gov/vuln/detail/CVE-2025-58356)
+- [Related context: CVE-2021-4122 (auto-recovery path silently decrypting disks)](https://www.cve.org/CVERecord?id=CVE-2021-4122)
+
+{{#include ../../banners/hacktricks-training.md}}

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

@@ -1,4 +1,4 @@
-# Pentesting Cloud Methodik
+# Pentesting Cloud Methodologie
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,31 +6,31 @@
 
 ## Grundlegende Methodik
 
-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:
+Jede Cloud hat ihre eigenen Besonderheiten, aber im Allgemeinen gibt es ein paar **gemeinsame Dinge, die ein pentester prüfen sollte**, wenn er eine Cloud-Umgebung testet:
 
 - **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.
+- Dies hilft dir, die Größe der Umgebung und die genutzten Services zu verstehen
+- Es ermöglicht dir außerdem, einige schnelle Fehlkonfigurationen zu finden, da du die meisten dieser Tests mit automatisierten Tools durchführen kannst
 - **Services Enumeration**
-- 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.
+- Wenn du die Benchmark-Tests korrekt durchgeführt hast, wirst du hier wahrscheinlich nicht viele zusätzliche Fehlkonfigurationen finden, aber möglicherweise solche, die im Benchmark-Test nicht explizit gesucht wurden.
+- Dies ermöglicht dir, genau zu wissen, was in der Cloud-Umgebung verwendet wird
+- Das hilft enorm für die nächsten Schritte
 - **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?)
+- Dies kann während des vorherigen Abschnitts erfolgen; du musst alles finden, was potenziell irgendwie dem Internet ausgesetzt ist und wie darauf zugegriffen werden kann.
+- Hier beziehe ich mich auf manuell exponierte Infrastruktur wie instances mit Webseiten oder anderen offenen Ports und auch auf andere cloud-managed Services, die so konfiguriert werden können, dass sie exponiert sind (z. B. DBs oder buckets)
+- Danach solltest du prüfen, ob diese Ressource exponiert werden kann oder nicht (vertrauliche Informationen? vulnerabilities? 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.
+- Hier solltest du alle Berechtigungen jedes Roles/Users innerhalb der Cloud ermitteln und wie sie verwendet werden
+- Zu viele hoch privilegierte (kontrollieren alles) Konten? Generierte Keys, die nicht verwendet werden?... Die meisten dieser Checks sollten bereits in 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 darüber bitten, wie jede Rolle zugewiesen wird (es ist nicht dasselbe, ob die Admin-Rolle 1 User oder 100 Usern zugewiesen ist)
+- Es reicht nicht aus herauszufinden, welche Nutzer Admin-Berechtigungen "\*:\*" haben. Es gibt viele andere Berechtigungen, die je nach genutzten Services sehr sensibel sein können.
+- Darüber hinaus gibt es potenzielle privesc-Wege, die man durch Missbrauch von Berechtigungen verfolgen kann. All diese Dinge sollten berücksichtigt werden und möglichst viele privesc-Pfade sollten gemeldet werden.
 - **Check Integrations**
-- Es ist sehr wahrscheinlich, dass **Integrationen mit anderen Clouds oder SaaS** innerhalb der Cloud-Umgebung verwendet werden.
-- 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.
+- Sehr wahrscheinlich werden Integrationen mit anderen Clouds oder SaaS innerhalb der Cloud-Umgebung verwendet.
+- Für Integrationen der Cloud, die du auditierst, mit anderen Plattformen solltest du benachrichtigen, wer Zugang hat, diese Integration (ab)zunutzen, und du solltest fragen, wie sensibel die durchgeführte Aktion ist.\
+Zum Beispiel: Wer kann in einen AWS bucket schreiben, aus dem GCP Daten bezieht (frage, wie sensibel die Aktion in GCP im Umgang mit diesen Daten ist).
+- Für Integrationen innerhalb der Cloud, die du auditierst, aus externen Plattformen heraus, solltest du fragen, wer externen Zugang hat, diese Integration (ab)zunutzen, 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 Image zu modifizieren und welche sensitiven Informationen und Zugriffe dieses Image beim Ausführen innerhalb einer AWS-Cloud erhalten würde.
 
 ## 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 privesc-Pfade in Clouds und zwischen Clouds/SaaS zu identifizieren.**
+A tool to **identify bad configurations and privesc path in clouds and across clouds/SaaS.**
 
 {{#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**. Anleitungen zur Konfiguration der einzelnen Provider findest du unter [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
+Unterstützt **AWS, GCP & Azure**. Prüfe, wie du jeden Anbieter in [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) konfigurierst.
 ```bash
 # Install
 pip install prowler
@@ -170,7 +170,7 @@ steampipe check all
 
 <summary>Alle Projekte prüfen</summary>
 
-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
+Um alle Projekte zu prü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.
 ```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 **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 **andere GCP-Einblicke** zu prüfen (nützlich zum Aufzählen von Diensten), 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)
 
-Weitere GCP-Plugins für Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
+Weitere GCP-Plugins von Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
 {{#endtab }}
 
 {{#tab name="AWS" }}
@@ -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)
+Zum Prüfen von Terraform AWS-Code: [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 }}
@@ -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 benötigt python2.7 und scheint nicht mehr gepflegt zu sein.
+Benötigt python2.7 und scheint nicht mehr gewartet zu werden.
 
 ### Nessus
 
-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.
+Nessus bietet 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 Erfassen von Assets** (Hostnamen, IP-Adressen) von Cloud-Anbietern.
+Cloudlist ist ein **Multi-Cloud-Tool zum Ermitteln von Assets** (Hostnames, IP-Adressen) von Cloud-Providern.
 
 {{#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 Infrastrukturressourcen und die Beziehungen zwischen ihnen in einer intuitiven Graph-Ansicht konsolidiert, die von einer Neo4j-Datenbank betrieben wird.
+Cartography ist ein Python-Tool, das Infrastruktur-Assets und die Beziehungen zwischen ihnen in einer intuitiven Graph-Ansicht konsolidiert, die von einer Neo4j-Datenbank angetrieben 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, in einer intuitiven Graph-Ansicht, die von der Neo4j-Datenbank unterstützt wird.
+Starbase sammelt assets und relationships von Diensten und Systemen, einschließlich Cloud-Infrastruktur, SaaS-Anwendungen, Sicherheitskontrollen und mehr, und stellt diese in einer intuitiven Graph-Ansicht 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)
 
-Ermittelt die am höchsten privilegierten Benutzer in der gescannten AWS- oder Azure-Umgebung, einschließlich der AWS Shadow Admins. Es verwendet powershell.
+Entdeckt 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,12 +372,12 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-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.
+Ein Tool, um die Infrastruktur, Dateien und Apps eines Unternehmens (Ziels) bei den großen Cloud-Anbietern (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode) zu finden.
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- 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.
+- CloudFox ist ein Tool, um ausnutzbare Angriffswege in Cloud-Infrastrukturen zu finden (derzeit werden nur AWS & Azure unterstützt, GCP folgt demnächst).
+- Es ist ein Enumeration-Tool, das manuelles pentesting ergänzen soll.
 - Es erstellt oder verändert keine Daten innerhalb der Cloud-Umgebung.
 
 ### More lists of cloud security tools
@@ -410,13 +410,12 @@ aws-security/
 azure-security/
 {{#endref}}
 
-### Attack Graph
+## Allgemeine Cloud-Sicherheitsfunktionen
 
-[**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
-
-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.
+### Confidential Computing
 
+{{#ref}}
+confidential-computing/luks2-header-malleability-null-cipher-abuse.md
+{{#endref}}
 
 {{#include ../banners/hacktricks-training.md}}