「このプレゼンテーションからぜひ持ち帰っていただきたいテーマは、『ネットワークを本当に守りたいのであれば、そのネットワークを徹底的に理解しなければならない』ということです。」 TAO局長、NSA、 USENIX Enigma 2016
「ネットワークを把握する」上で欠かせない要素の一つは、エンドポイントの永続化メカニズム、すなわちオペレーティングシステムがコードを自動的に読み込んで実行する無数の方法を追跡することです。 10年以上にわたり、バックグラウンドサービスは、Windowsにおいて最も一般的に利用されている永続化場所の一つとなっています。 Windows NT や XP の時代から利用可能なサービスは、システムの起動時、ユーザーのログオン時、あるいは特定の条件が満たされた際に、バックグラウンドでプロセスやライブラリを目立たないように確実に読み込むための信頼性の高い手段を提供します。 斬新で隠蔽性の高い持続化手法の追跡にはしばしば注目が集まりますが、基本を見失わないことが重要です。特に、サービスベースのマルウェアがいまだに広く蔓延していることを考えると、なおさらです。
かつては、企業全体で稼働しているシステムサービスを綿密に監視することは、不可能な作業でした。 2年前の最先端の手法といえば、異常を検出するために手作業による詳細な分析を伴う月次監査でした。 現在では、Taniumプラットフォームとそのインシデント対応モジュールを利用することで、これを継続的かつ自動化した形で実施することが可能です。
リモートアクセスツール（RAT）やその他のマルウェアは、3つの異なる方法でサービスとして常駐することができます。具体的には、スタンドアロンのサービス実行ファイル、ホスト型サービスモジュール、およびCOM+コンポーネントとしてです。 この記事では、攻撃者がWindowsサービスを悪用するさまざまな手法と、Taniumがそれらの検知にどのように役立つかについて解説します。
単体サービス
スタンドアロン型サービスは、それぞれの構成レジストリキー内の「ImagePath」値で指定された実行ファイルまたはコマンドラインを実行します。 Windows レジストリには、親キー「HKLM\System\CurrentControlSet\Services」の下に、現在実行中のすべてのサービスに関する構成設定が格納されています。
Taniumはかねてより、Windowsサービスの大規模な監視機能（Windows環境全体にわたる）を提供してきました。 たとえば、「 MD5 ハッシュ付きサービスステータス」センサーは、サービス名、状態（実行中、停止中など）、コマンドライン、ImagePathハッシュ、およびサービスが実行されているユーザーコンテキストを収集し、比較します。 つまり、スタンドアロン型サービスの場合、その構成や状態が通常とは異なっていたり、同じ名前を持つインスタンス間で差異があったりすると、発生頻度が低くなることで目立つことになります。 Taniumのユーザーは、このセンサーを活用して、ステータス（停止中のウイルス対策サービスなど）に基づいて設定ミスが生じているものの正当なサービスを特定するほか、名前、ユーザーコンテキスト、コマンドライン、あるいは同一名のサービスインスタンス間で異なるImagePathハッシュに基づいて、不正なサービスを特定しています。
攻撃者の観点から見ると、スタンドアロン型のサービスはあまり好まれません。というのも、タスクマネージャーやtasklist.exe、あるいはサービスコントロールマネージャーによるクエリを使用すれば、実行ファイルのパスを容易に特定できてしまうからです。 「Print Spooler」という正当なサービス名の下にマルウェアを偽装しようとする攻撃者を想定してください。 このサービスの実行ファイルのパスは「c:\windows\system32\spoolsv.exe」です。 このサービスが改ざんされている場合、「c:\windows\spoolsv.exe」や「c:\windows\system32\spoolsvc.exe」など、ファイル名や保存場所がわずかに変更されたファイルから、悪意のあるバイナリが読み込まれる可能性があります。 この手法は、「一瞥しただけの」分析からはマルウェアを効果的に隠すことができますが、ImagePath やコマンドラインの統計的積み重ねによって容易に検知されてしまいます。 「Service Status with MD5 hash」のようなTaniumセンサーは、こうした外れ値を迅速に群れの端に集約し、その後の分析や調査に備えます。
ホスト型サービスとCOM+アプリケーション
ホスト型サービスは、スタンドアロンの実行ファイルではなく、ライブラリ（通常はダイナミックリンクライブラリ（DLL））として実装されています。 これらは通常、Windowsのサービスホストプロセスである「svchost.exe」によって読み込まれます。 以下のスクリーンショットは、「アプリケーション管理」や「ベースフィルタリングエンジン」など、いくつかのホスト型サービスについて、Taniumの「 MD5 ハッシュ付きサービスステータス」センサーの出力を示しています。 各サービスについて、指定されたハッシュは、ホストされているDLLのものではなく、「svchost.exe」のものです。
Windowsは、特定のホストされたサービスに対してどのDLLを読み込むべきかを、どのようにして判断するのでしょうか？ これらの各サービスのレジストリ設定には、読み込むDLLを指すサブキーと値「\Parameters\ServiceDLL」が含まれています。 効率性とセキュリティ上の理由から、Windows では、ホストされるサービスも、ホスティングプロセスの共有インスタンスの下でグループごとに読み込まれます（サービスごとに個別の「svchost.exe」インスタンスを起動するのではなく）。
ホスト型サービスグループは、レジストリキー「HKLM\Software\Microsoft\Windows NT\CurrentVersion\Svchost」の下に構成されています。 各グループには異なるアクセス権限が設定されています。「netsvcs」は、ネットワークアクセス権を持つサービスにとって最も権限の高いグループの一つであり、そのため攻撃者によって頻繁に悪用されています。 「netsvcs」の値は、以下のスクリーンショットに示されているように、このグループに読み込むサービス名の文字列配列です。
攻撃者は、ホスト型サービスを悪用して、いくつかの方法で悪意のあるDLLを読み込むことができます。 一つの方法は、「未使用」のホスト型サービス名、つまり「HKLM\SYSTEM\CurrentControlSet\services」の下にサービスが設定されていないものを選択することです。 マルウェアのドロッパーは、これらの未使用のエントリを順に試行し、必要なレジストリキー（ServiceDLLパラメータを含む）を作成することで、ホストされたサービスとして永続性を維持することができます。 たとえば、古いバージョンのWindowsでは、攻撃者は「netsvcs」グループに含まれているものの、対応する設定がないと多くの場合非アクティブになっている「 “6to4” 」サービスを標的とすることがよくありました。 攻撃者は、このサービスを「c:\windows\system32\6to4svc.dll」のような一見妥当に見えるDLL名を指すように設定することができ、目視による確認をすり抜ける可能性が高いと考えられます。 もう一つの方法は、既存のWindowsサービス（無効になっているもの）のServiceDLLパラメータを単純に修正し、その後、自動的に開始されるように設定することです。
COM+ システムサービスは、悪意のある DLL を読み込む可能性のあるホスト型サービスのもう一つの形態です。 この場合、「dllhost.exe」プロセスは、複数のコンポーネントをDLLとして含むCOM+アプリケーションを読み込みます。 一例として、以下のスクリーンショットに記載されている「ComSysApp」サービスは、COM+ アプリケーションのホスティングを担当しています。 コマンドラインには、「dllhost.exe」へのパスと、COM+ アプリケーションを識別する「Processid」GUID が表示されます。また、コード内では「コンポーネント」を一覧表示することができます。 これらのコンポーネントは、アプリケーションを実装するために使用されるDLLです。
要約すると、ホスト型サービスやCOMサービスは、RATやその他のマルウェアを潜伏させるための、目立たず、広く利用されている手段となっています。 アナリストは、基本的なプロセス監視やサービス名・ImagePathの確認にとどまらず、悪意のあるDLLを読み込むサービスを検知する必要があります。
Tanium を使用した不正なサービス DLL の特定
Taniumには、エンタープライズ規模でサービスDLLを容易に検出して分析するのに役立つ、いくつかのセンサーが用意されています。 まず、今月末にリリース予定のインシデント対応ソリューション「 3.0 」に搭載される、新しいセンサー「Service Module Details」についてご紹介します。 以下のスクリーンショットは、このセンサーからの出力の一部を示しています（「count」列は省略されています）。
このセンサーは、前述の3種類のサービスすべてについて、積み重ねて表示する機能を提供します。 「サービス名」や「ImagePath」に加え、「モジュールパス」という列が追加されている点にご注意ください。 この例の最初の2行には、「COMSysApp」という名前のCOM+アプリケーションの2つのコンポーネントDLLへのパスが表示されています。 その他の結果はすべて「svchost.exe」によってホストされており、それぞれのサービス DLL へのパスが含まれています。 このデータのスタック分析は、すべてのTaniumセンサーと同様に、リアルタイムで行われます。 つまり、数万から数十万台に及ぶシステム全体において、不正なDLLを読み込むサービスの異常なインスタンスを、わずか数秒で特定することができるのです。
ホスト型サービスグループ内の不正なメンバーの特定
前四半期、Taniumのインシデント対応機能のアップデートには、「Hosted Service Name Audit」という名称の新たなサービス分析センサーが含まれていました。 以下のスクリーンショットは、「netsvcs」グループに対する出力例を示しています。
このセンサーの出力は、サービスグループ内のサービス群を大規模かつ迅速に点検するのに役立ちます。 各グループについて、「ホストされているサービス名のソート済みリスト」列には、サービス名がアルファベット順に並んだリストが表示されます。 これにより、各システムからの出力が「積み重なる」ことが保証されます。その結果、グループ内で一般的ではないサービスを含むシステムは、外れ値として区別されることになります。 もちろん、システムによってオペレーティングシステムや役割に応じて提供されるサービスの組み合わせは異なる場合がありますが、センサーの出力データからは、OSのバージョンやプラットフォームの種類ごとにクラスターが形成されていることがわかりました。 Taniumのユーザーは、「ドリルダウン」機能を使用して、異常値が検出されたシステムを簡単に調査したり、Tanium Traceに切り替えて、不正なサービスの作成に関連する過去のフォレンジックデータを確認したりすることができます。
Taniumの実際の動作をご覧になりませんか？ の個別デモをご予約いただくか、毎週開催されているウェビナーにご参加ください。 「 」の今後のイベント（）にて、当社のTaniumエキスパートにご相談ください。
