新しいパスワードをいただけますか？4億ドルの疑問。

2023年8月、Scattered Spiderグループに関連する攻撃者は、Cloroxをハッキングするためにゼロデイ脆弱性を悪用したわけではありません。彼らは単にサービスデスク（Cognizantが運営）に電話し、自分がロックアウトされた従業員だと主張して、パスワードとMFAリセットを依頼しただけでした。

裁判所への提出書類や報道によると、攻撃者はCognizantのサービスデスクに何度も電話し、実質的な本人確認なしに繰り返しリセットを取得し、そのアクセスを利用してドメイン管理者権限の足掛かりを迅速に得ました。

Cloroxによれば、この攻撃は最終的に約3億8,000万ドルの損害につながり、そのうち約4,900万ドルが修復費用、「数億ドル」が業務中断による損失でした。この記事では、何が起きたのか、サードパーティのサービスデスクをどのように保護するか、そして適切な技術で認証を強制する方法を解説します。

攻撃はどのように進行したのか？

ソーシャルエンジニアリング攻撃は、人間の脆弱性を狙うことで成功します。攻撃者は偵察を行い（名前、役職、最近の入社者、内部チケットの参照などを収集）、本物のユーザー行動を模倣した落ち着いたスクリプト通話を使います。彼らはサービスデスクの担当者にプレッシャーを与え、セキュリティプロセスを省略させようとします。

Cloroxのケースでは、訴状によると、現場の担当者は電話で説得され、エスカレーションや別経路での認証を行わずに資格情報やMFAをリセットしました。これは、Cognizantとの合意された手順（担当者は正しい認証なしに資格情報をリセットしてはならない）に反していたと主張されています。 

その結果：1つのIDが侵害されただけで、横展開と大規模な混乱のきっかけとなりました。

影響：業務の麻痺とデータ損失

Cloroxは、生産システムの停止、製造の中断、手動での注文処理、出荷の遅延により販売量が減少したと報告しています。これらのサプライチェーンやフルフィルメントへの影響（およびフォレンジックや修復費用）が、訴訟で挙げられた損失の大部分を占めています。これは、単純な不正なパスワードリセットがどれほど広範な影響を及ぼすかを示す警鐘です。   

CISAなどの機関もこのパターンに警鐘を鳴らしています：Scattered Spiderや類似グループは、委託されたヘルプデスクを標的にします。なぜなら、外部委託のデスクはしばしば複数顧客の環境への高権限ブリッジの背後にいるからです。このグループへの防御アドバイスでは、脅威アクターがユーザーになりすまし、弱い認証を悪用してMFAや資格情報のリセットを回避することが警告されています。したがって、強固な発信者認証は単なるベストプラクティスではなく、サプライチェーン全体の重要な管理策となります。

なぜアウトソーシングでリスクが増大したのか

ヘルプデスク機能のアウトソーシング自体は、ベンダーのプロセスが強固であればセキュリティ上問題ではありません。多くの組織がそうしています。しかし、ベンダーの認証プロセスが弱い、または適切に運用されていない場合、リスクは増大します。構造的な理由は3つあります：

• 同心円的な信頼：ベンダーはしばしば広範なクロステナント権限や高速なワークフロー（パスワードリセット、MFAリセット、アカウントロック解除）を持ち、悪用されると全社的な特権システムに到達する可能性があります。
• プロセスの逸脱と規模：大手ベンダーは大量のコールを処理します。スクリプトが曖昧だったり品質管理が不十分だと、担当者は厳格な認証よりも「ユーザーを早く復旧させる」行動に走りがちです。今回のCloroxの訴訟では、契約上の認証要件が守られていなかったと主張されています。
• 可視性の欠如：サードパーティのデスクは、自社システムやチケット管理でアクションを記録する場合があり、それが顧客のSIEMや特権アクセスの監視に完全に統合されていないため、検知が遅れることがあります。

防御側が取るべき対策

ヘルプデスクによるリセットは特権操作とみなし、次の5つの実践的なステップで適切に管理しましょう：

1. リモートリセットには必ず別経路での認証を強制：会社所有の電話番号への折り返し、業務用メールへのワンタイムトークン送信、または知識ベースではなく短い暗号チャレンジを要求しましょう。
2. 承認の閾値を設ける：高リスクなリセット（MFA、特権グループ、サービスアカウント）は2名による承認と、チケットIDに紐づく自動マネージャー通知を必須にします。
3. 短期間の権限昇格とセッション分離：修復作業には一時的な特権セッションを使い、長期間の管理者セッションは検知時に取り消しましょう。
4. 自動テレメトリと封じ込め：すべてのリセットを不変の監査証跡（チケットID、担当者ID、発信者の折り返し番号）に記録し、異常なリセットパターンで警告、疑わしい場合は自動でリフレッシュトークンの無効化や再認証を強制します。
5. 検知をルール化：「同じ外部折り返し番号が複数の異なるユーザーリセットに使われている」「同じ部門のユーザーでX分以内に複数のMFAリセット」などのパターンを監視しましょう。これらは高シグナルな事象であり、自動セッション無効化やSOCエスカレーションを即時発動すべきです。

運用ガバナンス：契約条項と監査

アウトソーシングする場合、契約にはベンダー側の技術的管理策と監査可能性を必ず盛り込みましょう。ベンダーが2経路認証、不変のリセットログ、SIEMとの統合を実際に運用していることを（ログや年次テストで）証明させてください。疑わしいアカウント侵害時のMTTD/MTTRに関する測定可能なSLAを含め、ソーシャルエンジニアリングの模擬テストとその是正結果の報告も義務付けましょう。

技術は助けになりますが、人は依然としてソーシャルエンジニアリングの標的になります。自社（およびベンダー）のヘルプデスクに対して定期的にレッドチームによる電話シミュレーションを実施し、失敗を測定し、是正トレーニングを運用に組み込みましょう。リセットから封じ込めまでの時間を追跡・短縮してください—この指標を改善することが、高額な一時的な強化プロジェクトよりも効果的です。

Specops Secure Service Deskをお試しください

発信者認証の強制、不変の監査証跡、チケット連携を本番環境でライブ体験したい場合は、Specops Secure Service Deskをお試しください。

決定論的な認証と自動封じ込めが、攻撃者の行動可能な時間をどれだけ短縮するかを最速で体験できます。

ライブデモを予約する。

Specops Softwareによるスポンサー記事・執筆。