Windowsメモリ内部解析サービス
豊田孝の「IT談話館」 Windowsメモリダンプ解析を依頼する WinDbgとシステム分析




 本「IT談話館」一般公開記事は、書籍 「インサイド Microsoft Windows」 程度の基礎知識をお持ちの方を想定しています。



Windowsセキュリティーメカニズム


 SaaS時代におけるWindows 10の頻繁なる内部更新は、性能向上と互換性維持などに加え、ML/DL/AI時代への対応と位置付けられています。簡単に表現すれば、Windows 10はCloudサービスと連携しながらBig Dataを収集・蓄積する「ソフトウェアセンサー」、という役割を担っています。本「IT談話館」は、そのソフトウェアセンサーのユーザー空間とカーネル空間を独自の解析コードで詳しく解析する技術を保有し、「Windowsメモリダンプ解析サービス」を提供しています。「本館サービス」をご利用の際には、所属チーム内でご協議の上、「ご連絡」頂けると幸いです。

 「メモリダンプ」を解析すると、採取時点におけるシステム内部の「異様な動き」を検出・解析することができます。「異様な動き」の中には、システムパフォーマンスの低下、既存アプリの動作異常、システムクラッシュ原因、あるいは、セキュリティー脅威なども含まれます。

 本「IT談話館」の「一般公開記事」は、「Active Memory Dump とカーネルメモリダンプ」の解析結果を基に起草され、0dayをはじめとする脆弱性研究者、組み込みシステム開発者、デジタルフォレンジック技術者、および、EDR製品のビジネス関係者に広く読まれています。公開はあくまでもビジネスに支障の出ない範囲に限定されていますが、それでも、インターネット空間上で容易に入手できるレベルの記事ではありません。

 現在、セキュリティー問題を無視することはできません。Microsoft社の技術者側の作業負担だけではなく、同社製品の利用者側の作業負担も増しています。困ったことではありますが、当面避けられません。セキュリティーの視点からWindows10ソフトウェアセンサーを見た場合、本「IT談話館」の確認範囲では、「カーネル層保護ロジック」に加え、次のような保護メカニズム階層が考案・実装されています。下記リンクはすべて本館記事を指しています。
  1. Silo/Server Silo
  2. Job
  3. Session
  4. Protected Process
  5. Mandatory Integrity Control(MIC)
  6. Windows API(+CPU)
  7. CPU
 現在のWindowsセキュリティーメカニズムは次のような概念の流れで構成されています。

データ収集<->分析+Alert<->特徴+モデル<->予測

 このメカニズムは、データを収集し、それを分析する過程でAlertを出力しながら、最終的に「将来の脅威を予測」する、という流れを示しています。また、流れを構成する各概念は「<->」記号で結ばれ、それぞれの成果物の品質が相互フィードバックにより常に改善されることを示しています。Alertや予測などは外れることがあるため、常に、批判的に解釈する技術力が必要になります。False Alertに引きずられた場合、貴重な時間が浪費され、真実に迫ることはできません。

 以上の流れは、次のように書き直すことができます。

Client<->Cloud<->File Upload<->Expert Analyst

 データ収集と分析作業はClient ML側で行われ、脅威の性質に応じてCloud側(Cloud ML+DL+AI)がトリガーされ、詳細な分析が行われます。米Microsoft社の資料は、Client上では500を超える攻撃パターンをモニターしており、攻撃の97%はClient上で阻止できる、と述べています。ML、DL、AIといった用語を使用すれば、次のような流れが出来上がります。

Sensors<->ML<->DL<->Neural Network<->Human

 データ収集にはSensorが必要になります。この場合のSensorとは、Windows 10に組み込まれている機能を指しますが、Windows 10は短周期で内部更新を繰り返している関係上、その機能実態を把握するには高度な技術力が必要とされます。本「IT談話館」は、独自解析コードでWindows 10センサーに直接アクセスし、そのユーザー空間とカーネル空間の詳細な解析を通して、最新のセンサー機能を把握する高度な技術力を保有しています。

 本稿では、上のリスト内の「Protected Process」記事を補足する意味みもあり、Windows 10保護プロセス(Protected ProcessとProtected Process Light)に焦点を当てています。本館はWindows内部解析技術に関する「オンサイトセミナーサービス」を提供していますが、この抽象度の高いWindows 10保護プロセスメカニズムはそれほど複雑ではないため、セミナー会場での本館説明は、「Mandatory Integrity Control(MIC)」や「Windows API(+CPU)」などの解説と異なり、比較的好感を持って受け入れられています。

 Windows 10環境で採取した「Active Memory Dump」を本「IT談話館」独自の解析コードで解析すると、次のようなWindows 10保護プロセスに関する内部情報を取得することができます。

独自解析コードの出力情報


 この表は、ダンプ採取時点で動作中のプロセスの性質を示しています。性質には保護プロセス特性に加え、次のような情報が含まれています。  保護プロセスメカニズムは分かりやすいものですが、この表内の結果には、より抽象度の高いレベルで基本的な不可解さが残されています。表内の「System」欄を見ると、すべてのプロセスは「0」という値を持ち、システムプロセスが存在しない、と報告されています。カーネル構造体には次のようなビットが用意されています。
0: kd> dt nt!_eprocess system*
   +0x6fc SystemProcess : Pos 12, 1 Bit
 今回の調査では、このビットが立っていません。しかし、次のビットは立っています。
0: kd> dt nt!_eprocess subsystem*
   +0x6fc SubsystemProcess : Pos 6, 1 Bit
 「SystemProcess」は存在しないが、「SubsystemProcess」は存在する。この論理はどう考えても成立しません。ちなみに、Windows 10の前身であるWindows 8.1では「SubsystemProcess」ビット自体が用意されていません。このあたりの不可解さが今後どのように解消されるのかを注視したいと思います。

 なお、表内の「CrossSession」欄は、オブジェクト名前空間内にEventオブジェクト、Keyオブジェクト、あるいはFileオブジェクトなどを作成し、セッション分離を超える機能を実装しているプロセスを示しています。オブジェクト名前空間へのアクセスは通常はシステム内部のハンドルテーブルを経由することになりますが、この面での改善試みは複数のWindowsバージョンを跨ぎながら、長期的かつ継続的に行われています。ハンドルテーブルとKeyオブジェクトについては、本館の次のような記事がそれぞれ参考になるでしょう。


ビジネスメニュー




 本「IT談話館」一般公開記事は、書籍 「インサイド Microsoft Windows」 程度の基礎知識をお持ちの方々を想定しています。
Windowsメモリダンプ解析技術開発室 ビジネスメニュー

Copyright©豊田孝 2004- 2020
本日は2020-09-30です。