新しいパスワードを教えてください4億ドルの質問

2023年8月、Scattered Spiderグループに属する攻撃者たちは、ゼロデイ脆弱性を悪用してクロロックスをハッキングしたわけではない。彼らは単にサービスデスク（Cognizantが運営）に電話をかけ、ロックアウトされた従業員を名乗り、パスワードとMFAのリセットを要求した。

裁判所に提出された書類や報告によると、攻撃者はCognizant社のサービスデスクに何度も電話をかけ、意味のある検証をすることなく何度もリセットを取得し、その結果得られたアクセス権を使ってドメイン管理者の足場へと素早く移動した。

クロロックス社によると、この攻撃は最終的に約3億8000万ドルの損害をもたらし、その中には約4900万ドルの修復費用と「数億ドル」の事業中断損失が含まれているという。ここでは、何が起こったのか、サードパーティーのサービスデスクを保護する方法、そして適切なテクノロジーを使って検証を実施する方法について説明する。

攻撃はどのように行われたのか？

ソーシャル・エンジニアリング攻撃は、人間の誤りを狙うことで成功します。攻撃者は偵察（名前、肩書き、最近の採用者、社内チケットのリファレンスの収集）を行い、次に正当なユーザーの行動を模倣した穏やかでスクリプト化された電話を使用します。サービスデスクの担当者がプレッシャーを感じ、セキュリティ・プロセスをスキップするように仕向けるのだ。

クロロックス社のケースでは、エスカレーションや帯域外検証を実行することなく、認証情報とMFAをリセットするよう、最前線のエージェントが電話で説得されたとして、法的訴状が提出されている。これは、Cognizant社との間で合意された、エージェントは最初に適切に認証することなくクレデンシャルをリセットすべきではないという手順に反していたと主張している。

その結果、1つの漏洩したIDが、横の動きと大きな混乱の軸となった。

a.fl_button { background-color：a.fl_button { background-color: #5177b6; border：a.fl_button { background-color: #5177b6; border: 1px solid #3b59aa; color：#text-align: center; text-decoration: none; border-radius: 8px; display: inline-block; font-size: 16px; font-weight: bold; margin：4px 2px; cursor: pointer; padding：12px 28px; } .fl_ad { background-color：#width: 95%; margin: 15px auto 15px auto; border-radius: 8px; border：1px solid #d6ddee; box-shadow: 2px 2px #728cb8; min-height: 200px; display: flex; align-items: center; } .fl_lef>a>img { margin-top: 0px !important; } .fl_rig>p { font-size: 16px; } .grad-text { background-image: linear-gradient(45deg, var(–dawn-red), var(–iris)54%, var(–aqua)); -webkit-text-fill-color: transparent; -webkit-background-clip: text; background-clip: text; } .fl_rig h2 { font-size: 18px!important; font-weight: 700; color：color: #333; line-height: 24px; font-family：font-family: Georgia, times new roman, Times, serif; display: block; text-align: left; margin-top: 0; } .fl_lef { display: inline-block; min-height: 150px; width: 25%; padding：10px 0 10px 10px; } .fl_rig { padding：10px; display: inline-block; min-height: 150px; width: 100%; vertical-align: top; } .fl_lef>a>img { border-radius: 8px; } .cz-news-title-right-area ul { padding-left: 0px; } @media screen and (max-width: 1200px) { .fl_ad { min-height: 184px; } .fl_rig>p { margin: 10p10px; } .fl_rig { padding：0 10px 10px 10px; width: 100%; } } @media screen and (max-width: 400px) { .cz-story-navigation ul li:first-child { padding-left: 6px; } .cz-story-navigation ul li:last-child { padding-right: 6px; } } }.

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

クロロックス社は、生産システムのオフライン、製造の一時停止、手作業による注文処理、出荷の遅延による販売量の減少を報告しました。これらのサプライチェーンとフルフィルメントへの影響（およびフォレンジックと修復コスト）は、訴訟で引用された損失額の大半を占めた。これは、単純な不正パスワード・リセットが広範囲に及ぶ結果をもたらす可能性があることを思い起こさせるものである。

CISAや他の機関もこのパターンを指摘している：散在スパイダーや類似のグループは、アウトソーシングされたデスクが複数の顧客の環境への高い特権の橋渡しの後ろに位置することが多いため、請負のヘルプデスクをターゲットにしている。このグループに対する防御に関するアドバイスでは、脅威行為者はユーザになりすまし、脆弱な検証を悪用して MFA をバイパスし、認証情報をリセットすると特に警告しています。そのため、強固な発信者認証は単に良い習慣というだけでなく、サプライチェーンの中核的な管理となっている。

アウトソーシングがリスクを拡大した理由

ベンダーのプロセスが強固であれば、ヘルプデスク機能をアウトソーシングすることはセキュリティ上問題ないはずです。しかし、ベンダーの検証プロセスが脆弱であったり、不十分であったりすると、リスクは増幅される。構造的な理由は3つある：

• 同心円的な信頼： ベンダーは多くの場合、テナントをまたがる広範な権限とファストパスのワークフロー（パスワードのリセット、MFAのリセット、アカウントのロック解除）を持っており、悪用されれば企業全体の特権システムに到達する可能性がある。
• プロセスのドリフトとスケール：スクリプトが曖昧であったり、QAが不十分であったりすると、エージェントは厳密な検証ではなく、「ユーザーを働かせる」行動に戻ってしまいます。このケースでは、検証に関する契約上の期待が守られていなかったと、クロロックス社は訴えている。
• 可視性の欠如： サードパーティのデスクは、顧客の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がスポンサーとなり、執筆しました。