体系的な ID 侵害からの回復に関するインシデント対応者へのアドバイス

Microsoft は、業界パートナーおよびセキュリティ コミュニティと共に、Solorigate 攻撃の範囲を調査し続けています。Microsoft の目標は、IOC を含む最新の脅威インテリジェンスを提供し、製品とソリューション全体でガイダンスを提供して、コミュニティが反撃し、インフラストラクチャを強化するのを支援することです。この前例のない規模の攻撃から回復し始めます。新しい情報が利用可能になり次第、この記事を更新します。

このブログでは、オンプレミスおよびクラウド環境でのこれまでのインシデント対応から得られた教訓を概説します。この最新のガイダンスは、Solorigate マルウェアによる侵害が疑われる資格情報の信頼できる ID を再確立しようとしているお客様を対象としています。

この記事は、Solorigate マルウェアの一部の被害者に見られるような、システム上の ID 侵害の疑いに組織が対応する際に考慮すべきテクニックについて、経験豊富なインシデント対応者にアドバイスを提供することを目的としています。 .ビジネスへの影響を最小限に抑えながら、組織のオンプレミス環境とクラウド環境で信頼を再確立するには、詳細な調査と永続化の潜在的な方法の理解が必要です。考えられるすべてのシナリオをカバーすることを意図したものではありませんが、このガイダンスは、同様の顧客の侵害に関する私たちの経験を要約することを目的としており、復旧の成功に役立つ新しい情報が得られた場合に更新されます。詳細については、この記事の最後で参照されているリソースを確認してください。この情報は現状のまま提供され、一般化されたガイダンスを構成します。このガイダンスをお客様の IT 環境およびテナントに適用する方法に関する最終的な決定は、お客様固有の環境とニーズを考慮する必要があり、各お客様が決定するのに最適な立場にあります。

このガイダンスで参照されているソロリゲートの調査は、発行時点で進行中であり、当社のチームはこれらの攻撃に対する最初の応答者として引き続き行動します。新しい情報が入手可能になり次第、マイクロソフト セキュリティ レスポンス センター (MSRC) ブログを通じて更新を行います。

侵入の概要

このMicrosoft ブログ投稿で説明されているように、この攻撃者の活動の特徴には、体系的な ID 侵害につながる可能性がある次の手法が含まれますが、これらに限定されません。

  • SolarWinds Orion 製品への悪意のあるコードによる侵入。これにより、攻撃者はネットワーク内に足場を築き、それを使用して昇格した資格情報を取得できます。 Microsoft Defender では、これらのファイルが検出されるようになりました。 Solorigate マルウェアの詳細な技術分析をお読みください。
  • 組織の信頼できる SAML トークン署名証明書へのアクセスを取得するために (オンプレミスの侵害によって取得された) 管理者権限を使用する侵入者。これにより、SAML トークンを偽造して、組織の既存のユーザーやアカウント (高度な特権を持つアカウントを含む) になりすますことができます。
  • 侵害されたトークン署名証明書で署名された SAML トークンを使用した異常なログイン。構成されているため、オンプレミスのリソース (ID システムまたはベンダーに関係なく) およびクラウド環境 (ベンダーに関係なく) に対して使用できます。証明書を信頼します。正当な証明書で署名されているため、組織は違法な SAML トークンの使用を見逃す可能性があります。
  • 高度な特権を持つアカウント (上記の手法またはその他の手段で取得) を使用して、不正な資格情報を既存のアプリケーション サービス プリンシパルに追加し、攻撃者がそのアプリケーションに割り当てられたアクセス許可で API を呼び出すことを可能にします。

対応目標の概要

体系的な ID 侵害を経験した組織は、信頼できる通信を再確立することによって回復を開始する必要があります。これにより、効果的なトリアージとビジネス オペレーションの回復の調整が可能になります。

多くの組織には、複雑な内部および外部の相互依存関係があります。組織内のコア ビジネス プロセスとアプリケーションは、環境内の信頼が再確立されるまで、復旧作業中に一時的に影響を受ける可能性があります。 Microsoft は、インシデント レスポンダーが、組織の回復に向けた最初のステップとして、組織の主要な担当者と安全な通信を確立することをお勧めします。調査の結果、攻撃者が組織のインフラストラクチャの下位レベルで、ID の侵害以外の手法 (ハードウェアやファームウェアへの攻撃など) を使用したことが判明した場合は、それらの脅威に対処して、再侵害のリスクを軽減する必要があります。

おおよその順序での応答目標:

  1. 調査および対応作業の要となる担当者の安全な通信を確立します。
  2. 復旧作業中の継続的な監視操作を確立しながら、永続性と初期アクセス ポイントについて環境を調査します。
  3. 環境の管理制御を取り戻して保持し、考えられる永続化手法と初期アクセスの悪用を修正またはブロックします。
  4. ベスト プラクティスの推奨事項に従ってセキュリティ機能を有効にすることで、体制を改善します。

インシデント対応担当者は、行動を起こす前にこのガイダンス全体を確認して理解することをお勧めします。これは、対応目標を達成するためにとられる行動の特定の順序は非常に状況に依存し、調査の結果 (および完全性) とビジネス上の制約に大きく依存するためです。特定の組織。次のセクションでは、上記の目的ごとに検討することをお勧めするインシデント対応手法について説明します。

安全な通信と生産性を確立する

応答を成功させるには、攻撃者があなたの通信を傍受することなく通信できる必要があります。現在のインフラストラクチャで通信のプライバシーが保証されるまでは、完全に分離された ID と通信リソースを使用して対応を調整し、攻撃者に調査のヒントを与える可能性のあるトピックについて話し合います。調査によってアクターの立ち退きが保証されるまでは、インシデントに関連するすべての通信を隔離して、修復アクションを実行するときに驚きの要素を持たせることを強くお勧めします。

  • 最初の 1 対 1 およびグループ通信は、電話 (PSTN) 通話、企業インフラストラクチャに接続されていない会議ブリッジ、およびエンドツーエンドの暗号化されたメッセージング ソリューションによって実現できます。
  • 多くの顧客が安全な生産性とコラボレーションを確立する方法の 1 つは、組織の運用テナントから完全に分離された新しい Office 365 テナントを作成し、必要な主要な担当者と、参加する必要があるインシデント対応ベンダーまたはパートナー専用のアカウントを作成することです。応答の。
    • このテナントを保護するためのベスト プラクティス、特にデフォルトでの管理者アカウントと権限に従ってください。新しいテナントは、管理者権限を制限し、外部のアプリケーションやベンダーとの信頼関係を持たないようにする必要があります。さらに支援が必要な場合、または Microsoft 365 の強化に関する情報が必要な場合は、こちらのガイダンスを確認してください。

環境を調査する

インシデント レスポンダーと主要担当者が安全に共同作業できる場所を確保したら、次のステップは、侵害が疑われる環境を調査することです。調査の成功は、すべての異常な動作の真相を突き止めて攻撃者の活動と持続の範囲を完全に把握することと、攻撃者による目的に対するさらなる活動を停止するために迅速に行動を起こすこととの間のバランスを取ることです。修復を成功させるには、侵入の初期方法と、攻撃者によって制御される持続メカニズムを可能な限り完全に理解する必要があります。永続化メカニズムが失われると、攻撃者によるアクセスが継続され、再侵害される可能性があります。

  • 以下を含む疑わしいアクションと攻撃者の IOC について、クラウド環境のログを調査および確認します。
    • 統合監査ログ (UAL)。
    • Azure Active Directory (Azure AD) のログ。
    • Active Directory ログ。
    • Exchange オンプレミス ログ。
    • VPN ログ。
    • エンジニアリング システムのロギング。
    • ウイルス対策とエンドポイント検出のログ。
  • 以下を含むがこれらに限定されないアクションについて、オンプレミスからの変更のエンドポイント監査ログを確認します。
    • グループ メンバーシップの変更。
    • 新しいユーザー アカウントの作成。
    • Active Directory 内の委任。
    • 侵害または活動の他の典型的な兆候とともに。
  • 環境の管理者権限を確認する
    • クラウドでの特権アクセスを確認し、不要なアクセス許可を削除します。 Privileged Identity Management (PIM) を実装します。条件付きアクセス ポリシーをセットアップして、強化中の管理アクセスを制限します。
    • オンプレミスの特権アクセスを確認し、不要なアクセス許可を削除します。組み込みグループのメンバーシップを削減し、Active Directory 委任を検証し、階層 0 環境を強化し、階層 0 資産にアクセスできるユーザーを制限します。
    • すべてのエンタープライズ アプリケーションで、許可されている委任されたアクセス許可と同意の付与を確認します (支援するサンプル スクリプト):
      • 特権ユーザーとロールの変更。
      • すべてのメールボックスの読み取りまたはアクセス。
      • 他のユーザーに代わって電子メールを送信または転送する。
      • すべての OneDrive または SharePoint サイトのコンテンツへのアクセス。
      • ディレクトリに読み書きできるサービス プリンシパルを追加します。
    • 次の Office 365 製品のアクセスと構成の設定を確認します。
      • SharePoint オンライン共有
      • チーム
      • PowerApps
      • OneDrive for Business
    • ユーザー アカウントを確認する
      • 不要になったゲスト ユーザーを確認して削除します。
      • Hawkなどを使用して電子メールの構成を確認します。
        • デリゲート
        • メールボックス フォルダーのアクセス許可
        • ActiveSync モバイル デバイスの登録
        • 受信トレイのルール
        • Outlook on the Web オプション
      • すべてのユーザーの MFA とセルフサービス パスワード リセット (SSPR) の両方の連絡先情報が正しいことを確認します。

上記のログ ソースの 1 つまたは複数が、組織が現在セキュリティ プログラムに含めていないデータ ソースであることがわかる場合があります。それらの一部、特にクラウドで使用可能なログは、構成されている場合にのみ使用できます。次のセクションの検出とログのフォレンジック レビューの両方を有効にするために、できるだけ早く構成することをお勧めします。組織の今後の調査目標をサポートし、法律、規制、または保険の目的で必要な場合は証拠を保持するように、ログの保持を構成してください。

継続的な監視を確立する

このキャンペーンに関連するアクティビティを検出する方法は多数あります。組織が攻撃者の行動を正確にどのように検出するかは、使用可能なセキュリティ ツール、またはそれに応じて展開することを選択したかによって異なります。マイクロソフトは、マイクロソフトが提供するコア セキュリティ製品およびサービスの一部の例を公開しており、この攻撃者に関連する新しい脅威インテリジェンスが特定されるたびに、これらのドキュメントを継続的に更新しています。他のベンダーの製品を使用している場合は、ベンダーの推奨事項を確認し、環境に類似の検出を独自に実装する必要がある場合は、以下の Microsoft ドキュメントを確認して検出手法を理解してください。

自分の環境で Azure Sentinel を使用している読者は、 SolarWinds の侵害後のハンティング ガイダンスを確認してください。

Microsoft Defender for Endpoint を使用している読者は、 こちらのガイダンスを確認し、 Microsoft Defender ウイルス対策のガイダンスを確認してください。

Azure Active Directory サインイン

適切な時間枠を選択し、CSV または JSON ファイルとしてレポートをダウンロードすることで、Azure Active Directory サインイン ブレードからこの情報を表示できます。注: このインターフェイスを介して、対話型および非対話型のサインイン レポートをダウンロードできます。結果をダウンロードしたら、「MFA 結果」フィールドで値「MFA 要件がトークン内のクレームによって満たされている」を探します。

次の例に示すように、Get-AzureADAuditSignInLogs コマンドレット ( 詳細はこちらを参照) を使用して結果をフィルター処理し、このフィールド値に一致するエントリのみを返すこともできます。

Get-AzureADAuditSignInLogs -All:$true -Filter "createdDateTime gt <開始日> and createdDateTime lt <終了日>" | where {$_.Status.AdditionalDetails -eq "トークン内のクレームによって満たされる MFA 要件"} |オブジェクトの選択 CreatedDateTime、IpAddress、UserAgent、ResourceDisplayName、CorrelationId、RequestId、UserPrincipalName -ExpandProperty Status

ADFS 環境が、MFA が満たされたという要求を送信するように構成されている場合、これは強力なシグナルではない可能性があります。ただし、ADFS を使用している多くの組織では、このクレームは構成ごとに含まれていません。そのような場合、この主張の存在は、攻撃者の活動の強力な指標になる可能性があります。フェデレーションされたドメインからの結果のみを表示するなど、信号対雑音比をさらに改善するために、where 句にフィルターまたは条件を追加することもできます。

疑わしいサインインが検出された場合は、識別された IP アドレス、識別されたユーザー アカウント、および/または観察された UserAgent 文字列やクライアント オペレーティング システムなどのその他の指標に基づいて、調査をさらに進めることができます。有力な指標となります。

危険なサインイン イベントの分析

場合によっては、Azure Active Directory とその Identity Protection プラットフォームが、攻撃者が生成した SAML トークンの使用に関連するリスク イベントを生成します。これらは、「なじみのないプロパティ」、「匿名の IP アドレス」、「不可能な旅行」、およびここで説明するその他のリスク イベントとして分類できます。

管理者権限を持つアカウントに関連するすべてのリスク イベントを詳細に分析します。これらのアクションの一部は自動的に行われるため、無視または修復されたイベントを分析することも重要です。たとえば、匿名 IP アドレスのリスク イベントは、ユーザーが MFA に合格したため、自動的に修復できます。

ドメイン認証プロパティの検出

攻撃者は、Azure Active Directory 監査ログに記録され、統合監査ログに反映されるドメイン認証ポリシーを操作しようとする可能性があります。グローバル管理者権限でアクセスした攻撃者は、フェデレーションおよび/または信頼されているドメインを変更できます。統合監査ログ、Azure AD 監査ログ、SIEM 環境のいずれかで、「ドメイン認証の設定」に関連付けられているイベントを確認します。すべての活動が予期され、計画されていたことを確認してください。

以下のサンプル コマンドは、ドメイン認証設定の操作に関連する統合監査ログのエントリを返します。

Search-UnifiedAuditLog -StartDate <開始日> -EndDate <終了日> -ResultSize 5000 -Operations "ドメイン認証の設定"

OAuth アプリケーションに関連付けられたサービス プリンシパルへの資格情報の検出

攻撃者が十分な権限を持つ資格情報を制御した場合、攻撃パターンには、組織内の任意のユーザーの電子メールにアクセスする権限が付与されているアプリケーションを見つけ、攻撃者が制御する資格情報をそのアプリケーションに追加することが含まれます。場合によっては、攻撃者はこれらのアプリケーションを変更して、組織内のすべての電子メールへのアクセスなどの追加の権限を付与しています。

以下は、攻撃者の動作と一致する操作です。

  • サービス プリンシパルの資格情報を追加します。
  • アプリケーションの証明書と秘密の管理を更新します。
  • サービス プリンシパルを更新します。
  • アプリ ロールの割り当てをサービス プリンシパルに追加します。
  • ユーザーにアプリ ロールの割り当て付与を追加します。
  • OAuth2PermissionGrant を追加します。

アプリケーションによるメールアクセスの検出

アプリケーションによる電子メールへのアクセスの検出は、Office 365 の高度な監査機能を使用して実現できます。 Office 365 内のメッセージへのアクセスは、MailItemsAccessed 機能によって監査されます。

MailItemsAccessed の操作について、統合監査ログのイベントを分析します。

サービス プリンシパルへの非対話型サインインの検出

サインイン レポートの Azure Active Directory は、サービス プリンシパルに発行された資格情報を使用した非対話型サインインのレポートを提供します (この攻撃で観察されたように)。サービス プリンシパル レポートのサインインを分析すると、攻撃者が電子メール アクセス用のアプリケーションにアクセスするために使用していた IP アドレスなどの貴重なデータが得られます。

組織のグローバル管理者アカウントおよび/または信頼できる SAML トークン署名証明書にアクセスするために、オンプレミスの侵害を通じて取得された管理アクセス許可を明らかにする証拠が見つかった場合、Microsoft は次の即時アクションを実行することをお勧めします。

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

環境の管理制御を取り戻して保持する

調査の結果、攻撃者が組織のクラウド環境やオンプレミスで管理制御を行っていることが判明した場合は、攻撃者が永続的でないことを確認するような方法で制御を取り戻すことが重要です。正確にどの手順を実行するかは、調査で発見した持続性と、その調査の完全性に対する自信のレベル、および侵入と持続の可能性のあるすべての方法の発見の両方に依存します。不完全な調査に直面した場合でも、高い信頼性で制御を取り戻すことは可能ですが、それには事業運営に大きな影響を与える必要があるため、ほとんどの組織は、私たちの経験では調査の結果に基づいて修復することを選択します。

管理制御回復計画を作成する際には、次の手順を検討することをお勧めしますが、正確な順序とタイミングは、敵対者が所有する管理資産と永続化の方法に関する調査と理解の結果に基づいて計画する必要があります。

  • ここで説明するアクションは、特権アクセス ワークステーションなど、 クリーンなソースから構築された信頼できるデバイスから実行されるようにしてください。
  • 組織がトークン署名証明書またはフェデレーションされた信頼を制御できなくなった場合、最も確実なアプローチは、信頼を削除し、オンプレミスで修復しながらクラウド マスター ID に切り替えることです。そのための詳細な計画は、このドキュメントの範囲を超えており、ID の分離によるビジネス オペレーションへの影響を慎重に計画し、理解する必要があります。 Azure Active Directory のガイダンスまたは重要な考慮事項を確認してください。
  • オンプレミスで管理制御を回復する際に組織が信頼を壊さないことを選択した場合、オンプレミスで管理制御を取り戻し、攻撃者が署名証明書に再びアクセスする能力をブロックしたら、SAML トークン署名証明書をローテーションする必要があります。攻撃者がドメインのトークンを偽造する能力を維持しないようにするには、組織が以下の証明書のローテーション手順に従うことが重要です。

ADFS トークン署名証明書のローテーション

侵害された、または侵害された可能性のある ADFS トークン署名証明書の場合、トークン署名証明書を 1 回ローテーションすると、以前のトークン署名証明書が引き続き機能します。この理由は、署名証明書の通常のローテーション中に、証明書の有効期限が切れる前に証明書利用者信頼を更新するための猶予期間を許可するためです。

注: ADFS 環境で以下の手順を実行すると、プライマリ証明書とセカンダリ証明書の両方が作成され、既定の 5 日間が経過すると、セカンダリ証明書が自動的にプライマリに昇格します。証明書利用者の信頼がある場合、最初の ADFS 環境の変更から 5 日後に影響が生じる可能性があるため、プロセス内で考慮する必要があります。これを解決するには、プライマリ証明書を「-Urgent」で 3 回置き換え、セカンダリ証明書を削除するか、証明書の自動ローテーションをオフにします。

組織がトークン署名証明書をローリングする代わりに、ADFS サーバーを既知のクリーンなシステムに置き換える必要があると感じた場合は、手順に従って環境から既存の ADFS を削除し、新しい ADFS を構築できます。

Azure AD クラウド プロビジョニング エージェントの構成を削除します。

組織が現在の ADFS サーバーで証明書をローテーションすることを決定した場合は、ADFS サーバーから次の手順を順番に実行します。

  1. AutoCertificateRollover がTrueに設定されていることを確認してください。 
     Get-AdfsProperties | FL AutoCert*、証明書*
    • そうでない場合は、次のコマンドで設定できます。 
      セット ADFSProperties -AutoCertificateRollover $true
  2. Microsoft オンライン サービスに接続する 
    接続 MsolService
  3. オンプレミスとクラウドの両方のトークン署名証明書の拇印と有効期限を文書化します。 
     Get-MsolFederationProperty -DomainName <ドメイン>
  4. -Urgent スイッチを使用してプライマリ トークン署名証明書を置き換え、ADFS がプライマリ証明書をセカンダリ証明書にせずにすぐに置き換えます。 
     Update-AdfsCertificate -CertificateType Token-Signing -Urgent
  5. Azure クラウドと同期する前に、-Urgent スイッチを使用せずにセカンダリ トークン署名証明書を作成して、2 つのオンプレミス トークン署名証明書を許可します。 
     Update-AdfsCertificate -CertificateType トークン署名
  6. オンプレミスのプライマリ証明書とセカンダリ証明書の両方でクラウド環境を更新して、クラウドで公開されたトークン署名証明書をすぐに削除します。この方法を使用してこの手順を完了しないと、古いトークン署名証明書が引き続きユーザーを認証する可能性が残ります。 
     Update-MsolFederatedDomain -DomainName <ドメイン>
 
  7. 上記の手順を完了し、上記の手順 3 で表示された証明書を削除したことの確認。 
     Get-MsolFederationProperty -DomainName <ドメイン>
  8. PowerShell を介して更新トークンを取り消します。情報はこちらで確認できます。また、「 Azure Active Directory でユーザー アクセスを取り消す」方法も参照できます。
    • 注: これにより、ユーザーは電話、現在の Web メール セッション、およびトークンとリフレッシュ トークンを使用している他のアイテムからログアウトされます。

完了する追加のクラウド修復アクティビティ

  • ブレークグラス アカウントのパスワードをリセットし、 ブレークグラス アカウントの数を必要最小限に減らします。
  • 特権アクセスを持つサービス アカウントとユーザー アカウントはクラウドのみのアカウントとし、Azure Active Directory に同期またはフェデレーションされたオンプレミス アカウントを使用しないことをお勧めします。
  • テナント内の昇格されたすべてのユーザーに多要素認証 (MFA) を適用します。テナント内のすべてのユーザーに MFA を適用することをお勧めします。
  • Privileged Identity Management (PIM) と条件付きアクセスを実装して、管理アクセスを制限します。
    • Office 365 ユーザーの場合、 Privileged Access Management (PAM)を実装して機密機能 (電子情報開示、グローバル管理者、アカウント管理など) へのアクセスを制限します。
  • 次のようなすべてのエンタープライズ アプリケーションの委任されたアクセス許可または同意の付与を確認して削減します。
    • 特権ユーザーとロールの変更。
    • 電子メールの読み取り、送信、またはすべてのメールボックスへのアクセス。
    • OneDrive、Teams、または SharePoint コンテンツへのアクセス。
    • ディレクトリへの読み取り/書き込みが可能なサービス プリンシパルの追加。
    • アプリケーションのアクセス許可と委任されたアクセス。

完了するための追加のオンプレミス修復アクティビティ

  • 調査中に攻撃者によって侵害されたと特定されたシステムを再構築します。
  • Domain Admins、Backup Operators、および Enterprise Admin グループから不要なメンバーを削除します。 Microsoft のSecuring Privileged Accessを参照してください。
  • 環境内のすべての特権アカウントのパスワードをリセットします。
    • 特権アカウントは組み込みグループに限定されず、サーバー管理/ワークステーション管理および環境のその他の側面へのアクセスを委任されたグループにすることもできます。
  • このスクリプトを 2 回使用して、krbtgt アカウントをリセットします。
    • 注: 読み取り専用ドメイン コントローラーを使用している場合は、読み取り/書き込みドメイン コントローラーと読み取り専用ドメイン コントローラーのスクリプトを実行する必要があります。
  • 攻撃者によって作成された永続化メカニズムが存在しないか、システムに残っていないことを確認したら、再起動をスケジュールします。これは、メモリ常駐マルウェアの削除に役立ちます。
  • 各ドメイン コントローラの DSRM (Directory Services Restore Mode) パスワードを一意で複雑なものにリセットします。

調査中に発見された持続性を修復またはブロックする

以前の調査段階で特定された永続化手法を修正します。調査は反復的なプロセスであり、異常を特定したときに修復したいという組織の欲求と、修復によって攻撃者に検出の警告を発し、手法を変更するか追加の持続性を作成することで攻撃者が反応する可能性とのバランスを取る必要があります。 Office 365 アカウントの場合、既知の永続化手法が発見された場合は、説明されているスクリプトを使用して自動的に修正します。

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

推奨されるユーザーレベルのアクションの一部は、特に MFA が有効になっていることを確認し、特定の修復スクリプトを実行して既知の永続化手法をクリーンアップするという点で、既に説明されています。ユーザー アカウントを修正および復元するために考慮すべき追加の手順を次に示します。

  • 信頼できるデバイスに基づいて条件付きアクセスを適用します。
    • 可能であれば、組織の要件に合った場所ベースの条件付きアクセスを適用してください。
  • 侵害された疑いのあるユーザー アカウントについては、削除後すぐにパスワードをリセットします。ディレクトリ内のすべてのアカウントの資格情報をリセットするための中期計画も実装してください。
  • 資格情報のローテーション後、PowerShell を使用して更新トークンをすぐに取り消します。詳細についてはこちらを参照してください。追加のリソースについては、Azure Active Directory で緊急時にユーザー アクセスを取り消す | を参照してください。 Microsoft ドキュメント.

セキュリティ態勢を改善する

セキュリティ イベントの後は、組織がセキュリティ戦略と優先事項について考える良い機会です。インシデント レスポンダーは、新しい脅威に直面した今、組織が優先すべき投資について、イベントの後に推奨事項を提供するよう求められることがよくあります。以前に文書化された推奨事項に加えて、この攻撃者が使用する悪用後の手法と、それらを可能にする一般的なセキュリティ体制のギャップに対応するインシデント後のレビューの推奨事項について、これらの重点分野を検討することをお勧めします。

一般的なセキュリティ体制

  • 使用する Microsoft 製品およびサービスに合わせてカスタマイズされたセキュリティの基礎に関する推奨事項については、Microsoft セキュリティ スコアを確認してください。
  • 組織に EDR および SIEM ソリューションが導入されていることを確認してください。
  • Microsoft のエンタープライズ アクセス モデルを確認してください。

身元

  1. ID インフラストラクチャを保護するための 5 つの手順を確認し、ID アーキテクチャに応じて手順に優先順位を付けます。
  2. 認証ポリシーの Azure AD セキュリティの既定値への移行を検討してください。 詳細については、こちらを参照してください。
  3. システムまたはアプリケーションで依然としてレガシー認証が必要な場合は、組織でのレガシー認証の使用を排除します。 こちらのガイダンスを確認してください。
    • 昨年発表したように、Exchange チームは 2021 年後半に EAS、EWS、POP、IMAP、および RPS プロトコルの基本認証を無効にすることを計画しています。特徴。認証ポリシーを使用して、Exchange Online プロトコルのサブセットの基本認証をオフにするか、大規模な組織全体で基本認証を徐々にオフにすることをお勧めします。詳細は今後の発表で発表されますが、4 月に述べたように、2020 年 10 月には、使用状況が記録されていない既存のテナントの基本認証の無効化を開始する予定です。テナントの基本認証を無効にする前に、メッセージ センターの投稿を通じて通知を提供します。 .
  4. ADFS/Azure AD Connect システムを保護するために、見つけた ADFS ガイダンスを超えて、次のアクションを検討することをお勧めします。
    • ADFS インフラストラクチャと AD Connect インフラストラクチャを Tier 0 資産として扱います。
    • ADFS サービスの実行に使用されるアカウントを含め、システムへのローカル管理アクセスを制限します。
      • ADFS を実行するアカウントに必要な最小限の特権は、 Log on as a Serviceユーザー権利の割り当てです。
    • リモート デスクトップのWindows ファイアウォール ポリシーを利用して、限られたユーザーと限られた IP アドレス範囲からの管理アクセスを制限します。
      • Tier 0 ジャンプ ボックスまたは同等のシステムをセットアップすることをお勧めします。
    • 環境内のどこからでも、システムへのインバウンド SMB アクセスをすべてブロックします。詳細については、このリソースを参照してください。
      • Windows ファイアウォールのログを SIEM に取得して、履歴およびプロアクティブな監視を行います。
    • サービス アカウントを使用していて、環境がそれをサポートしている場合は、サービス アカウントからグループのマネージド サービス アカウント (gMSA)に移行します。 gMSA に移行できない場合は、サービス アカウントのパスワードを複雑なパスワードに変更します。
    • 次のコマンドを実行して、ADFS システムで詳細ログが有効になっていることを確認します。
Set-AdfsProperties -AuditLevel verbose
Restart-Service -Name adfssrv
Auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable

寄稿者: FireEye のチームの寄稿とレビューに感謝します。

参照: https://www.microsoft.com/en-us/security/blog/2020/12/21/advice-for-incident-responders-on-recovery-from-systemic-identity-compromises/

Comments

Copied title and URL