- 2018/02/16
- サイバー攻撃
新しいラテラルムーブメントの手法 – DCOM技術の悪用
Post by : PHILIP TSUKERMAN
ラテラルムーブメントとは
ラテラルムーブメントとは、組織のネットワークへの侵入に成功したマルウェアが、OSの正規の機能を悪用し、内部偵察、資格奪取、組織内の感染領域を広げる行動のことを指し、攻撃プロセスにおける感染拡大フェーズで実行されます。
DCOM機能を悪用する新たなラテラルムーブメント手法
最近のネットワーク攻撃では、最終的にデータや資産にたどり着く前に、標的のネットワーク内を攻撃者が移動するラテラルムーブメントのフェーズが多く見られるようになりました。
脆弱なマシンやEternalBlueのような脆弱性攻撃ツールがない場合、盗んだ資格情報を使って、ネットワーク内の最初の足場から到達可能なリモートマシン上で実行することでこのフェーズは完遂されます。
ソーシャルエンジニアリングや脆弱性を悪用する通常の突破口型攻撃とは異なり、ラテラルムーブメントではOSの正規の機能が悪用されます。Windowsマシンでは、通常、リモートサービス作成、タスクスケジューラ作成、リモートWMIプロセス作成といったいくつかの方法を多様な形にしてラテラルムーブメントが行われます。
これらの機能の奇妙な挙動を詳しく観察することで、攻撃者に対してある程度の効果を上げることは容易です。この種の挙動を綿密に監視する環境で攻撃者がリモートサービスを作成しているので、さまざまな回避手法を駆使して巧妙に計画された攻撃でさえも検出が可能です。
最近、この種のラテラルムーブメント手法は、さまざまなWindowsアプリケーションのDCOM(Distributed Component Object Model)機能を悪用するいくつかの新しい手法(主にSpecterOpsのMatt Nelson氏によって発見され、いくつかはOren Ofer氏の協力の下でリサーチの私自身が発見したもの)とともに広がっています。
この記事では、DCOMを利用したラテラルムーブメントのさまざまな手法(まだ報告されていないものも含む)を検討し、ユースケースおよびフォレンジック調査の対象となる痕跡を評価し、これらの手法による攻撃を検出して防止する方法を提供します。
DCOMとは
DCOMはCOM(コンポーネントオブジェクトモデル)の拡張版で、アプリケーションが、DCERPCベースのDCOMプロトコルを使用するローカルマシン上のオブジェクトと同様に、リモートコンピュータ上のCOMオブジェクトのプロパティとメソッドをインスタンス化してアクセスできるようにします。
すべてのCOM(およびDCOM)オブジェクトのID、実装、および構成に関する情報はレジストリに格納されており、以下のいくつかの重要な識別子に関連付けられています。
- CLSID – クラス識別子はGUIDであり、COMクラスの一意の識別子として機能します。Windowsに登録されているクラスはすべてCLSIDに関連付けられています(COMオブジェクトは登録なしで使用できますが、この記事では説明しません)。レジストリ内のCLSIDキーは、dllベースのオブジェクトの場合はInProcServer32サブキーを使用し、exeの場合はLocalServer32サブキーを使用してクラスの実装を参照します。
- ProgID – プログラム識別子は省略可能な識別子です。CLSIDの強制的なGUID形式を遵守する必要がないため(System.AppDomainManagerなどは、見た目にGUIDよりはるかに易しい)、CLSIDに代わるものとしてユーザーには扱いやすい識別子です。ProgIDは一意であることが保証されてはおらず、CLSIDとは異なり、すべてのクラスがProgIDに関連付けられているとは限りません。
- AppID – アプリケーション識別子は、同じ実行可能ファイルに関連付けられた1つ以上のCOMオブジェクトの構成を指定するために使用されます。これには、ローカルおよびリモートマシン内の関連付けられたクラスをインスタンス化およびアクセスできるよう、さまざまなグループに与えられたアクセス許可が含まれます。
DCOMがCOMオブジェクトにアクセスできるようにするには、AppIDをクラスのCLSIDに関連付け、適切なアクセス許可をAppIDに渡す必要があります。AppIDが関連付けられていないCOMオブジェクトへは、リモートマシンから直接アクセスすることはできません。
Win32_DCOMApplication WMIクラスで、使用可能なDCOMアプリケーションをAppIDで簡単に列挙することができます。
リモートDCOMオブジェクトのインスタンス化は、次のような流れで行われます。
- クライアントマシンが、CLSIDで指定したオブジェクトのインスタンス化をリモートマシンに要求します。クライアントがProgIDを使用する場合は、まずローカルでCLSIDに解決されます。
- リモートマシンは、指定されたCLSIDに関連付けられたAppIDがあるかどうかを確認し、クライアントのアクセス許可を確認します。
- 確認が問題なく終わると、DCOMLaunchサービスは要求されたクラスのインスタンスを作成します。通常は、LocalServer32サブキーの実行可能ファイルを実行するか、InProcServer32サブキーによって参照されるdllをホストするDllHostプロセスを作成します。
- クライアントアプリケーションとサーバープロセスとの間で通信が確立されます。ほとんどの場合、新しいプロセスはDCOM通信に関連するセッションで作成されます。
- クライアントは、新しく作成されたオブジェクトのメンバーとメソッドにアクセス可能になります。
DCOMによるアプリケーションの起動を確認する
ローカルマシンにインスタンス化されたInProcServerクラス(呼び出し元プロセスに読み込まれる)と既存のプロセスにホストされているオブジェクトを除き、オブジェクトの作成はDCOMLaunchサービスによって処理されます。
このサービスはrpcss.dllライブラリに実装されており、”C:¥WINDOWS¥system32¥svchost.exe -k DcomLaunch” のコマンドラインで確認することができます。このように、COMによって開始された新しいプロセスには、親プロセスとしてDCOMLaunchサービスが存在します。
COMによってプロセスが開始されたことを知ることで、プロセスがローカルで使用されているか、リモートで使用されているかを簡単に特定できます。
ローカルクライアントと通信する場合、COMオブジェクトはALPC(Advanced Local Procedure Call)プロセス間通信メカニズムを使用します。これを使用しない場合は、明示的に構成されていない限り通常は高位ポートで、DCOMプロトコルを介してリモートクライアントと通信する必要があります。
したがって、親プロセスのDCOMLaunchと高位ポートで待機しているソケットの両方を組み合わせれば、リモートで使用されているDCOMオブジェクトを特定できます。Officeアプリケーションは、COMを介して、”-Embedding” または “/automation -Embedding” のコマンドラインオプションで起動されるのが特徴的です。
DCOMを利用したラテラルムーブメント手法
以降のセクションに示すラテラルムーブメントの手法は、その実行がシステムに与える影響の程度によってグループ化されています。これらのほとんどはこれまでに報告されていますが、われわれが知る限り、これまでに報告されていないものもあります。
任意コマンドラインの実行
■Excel DDE
サイバーリーズンによって最初に報告しました(こちらを参照)。
この手法では、近頃悪名を馳せているDirect Data Exchange(DDE)プロセス間通信を使用して任意のコマンドラインを実行します。
この手法を実行するには、まず、Excelオートメーションに関連付けられたCOMオブジェクトであるExcel.Applicationオブジェクトのインスタンスを作成します。「xxx.xxx.xxx.xxx」はターゲットアドレスを表します(以下同様)。
これに続いて、アラートと実行が制止されます。
Excelプロセスは、選択されたコマンドラインを実行し、前記アプリケーションとのDDEチャネルを確立しようと試みます。失敗するとエラーコードを返しますが、コマンドはまだ実行されています。
- アーティファクトとインジケータ – 実行されたコマンドは、Excelの子プロセスとして実行されます。
- 制限事項 – アプリケーションの名前は8文字に制限されています。この文字列に使用できるのは、%PATH%環境変数が参照する「cmd.exe」などの実行可能ファイルのみです。コマンドライン引数の「cmd」にはこの制限がないので、文字列を自由に指定することができます。
- 注意 – Rundll32やRegsvrなどの文字列は短いので、最初のアプリケーションを示すcmdを置き換えることができます。「.exe」は実行可能ファイル名の末尾に自動的に付けられるため、「cmd.exe」としてしまうと「cmd.exe.exe」になってしまうので、拡張子は指定しないでください。
■MMC20.APPLICATION
SpecterOpsのMatt Nelson氏によって最初に報告されました(こちらを参照)。
この手法を実行するには、まずMMC20.Applicationオブジェクトのインスタンスを作成します。
次に、Document.ActiveViewプロパティのExecuteShellCommandメソッドを使ってCybereasonのコマンドを実行することができます。
- アーティファクトとインジケータ – 実行されたコマンドは、mmc.exeの子プロセスとして実行されます。
- 注意 – COMを介したmmc.exeの実行は非常にまれであるため、この手法をアラートディフェンダーにノイズとして表示させることは困難です。
■SHELLWINDOWS
Matt Nelson氏によって最初に報告されました(こちらを参照)。
この手法を実行するには、まずShellWindowsオブジェクトのインスタンスを作成します。
Document.ApplicationプロパティのShellExecuteメソッドを使用して任意のコマンドを実行できます。
- アーティファクトとインジケータ – 他のほとんどの手法とは異なり、ShellWindowsはプロセスを作成しません。代わりに、既存のexplorer.exeプロセス内のクラスインスタンスをアクティブにすることで、子プロセスを極めて規則的に実行します。通信するために、ホストexplorer.exeがDCOMポートでリスニングソケットを開くことが、この手法の明確な目印となります。このメソッドに関係なく、explorer.exeプロセスがリスニングソケットを使用する場合は、攻撃を疑う必要があります。
- 制限事項 – ShellWindowsオブジェクトは、開いているファイルのエクスプローラウィンドウを表します。つまり、エクスプローラウィンドウが開いていないマシンでこのオブジェクトを作成しようとすると何も返されず、このメソッドを使用できなくなります。
- 注意 – ShellWindowsクラスはProgIDに関連付けられないため、CLSIDを使用して作成する必要があります。もちろん、他のすべてのオブジェクトもCLSIDを使用して作成できます。
■SHELLBROWSERWINDOW
Matt Nelson氏によって最初に報告されました。
この手法を実行するには、まずShellBrowserWindowオブジェクトのインスタンスを作成します。
これも、Document.ApplicationプロパティのShellExecuteメソッドを介してコマンドを実行することができます。
- アーティファクトとインジケータ – ShellWindowsと同様に、このメソッドは既存のexplorer.exeプロセスによってホストされます。また、explorer.exeプロセスがリスニングソケットを開くというインジケータもあります。
- 制限事項 – このオブジェクトはShellWindowsのようにエクスプローラウィンドウを開く必要はありませんが、Windows 7以前のバージョンでは使用できません。
- 注意 – ShellBrowserWindowクラスもProgIDに関連付けられていません。
■VISIOアドオンの実行
サイバーリーズンが最初に発見しました。
Visioは、デフォルトではOfficeに含まれず、広く普及しているわけではありませんが、ラテラルムーブメントに使用できるDCOMオブジェクトを提供します。
この手法を実行するには、まずVisioオブジェクトのインスタンスを作成します。これは、Visio.Application ProgIDまたはVisio.InvisibleApp ProgIDのいずれかで実行できます。
Visioアドオンはスタンドアロンプロセスとして実装でき、Visioではカスタムアドオンとして実行可能ファイルを読み込むことができます。実行を容易にするために以下のように指定できます。
- アーティファクトとインジケータ – アドオンはVisioの直接の子プロセスとして実行されます。
- 注意 – Visioの普及率が低いため、この手法はこの記事の他の手法で説明されている数のコンピュータには適用されません。子プロセスを生成する可能性が低いためです。
■CREATEOBJECTとSHELL.APPLICATIOを使用したOUTLOOKEXECUTION
Matt Nelson氏によって報告された手法のバリエーション。
Outlookオブジェクトは、CreateObjectメソッドを使用して、任意のCOMオブジェクトのインスタンス化とやりとりを許可します。これにより、攻撃者は通常、DCOMによって公開されていないリモートコンピュータ上のCOMオブジェクトとやりとりできます。
Outlook経由でShell.Applicationオブジェクトを作成することでコマンドラインを実行できます。
- アーティファクトとインジケータ – このコマンドは、Outlookの直接の子プロセスとして実行されます。
- 注意 – Shell.Application(これは既にロードされているshell32.dllに実装されている)の代わりにWscript.Shellオブジェクトを使用できますが、これには利点がないため、wshom.ocxを読み込むプロセスをインジケータとして追加します。
任意のライブラリの読み込み
■Excel XLLの登録
Ryan Hanson氏によって最初に報告されました(こちらを参照)。
Excelは、特定の機能をエクスポートするDLLであるXLLライブラリによって拡張可能です。 Excel.Applicationオブジェクトは、RegisterXLLメソッドを介してこの機能を攻撃に晒します。
- アーティファクトとインジケータ – Excelプロセスで不明なDLLが読み込まれます。
- 注意 – 標準XLLには拡張子.xllと特定のエクスポートがありますが、RegisterXLLメソッドは、ファイルの拡張子やエクスポートされた関数に関係なく、任意のdllのDllMainを実行します。
■Word WLLアドイン
Wordには、WLLライブラリを使用して実装されたXLLのようなアドインもあります。これらのアドインは、Word.ApplicationオブジェクトのAddInsプロパティを使用して追加できます。
- アーティファクトとインジケータ – Wordプロセスは、WLL拡張子を持つ未知のライブラリを読み込みます。
- 制限事項 – XLLとは異なり、Wordアドインの拡張子は.wllでなければなりません。さらに、64ビットのWordではWLLアドインはサポートされないため、この手法が機能するのは32ビットのWordのみです。
■任意スクリプトの実行
CreateObjectおよびScriptControlを使用したOutlookScriptの実行
Matt Nelson氏によって最初に報告された(こちらを参照)。
元々の手法では、Outlookを使用してScriptControl COMクラスにアクセスすることで、攻撃者は文字列形式で提供したスクリプトを実行できます。
- アーティファクトとインジケータ – ScriptControlオブジェクトはmsscript.ocxで実装されますが、使用されることはめったにありません。正規にこれを読み込むOutlookのインスタンスは極めてまれな現象です。さらに、スクリプト自体を実行するために、jscript.dllまたはvbscript.dllが読み込まれます。
- 制限事項 – ScriptControlオブジェクトは32ビット版でのみ使用できます。64ビットプロセスは32ビットのinprocオブジェクトを読み込むことができないため、64ビットのOutlookはこのオブジェクトとやりとりできません。
■VISIO EXECUTELINE
サイバーリーズンが最初に発見しました。
Visioオブジェクトは、ExecuteLineメソッドを使用して、文字列からVBAの任意の行を直接実行できます。
- アーティファクトとインジケータ – VBE7.dllとScrRun.dllがVisioプロセスに読み込まれます。
- 注意 – ExecuteLineメソッドは、1行のコードの実行のみを許可します。これは、コロン(:)を使って1行のステートメントを区切ることでバイパスされます。
■Officeファイルレスマクロ実行
OfficeのVBAエンジンモデルは、通常はアクセスできないようにプログラミングされているため、各アプリケーションのプロパティメニューで [Visual Basicプロジェクトへのアクセスを信頼する] オプションを有効にする必要があります。
この設定は、関連するすべてのOfficeアプリケーションのレジストリの “HKCU\Software\Microsoft\Office\
これらの値を(WMIなどを使用して)リモート操作で1に設定すると、文書ファイルを含むペイロードを最初に提供せずに、VBAマクロをExcel、Word、PowerPointおよびAccessに注入して実行することできます。
この例で使用されるマクロは単にcalc.exeを実行するだけです。
Excelでの実行
Wordでの実行
PowerPointでの実行
Accessでの実行
- アーティファクトとインジケータ – 前述のように、これらのメソッドを有効にすると、リモート操作されることはほとんどなく、悪質なマクロによってたまに使用されることのある特定のレジストリキーを操作する必要があります。これには、アプリケーションにVisual Basic Environment(vbe7.dll)ライブラリを読み込む必要があります。さらに、いずれかのアプリケーションで新しい文書を作成すると、文書を保存する必要があるため、Quitメソッドが失敗します。これは、有効化プロセスが実行後に環境に残るのを避けるために、潜在的なペイロードが何らかの形で親のOfficeプロセスを秘かに処理する必要があることを意味します。アクセスによって、追加のアーティファクトが残ります。これは、他のアプリケーションとは異なり、マクロを挿入して実行するには、データベースファイルを実際に作成し、攻撃者が選択したディスク上の場所に保存する必要があるからです。
- 注意 – AccessVBOMレジストリ値は、ステージャのシェルコードをrundll32に注入するExcelマクロを作成して実行するために、標準のCobalt Strikeステージャの1つによって使用されます。
■既存の文書からのOfficeマクロの実行
このExcelバージョンはMatt Nelson氏によって最初に報告されました(こちらを参照)。
上記のCOMオブジェクトは、既存の文書に埋め込まれたマクロペイロードを実行するためにも使用できますが、それは、メソッドを使用して既存の文書を開いてから、Runメソッドを使用してマクロペイロードを実行する方法とほとんど変わりません。
- アーティファクトとインジケータ – この方法は、ファイルなしにマクロを実行できるようにする代わりに、マクロを必要とします。つまり、実行するためには、悪質な文書がマシン上に存在し、関連するアプリケーションによって開かれる必要があります。文書に変更が加えられない限り、アプリケーションはQuitメソッドで正常に終了するため、ペイロード内でこれを処理する必要性がありません。
予防対策と検出
- DCOMによってどのアプリケーションがリモートから開始されたかを特定する機能と組み合わせることで、各手法が残したアーティファクトとインジケータから強力なIoC(Indicator of Compromise:脅威の痕跡)が発生する可能性があります。
- これらの手法はどれも脆弱性を突くものではなく、正規の機能を悪用するものです。これは、これらの機能が一部の環境で実際に使用されている可能性があることを意味します(たとえば、マクロをリモートで実行している正規のExcelインスタンスが相当数あります)が、これは極めてまれなケースです。つまり、個々の組織がネットワーク内でのDCOM使用の基準ラインを試行錯誤しながら作成し、ホワイトリストに登録されていないイベントを不審なものとして扱えることを意味します。これらの機能のほとんどのアプリケーションは、歴史的な理由から使用され続けてられているため、DCOMイベントが目につくにつれて、ホワイトリストの作成は次第に容易になります。
- DCOMオブジェクトを作成することは、攻撃者がそれをシャットダウンする必要があることを意味します。前述のほとんどのオブジェクトには手軽なQuitメソッドが用意されていますが、ホストアプリケーションが終了を拒否することがあるために、文書の作成、オープン、変更といった環境によっては、オブジェクトを強制的にシャットダウンするタスクがあります。実行後に痕跡を消すことができない無謀な攻撃者は、痕跡が非常に目立つOfficeプロセスを標的内にいつまでも残す可能性があります。
- 危険なオブジェクトへのDCOMアクセスは、ポリシーによって禁止され、必要に応じて厳重にホワイトリストに登録されている必要がありますが、これは、これらのオブジェクトに対してDCOMアクセス(たとえばdcomcnfg経由で)を拒否しても、おそらく不都合な副作用が生じないからです。
- 実際には、64ビットバージョンのWindowsに32ビット版のOfficeをインストールしても、関連するアプリケーションのappIDは登録されません(そのような設計なのか、設計ミスであるのかはわかりません)。したがって、DCOMベースのラテラルムーブメントを認識しないユーザーにとっては「ワクチン」になると言えます。この攻撃の認識がなく、これらのコンピュータでOffice関連のDCOMの問題が発生していない場合は、x64 Officeがインストールされているコンピュータ上のOfficeオブジェクトへのDCOMアクセスを拒否することがおそらく安全と思われます。
まとめ
DCOM、特にMicrosoft Office DCOMオブジェクトは、ラテラルムーブメントに対して脆弱です。この攻撃は、防御側が注意深く警戒すれば容易に検出できる痕跡を残しますが、それらを使用することで、ほとんど監視されていないチャネルを介してコードをリモートで実行することによって防御側に検出されることを回避します。
膨大な数の手法を駆使することで、攻撃者は標的のネットワーク内で可能な限り打撃を与えられるようラテラルムーブメントの手法を洗練化していくことが考えられます。防御者が従うべきアドバイスは、ネットワーク上であまり使用されていないリモート実行チャネルをできるだけ閉じることです。
ホワイトペーパー「すべての組織が狙われている」
企業、組織がどんなにセキュリティを強固にしてもハッカーが悪用できる脆弱性は必ず存在します。侵入されることが避けられないことを受け入れ、新たな対策を立てる必要があります。本書で、なぜ避けられないのか、どのように対処するのかをご覧ください。
https://www.cybereason.co.jp/product-documents/white-paper/606/