はじめに

フォレンジッカー以外にはあまり意識されないと思いますが、タイムスタンプというのは非常に重要です。
ファイルシステムによって保持されるタイムスタンプは異なりますが、ファイルの作成日時、ファイルの最終更新日時といった情報がファイルごとに保持されています。
本記事では、あるファイルをZIPで圧縮した場合、最終更新日時しか保持されないという問題を取り上げます。
（実際には問題ではなくZIPの仕様ですが、フォレンジック調査においては割と問題になるので、ここでは問題と記載しています）

検証

まずは実際に検証してみましょう。以下のようにLinux上でファイルを作成します。
Linuxの場合は、ファイルシステムはext3かext4、XFSあたりがほとんどだと思います。
以下はext4での例です。

$ echo test > test.txt
$ stat test.txt 
  File: test.txt
  Size: 5               Blocks: 8          IO Block: 4096   regular file
Device: 801h/2049d      Inode: 1966092     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    kali)   Gid: ( 1000/    kali)
Access: 2020-06-17 22:54:33.330254678 +0900
Modify: 2020-06-17 22:54:33.330254678 +0900
Change: 2020-06-17 22:54:33.330254678 +0900

ファイルを作成した段階では、ext4が保持する3つのタイムスタンプはすべて同じです。
ではこのtest.txtをzip圧縮してから別の場所に解凍してみます。

 $ stat test/test.txt 
  File: test/test.txt
  Size: 3               Blocks: 8          IO Block: 4096   regular file
Device: 801h/2049d      Inode: 1976419     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    kali)   Gid: ( 1000/    kali)
Access: 2020-06-17 22:54:33.000000000 +0900
Modify: 2020-06-17 22:54:33.000000000 +0900
Change: 2020-06-17 22:57:16.396726759 +0900
 Birth: -

Changeが元のタイムスタンプから変わっているのがわかります。
実はAccessとModifyも小数点以下の値が変わっています。厳密には3つのタイムスタンプすべてが変わっていることになります。

ケーススタディ

実際の調査を行う際には、元のファイルがなく、圧縮されたファイルしかないというケースが想定されます。
この例では、mtimeは保持されますが、ctimeが保持されません。mtimeはファイルを変更すると変わってしまうため、作成された日時が特定できなくなります。

例えばLinux上でWebサーバが運用されており、何らかの方法で侵害され、WebShellが置かれてしまった場合を想定してみましょう。
このインシデントに気づいた管理者は、WebShellをzipで圧縮後、削除してしまったとします。圧縮ファイルの中にあるWebShellは、最終更新日時しかわかりません。
ただし、WebShellが変更されることは通常考えにくいことから、このケースでは最終更新日時は作成日時であると考えても良いでしょう。これが通常編集されるファイルの場合は、作成日時が消滅してしまうことになります。

原因

この現象は、Zipファイルの仕様上、圧縮されたファイルは最終更新日時しか保持しないために起こります。

対策

消滅してしまった情報はどうしようもありませんが、他のアーティファクトから作成日時を特定できる可能性はあります。（Linuxの場合は難しいかもしれません）

また、マルウェアを発見した場合、すぐに隔離したくなりますが、その場合はファイルの圧縮は避け、できればすぐにディスクイメージを作成する、それが難しい場合は、例えばlsコマンドの-cオプションでctimeを取得すると良いと思います。Windowsの場合はdir /TCで作成日時とファイル名をリスト表示できます。