NTFS Timestamps

Windows 10ではアクセス日時の更新設定が変わり、一部の環境では既定で更新するようになりました。

参考: DisableLastAccess and 2 (System Managed, Disabled)

以前、ファイルへの各種処理でどのタイムスタンプが更新されるかをWindows 7環境で確認しましたが、Windows 10を含め、現状のファイル/フォルダに対する様々な操作による更新状況を確認してみました。以下が自環境での検証結果です。

NTFS Timestamps

表内の値は以下を示します。

  • Y (Yes/赤) - その処理時点の時間にセットする
  • N (No/紺) - 更新しない
  • I (Inherited/青) - 処理時点で設定されていた別のタイムスタンプ値をセットする
  • D (Depend/紫) - 環境、対象によってはその処理時点にセットする

ヘッダ内は以下のように省略表記しています。

  • (SI) - $STANDARD_INFORMATION属性
  • (FN) - $FILE_NAME属性

SANSのPosterやCyberForensicator.comで紹介されている内容とも類似しますが、上の表ではフォレンジックツールの表示にあわせて、タイムスタンプを列単位にしています。ファイルのタイムスタンプの話ではMACtime, MACB, MACEの名称で扱うことも多いですが、ここではX-Waysの表記にあわせています。

検証結果をまとめると、各タイムスタンプの基本的な考え方は以下の通りです。

  • Created (SI) - 原則はそのファイルシステム上で作成された日時を示す。別ボリュームから移動されたファイルは、移動方法によっては元ファイルシステムでの作成日時を示す。圧縮ファイルから展開すると、展開ツールによっては更新日時を作成日時にセットする。

 

  • Modified (SI) - コンテンツが最後に更新された日時を示す。別ボリュームからのファイル移動、ファイルコピー、圧縮ファイルの展開等では元の値を維持する傾向にあるが、処理方法によっては処理時点に更新される。フォルダは配下のファイル作成、更新、削除などの処理によって処理時点に更新される。

 

  • Record Changed (SI) - メタデータが最後に更新された日時を示す。様々な処理によって更新される傾向にあるが、別ボリュームからのファイル移動、ファイルコピーについては環境によって元の値を維持することがある。

 

  • Accessed (SI) - 最後に参照された日時を示すが、環境によって更新の有効/無効が異なり、無効の場合は参照しただけで更新することはない。この設定の有効/無効に関わらず、参照以外の様々な処理によって更新される傾向にある。圧縮ファイルから展開すると、展開ツールによっては更新日時をアクセス日時にセットする。

 

  • (FN)のタイムスタンプ - SIのような意味合いを持たない。処理によっていずれも変化がないか全種類更新される傾向にある。ファイル名の変更やボリューム内移動で(SI)の各タイムスタンプがセットされる点は特徴的といえる。

 

以降では、確認した一部の挙動について紹介します。

  • 作業環境
    Windows 10 バージョン1809
    DisableLastAccess = 2
    Firefox 64.0
    Google Chrome 71.0.3578.98
    LibreOffice 6.1.3.2
    fte 1.8.2

 

File Download

IE/Edge, Firefox, Chrome, Invoke-WebRequest(PowerShell)でファイルをダウンロードした際のタイムスタンプは以下の通りでした。

NTFS Timestamps - Download

基本はファイルの新規作成と同様に全タイムスタンプがダウンロード時に設定されていることがわかりますが、細かい差分を見るとCreated(SI)の後にModified(SI), Record Changed(SI), Accessed(SI)が設定されていることがわかります。また、ブラウザによってはModified(SI)の後にRecord Changed(SI)が設定され、さらにその後にAccessed(SI)が設定されています。(FN)のタイムスタンプは後述のRenameの影響を受けているように見えます。

 

File Modification

ファイルの更新は、基本的に対応するアプリケーションでファイルをオープンしてから編集、上書き保存、という流れが一般的です。更新方法はアプリケーションの実装に依存しますが、ここではメモ帳とLibreOfficeで確認した結果を記載します。

メモ帳起動後に最初にファイルを保存し、文章を入力してから保存した際のタイムスタンプは以下の通りでした。

NTFS Timestamps - Modification of Notepad

Modified(SI), Record Changed(SI), Accessed(SI)が更新されています。

次にLibreOfficeです。Writer起動後に新規作成し終了します。いったんファイルを別ボリュームに移動し(理由は後述)、再度LibreOffice Writerを起動してから文章を入力し保存した際のタイムスタンプは以下の通りでした。

NTFS Timestamps - Modification of LibreOffice

ボリューム間のファイル移動ではCreated(SI), Modified(SI)以外のタイムスタンプが更新されています。その後、LibreOfficeでファイルを更新すると、メモ帳の時と同様にModified(SI), Record Changed(SI), Accessed(SI)が更新されていまが、加えて(FN)のタイムスタンプも更新されています。そのうち、Created(FN)についてはCreated(SI)が設定されています。

 

Unzipped File/Folder (7zip)

ダウンロードしたzipファイルと7-zipで展開した後のファイルのタイムスタンプは以下の通りでした。

NTFS Timestamps - Unzipped

zip展開後のファイルは元のModified(SI)の値が引き継がれ、その値がCreated(SI)とAccessed(SI)にも設定されています。Record Changed(SI)と(FN)のタイムスタンプは展開時点に設定されています。

 

File/Folder Rename

renameコマンドでファイル名を変更した際のタイムスタンプは以下の通りでした。

NTFS Timestamps - Rename

元ファイルの(SI)の各タイムスタンプが、(FN)の対応するタイムスタンプに設定されていることがわかります。この挙動はWindows 7の時にも確認していましたが、(SI)と(FN)のタイムスタンプが同じままでは気づかないため、検証時にはファイルのタイムスタンプが同値にならないように気をつける必要があります。LibreOfficeの検証でボリューム間移動を加えたのは、(SI)と(FN)の作成日時を一致させないためでした。

 

bitsadmin

Windows 8以上ではbitsadminコマンドでもリモートのファイルを取得することができます。実行形式は以下です。

> bitsadmin.exe /TRANSFER <ジョブ名> <リモートURL> <ダウンロード先>

取得したファイルのタイムスタンプは以下の通りでした。

NTFS Timestamps - bitsadmin

元のModifiedの値が引き継がれ、Record Changed(SI)、Record Changed(FN)に実行時点の値に設定されますが、それ以外のタイムスタンプにはModified(SI)の値が設定されています。

 

File Access/File Open

表ではAccessとOpenを分けていますが、DisableLastAccess = 2のような最終アクセスの更新が有効な環境では、Explorerでファイルを選択(クリック)するだけでもアクセスの処理となりAccessが更新されます。ただ、一定時間内の複数回のアクセスなどは反映されないなどの条件があるため、注意が必要です。

参考: NTFS last access time and 1 hour (3) / The (in)consistency of last access timestamps

Openはファイルを開いた時としていますが、該当ファイルにObjectIDが付与されていない場合で付与される条件で開くとRecord Changed(SI)が更新されます。

 

留意事項

検証環境で何度か試した結果を表にまとめてみましたが、Windows 7と8以上で挙動が変わったり、コマンドプロンプトとExplorerで挙動が変わったり、標準のzip展開機能と7-zipで挙動が変わったり...という状況のため、この処理では必ずこうなる、という考え方は避けた方が良いように思います。

 

コメント

Great post here chief :)

Just curious if you already tried to acquired memory dump from Win10 32/64bit OS and analyzed it using volatility? If so, any issue encountered like corrupted output or something?

Thanks in advanced.

Thanks! I have experiences of acquisition and analysis memory dump from Win 10. It seems that some commands of volatility don't parse properly, but most outputs are useful. Anyway, we must specify exact profile.

Thank you for presenting this information. I am using NTFS under Windows 10. I would like to obtain the individual file creation dates as text strings, in order to process these strings in a PowerShell script. Alternatively, I could do the same thing using the old Command window. I have not found a way to obtain the creation dates using the commands available in either the PowerShell or Cmd environment. The options on the DIR command do not appear to provide access to the creation date. I would appreciate any suggestions. If this is not possible with shell tools, perhaps it could be done with a program written in C or Java. Thank you.

Hi, thanks for your comment.

I think there are 2 ways of obtaining creation timestamp.

  1. "dir /TC targetfile" provides creation timestamp, but it doesn't display second information.
  2. In PowerShell, "$item=Get-Item -LiteralPath targetfile; $item.CreationTime"

I hope it will help you.