mcpField
C
compromise-recovery

compromise-recovery

github.com/vinayaklattheセキュリティ17879 回インストール19 週間前に更新
リポジトリ

compromise-recovery について

重大な環境侵害に対応するセキュリティチーム向けの復旧スキルです。管理権限の回復、攻撃者の一斉排除、信頼できるセキュリティ状態の再構築を支援し、先に信頼できる作業環境の確立と証拠保全を重視します。

主な機能

  1. 01段階に沿った調査と復旧
  2. 02信頼できる通信と管理環境の確立
  3. 03修復前のフォレンジック証拠保全
  4. 04複数の永続化手段の一括排除
  5. 05ID の信頼再構築と防御強化
  6. 06復旧後の継続的な監視計画

活用シーン

  1. 01テナント全体の Entra または AD 侵害への対応
  2. 02ランサムウェアや持続的な攻撃者への対処
  3. 03特権アカウント侵害後の排除と復旧の計画
  4. 04侵害後のセキュリティ強化策の策定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill compromise-recovery

インストール後、Claude Code で/compromise-recoveryを入力して読み込まれたか確認します。

詳細

侵害からの復旧

侵害からの復旧とは、重大な侵害の発生中または発生後に、環境の管理権限を規律ある方法で取り戻し、調整された単一の対応で攻撃者を排除し、攻撃者が再侵入できないよう、信頼できるセキュリティ体制を再確立するプロセスです。

使用するタイミング

広範囲に及ぶ侵害が確認された場合に対応します。たとえば、テナント全体に及ぶ Entra/AD の侵害、ランサムウェア、Global Admin または Domain Admin の権限を持つ執拗な攻撃者など、通常の修復では不十分で、既存のインフラストラクチャを信頼できない場合です。

次の場合は、このスキルを使用しないでください。

  • 通常のアラートのトリアージや単一ホストのマルウェア(defender-xdr を使用)
  • インシデント発生前のアーキテクチャ強化(security-architecture、entra-id、paw-design を使用)
  • Sentinel のハンティングや検知エンジニアリング(sentinel を使用)

現在の段階を判断する

状況段階最初のアクション
異常が検出されたが、影響範囲はまだ確認できていない調査ハンティングと証拠の保全を行い、攻撃者に気付かれないようにする
攻撃者が確認され、影響範囲がまだ拡大中封じ込め信頼できる基盤(PAW)を構築し、最重要資産を保護する
攻撃者の影響範囲が判明し、排除の準備が整った排除すべての永続化手段に対し、調整された単一の対応を実施する
攻撃者を排除し、再侵入がないことを検証中復旧krbtgt、フェデレーションのシークレット、特権アカウントの認証情報をリセットする
安定し、再発防止の強化を実施中強化全環境で MFA を導入し、PIM、PAW、監視範囲の拡大を行う
強化が完了し、通常業務に復帰移行継続的な SecOps と改善活動に引き継ぐ

経験則: 侵害された環境から排除を開始してはいけません。 まず、専用の管理用ワークステーション(PAW)、帯域外通信、クリーンな Entra テナント、または再構築したクリーンな管理者アカウントを用意し、信頼できる基盤を構築してください。信頼できないインフラストラクチャから対応すると、攻撃者に対応計画をリアルタイムで渡すことになります。

アプローチ

  1. 有資格のインシデント対応担当者に直ちに依頼する - 重大なインシデントでは、Microsoft Incident Response または有資格の DFIR パートナーに依頼します。対応が遅れることで生じるコスト(再侵入、ランサムウェアによる二重恐喝、規制当局への対応期限)は、依頼にかかるコストをはるかに上回ります。 確認事項:侵害が確認されてから最初の24時間以内に、IR パートナーに依頼していること。
  2. 信頼できる基盤を確立する - 帯域外の通信手段(別の Teams テナント、Signal/音声通話)、セキュアな管理者デバイス(PAW)、クリーンな管理者 ID の経路を準備します。メール、チャット、踏み台ホスト、管理者アカウントなど、既存のインフラストラクチャは信頼できない、または攻撃者に監視されている可能性があると想定します。 確認事項:インシデント対応用の会議は帯域外チャネルで行っていること。対応担当者は PAW または同等の隔離されたワークステーションから認証していること。侵害された管理者アカウントは使用していないこと。
  3. 修復の前にフォレンジック証拠を保全する - 影響を受けたシステムのスナップショットを作成し、サインインログ、監査ログ、メールアイテム、Entra/AD の変更をエクスポートします。修復すると証拠が失われます。規制当局や保険会社から提示を求められます。 確認事項:フォレンジック取得データを隔離された書き込み保護メディアに保存し、証拠保全の連鎖を記録していること。
  4. 攻撃者に気付かれずに封じ込める - 攻撃者の行動能力を制限します。最重要資産(特権アカウント、フェデレーション/署名キー、バックアップ認証情報)を保護し、可能であればステルスモードで Conditional Access を強化し、既知の攻撃者アカウントをブロックせずに監視します。不完全な排除は攻撃者に警告を与え、新しい ID で再び足場を築く機会を与えます。 確認事項:封じ込めの対応を場当たり的にではなく、順序を定めたランブックに記録していること。意図的な対応を除き、攻撃者から見える変更を加えていないこと。
  5. 一度の協調した対応で排除する - 既知のすべての永続化手段について、順序を定めた削除計画を立てます。侵害されたアカウント(無効化+リセット)、アプリの登録と同意の許可(確認して取り消し)、メールボックスのルールと転送(削除)、スケジュールされたタスク/スタートアップ項目、ゴールデン/偽造 Kerberos チケット、フェデレーション/SAML トークン、追加された管理者ロールなどが対象です。個別に小分けして変更するのではなく、決定的な対応を一度に実施する時間枠を設けます。 確認事項:排除用ランブックに、すべての永続化要素と担当者、時刻、検証手順を記載し、実行前にリハーサルしていること。
  6. ID の信頼をリセットする - krbtgt アカウントを(レプリケーションに十分な間隔を空けて2回)リセットし、すべての特権認証情報をリセットし、フェデレーション/SAML 署名証明書をローテーションし、Entra Connect の同期アカウントをローテーションし、攻撃者がアクセスした可能性のあるサービスプリンシパルのシークレットもすべてリセットします。 確認事項:krbtgt のリセットが2回記録されていること。フェデレーション証明書のロールオーバーが完了していること。サインインログに、侵害されたトークンによるセッションが残っていないこと。
  7. 再侵入を防ぐためにセキュリティを強化する - すべての特権ユーザーと高リスクユーザーにフィッシング耐性のある MFA を適用し、特権ロールをPIMに移行してジャストインタイムの有効化と承認を必須にし、管理作業用の PAW を導入または拡張し、確認された攻撃者の TTP に合わせて検出を調整しながら Defender と Sentinel の監視を拡張し、特権階層全体に最小権限モデルを適用します。 確認事項:すべての特権アカウントが PIM に登録され、フィッシング耐性のある MFA で保護されていること。管理作業用の PAW 環境が明確に定義されていること。確認された具体的な TTP に対する新たな検出機能が導入されていること。
  8. 通常業務へ移行する - 90日間の監視期間、文書化された教訓、初期侵害を許した脆弱性への継続的な投資を含む、持続的なセキュリティ運用と改善プログラムに引き継ぎます。

ガードレール

  • 重大なインシデントでは、資格を持つインシデント対応担当者(例:Microsoft Incident Response)に依頼してください。一定のしきい値を超えると、セルフサービスで対応できるものではありません。
  • 排除の順序は慎重に決めてください。部分的な排除は攻撃者に警告し、再定着を招きます。計画し、リハーサルを行ったうえで、1つのアクションとして実行してください。
  • 調査、規制、または保険上の義務がある場合は、修復の前にフォレンジック証拠を保全してください。データの消去は証拠の破壊にあたります。
  • 侵害されたインフラストラクチャからは決して作業しないでください。攻撃者の領域に触れる前に、信頼できる基盤とPAWを確立してください。
  • krbtgt を2回リセットし、リセットの間にはレプリケーション間隔を設けてください。1回だけのリセットでは、有効なゴールデンチケットがまだ残っています。
  • AiTM時代以降、フィッシング耐性のある要素を使わないMFAでは不十分です。特権ユーザーを FIDO2/Windows Hello for Business/証明書ベースの認証に移行してください。
  • PIMと最小特権は、排除後に必須です。常設特権を経由して攻撃者が侵入した場合、常設特権を取り除くことが排除につながります。

よくあるアンチパターン

  • 段階的な排除。 侵害されたアカウントを1つ無効化すると攻撃者に気付かれ、次の永続化手段に移って、さらに深く侵入されます。計画を立て、調整された1つのアクションとして実行してください。
  • 侵害された管理者ワークステーションからの作業。 攻撃者は対応をリアルタイムで監視し、それに応じて適応します。必ずPAWまたは同等の環境から作業してください。
  • 「パスワードは変更した」という理由でkrbtgt のリセットを省略すること。krbtgt は AD の信頼のルートです。窃取されていた場合、2回リセットするまでは、すべての Kerberos チケットを偽造できます。
  • サービスプリンシパルとアプリの登録を忘れること。 最新の Entra 侵害は、ユーザーアカウントをリセットした後も、同意の付与やアプリのシークレットを介して持続します。
  • 勝利を早まって宣言すること。 90日間の監視期間を設け、確認されたTTPに合わせて新たな検出を調整しなければ、再侵入の試みを見逃します。
  • 教訓を得ず、投資を約束しないこと。 根本原因(弱いMFA、PIMの未導入、フラットなネットワーク、PAWの未導入)への対策に予算を割り当てなければ、侵害は再発します。

プロンプトの例

  • 攻撃者が現在、テナントのグローバル管理者権限を持っています。排除の手順を説明してください。
  • ランサムウェア攻撃に対する Microsoft のインシデント対応プロセスを説明してください。
  • 攻撃者に気付かれずに、Entra ID テナントから攻撃者を排除するにはどうすればよいですか?
  • テナントの侵害を発見した後、最初の24時間で何をすべきですか?
  • 攻撃者が再侵入できないよう、排除後にテナントを強化するにはどうすればよいですか?
  • 侵害後、管理者アカウントへの信頼を回復するにはどうすればよいですか?

Microsoft Learn

コメント