サマリー
- 攻撃者は、以前に侵害され正規に署名された取引アプリケーションを通じて 3CX に到達し、その企業環境に侵入して Windows と macOS のビルド環境を侵害しました。その結果生成された 3CX インストーラも有効に署名され、通常のチャネルを通じて配布されたため、2 つのサプライヤーの信頼メカニズムが連鎖的な攻撃経路に変わりました。
- 公開されたエンドポイントの証拠は、3CX の確認に先行していました。SentinelOne は 2023 年 3 月 22 日から検出の急増を観測し、3CX は 3 月 29 日に悪意のある悪用に関する第三者報告を受けたと述べています。この期間は、アラートの受信、相関、エスカレーションにおける説明責任の問題として理解するのが最も適切であり、単一の早期報告だけで全体の侵害が証明されたわけではありません。
- 顧客は 3CX の内部ビルドシステムを検査できませんでしたが、無力ではありませんでした。行動ベースのエンドポイント制御、DNS とネットワークテレメトリ、ソフトウェアインベントリ、段階的な更新、資格情報のローテーション、テスト済みのブラウザベースのフォールバックが、露出または不確実性を低減しました。
- 責任は依然として区別されます。攻撃者は侵入を引き起こし、3CX はビルドの整合性、リリース署名、顧客コミュニケーション、セキュリティ報告経路を管理し、顧客はローカルな展開と対応を管理し、セキュリティベンダーは検出品質とエスカレーションを管理しました。責任の共有は、それらの義務を交換可能にするわけではありません。
更新が信頼された経路だった
3CX インシデントは、顧客の境界から始まったわけではありません。影響を受けたユーザーにとって、危険なアクションは、ベンダーのインフラストラクチャから入手したソフトウェアの通常のインストールまたは自動更新でした。パッケージは、顧客が使用しようとしていた製品のように見えました。それは 3CX のコード署名を保持していました。悪意のある動作は、ビジネス通話、会議、メッセージングに使用される見慣れたデスクトッププロセス内で展開されました。ファイルが期待される発行元からのものかどうかのみを問う制御は、したがって、間違った質問に対する正しい答えを受け取っていました。
2023 年 3 月 30 日、3CX は Windows Desktop App バージョン 18.12.407 および 18.12.416 が影響を受けたと特定し、後に macOS のリストを Update 6 および 7 で提供されたバージョンに拡大しました。その最初のセキュリティアラートでは、Electron アプリケーションをアンインストールし、可能な場合はプログレッシブ Web アプリケーションを使用し、ホスト型または自己管理型サーバーを更新して影響を受けたインストーラを提供しないようにするよう顧客に指示しました。サーバーとエンドポイントの区別は重要でした。電話システムサーバーから汚染されたパッケージを削除すると、その場所からのさらなる配布が停止しましたが、すべてのワークステーションがクライアントを削除したか、悪意のあるチェーンを実行したか、または後続のペイロードを受け取ったかは確立されませんでした。
デジタル署名は、ソフトウェアが安全であることの証明としてあまりにも広範に説明されることがよくあります。署名は、定義されたプロセス内での身元と整合性に関する証拠です。それは、特定の署名キーの保持者が署名してからバイトが変更されていないことを示すことができます。署名者が含まれるすべてのコンポーネントを意図していたこと、ビルドマシンがクリーンであったこと、または結果のプログラムが良性に動作することを証明するものではありません。このケースでは、署名によって侵害されたパッケージがより運用上信頼できるものになりました。なぜなら、顧客とオペレーティングシステムが 3CX を発行元として信頼する正当な理由を持っていたからです。
これが、侵害されたオブジェクトがデスクトップアプリケーションであったにもかかわらず、この事象がクラウドサービス依存カテゴリに属する理由です。デスクトップクライアントは、中央管理された通信サービスに参加していました。その更新経路、組織がアプリを提供していたサーバー、ホスト型管理、外部コードリポジトリ、証明書インフラストラクチャ、エンドポイントセキュリティサービス、脅威インテリジェンスチャネルすべてが結果に影響を与えました。アプリケーションはローカルで実行されましたが、信頼の決定はリモートで組み立てられました。
このインシデントは、単純な被害者数にも抵抗します。ディスク上の脆弱または汚染されたパッケージは、完全な多段階侵入と同じではありません。シェルコードをブロックするセキュリティ製品は、検出されない感染と同じではありません。偵察インフラストラクチャとの接触は、攻撃者が最終的なペイロードを配信した証拠にはなりません。広範な配布は体系的な露出を生み出しましたが、攻撃者は依然として追加のアクションのために特定のエンドポイントを選択するメカニズムを保持していました。厳密な説明責任の説明は、これらの状態を区別しなければなりません。
あるサプライチェーン侵害が別の侵害に到達した
3CX への最初の経路自体が侵害されたソフトウェアでした。Mandiant の調査によると、従業員が 2022 年に退職した取引アプリケーション X_TRADER を個人のコンピュータにインストールしていました。そのインストーラは Trading Technologies の Web サイトからダウンロードされ、有効な Trading Technologies の証明書で署名されており、Mandiant が VEILEDSIGNAL と呼ぶマルウェアを含んでいました。その後、攻撃者は従業員の 3CX 資格情報を盗み、個人のマシンが侵害されてから 2 日後に VPN を通じて企業環境にアクセスし、横移動して最終的に Windows と macOS の両方のビルド環境に到達しました。Mandiant は、これが調査した中で別のサプライチェーン侵害に直接つながった最初のサプライチェーン侵害であると、4 月 20 日のテクニカルレポートで説明しました。
この連鎖は、後続の制御の失敗を許容することなく、タイムラインを拡大します。X_TRADER インストーラは、敵対的な上流の入力でした。これは、攻撃者がどのように侵入したかを説明するのに役立ちます。3CX のビルドおよびリリースプロセスの整合性を他者の運用責任にすることはできません。逆に、従業員が個人のマシンを使用したという事実だけでは、一人の選択が顧客侵害の根本原因であると確立することはできません。企業の資格情報が感染したエンドポイントから機能し、アクセス制御がそれを受け入れ、横移動が成功し、マルウェアがビルド環境に存続し、リリースプロセスが結果のアーティファクトに署名して配布しました。各遷移では、制御境界が失敗するか、不十分な証拠を提供する必要がありました。
3CX 自身の4 月 20 日のインシデントアップデートによると、攻撃者は横移動中にリバースプロキシツールを展開し、Windows ビルド環境でシステムレベルの永続性を持つランチャーとダウンローダーを使用し、macOS ビルドサーバーにバックドアを設置しました。この一連の流れは、コンパイル時に取得されたオープンソースの依存関係に毒を盛っただけではなく、本番システムが侵害されたことを確立します。また、これによって人事ポリシーは教訓の一部に過ぎなくなります。管理されていないデバイスからの企業資格情報の使用を防ぐこと、より強力なデバイスアイデンティティを要求すること、VPN アクセスを制限すること、ビルドインフラストラクチャをセグメント化すること、特権的なビルドホストを監視することは、すべて初期感染と署名された顧客リリースの間に位置します。
連鎖における 2 つの署名は特に示唆的です。X_TRADER の署名は、最初のインストーラが承認された署名機能を通過したことを示しました。3CX の署名は、下流のアプリケーションについて同じことを示しました。どちらの証明書も、狭い暗号学的な意味では嘘ではありませんでした。周囲の保証主張は、署名するものを決定するシステムが転覆されていたため不完全でした。コード署名キーを最終的なセキュリティ制御として扱う組織は、そのキーに供給される可能性のあるすべてのものにリリース儀式を依存させています。
したがって、安全なリリース設計には権限の分離が必要です。開発者の資格情報それ自体が本番アーティファクトを変更してはなりません。ビルドホストは、ジョブを完了したという理由だけで公開できてはなりません。署名サービスは、認証された任意のマシンからの不透明なファイルではなく、検証可能なアーティファクトアイデンティティとポリシー決定を受け取るべきです。リリースの来歴は、ソースリビジョン、レビューされた変更、宣言された依存関係、ビルドレシピ、分離されたビルダー、テスト結果、署名者、公開イベントを結びつけるべきです。これらの記録はすべての高度な侵入を防ぐわけではありませんが、不正な差異を可視化し、調査者に一貫した履歴を提供します。
連鎖的な侵害は、サプライヤーのデューデリジェンスも変えます。顧客は、通信ベンダーに対して、従業員が侵害されたサードパーティソフトウェアに遭遇しないことを保証するよう賢明に要求することはできません。本番ビルドが通常の企業アクセスから分離されているか、個人のデバイスが機密システムに認証できるか、ビルド資格情報が短命か、リリースアーティファクトが独立して分析されているか、ベンダーがリリースを迅速に取り消せるかを尋ねることはできます。これらは、完璧の約束ではなく、制御設計と証拠に関する質問です。
署名された Windows アプリケーションが行ったこと
Windows のチェーンは、馴染みのあるコンポーネントを見慣れない配置で使用しました。研究者は、3CX パッケージ内に悪意のあるffmpeg.dllを発見しました。署名された Desktop App がそれをロードすると、そのライブラリは改ざんされたd3dcompiler_47.dllに隠されたコードを抽出して復号しました。後者のファイルは、署名されたコンテンツの後にデータが追加されていたにもかかわらず、有効な Microsoft の署名を保持していました。これは、Microsoft が悪意のあるペイロードに署名した証拠ではありませんでした。それは、署名検証が適切なオブジェクト境界で解釈され、構造解析と組み合わせなければならないことを思い出させるものでした。
Huntress はローダーを再構築し、埋め込まれたコードが外部インフラストラクチャに接触する前に 7 日間の遅延があったことを技術調査で報告しました。この遅延は、ソフトウェアが表面的なテストを生き延びるのを助け、インストールとエンドポイント製品がフラグを立てるかもしれない後の動作を分離しました。また、最近更新されたホストがクリーンでなくても静かに見える理由を説明しています。展開直後に即時のネットワーク接続のみをチェックする防御者は、関連するタイマーが期限切れになる前に調査を終了してしまう可能性があります。
Windows では、次の段階が公開 GitHub リポジトリにアクセスし、アイコンファイルを取得しました。画像は有効でしたが、暗号化された設定データがそれらに追加されていました。復号されると、そのデータはコマンドアンドコントロールの場所のセットを提供しました。Volexity のリバースエンジニアリングとインフラストラクチャのタイムラインによると、ドメインは早くも 2022 年 11 月に登録され、暗号化された 3CX URL を含むリポジトリコミットが 12 月 7 日に現れました。これらの日付は準備と可能性のあるテストを示していますが、顧客のエンドポイントが 12 月に同じペイロードを受け取ったことを証明するものではありません。
偵察段階では、マシン識別子を収集し、その後、ホスト名、ドメイン、OS バージョン、Chrome、Edge、Brave、Firefox のブラウザ履歴を読み取るコンポーネントを取得しました。CISA のマルウェア分析レポートは、最近訪問した URL には、資格情報や支払い情報などの機密パラメータが含まれている可能性があると警告しました。CISA はまた、分析された情報窃取ツールには独自の流出機能が含まれていなかったため、別のコンポーネントが送信を処理したと示唆しました。これは有用な境界です。コンポーネントは機密ブラウザデータを収集できましたが、ファイルの存在だけでは、どのデータが最終的に特定のエンドポイントから流出したかを証明できません。
macOS パッケージは、改変されたlibffmpeg.dylibと、関連するが同一ではない通信経路を使用しました。両方のプラットフォームが影響を受けており、これは Mandiant が両方のビルド環境に到達したという調査結果と一致します。プラットフォーム固有の違いは、対応中に重要です。Windows のみのハッシュスイープでは macOS 環境をクリーンにできず、GitHub ステップ用に書かれたネットワーククエリが macOS の設定経路をカバーするとは限りません。
研究者はチェーンの一部に SmoothOperator、SUDDENICON、ICONIC、ICONICSTEALER などの複数の名前を付けました。これらのラベルは分析上の便宜であり、被害への影響の個別の証拠ではありません。組織が行動ではなく名前を追跡すると、対応の質問を曖昧にする可能性があります。耐久性のある証拠は、パッケージのバージョンとハッシュ、異常なライブラリのロード、プロセス注入またはシェルコードの実行、DNS および HTTP アクティビティ、ブラウザデータベースへのアクセス、後続のペイロードの組み合わせです。顧客は、その一連の動作を自身のエンドポイントで保存する必要がありました。
公的な確認前の静かな期間
公開タイムラインには 2 つの異なる時計があります。1 つはセキュリティ製品が動作を観測した時を記録します。もう 1 つは、3CX がインシデントレポートと見なす情報を受け取り、行動したと述べている時を記録します。それらは重複しますが、同一ではありません。
SentinelOne は、その行動ベースのシステムが 3 月 22 日に 3CXDesktopApp に関連する急増を見始めたと述べています。その3 月 29 日の開示では、デフォルトの隔離、多段階チェーン、署名されたバイナリ、GitHub でホストされたマテリアル、最終的な情報窃取ツールが説明されていました。Palo Alto Networks は後にUnit 42 脅威ブリーフで、Cortex XDR が 3 月 9 日から 3 月 30 日の間に 127 の顧客で 3CX プロセスによるシェルコード実行の試みをブロックしていたと報告しました。これらの遡及的な範囲は、公表前に関連するテレメトリが存在していたことを示しています。各ベンダーが共通のサプライヤービルドが発生源であると理解した時期や、正確にいつ 3CX に連絡したかを確立するものではありません。
Sophos の維持されているインシデント分析は、3 月 22 日から始まる可能性のある誤検出についての顧客の議論を記録しています。その表現はその瞬間の不確実性を捉えています。セキュリティ製品は実際に誤検出を生成し、人気のある署名されたアプリケーションが良性の理由で疑わしいように見える動作を実行する可能性があります。サンプル、プロセスツリー、またはネットワーク証拠のない単一のアラートは、グローバルなサプライチェーンインシデントを宣言する正当な理由にはならないかもしれません。しかし、同じ新しくリリースされた署名済みアプリケーションから同様の動作を観測する複数の組織は、単に同じ弱い事実の複数のコピーではありません。相関は証拠の重みを変えます。
CrowdStrike は、3 月 29 日に OverWatch ハンターが署名されたアプリから発生する予期しない活動を観測し、リバースエンジニアリングによって悪意のあるインストーラが確認されたと述べています。その公開アカウントでは、この活動を LABYRINTH CHOLLIMA と呼ぶ北朝鮮に関連するクラスターに帰属させました。3CX の後の4 月 1 日のアップデートでは、3 月 29 日に第三者報告を受け取り、その後 Mandiant を雇ったと述べています。3 月 30 日に、問題を公に認め、削除とフォールバックの指示を出しました。
防御可能な結論は、この時系列の最も劇的なバージョンよりも狭いものです。最初の公に文書化された顧客の議論と 3CX の確認の間には、およそ 1 週間がありました。公の記録は、早期のエンドポイント警告、それらが誤検出であるかどうかの混乱、そして後のベンダー確認を示しています。すべての私的なメール、サポートチケット、電話、サンプル転送、内部割り当て、エスカレーション決定を明らかにするものではありません。したがって、3CX のアラート処理システムの精査を支持しますが、幹部が 7 日間も決定的な証拠を故意に無視したという確信的な主張を支持するものではありません。
その区別は、このケースをより有用にします。教訓が一人の意思決定者の悪意を証明することに依存しているなら、それは広く伝わりません。教訓が、通常のサポートの経済性が低頻度で高影響のイベントの認識を遅らせる可能性があるということなら、それはほぼすべてのソフトウェアサプライヤーに当てはまります。
エンドポイントテレメトリが顧客の警報となった
侵害されたリリースは、ベンダー境界を越えて最も強力な従来の許可信号を伴っていました。それは期待されており署名されていました。行動テレメトリが対抗信号を提供しました。プロセスは異常なライブラリをロードし、実行可能メモリを準備し、シェルコードを実行し、テレフォニーに通常必要とされないリポジトリにアクセスし、新たに観測されたドメインに接触し、ブラウザデータにアクセスしました。これらのアクションは、信頼がそれを許可した後にソフトウェアが何をしたかを説明していました。
Elastic のSUDDENICON 分析は、指標と行動検索の違いを示しているため価値があります。既知の悪意のあるハッシュと GitHub 解決のためのクエリを提供しましたが、さらに、3CX 署名されたプロセスが自身のアプリケーションディレクトリから信頼できないライブラリをロードする、より一般的なクエリも提供しました。後者は、ファイル名やハッシュが変更されても生き残る可能性が高いです。Elastic はまた、親アプリケーションが署名されていることだけを理由にプロセス注入アラートの例外を作成しないよう顧客に警告しました。
そのアドバイスは、一般的な組織の障害モードを暴露します。エンドポイントアラートは通話ソフトウェアを中断させ、ユーザーの苦情を引き起こし、ただちにサポートコストを発生させる可能性があります。それが防ぐ仮想の攻撃は見えないかもしれません。したがって、管理者はアプリケーションを許可リストに登録して復旧させるよう圧力に直面します。ベンダーが信頼され運用上重要であるほど、その圧力は強くなります。悪意のある署名付き更新は、技術的な信頼だけでなく、既知の製品を再び動作させようとするサービスデスクのインセンティブも悪用します。
Huntress は逆のトレードオフを明示しました。同社は、バイナリが既知の悪意のあるハッシュと一致する 2,783 件のインシデントレポートを送信したが、すべての影響を受けたホストを自動的に隔離しなかったと述べました。そうすることで顧客の電話通信がオフラインになる可能性があるためです。これは受動性ではありませんでした。封じ込めには独自の安全性と継続性のコストがかかるという運用上の判断でした。顧客は依然としてソフトウェアを削除し、調査し、経路を切り替える必要がありました。この例は、対応の自動化にコンテキストが必要な理由を示しています。制御は危険を正しく識別できますが、それを封じ込める方法については依然として人間の判断が必要になる場合があります。
テレメトリはまた、顧客が後で何を証明できるかを決定しました。プロセス、ライブラリ、DNS、ネットワーク、ファイルイベントが保持されているホストは、ブロックされた実行と成功したビーコン送信を区別できました。ウイルス対策のポップアップのみで集中管理された記録のないホストは、ファイルが疑わしいことを知ることはできても、後続の段階が実行されたかどうかはわかりませんでした。したがって、ログ記録は対応速度と最終的な顧客通知の信頼性の両方に影響を与えました。それは単なるフォレンジックの贅沢ではありませんでした。
都合の悪い報告の経済学
「abuse contact」というフレーズは通常、スパム、フィッシング、マルウェアホスティング、脆弱性開示のためのメールアドレスを連想させます。その根底にある機能はより広範です。それは、サービスが正常に運用されていることを好む組織に、外部者が新たな証拠を課すための経路です。その経路には経済的な設計があります。
すべての受信アラートはトリアージ時間を消費します。ほとんどのサプライヤーは、スキャナーのノイズ、重複した発見、弱い自動化された主張、製品の競合、本物の誤検出を受け取ります。エンジニアリングの注意は希少ですが、サポートチームは量、解決時間、顧客満足度で評価されます。すべてのアンチウイルスに関する苦情をインシデントコマンドにエスカレーションすることは、高コストで混乱を招きます。毒入りリリースを明らかにするまれな報告をエスカレーションしないと、顧客にはるかに大きなコストが外部化される可能性があります。サプライヤーは調査の即時のコストを支払いますが、回避された害は、直接目にすることのない組織全体に分散されます。
この不均衡は予測可能な摩擦を生み出します。報告者は、問題の再現、セキュリティベンダーへの連絡、ログの収集、ハッシュの提供、または一次サポートを待つよう求められます。それぞれの要求は単独では合理的かもしれません。連続して発生すると、報告経路は報告者の持続性のテストに変わる可能性があります。セキュリティオペレーションセンターを持つ大企業は押し続けることができます。小規模なリセラーや顧客は、アプリケーションを削除し、アラートを抑制するか、次に進むかもしれません。ベンダーはその後、偏ったサンプルを見ることになります。最も強力または最も騒々しい報告であり、必ずしも最も初期のシグナルではありません。
3CX は後に、このプロセスについて重要な認めをしました。5 月に、同社のアラート処理計画は「大幅な改善が必要」と書き、専用のセキュリティおよびアンチウイルスフォーラム、24 時間監視、スタッフトレーニング、報告の可視状態、内部エスカレーション、公開フィードバックを導入しました。その新しいアラート手順は、より迅速な応答、透明性、迅速なエスカレーション、より速い解決を求めました。これらは企業が表明した手順であるため、プロセス設計の変更を証明するものであり、それ以降のプロセスがどれほど一貫して運用されているかを証明するものではありません。
この手順はまた、残存する緊張を例示しています。報告者に対して、最初にアンチウイルスベンダーに連絡し、次に 3CX フォーラムに投稿し、プライベートフォームに記入し、後でベンダーの返信を追加するよう指示しています。検出器との調整は有用です。セキュリティ製品はサンプルと分析コンテキストを提供できます。しかし、製品サプライヤーは、他社のベンダーの確認を、レポートの保存と内部相関のための実際的な前提条件とすべきではありません。サプライヤーは、リリースハッシュ、ビルド記録、署名イベント、ソース履歴、他の顧客レポートに独自にアクセスできます。個別に曖昧な複数のアラートが 1 つのリリースを指していることを認識できる唯一の当事者である可能性があります。
成熟した受付システムは、受け入れと裁定を分離します。報告者に摩擦の少ない経路を提供し、提出物と添付ファイルを即座に保存し、主張されたバージョンとハッシュをリリース記録と照合し、類似の報告をグループ化します。独立した顧客が同じ動作を報告した場合、ファイルが新しくリリースされた場合、信頼されたプロセスが宣言されていないネットワークアクションを実行した場合、または署名が行動証拠と矛盾する場合に、重大度が上昇します。チームはケースを未確認とラベル付けしつつ、それを破棄しないことができます。内部比較を開始しながら、さらなる証拠を求めることができます。
応答クロックは、チケットのティアだけでなくリスクに結び付けられるべきです。本番署名されたバイナリまたは更新チャネルを含むレポートは、影響が不確実であっても、迅速に確認応答と指名された所有者を得るに値します。事前定義されたしきい値は、製品セキュリティ、リリースエンジニアリング、エンドポイントスペシャリスト、コミュニケーションおよび法務スタッフを召集すべきです。しきい値は、2 人の独立した顧客、1 つの高信頼度の行動トレース、または現在のダウンロードが既知の良好なビルドと異なるという証拠である可能性があります。正確なルールは異なりますが、重要な点は、厄介なレポートが到着する前にそれを決定することです。
公開チャネルには利点とコストがあります。顧客が他の人々も同じ動作を経験していることを確認でき、これにより相関が生まれ、静かな却下が制約されます。また、機密のテレメトリを露出させ、推測を助長し、報告者に評判の衝突を恐れさせる可能性もあります。良いシステムは、顧客データを露出させることなく調査を認める公開ステータスページと、機密の提出経路を組み合わせます。証拠が許せば、影響を受ける正規のバージョン、ハッシュ、封じ込め手順、更新時間を公開します。
2023 年 3 月のエピソードは、abuse contact の経済学がビルドセキュリティと並ぶべきであることを示しています。完璧な報告用メールボックスは侵害されたビルダーを修復できません。強化されたビルダーは、新たな侵害が決して発生しないことを保証できません。予防が失敗した場合、外部検出からサプライヤーのアクションまでの時間は、顧客の被害の制御可能な部分となります。
広範な配布、選択的な後続アクセス
初期の報道では、3CX が 60 万以上の顧客と 1200 万ユーザーの基盤を説明したため、3CX を最大級のソフトウェアサプライチェーンイベントと比較することがよくありました。これらの数字は潜在的なリーチを示しており、測定された侵害エンドポイントの数ではありません。Palo Alto Networks の外部スキャンでは、3CX 製品に関連する数十万のアドレスが見つかりましたが、露出したサーバーは Electron デスクトップクライアントがインストールされていることを証明するものではなく、ましてや悪意のある段階が実行されたことも証明しませんでした。
公の証拠は代わりにファネルを支持します。侵害されたインストーラは広く利用可能であり、自動更新がそれらを配布する可能性がありました。多くのエンドポイントが汚染されたコンポーネントをロードしました。行動ベースの製品は、シェルコードまたは後続段階が実行される前に一部をブロックしました。偵察段階ではホストとブラウザの情報が収集されました。コマンドインフラストラクチャはその後、別のペイロードを返すかどうかを決定できました。Volexity は、一元化された選択と一致するマシン識別子の 1 回限りの処理を発見しました。
Kaspersky は、観測された集団内で Gopuram と呼ぶバックドアが 10 台未満のマシンに展開され、暗号通貨関連組織が標的に含まれていたと報告しました。その標的分析は、選択的な後続アクションを支持します。どのセキュリティベンダーもすべてのエンドポイントを把握しているわけではないため、これはキャンペーンをグローバルに制限するものではありません。また、選択されなかったシステムを無害にするわけでもありません。偵察データと機能する足場は依然として侵害を表していました。
ESET は、クロスプラットフォーム分析で、関連するマルウェアとインフラを Lazarus エコシステムに結び付けました。Mandiant は、UNC4736 クラスターが北朝鮮との関連を持つと高い信頼度で評価しました。CrowdStrike は異なるクラスター名を使用しました。これらの重なり合う評価は、裏付けのないラベルよりも強力ですが、帰属によって直接的な制御所有者が変わるわけではありません。オペレーターが国家機関であれ、請負業者であれ、犯罪グループであれ、顧客はソフトウェアを封じ込める必要がありました。3CX は動機に関係なく、ビルドおよび報告システムを保護する必要がありました。
このファネルはインシデントの表現を形成すべきです。「影響を受けたバージョンがインストールされた」は露出状態です。「悪意のあるライブラリが実行された」は別の状態です。「偵察データが返された」および「後続ペイロードが配信された」はより高い影響の状態です。組織は、証拠が支持する最も高い状態を報告し、欠落しているテレメトリを明示的に説明すべきです。4 つすべてを「侵害された」にまとめると、一部のケースを誇張する一方で、他のケースについてほとんど知られていないことを隠す可能性があります。
ローカルクライアントがクラウド依存関係チェーンを運んだ
3CX は、顧客がさまざまな方法でホストできる通信システムを販売していました。一部は 3CX ホスト型サービスを使用し、他は自己ホスト型またはオンプレミスシステムを運用していました。3 月 30 日の指示はこの分割を反映していました。3CX はホスト型サーバーを自身で更新できましたが、自己管理オペレーターはサーバー更新をインストールする必要がありました。エンドポイントでは、両方のモデルで依然として Electron アプリケーションに対するアクションが必要でした。
依存関係チェーンは契約上の境界を越えました。組織はリセラーやマネージドサービスプロバイダを通じて購入し、パブリッククラウドで PBX を管理し、そのサーバからデスクトップアプリを配布し、別のマネージドセキュリティサービスでエンドポイントを保護し、緊急時のプログレッシブ Web アプリの代替のためにブラウザベンダーに依存することがありました。従業員は 1 つの通話ツールを体験しました。インシデント対応者は、それぞれが継続性と証拠の一部を管理する複数の組織を見ました。
したがって、プログレッシブ Web アプリケーションは製品の好み以上のものでした。それは多様性のメカニズムでした。3CX の 4 月のガイダンスでは、ブラウザサンドボックス内で動作し、影響を受けたデスクトップバイナリを必要としない PWA を使用するよう顧客に奨励しました。同社のUpdate 7A 計画では、その後 PWA がより顕著に推進されました。ただし、フォールバックは、ID、DNS、ブラウザサポート、通話ルーティング、ユーザー指示がすでに機能している場合にのみ有用でした。サプライチェーンの緊急時に初めてテストされる代替手段は、侵害されたクライアントとは無関係な理由で失敗する可能性があります。
これがクラウドサービス依存の実際的な意味です。単にリモートベンダーがオフラインになる可能性があるというだけではありません。信頼されたサービスが、障害モードがユーザーのマシンに追随するローカルコンポーネントを配信できるということです。サプライヤーはホスト型コントロールプレーンを復旧しても、顧客には依然として数百のエンドポイントの調査が残るかもしれません。中央サービスはダウンロードを削除できますが、顧客のエンドポイント製品が保持しなかったログを再作成することはできません。
顧客は、ベンダー名ではなく機能ごとに依存関係をマッピングすべきです。ビジネス通話の場合、通常の経路、更新経路、ID 経路、緊急経路、証拠経路を知る必要があります。デスクトップクライアントを削除した場合、人々は発着信できますか？緊急および顧客サービス機能は継続できますか？勤務時間外に誰が削除をプッシュできますか？どのプロバイダーがプロセス注入を確認できますか？誰が DNS 履歴を保持していますか？ブラウザデータが露出した可能性がある場合、誰が資格情報をローテーションする権限を持っていますか？
そのマップはまた、契約を明確にします。リセラーのサポート契約はアップタイムを定義するかもしれませんが、セキュリティシグナルの転送についてはほとんど述べていません。エンドポイントプロバイダーは、顧客ではなくマネージドサービスプロバイダーに警告するかもしれません。クラウドホストはネットワークデータを短期間しか保存しないかもしれません。調達では、通知経路、証拠保持、緊急連絡先、隔離権限、サプライヤーインシデント中の協力を指定すべきです。さもなければ、各当事者は、顧客が一貫した回答を待つ間、狭いサービス義務を満たすことができます。
説明責任は最初の感染への近接性ではなく、制御に従う
攻撃者は、ソフトウェアを意図的に侵害し、信頼された配布を使用して下流のシステムに到達したことに対して主な責任を負います。北朝鮮に関連するクラスターへの帰属は戦略的対応と脅威モデリングに情報を提供できますが、説明責任の分析に吸収されるべきではありません。セキュリティガバナンスが存在するのは、悪意のあるアクターが契約や制御フレームワークを尊重しないからです。
3CX は、企業アクセス経路、ネットワークセグメンテーション、ビルド環境、署名と公開プロセス、リリーステスト、顧客通知、失効決定、および自社製品に関するセキュリティレポートの受け入れを管理していました。同社自体が X_TRADER 侵害の被害者でしたが、同時に、下流のアーティファクトを保証したサプライヤーでもありました。これらの役割は共存します。被害者性は悪意のあるコードが侵入した理由を説明しますが、サプライヤーの説明責任は、なぜ侵害が本番に到達できたのか、そして企業がそれをどれだけ迅速に認識して封じ込めたかを問います。
Trading Technologies は、上流の侵害中に、退職した X_TRADER アプリケーションの Web サイトと署名プロセスを管理していました。Mandiant の調査結果により、チェーンのそのコンポーネントが関連性を持つことになります。ここで使用されている公開記録は、完全な Trading Technologies のインシデントレポート、契約履歴、または裁定された調査結果を提供していないため、最終的な法的割り当てを支持することはできません。それはガバナンスの教訓を支持します。退職したダウンロード可能なソフトウェアと残余の署名機能は、削除、失効、または検証可能に無効化されるまでセキュリティ資産であり続けます。
顧客は、展開ポリシー、エンドポイント検出、ローカル許可リスト、資格情報の衛生、ネットワーク記録、フォールバック通信、インシデント調査を管理していました。3CX のビルダーを管理しておらず、使用前にすべての署名済み更新をリバースエンジニアリングすることは合理的にできませんでした。したがって、彼らの義務はサプライヤーの安全な開発プログラムを複製することではありませんでした。それは、発行元の身元をエンドポイント制御の唯一のものにすることを避け、クライアントがどこで実行されたかを把握し、サプライヤーの保証が失敗したときに行動できるだけのテレメトリを保存することでした。
セキュリティベンダーは、自社製品がどのように動作を検出、ブロック、説明、エスカレーションするかを管理していました。シェルコードをブロックしたベンダーは、帰属が確定する前であっても被害を軽減しました。使用可能な証拠を提供し、誤検出リスクを管理する義務もありました。プロセスチェーンのない不可解な高重大度のアラートは、顧客を除外に追いやる可能性があります。検出プロバイダーは、緊急サプライヤー連絡経路と、顧客 ID を露出させることなく、同じ署名された発行元を顧客間で相関させる方法を持つべきです。
マネージドサービスプロバイダーとリセラーは、重要な翻訳層に位置していました。彼らは多くの場合、どの顧客がアプリを持っているか、エンドポイントアラートを受け取り、展開権限を持っているかを知っていました。個々の中小企業ではできない弱いシグナルを集約できました。この立場は、通常のライセンスサポートとは別のセキュリティエスカレーション経路を維持し、封じ込めがテレフォニーを中断する可能性がある場合に顧客に知らせる責任を生み出します。
GitHub、ドメインレジストラ、ホスティング会社、証明書エコシステム参加者は、指標が知られるとインフラを無効化したり信頼を失効させたりするのに役立ちました。彼らの対応はキャンペーンを妨害する可能性がありますが、テイクダウンは封じ込めであり、ビルドの整合性の代替ではありません。まだリリース経路を制御している攻撃者は、リポジトリとドメインを変更できます。説明責任は、そのアクションが観察可能であるという理由だけで、最も目に見えるインフラ仲介者に移行すべきではありません。
したがって、責任は共有されていますが薄められていません。各当事者は、運用できた制御と保存できた証拠に基づいて判断されるべきです。ベンダーはビルド保証を顧客に移転できず、顧客はローカル対応をベンダーに移転できず、検出プロバイダーはアラートの明確さをフラグを立てたプロセスに移転できません。
信頼できるリリースが証明できるべきこと
最も強力な修復は、マルウェアハッシュの長いリストではありません。それは、特定のアーティファクトがなぜ存在し、なぜ顧客に届くことを許されたのかに答えられるリリースシステムです。その答えには、インシデント前に生成された証拠が必要です。
NIST のセキュアソフトウェア開発フレームワークは、保護された開発環境、ソフトウェアコンポーネントの来歴、安全なリリースプラクティス、脆弱性対応、根本原因の作業を求めています。共同の Enduring Security Framework開発者ガイダンスは、専用の開発システム、制限されたアクティビティ、強化されたビルド環境、事前承認されたツール、アクセス制御、ログ記録と検証という、実践的な分離についてさらに進んでいます。これらは 3CX に関するインシデント固有の評決ではありません。インシデント後のプログラムをテスト可能にするための基準を提供します。
高影響度のデスクトップリリースの場合、ビルド環境は通常の企業ブラウジングやメールから隔離されるべきです。管理者は、フィッシング耐性のある別の ID と管理デバイスを使用すべきです。ネットワーク出力は狭く定義されるべきであり、リバースプロキシを起動したり宣言されていないドメインにアクセスしたりするビルドサーバーは、別のログエントリではなくインシデントを生成すべきです。資格情報は短命で、1 つのステージにスコープされるべきです。単一の侵害されたワークステーションがソースを提供し、ビルドを承認し、署名し、公開してはなりません。
ビルドは再現可能であるか、少なくとも入力が宣言され保持されるほど密閉的であるべきです。すべてのサードパーティバイナリは、インベントリされ、構造的にチェックされ、既知のソースと比較されるべきです。静的分析だけでは不十分です。なぜなら、危険な動作は暗号化されたり遅延される可能性があるからです。動的分析では、パッケージ化されたアプリケーションを監視環境で、時間ベースのゲートを通過し更新動作を実行するのに十分な時間実行すべきです。7 日間のスリープは、加速されたクロック、スナップショット復元、古いインストールをシミュレートするテストへの直接的な議論です。
署名ステップはポリシー証拠を消費すべきです。アーティファクトが承認されたビルダーからのものであり、承認されたソースリビジョンと一致し、期待されるコンポーネントを含み、テストに合格し、独立した承認を受けたことを検証すべきです。署名者は、ダイジェストとリリース ID を改ざん耐性のあるストアに記録すべきです。公開は、顧客がダウンロードするオブジェクトが承認され署名された正確なオブジェクトであることを独立して検証すべきです。
現在のSLSA 脅威モデルは、ソースの整合性とビルドの整合性を区別し、ビルドプロセスの侵害、アーティファクトの公開、配布を個別の脅威として特定しています。この用語はここで有用です。有効な署名は、署名後のアーティファクトを改ざんから保護できますが、ビルドプロセスが不正な入力を使用したかどうかについては何も述べていません。来歴により、検証者は「誰がこれに署名したか？」だけでなく、「どのビルダーが、どのレビューされたソースとレシピからそれを生成したか？」を尋ねることができます。
すべての顧客が豊富な来歴を直接検証するわけではありません。大口購入者やプラットフォーム事業者は、検証をゲートウェイにすることができますが、小規模組織はオペレーティングシステム、パッケージマネージャー、セキュリティサービス、またはリセラーに依存する可能性があります。サプライヤーは依然として、これらの仲介者が検証できる十分な証拠を公開し、ハッシュ、バージョン、署名 ID、失効ステータスを含む安定したリリースフィードを提供すべきです。1 つの専門家による検証が、各購入者に製品のリバースエンジニアリングを求めることなく多くの購入者を保護できる場合、保証はスケールします。
最後に、リリースシステムには緊急ブレーキが必要です。ベンダーは、配布を停止し、署名 ID を失効させ、既知の良好なハッシュを公開し、ホスト型および自己管理の顧客に通知し、所有権をその場しのぎで割り当てることなく継続性の経路を提供できるべきです。この演習には、ビルドシステム自体が信頼できないという不快なケースを含めるべきであり、「クリーンな更新を出荷する」ことが最初に想定される対策であってはなりません。
顧客がインシデント前およびインシデント中に制御できたこと
顧客は 3CX 内部の最初の侵害を防ぐことができなかったため、そうでないことを示唆するのは不合理です。彼らは、サプライヤーの信頼が自社の環境でどの程度完全に伝播するかを低減することができました。
ソフトウェアインベントリが最初の制御でした。組織は、3CX を使用していることだけでなく、どのエンドポイントに Electron クライアントがあるか、どのバージョンがインストールされているか、ユーザーがユーザーごとにインストールしたか、そしてどのサーバーがパッケージを提供しているかを把握する必要がありました。中央パッケージ展開のみに基づくインベントリでは、ユーザープロファイルのインストールを見逃す可能性がありました。エンドポイントクエリ機能により、従業員がアイコンを報告するのを待つ代わりに、ハッシュとバージョンを迅速に見つけることが可能になりました。
更新ポリシーが 2 番目でした。自動更新は既知の脆弱性にさらされる時間を短縮するため、それらを一律に無効にすると、1 つのサプライチェーンリスクを多数のパッチ適用リスクと交換することになります。バランスの取れたアプローチでは、高影響のデスクトップソフトウェアに展開リングを使用します。最初に小規模な監視グループ、次に待機期間の後により広範なリリースを行います。最初のリングには、アプリが開くかどうかの確認だけでなく、実際の行動テレメトリが必要です。緊急のセキュリティ修正はより短い間隔を正当化する場合がありますが、通常の機能リリースはより多くの観察を許容できます。
行動ベースの防止が 3 番目でした。3CX のケースは、署名された発行元の許可ルールが、プロセス注入、異常なライブラリロード、ブラウザデータベースアクセス、または新規のネットワーク宛先を抑制すべきでない理由を示しています。継続性のためにそのようなルールが不可避な場合は、狭く、時間制限があり、セキュリティスタッフによって承認され、監視と組み合わせられるべきです。アプリケーションディレクトリ全体の除外は、署名と矛盾する可能性のある証拠そのものを削除したでしょう。
ネットワークと DNS の記録が 4 番目でした。多くのコマンドドメインは、Microsoft、クラウドストレージ、PBX の用語を模倣していました。明らかに疑わしい名前のみをブロックするのは弱いでしょう。ベースラインにより、テレフォニークライアントが生のコードホスティング場所や新しく見られたドメインをクエリする通常の理由がないことを示すことができました。その後、エンドポイントの記録が不完全であっても、履歴 DNS、プロキシ、ファイアウォールログにより、ホストがインフラに到達したかどうかを確立できました。
インシデント対応には状態ベースの決定が必要でした。影響を受けたバージョンが存在するが実行の証拠がない場合でも、組織は削除とテレメトリカバレッジのレビューを必要としました。シェルコードがブロックされた場合は、その防止を文書化し、代替経路を探索できました。プロセスがコマンドインフラに接触したりブラウザデータベースにアクセスした場合、対応者はエンドポイントを隔離し、証拠を保存し、露出した可能性のある資格情報やトークンをローテーションし、後のアクティビティを調査する必要がありました。最初に ID の露出を特定せずに再イメージングを行うと、攻撃者に有効なクラウドアクセスを残す可能性がありました。
継続性計画が封じ込めを可能にしました。Huntress が自動的に隔離しなかったという選択は、実際の依存関係を反映していました。電話サービスは運用上重要である可能性があります。組織は、PWA、デスクフォン、モバイルクライアント、コール転送、または別の通信チャネルなどの代替手段を事前に承認すべきです。計画では、待てない機能と各フォールバックのセキュリティトレードオフを特定すべきです。継続性は、既知の悪意のあるソフトウェアを実行し続ける理由ではありません。それは、ビジネスが迅速にそれを削除できるようにするものです。
サプライヤーとのコミュニケーションにも所有権が必要でした。誰かが通常の営業時間外にベンダーアドバイザリ、リセラー通知、セキュリティベンダーレポート、セクターアラートを監視する必要がありました。最初の警告を受け取った人は、エンドポイント、コミュニケーション、ビジネスチームを招集する権限が必要でした。調達担当者だけでは、進行中のソフトウェア侵害中にはほとんど十分ではありません。
これらの制御は、汚染された更新の責任を顧客に転嫁するものではありません。依存関係リスクには、異なる層に 2 人の所有者がいることを認識しています。生産者はリリースを信頼できるものにしなければならず、顧客は 1 つの生産者の保証が絶対的でないように自社の環境を設計しなければなりません。
修復は運用証拠が存在するまでは主張に過ぎない
調査後、3CX は 7 部構成のセキュリティプログラムを発表しました。その4 月 26 日の概要では、強化および隔離されたビルド環境、新しいエンドポイント監視、オフサイトの 24 時間脅威ハンティング、より厳格なアクセス制御、より強力な静的分析と動的分析、コード署名と監視の変更、継続的な Mandiant レビュー、ペネトレーションテスト、危機管理改革、新しいネットワークオペレーションおよびセキュリティ機能について説明されました。これらのアクションは、インシデントで特定された主な障害経路に対応しています。
同社は後にVersion 20 リリースアカウントで、ネットワークと専用ビルド環境を再構築し、監視とアクセスの変更を実装し、Electron デスクトップアプリから移行したと述べました。これは有用な進捗報告ですが、主に自己証明のままです。制御の存在は、その運用上の有効性とは異なります。関連する質問は、管理されていない資格情報が依然として本番に到達できるか、すべてのリリースが独立して検証されているか、疑わしいビルダーの出力がテストされているか、アラート演習が定義された応答クロックを満たしているかどうかです。
その後、いくつかの独立した製品証拠があります。3CX は、2023 年 11 月から 2024 年 9 月の間に実施された 4 回のレビューをカバーする2025 年 Mandiant 評価概要を公開しました。それによると、評価者はソースアクセス権を持ち、静的および動的テストを使用し、1 つのクリティカルおよび 1 つの高リスクの問題を発見し、修復を検証したとされています。これは、実質的な製品テストが行われ、特定された発見が再テストされたという主張を支持します。それ自体では、すべてのビルド整合性またはアラート処理制御を独立して認証するものではありません。
この区別は皮肉として解釈されるべきではありません。修復保証は自然に層状に発展します。企業は設計を発表し、展開し、テストし、測定し、外部評価を招き、顧客が判断するのに十分な結果を公開します。3CX の後の開示は、セキュリティを真剣に受け止めるという一般的な約束よりも多くの証拠を提供します。残りの説明責任のタスクは、これらの開示を測定可能なリリースおよびインシデントの結果に結び付けることです。
有用な指標には、隔離された短命のワーカーでビルドされたリリースの割合、検証された来歴を持つ割合、ビルド環境でブロックされた不正な出力の試行、署名ポリシーの例外、高リスクの外部レポートを確認するまでの時間、顧客間でレポートを相関させるまでの時間、侵害されたビルダー演習の結果が含まれます。集約された公開は防御の詳細を暴露する必要はありません。制御が繰り返し機能すること、ツールが購入されたことだけではないことを示すべきです。
取締役会が必要とするのは証拠モデルであり、クリーンなダッシュボードではない
このイベントをレビューする取締役会は、単一数字の保証に抵抗すべきです。「すべてのリリースは署名されている」は、侵害中も真実だったでしょう。「クイックスキャンでマルウェアが検出されなかった」も、遅延段階がアクティブになる前には真実だった可能性があります。指標は正確でありながら、リスクを見逃す可能性があります。
取締役会の最初の質問は権限に関するものです。企業の資格情報と顧客リリースの間に、いくつの独立した決定が分離しているか？ 2 番目は可観測性に関するものです。侵害されたビルダーを明らかにするイベントは何か、そしてそれを午前 3 時に誰が受け取るのか？ 3 番目は矛盾に関するものです。顧客またはセキュリティベンダーが、通常のサポートインセンティブを迂回する監視された経路を通じて、署名されたリリースに異議を申し立てることができるか？ 4 番目は復旧に関するものです。疑わしいビルドシステムを使用せずに、同社は配布を停止し、顧客に安全な代替手段を提供できるか？
証拠はサンプリングされるべきです。取締役またはリスク委員会は、最近の 1 つのリリースを要求し、そのソース承認、依存関係記録、ビルダーID、テスト出力、署名、公開ダイジェスト、外部スキャンを追跡できます。1 つの高重大度の誤検出と 1 つの確認された外部レポートを要求して、処理時間を比較できます。2 人の顧客が同じ有効に署名されたバイナリから疑わしい動作を報告する演習をレビューできます。これはポリシーの文言を可視化された制御チェーンに変えます。
取締役会はまた、不確実性を確認すべきです。影響を受けたバージョン、パッケージを持つホスト、ブロックされた実行、コマンド接触、確認された後続ペイロード、不明なエンドポイントの数は、別々の列に属します。それらを 1 つの「影響を受けた」数にまとめると、顧客コミュニケーションと投資決定に必要な区別が破壊されます。
報酬とパフォーマンス指標は重要です。なぜなら、abuse-contact の経済学は部分的にインセンティブの問題だからです。後で良性と判明する信頼できるレポートをエスカレーションしたことでサポートが罰せられるべきではありません。リリースチームは速度だけで報われるべきではありません。セキュリティスタッフは、最初に顧客の被害を証明することなく配布を一時停止する権限を持つべきです。組織は、顧客が制御不能なダウンサイドを負わないように、まさに調査コストの一部を負担します。
7 日間の警告はシステムの特性である
3CX インシデントで記憶に残る数字は、3 月 22 日の検出急増と 3 月 29 日の公開変曲点の間隔です。それは、すべての早期アラートが明らかに決定的だったという道徳劇に変えられるべきではありません。証拠は、エンドポイントベンダー、顧客、研究者、3CX を横断して熟成されました。重要なのは、その熟成を迅速に行うようにシステムが設計されていたかどうかです。
侵害されたビルドは、2 つの有効な署名を誤った信頼の連鎖に変換しました。7 日間のスリープは、インストールと動作を分離しました。行動ベースのエンドポイントツールは、署名が提供できない証拠を提供しました。顧客とマネージドプロバイダーは、ビジネス通話を中断するかどうかを決定しなければなりませんでした。研究者はサンプルとインフラストラクチャを相関させました。ベンダーは、製品サポートの問題から全社的なインシデントに移行しなければなりませんでした。
説明責任はそれらの移行に存在します。3CX は、署名されたリリースが署名キーの所有以上の意味を持つようにし、ビルダーの周囲の分離を維持し、外部警告に意思決定者への経路を提供する責任がありました。顧客は、エンドポイントでの第二の真実のソースと、削除を可能にする継続性の経路を維持する責任がありました。検出プロバイダーは、異常スコアを人々が行動できる証拠に変える責任がありました。経営陣と取締役会は、都合よく見えなかったレポートに予備の注意を向けるための資金を提供する責任がありました。
より広範なクラウドの教訓は、コードがラップトップ上で実行される場合でも、信頼はサービスとして提供されるということです。更新、証明書、リポジトリ、ホスト型管理、脅威インテリジェンス、ID すべてがそのサービスに貢献します。サプライヤーはターゲットであると同時に、説明責任のある制御所有者でもあり得ます。顧客は無力でなくとも依存する可能性があります。リリースが敵対的であっても、署名は本物であり得ます。
したがって、3CX への最も強力な対応は、すべての更新を疑うことではありません。リリースプロセスからより豊富な証明を要求し、行動を独立したシグナルとして保存し、信頼された製品が間違っている可能性があると聞く組織コストを下げることです。次のサプライチェーン侵害では、これら 3 つの選択の質が、早期警告がチケット、例外、またはインシデントになるかを決定します。