この出版物は、Microsoft Entra ID（旧称Azure Active Directory）に対するさまざまな一般的な攻撃シナリオと、それらを軽減または検出する方法をまとめたものです。
この出版物は、Microsoft Entraに対する一般的な攻撃シナリオと、それらを軽減または検出する方法をまとめたものです。収録されているすべてのシナリオ、洞察、コメントは、貢献者が攻撃シミュレーション、実践、または実世界のシナリオで得た経験に基づいています。
これは生きたドキュメントと見なすべきであり、攻撃・防御技術の進展に伴って更新されます。コミュニティのアイデンティティまたはセキュリティの専門家には、この出版物に協力し、更新、フィードバック、コメント、または追加の寄稿を行っていただくことを歓迎します。
すべての章で、章構成に関する同じガイドラインに従っています。読む際には、以下のような内容が見つかることを期待できます。
次のセクションでは、「Entra ID Attack & Defense Playbook」にある各章の概要を説明します。
'Azure AD Attack & Defense Playbook'作成の初期アイデアは、Thomas Naunheimから発案されました。最初のTeams通話は2020年秋頃で、Thomasがアイデアを発表し、すぐに採用されました。
最初の章は「Password Spray」攻撃に関するもので、Entra ID Protection（旧Azure AD Identity Protection）の検出メカニズムに重点を置き、「パスワードスプレー」タイプの攻撃を検出しました。最初の章を通じて、研究の複雑さとさまざまな角度から、研究を完成させるまでの期間が予想よりも大幅に長くなる可能性があることを学びました。あらゆるプロジェクト作業と同様に、スコープ設定は極めて重要です。
最新の章では、Joosua Santasalo、Fabian Bader、Christopher Brummなどのコミュニティメンバーがスパーリングパートナーおよびレビュアーとしてプロジェクトに参加していただける幸運に恵まれました。
MITRE ATT&CK Framework は、敵対者の行動に対する戦術・技法・手順（TTP）のマッピングや、世界中の組織における防御のエミュレーションに広く使用されています。このプレイブックでは、すべての章でMITRE ATT&CKフレームワークv11を活用し、攻撃シナリオにTechnics、Tactics & Procedures（TTP）をマッピングしています。これにより、Blue Teamsが対応するシナリオに対する防御を構築するのに役立ちます。
各章には、特定の攻撃シナリオに基づく複数の検出ルールがあります。プレイブックには多数の検出ルールがあるため、すべての攻撃シナリオをTTPにマッピングした可視化を作成することにしました。また、各章に、対応する攻撃シナリオの可視化があることにも注意してください。
Microsoftセキュリティ製品（Microsoft Defender XDR、Microsoft Sentinel、Azure Entra ID Connect、Microsoft Defender for Cloud）の関連する検出機能は、攻撃シナリオの検出パートで説明します。プレイブック用に開発されたMicrosoft Sentinel向けカスタムルールテンプレートもTTPにマッピングされています。検出ルールは、Microsoft Sentinelルールテンプレート（デプロイ準備済み）JSON（ARM Template）形式でこちらから入手できます。
補足: 既存のTTPマッピングはMicrosoft SentinelルールテンプレートとMicrosoft 365インシデント相関から使用しています。一部の検出は完全なMITRE ATT&CKカバレッジを提供しておらず、この可視化には含まれていません。
通常、1つの章には約1〜2か月のカレンダー時間がかかるため、4つの章と付録をまとめるのはかなりの労力でした。過去2年間に、次のシナリオについて研究を行いました:
「パスワードスプレー攻撃とは、共通のパスワードを使用して複数のユーザー名を統一的かつブルートフォースの方法で攻撃し、不正アクセスを得ようとするものです。」
この章は2020年11月に最初に作成され、2021年11月にMicrosoft Ignite 2021の最新セキュリティ製品アップデートを含むよう更新されました。
この章には、パスワードスプレータイプの攻撃をシミュレートするための攻撃の簡単な説明と使用するツールが含まれています。検出パートでは、Microsoft SentinelやDefender for Cloud Appsなど、複数のMicrosoftセキュリティソリューションが使用されています。
補足として、オンプレミス環境とADFSに関する考慮事項もあります（まだ使用されている場合）。
「不正な同意付与攻撃では、攻撃者がAzure登録アプリケーションを作成し、連絡先情報、電子メール、ドキュメントなどのデータへのアクセスを要求します。次に、攻撃者はフィッシング攻撃または信頼できるWebサイトへの不正コードの注入を通じて、エンドユーザーをだましてそのアプリケーションのデータアクセスへの同意を付与させます。不正なアプリケーションが同意を得た後、組織アカウントを必要とせずにデータへのアカウントレベルのアクセス権を持ちます。
侵害されたアカウントのパスワードリセットやアカウントへの多要素認証（MFA）の要求などの通常の修復手順は、サードパーティアプリケーションであり組織の外部にあるため、このタイプの攻撃には効果がありません。これらの攻撃は、情報を呼び出しているエンティティが人間ではなく自動化であると想定する対話モデルを利用しています。」
この章には、攻撃の説明と、Entra ID同意フレームワーク周辺のアクティビティを保護および監視することが重要である理由の説明が含まれています。検出の章では、次のソリューションを使用しました:
このトピックは広大で複雑なため、緩和パートには、環境内の攻撃対象領域を減らす方法に関する手順と詳細が含まれています。
次の2つの攻撃シナリオでは、Azure DevOps（ADO）のリリースパイプラインの一部としての特権サービスプリンシパルと、監査における（潜在的な）可視性の制限に焦点を当てています。
ADOは大きなトピックであり、この章では前述のシナリオのみに範囲を限定しています。ここでも同じ流れに従います。
この章に取り組んだ際、検出技術に多くの時間を費やしました。これは主にADO監査ログのスキーマのせいで複雑でした。それでも、努力は報われ、定義した目標を達成し、Microsoft Sentinelで攻撃を検出することができました。
この章には、緩和の章でAzure DevOps環境をセキュリティ保護する方法に関する詳細情報が含まれています。
この文書では、主に次のシナリオに焦点を当てています:
対象外となるのは、AADCサーバーからActive Directory方向への特権昇格および攻撃パスです（Azure AD DSコネクタアカウントの悪用を含む）。
2022年3月14日に公開された最新の章は、Microsoft Entra Connect同期サービスアカウントの悪用に関するものです。正確には、AAD ConnectアカウントはAzure AD側に対してアクションを実行する責任があります。
このトピックと攻撃シナリオは研究作業にとって非常に興味深く、過去にMicrosoft Entra Connectで数多く作業してきたにもかかわらず、この2か月間で多くのことを学んだことを認めざるを得ません。以前は気づかなかった興味深い発見もいくつかありました。
ここまで読んでいただいたなら、研究作業中に作成したMicrosoft Sentinel用のKQLクエリを確認することをお勧めします。
MicrosoftはWindows 11を導入し、Trusted Platform Module（TPM）チップの使用を必須としました。これにより、クラウドベースの認証シナリオの保護レイヤーを含む、Windows 11 OSのセキュリティ機能の利用能力が大幅に向上しました。Primary Refresh Token（PRT）およびその他の関連キーは、Windows 11のTPMだけでなく、Windows 10およびWindows Server 2016以降のバージョンでも適切に保護できます。この点を考慮し、この文書では主に次のシナリオに焦点を当てています。
Entra ID Security Config Analyzerの目的は、選択したMicrosoft Graph APIエンドポイントからEntra IDのセキュリティ構成を取得し、そのデータをLog Analyticsに取り込むソリューションを提供することです。Azure Workbookはデータ可視化に使用され、Microsoft Sentinelは重要な構成変更が検出されたときにアラート/インシデントを作成するために使用できます。
次の図は、EIDSCAソリューションのアーキテクチャ、使用されるソリューション、データフローを示しています。
EIDSCAをMicrosoft Sentinel環境の一部として統合するためのリファレンスアーキテクチャ。データはSentinelと同じワークスペースに取り込まれます。 専用、運用、または既存のSentinelワークスペースへの統合が必要かどうかは、実装と設計によって異なります。
EIDSCAコントロールはMaesterでも使用されています。詳細は、Maesterドキュメントを参照してください。
さまざまなトークンはクラウド認証において重要な役割を果たします。そのため、その仕組みと、悪意のある者が入手した場合にどのように悪用されるかを理解することが重要です。これを理解することで、アイデンティティ攻撃に対する保護を構築するのに役立ちます。
トークンの盗難は、攻撃者がトークンにアクセスして侵害したときに発生します。一度盗まれると、攻撃者は盗んだトークンをリプレイして侵害されたアカウントにアクセスできます。AiTMシナリオでは、MFAクレームがすでにトークンに含まれており認証要件が満たされているため、攻撃者はMFA要件をバイパスできます。したがって、攻撃者は環境へのアクセスを得ます。このシナリオ、検出、および緩和については、この文書の後半で詳しく説明します。
Entra IDセキュリティトークンの詳細については、次のMicrosoft Learnリソースを参照してください。
Entra ID Attack & Defense Playbookの章「Replay of Primary Refresh (PRT) and other issued tokens from an Azure AD joined device」では、PRT、アクセストークン、リフレッシュトークンのリプレイについて解説しています。
この章では、攻撃者が被害者のセッションCookieを傍受し、後でそれをリプレイしてサインインサービスにアクセスするAdversary-in-the-Middle（AiTM）タイプの攻撃に焦点を当てています。
サイバー犯罪者は現在、多要素認証（MFA）保護を大規模にバイパスするためにAiTMフィッシング技術を使用しています。これらの高度な技術は、2021年以降にいくつかのサービス提供を生み出したPhishing-as-a-service（PhaaS）サイバー犯罪経済モデルを通じて民主化され、増加しています。
現在、AiTM対応のPhaaSプラットフォームの数は2023年から2024年にかけて成長を続けており、既存のサービスが自社プラットフォームにAiTM機能を追加し、新しく作成されたサービスがAiTMフィッシング技術をネイティブに組み込んでいます。従来の資格情報フィッシングの形式は依然として存在しますが、AiTMフィッシング攻撃の数はこの機能を持たない攻撃の数を上回っています。
AiTMフィッシングの最終的な目的は、ユーザーの資格情報とセッションCookieを盗むことです。ブラウザは、ユーザーが繰り返し認証を受けずにサービスにアクセスできるように、セッションCookieを保存します。AiTMフィッシングは、従来のMFA保護をバイパスするためにセッションCookieと資格情報を標的にします。
PhaaSの詳細情報:
最新のWebサービスは、ユーザーが認証に成功した後、訪問する新しいページごとに認証する必要がないように、ユーザーとのセッションを実装しています。このセッション機能は、最初の認証後に認証サービスが発行するセッションCookieによって有効になります。セッションCookieは、ユーザーが認証済みであり、Webサイト上でアクティブなセッションを維持していることをWebサーバーに証明する役割を果たします。
AiTMフィッシング攻撃では、攻撃者は対象ユーザーのセッションCookieを傍受し、後でそれを再生してサインインサービスにアクセスします。CookieはMFAチェックがすでに通過済みであることを証明する（トークンに含まれるクレーム）ため、MFA要件を満たし、攻撃者はMFA保護を回避して侵害されたユーザーアカウントへのアクセスを取得できます。
リバースプロキシによるAiTMフィッシングでは、プロキシはユーザーと、ユーザーが訪問したい正規のWebサイトまたはアプリケーション（MicrosoftサインインポータルやLinkedInなど）の間に配置されます。リバースプロキシはユーザーからのリクエストを実際のサービスに転送し、レスポンスを傍受します。このような構成により、攻撃者は対象のパスワードと、Webサイトとの進行中の認証済みセッションを証明するセッションCookieを盗み取り、傍受することが可能になります。
攻撃者の間で人気のあるフィッシングキットには、EvilGinx、Modlishka、Muraena、"Office 365"（EvilProxy）などがあります。これらのフィッシングキットにより、攻撃者はリバースプロキシサーバーを使用してAiTMフィッシング攻撃を実行できます。
補足: 多くのキャンペーンでは、Entra IDログの対象アプリケーションはOfficeHomeになっています。
リバースプロキシによるAiTMフィッシング攻撃の図（初期図はMicrosoft Defender XDR Threat Intelligenceレポートからの引用）。
もう1つのAiTM手法は「同期リレーによるAiTMフィッシング」と呼ばれます。この種の攻撃では、従来のフィッシング攻撃と同様に、サインインページのコピーまたは偽装ページが対象者に提示されます。ユーザーがこのページに資格情報を入力すると、資格情報は、管理パネルを含むフィッシングキットインスタンスがインストールされた攻撃者制御のサーバーに保存されます。基本的に、サインイン資格情報、2要素認証（MFA）コード、セッションCookieを含むユーザーの入力が盗まれることを意味します。
リレーサーバーは通常、開発の背後にいるアクターグループ、およびPhaaSプラットフォームの責任ある利害関係者によって提供・管理されています。この種のグループの一例として、Microsoft Threat Intelligenceレポートによると、Greatness PhaaSプラットフォームの背後にいるStorm-1295が挙げられます。
同期リレーによるAiTMフィッシングの図（初期図はMicrosoft Defender XDR Threat Intelligenceレポートからの引用）。
更新または新規コンテンツ（プルリクエスト）： 既に述べたように、私たちはEntraコミュニティによって推進される生きたドキュメントを望んでいます！ あなたの結果と洞察をこのプロジェクトの一部として共有してください！ プルリクエストを送信して、あなたのコンテンツをこのプロジェクトに追加してください。
問題/古いコンテンツ： 保護機能やツールは絶えず変化しています。古いコンテンツを更新する（プルリクエストの一部として）か、指摘するためのイシューを作成してください。
レビュアー： 公開前に既存または新しいコンテンツをレビューまたは議論したい専門家も募集しています！
フィードバック： コミュニティにとって興味深い攻撃/防御シナリオを提案してください。それらをバックログとアイデアコレクションに追加します！
これはコミュニティ主導のプロジェクトであり、公式のソリューションや製品ではありません。コードまたはその他のクエリサンプルは、明示または黙示を問わず、いかなる種類の保証もなく「現状のまま」提供されます。これには、商品性および/または特定目的への適合性の黙示の保証が含まれますが、これらに限定されません。このサンプルは、いかなるサポートプログラムやサービスの対象でもありません。 私たちは、商品性または特定目的への適合性の黙示の保証を含め、すべての黙示の保証をさらに否認します。サンプルおよびドキュメントの使用またはパフォーマンスから生じるすべてのリスクは、お客様に帰属します。いかなる場合も、当社、その著者、またはスクリプトの作成、制作、配布に関与したその他の者は、サンプルまたはドキュメントの使用または使用不能から生じるいかなる損害（事業利益の損失、事業の中断、事業情報の喪失、その他の金銭的損失を含みますがこれらに限定されません）についても、たとえMicrosoftがそのような損害の可能性について通知を受けていたとしても、責任を負いません。
 Sami Lamppu 💬 📖 |  Thomas Naunheim 💬 📖 |
 Joosua Santasalo 💬 📖 |  Markus Pitkäranta 💬 📖 |  Christopher Brumm 💬 📖 |  Fabian Bader 💬 📖 |  Nestori Syynimaa 💬 📖 |  Robbe Van den Daele 💬 📖 |
