本サイトは、快適にご利用いただくためにクッキー(Cookie)を使用しております。
Cookieの使用に同意いただける場合は「同意する」ボタンを押してください。
なお本サイトのCookie使用については、「個人情報保護方針」をご覧ください。
はじめに
こんにちは、セキュリティサービス開発事業部の藤田です。普段はプラットフォーム診断やサーバ構成診断などを担当しています。
2026年8月1日から8月6日までラスベガスで開催された「Black Hat USA 2026」に参加する機会をいただきましたので参加レポートとしてご紹介します。
海外出張は初めてであり、入国審査で別室での追加確認を受けた事例も聞いていたため、現地に着くまでに不安なことも多かったです。しかし、幸いにも手続きなどはスムーズに進み、時差ぼけの影響もあまり受けることなく過ごせました。
ラスベガスは猛暑と聞いていましたが、滞在先のLuxor HotelからBlack Hat会場までは屋外に出ることなく徒歩で移動できたこともありがたかったです。

Black Hat会場付近のイベントサイン
Black Hat USA 2026 スケジュール
今回のBlack Hat USA 2026では、以下スケジュールで主に4日間のTrainingsとBriefingsに参加しました。
| 日付 | 内容 |
| 8/1~8/4 | 4Days Trainings参加 |
| 8/5~8/6 | Briefings参加 |
今回の記事では8/1~8/4に受講したトレーニングにフォーカスしてお送りします。
今回受講したNotSoSecure社の「Hacking and Securing Cloud Infrastructure」は、AWS、Azure、Google Cloud Platformを中心とした、様々なクラウドサービスにおけるセキュリティを攻撃者・防御者双方の視点から体系的に学ぶ内容で構成されていました。
トレーニング期間の半分以上がラボ環境での演習となっており、講義で学んだ内容をすぐに手を動かして理解することができます。
私が普段担当しているプラットフォーム診断では、例えばEC2をはじめとしたIaaS基盤などのクラウドサービス上に構築されたシステムなどを対象とすることが多くあります。一方で、システムの手前にあるクラウドサービスそのもののセキュリティは、日々の診断スコープに直接含まれる機会が少なかったため、そうした領域への知見を増やし、現在の診断業務の精度・品質向上や新たな領域に対する診断スキル習得に繋げたいというのが今回のトレーニング受講を決めた主な理由です。
最近ではレッドチーム(攻撃者視点で疑似攻撃を行い組織のセキュリティを評価する専門チーム)と共同でペネトレーションテストを実施する機会もあることから、クラウドインフラにおいてどのような設定がどういう条件のもとで実際の侵害につながるのか、それらをいかに防ぐかについて座学だけでなく手を動かしてつかむことで、今後のペネトレーションテストにおいて更なる攻撃の起点の発見や、より実践的な攻撃シナリオの構築につなげていくことも期待しながら臨みました。
トレーニング受講前はクラウドに対する攻撃も公開状態のストレージや過剰なIAM権限といった、個々の設定不備に起因するものであり、それらを一つずつ潰していくことが防御策につながるだろうと思っていました。診断の現場で設定不備を指摘してきた経験から、クラウド環境でも設定不備や攻撃手法に関するカタログを増やせば対応できるだろうという感覚を持っていましたが、この感覚が4日間でどう変わったのかは本記事の最後にあらためて整理します。
今回のトレーニングでは、タイトルにHacking and Securingとある通り、防御視点の内容も充実しており、攻撃手法に関する内容や防御策に関する部分を中心にご紹介したいと思います。
なお、各日程のトレーニング内容は以下の通りです。
| Day1 | ・Introduction to Cloud Computing ・Enumeration of Cloud Environments ・Attack Surface of Cloud Services ・Attacking Storage Services ・Attacking Microsoft Azure AD Environment |
| Day2 | ・Attacking Microsoft Azure AD Environment ・Attacking AWS Environment |
| Day3 | ・Attacking AWS Environment ・Attacking GCP Environment |
| Day4 | ・Attacking GCP Environment ・Revisiting Cloud Misconfigurations In Hardened Environment ・Cloud Defense Using Open-Source And Cloud-Native Tools ・Cloud Auditing And Benchmarking ・Capture The Flag |
(出典:NotSoSecure社が公開している同コースのCourse Informationより)
トレーニング概要
本コースでは、先ほどお伝えした通り、講義に対してトレーニング期間の半分以上がラボ演習に割かれていることが特徴です。参加者にはWebブラウザからアクセス可能なクラウドベースのKali Linux(ペネトレーションテストや脆弱性診断用に特化したLinuxディストリビューション)の仮想マシンが提供される他、ローカルで利用可能な仮想マシンのイメージも提供されます。
筆者はトレーニング期間終了後も学習を継続しやすいようにローカルの仮想マシンを使用しました。Kali Linuxについては普段から診断やペネトレーションテストで使用しているため、演習環境の操作に戸惑うことはなく、スムーズに演習へ入ることができました。
仮想マシン内には、各クラウドのCLI(az / aws / gcloudなど)やトレーニングで使用する様々なツールがあらかじめ準備されていました。参加者側の事前準備がほとんど不要なほど手厚く受講環境が整えられており、攻撃に関する演習ではこれらを使用しながら用意されたクラウド環境に対して、情報収集、権限調査、アクセス範囲の確認、権限昇格や横展開の可能性に対する検証などを段階的に実施していきます。
一方で、環境が学習用に整えられている以上、権限やポリシーなどは攻撃が成立するように意図的に構成されている場面もありました。漫然と手を動かしていると、用意されたシナリオの再現に終始して理解度が低くなる可能性があったので、演習の際は常に「なぜ今この攻撃が通ったのか=どのような前提に立っているのか」「この前提が崩れたら攻撃はどこで止まるのか」を分解しながら取り組みました。この成立条件の分解が、後述する気づきの起点になりました。
Attacking Storage Services
このセクションでは、AWS・GCP・Azureにおけるクラウドストレージのセキュリティについて学びました。
AWS S3で主要なリスクとして取り上げられたのは、バケットポリシーやACLの設定ミスによる意図しない公開アクセスです。Public Accessが許可されているケースや、過剰に許可されたバケットポリシーが、実際の侵害事例へ直結してきた経緯が解説されました。
GCPのCloud Storageでも同様に、アクセス制御の設定ミスが攻撃の糸口になります。
Azureについては、SAS(Shared Access Signature)の設定ミスが取り上げられました。SASは有効期限やアクセス権限を署名付きトークンとしてURL(クエリ文字列)に付与する仕組みですが、過度な権限設定や長すぎる有効期限、URLの意図しない漏洩が予期せぬデータ漏洩につながるリスクがあります。
演習では、それぞれのストレージの列挙・特定を行い、コンテンツの奪取まで実践しました。
Attacking Microsoft Azure AD Environment
Microsoft AzureおよびMicrosoft Entra ID(旧Azure AD)環境への攻撃手法を体系的に学びました。
まずAzureの基本アーキテクチャを押さえたうえで、App Service・Azure Functions・Storage Accountといったアプリケーション基盤への攻撃手法へと進みます。さらに、Azure DatabaseやAutomation Accountの悪用、機密情報の管理基盤であるAzure Key Vaultへの攻撃など、対象は多岐にわたりました。
認証・認可の観点では、Microsoft Entra IDの認証方式を整理した上で、正規に有効化されているManaged Identityのアクセストークンが悪用され、そのIDの権限でリソースが操作されうる攻撃シナリオが取り上げられました。また、Conditional Access Policyの設定不備によってMFAの認証制御が期待通りに機能しないケースも取り上げられ、クラウド環境におけるアイデンティティ管理の重要性を実感する内容でした。
ラボ環境での演習では、講義で学んだテクニックを用いて、実際に以下の流れで初期侵入から権限昇格までを体験しました。
- Initial Access
- Post Exploitation
- Lateral Movement
- Cross Subscription
- MFA Bypass
- Privilege Escalation
この一連の流れで最も学びが大きかったのは、各ステップの遷移が単一の致命的な脆弱性ではなく、単体では低リスクに見えるものも含めた複数の設定・権限を組み合わせた結果として成立していた点です。例えばManaged Identityのトークン取得そのものは正規の挙動であり、それ単体を脆弱性として指摘するのは難しいです。しかし、そのトークンに紐づく権限が過剰であれば、正規機能の連鎖が攻撃経路になり得ます。
この演習では確認した設定や権限などを点として並べるだけでは、点と点を結んだときに生まれる本当のリスクを見落としうることを具体的な操作を通して感じることができました。この低リスク項目の連鎖が高リスクを生むという感覚は、担当する診断サービスを問わず持ち帰るべき視点だと感じました。
Attacking AWS Environment
AWS環境における典型的な設定ミスを起点とし、特権昇格や機密情報奪取に至るまでの攻撃チェーンを学びました。
中心となるのがIAMの悪用です。管理者グループに属していなくても、特定の権限を持つことで環境全体の乗っ取りに悪用される可能性がある「Shadow Admin」の考え方やiam:PassRoleを利用して特権ロールをサービスに付与し、そのサービスを経由して操作を行う手法などを扱いました。
認証情報の漏洩経路についても深く掘り下げ、AWS Cognitoの設定ミスにより攻撃者がAWSの一時的な認証情報を取得しリソースへ不正アクセスされるリスクや、IMDS(Instance Metadata Service)とSSRFを組み合わせて一時的なIAM認証情報を窃取する手法など、攻撃の足掛かりとなり得る典型的な問題を確認しました。
コンテナやスナップショットのイメージから機密情報を取得するアプローチも扱われました。ECR(Elastic Container Registry)から取得したDockerイメージをDiveなどのツールで解析し、イメージ内に含まれる機密情報を抽出する演習や公開設定のままになっているスナップショットを攻撃者が自身のアカウントにコピー・マウントし、OS内部の機密ファイルへ直接アクセスする手法などを実践しました。
このセクションでも、クラウドセキュリティに対する考え方として印象深い点がありました。例えばiam:PassRoleに関する演習ではiam:AddUserToGroupを含むポリシーがアタッチされたロールをiam:PassRoleでEC2インスタンスに渡して起動し、そのインスタンスにSSH接続後、インスタンスプロファイル経由で得た認証情報から自身のユーザーを特権グループへ追加することで、管理者相当への昇格チェーンを達成するというステップがありました。
iam:PassRoleもiam:AddUserToGroupも、それぞれ単体で見ればサービス連携や権限管理に用いられる正規の権限です。しかしこれらがロールをEC2に渡して起動し、その上で権限を行使するという一連の経路でつながると、単体では見えなかった昇格パスができあがります。知識としては理解していたつもりでしたが、初期状態から昇格成立までを自分の手で一連の操作として追うことで、周囲の権限や実行環境との組み合わせ次第でリスクが大きく変わることが実感を伴って理解できました。個々の権限を単体で眺めるのではなく、「この権限は、他のどの権限や実行経路と結び付いたとき、どこまで到達可能になるか」という到達経路として捉える視点が不可欠だと痛感しました。
さらに、単一アカウント内にとどまらず、アカウントをまたいだ権限の利用やポリシーの設定不備が影響範囲の拡大につながる可能性についても確認しました。これは診断のスコープ設計そのものにも関わってくる点であり、アカウント単位・システム単位で切ったスコープが攻撃者の視点では意味をなさない場合があるという気づきにつながりました。
Attacking GCP Environment
GCP環境における攻撃パスについても、列挙から権限昇格、そしてPost Exploitationまで幅広く学びました。
GCPのセキュリティを理解するうえで中心となるのが、IAMロールとサービスアカウントです。まずはサービスアカウントファイルやアクセストークンを用いた認証の仕組みを整理し、これらが漏洩・悪用された場合にどのようなリスクにつながるのかを攻撃者視点で確認しました。
各サービスに対する具体的な攻撃手法の例としては、Compute EngineのメタデータAPIを悪用してデフォルトサービスアカウントのスコープを確認のうえCloud Storageなど他のリソースへの不正アクセスを試みる手法や、Artifact Registryのストレージバケットを特定してDockerイメージをプルし、イメージ内に含まれる機密情報を抽出する手法などが紹介されました。
また、IAP(Identity Aware Proxy)に対するアクセス制御の回避に関する演習では、サービスアカウントをリソースに関連付けて、その権限で実行する権限(iam.serviceAccountUser)を悪用する手法が扱われました。IAP設定を変更できる権限を持った別のサービスアカウントをCloud Run関数に関連付けてデプロイし、その権限を間接的に借りることでIAPのアクセス許可設定(IAMポリシー)に攻撃者自身を正規の許可対象として追加し、保護対象リソースへ到達する、という流れです。
その他、IAM Impersonation(サービスアカウントのなりすまし)を用いた攻撃手法なども扱われました。これはserviceAccountTokenCreatorロールを持つプリンシパルが、対象のサービスアカウントに対して一時的な認証情報を生成できる点に着目したものです。演習ではこの権限を悪用し、より強い権限を持つサービスアカウント(本来アクセスできないプライベートバケットやシークレット管理サービスへのアクセス権を持つもの)になりすまし、情報を奪取する流れを体験しました。
ここでも、AWSと同じ構造が別の名前で現れていることに気づきました。IAPの事例における「別のサービスアカウントをリソースに関連付ける権限」や、IAM Impersonationにおける「より強い権限のサービスアカウントになりすませる権限」といった間接的な特権が、実質的な権限昇格経路になる構造はAWSのiam:PassRoleと類似しており、「委任・引き受け系の権限」が共通の勘所になるという横断的な学びを得られたのは、複数のクラウドサービスを一度に学ぶ本コースならではの気づきでした。
なお、ここまで各プラットフォームで取り上げた攻撃手法は、いずれも「その手法があれば必ず特定の攻撃が成立する」というものではありません。ある手法が初期侵入・権限昇格・横展開・情報窃取のどの目的で有効に機能するかは、攻撃対象となるサービスやアカウント/プリンシパルに割り当てられた権限・ポリシー・ロール、そして対象サービス側の構成などに大きく左右されます。今回のラボはあくまで学習用に設計された環境であり、そこで有効だった手法がそのまま普遍的に通用するわけではないという点は意識しておく必要があると感じました。裏を返せば、防御側は権限やポリシーを適切に絞り込むことで、同じ手法の成立条件そのものを崩せるということでもあります。
Revisiting Cloud Misconfigurations In Hardened Environment
攻撃手法の学習を踏まえ、それらをいかに遮断するかという防御策に関する内容です。
Azure・AWS・GCPそれぞれのプラットフォームについて、設定ミスを解消するアプローチを整理しました。例として以下のようなものがあります。
- Azure:Key Vaultやストレージアカウントに対するネットワークファイアウォールの適用に加え、条件付きアクセスポリシーによるMFAの強制など、境界防御とアイデンティティ管理の両面からのアプローチを行う
- AWS:デフォルトで有効な機能・ポリシーの精査やメタデータエンドポイントへのアクセス制限など、見落としがちなデフォルト設定の無効化やシークレット管理サービスへのネットワーク制限を行う
- GCP:過剰な権限が付与されたデフォルトサービスアカウントの使用を避け、カスタムサービスアカウントへ移行して最小権限を割り当てる。また、ファイアウォールルールをタグやサービスアカウント単位で厳格に制御し、攻撃者の横展開を防ぐ
各プラットフォームを通じて、クラウドセキュリティにおける共通の重要原則は以下の3点にあると考えました。
- デフォルト設定を前提としない:デフォルトで有効な機能や権限が攻撃経路となる場合があるため、必要性を確認したうえで必要最小限に絞り込む
- 多層防御の構築:権限管理だけでなく、ファイアウォールなどのネットワーク制御を組み合わせ、二重三重の制限をかける
- 最小権限の原則:カスタムロールの活用やリソースベースポリシーなどを用いて誰が・いつ・どこから・何にアクセスできるかを厳格に定義する
重要なのは、これらの防御策が攻撃セクションで学んだ成立条件を打ち消す形で対応している点です。攻撃を成立条件の集合として分解できていれば、防御はどの条件を、どの優先度で対策するかという具体的な判断に落ちます。理想は連鎖を構成する複数の条件に対して多層的に対策を講じることですが、現実にはリソースや運用上の制約もあります。そうした中でも、成立条件を可視化できていれば、影響の大きい条件から優先的に対処しつつ、単一の対策に依存しない多層防御を組み立てられます。攻撃と防御を対になるものとして学べたことが本セクションの価値でした。
Cloud Defense Using Open-Source And Cloud-Native Tools
このセクションでは、クラウドネイティブツールやオープンソースツールを組み合わせ、実効性のある防御体制を構築する手法について学びました。
軸となるのは、「資産の特定(Identify)」→「保護(Protect)」→「検知(Detect)」→「対応(Respond)」というライフサイクルに基づいた防御戦略です。特に管理外のリソース(シャドウIT)の可視化や最小権限の原則の適用が重要です。
有用なツールの例としては以下のようなものが紹介されており、各プラットフォームが提供するセキュリティサービスを最適に組み合わせることがポイントになります。
- 検知:GuardDuty / Defender for Cloud / Security Command Centerによる脅威検知
- 脆弱性・構成管理:Amazon Inspectorによる継続的な脆弱性スキャンやAWS Configを用いた構成変更の監視・自動修正
その他、マルチクラウド環境対応のオープンソースSIEMであるWazuhなどを活用し、プラットフォームを横断してログを一元的に収集・分析することでベンダー固有のツールだけでは見落としがちな相関関係を可視化する手法も紹介されていました。
Cloud Auditing And Benchmarking
クラウド環境でのガバナンス手法に関するセクションです。CIS Benchmarksなどのガイドラインを用いてIAMやリソース設定を客観的に評価する手法が紹介され、Steampipeなどのオープンソースツールを用いて設定ミスの可視化を実践しました。
さらにコンテナのゴールデンイメージに対する監査を行い、デプロイ前に脆弱性を排除する「Secure by Default」の考え方の重要性なども示されていました。
トレーニングのまとめ
本コースはクラウドセキュリティを攻撃・防御の両面から広範に扱う、非常に密度の高い内容でした。学べる要素は多岐にわたりましたが、ここではそれらを個別の手法として振り返るのではなく、4日間を通して筆者自身が学びになった視点に絞って整理します。
いずれも本コースの主題そのものというより、広範な内容の中から普段の業務観点で価値を見出した点について記載したものであり、以下の根拠として挙げる手法はあくまでその視点を象徴的に示す一例として取り上げています。
- 攻撃は「成立条件の連鎖」として立ち上がる
この視点を象徴的に示していたのが、Azureにおける正規のManaged Identityのトークン悪用やAWSのiam:PassRoleを利用した特権ロールの付与、そしてGCPにおけるiam.serviceAccountUserを利用したサービスアカウントの関連付け・IAM Impersonationによるサービスアカウントのなりすましなどです。攻撃の起点となる仕組みはそれぞれ異なりますが、いずれも単体では正規の機能・権限でしかありません。共通しているのは、正規に用意された仕組みを目的外利用し、権限や資格情報を次々とたどることで、本来到達できないはずのリソースへ到達している点です。
同様の構造はコース全体の随所に共通して現れていました。致命的な攻撃は、こうした低リスクに見える要素も含めて複数の問題が連鎖して成立します。この設定は脆弱か否かという二値評価ではなく、この要素が他のどの要素と結び付いたとき、どこまで到達可能になるかという到達経路の視点。これがコース全体を通して感じた学びです。
- プラットフォームごとの攻撃原理は共通する
Azure・AWS・GCPはサービスや使用される用語、APIなども異なりますが、3プラットフォームを横断的に学んだことで、攻撃者が狙う本質が共通していることが見えてきました。権限の悪用はもちろん、それに限らずメタデータや資格情報の露出面をどう見つけるか、正規の機能をどう目的外利用するかといった点は、プラットフォームを問わず繰り返し登場しました。個別の手法ではなく、クラウドというレイヤーで攻撃を捉える視点を獲得できたことは、応用の効く資産だと考えています。
- 攻撃と防御は成立条件を挟んだ表裏である
本コースは攻撃手法だけでなく、Hardened環境での再検証、防御ツールの活用、CIS Benchmarksによる監査までを一連の流れとして扱っていました。この構成を通じて、攻撃を成立条件の集合として分解できていれば、防御はそれらの条件へ多層的に対策を講じる具体的な行動に落ちる、という関係が腹落ちしました。連鎖を構成する条件が可視化されていれば、どの条件がより多くの攻撃経路の起点になっているかを見極め、優先度をつけながら二重三重に対策を重ねられます。攻撃手法と防御策を別々の知識としてではなく、同じ成立条件を攻撃側から見るか防御側から見るかの違いとして統合的に捉えられたことが本コースの構成上の大きな価値でした。
そして冒頭で述べた設定不備や攻撃手法のカタログを増やせば対応できるという当初の感覚は、これら3つの視点を得たことで明確に更新されました。攻撃も防御も、個々の項目を並べる作業ではなく、成立条件の連鎖を読み解く必要があると捉え直せたことが4日間の最大の収穫です。
また、「攻撃を成立条件の連鎖として捉える」「表層的なサービスや実装の違いではなく、その裏にある共通の攻撃原理に着目する」「攻撃と防御を対で捉える」という視点は、いずれも特定のクラウドや技術に閉じない思考様式として活用できるものであり、現在担当しているプラットフォーム診断やペネトレーションテストにおいても複数の指摘事項を独立した点ではなく攻撃経路として捉え直すことにより、リスク評価の妥当性や改善提案の説得力を高める土台にしていきたいと考えています。
今回のトレーニングをきっかけに今後もクラウドインフラに対する知見を増やしつつ、将来クラウドインフラを対象としたペネトレーションテストにも積極的に取り組んでいきたいと思います。
最後に
英語でのトレーニングということで不安もありましたが、教材が丁寧に作られていたことやトレーニングの大部分がガイド付きの演習時間に充てられていたこともあり、これまでの業務経験やトレーニング概要、配布資料などをもとに行った予習もベースにしながら内容は十分に理解可能なものでした。
トレーニングはクラウドに関する内容がほとんどでしたので、ここで少しだけトレーニング以外のお話をさせていただきますが、今回のBlack Hat USA 2026のメイントピックはやはりAIであり、今回の参加を通じて特に強く実感したのは、AIが単にセキュリティを支援する技術ではなく、攻撃・防御の在り方そのものを変えつつあるということでした。
BriefingsでもAIを活用した脆弱性研究や脅威ハンティング、AIエージェントに対する攻撃などAIとセキュリティに関するテーマが数多く取り上げられていました。
またBriefingsの合間に覗いたArsenalでも様々なAI関連のツールが紹介されており、AIエージェントがペネトレーションテストの作業を支援するだけでなく、ツール実行・結果分析・次のアクションの判断および実行までを完全自律的に行っていくものなど非常に興味深く、その様子を実際に見ることでAIがセキュリティの現場で使われるものから自ら動くものへと変わりつつあることを強く感じました。
今回得た知見や現地で感じた変化を今後の取り組みに活かし、これからも技術力と知見の向上に努めていきたいと思います。
以上、Black Hat USA 2026のトレーニング参加レポートをお送りいたしました。

トレーニング会場
おすすめ記事