diff --git a/src/pentesting-cloud/confidential-computing/luks2-header-malleability-null-cipher-abuse.md b/src/pentesting-cloud/confidential-computing/luks2-header-malleability-null-cipher-abuse.md new file mode 100644 index 000000000..03174e7c7 --- /dev/null +++ b/src/pentesting-cloud/confidential-computing/luks2-header-malleability-null-cipher-abuse.md @@ -0,0 +1,141 @@ +# LUKS2ヘッダの可変性とConfidential VMにおけるNull-Cipherの悪用 + +{{#include ../../banners/hacktricks-training.md}} + +## TL;DR + +- 多くのLinuxベースのConfidential VMs (CVMs) は AMD SEV-SNP や Intel TDX 上で動作し、永続ストレージに LUKS2 を使っている。オンディスクの LUKS2 ヘッダは可変であり、ストレージ隣接の攻撃者に対して完全性保護されていない。 +- ヘッダ内のデータセグメント暗号が null cipher（例: "cipher_null-ecb"）に設定されていると、cryptsetup はそれを受け入れ、ゲストはディスクが暗号化されていると信じたまま平文の読み書きを透過的に行う。 +- cryptsetup 2.8.0 以前（含む）では null ciphers を keyslots に使うことができた；2.8.1 以降は空でないパスワードを持つ keyslots では拒否されるが、null ciphers はボリュームセグメントでは引き続き許可されている。 +- Remote attestation は通常 VM のコードや設定を計測し、可変な外部 LUKS ヘッダを計測しない；明示的な検証／計測が行われていなければ、ディスクへの書き込み権を持つ攻撃者は平文I/Oを強制できる。 + +## Background: LUKS2 on-disk format (what matters for attackers) + +- LUKS2 デバイスはヘッダの後に暗号化データが続く。 +- ヘッダは、2つの同一コピーのバイナリセクションと JSON メタデータセクション、さらに1つ以上の keyslots を含む。 +- JSON メタデータは次を定義する: + - 有効な keyslots とそれらのラッピング KDF/cipher + - データ領域を記述する segments（cipher/mode） + - digests（例: passphrases を検証するための volume key のハッシュ） +- 一般的に安全とされる値: keyslot KDF は argon2id; keyslot とデータセグメント暗号は 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' +``` +## 根本原因 + +- LUKS2 headers はストレージの改ざんに対して認証／検証されていない。ホスト／ストレージ攻撃者は cryptsetup が受け入れる JSON メタデータを書き換えられる。 +- cryptsetup 2.8.0 以降、セグメントの暗号化を cipher_null-ecb に設定するヘッダが受け入れられる。null cipher はキーを無視し平文を返す。 +- 2.8.0 まで、null ciphers は keyslots にも使えた（keyslot は任意の passphrase で開く）。2.8.1 以降、非空のパスワードを持つ keyslot に対する null ciphers は拒否されるが、セグメントには引き続き許可される。セグメント暗号だけを切り替えても、2.8.1 以降でも平文 I/O が発生する。 + +## 脅威モデル: なぜ attestation がデフォルトであなたを救わなかったか + +- CVMs は信頼されていないホスト上で機密性、完全性、真正性を確保することを目的とする。 +- Remote attestation は通常 VM image と launch configuration を測定し、信頼されていないストレージ上にある可変の LUKS header は測定しない。 +- CVM がオンディスクのヘッダを堅牢な検証／測定なしに信頼している場合、ストレージ攻撃者はそれを null cipher に書き換え、ゲストはエラーなく平文ボリュームをマウントしてしまう。 + +## Exploitation (storage write access required) + +Preconditions: +- CVM の LUKS2 暗号化ブロックデバイスへの書き込みアクセス。 +- ゲストがオンディスクの LUKS2 header を堅牢な検証／attestation なしに使用していること。 + +Steps (high level): +1) ヘッダの JSON を読み、データセグメント定義を特定する。例のターゲットフィールド: segments["0"].encryption +2) データセグメントの暗号化を null cipher（例: cipher_null-ecb）に設定する。guest の通常の passphrase が「動作」するように keyslot パラメータとダイジェスト構造はそのままにしておく。 +3) ヘッダの両コピーと関連するヘッダダイジェストを更新し、ヘッダが自己整合的になるようにする。 +4) 次回起動時、ゲストは cryptsetup を実行し、既存の keyslot を passphrase で正常にアンロックしてボリュームをマウントする。セグメント暗号が null cipher のため、すべての読み書きは平文となる。 + +Variant (pre-2.8.1 keyslot abuse): keyslot の area.encryption が null cipher の場合、任意の passphrase で開く。これを null セグメント cipher と組み合わせることで、ゲストの秘密を知らなくてもシームレスに平文アクセスできる。 + +## Robust mitigations (avoid TOCTOU with detached headers) + +オンディスクの LUKS ヘッダは常に信頼できない入力として扱う。detached-header mode を使用し、検証とオープンが保護された 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 +``` +次に、次のいずれか一つ以上を実施する: + +1) ヘッダ全体のMACを行う +- 使用前にヘッダ全体に対するMACを計算/検証する。 +- MACが検証されたときのみボリュームを開く。 +- 実際の例: Flashbots tdx-init と Fortanix Salmiac はMACベースの検証を採用している。 + +2) 厳密なJSON検証（後方互換） +- JSONメタデータをダンプし、パラメータの厳格な許可リストを検証する (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 +``` +
+例のバリデータ（安全なフィールドを強制する） +```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") +``` +
+ +3) ヘッダを測定／証明する +- ランダムな salts/digests を取り除き、サニタイズされたヘッダを TPM/TDX/SEV の PCRs または KMS ポリシー状態に計測する。 +- 計測したヘッダが承認済みで安全なプロファイルと一致する場合にのみ復号キーを公開する。 + +運用上のガイダンス: +- detached header + MAC または厳格な検証を強制し、on-disk headers を直接信頼しないこと。 +- attestation の利用者は allow-lists において pre-patch framework versions を拒否すべきである。 + +## バージョンとメンテナの立場に関する注意 + +- cryptsetup のメンテナは、LUKS2 はこの設定でストレージの改ざんに対する完全性を提供するよう設計されていないと明言しており、null ciphers は後方互換性のために残されている。 +- cryptsetup 2.8.1 (Oct 19, 2025) はパスワードが空でない keyslots に対する null ciphers を拒否するが、segments に対しては引き続き null ciphers を許可する。 + +## クイックチェックとトリアージ + +- 任意の segment encryption が null cipher に設定されていないかを確認する: +```bash +cryptsetup luksDump --type luks2 --dump-json-metadata /dev/VDISK \ +| jq -r '.segments | to_entries[] | "segment=" + .key + ", enc=" + .value.encryption' +``` +- ボリュームを開く前に keyslot と segment algorithms を検証してください。MAC が使えない場合は厳格な JSON 検証を強制し、protected memory からの detached header を使用して開いてください。 + +## References + +- [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}} diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md index a674475ac..87c9be53e 100644 --- a/src/pentesting-cloud/pentesting-cloud-methodology.md +++ b/src/pentesting-cloud/pentesting-cloud-methodology.md @@ -1,44 +1,44 @@ -# Pentesting Cloud 方法論 +# Pentesting クラウド方法論 {{#include ../banners/hacktricks-training.md}}
-## 基本的な方法論 +## 基本的なメソドロジー -各クラウドには固有の特徴がありますが、一般的にクラウド環境をテストする際に確認すべき**共通のチェック項目（a pentester should check）**がいくつかあります: +各クラウドには固有の特性がありますが、一般的にクラウド環境をテストする際にペンテスターが確認すべき**共通の項目**がいくつかあります: - **ベンチマークチェック** -- これにより環境の**規模を理解**し、**使用されているサービス**を把握できます -- ほとんどのテストを**自動化ツール**で実行できるため、**簡単なミスコンフィギュレーション**を見つけられることもあります -- **Services Enumeration** -- ベンチマークテストを正しく実施していればここで大きなミスコンフィギュレーションはあまり見つからないかもしれませんが、ベンチマークで見落とされていたものが見つかる場合があります -- これによりクラウド環境で**何が実際に使われているか**を把握できます +- これは環境の**規模を理解**し、**利用されているサービス**を把握するのに役立ちます +- ほとんどのテストを**自動化ツール**で実行できるため、**迅速な設定ミス**を見つけるのにも有効です +- **サービスの列挙** +- ベンチマークテストを正しく実施していればここで新たな設定ミスは多く見つからない可能性がありますが、ベンチマークで見られていなかったものが見つかることがあります +- これによりクラウド環境で**具体的に何が使われているか**を把握できます - 次のステップで非常に役立ちます - **公開されているアセットの確認** -- これは前のセクションで行うことができ、潜在的にインターネットに公開されているものを**すべて特定**し、それがどのようにアクセス可能かを確認する必要があります -- ここでは、webページや他のポートが公開されているインスタンスのような**手動で公開されたインフラ**、および公開可能な構成がなされる**クラウド管理サービス**（DBsやbucketsなど）について扱います -- 次に、そのリソースが**実際に公開され得るか**（機密情報？脆弱性？公開されているサービスの設定ミス？）を確認するべきです +- これは前節の間に実施できます。インターネットに**何が潜在的に公開されているか**、またそれにどうアクセスできるかを**全て見つけ出す**必要があります。 +- ここでは手動で公開されたインフラ（ウェブページや他のポートが公開されているインスタンスなど）や、公開可能に設定されうる**クラウド管理サービス**（例えば DBs やバケット）について扱います +- 次にそのリソースが**公開可能かどうかを確認**するべきです（機密情報か？脆弱性か？公開サービスの設定ミスか？） - **権限の確認** -- ここでは、クラウド内の各ロール/ユーザーが持つ**すべての権限**とそれらがどのように使われているかを特定する必要があります -- 過度に**高い権限を持つアカウント**が多すぎる？（すべてを制御できる）生成されたキーが使われていない？…これらの多くは既にベンチマークテストで確認されているはずです -- クライアントがOpenIDやSAML、その他の**federation**を使用している場合、各ロールがどのように割り当てられているかについてさらに**情報**を求める必要があるかもしれません（管理者ロールが1人に割り当てられているのと100人に割り当てられているのでは状況が異なります） -- **見つけるだけでは不十分**にどのユーザーが**admin**権限 "\*:\*" を持っているかを確認するだけでは不十分です。使用されているサービスによっては非常に**センシティブ**になり得る**その他の権限**が多数存在します -- さらに、権限を悪用して追跡可能な**potential privesc**の経路が存在します。これらすべてを考慮し、**できるだけ多くの privesc paths**を報告する必要があります +- ここではクラウド内の各ロール/ユーザーの**全ての権限を調べ**、それらがどのように使われているかを把握するべきです +- あまりにも**多くの高権限アカウント**（すべてを制御する）がありますか？ 生成されたキーが未使用ですか？… これらの多くはベンチマークテストで既に確認されているはずです +- クライアントが OpenID や SAML やその他の federation を使用している場合、各ロールが**どのように割り当てられているか**についてさらに**情報**を求める必要があるかもしれません（admin ロールが 1 人に割り当てられているのと 100 人に割り当てられているのとでは同じではありません） +- 単にどのユーザーが "**admin**" 権限（"*:*"）を持っているかを見つけるだけでは**不十分**です。利用されているサービスによっては他にも非常に**センシティブな**権限が多数あります。 +- さらに、権限を悪用して進められる**privesc** の経路が存在する可能性があります。これらすべてを考慮し、**可能な限り多くの privesc パス**を報告すべきです。 - **統合の確認** -- クラウド環境内で**他のクラウドやSaaSとの統合**が使われている可能性が非常に高いです -- 監査対象のクラウドが他のプラットフォームと行っている**統合**については、その統合を(悪用)できる**誰がアクセス権を持っているか**を通知し、その操作がどれほど**機密性が高いか**を確認するべきです。\ -例えば、GCPがデータを取得しているAWSのbucketに誰が書き込みできるか（そのデータをGCPで扱う際にどの程度機密性があるかを尋ねる）。 -- 外部プラットフォームから監査対象のクラウド内に対する**統合**については、その統合を外部から(悪用)できる**誰がアクセス権を持っているか**を確認し、そのデータがどのように使用されているかをチェックするべきです。\ -例えば、あるサービスがGCRにホストされたDockerイメージを使用している場合、そのイメージを変更できるのは誰か、そしてそのイメージがAWSクラウド内で実行されたときにどのような機密情報やアクセス権を取得するかを確認すべきです。 +- クラウド環境内で他のクラウドや SaaS との**統合**が利用されている可能性が高いです。 +- 監査対象のクラウドが他のプラットフォームと統合されている場合、**その統合を(濫用)できるのは誰か**を通知し、その操作がどれほど**センシティブ**かを確認すべきです。\ +例えば、GCP がデータを取得している AWS のバケットに誰が書き込みできるか（GCP 側でそのデータを扱う操作がどれほどセンシティブかを確認する）など。 +- 監査対象のクラウド内に外部プラットフォームからの統合がある場合、**外部からその統合を(濫用)できるのは誰か**を確認し、そのデータがどのように使われているかをチェックすべきです。\ +例えば、あるサービスが GCR にホストされた Docker image を使用している場合、その image を修正できるのは誰か、そしてその image が AWS クラウド内で実行されたときにどのような機密情報やアクセスを得るかを確認すべきです。 -## マルチクラウドツール +## マルチクラウド用ツール -異なるクラウド環境をテストするために使用できるツールがいくつかあります。インストール手順とリンクはこのセクションで示します。 +さまざまなクラウド環境をテストするために使えるツールがいくつかあります。インストール手順とリンクはこのセクションで示します。 ### [PurplePanda](https://github.com/carlospolop/purplepanda) -クラウドおよびクラウド間/SaaSにおける**不適切な設定とprivesc pathを識別する**ツール。 +クラウド内およびクラウド/SaaS 間での**不適切な設定や privesc パスを特定する**ツールです。 {{#tabs }} {{#tab name="Install" }} @@ -71,7 +71,7 @@ python3 main.py -e -p google #Enumerate the env ### [Prowler](https://github.com/prowler-cloud/prowler) -それは **AWS, GCP & Azure** をサポートしています。各プロバイダの設定方法は [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) を確認してください。 +これは **AWS, GCP & Azure** をサポートしています。各プロバイダの設定方法は [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" }} -Steampipe をダウンロードしてインストールしてください（[https://steampipe.io/downloads](https://steampipe.io/downloads)）。または Brew を使用してください: +Steampipe をダウンロードしてインストールします（[https://steampipe.io/downloads](https://steampipe.io/downloads)）。または Brew を使用： ``` brew tap turbot/tap brew install steampipe @@ -168,9 +168,11 @@ steampipe check all ```
-すべてのプロジェクトを確認 +すべてのプロジェクトをチェック -すべてのプロジェクトをチェックするには、テストするすべてのプロジェクトを指定する `gcp.spc` ファイルを生成する必要があります。以下のスクリプトの指示に従えばよいです。 +すべてのプロジェクトをチェックするには、テストするすべてのプロジェクトを示す `gcp.spc` ファイルを生成する必要があります。以下のスクリプトに従ってください。 + +
```bash FILEPATH="/tmp/gcp.spc" rm -rf "$FILEPATH" 2>/dev/null @@ -194,11 +196,11 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate ``` -他の **GCP insights**（サービスの列挙に有用）を確認するには、次を使用してください: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights) +To check **他の GCP インサイト**（サービスの列挙に役立ちます）を確認するには: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights) -Terraform の GCP コードを確認するには: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance) +To check Terraform GCP code: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance) -Steampipe の GCP プラグインをさらに見る: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp) +Steampipe のその他の GCP プラグイン: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp) {{#endtab }} {{#tab name="AWS" }} @@ -225,24 +227,24 @@ 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) +Terraform の 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) +Steampipe の他の AWS プラグイン: [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.\ -python2.7 が必要で、メンテナンスされていないように見えます。 +python2.7 が必要で、メンテナンスされていないようです。 ### Nessus -Nessus には _**Audit Cloud Infrastructure**_ スキャンがあり、以下をサポートします: AWS、Azure、Office 365、Rackspace、Salesforce。**Azure** では **Client Id** を取得するためにいくつかの追加設定が必要です。 +Nessus には _**Audit Cloud Infrastructure**_ スキャンがあり、以下をサポートします: AWS, Azure, Office 365, Rackspace, Salesforce。**Azure** では **Client Id** を取得するためにいくつか追加の設定が必要です。 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist) -Cloudlist は Cloud Providers から Assets（Hostnames、IP Addresses）を取得するための **multi-cloud tool for getting Assets** です。 +Cloudlist は Cloud Providers から Assets（Hostnames, IP Addresses）を取得するための **multi-cloud tool** です。 {{#tabs }} {{#tab name="Cloudlist" }} @@ -265,7 +267,7 @@ cloudlist -config ### [**cartography**](https://github.com/lyft/cartography) -Cartographyは、Neo4jデータベースで駆動される直感的なグラフビューで、インフラストラクチャの資産とそれらの関係を統合するPythonツールです。 +Cartographyは、Neo4jデータベースによって駆動される直感的なグラフビューで、インフラ資産とそれらの関係を統合するPythonツールです。 {{#tabs }} {{#tab name="Install" }} @@ -302,7 +304,7 @@ ghcr.io/lyft/cartography \ ### [**starbase**](https://github.com/JupiterOne/starbase) -Starbaseはクラウドインフラ、SaaSアプリケーション、セキュリティコントロールなどを含むサービスやシステムから資産と関係性を収集し、Neo4jデータベースをバックエンドにした直感的なグラフビューにまとめます。 +Starbaseは、クラウドインフラ、SaaSアプリケーション、セキュリティコントロールなどを含むサービスやシステムから資産と関係性を収集し、Neo4jデータベースで支えられた直感的なグラフビューに統合します。 {{#tabs }} {{#tab name="Install" }} @@ -361,7 +363,7 @@ uri: bolt://localhost:7687 ### [**SkyArk**](https://github.com/cyberark/SkyArk) -スキャンされた AWS または Azure 環境で、最も権限の高いユーザー（AWS Shadow Admins を含む）を検出します。powershell を使用します。 +スキャン対象の AWS または Azure 環境内で、AWS Shadow Admins を含む最も権限の高いユーザーを特定します。powershell を使用します。 ```bash Import-Module .\SkyArk.ps1 -force Start-AzureStealth @@ -372,15 +374,15 @@ Scan-AzureAdmins ``` ### [Cloud Brute](https://github.com/0xsha/CloudBrute) -A tool to find a company (target) infrastructure, files, and apps on the top cloud providers (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode). +企業（ターゲット）のインフラ、ファイル、アプリを主要クラウドプロバイダ（Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode）上で発見するためのツール。 ### [CloudFox](https://github.com/BishopFox/cloudfox) -- CloudFox is a tool to find exploitable attack paths in cloud infrastructure (currently only AWS & Azure supported with GCP upcoming). -- It is an enumeration tool which is intended to compliment manual pentesting. -- It doesn't create or modify any data within the cloud environment. +- CloudFoxは、クラウドインフラ内の悪用可能な攻撃経路を発見するためのツールです（現時点ではAWSとAzureのみ対応、GCPは今後対応予定）。 +- 手動pentestingを補完する列挙ツールです。 +- クラウド環境内のデータを作成・変更しません。 -### More lists of cloud security tools +### クラウドセキュリティツールの追加リスト - [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec) @@ -410,13 +412,12 @@ aws-security/ azure-security/ {{#endref}} -### 攻撃グラフ +## 共通のクラウドセキュリティ機能 -[**Stormspotter** ](https://github.com/Azure/Stormspotter)はAzureサブスクリプション内のリソースの“攻撃グラフ”を作成します。red teamsやpentestersがテナント内の攻撃面とピボットの機会を可視化できるようにし、防御担当者が迅速にインシデント対応の方向付けと優先順位付けを行えるように大幅に支援します。 - -### Office365 - -You need **Global Admin** or at least **Global Admin Reader** (but note that Global Admin Reader is a little bit limited). However, those limitations appear in some PS modules and can be bypassed accessing the features **Web アプリケーション経由**. +### 機密コンピューティング +{{#ref}} +confidential-computing/luks2-header-malleability-null-cipher-abuse.md +{{#endref}} {{#include ../banners/hacktricks-training.md}}