システムの ID 侵害からの復旧

  • [アーティクル]

この記事では、ランサムウェア攻撃のときに発生する可能性のある組織に対する体系的 ID 侵害攻撃からの回復に関する Microsoft のリソースと推奨事項について説明します。

この記事の内容は、Microsoft インシデント対応チーム (旧称 DART/CRSP) によって提供されるガイダンスに基づいています。このチームは、侵害に対処し、お客様がサイバー回復力を持つように支援します。 Microsoft インシデント対応チームからの詳細なガイダンスについては、Microsoft のセキュリティ ブログ シリーズを参照してください。

多くの組織は、ID およびアクセス管理のセキュリティを強化するために、クラウドベースのアプローチに移行しました。 しかしながら、組織は、オンプレミスのシステムを保持して、さまざまなハイブリッド アーキテクチャの方法を使用することもあります。 この記事では、体系的 ID 攻撃がクラウド システム、オンプレミス システム、ハイブリッド システムに影響することを認識し、それらすべての環境に関する推奨事項および参照情報を提供します。

重要

この情報は現状のまま提供され、一般化されたガイダンスとなります。IT 環境およびテナントへのこのガイダンスの適用方法を最終的に決定するには、独自の環境とニーズを考慮する必要があります。これを判断する最適な立場にいるのはそれぞれの顧客です。

体系的 ID 侵害について

組織に対する体系的 ID 侵害攻撃が発生するのは、攻撃者が組織の ID インフラストラクチャの管理に足場を得たときです。

これが組織で発生すると、攻撃者と競い合って、さらなる被害を受ける前に環境をセキュリティで保護することになります。

  • 環境の ID インフラストラクチャの管理制御を得た攻撃者は、その制御を利用して、その環境内の ID および ID のアクセス許可を作成、変更、または削除できます。

    オンプレミスの侵害で、信頼できる SAML トークン署名証明書が HSMに格納されて "いない" 場合、その信頼できる SAML トークン署名証明書に対するアクセスもその攻撃に含まれます。

  • 攻撃者は、証明書を使用して SAML トークンを偽造し、組織の既存のユーザーやアカウントを偽装することができます。アカウントの資格情報へのアクセス権は必要なく、痕跡を残すこともありません。

  • また、高い権限が与えられているアカウントのアクセス権を使用すると、既存のアプリケーションに攻撃者が管理する資格情報を追加することもできます。したがって、攻撃者はそのようなアクセス許可を使用して、検出されることなくシステムにアクセスできるようになります(API を呼び出すなど)。

攻撃に対応する

体系的 ID 侵害への対応には、次の図と表に示す手順を含める必要があります。

ID 侵害から回復する手順。

手順 説明
セキュリティで保護された通信を確立する 体系的 ID 侵害を経験している組織は、すべての通信が影響を受けていると想定する必要があります。 どのような回復処置を行うとしても事前に、調査および対応の取り組みにとって重要なチームのメンバーが安全に通信できるようにする必要があります。

"通信をセキュリティで保護することを必ず最初の手順として行う必要があります。そうすることで、攻撃者の知識がなくても先に進むことができます。 "
環境を調査する コア調査チームについて通信をセキュリティで保護した後で、初期アクセス ポイントと永続化手法を探し始めることができます。 侵害の兆候を特定してから、初期アクセス ポイントと永続化を探します。 同時に、回復への取り組みの中で、継続的監視操作の確立を開始します。
セキュリティ体制を改善する システム セキュリティを強化するためのベスト プラクティスの推奨事項に従って、セキュリティの機能を有効にします。

時間の経過に伴って、セキュリティ環境が変化する際も、継続的監視の取り組みを必ず続けます。
制御を回復して維持する 環境の管理制御を攻撃者から取り戻す必要があります。 制御を取り戻して、システムのセキュリティ体制を更新した後で、可能性のあるすべての永続化手法および新しい初期アクセス悪用を修復またはブロックしてください。

セキュリティで保護された通信を確立する

対応を開始する前に、攻撃者から盗聴されることなく安全に通信できることを確認する必要があります。 インシデントに関係したすべての通信を確実に分離することで、攻撃者は調査に気付かず、対応処置によって不意打ちされます。

次に例を示します。

  1. 最初の 1 対 1 およびグループの通信では、PSTN 通話、企業インフラストラクチャに接続されていない会議ブリッジ、およびエンドツーエンドで暗号化されたメッセージング ソリューションを使用することをお勧めします。

    セキュリティで保護されたチャネルで検証されない限り、これらのフレームワークの外部にある通信は、侵害された信頼できないものとして扱う必要があります。

  2. このような最初の会話の後で、組織の運用テナントから分離された、まったく新しい Microsoft 365 テナントを作成することができます。 対応に参加する必要がある主要な担当者に対してのみ、アカウントを作成します。

新しい Microsoft 365 テナントを作成する場合は、特に管理者アカウントと権限について、テナントに関するすべてのベスト プラクティスに従ってください。 外部のアプリケーションやベンダーを信頼しないように、管理者権限を制限します。

重要

新しいテナントについて、侵害された可能性がある既存の電子メール アカウントでは通信しないようにします。

詳細については、「Microsoft 365 を安全に使用するためのベスト プラクティス」を参照してください。

侵害の兆候を特定する

お客様には、Microsoft およびすべてのパートナーの両方を含むシステム プロバイダーからの更新プログラムに従い、提供される新しい検出と保護を実装し、公開された侵害インシデント (IOC) を特定することをお勧めします。

次の Microsoft セキュリティ製品の更新プログラムを確認し、推奨される変更をすべて実装します。

新しい更新プログラムを実装すると、以前の攻撃行動を特定したり、システムに対する今後の攻撃行動を防いだりするのに役立ちます。 IOC のリストは完全ではなく、調査の継続に伴って充実する可能性があることに注意してください。

したがって、次の処置も行うことをお勧めします。

詳細については、Microsoft のセキュリティに関するドキュメントを参照してください。

環境を調査する

インシデントの対応者と主要担当者が共同作業を行うための安全な場所を確保したら、侵害された環境の調査を開始できます。

すべての異常動作の本質を突き止めることと、攻撃者のさらなるアクティビティを止める迅速な処置を取ることを、バランスよく行う必要があります。 修復を成功させるには、攻撃者が使用した最初の侵入方法と永続化方法について、この時点で可能な限り理解しておく必要があります。 調査中に見逃がした永続化方法があると、攻撃者が継続的にアクセスでき、再侵害の可能性が生じます。

この時点で、リスク分析を実行して、処置に優先順位を付けることをお勧めします。 詳細については、次を参照してください。

Microsoft のセキュリティ サービスでは、詳細な調査のために豊富なリソースが提供されます。 以下のセクションでは、特に推奨される処置について説明します。

Note

一覧で示すログ ソースの 1 つ以上が現在のセキュリティ プログラムに含まれていないことがわかった場合は、検出と今後のログ レビューを有効にするために、できるだけ早く構成することをお勧めします。

将来的に組織の調査目標に合うように、ログのリテンション期間を構成してください。 法律、規制、または保険の目的で必要に応じて証拠を保持します。

クラウド環境のログを調査して確認する

クラウド環境のログを調査して確認し、疑わしい操作や攻撃者による侵害の兆候を確認します。 たとえば、次のログを確認します。

エンドポイント監査ログを確認する

エンドポイント監査ログで、オンプレミスの変更を確認します (たとえば次の種類の操作)。

  • グループ メンバーシップの変更
  • ユーザー アカウントの新規作成
  • Active Directory 内の委任

特に、他の侵害やアクティビティの典型的な兆候と共に発生したこれらの変更について注意してください。

環境内の管理者権限を確認する

クラウド環境とオンプレミス環境の両方で管理者権限を確認します。 次に例を示します。

環境 説明
すべてのクラウド環境 - クラウド内の特権アクセス権を確認し、不要なアクセス許可があれば削除します
- Privileged Identity Management (PIM) を実装します
- 強化中に管理アクセスを制限する条件付きアクセス ポリシーを設定します
すべてのオンプレミス環境 - オンプレミスの特権アクセスを確認し、不要なアクセス許可を削除します
- 組み込みグループのメンバーシップを減らします
- Active Directory の委任を確認します
- 階層 0 環境を強化し、階層 0 の資産にアクセスできるユーザーを制限します
すべてのエンタープライズ アプリケーション 次の操作を許可する、委任されたアクセス許可および同意付与を確認します。

- 特権ユーザーおよびロールの変更
- すべてのメールボックスの読み取りまたはアクセス
- 他のユーザーの代理としての電子メールの送信または転送
- OneDrive または SharePoint サイトのすべてのコンテンツへのアクセス
- ディレクトリの読み取り/書き込みができるサービス プリンシパルの追加
Microsoft 365 環境 次を含む、Microsoft 365 環境のアクセスと構成の設定を確認します。
- SharePoint Online の共有
- Microsoft Teams
- Power Apps
- Microsoft OneDrive for Business
環境内のユーザー アカウントを確認する - 不要になったゲスト ユーザー アカウントを確認して削除します。
- 委任、メールボックス フォルダーのアクセス許可、ActiveSync モバイル デバイス登録、受信トレイ規則、Outlook on the Web のオプションについて、電子メールの構成を確認します。
- アプリケーション偽装の権限を確認し、レガシ認証の使用をできるだけ減らします。
- MFA が適用されていることと、すべてのユーザーについて MFA とセルフサービス パスワード リセット (SSPR) 両方の連絡先情報が正しいことを検証します。

継続的な監視を確立する

攻撃者の行動の検出には、いくつかの方法が含まれます。また、組織が攻撃に対応するために使用できるセキュリティ ツールによって異なります。

たとえば、Microsoft のセキュリティ サービスには、以下のセクションで説明するように、攻撃に関連する特定のリソースとガイダンスが用意されている場合があります。

重要

調査によって、管理権限がシステムの侵害によって盗まれ、そのために組織のグローバル管理者アカウントまたは信頼できる SAML トークン署名証明書 (あるいは両方) へのアクセスが与えられたという証拠が見つかった場合は、管理制御を修復して保持する処置の実行をお勧めします。

Microsoft Sentinel を使用して監視する

Microsoft Sentinel には、調査に役立つ多くの組み込みリソース (環境内の関連する領域での攻撃を検出するのに役立つハンティング ブックや分析ルールなど) があります。

Microsoft Sentinel のコンテンツ ハブを使って、環境内の他のサービスからコンテンツをストリーミングする拡張セキュリティ ソリューションとデータ コネクタをインストールします。 詳細については、次を参照してください。

Microsoft Defender for IoT を使用した監視

環境に運用テクノロジ (OT) リソースも含まれている場合は、セキュリティより運用上の課題を優先する特殊なプロトコルを使用するデバイスが存在している可能性があります。

そのようなデバイス (特に、従来のセキュリティ監視システムによって保護されないもの) を監視してセキュリティ保護するには、Microsoft Defender for IoT をデプロイします。 環境内の特定の関心ポイントに Defender for IoT のネットワーク センサーをインストールし、エージェントレス監視と動的脅威インテリジェンスを使って、進行中のネットワーク アクティビティで脅威を検出します。

詳しくは、「OT ネットワーク セキュリティの監視を始める」をご覧ください。

Microsoft Defender XDR を使用した監視

Microsoft Defender XDR for Endpoint および Microsoft Defender ウイルス対策で対象の攻撃に関連する具体的なガイダンスを確認することをお勧めします。

Microsoft セキュリティ センターで、検出、ハンティング クエリ、脅威分析レポートのその他の例 (Microsoft Defender XDR、Microsoft Defender XDR for Identity、Microsoft Defender for Cloud Apps など) を確認します。 確実にカバーするためには、すべてのドメイン コントローラーに加えて ADFS サーバーに Microsoft Defender for Identity エージェントをインストールしてください。

詳細については、次を参照してください。

Microsoft Entra ID を使用した監視

Microsoft Entra サインイン ログによって、多要素認証が正しく使用されているかどうかがわかります。 Azure portal の Microsoft Entra 領域からサインイン ログに直接アクセスするには、Get-MgBetaAuditLogSignIn コマンドレットを使用するか、Microsoft Sentinel の [ログ] 領域で表示します。

たとえば、 [MFA results](MFA 結果) フィールドの値が [MFA requirement satisfied by claim in the token](トークンの要求によって MFA 要件が満たされる) の場合について、結果を検索またはフィルターします。 組織が ADFS を使用しているとき、ログに記録された要求が ADFS 構成に含まれない場合、それらの要求が攻撃者のアクティビティを示している可能性があります。

結果をさらに検索またはフィルター処理して、余分なノイズを除外します。 たとえば、フェデレーション ドメインからの結果のみを含めたい場合があります。 疑わしいサインインを見つけた場合は、IP アドレスやユーザー アカウントなどに基づいてさらにドリルダウンします。

次の表では、調査で Microsoft Entra のログを使用するその他の方法について説明します:

メソッド 説明
危険なサインイン イベントを分析する Microsoft Entra ID および Identity Protection プラットフォームでは、攻撃者が生成した SAML トークンの使用に関連するリスク イベントが生成される可能性があります。

このようなイベントには、 [unfamiliar properties](見慣れないプロパティ) 、 [匿名 IP アドレス] 、 [あり得ない移動] などのラベルが付けられます。

管理者特権を持つアカウントに関連付けられているすべてのリスク イベント (自動的に却下または修復された可能性があるものも含む) を詳しく分析することをお勧めします。 たとえば、ユーザーの MFA が成功したことにより、リスク イベントや匿名 IP アドレスが自動的に修復される場合があります。

すべての認証イベントが Microsoft Entra ID に表示されるように、ADFS Connect Health を使用してください。
ドメイン認証プロパティを検出する 攻撃者がドメイン認証ポリシーを操作しようとすると、Microsoft Entra 監査ログに記録され、統合監査ログに反映されます。

統合監査ログ、Microsoft Entra 監査ログ、および SIEM 環境で、[ドメイン認証の設定] によって関連付けられたイベントを確認し、一覧表示されるすべてのアクティビティが予期され計画されたものであることを確かめます。
OAuth アプリケーションの資格情報を検出する 特権アカウントの制御を得た攻撃者は、組織内のユーザーの電子メールにアクセスできるアプリケーションを探し、攻撃者が管理する資格情報をそのアプリケーションに追加します。

たとえば、攻撃者の行動と一致する次のいずれかのアクティビティを探すことをお勧めします。
- サービス プリンシパル資格情報の追加または更新
- アプリケーションの証明書とシークレットの更新
- アプリ ロールの割り当て許可のユーザーへの追加
- Oauth2PermissionGrant の追加
アプリケーションによる電子メール アクセスを検出する 環境内のアプリケーションによる電子メールへのアクセスを探します。 たとえば、Microsoft Purview 監査 (Premium) 機能を使用して、侵害されたアカウントを調査します。
サービス プリンシパルへの非対話型サインインを検出する Microsoft Entra サインイン レポートによって、サービス プリンシパルの資格情報を使用した非対話型サインインの詳細が提供されます。 たとえば、サインイン レポートを使用して、調査にとって貴重なデータ (攻撃者が電子メール アプリケーションにアクセスするために使用した IP アドレスなど) を見つけることができます。

セキュリティ体制を改善する

システムでセキュリティ イベントが発生した場合は、現在のセキュリティ戦略と優先順位について熟考することをお勧めします。

インシデント レスポンダーは、組織が新しい脅威に直面したとき、優先すべき投資に関して推奨事項を提供するように求められることがよくあります。

この記事に記載されている推奨事項に加え、この攻撃者によって悪用後に使用される手法に特に対応すべき分野と、それを許した一般的なセキュリティ体制の間隙を優先することを検討してください。

次のセクションでは、一般的なセキュリティ体制と ID セキュリティ体制の両方を改善するための推奨事項を示します。

一般的なセキュリティ体制を改善する

一般的なセキュリティ体制を確保するには、次の処置をお勧めします。

ID セキュリティ体制を改善する

ID 関連のセキュリティ体制を確保するには、次の処置をお勧めします。

  • Microsoft の「ID インフラストラクチャをセキュリティ保護する 5 つのステップ 」を確認し、ご使用の ID アーキテクチャに適した手順を優先します。

  • 認証ポリシーについて Microsoft Entra のセキュリティの既定値群を検討します。

  • 組織でのレガシ認証の使用を排除します (システムまたはアプリケーションで必要な場合でも)。 詳細については、「条件付きアクセスを使用して Microsoft Entra ID へのレガシ認証をブロックする」を参照してください。

  • ADFS インフラストラクチャおよび AD Connect インフラストラクチャを階層 0 資産として扱います.

  • ADFS サービスの実行に使用されるアカウントを含め、システムへのローカル管理アクセスを制限します。

    ADFS を実行するアカウントに必要な最小限の特権は、 [サービスとしてログオン] ユーザー権利割り当てです。

  • リモート デスクトップの Windows ファイアウォール ポリシーを使用して、限定されたユーザーと限定された IP アドレス範囲に管理アクセスを制限します。

    階層 0 のジャンプ ボックスまたは同等のシステムを設定することをお勧めします。

  • 環境内の任意の場所からシステムへのすべてのインバウンド SMB アクセスをブロックします。 詳細については、「境界を越えて: Windows で SMB トラフィックをセキュリティ保護する方法」を参照してください。 また、監視履歴およびプロアクティブな監視のために Windows ファイアウォール ログを SIEM にストリーミングすることをお勧めします。

  • サービス アカウントを使用しており、それが環境でサポートされている場合は、サービス アカウントからグループ管理サービス アカウント (gMSA) に移行します。 gMSA に移行できない場合は、サービス アカウントのパスワードを複雑なパスワードにローテーションします。

  • ADFS システムで詳細ログが有効になっていることを確認します。

管理制御を修復して保持する

調査によって、組織のクラウド環境またはオンプレミス環境で攻撃者が管理制御を持っていることが明らかになった場合は、攻撃者が永続的でないことが確認できる方法で、制御を取り戻す必要があります。

このセクションでは、管理制御の回復計画を作成するときに考慮する必要がある方法と手順について説明します。

重要

組織で必要な正確な手順は、調査で検出された永続性がどのようなものか、および調査が完了して考えられるすべての侵入方法と永続化方法が明らかになったということにどれほど自信があるかによって異なります。

行うすべての処置は、クリーン ソースから構築された、信頼できるデバイスから実行してください。 たとえば、新しい特権アクセス ワークステーションを使用します。

次のセクションには、管理制御を修復して保持するための次の種類の推奨事項が含まれます。

  • 現在のサーバーでの信頼の削除
  • SAML トークン署名証明書のローテーション、または必要に応じた ADFS サーバーの置換
  • クラウド環境またはオンプレミス環境の固有の修復アクティビティ

現在のサーバーでの信頼を削除する

トークン署名証明書またはフェデレーション信頼の制御が組織から失われた場合、最も確実な方法は、信頼を削除し、オンプレミスの修復中にクラウドマスター ID に切り替える方法です。

信頼を削除し、クラウドマスター ID に切り替えるには、慎重な計画と、ID の分離による事業運営への影響についての深い理解が必要です。 詳細については、「オンプレミスの攻撃から Microsoft 365 を保護する」を参照してください。

SAML トークン署名証明書をローテーションする

組織が、オンプレミスの管理制御を取り戻す際に信頼を削除 "しない" と決めた場合は、オンプレミスの管理制御を取り戻して、攻撃者が署名証明書にアクセスできないようにした後で、SAML トークン署名証明書をローテーションする必要があります。

トークン署名証明書を 1 回ローテーションしても、まだ前のトークン署名証明書を使用できます。 前の証明書の動作を引き続き許可するのは、通常の証明書ローテーションに組み込まれた機能です。これにより、証明書の有効期限が切れる前に、証明書利用者の信頼を更新するための猶予期間が組織に与えられます。

攻撃があった場合は、攻撃者がまったくアクセス権を保持できないようにする必要があります。 攻撃者がドメインのトークンを偽造する能力を持ち続けないようにします。

詳細については、以下を参照してください:

ADFS サーバーを置き換える

SAML トークン署名証明書のローテーションの代わりに、クリーン システムで ADFS サーバーを置き換えることにした場合は、既存の ADFS を環境から削除して新しいものを構築する必要があります。

詳細については、「構成の削除」をご覧ください。

クラウド修復アクティビティ

この記事で前に示した推奨事項に加え、クラウド環境に対しては次のアクティビティもお勧めします。

アクティビティ 説明
パスワードをリセットする すべてのブレークグラス アカウントのパスワードをリセットし、ブレークグラス アカウントの数を必要最小限に減らします。
特権アクセス アカウントを制限する 特権アクセス権を持つサービス アカウントとユーザー アカウントがクラウド専用アカウントであることを確認します。Microsoft Entra ID と同期またはフェデレーションされているオンプレミス アカウントは使用しないでください。
MFA を適用する テナント内のすべての管理者特権ユーザーに対して多要素認証 (MFA) を適用します。 テナント内のすべてのユーザーに MFA を適用にすることをお勧めします。
管理アクセス権を制限する Privileged Identity Management (PIM) および条件付きアクセスを実装して、管理アクセス権を制限します。

Microsoft 365 ユーザーの場合は、Privileged Access Management (PAM) を実装して、電子情報開示、グローバル管理者、アカウント管理など、機密性の高い機能へのアクセスを制限します。
委任されたアクセス許可と同意付与を確認/削減する 次のいずれかの機能を許可する、すべてのエンタープライズ アプリケーションの委任されたアクセス許可または同意付与を確認して削減します。

- 特権ユーザーとロールの変更
- 電子メールの読み取り、送信、またはすべてのメールボックスへのアクセス
- OneDrive、Teams、または SharePoint コンテンツへのアクセス
- ディレクトリの読み取り/書き込みができるサービス プリンシパルの追加
- アプリケーションのアクセス許可と委任されたアクセス

オンプレミスの修復アクティビティ

この記事で前に示した推奨事項に加え、オンプレミス環境に対しては次のアクティビティもお勧めします。

アクティビティ 説明
影響を受けたシステムを再構築する 攻撃者によって侵害されたことが調査の際に特定されたシステムを再構築します。
不要な管理者ユーザーを削除する ドメイン管理者、バックアップ オペレーター、およびエンタープライズ管理者のグループから不要なメンバーを削除します。 詳細については、「特権アクセスの保護」を参照してください。
特権アカウントのパスワードをリセットする 環境内のすべての特権アカウントのパスワードをリセットします。

注: 特権アカウントは、組み込みグループだけではありません。サーバー管理、ワークステーション管理、または環境内の他の領域へのアクセスを委任されたグループも該当します。
krbtgt アカウントをリセットする New-KrbtgtKeys スクリプトを使用して krbtgt アカウントを 2 回リセットします。

注: 読み取り専用ドメイン コントローラーを使用している場合は、読み取り/書き込みドメイン コントローラーと読み取り専用ドメイン コントローラーに対してスクリプトを別に実行する必要があります。
システムの再起動をスケジュールする 攻撃者によって作成された永続化メカニズムが存在しないか、システムに残っていないことを検証した後で、メモリ常駐マルウェアの削除に役立つようにシステムの再起動をスケジュールします。
DSRM パスワードをリセットする 各ドメイン コントローラーの DSRM (ディレクトリ サービス復元モード) パスワードを一意の複雑なパスワードにリセットします。

調査中に検出された永続化を修復またはブロックする

調査は反復的なプロセスです。異常を特定したら修復するという組織の要望と、修復によって攻撃者に検出を警戒させ、対応するための時間を与えるという可能性の間でバランスを取る必要があります。

たとえば、検出に気付いた攻撃者が、手法を変更したり、さらに多くの永続化を作成したりする可能性があります。

調査の初期の段階で特定した永続化手法はすべて必ず修復してください。

ユーザー アカウントとサービス アカウントのアクセスを修復する

上記で示した推奨処置の他に、ユーザー アカウントを修復して復元するために次の手順を検討することをお勧めします。

  • 信頼できるデバイスに基づいて条件付きアクセスを適用します。 可能であれば、組織の要件に合う "場所ベースの条件付きアクセス" を適用することをお勧めします。

  • 侵害された可能性があるすべてのユーザー アカウントについて、削除後にパスワードをリセットします。 また、ディレクトリ内のすべてのアカウントの資格情報をリセットするための中期計画も実装してください。

  • 資格情報のローテーションの直後に更新トークンを取り消します。

    詳細については、以下を参照してください:

次のステップ

  • 上部のナビゲーション バーで [ヘルプ] (?) ボタンを選択して、Microsoft Defender ポータル、Microsoft Purview コンプライアンス ポータル、Office 365 セキュリティ/コンプライアンス センターを含む Microsoft 製品内のヘルプを利用します。

  • デプロイの支援については、FastTrack に問い合わせてください

  • 製品サポート関連のニーズがある場合は、Microsoft サポート ケースを送信します。

    重要

    侵害されたと考えられ、インシデント対応による支援が必要な場合には、Sev A Microsoft サポート ケースを開きます。