CISAが2つのSOCを比較検証 — 検知できた組織とできなかった組織を分けた3つの要因

米サイバーセキュリティ・インフラストラクチャ安全保障局（CISA）は2026年8月25日、「A Tale of Two SOCs: Insights From Two Red Team Assessments」（AA26-237A） と題したサイバーセキュリティ・アドバイザリを公開した。2つの重要インフラ組織で同時期に実施したレッドチーム評価の結果を比較し、同じ攻撃手口でも防御の成否がなぜ分かれたかを分析した報告書だ。

2つの組織と評価の枠組み

CISAのレッドチームは、組織の要請に応じて、実際の攻撃者の手口を模倣して侵入を試み、検知・調査・対応能力を評価する。

今回の評価対象は次の2組織だった。

• 組織A: Government Services and Facilitiesセクター（政府サービス・施設）の組織
• 組織B: Water and Wastewater Systemsセクター（上下水道）の組織

両組織とも、レッドチームは最終的にドメイン全体の侵害と、重要業務システム（SBS: Sensitive Business Systems）やクラウドリソースへのアクセスに成功した。しかし、防御側の対応は大きく異なった。組織Aは攻撃を検知も封じ込めもできなかったのに対し、組織Bは初期侵害の段階で迅速に検知し、影響を受けたシステムを隔離した。組織Bではその後、レッドチームが「アサンプション・オブ・ブリーチ（assume breach）」モデルへ移行し、信頼されたエージェントから同等の権限を持つホストの提供を受けて評価を継続したが、そこからの権限昇格やOTのDMZにある踏み台ホストへの横展開も、再び検知・隔離された。

CISAはこの対比から、重要インフラ組織がIT、クラウド、OT環境での検知と対応を強化するための教訓と緩和策をまとめている。

レッドチームが使った手口

アドバイザリのTechnical Detailsによると、両組織で使われた手口は共通しており、MITRE ATT&CK v19にマッピングされている。組織Aでの詳細は次のとおりだ。

初期侵入とActive Directoryの偵察

レッドチームはまず、デフォルト認証情報が残るウェブアプリケーションを発見した。複数の組み込みユーザーアカウントで同じパスワードが使われており、内部のメールアドレスからの送信が可能だった。レッドチームはこの内部メールアドレスからフィッシングメール（T1566）を送り、4台のワークステーションで初期アクセスを得た。

ワークステーションからは、EDRの静的なシグネチャを回避するよう改変したBloodHoundコレクターでActive Directory（AD）情報を収集した。取得した情報は、ADユーザー（T1087.002）、コンピューター（T1018）、グループ（T1069.002）、アクセス制御リスト、組織単位（OU）、グループポリシーオブジェクト（T1615）などだ。

さらに、レッドチームは次の2つのADの設定ミスを発見した。

• Machine Account Quota（MAQ）がデフォルトの10のまま: 通常ユーザーでも最大10台までコンピューターアカウントをドメインに追加できる状態だった
• Active Directory証明書サービス（ADCS）の証明書テンプレートでESC1の設定ミス: 任意のユーザーが全ユーザー・コンピューターのアカウントになりすまして証明書を要求できる脆弱なテンプレートが複数存在した

レッドチームはMAQを悪用してマシンアカウントを作成し（T1136.002）、そのマシンアカウントでESC1の脆弱なテンプレートを悪用して証明書を取得（T1649）した。マシンアカウントの証明書を使えば任意のユーザーとして証明書を取得できるため、ドメイン全体の権限昇格につながった。

権限昇格と重要業務システムへの横展開

ドメイン管理権限を得た後、レッドチームは重要業務システム（SBS）へのアクセスを試みた。手順は、ADデータからSBSに関連するユーザーとグループを特定し、System Center Configuration Manager（SCCM） でユーザーとデバイスの紐付けを列挙（T1033）し、標的ユーザーのワークステーションへ横展開して認証情報を収集するというものだった。

SBSごとに手法は異なった。

• SBS 1（データベース）: 管理者ワークステーションに残る平文の認証情報（T1552）を取得した
• SBS 2（データベース）: SQL開発ツールの設定ファイル connections.json と product-preferences.xml を探し、復号して平文パスワード（T1552.001）を得た
• SBS 3（自動処理システム）: ユーザーのホームディレクトリに保存された、有効期限やローテーションが設定されていない長期間有効なAWS IAMユーザー認証情報を窃取した

さらに、SBS 2とSBS 3では、仮想デスクトップが分散ファイルシステム（DFS）のルートドライブと同期されている点に着目し、DFSのルートドライブを侵害して、アクティブなセッションの有無にかかわらず数千人分の仮想デスクトップ上のクラウド設定ファイルやデータベース接続ファイルを一括で検索した。レッドチームはプロキシ（T1090.001）経由でツールを中継し、防御側に検知されることなく全てのSBSで管理者アクセスを得た。

クラウド（Microsoft Entra ID）への展開

SBS侵害後、レッドチームは Microsoft Entra ID（旧Azure AD） のクラウド環境へ展開した。標的は Application permissions を持つEntra IDアプリケーションだった。Application permissionsはユーザー同意なしにデータへアクセスできる権限で、通常の条件付きアクセスポリシー（CAP）の適用外で動作する。昇格したApplication permissionsを持つアプリケーションを侵害すれば、そのアプリケーションと同じ権限をレッドチームが得られる。

CISAは、ワークロードIDに対する条件付きアクセス（Conditional Access for workload identities） を実装していればこの手口を防げた可能性があるが、評価した組織ではいずれも使われていなかったと指摘している。

CISAが挙げた3つの教訓と推奨策

アドバイザリは、防御の成否を分けた要因を次の3点に整理した。

1. 未調整の検知ツールが脅威の見逃しを招く: ベースラインが定義されておらず、アラートのフィルタリングが不十分だと、誤検知や日常的なアラートが防御者を圧倒し、本当の脅威が埋もれる
2. 組織のサイロ化と官僚的な障壁が対応を妨げる: ツールの性能だけでなく、人・プロセス・手順が重要だ。コミュニケーションの分断、責任の不明確さ、防御担当者の権限不足が対応を遅らせる
3. クラウド環境のリスクが過小評価されている: クラウド向けの統制や、クラウド侵害時の対応手順が不足している組織が多い

これを踏まえ、CISAは次の**Key Actions（主要な対策）**を推奨している。

• ベースラインを確立して継続的に維持し、検知ツールを適切にチューニングしてアラートノイズを減らす
• サイロを解消し、防御担当者に権限を与える（検知時に迅速に隔離・対応できる権限と責任を明確にする）
• ワークロードIDに条件付きアクセスポリシーを実装し、過剰または未使用の権限を監視する
• クラウド侵害時にアクセス／リフレッシュトークンを検知・修復・失効させるための包括的な手順を確立し、定期的に見直す

CISAは、評価の詳細、MITRE ATT&CKへのマッピング、緩和策の全文をアドバイザリ本文とPDF（937KB）で公開しており、重要インフラの管理者やインシデント対応者、ネットワーク防御者に対して、緩和策セクションの実装を推奨している。

日本の組織への示唆

CISAの評価は米国の重要インフラが対象だが、指摘された問題は日本企業にも共通する。ADCSのESC1やMAQのデフォルト設定は国内のActive Directory環境でも頻繁に見つかる設定ミスであり、SCCMやDFS、Entra IDを使った横展開の手口は、日本の多くの企業が使うMicrosoft環境でも再現しうる。クラウドのワークロードIDに対する条件付きアクセスや、トークン失効手順の整備は、Entra IDやAWS IAMを使う組織が優先して確認すべき項目だ。

出典

• CISA Cybersecurity Advisory AA26-237A: A Tale of Two SOCs: Insights From Two Red Team Assessments（2026年8月25日公開） https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-237a