【PC遠隔操作事件】コンピュータ・フォレンジクスでHDDを徹底”解剖”する(第４回公判メモ２)
第４回公判が開かれた３月20日午後には、検察側の依頼で本件に関する鑑定を行った情報セキュリティ会社ラックでコンピュータ・フォレンジクスを担当する関宏介氏の証人尋問が行われた。コンピュータ・フォレンジクスとは、PCなどの電子機器やデジタル記録媒体を分析して、法的な証拠とするための作業や技術のこと。検察側は、ラックが作成した（１）片山祐輔氏が派遣先乙社で使っていたPCの解析（２）片山氏がiesysを作成する能力の有無――についての鑑定書２通を証拠提出している。ただ、関証言によれば、ラック社は３通の鑑定書を検察に提出しており、これまで存在すら伏せられていた鑑定書があることが明らかになった。
鑑定は、関氏ら４人で行った。乙社PCについては、フォレンジクス専用のソフトウェアX-waysを使ってハードディスクの情報を検索した、という。
その作業について、関氏はコンピュータ・フォレンジクスで「PC内の情報を解剖する」と説明した。
関氏によれば、ファイルの読み書きをする際には、必ずOS（Windows）を介して行われる。そのため、Windowsが残す痕跡が分かれば、そのPCの中で何が起きたかが分かる。
第2回公判での生駒証人と同じように、関氏も多くの痕跡が「ファイルスラック領域」から出てきた、と述べた。ファイルスラック領域は、あるファイルの上に、それよりサイズの小さいファイルを上書きした場合、クラスタ内で元データが消去されずに残った部分。この領域に意図的にデータを残すことは「非常に難しい」と関証人は証言した。その理由を、次のように説明した。
「あるデータをファイルスラック領域に残したい場合、そのデータが含まれるファイルより小さいファイルを上書きすることになるが、新たに保存するファイルがHD内のどこに書き込まれるのかを、ユーザは決められない。狙った場所に上書きすることは難しい」
関証言の概要は以下の通り。
【このPCで開発された「可能性が高い」】
対象PCでは、４ユーザによってログオン・ログオフが行われていた。うち３つは、調査時点で削除済み。その1つである「TKY-DEV-PC07_2」は、2012年７月始めから９月末まで使われていた。これを調べるため、Windowsのユーザ情報の記録（SAMファイル）を調べると共に、Windowsが自動で記録する活動記録（イベントログ）のログオン・ログオフ情報からユーザ一覧を調査した。
イベントログの１つである監査ログは、2012年９月28日9:30:34にユーザ「TKY_DEV_PC07」によって消去されていた。監査ログには、ログオン・ログオフの記録が含まれている。これが消されていたため、他のWindowsが自動で記録する活動記録からログオン・ログオフの調査をおこなった。
「Visual C# 2010 Express」は、2011年11月02日から2012年09月18日までの間に４回に渡ってインストール、アンインストールが繰り返されていた。うち、2012年７月12日以降の２回にわたるインストールは「TKY-DEV-PC07_2」のユーザ名で行われた。
「Visual C# 2010 Express」で新規にプログラムを開発する時には、自動的に「Temporary Projects」フォルダが作成される。その中に、自動的に「vshost.exe」を含む実行ファイルが作成される。この「vshost.exe」は、プログラムから不具合を取り除くための作業（デバッグ）に供するファイルである。他の場所からソースコードを持ってきても、「Temporary Projects」フォルダは作成されない。
「Temporary Projects」で検索すると、この文字列を含む、以下のようなファイルパス（ファイルが保存されている位置を示す文字列）が検出された。
C:\Users\TKY-DEV-PC07_2\AppData\Local \Temporary Projects\Chikan\……
C:\Users\TKY-DEV-PC07_2\AppData\Local \Temporary Projects\Dam\……
これらの文字列によれば、「TKY-DEV-PC07_2」のユーザアカウントが使われ、「Chikan」「Dam」が開発された可能性が高い《江川注：「Chikan」はAKB48事件、「Dam」は伊勢神宮事件などで使われたプログラム名》。
また、「cofee」「iesys」を含む文字列が、「C:\Users\TKY-DEV-PC07_2\AppData\Local \Temporary Projects\」を含む文字列と同一のセクターから検出されている。同一のセクター内のデータは、同一時期に記録されたという原則があり、この３つの文字列は関連性がある。
F:\vproj\……\Debug\CryptTool.vshost.exe 《江川注：CryptToolはiesysで使われた暗号化プログラム名》
F:\vproj\……\Debug\cofee.vshost.exe 《江川注：cofeeは開発時のiesysのプログラム名》
C:\Users\TKY-DEV-PC07_2\AppData\Local \Temporary Projects\Chikan\……\Chikan.vshost.exe
などの文字列から、
a)このPCで複数のC#プログラムが新規に作成された可能性が高い
b)「TKY-DEV-PC07_2」のユーザアカウントが利用された
c)一部のC#プログラムは、Fドライブに保存されている
ことが分かる
【USN Change journalの分析】
USN Change journalは、Windowsが管理する変更履歴の帳簿である。Windowsは、ファイルを操作するたびに、変更履歴の帳簿（USN Change journal）を記録する。どのファイルが、いつ、何をされたのかが記録されている。フォレンジクス専用のソフトウェアを使い、削除されたUSN Change journalを復元し、解析した。
その結果、
1）USN Change journalの痕跡から2012年７月26日にiesys.exeおよびフォルダ「iesys」の作成・削除が繰り返し行われた可能性が高い。
2) 「CRYPTTOOL.EXE-4414E390.pf」の痕跡から、同日にCRYPTTOOL.EXEの実行の痕跡を確認した。pf(プリフェッチ）とは、実行したプログラムを次回すばやく起動するためにWindowsが作成するファイルであり、pfファイルがあるということは、このプログラムが実行されたことを示す。
意図的に事実でない記録をUSN Change journalに残すことは難しい。なぜなら、USN Change journalは人間には読めない形式で書いてあるからだ。これを読み取るためのツールは存在するが、任意のUSN Change journalを作成するツールがあるとは聞いたことがない。しかも、USN Change journalについての正式な情報は公開されていないので、任意のUSN Change journalを作ることは難しい。
【TrueCryptでFドライブ作成の「可能性が高い」】
暗号化仮想ドライブのアプリケーションTrueCryptが、2012年６月11日に公式サイトからダウンロードされ、同じ日にTrueCryptが利用するファイルが作成されていることを確認した。ダウンロードとインストールが同日のうちに実行された可能性が高い。
マイクロソフトのアンチウイルス製品（Security Essentials）は、プログラムのダウンロード時に自動的に検査を行う。その検査が行われた時刻がダウンロードの時刻と見てよい。この検査記録によれば、検査のスタート時は2012年６月11日15時22分25秒。ユーザ名は「TKY-DEV-PC07」である。
鑑定時には、TrueCryptは削除されていたが、TrueCryptはアンインストールしても、インストール時にCドライブに作成された「truecrypt.sys」というファイルは残る。
Windowsが自動的に作成したレポートのファイルにある「\Device\TrueCryptVolumeF\」という痕跡から、FドライブはTrueCryptが作成したドライブである可能性が高い。
【Fドライブにiesysの痕跡】
「F:\」で検索すると、
F:\vproj\……\cofee.exe
F:\vproj\……\Dam.exe
F:\vproj\……\iesys.exe
F:\vproj\……\CryptTool.exe
F:\vproj\……\iesys- コピー.exe
などの文字列を含むファイルパスの痕跡が検出された。
このことから、「iesys.exe」に関連するプログラムが、Fドライブに存在した可能性が高い。
また、「- コピー」がつくファイル名は、Windows７のエクスプローラー上で同じフォルダにファイルをコピーする際に作成される名称である。当該PCのエクスプローラー上で、「iesys.exe」ファイルのコピーをした可能性が高い。
「F:\」で検索した結果にあったURLの痕跡から、Fドライブの「Google Chrome Portable」を利用して複数のURLを閲覧した可能性が高い。
Windowsが自動で記録する活動記録（イベントログ）の調査から、2012年６月８日にTorが利用された可能性が高い。メモリにトラブルがあった時の記録（リーク診断イベント）によれば、トラブルを起こしたのは「tbb-firefox.exe」。これは、Torを利用する時に利用されるウェブブラウザの実行ファイルと一致している。トラブルがあった時刻は、05:14:01と記録されているが、これを日本時間に直すと、14:14:01である。
ただし、イベントログには何らかのイベントが発生しないと記録されないので、この記録があった時以外はTorへの接続がない、というわけではない。
2012年６月12日には、したらば掲示板の利用に関連する痕跡があった。
16時41分39秒に同掲示板URL「auto/6682/login/」に、17時17分11秒に「auto/6682/config/」にアクセスした可能性が高い。
マイクロソフトのアンチウイルス製品の検査記録から、2012年４月27日17時49分31秒にDropBoxをダウンロードしていたことを確認した。Windowsの設定情報（レジストリ）から、2012年６月21日にDropBoxをインストールした可能性が高い。ファイルパスから、「TKY-DEV-PC07_2」と「TKY-DEV-PC07」がDropBoxを使用した可能性が高い。
【意図的に痕跡を残すのは困難】
鑑定書で「可能性が高い」と記述した部分は、科学的な正確性を重視しての表記。「Temporary Projects」を含む文字列1つ程度ならば、同名のフォルダを作るなど、Visual C#を使っていなくても痕跡は残せるかもしれない。しかし、（乙社PCのハードディスクには）整合性を保った多量の痕跡があり、たまたま同じ痕跡が残ったとは考えにくい。「イベントログ」「ファイルスラック領域」「レジストリ」「USN Change Journal」など多種類の痕跡が、整合性を保ったまま、たまたま同名の痕跡として残ったとは考えにくい。
ファイルスラック領域の大規模な偽造も、「USN Change Journal」の偽造も現実的ではない。
第三者が、こうした書き込みを行うことは非常に難しい。痕跡を残そうとすれば、残そうとする痕跡が残る。痕跡を消去しても、消去する動作の痕跡が残る。痕跡を偽造するには、動作させるプログラムとWindowsの動作でどういう痕跡が残るかについて、きわめて深い知識が必要だが、それでも予想外の痕跡はいくらでも残る。常識的に考えて、稼働中のPCにおいて、長期にわたって、偽造が疑われないように、意図した痕跡だけを残し続けることは、現実的ではない。私にはできない。
遠隔操作されたPCで、画面を表示しないままVisualC#を使ってプログラムを作成し、操作する側はその状況を見られて動作もできる、というようなマルウェアの存在は聞いたことがない。
【被告人のiesys作成能力は？】
JavaができればC#の利用は容易かどうかを、一般的に判断することは困難である。ただ、JavaとC#は類似点が多いので、目標を低く設定し、C#の特徴を生かさない場合は、高度な技量がなくても習得しやすくなる。Java未経験者より経験者の方がC#を習得しやすい。
被告人が乙社の業務で作成したソースコード、業務経験、保有資格などから、プログラムに何をさせるか（要件）を検討する能力があり、iesys作成に必要な技術に関する基本的な知識を有していると判断できる。iesys等のプログラムに特徴的な部分の基本的知識と経験は有していると判断できる。
iesys本体である「egservice」のソースコードを分析すると、ウェブで探して見つかる情報のコピー（引用）が多く、C#の機能はあまり利用していない。「egservice」のソースコードを記述するために高いプログラミング能力は必要ない。
以上から、能力が確実にあったとまでは断言できないが、あった可能性はあると判断できる。
《江川注：ここまでが主尋問での関証言要旨》
【弁護側反対尋問では「覚えてない」「記憶にない」】
反対尋問には、午前中の新井証人に引き続き、竹田真弁護士が立った。
――鑑定期間は？
乙社PCについては、昨年５月28日～12月６日、C#プログラミングについては12月９日まで。
――５月28日より前に捜査機関から相談を受けたことは？
相談を受けたことはある。
――いつ？
記憶がありません。
――平成24年中か、それとも平成25年に入ってからか。
記憶がありません。
――誤認逮捕が発覚した前か後か。
時期は覚えていない。
――作成した鑑定書は２通だけか。
依頼された鑑定書は２通だけではない。もう１通あります。
――何に関する鑑定か。
だいぶ前なので、記憶がありません。
――セキュリティ関係の経験が多いようだが、プログラマーとしての経験は？
プログラマーの経験はありません。
――C#は使えるか
私は使えません。鑑定に関しては、C#のプログラミングができる技術者が行っています。
――関係署には、乙社PCの複製ハードディスクの他に、「検察庁提供の紙面による参考資料」を調査対象にしたというが、資料は紙媒体だったのか？
紙媒体で受けた。
――デジタルデータは？
記憶にありません。
――書面を受け取ったか。
受け取りました。
――分量はどれくらい？
正確なところ覚えてないです。
――被告人の同僚や上司の供述調書はあったか
あ－、んー、確認しないと分かりません。
――鑑定書には「egserviceのソースコードは、被告人が作成した自主課題プログラムより規模は大きく複雑」と書いてある。
はい。
――egserviceのソースコードの行数はどれくらい？
そこのあたりの細かい所までは覚えていません。
――被告人が作成した自主課題プログラムの行数は？
記憶にありません。
このように、被告人のiesys作成能力についての鑑定に関しては、弁護人が何を聞いても、「覚えてない」「記憶にない」を繰り返すか、「この鑑定結果に関係していることなんでしょうか」と逆質問して回答を渋ったり、「私はこの鑑定書の概要を説明に来た」「鑑定書記載の通り」と回答を避ける状態が続いた。被告人が自主課題として作成したC#プログラムは「プログラマーであれば誰でも書ける程度のもの」だったとする（被告人の）同僚の調書を読み上げ、記憶喚起を促すが、やはり「記憶はない」という答弁だった。
【C#はマルウェアには適さない】
反対尋問では、次のようなやりとりもあった。
竹田弁護士)乙社PCがウイルスによって遠隔操作されている可能性は検討したか
関証人)した。マルウェアがないか、削除済みのものも含めて復元して３種類のアンチウイルスソフトで確認した。
竹田)過去のウィルスは削除して上書きされれば検出されないのではないか。
関）一般的にはそうだが、未知のウイルスやプログラムで、持続的に他のPCをコントロールするためには、そのPCが（いったんシャットダウンした後に）再起動してもコントロールをし続けなければならない。様々なコントロールをするプログラムが入った場合、一定の場所に記録が残る。我々の知見から調査したが、そういう痕跡は検出されなかった。
竹田）定義されていないウイルスは、市販のアンチウイルスソフトでは検知できないのではないか。
関）必ずしもそうではない。アンチウイルスソフトが持つ定義ファイルに登録されていなくても、「ふるまい検知」などによって未知のウイルスを見つける能力を持っている者が多い。
竹田）C#ウイルスは、アンチウイルスソフトでは発見しにくいのでは？
関）そういうことは言えない。C#は逆コンパイルができるので挙動がわかりやすい。C＃でウイルスのソースコードを書くというのは稀有だと思う。
佐藤博史弁護士）C＃でマルウェアを作成するのは稀というのはどういうことか。
関）逆コンパイルをすれば、設計情報が丸わかりになってしまう。マルウェアの場合は、基本的には難読化して、自分の機能を隠そうとするのが普通。C#は、マルウェアには適さない言語だ。
竹田）存在しないパスがファイルスラック領域から抽出されることはあるか。
関）非常に限定的な場合にある。
竹田）どのような場合か。
関）たとえば、仮に対象PCを遠隔操作できた状態で、ファイルの名前を書いたテキストファイルを置いて、消して、うまいこと情報が残るような形で上書きされた場合、そういう状況が残る可能性はある。
【江川コメント：検察は情報をもっとオープンに】
関証人は、フォレンジックを「解剖」にたとえた。証言を聞いていると、確かに細胞単位まで腑分けしていくような印象を受ける。徹底的に解析されれば、わずかな痕跡も見逃さない、という感じがする。ただ、その痕跡と矛盾する別の痕跡があるかどうかを確認しているのかどうかなど、その解析をどう評価するかは、同等の技術を持つ専門家しか分からない。今後、様々な犯罪の捜査で、こうした技術が使われることになるのだろう。ただ、民間企業にそれを託せば、相当の費用もかかる。それを検証する際も同様で、負担できる被告人は限られるだろう。また、IT技術には最も精通していないと思われる裁判所が、それをいかに評価するのか、という問題もある。「可能性が高い」という評価を伴う証言を、どう受け止めたらいいのか、裁判所には把握できるだろうか。
だからこそ、捜査に協力し、検察側証人となった人には、できるだけ情報をオープンにし、反対尋問に対しても、鑑定にいたる経緯、その方法などを詳しく、分かりやすく証言してもらいたい、と思う。ところが関証人は、検察側主尋問においては鑑定書の概要は分かりやすく証言をしたものの、弁護側反対尋問になると、「記憶にない」などで証言をしない場面が多かった。
おそらく、弁護側に反撃の材料を与えないため、証人自身が関わった鑑定については鑑定書の中身に限定した質問に答え、iesys作成能力に関する質問には答えないという戦術を、検察側が証人に指示しているのだろう。証人が回答を渋る前後に、証人の視覚に入る位置に座っていた平光公判部副部長が、証人を見つめながら何度も大きくうなづくのが気になった。激励なのだろうか。それとも合図？
被告人のiesys作成能力に関する鑑定書は、反対尋問を受け付けない状態であり、著しく信頼性が低下したと言わざるをえない。公判前整理手続を経ているので、検察側が新たにこの鑑定の担当者を証人請求するわけにはいかないはずだ。検察側は、なぜ最初から、担当者を証人請求しなかったのか、理解に苦しむ。
また、ラック社が捜査機関とはいつ頃からどのような相談を受けたり情報交換をしていたのかなど、鑑定に至る経緯などを一切証言しないという態度を続ければ、この証人の証言全体についての信頼度は損なわれかねない。このような態度が、検察の指南によるものであれば、これまた検察にとって逆効果ではないのか。
鑑定書を３通作成させながら、２通しか証拠提出しない、という問題もある。検察の見立てに合わない証拠は隠すという、”伝統の”悪癖が出ているのではないか、と気がかりだ。検察は、残る１通を速やかに弁護側に開示すべきだ。
関証人は、自身も含めて４人で鑑定を行ったと証言したが、鑑定書には、鑑定に携わった人の氏名や立場が全く書いてない、という。しかも、検察側から提供された資料について明記しないのはなぜだろうか。鑑定資料は複製ハードディスクを除けば、すべて「紙面による資料」とのこと。ソースコードの分析などを、情報セキュリティの最先端にいる企業が、デジタルデータを要求せずに「紙」のみで行うなんて、ありうるのだろうか。
専門家による「鑑定書」として提出する証拠であれば、少なくとも鑑定者の氏名と立場、鑑定資料のリストくらいは正しくつけておくべきではないのか。書面の体裁などについては、検察庁と打ち合わせのうえで作成しているだろうから、このように検証の材料をできるだけ出さないという形になったのは、検察側の意向なのだろう。
４人が誤認逮捕され、うち２人は虚偽の自白までさせられたという所からスタートした捜査である。通常の事件以上に、検察側はできるだけ捜査のプロセスをオープンにする必要があるだろう。しかし、今回の裁判を見ていると、対応はむしろ逆のようである。裁判には、検察官が６人も公判に立ち会い、３席もの特別傍聴席を確保して東京地検検事正ら検察幹部が傍聴するという異様な力の入れようだが、その割に、できるだけ情報を出さずに守りに入っている感じがする。検察は、できるだけ情報をオープンにして、フェアネスを疑われないように努めてもらいたい。
また、裁判長も証人が弁護側質問にも誠実に答えるよう、もっと働きかけるべきではないか。証人が「覚えていない」「記憶にない」を繰り返し、明らかに鑑定と関連する事項についての問いにも証言をしぶる間、裁判長はわずか一度、それも「証言できたら証言して下さい」と控えめに促しただけだった。わずか４ヶ月前にできあがった鑑定だというのに、鑑定を統括する立場として出てきた関証人が、残る１通は何についての鑑定なのかも覚えていない、などというのは、信じがたい。証人は「何事も隠さず、偽りを述べない」という宣誓をしていることを、思い出させる必要があるのではないか。
もっとも、この日の法廷でのやりとりを聞く限り、弁護側はもう１通の鑑定書については開示を求めたものの、鑑定のメンバーや鑑定資料について、さほど問題にしていないようだ。それがなぜなのか、私にはよく分からない。弁護側は、公判後の記者会見で「検察側の立証は成功しているとは言えない」と明るい顔で語った。果たしてそうなのか…。楽観的にも見える弁護側の自信に満ちた対応には、いささか戸惑う。
もちろん、裁判はまだ始まったばかり。検察側証人となった専門家たちについても、弁護側の本格的な反対尋問や弁護側主尋問を聞いてからでないと、何とも評価はできない。先入観を持たずに、今後の裁判を見守っていきたい。
