パッチ適用だけでは不十分:露出期間露出期間の調査

要約

• パッチ適用だけでは不十分
• 露出期間を特定する
• 露出期間内でセキュリティ侵害の痕跡、不正使用、常駐化の調査をする
• Microsoft は対応担当者向けのガイダンスを公開している
  ソフォスも対応担当者向けのガイダンスを公開している
  観測可能な情報については、ソフォスの調査フレームワークを参照
  侵害を受けてサポートが必要な場合は、ソフォスの Rapid Response チームに連絡を
  問題がない場合は、次の攻撃に備えて、脅威の検出と対応機能の見直しを
• ソフォスも対応担当者向けのガイダンスを公開している
• 観測可能な情報については、ソフォスの調査フレームワーク(リンク先: 英語) を参照
• 侵害を受けてサポートが必要な場合は、ソフォスの Rapid Response チームに連絡を
• 問題がない場合は、次の攻撃に備えて、脅威の検出と対応機能の見直しを

Hafnium、DearCry をはじめ、多くの攻撃者が次々に Microsoft Exchange の脆弱性を悪用しています。ここで、パッチの適用だけでは不十分であるというシンプルな事実を受け入れることが重要です。

パッチを適用することはもちろん重要です。それによって、敵対者がネットワークに侵入して足場を得るために利用する欠陥をカバーできます。しかしパッチを適用しても、すでに侵入して脆弱性が悪用されていると、ほとんどの場合攻撃者を阻止することはできません。

パッチの適用はソフトウェアの脆弱性に関するリスク低減のために欠かせない行動です。しかし、パッチが公開される前に脆弱性がすでに明かされ、実環境で悪用されていた場合、脅威ハンティングを行い、システムアクティビティの分析をすべての露出期間に対して行う必要があります。

露出期間とは

露出期間 (Exposure Window) は、ソフトウェアの脆弱性が公開された時点で始まります。2 つの重要なイベント間の期間、つまり、脆弱性悪用の発見から、脅威緩和のためにパッチを適用するまでの時間を指します。

露出期間を把握すると、攻撃活動が発生した可能性のある時期が特定でき、その期間に絞って脅威ハンティングを行うことができます。

ローカルの露出期間とは、ネットワーク内またはそのエッジで攻撃の痕跡 (IOA) または侵害の痕跡 (IOC) が最初に確認されてから、その脆弱性に関連するパッチをインストールするまでの時間を指します。ネットワークに IOC や IOA が存在しない場合は、脆弱性が公表された日を最初とします。

多くの人にとって、Exchange Server に Web シェルが現れたのは 2021 年 2 月 27 日からで、これは Hafnium などが脆弱性を悪用し始めた段階です。

グローバルの露出期間とは、実環境での悪用が初めて観測された時、または脆弱性が公表された時のいずれか早い方を始まりとし、関連するパッチをインストールした時点で終了する期間を指します。

公開されたインテリジェンスレポートによると、グローバル露出期間が始まった時期についてはさまざまな憶測があり、多くのセキュリティチームは 2021 年 1 月に悪用が初めて成功したとの認識ですが、SNS 上では、最も早い悪用は 2020 年 11 月にさかのぼる可能性を示唆する話もあります。

ProxyLogon あるいは Hafnium の場合、ローカルの露出期間、グローバルの露出期間は下記の図のようになります。

期間特定と露出期間内でのハンティング

パッチによって露出期間の期間特定に必要な情報の片方 (期間が終了したとき) は分かりますが、始まった時期を特定する必要もあります。

2020 年 11 月から 2021 年 1 月の間にグローバル露出期間が始まったことはわかっています。しかし、ローカル露出期間がいつから始まったかを特定するには、IOC または IOA によって脆弱性が悪用されたかどうかを特定し、悪用があった場合には観測可能な情報から時間を割り出し、期間の特定を行ったり、その後の攻撃活動に対する脅威ハンティングに役立てたりする必要があります。

Microsoft が最近発表した対応担当者向けのガイダンスでは、最近の Microsoft Exchange の脆弱性によって侵害されたかどうかを確認する方法が詳しく説明されています。

この脆弱性に関するガイダンスから、「電子メールへの不正アクセス」と「Web シェルの展開」という 2 つの大きなリスクが予測されます。

電子メールへの不正アクセス

まず、Test-ProxyLogon.ps1 のアウトプットを確認し、Cve-2021-26855.csv があるかどうかを確認します。存在している場合には、サーバーサイドリクエストフォージェリの脆弱性悪用が成功したことを示唆しています。

.csv の AnchorMailbox カラムに /ews/exchange.asmx? への参照が含まれている場合、攻撃者が電子メールを流出させた可能性があります。調査のためには、<Exchange install path>\V15\Logging\EWS で Exchange のログを確認する必要があります。

Web シェルの展開

Microsoft が対応担当者向けガイダンスで公開しているツールを使用するか、Sophos Intercept X EDR を使用している場合は、ソフォスのガイダンスとクエリを活用して、攻撃者が展開した Web シェルが存在するかどうかを特定します。

Web シェルが存在する場合、攻撃者が行ったアクションを明らかにするために、コマンドアクティビティを確認する必要があります。

Web シェルを利用すると、攻撃者はリモートでサーバーにコマンドを出して、残りの攻撃を実行することができます。もしネットワーク内へ Web シェルを導入することに成功した場合、あらゆる行為に使用できます。そのため、攻撃者がシェルを使って何をしたのか、どのような影響を与えたのかを明らかにしなければなりません。

攻撃活動

Sophos Intercept X EDR などの EDR テクノロジーを使用して、露出期間全体を検索し、攻撃活動を特定します。EDR は、コマンドの実行やプロセスアクティビティなど、システムテレメトリの履歴を記録し、過去にさかのぼって検索することができます。

まず、最もリスクの高いローカル露出期間をレビューする必要があります。この作業が完了し、調査結果に確証が持てて、かつ問題がなければ、次にグローバル露出期間をレビューします。

それぞれの期間内で、異常な動作、ファイルへのアクセス、ラテラルムーブメント、権限昇格、データ窃取、追加コードの埋め込み、構成の改ざんなど、あらゆるアクティビティをレビューします。

Sophos Managed Threat Response (MTR) で観測される最も一般的なシナリオは、親プロセスが w3wp.exe または umworkerprocess.exe で、これらのプロセスから悪意のあるアクティビティが発生するケースです。

csc.exe を使用して C# .NET アセンブリをオンザフライでコンパイルするケースも多く見られ、この場合は以下のディレクトリで不審な DLL を探します。

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\%

ソフォス MTR では、上記のような動作が複数の異なるネットワークで確認されていますが、脆弱性の性質上、さまざまなシナリオが発生する可能性があることには注意してください。ソフォスでは、露出期間を特定し、すべてのシステムアクティビティを確認することを強くお勧めします。特に攻撃者によって Web シェルが展開された段階の前後のシステムアクティビティを確認してください。

ソフォスの調査フレームワーク

調査を一直線に終わらせることは容易ではありません。データを分析し、痕跡をたどっていくうちにさまざまな迷宮に入り込むことがあります。目標を絶えず維持するには、体系的なアプローチが必要です。

Sophos MTR では、Threat Detection and Response (TDR) と呼ばれる独自の調査フレームワークを使用しています。ソフォスのフレームワークについては以前にもご紹介しました (リンク先: 英語) が、このフレームワークに含まれるツールは、調査中だけでなく、次の潜在的なインシデントに備える際にも役立ちます。

能力と限界を知る

Hafnium や ProxyLogon のような大規模なインシデントが発生した後に調査を行うには、時間と専門知識が必要です。大半の組織にとって、チームの現行の能力ではネットワーク上に攻撃活動が一切ないことを保証するのは困難です。

Microsoft Exchange の脆弱性を悪用したアクティブな脅威に直面していると思われる場合、特に Web シェルの存在が確認された場合は、Sophos Rapid Response が攻撃者をネットワークから確実に排除します。

アクティブな脅威に直面していない場合も、Sophos Managed Threat Response の専門家チームが 24 時間 365 日体制でネットワークを監視し、防御を回避した脅威を特定、調査、対応します。

最後に、脆弱な Microsoft Exchange Server の悪用もなく、調査の結果 Web シェルや攻撃活動の痕跡が見られなかった場合も、次の攻撃に備えて脅威の検出と対応能力を見直しましょう。

ProxyLogon のような大規模なインシデントは、強力な学習機会となります。攻撃経路と侵入後に見られる攻撃活動を理解することで、今後の調査を加速させ、次の脅威を防ぐための貴重な検知や対応機能を増やす役に立てることができます。