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 @@
+# Modyfikowalność nagłówka LUKS2 i nadużycie null-cipher w Confidential VMs
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## W skrócie
+
+- Wiele opartych na Linux Confidential VMs (CVMs) działających na AMD SEV-SNP lub Intel TDX używa LUKS2 do przechowywania trwałego. Nagłówek LUKS2 znajdujący się na dysku jest modyfikowalny i nie jest chroniony integralnością względem atakujących mających dostęp do warstwy pamięci.
+- Jeśli szyfrowanie segmentu danych w nagłówku ustawione jest na null cipher (np. "cipher_null-ecb"), cryptsetup to zaakceptuje i gość przezroczysto będzie czytał/zapisywał plaintext, wierząc, że dysk jest zaszyfrowany.
+- Do i włącznie z cryptsetup 2.8.0 null ciphers mogły być używane dla keyslots; od 2.8.1 są odrzucane dla keyslots z niepustymi hasłami, ale null ciphers nadal są dozwolone dla segmentów wolumenu.
+- Remote attestation zwykle mierzy kod/konfigurację VM, a nie zewnętrzne, modyfikowalne nagłówki LUKS; bez jawnej walidacji/pomiaru atakujący z możliwością zapisu na dysku może wymusić I/O w postaci plaintextu.
+
+## Tło: format LUKS2 na dysku (co ma znaczenie dla atakujących)
+
+- Urządzenie LUKS2 zaczyna się od nagłówka, po którym następują zaszyfrowane dane.
+- Nagłówek zawiera dwie identyczne kopie sekcji binarnej i sekcję metadanych JSON, oraz jeden lub więcej keyslots.
+- Metadane JSON definiują:
+  - włączone keyslots oraz ich wrapping KDF/cipher
+  - segmenty opisujące obszar danych (cipher/mode)
+  - digests (np. hash klucza wolumenu do weryfikacji haseł)
+- Typowe bezpieczne wartości: keyslot KDF argon2id; szyfrowanie keyslot i segmentu danych aes-xts-plain64.
+
+Szybko sprawdź szyfr segmentu bezpośrednio w 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'
+```
+## Przyczyna źródłowa
+
+- LUKS2 headers nie są uwierzytelniane pod kątem manipulacji na storage. Atakujący z poziomu hosta/storage może przepisać JSON metadata akceptowany przez cryptsetup.
+- Od cryptsetup 2.8.0 akceptowane są nagłówki, które ustawiają szyfrowanie segmentu na cipher_null-ecb. Null cipher ignoruje klucze i zwraca plaintext.
+- Do wersji 2.8.0 null ciphers mogły być też używane dla keyslots (keyslot otwiera się przy dowolnym passphrase). Od 2.8.1 null ciphers są odrzucane dla keyslots z niepustymi hasłami, ale pozostają dozwolone dla segments. Zmiana tylko ciphera segmentu nadal skutkuje plaintext I/O po 2.8.1.
+
+## Model zagrożeń: dlaczego attestation domyślnie cię nie uratowało
+
+- CVMs mają na celu zapewnienie confidentiality, integrity i authenticity w nieufnym hoście.
+- Remote attestation zwykle mierzy obraz VM i konfigurację uruchomienia, a nie mutowalny LUKS header znajdujący się na nieufnym storage.
+- Jeśli twój CVM ufa nagłówkowi na dysku bez solidnej walidacji/measurement, atakujący na storage może go zmodyfikować na null cipher, a twój gość zamontuje wolumin w plaintext bez błędu.
+
+## Eksploatacja (wymagany dostęp zapisu do storage)
+
+Warunki wstępne:
+- Dostęp zapisu do LUKS2-szyfrowanego urządzenia blokowego CVM.
+- Gość używa on-disk LUKS header bez solidnej walidacji/attestation.
+
+Kroki (ogólnie):
+1) Odczytaj header JSON i zidentyfikuj definicję segmentu danych. Przykładowe pole docelowe: segments["0"].encryption.
+2) Ustaw szyfrowanie segmentu danych na null cipher, np. cipher_null-ecb. Zachowaj parametry keyslot i strukturę digest tak, aby zwykły passphrase gościa nadal „działał.”
+3) Zaktualizuj obie kopie headera i powiązane header digesty, aby header był samospójny.
+4) Przy następnym uruchomieniu gość uruchomi cryptsetup, pomyślnie odblokuje istniejący keyslot swoim passphrase i zamontuje wolumin. Ponieważ cipher segmentu to null cipher, wszystkie odczyty/zapisy będą plaintext.
+
+Wariant (nadużycie keyslot przed 2.8.1): jeśli area.encryption keyslota jest null cipher, otwiera się on przy dowolnym passphrase. Połącz to z null segment cipher, aby uzyskać bezproblemowy dostęp w plaintext bez znajomości sekretu gościa.
+
+## Skuteczne środki zaradcze (unikaj TOCTOU przy detached headers)
+
+Zawsze traktuj nagłówki LUKS zapisane na dysku jako nieufne dane wejściowe. Użyj trybu detached-header, aby walidacja i otwarcie korzystały z tych samych zaufanych bajtów z chronionej pamięci RAM:
+```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
+```
+Wymuś jedno (lub więcej) z poniższych:
+
+1) MAC całego nagłówka
+- Oblicz/zweryfikuj MAC dla całego nagłówka przed użyciem.
+- Otwieraj wolumin tylko wtedy, gdy MAC zostanie zweryfikowany.
+- Przykłady w praktyce: Flashbots tdx-init i Fortanix Salmiac zastosowały weryfikację opartą na MAC.
+
+2) Ścisła walidacja JSON (wstecznie kompatybilna)
+- Zrzucaj metadane JSON i waliduj ścisłą listę dozwolonych parametrów (KDF, ciphers, liczba/typ segmentów, flagi).
+```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>Przykładowy walidator (wymusza bezpieczne pola)</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) Zmierz/atestuj nagłówek
+- Usuń losowe salts/digests i zmierz oczyszczony nagłówek do TPM/TDX/SEV PCRs lub stanu polityki KMS.
+- Wydawaj klucze odszyfrowania tylko wtedy, gdy zmierzony nagłówek pasuje do zatwierdzonego, bezpiecznego profilu.
+
+Wytyczne operacyjne:
+- Wymuszaj detached header + MAC lub ścisłą walidację; nigdy nie ufaj bezpośrednio nagłówkom na dysku.
+- Konsumenci atestacji powinni odrzucać pre-patch wersje frameworków w allow-lists.
+
+## Notatki o wersjach i stanowisku maintainerów
+
+- maintainerzy cryptsetup wyjaśnili, że LUKS2 nie został zaprojektowany, aby zapewniać integralność przeciwko manipulacji pamięcią masową w tym kontekście; null ciphers są zachowane dla kompatybilności wstecznej.
+- cryptsetup 2.8.1 (Oct 19, 2025) odrzuca null ciphers dla keyslots z niepustymi hasłami, ale nadal pozwala null ciphers dla segments.
+
+## Szybkie kontrole i triage
+
+- Sprawdź, czy segment encryption jest ustawione na null cipher:
+```bash
+cryptsetup luksDump --type luks2 --dump-json-metadata /dev/VDISK \
+| jq -r '.segments | to_entries[] | "segment=" + .key + ", enc=" + .value.encryption'
+```
+- Zweryfikuj algorytmy keyslot i segment przed otwarciem wolumenu. Jeśli nie możesz zweryfikować MAC, wymuś ścisłą walidację JSON i otwórz, używając detached header znajdującego się w protected memory.
+
+## Źródła
+
+- [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 @@
-# Metodologia Pentesting Cloud
+# Pentesting Cloud Methodology
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,39 +6,39 @@
 
 ## Podstawowa metodologia
 
-Każda chmura ma swoje specyfiki, ale ogólnie istnieje kilka **wspólnych rzeczy, które pentester powinien sprawdzić** podczas testów środowiska chmurowego:
+Każda chmura ma swoje specyfiki, ale ogólnie istnieje kilka **wspólnych rzeczy, które pentester powinien sprawdzić** podczas testowania środowiska cloud:
 
-- **Testy benchmarkowe**
-- To pomoże Ci **zrozumieć rozmiar** środowiska i **używane usługi**
-- Pozwoli także znaleźć kilka **szybkich błędów konfiguracyjnych**, ponieważ większość tych testów możesz wykonać przy pomocy **narzędzi automatycznych**
-- **Enumeracja usług**
-- Prawdopodobnie nie znajdziesz tu znacznie więcej błędów konfiguracyjnych jeśli poprawnie wykonałeś testy benchmarkowe, ale możesz znaleźć takie, które nie były brane pod uwagę w testach benchmarkowych.
-- To pozwoli Ci wiedzieć **co dokładnie jest używane** w środowisku chmurowym
+- **Kontrole benchmarkowe**
+- To pomoże ci **zrozumieć rozmiar** środowiska i **używane usługi**
+- Pozwoli też znaleźć kilka **szybkich błędów konfiguracyjnych**, ponieważ większość tych testów można przeprowadzić przy pomocy **narzędzi automatycznych**
+- **Services Enumeration**
+- Prawdopodobnie nie znajdziesz tu znacznie więcej błędów konfiguracyjnych, jeśli poprawnie przeprowadziłeś testy benchmarkowe, ale możesz trafić na takie, których nie wyszukiwano podczas testów benchmarkowych.
+- To pozwoli ci wiedzieć **co dokładnie jest używane** w środowisku cloud
 - To bardzo pomoże w kolejnych krokach
-- **Sprawdź zasoby wystawione**
-- Można to zrobić podczas poprzedniej sekcji, musisz **odnaleźć wszystko, co potencjalnie jest wystawione** do Internetu w jakiś sposób i jak można to uzyskać.
-- Mam tu na myśli **ręcznie wystawioną infrastrukturę** jak instancje z stronami WWW lub innymi wystawionymi portami, oraz także **zarządzane usługi chmurowe, które mogą być skonfigurowane** jako wystawione (np. DBs lub buckets)
-- Następnie powinieneś sprawdzić **czy dany zasób może ujawniać informacje czy nie** (informacje poufne? podatności? błędy konfiguracyjne w wystawionej usłudze?)
+- **Sprawdź zasoby wystawione na zewnątrz**
+- Można to zrobić podczas poprzedniej sekcji, musisz **wykryć wszystko, co potencjalnie jest wystawione** do Internetu i w jaki sposób można uzyskać do tego dostęp.
+- Tu mam na myśli **ręcznie wystawioną infrastrukturę** jak instancje z serwisami WWW lub innymi otwartymi portami, a także inne **cloud managed services, które można skonfigurować** jako wystawione (np. DBs lub buckets)
+- Następnie powinieneś sprawdzić **czy dany zasób może być wystawiony czy nie** (informacje poufne? luki? błędy konfiguracyjne w wystawionej usłudze?)
 - **Sprawdź uprawnienia**
-- Tutaj powinieneś **ustalić wszystkie uprawnienia każdej roli/użytkownika** w chmurze i sposób ich użycia
-- Za dużo **kont o wysokich uprawnieniach** (kontrolujących wszystko)? Wygenerowane klucze nieużywane?... Większość tych kontroli powinna być już wykonana podczas testów benchmarkowych
-- Jeśli klient używa OpenID lub SAML lub innej **federacji** możesz potrzebować poprosić ich o dodatkowe **informacje** o **tym, jak przypisywana jest każda rola** (to nie to samo, gdy rola admin jest przypisana do 1 użytkownika lub do 100)
-- **Nie wystarczy ustalić**, którzy użytkownicy mają uprawnienia **admin** "\*:\*". Istnieje wiele **innych uprawnień**, które w zależności od używanych usług mogą być bardzo **wrażliwe**.
-- Co więcej, istnieją **potencjalne privesc** ścieżki do wykorzystania przez nadużycie uprawnień. Wszystkie te rzeczy powinny być uwzględnione i należy zgłosić **jak najwięcej privesc ścieżek**.
+- Tutaj powinieneś **ustalić wszystkie uprawnienia każdej roli/użytkownika** w środowisku cloud i jak są używane
+- Zbyt **wiele kont o wysokich uprawnieniach** (kontrolujących wszystko)? Generowane klucze nieużywane?... Większość tych kontroli powinna być już przeprowadzona w testach benchmarkowych
+- Jeśli klient używa OpenID lub SAML lub innej **federacji**, może być konieczne poproszenie ich o dodatkowe **informacje** dotyczące **jak przypisywana jest każda rola** (to nie to samo, gdy rola admin przypisana jest do 1 użytkownika lub do 100)
+- Nie wystarczy ustalić, którzy użytkownicy mają uprawnienia **admin** "*:*". Istnieje wiele **innych uprawnień**, które w zależności od używanych usług mogą być bardzo **wrażliwe**.
+- Co więcej, istnieją **potencjalne privesc** ścieżki do wykorzystania przy nadużyciu uprawnień. Wszystkie te kwestie powinny zostać uwzględnione i należy zgłosić **jak najwięcej privesc ścieżek**.
 - **Sprawdź integracje**
-- Jest bardzo prawdopodobne, że **integracje z innymi chmurami lub SaaS** są używane wewnątrz środowiska.
-- Dla **integracji chmury, którą audytujesz** z innymi platformami powinieneś powiadomić **kto ma dostęp do (nadużycia) tej integracji** i zapytać **jak wrażliwa** jest akcja, która jest wykonywana.\
-Na przykład, kto może zapisać do AWS bucket, z którego GCP pobiera dane (zapytaj, jak wrażliwa jest ta akcja w GCP traktująca te dane).
-- Dla **integracji wewnątrz chmury, którą audytujesz** pochodzących z zewnętrznych platform, powinieneś zapytać **kto zewnętrznie ma dostęp do (nadużycia) tej integracji** i sprawdzić jak te dane są wykorzystywane.\
-Na przykład, jeśli usługa używa obrazu Docker hostowanego w GCR, powinieneś zapytać, kto ma dostęp do modyfikacji tego obrazu i jakie wrażliwe informacje oraz dostępy uzyska ten obraz po uruchomieniu wewnątrz AWS cloud.
+- Jest bardzo prawdopodobne, że wewnątrz środowiska cloud wykorzystywane są **integracje z innymi cloudami lub SaaS**.
+- Dla **integracji cloud, które audytujesz** z inną platformą powinieneś powiadomić, **kto ma dostęp do (nadużycia) tej integracji** oraz zapytać, **jak wrażliwa** jest akcja, która jest wykonywana.\
+Na przykład: kto może zapisywać do AWS bucketu, z którego GCP pobiera dane (zapytaj, jak wrażliwa jest ta akcja po stronie GCP przy przetwarzaniu tych danych).
+- Dla **integracji wewnątrz audytowanego cloud** pochodzących z zewnętrznych platform, powinieneś zapytać, **kto ma zewnętrzny dostęp do (nadużycia) tej integracji** i sprawdzić, jak te dane są wykorzystywane.\
+Na przykład, jeśli serwis używa obrazu Docker hostowanego w GCR, powinieneś zapytać, kto ma dostęp do modyfikacji tego obrazu i jakie poufne informacje oraz uprawnienia uzyska ten obraz po uruchomieniu wewnątrz AWS.
 
 ## Narzędzia Multi-Cloud
 
-Istnieje kilka narzędzi, które można użyć do testowania różnych środowisk chmurowych. Kroki instalacji i linki zostaną wskazane w tej sekcji.
+Istnieje kilka narzędzi, które można wykorzystać do testowania różnych środowisk cloud. Kroki instalacji i linki zostaną podane w tej sekcji.
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-Narzędzie do **identyfikowania złych konfiguracji i privesc ścieżek w chmurach i pomiędzy chmurami/SaaS.**
+Narzędzie do **identyfikowania złych konfiguracji i privesc path w cloudach i pomiędzy cloudami/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)
 
-Obsługuje **AWS, GCP & Azure**. Sprawdź, jak skonfigurować każdego dostawcę w [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
+Obsługuje **AWS, GCP & Azure**. Sprawdź, jak skonfigurować każdego dostawcę na [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
 ```bash
 # Install
 pip install prowler
@@ -170,7 +170,7 @@ steampipe check all
 
 <summary>Sprawdź wszystkie projekty</summary>
 
-Aby sprawdzić wszystkie projekty, musisz wygenerować plik `gcp.spc`, wskazujący wszystkie projekty do przetestowania. Możesz po prostu postępować zgodnie ze wskazówkami z poniższego skryptu
+Aby sprawdzić wszystkie projekty, musisz wygenerować plik `gcp.spc` wskazujący wszystkie projekty do przetestowania. Możesz po prostu postępować zgodnie z wskazówkami z poniższego skryptu
 ```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>
 
-Aby sprawdzić **inne GCP insights** (przydatne do enumeracji usług) użyj: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+Aby sprawdzić **inne informacje o GCP** (przydatne do enumerowania usług) użyj: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
 
-Aby sprawdzić Terraform GCP code: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
+Aby sprawdzić kod Terraform dla GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
 
-Więcej GCP pluginów Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
+Więcej pluginów GCP dla Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
 {{#endtab }}
 
 {{#tab name="AWS" }}
@@ -225,20 +225,20 @@ cd steampipe-mod-aws-compliance
 steampipe dashboard # To see results in browser
 steampipe check all --export=/tmp/output4.json
 ```
-To check Terraform AWS code: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
+Aby sprawdzić kod Terraform dla AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
 
-More AWS plugins of Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
+Więcej wtyczek AWS dla 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.\
-Wymaga python2.7 i wygląda na porzucone.
+Wymaga python2.7 i wygląda na nieutrzymywany.
 
 ### Nessus
 
-Nessus posiada skan _**Audit Cloud Infrastructure**_ obsługujący: AWS, Azure, Office 365, Rackspace, Salesforce. W **Azure** potrzebne są dodatkowe konfiguracje, aby uzyskać **Client Id**.
+Nessus posiada skan _**Audit Cloud Infrastructure**_ obsługujący: AWS, Azure, Office 365, Rackspace, Salesforce. W **Azure** wymagane są dodatkowe konfiguracje, aby uzyskać **Client Id**.
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
@@ -265,7 +265,7 @@ cloudlist -config </path/to/config>
 
 ### [**cartography**](https://github.com/lyft/cartography)
 
-Cartography to narzędzie w Pythonie, które konsoliduje zasoby infrastruktury oraz relacje między nimi w intuicyjnym widoku grafu opartym na bazie danych Neo4j.
+Cartography to narzędzie w Pythonie, które konsoliduje zasoby infrastruktury i relacje między nimi w intuicyjnym widoku grafu opartym na bazie danych Neo4j.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -302,7 +302,7 @@ ghcr.io/lyft/cartography  \
 
 ### [**starbase**](https://github.com/JupiterOne/starbase)
 
-Starbase zbiera zasoby i relacje z usług i systemów, w tym z infrastruktury chmurowej, aplikacji SaaS, mechanizmów kontroli bezpieczeństwa i innych, i prezentuje je w intuicyjnym widoku grafu opartym na bazie danych Neo4j.
+Starbase zbiera zasoby i relacje z usług i systemów, w tym infrastruktury chmurowej, aplikacji SaaS, kontroli bezpieczeństwa i innych, oraz prezentuje je w intuicyjnym widoku grafu opartym na bazie danych Neo4j.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -361,7 +361,7 @@ uri: bolt://localhost:7687
 
 ### [**SkyArk**](https://github.com/cyberark/SkyArk)
 
-Odnajduje najbardziej uprzywilejowanych użytkowników w zeskanowanym środowisku AWS lub Azure, w tym AWS Shadow Admins. Używa powershell.
+Odkrywa najbardziej uprzywilejowanych użytkowników w skanowanym środowisku AWS lub Azure, w tym AWS Shadow Admins. Używa powershell.
 ```bash
 Import-Module .\SkyArk.ps1 -force
 Start-AzureStealth
@@ -372,15 +372,15 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-Narzędzie do znajdowania infrastruktury firmy (cel), plików i aplikacji na największych dostawcach chmury (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
+Narzędzie do znajdowania infrastruktury firmy (target), plików i aplikacji u największych dostawców chmurowych (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- CloudFox to narzędzie do znajdowania eksploatowalnych ścieżek ataku w infrastrukturze chmurowej (obecnie obsługiwane tylko AWS & Azure, wkrótce GCP).
-- Jest to narzędzie do enumeracji, które ma na celu uzupełnienie manualnego pentestingu.
+- CloudFox to narzędzie do wyszukiwania wykorzystalnych ścieżek ataku w infrastrukturze chmurowej (obecnie obsługiwane tylko AWS & Azure, wsparcie dla GCP wkrótce).
+- Jest to narzędzie do enumeracji, mające na celu uzupełnianie manualnego pentestingu.
 - Nie tworzy ani nie modyfikuje żadnych danych w środowisku chmurowym.
 
-### More lists of cloud security tools
+### Więcej list narzędzi do bezpieczeństwa chmurowego
 
 - [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec)
 
@@ -410,13 +410,12 @@ aws-security/
 azure-security/
 {{#endref}}
 
-### Attack Graph
+## Typowe funkcje bezpieczeństwa chmurowego
 
-[**Stormspotter** ](https://github.com/Azure/Stormspotter)tworzy “attack graph” zasobów w subskrypcji Azure. Umożliwia red teams i pentesters wizualizację powierzchni ataku i możliwości pivotowania w obrębie tenant, oraz znacznie przyspiesza pracę twoich obrońców, pozwalając im szybko się zorientować i priorytetyzować działania związane z reakcją na incydenty.
-
-### Office365
-
-Potrzebujesz **Global Admin** lub przynajmniej **Global Admin Reader** (uwaga: Global Admin Reader jest trochę ograniczony). Jednak te ograniczenia pojawiają się w niektórych PS modules i można je obejść, uzyskując dostęp do funkcji **poprzez aplikację webową**.
+### Poufne przetwarzanie
 
+{{#ref}}
+confidential-computing/luks2-header-malleability-null-cipher-abuse.md
+{{#endref}}
 
 {{#include ../banners/hacktricks-training.md}}