ランサムウェア攻撃の前にセキュリティツールが沈黙するとき何が起きるのか

10月1日、脅威リサーチャーらは、Warlockランサムウェアの背後にいる中国関連グループ(Microsoftは「Storm-2603」として追跡)が、過去2カ月間に少なくとも4つの組織を攻撃していたと報告しました。被害組織には水道事業者と通信事業者が含まれ、ほかに地方自治体の機関と大学も標的になりました。攻撃はいずれも、欧州、アフリカ、中南米のポルトガル語圏・スペイン語圏の国々で発生しています。

侵入経路はオンプレミス版のMicrosoft SharePointだった可能性が高いとみられます。リサーチャーらは、このグループが2025年7月に悪用した「ToolShell」の脆弱性を今も攻撃手段として保持しており、あわせて新しいSharePointの脆弱性も利用していると考えています。ToolShellはMicrosoftが修正プログラムを公開したのと同じ月に悪用された脆弱性です。1年以上前に修正された脆弱性のエクスプロイトでも、手札に加えておく価値は十分にあります。修正が適用されないままのサーバーが、どこかに残っているからです。

私はセキュリティ企業を経営する前、その財務を担当していました。そこで身についた習慣が、あらゆる数字の裏にある前提を読み解くことです。設備は稼働し続けると見込まれ、在庫は売れると見込まれています。この前提が崩れれば、その資産は減損処理の対象になります。

セキュリティ予算にも同じような前提がありますが、それを明文化している企業はほとんどありません。帳簿に載っているツールは、攻撃を受けたときにも稼働しているはずだという前提です。Warlockの攻撃者は、まさにこの前提を狙い撃ちにしました。

潜伏9日、無力化に2時間

重要インフラ事業者を狙ったある侵入事案に、その攻撃パターンが表れています。

攻撃者は7月22日、SharePointサーバーにWebシェルを設置しました。その後1週間でドメインの構成を調べ上げ、秘匿性の高いリモートアクセスを確立しています。さらに、SharePointのサービスアカウントに見せかけたとみられる名前のアカウントを、ローカル管理者グループに追加しました。その後、約1日にわたって記録された活動は、バックグラウンドで動く1つの仕込みコードだけでした。

攻撃者が動いたのは7月31日の未明です。最初に使われたのは、セキュリティソフトを停止させるために作られたツールでした。このツールは、約2時間のうちに少なくとも40台のホストで実行された記録が残っています。続いて攻撃者はWarlockをドメインのSYSVOL共有に配置しました。SYSVOLは、Windowsがすべてのドメインコントローラーに複製し、ドメイン全体から読み取れるようにするフォルダーです。攻撃者は通常のレプリケーションに任せて、少なくとも33台のホストにWarlockを行き渡らせました。リサーチャーらによると、どのホストでも保護機能が失われた直後にランサムウェアが現れたといいます。

計算してみましょう。120分でおよそ40台ということは、平均して3分に1台のペースで端末が保護を失った計算になります。

攻撃者は、データそのものよりも先に、そのデータを監視するツールを狙ったのです。

攻撃者が停止できる予算項目

リサーチャーらが示した事実に基づけば、これはまずパッチ適用とActive Directoryの問題です。パッチ適用とエンドポイントの検知・対応(EDR)は、今も不可欠です。パッチ適用は、このグループが侵入に使った可能性が高い入り口をふさぎます。検知は、異常に気づく唯一のきっかけになることも少なくありません。別の施策の資金を捻出するためにどちらかを削る水道事業者は、割に合わない取引をしています。改ざん防止機能(tamper protection)と既知の脆弱なドライバーのブロックも、あらゆる環境で有効にしておくべきです。そうすれば、攻撃者が防御を停止させる工程は難しくなります。

とはいえ、攻撃者が停止できる対策の価値は、予算項目に書かれた金額より小さくなります。

会計の世界では、これを減損と呼びます。ある出来事によって、資産が帳簿価額どおりの価値を生めなくなった可能性が出てきたら、減損テストを行います。テストに通らなければ、帳簿価額を切り下げます。資産に価値がなくなるわけではありません。帳簿が過大に評価していただけです。セキュリティ支出の大半は資本化されず費用として処理されるため、このテストを求める監査人はいません。それでも実施してください。

Warlockの事案は、多くのセキュリティ予算にとってまさにその「出来事」にあたります。検知に投じる支出の大半は、最悪のタイミングですべてが順調に進むことを前提にしています。センサーが生きていて、コンソールが報告を受け取り、担当者が間に合うように目を通すという前提です。センサーが失われれば、残りの仕組みは何もできません。支出は予算に残っていても、端末は無防備なままです。

人員が手薄な水道事業者は、取締役会が思う以上にこのギャップを抱えています。米議会調査局(CRS)は8月に、米国にある約4万9,500の地域水道システムのうち81%が小規模に分類され、給水人口は3,300人以下だと指摘しました。報告書によれば、大規模なシステムはセキュリティ専門家を雇う余力がより大きいといいます。つまり小規模な事業者ほど監視する人員が少なく、誰も見ていない時間が長いとみられます。

今回の一連の攻撃で、被害に遭ったのはすべて米国外の組織でした。この攻撃手法に、国境は関係ありません。

そして未明の時間帯にセンサーが沈黙したとき、その静けさは安全な状態とまったく見分けがつきません。

センサーを待たない予防策

監視役を停止させる工程がペイロード実行の直前に来るのであれば、本当に重要な防御は、それよりずっと前から機能していなければなりません。クラウド接続が維持されることも、アナリストがアラートを確認することも、センサーが一晩持ちこたえることも、当てにできないからです。

まず、限界を認識しましょう。脆弱な署名付きドライバーを読み込むツールは、マシンの最深部で動作します。見つけたセキュリティソフトは何でも停止でき、これから説明する種類の対策も例外ではありません。

だからこそ、タイミングが決め手になります。今回の事案では、防御の停止は侵入から9日後でした。それまでの間に攻撃者は、サーバーを悪用し、サイドローディングで自前のコードをメモリに読み込み、ドメイン全体で権限を獲得する必要がありました。これらの各段階は、攻撃者を止めるチャンスでした。しかも、防御停止の工程をくぐり抜ける必要のない対策で止められたはずです。攻撃者はそこまで近づけなかったでしょうから。

そうした対策の作り方の1つが、メモリ上で機能させる方法です。侵入者がその過程で読み込むコードの多くは、アプリケーションが想定どおりのメモリ配置になっていることに依存しています。アプリケーションを読み込むたびにこの配置を変えれば、その想定に頼るコードは実行の瞬間に失敗するはずです。これはエンドポイントでもサーバーでも変わらず、センサーが誰かに報告しているかどうかも関係ありません。判断はマシン上で下されます。

水道事業者の取締役会のための減損テスト

取締役会は、他のあらゆる資産についてはすでにこうした見直しを行っています。セキュリティの場合、問うべきことは1つに絞られます。監視が止まった後も、何が機能し続けるのかという点です。

経営陣に、セキュリティ予算を2つに分けるよう求めましょう。1つ目は、センサーがオンラインであり続け、担当者が対応することに依存する防御です。2つ目は、コンソールや担当者を待たずにマシン上で判断を下し、攻撃者が停止に必要な権限を手にする前に作動する防御です。次に、センサーが沈黙したとき誰がそれに気づくのか、何を通じて知るのかを尋ねてください。攻撃者は、目立つ通知手段から真っ先に止めるからです。

2つ目が空で、誰にも通知が届かないのであれば、そのとおりの言葉でリスク登録簿に記載してください。1つ目のうち、その夜を乗り切れない部分の割合が、減損額にあたります。インシデント報告書で知るより、取締役会で計上するほうがずっとましです。

40台のマシンが2時間で沈黙しました。スイッチを持ち込む攻撃者を前提に、予算を組みましょう。

翻訳元: https://cyberscoop.com/warlock-ransomware-storm-2603-sharepoint-attacks-op-ed/

本記事は cyberscoop.com の記事を翻訳・要約したものです。